Re: sata_sil, writing bug with multiple cards?
On Wednesday 04 July 2007 05:53:30 Tejun Heo wrote: > [EMAIL PROTECTED] wrote: > > Apologies for the chain-replying to myself, just replying as I think of > > things to try. > > [EMAIL PROTECTED] writes: > >> Here's an odd data point. > >> I just broke that array, formatted all three of those partitions > >> seperately, mounted and did my ISO copy test. > >> All three drives, run one at a time, function fine. No corruption. > > > > Here's another odd one. I did the following: > > # Mount all 3 drives as individuals... > > mount /dev/sda1 /mnt/a > > mount /dev/sdb1 /mnt/b > > mount /dev/sdc1 /mnt/c > > # Copy the same file to all three drives at the same time > > cp KNOPPIX_V5.1.0CD-2006-12-30-EN.iso a/kn10.iso & > > cp KNOPPIX_V5.1.0CD-2006-12-30-EN.iso b/kn10.iso & > > cp KNOPPIX_V5.1.0CD-2006-12-30-EN.iso c/kn10.iso & > > Got massive corruption. > > Hmmm... I don't think this is sata_sil driver bug. cc'ing Andi Kleen > and lkml. Andi, the original thread can be read from > > http://thread.gmane.org/gmane.linux.ide/20213 It seems to be a 32bit system. There is no IOMMU. If it has >2GB or so it might be worth trying booting it with mem=2G and see if it goes away. However if it was the standard VIA DAC issue you should get problems even with a single interface, so probably that's not it either. Most likely it is some sort of hardware bug that we might not be able to do much about. Have you tried contacting SIL or VIA? e.g. if you have some other system with a different chipset it might be useful to test the SIL controllers in those. I would perhaps also try a newer kernel. -Andi - To unsubscribe from this list: send the line "unsubscribe linux-ide" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: sata_sil, writing bug with multiple cards?
Andi Kleen writes: If it has >2GB or so it might be worth trying booting it with mem=2G Nope, only 1GB of RAM. Most likely it is some sort of hardware bug that we might not be able to do much about. Have you tried contacting SIL or VIA? No, I haven't. Like I mentioned above, the OpenBSD drivers seemed to work, or at least did with similar tests. I would need to run the more extensive checks to be positive, but those take a lot of time, obviously. And downtime for the box, a lot of which isn't really manageable, at the moment. e.g. if you have some other system with a different chipset it might be useful to test the SIL controllers in those. The previous motherboard was an AMD 760 chipset, and it had the same problem. I would perhaps also try a newer kernel. I can certainly try that - I admit 2.6.20.3 is a little old now. This will probably take me a couple days - tomorrow is the 4th of July and a holiday for me. - To unsubscribe from this list: send the line "unsubscribe linux-ide" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [info] What's in Jeff's libata-dev inbox?
Jeff Garzik wrote: >>> I have patches from Alan (pata_sis FIFO whack, pata_dma option), Tejun, >>> Albert and Kristen still to be reviewed. Will get to those on Friday, >>> after the July 4th US holiday.tions(-) > > > Just to be more specific, my to-review inbox contains: > > Alan: pata_sis FIFO whack, pata_dma option > > Tejun: PMP patchbomb > > Albert: irq_on/off restructure, irq-driven PIO to wq, minor PIO fixes > Please ignore the "irq-driven PIO to wq" patchset; it's not ready. For the other two patchsets, I'll rediff and resend for your review. -- albert - To unsubscribe from this list: send the line "unsubscribe linux-ide" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/1] ide: pdc202xx_new PLL input clock fix
Sergei Shtylyov wrote: > Bartlomiej Zolnierkiewicz wrote: > >> typos fixed manually > > Signed-off-by: Albert Lee <[EMAIL PROTECTED]> > > >>>Except for types in description: > > >Said he, while making his own typo. :-) > :) -- albert - To unsubscribe from this list: send the line "unsubscribe linux-ide" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 0/2] libata: minor pio fixes (resend)
Minor pio fixes: 1/2: move ata_altstatus() to pio data xfer functions 2/2: change the last state of pio read to HSM_ST_IDLE (The previous "remove unneeded ata_altstatus() from ata_hsm_qc_complete()" has been accepted.) Patch against the libata-dev tree for your review. - To unsubscribe from this list: send the line "unsubscribe linux-ide" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 1/2] libata: move ata_altstatus() to pio data xfer functions
Patch 1/2:
Move ata_altstatus() out from ata_hsm_move() to the pio data xfer functions
like ata_pio_sectors() and atapi_pio_bytes() where it makes more sense.
Signed-off-by: Albert Lee <[EMAIL PROTECTED]>
---
atapi_send_cdb() already calls ata_altstatus() inside.
This patch makes ata_pio_sectors() and atapi_pio_bytes() do the same.
diff -Nrup 00_libata-dev/drivers/ata/libata-core.c
01_move_altstatus/drivers/ata/libata-core.c
--- 00_libata-dev/drivers/ata/libata-core.c 2007-07-04 11:26:30.0
+0800
+++ 01_move_altstatus/drivers/ata/libata-core.c 2007-07-04 11:32:36.0
+0800
@@ -4524,6 +4524,8 @@ static void ata_pio_sectors(struct ata_q
ata_pio_sector(qc);
} else
ata_pio_sector(qc);
+
+ ata_altstatus(ap); /* flush */
}
/**
@@ -4698,6 +4700,7 @@ static void atapi_pio_bytes(struct ata_q
VPRINTK("ata%u: xfering %d bytes\n", ap->print_id, bytes);
__atapi_pio_bytes(qc, bytes);
+ ata_altstatus(ap); /* flush */
return;
@@ -4869,7 +4872,6 @@ fsm_start:
*/
ap->hsm_task_state = HSM_ST;
ata_pio_sectors(qc);
- ata_altstatus(ap); /* flush */
} else
/* send CDB */
atapi_send_cdb(ap, qc);
@@ -4950,7 +4952,6 @@ fsm_start:
if (!(qc->tf.flags & ATA_TFLAG_WRITE)) {
ata_pio_sectors(qc);
- ata_altstatus(ap);
status = ata_wait_idle(ap);
}
@@ -4970,13 +4971,11 @@ fsm_start:
if (ap->hsm_task_state == HSM_ST_LAST &&
(!(qc->tf.flags & ATA_TFLAG_WRITE))) {
/* all data read */
- ata_altstatus(ap);
status = ata_wait_idle(ap);
goto fsm_start;
}
}
- ata_altstatus(ap); /* flush */
poll_next = 1;
break;
-
To unsubscribe from this list: send the line "unsubscribe linux-ide" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 2/2] libata: change the last state of pio read to HSM_ST_IDLE
Patch 2/2:
After reading the last pio data block, the HSM is waiting for device
to be idle, not waiting for the last interrupt.
This patch changes the state after "PIO data-in" to HSM_ST_IDLE instead
of HSM_ST_LAST for accuracy.
Signed-off-by: Albert Lee <[EMAIL PROTECTED]>
---
diff -Nrup 01_move_altstatus/drivers/ata/libata-core.c
02_pio_read_state/drivers/ata/libata-core.c
--- 01_move_altstatus/drivers/ata/libata-core.c 2007-07-04 11:32:36.0
+0800
+++ 02_pio_read_state/drivers/ata/libata-core.c 2007-07-04 11:33:53.0
+0800
@@ -4462,7 +4462,7 @@ static void ata_pio_sector(struct ata_qu
unsigned char *buf;
if (qc->curbytes == qc->nbytes - qc->sect_size)
- ap->hsm_task_state = HSM_ST_LAST;
+ ap->hsm_task_state = do_write ? HSM_ST_LAST : HSM_ST_IDLE;
page = sg[qc->cursg].page;
offset = sg[qc->cursg].offset + qc->cursg_ofs;
@@ -4811,6 +4811,8 @@ int ata_hsm_move(struct ata_port *ap, st
*/
WARN_ON(in_wq != ata_hsm_ok_in_wq(ap, qc));
+ WARN_ON(ap->hsm_task_state == HSM_ST_IDLE);
+
fsm_start:
DPRINTK("ata%u: protocol %d task_state %d (dev_stat 0x%X)\n",
ap->print_id, qc->tf.protocol, ap->hsm_task_state, status);
@@ -4968,8 +4970,7 @@ fsm_start:
ata_pio_sectors(qc);
- if (ap->hsm_task_state == HSM_ST_LAST &&
- (!(qc->tf.flags & ATA_TFLAG_WRITE))) {
+ if (ap->hsm_task_state == HSM_ST_IDLE) {
/* all data read */
status = ata_wait_idle(ap);
goto fsm_start;
@@ -4980,6 +4981,7 @@ fsm_start:
break;
case HSM_ST_LAST:
+ case HSM_ST_IDLE:
if (unlikely(!ata_ok(status))) {
qc->err_mask |= __ac_err_mask(status);
ap->hsm_task_state = HSM_ST_ERR;
-
To unsubscribe from this list: send the line "unsubscribe linux-ide" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 0/10] libata: irq_on/off restructuring
For ATA, there are two levels of mechanism available to turn irq on/off. - device level: nIEN bit in the control register. This masks INTRQ from the device. - host adapter level: some controller can mask out per-port irq from the host adapter. Currently various parts of libata deal with irq on/off. ex. tf_load() can alter the nIEN bit. ex. irq_on() also alters the device level nIEN bit. ex. freeze()/thaw() deal with the host adapter irq mask. It seems these irq on/off codes could be better structured. Patches against libata-dev tree for your review/advice, thanks. 1/10: remove irq_on from ata_bus_reset() and ata_std_postreset() 2/10: add ->irq_off() for symmetry 3/10: implement ->irq_off() in LLDDs 4/10: use irq_off from bmdma_freeze() 5/10: use freeze()/thaw() for polling 6/10: add freeze()/thaw() to old EH LLDDs 7/10: pdc_freeze() semantic change 8/10: remove writing of tf->ctl from ata_tf_load() 9/10: integrate freeze()/thaw() with irq_on/off. 10/10: integrate freeze/thaw with irq_on/off in LLDDs - To unsubscribe from this list: send the line "unsubscribe linux-ide" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: sata_sil, writing bug with multiple cards?
On Wednesday 04 July 2007 10:17:34 [EMAIL PROTECTED] wrote: > > Most likely it is some sort of hardware bug that we might > > not be able to do much about. Have you tried contacting SIL or VIA? > > No, I haven't. Like I mentioned above, the OpenBSD drivers seemed to work, > or at least did with similar tests. I would need to run the more extensive > checks to be positive, but those take a lot of time, obviously. And > downtime for the box, a lot of which isn't really manageable, at the moment. Perhaps the OpenBSD drivers program the SIL chip in a different way that avoids this problem. > > > e.g. if you have some other system with a different chipset it might > > be useful to test the SIL controllers in those. > > The previous motherboard was an AMD 760 chipset, and it had the same > problem. Ok this means it's likely a SIL issue, not a chipset issue. -Andi - To unsubscribe from this list: send the line "unsubscribe linux-ide" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 1/10] libata: remove irq_on from ata_bus_reset() and ata_std_postreset()
Patch 1/10:
After checking, it seems calling irq_on() in ata_bus_reset() and
ata_std_postreset()
are leftover of the EDD reset. Remove them.
Signed-off-by: Albert Lee <[EMAIL PROTECTED]>
---
diff -Nrup 00_libata-dev/drivers/ata/libata-core.c
01_remove_leftover_irqon/drivers/ata/libata-core.c
--- 00_libata-dev/drivers/ata/libata-core.c 2007-07-04 11:26:30.0
+0800
+++ 01_remove_leftover_irqon/drivers/ata/libata-core.c 2007-07-04
11:43:30.0 +0800
@@ -3194,9 +3194,6 @@ void ata_bus_reset(struct ata_port *ap)
if ((slave_possible) && (err != 0x81))
ap->device[1].class = ata_dev_try_classify(ap, 1, &err);
- /* re-enable interrupts */
- ap->ops->irq_on(ap);
-
/* is double-select really necessary? */
if (ap->device[1].class != ATA_DEV_NONE)
ap->ops->dev_select(ap, 1);
@@ -3581,10 +3578,6 @@ void ata_std_postreset(struct ata_port *
if (sata_scr_read(ap, SCR_ERROR, &serror) == 0)
sata_scr_write(ap, SCR_ERROR, serror);
- /* re-enable interrupts */
- if (!ap->ops->error_handler)
- ap->ops->irq_on(ap);
-
/* is double-select really necessary? */
if (classes[0] != ATA_DEV_NONE)
ap->ops->dev_select(ap, 1);
diff -Nrup 00_libata-dev/drivers/ata/pata_scc.c
01_remove_leftover_irqon/drivers/ata/pata_scc.c
--- 00_libata-dev/drivers/ata/pata_scc.c2007-07-04 11:26:30.0
+0800
+++ 01_remove_leftover_irqon/drivers/ata/pata_scc.c 2007-07-04
11:43:30.0 +0800
@@ -892,10 +892,6 @@ static void scc_std_postreset (struct at
{
DPRINTK("ENTER\n");
- /* re-enable interrupts */
- if (!ap->ops->error_handler)
- ap->ops->irq_on(ap);
-
/* is double-select really necessary? */
if (classes[0] != ATA_DEV_NONE)
ap->ops->dev_select(ap, 1);
-
To unsubscribe from this list: send the line "unsubscribe linux-ide" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 2/10] libata: add irq_off
Patch 2/10:
Currently there is ->irq_on but no ->irq_off.
Turning irq off is done via altering the nIEN bit of qc->tf, together with
tf_load().
This patch adds ->irq_off for symmetry.
tf_load() and ata_qc_set_polling() will be fixed/removed in later patches.
Signed-off-by: Albert Lee <[EMAIL PROTECTED]>
---
diff -Nrup 01_remove_leftover_irqon/drivers/ata/libata-core.c
02_add_irq_off/drivers/ata/libata-core.c
--- 01_remove_leftover_irqon/drivers/ata/libata-core.c 2007-07-04
11:43:30.0 +0800
+++ 02_add_irq_off/drivers/ata/libata-core.c2007-07-04 11:57:33.0
+0800
@@ -6901,6 +6901,8 @@ EXPORT_SYMBOL_GPL(ata_eh_qc_retry);
EXPORT_SYMBOL_GPL(ata_do_eh);
EXPORT_SYMBOL_GPL(ata_irq_on);
EXPORT_SYMBOL_GPL(ata_dummy_irq_on);
+EXPORT_SYMBOL_GPL(ata_irq_off);
+EXPORT_SYMBOL_GPL(ata_dummy_irq_off);
EXPORT_SYMBOL_GPL(ata_irq_ack);
EXPORT_SYMBOL_GPL(ata_dummy_irq_ack);
EXPORT_SYMBOL_GPL(ata_dev_try_classify);
diff -Nrup 01_remove_leftover_irqon/drivers/ata/libata-sff.c
02_add_irq_off/drivers/ata/libata-sff.c
--- 01_remove_leftover_irqon/drivers/ata/libata-sff.c 2007-07-04
11:26:30.0 +0800
+++ 02_add_irq_off/drivers/ata/libata-sff.c 2007-07-04 11:57:33.0
+0800
@@ -67,6 +67,39 @@ u8 ata_irq_on(struct ata_port *ap)
u8 ata_dummy_irq_on (struct ata_port *ap) { return 0; }
/**
+ * ata_irq_off - Disable interrupts on a port.
+ * @ap: Port on which interrupts are disabled.
+ *
+ * Disable interrupts on a legacy IDE device using MMIO or PIO,
+ * wait for idle, clear any pending interrupts.
+ *
+ * LOCKING:
+ * Inherited from caller.
+ */
+u8 ata_irq_off(struct ata_port *ap)
+{
+ struct ata_ioports *ioaddr = &ap->ioaddr;
+ u8 tmp;
+
+ ap->ctl |= ATA_NIEN;
+ ap->last_ctl = ap->ctl;
+
+ iowrite8(ap->ctl, ioaddr->ctl_addr);
+
+ /* Under certain circumstances, some controllers raise IRQ on
+* ATA_NIEN manipulation. Also, many controllers fail to mask
+* previously pending IRQ on ATA_NIEN assertion. Clear it.
+*/
+ tmp = ata_wait_idle(ap);
+
+ ap->ops->irq_clear(ap);
+
+ return tmp;
+}
+
+u8 ata_dummy_irq_off (struct ata_port *ap) { return 0; }
+
+/**
* ata_irq_ack - Acknowledge a device interrupt.
* @ap: Port on which interrupts are enabled.
*
diff -Nrup 01_remove_leftover_irqon/drivers/ata/libata.h
02_add_irq_off/drivers/ata/libata.h
--- 01_remove_leftover_irqon/drivers/ata/libata.h 2007-07-04
11:26:30.0 +0800
+++ 02_add_irq_off/drivers/ata/libata.h 2007-07-04 11:57:33.0 +0800
@@ -156,7 +156,5 @@ extern void ata_port_wait_eh(struct ata_
extern void ata_qc_schedule_eh(struct ata_queued_cmd *qc);
/* libata-sff.c */
-extern u8 ata_irq_on(struct ata_port *ap);
-
#endif /* __LIBATA_H__ */
diff -Nrup 01_remove_leftover_irqon/include/linux/libata.h
02_add_irq_off/include/linux/libata.h
--- 01_remove_leftover_irqon/include/linux/libata.h 2007-07-04
11:26:45.0 +0800
+++ 02_add_irq_off/include/linux/libata.h 2007-07-04 11:57:33.0
+0800
@@ -597,6 +597,7 @@ struct ata_port_operations {
irq_handler_t irq_handler;
void (*irq_clear) (struct ata_port *);
u8 (*irq_on) (struct ata_port *);
+ u8 (*irq_off) (struct ata_port *);
u8 (*irq_ack) (struct ata_port *ap, unsigned int chk_drq);
u32 (*scr_read) (struct ata_port *ap, unsigned int sc_reg);
@@ -804,6 +805,8 @@ extern struct ata_device *ata_dev_pair(s
extern int ata_do_set_mode(struct ata_port *ap, struct ata_device
**r_failed_dev);
extern u8 ata_irq_on(struct ata_port *ap);
extern u8 ata_dummy_irq_on(struct ata_port *ap);
+extern u8 ata_irq_off(struct ata_port *ap);
+extern u8 ata_dummy_irq_off(struct ata_port *ap);
extern u8 ata_irq_ack(struct ata_port *ap, unsigned int chk_drq);
extern u8 ata_dummy_irq_ack(struct ata_port *ap, unsigned int chk_drq);
-
To unsubscribe from this list: send the line "unsubscribe linux-ide" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 3/10] libata: implement ->irq_off in LLDDs
Patch 3/10: Implement the newly added ->irq_off in LLDDs. Signed-off-by: Albert Lee <[EMAIL PROTECTED]> --- diff -Nrup 02_add_irq_off/drivers/ata/ahci.c 03_add_irq_off_lldd/drivers/ata/ahci.c --- 02_add_irq_off/drivers/ata/ahci.c 2007-07-04 11:26:30.0 +0800 +++ 03_add_irq_off_lldd/drivers/ata/ahci.c 2007-07-04 12:09:29.0 +0800 @@ -268,6 +268,7 @@ static const struct ata_port_operations .irq_clear = ahci_irq_clear, .irq_on = ata_dummy_irq_on, + .irq_off= ata_dummy_irq_off, .irq_ack= ata_dummy_irq_ack, .scr_read = ahci_scr_read, @@ -302,6 +303,7 @@ static const struct ata_port_operations .irq_clear = ahci_irq_clear, .irq_on = ata_dummy_irq_on, + .irq_off= ata_dummy_irq_off, .irq_ack= ata_dummy_irq_ack, .scr_read = ahci_scr_read, diff -Nrup 02_add_irq_off/drivers/ata/ata_generic.c 03_add_irq_off_lldd/drivers/ata/ata_generic.c --- 02_add_irq_off/drivers/ata/ata_generic.c2007-07-04 11:26:30.0 +0800 +++ 03_add_irq_off_lldd/drivers/ata/ata_generic.c 2007-07-04 12:09:29.0 +0800 @@ -121,6 +121,7 @@ static struct ata_port_operations generi .irq_handler= ata_interrupt, .irq_clear = ata_bmdma_irq_clear, .irq_on = ata_irq_on, + .irq_off= ata_irq_off, .irq_ack= ata_irq_ack, .port_start = ata_port_start, diff -Nrup 02_add_irq_off/drivers/ata/ata_piix.c 03_add_irq_off_lldd/drivers/ata/ata_piix.c --- 02_add_irq_off/drivers/ata/ata_piix.c 2007-07-04 11:26:30.0 +0800 +++ 03_add_irq_off_lldd/drivers/ata/ata_piix.c 2007-07-04 12:09:29.0 +0800 @@ -305,6 +305,7 @@ static const struct ata_port_operations .irq_handler= ata_interrupt, .irq_clear = ata_bmdma_irq_clear, .irq_on = ata_irq_on, + .irq_off= ata_irq_off, .irq_ack= ata_irq_ack, .port_start = ata_port_start, @@ -339,6 +340,7 @@ static const struct ata_port_operations .irq_handler= ata_interrupt, .irq_clear = ata_bmdma_irq_clear, .irq_on = ata_irq_on, + .irq_off= ata_irq_off, .irq_ack= ata_irq_ack, .port_start = ata_port_start, @@ -369,6 +371,7 @@ static const struct ata_port_operations .irq_handler= ata_interrupt, .irq_clear = ata_bmdma_irq_clear, .irq_on = ata_irq_on, + .irq_off= ata_irq_off, .irq_ack= ata_irq_ack, .port_start = ata_port_start, diff -Nrup 02_add_irq_off/drivers/ata/pata_ali.c 03_add_irq_off_lldd/drivers/ata/pata_ali.c --- 02_add_irq_off/drivers/ata/pata_ali.c 2007-07-04 11:26:30.0 +0800 +++ 03_add_irq_off_lldd/drivers/ata/pata_ali.c 2007-07-04 12:09:29.0 +0800 @@ -320,6 +320,7 @@ static struct ata_port_operations ali_ea .irq_handler= ata_interrupt, .irq_clear = ata_bmdma_irq_clear, .irq_on = ata_irq_on, + .irq_off= ata_irq_off, .irq_ack= ata_irq_ack, .port_start = ata_port_start, @@ -362,6 +363,7 @@ static struct ata_port_operations ali_20 .irq_handler= ata_interrupt, .irq_clear = ata_bmdma_irq_clear, .irq_on = ata_irq_on, + .irq_off= ata_irq_off, .irq_ack= ata_irq_ack, .port_start = ata_port_start, @@ -401,6 +403,7 @@ static struct ata_port_operations ali_c2 .irq_handler= ata_interrupt, .irq_clear = ata_bmdma_irq_clear, .irq_on = ata_irq_on, + .irq_off= ata_irq_off, .irq_ack= ata_irq_ack, .port_start = ata_port_start, @@ -439,6 +442,7 @@ static struct ata_port_operations ali_c5 .irq_handler= ata_interrupt, .irq_clear = ata_bmdma_irq_clear, .irq_on = ata_irq_on, + .irq_off= ata_irq_off, .irq_ack= ata_irq_ack, .port_start = ata_port_start, diff -Nrup 02_add_irq_off/drivers/ata/pata_amd.c 03_add_irq_off_lldd/drivers/ata/pata_amd.c --- 02_add_irq_off/drivers/ata/pata_amd.c 2007-07-04 11:26:30.0 +0800 +++ 03_add_irq_off_lldd/drivers/ata/pata_amd.c 2007-07-04 12:09:29.0 +0800 @@ -356,6 +356,7 @@ static struct ata_port_operations amd33_ .irq_handler= ata_interrupt, .irq_clear = ata_bmdma_irq_clear, .irq_on = ata_irq_on, + .irq_off= ata_irq_off, .irq_ack= ata_irq_ack, .port_start = ata_port_start, @@ -39
Re: sata_sil, writing bug with multiple cards?
Andi Kleen wrote: > On Wednesday 04 July 2007 10:17:34 [EMAIL PROTECTED] wrote: > >>> Most likely it is some sort of hardware bug that we might >>> not be able to do much about. Have you tried contacting SIL or VIA? >> No, I haven't. Like I mentioned above, the OpenBSD drivers seemed to work, >> or at least did with similar tests. I would need to run the more extensive >> checks to be positive, but those take a lot of time, obviously. And >> downtime for the box, a lot of which isn't really manageable, at the moment. > > Perhaps the OpenBSD drivers program the SIL chip in a different way > that avoids this problem. > >>> e.g. if you have some other system with a different chipset it might >>> be useful to test the SIL controllers in those. >> The previous motherboard was an AMD 760 chipset, and it had the same >> problem. > > Ok this means it's likely a SIL issue, not a chipset issue. H... okay. I'll take look at the openBSD driver. I still have no idea what it can be tho. Maybe, FIFO setup? Thanks. -- tejun - To unsubscribe from this list: send the line "unsubscribe linux-ide" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 4/10] libata: call irq_off from bmdma_freeze()
Patch 4/10:
Call irq_off() from bmdma_freeze() and remove duplicated code.
Signed-off-by: Albert Lee <[EMAIL PROTECTED]>
---
diff -Nrup 03_add_irq_off_lldd/drivers/ata/libata-sff.c
04_convert_freeze/drivers/ata/libata-sff.c
--- 03_add_irq_off_lldd/drivers/ata/libata-sff.c2007-07-04
11:57:33.0 +0800
+++ 04_convert_freeze/drivers/ata/libata-sff.c 2007-07-04 13:12:38.0
+0800
@@ -413,20 +413,7 @@ void ata_bmdma_stop(struct ata_queued_cm
*/
void ata_bmdma_freeze(struct ata_port *ap)
{
- struct ata_ioports *ioaddr = &ap->ioaddr;
-
- ap->ctl |= ATA_NIEN;
- ap->last_ctl = ap->ctl;
-
- iowrite8(ap->ctl, ioaddr->ctl_addr);
-
- /* Under certain circumstances, some controllers raise IRQ on
-* ATA_NIEN manipulation. Also, many controllers fail to mask
-* previously pending IRQ on ATA_NIEN assertion. Clear it.
-*/
- ata_chk_status(ap);
-
- ap->ops->irq_clear(ap);
+ ap->ops->irq_off(ap);
}
/**
diff -Nrup 03_add_irq_off_lldd/drivers/ata/pata_scc.c
04_convert_freeze/drivers/ata/pata_scc.c
--- 03_add_irq_off_lldd/drivers/ata/pata_scc.c 2007-07-04 12:09:29.0
+0800
+++ 04_convert_freeze/drivers/ata/pata_scc.c2007-07-04 13:12:38.0
+0800
@@ -875,20 +875,7 @@ static u8 scc_irq_ack (struct ata_port *
static void scc_bmdma_freeze (struct ata_port *ap)
{
- struct ata_ioports *ioaddr = &ap->ioaddr;
-
- ap->ctl |= ATA_NIEN;
- ap->last_ctl = ap->ctl;
-
- out_be32(ioaddr->ctl_addr, ap->ctl);
-
- /* Under certain circumstances, some controllers raise IRQ on
-* ATA_NIEN manipulation. Also, many controllers fail to mask
-* previously pending IRQ on ATA_NIEN assertion. Clear it.
-*/
- ata_chk_status(ap);
-
- ap->ops->irq_clear(ap);
+ scc_irq_off(ap);
}
/**
-
To unsubscribe from this list: send the line "unsubscribe linux-ide" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: how to handle pata_via when controller not in fully-pci-native mode (two irqs?)
Matt Sealey wrote: > Well, let's put the class code as "native" since the chip is made "native", > in a platform file somewhere. Then, we can have a configuration option in > the platform code which allows users to choose whether the IDE configuration > is reworked to steer to a single IRQ or two IRQs. That way they can choose > which driver they are using (they cannot use both, and compiling in both is > stupid, so..) > > Then pata_via can just work. It does seem easier now to do this in the > platform support thing. As long as it only affects brand new kernels and > is only enabled when libata pata_via is enabled (we can make it depend on > it) then it should work fine, although having it in some other config > page seems pretty quirky. I don't know how you would suggest to do it.. > have CONFIG_FIX_PEGASOS_IDE in drivers/ata/Kconfig and code in > arch/powerpc/platforms/chrp which recognises it? This patch idea has to > get past two teams now, though.. and modifying chip registers that early > in CHRP initialisation seems to be quirky in itself (I don't think PCI > is up yet) :D I forgot about the PCI resource fix up done for legacy hosts. I think making the host legacy is the best way to take here considering that - no change for both ide and libata, just some fix up in platform code. ATA native/legacy thing doesn't mean much. It's just how the resources are allocated. Is there any specific reason to use native mode? -- tejun - To unsubscribe from this list: send the line "unsubscribe linux-ide" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 5/10] libata: use freeze/thaw for polling
Patch 5/10:
This patch changes polling codes to use freeze()/thaw() for irq off/on.
The reason is: some ATAPI devices raises INTRQ even of nIEN = 1.
Using the host adapter irq mask mechanism, if available, is more reliable than
the device nIEN bit.
ata_qc_set_polling() is also removed since now unused.
Signed-off-by: Albert Lee <[EMAIL PROTECTED]>
---
Considerations:
HSM, the new user of freeze()/thaw(), will call freeze()/thaw() in higher
frequency than EH.
Can current implemention of freeze()/thaw() handle it?
diff -Nrup 04_convert_freeze/drivers/ata/libata-core.c
05_convert_hsm_to_freeze/drivers/ata/libata-core.c
--- 04_convert_freeze/drivers/ata/libata-core.c 2007-07-04 11:57:33.0
+0800
+++ 05_convert_hsm_to_freeze/drivers/ata/libata-core.c 2007-07-04
13:13:56.0 +0800
@@ -4753,7 +4753,7 @@ static void ata_hsm_qc_complete(struct a
qc = ata_qc_from_tag(ap, qc->tag);
if (qc) {
if (likely(!(qc->err_mask & AC_ERR_HSM))) {
- ap->ops->irq_on(ap);
+ ap->ops->thaw(ap);
ata_qc_complete(qc);
} else
ata_port_freeze(ap);
@@ -4769,7 +4769,7 @@ static void ata_hsm_qc_complete(struct a
} else {
if (in_wq) {
spin_lock_irqsave(ap->lock, flags);
- ap->ops->irq_on(ap);
+ ap->ops->thaw(ap);
ata_qc_complete(qc);
spin_unlock_irqrestore(ap->lock, flags);
} else
@@ -5411,7 +5411,7 @@ unsigned int ata_qc_issue_prot(struct at
switch (qc->tf.protocol) {
case ATA_PROT_NODATA:
if (qc->tf.flags & ATA_TFLAG_POLLING)
- ata_qc_set_polling(qc);
+ ap->ops->freeze(ap);
ata_tf_to_host(ap, &qc->tf);
ap->hsm_task_state = HSM_ST_LAST;
@@ -5432,7 +5432,7 @@ unsigned int ata_qc_issue_prot(struct at
case ATA_PROT_PIO:
if (qc->tf.flags & ATA_TFLAG_POLLING)
- ata_qc_set_polling(qc);
+ ap->ops->freeze(ap);
ata_tf_to_host(ap, &qc->tf);
@@ -5461,7 +5461,7 @@ unsigned int ata_qc_issue_prot(struct at
case ATA_PROT_ATAPI:
case ATA_PROT_ATAPI_NODATA:
if (qc->tf.flags & ATA_TFLAG_POLLING)
- ata_qc_set_polling(qc);
+ ap->ops->freeze(ap);
ata_tf_to_host(ap, &qc->tf);
diff -Nrup 04_convert_freeze/include/linux/libata.h
05_convert_hsm_to_freeze/include/linux/libata.h
--- 04_convert_freeze/include/linux/libata.h2007-07-04 11:57:33.0
+0800
+++ 05_convert_hsm_to_freeze/include/linux/libata.h 2007-07-04
13:13:56.0 +0800
@@ -1097,11 +1097,6 @@ static inline u8 ata_wait_idle(struct at
return status;
}
-static inline void ata_qc_set_polling(struct ata_queued_cmd *qc)
-{
- qc->tf.ctl |= ATA_NIEN;
-}
-
static inline struct ata_queued_cmd *__ata_qc_from_tag(struct ata_port *ap,
unsigned int tag)
{
-
To unsubscribe from this list: send the line "unsubscribe linux-ide" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH libata-dev#upstream] libata: kill duplicate functions
I like these _dumb functions but I think we can live with just one
copy.
Signed-off-by: Tejun Heo <[EMAIL PROTECTED]>
---
drivers/ata/libata-core.c | 79 --
1 file changed, 79 deletions(-)
Index: work/drivers/ata/libata-core.c
===
--- work.orig/drivers/ata/libata-core.c
+++ work/drivers/ata/libata-core.c
@@ -4165,68 +4165,6 @@ static void ata_fill_sg_dumb(struct ata_
}
/**
- * ata_fill_sg_dumb - Fill PCI IDE PRD table
- * @qc: Metadata associated with taskfile to be transferred
- *
- * Fill PCI IDE PRD (scatter-gather) table with segments
- * associated with the current disk command. Perform the fill
- * so that we avoid writing any length 64K records for
- * controllers that don't follow the spec.
- *
- * LOCKING:
- * spin_lock_irqsave(host lock)
- *
- */
-static void ata_fill_sg_dumb(struct ata_queued_cmd *qc)
-{
- struct ata_port *ap = qc->ap;
- struct scatterlist *sg;
- unsigned int idx;
-
- WARN_ON(qc->__sg == NULL);
- WARN_ON(qc->n_elem == 0 && qc->pad_len == 0);
-
- idx = 0;
- ata_for_each_sg(sg, qc) {
- u32 addr, offset;
- u32 sg_len, len, blen;
-
- /* determine if physical DMA addr spans 64K boundary.
-* Note h/w doesn't support 64-bit, so we unconditionally
-* truncate dma_addr_t to u32.
-*/
- addr = (u32) sg_dma_address(sg);
- sg_len = sg_dma_len(sg);
-
- while (sg_len) {
- offset = addr & 0x;
- len = sg_len;
- if ((offset + sg_len) > 0x1)
- len = 0x1 - offset;
-
- blen = len & 0x;
- ap->prd[idx].addr = cpu_to_le32(addr);
- if (blen == 0) {
- /* Some PATA chipsets like the CS5530 can't
- cope with 0x meaning 64K as the spec
says */
- ap->prd[idx].flags_len = cpu_to_le32(0x8000);
- blen = 0x8000;
- ap->prd[++idx].addr = cpu_to_le32(addr +
0x8000);
- }
- ap->prd[idx].flags_len = cpu_to_le32(blen);
- VPRINTK("PRD[%u] = (0x%X, 0x%X)\n", idx, addr, len);
-
- idx++;
- sg_len -= len;
- addr += len;
- }
- }
-
- if (idx)
- ap->prd[idx - 1].flags_len |= cpu_to_le32(ATA_PRD_EOT);
-}
-
-/**
* ata_check_atapi_dma - Check whether ATAPI DMA can be supported
* @qc: Metadata associated with taskfile to check
*
@@ -4290,23 +4228,6 @@ void ata_dumb_qc_prep(struct ata_queued_
ata_fill_sg_dumb(qc);
}
-/**
- * ata_dumb_qc_prep - Prepare taskfile for submission
- * @qc: Metadata associated with taskfile to be prepared
- *
- * Prepare ATA taskfile for submission.
- *
- * LOCKING:
- * spin_lock_irqsave(host lock)
- */
-void ata_dumb_qc_prep(struct ata_queued_cmd *qc)
-{
- if (!(qc->flags & ATA_QCFLAG_DMAMAP))
- return;
-
- ata_fill_sg_dumb(qc);
-}
-
void ata_noop_qc_prep(struct ata_queued_cmd *qc) { }
/**
-
To unsubscribe from this list: send the line "unsubscribe linux-ide" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 6/10] libata: add freeze/thaw to old EH LLDDs
Patch 6/10:
Now that HSM polling code path uses freeze()/thaw() regardless of old EH or new
EH.
Add freeze()/thaw() to old EH LLDDs for the HSM polling code.
Signed-off-by: Albert Lee <[EMAIL PROTECTED]>
---
diff -Nrup 05_convert_hsm_to_freeze/drivers/ata/pata_ixp4xx_cf.c
06_add_freeze_thaw_to_lldd/drivers/ata/pata_ixp4xx_cf.c
--- 05_convert_hsm_to_freeze/drivers/ata/pata_ixp4xx_cf.c 2007-07-04
12:09:29.0 +0800
+++ 06_add_freeze_thaw_to_lldd/drivers/ata/pata_ixp4xx_cf.c 2007-07-04
13:17:13.0 +0800
@@ -131,6 +131,9 @@ static struct ata_port_operations ixp4xx
.data_xfer = ixp4xx_mmio_data_xfer,
.cable_detect = ata_cable_40wire,
+ .freeze = ata_bmdma_freeze,
+ .thaw = ata_bmdma_thaw,
+
.irq_clear = ixp4xx_irq_clear,
.irq_on = ata_irq_on,
.irq_off= ata_irq_off,
diff -Nrup 05_convert_hsm_to_freeze/drivers/ata/pata_scc.c
06_add_freeze_thaw_to_lldd/drivers/ata/pata_scc.c
--- 05_convert_hsm_to_freeze/drivers/ata/pata_scc.c 2007-07-04
13:12:38.0 +0800
+++ 06_add_freeze_thaw_to_lldd/drivers/ata/pata_scc.c 2007-07-04
13:17:13.0 +0800
@@ -879,6 +879,18 @@ static void scc_bmdma_freeze (struct ata
}
/**
+ * scc_bmdma_thaw - Thaw BMDMA controller port
+ * @ap: port to thaw
+ *
+ * Note: Original code is ata_bmdma_thaw().
+ */
+
+static void scc_bmdma_thaw (struct ata_port *ap)
+{
+ scc_irq_on(ap);
+}
+
+/**
* scc_pata_prereset - prepare for reset
* @ap: ATA port to be reset
* @deadline: deadline jiffies for the operation
@@ -1025,6 +1037,7 @@ static const struct ata_port_operations
.qc_issue = ata_qc_issue_prot,
.freeze = scc_bmdma_freeze,
+ .thaw = scc_bmdma_thaw,
.error_handler = scc_error_handler,
.post_internal_cmd = scc_bmdma_stop,
diff -Nrup 05_convert_hsm_to_freeze/drivers/ata/pdc_adma.c
06_add_freeze_thaw_to_lldd/drivers/ata/pdc_adma.c
--- 05_convert_hsm_to_freeze/drivers/ata/pdc_adma.c 2007-07-04
12:09:29.0 +0800
+++ 06_add_freeze_thaw_to_lldd/drivers/ata/pdc_adma.c 2007-07-04
13:17:13.0 +0800
@@ -171,6 +171,8 @@ static const struct ata_port_operations
.qc_issue = adma_qc_issue,
.eng_timeout= adma_eng_timeout,
.data_xfer = ata_data_xfer,
+ .freeze = ata_bmdma_freeze,
+ .thaw = ata_bmdma_thaw,
.irq_clear = adma_irq_clear,
.irq_on = ata_irq_on,
.irq_off= ata_irq_off,
diff -Nrup 05_convert_hsm_to_freeze/drivers/ata/sata_mv.c
06_add_freeze_thaw_to_lldd/drivers/ata/sata_mv.c
--- 05_convert_hsm_to_freeze/drivers/ata/sata_mv.c 2007-07-04
12:09:29.0 +0800
+++ 06_add_freeze_thaw_to_lldd/drivers/ata/sata_mv.c2007-07-04
13:17:13.0 +0800
@@ -453,6 +453,9 @@ static const struct ata_port_operations
.eng_timeout= mv_eng_timeout,
+ .freeze = ata_bmdma_freeze,
+ .thaw = ata_bmdma_thaw,
+
.irq_clear = mv_irq_clear,
.irq_on = ata_irq_on,
.irq_off= ata_irq_off,
@@ -483,6 +486,9 @@ static const struct ata_port_operations
.eng_timeout= mv_eng_timeout,
+ .freeze = ata_bmdma_freeze,
+ .thaw = ata_bmdma_thaw,
+
.irq_clear = mv_irq_clear,
.irq_on = ata_irq_on,
.irq_off= ata_irq_off,
@@ -513,6 +519,9 @@ static const struct ata_port_operations
.eng_timeout= mv_eng_timeout,
+ .freeze = ata_bmdma_freeze,
+ .thaw = ata_bmdma_thaw,
+
.irq_clear = mv_irq_clear,
.irq_on = ata_irq_on,
.irq_off= ata_irq_off,
diff -Nrup 05_convert_hsm_to_freeze/drivers/ata/sata_qstor.c
06_add_freeze_thaw_to_lldd/drivers/ata/sata_qstor.c
--- 05_convert_hsm_to_freeze/drivers/ata/sata_qstor.c 2007-07-04
12:09:29.0 +0800
+++ 06_add_freeze_thaw_to_lldd/drivers/ata/sata_qstor.c 2007-07-04
13:17:13.0 +0800
@@ -157,6 +157,8 @@ static const struct ata_port_operations
.qc_issue = qs_qc_issue,
.data_xfer = ata_data_xfer,
.eng_timeout= qs_eng_timeout,
+ .freeze = ata_bmdma_freeze,
+ .thaw = ata_bmdma_thaw,
.irq_clear = qs_irq_clear,
.irq_on = ata_irq_on,
.irq_off= ata_irq_off,
diff -Nrup 05_convert_hsm_to_freeze/drivers/ata/sata_sx4.c
06_add_freeze_thaw_to_lldd/drivers/ata/sata_sx4.c
--- 05_convert_hsm_to_freeze/drivers/ata/sata_sx4.c 2007
[PATCH 7/10] libata: pdc_freeze() semantic change
Patch 7/10: After checking the current implementations of freeze()/thaw(), it seems only pdc_freeze() do more than simple irq masking. Remove the DMA stop code from pdc_freeze(). Signed-off-by: Albert Lee <[EMAIL PROTECTED]> --- diff -Nrup 06_add_freeze_thaw_to_lldd/drivers/ata/sata_promise.c 07_sata_promise_freeze/drivers/ata/sata_promise.c --- 06_add_freeze_thaw_to_lldd/drivers/ata/sata_promise.c 2007-07-04 12:09:29.0 +0800 +++ 07_sata_promise_freeze/drivers/ata/sata_promise.c 2007-07-04 13:17:59.0 +0800 @@ -581,7 +581,6 @@ static void pdc_freeze(struct ata_port * tmp = readl(mmio + PDC_CTLSTAT); tmp |= PDC_IRQ_DISABLE; - tmp &= ~PDC_DMA_ENABLE; writel(tmp, mmio + PDC_CTLSTAT); readl(mmio + PDC_CTLSTAT); /* flush */ } - To unsubscribe from this list: send the line "unsubscribe linux-ide" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH libata-dev#upstream] libata: simplify PCI legacy SFF host handling
With PCI resource fix up for legacy hosts. We can use the same code
path to allocate IO resources and initialize host for both legacy and
native SFF hosts. Only IRQ requesting needs to be different.
Rename ata_pci_*_native_host() to ata_pci_*_sff_host(), kill all
legacy specific functions and use the renamed functions instead. This
simplifies code a lot.
Signed-off-by: Tejun Heo <[EMAIL PROTECTED]>
Cc: Alan Cox <[EMAIL PROTECTED]>
---
Gee, I like it. The BAR fixup thing was a really good idea. :-)
drivers/ata/libata-core.c |4
drivers/ata/libata-sff.c | 288 +-
drivers/ata/sata_nv.c |2
drivers/ata/sata_sis.c|2
drivers/ata/sata_uli.c|2
drivers/ata/sata_via.c|2
include/linux/libata.h|8 -
7 files changed, 42 insertions(+), 266 deletions(-)
Index: work/drivers/ata/libata-core.c
===
--- work.orig/drivers/ata/libata-core.c
+++ work/drivers/ata/libata-core.c
@@ -6961,9 +6961,9 @@ EXPORT_SYMBOL_GPL(ata_timing_merge);
#ifdef CONFIG_PCI
EXPORT_SYMBOL_GPL(pci_test_config_bits);
-EXPORT_SYMBOL_GPL(ata_pci_init_native_host);
+EXPORT_SYMBOL_GPL(ata_pci_init_sff_host);
EXPORT_SYMBOL_GPL(ata_pci_init_bmdma);
-EXPORT_SYMBOL_GPL(ata_pci_prepare_native_host);
+EXPORT_SYMBOL_GPL(ata_pci_prepare_sff_host);
EXPORT_SYMBOL_GPL(ata_pci_init_one);
EXPORT_SYMBOL_GPL(ata_pci_remove_one);
#ifdef CONFIG_PM
Index: work/drivers/ata/libata-sff.c
===
--- work.orig/drivers/ata/libata-sff.c
+++ work/drivers/ata/libata-sff.c
@@ -604,13 +604,17 @@ int ata_pci_init_bmdma(struct ata_host *
}
/**
- * ata_pci_init_native_host - acquire native ATA resources and init host
+ * ata_pci_init_sff_host - acquire native PCI ATA resources and init host
* @host: target ATA host
*
* Acquire native PCI ATA resources for @host and initialize the
* first two ports of @host accordingly. Ports marked dummy are
* skipped and allocation failure makes the port dummy.
*
+ * Note that native PCI resources are valid even for legacy hosts
+ * as we fix up pdev resources array early in boot, so this
+ * function can be used for both native and legacy SFF hosts.
+ *
* LOCKING:
* Inherited from calling layer (may sleep).
*
@@ -618,7 +622,7 @@ int ata_pci_init_bmdma(struct ata_host *
* 0 if at least one port is initialized, -ENODEV if no port is
* available.
*/
-int ata_pci_init_native_host(struct ata_host *host)
+int ata_pci_init_sff_host(struct ata_host *host)
{
struct device *gdev = host->dev;
struct pci_dev *pdev = to_pci_dev(gdev);
@@ -673,7 +677,7 @@ int ata_pci_init_native_host(struct ata_
}
/**
- * ata_pci_prepare_native_host - helper to prepare native PCI ATA host
+ * ata_pci_prepare_sff_host - helper to prepare native PCI ATA host
* @pdev: target PCI device
* @ppi: array of port_info, must be enough for two ports
* @r_host: out argument for the initialized ATA host
@@ -687,9 +691,9 @@ int ata_pci_init_native_host(struct ata_
* RETURNS:
* 0 on success, -errno otherwise.
*/
-int ata_pci_prepare_native_host(struct pci_dev *pdev,
- const struct ata_port_info * const * ppi,
- struct ata_host **r_host)
+int ata_pci_prepare_sff_host(struct pci_dev *pdev,
+const struct ata_port_info * const * ppi,
+struct ata_host **r_host)
{
struct ata_host *host;
int rc;
@@ -705,7 +709,7 @@ int ata_pci_prepare_native_host(struct p
goto err_out;
}
- rc = ata_pci_init_native_host(host);
+ rc = ata_pci_init_sff_host(host);
if (rc)
goto err_out;
@@ -730,221 +734,6 @@ int ata_pci_prepare_native_host(struct p
return rc;
}
-struct ata_legacy_devres {
- unsigned intmask;
- unsigned long cmd_port[2];
- void __iomem * cmd_addr[2];
- void __iomem * ctl_addr[2];
- unsigned intirq[2];
- void * irq_dev_id[2];
-};
-
-static void ata_legacy_free_irqs(struct ata_legacy_devres *legacy_dr)
-{
- int i;
-
- for (i = 0; i < 2; i++) {
- if (!legacy_dr->irq[i])
- continue;
-
- free_irq(legacy_dr->irq[i], legacy_dr->irq_dev_id[i]);
- legacy_dr->irq[i] = 0;
- legacy_dr->irq_dev_id[i] = NULL;
- }
-}
-
-static void ata_legacy_release(struct device *gdev, void *res)
-{
- struct ata_legacy_devres *this = res;
- int i;
-
- ata_legacy_free_irqs(this);
-
- for (i = 0; i < 2; i++) {
- if (this->cmd_addr[i])
- ioport_unmap(this->cmd_addr[i]);
- if (this->ctl_addr[i])
- ioport_unmap(this->ctl
[PATCH 8/10] libata: remove writing of tf->ctl from ata_tf_load()
Patch 8/10:
The relevant bits in the ctl register are HOB, SRST and nIEN.
- HOB is only used by ata_tf_read().
- For SRST, soft reset is not the duty of tf_load.
- For nIEN, explicit irq_on()/irq_off and freeze()/thaw() are provided.
Since EH/HSM now call explicit freeze()/thaw() for irq off/on.
Remove the implicit nIEN handling from ata_tf_load().
Signed-off-by: Albert Lee <[EMAIL PROTECTED]>
---
diff -Nrup 07_sata_promise_freeze/drivers/ata/libata-sff.c
08_tfload_cleanup/drivers/ata/libata-sff.c
--- 07_sata_promise_freeze/drivers/ata/libata-sff.c 2007-07-04
13:12:38.0 +0800
+++ 08_tfload_cleanup/drivers/ata/libata-sff.c 2007-07-04 13:20:30.0
+0800
@@ -153,11 +153,13 @@ void ata_tf_load(struct ata_port *ap, co
struct ata_ioports *ioaddr = &ap->ioaddr;
unsigned int is_addr = tf->flags & ATA_TFLAG_ISADDR;
- if (tf->ctl != ap->last_ctl) {
- iowrite8(tf->ctl, ioaddr->ctl_addr);
- ap->last_ctl = tf->ctl;
- ata_wait_idle(ap);
- }
+ /*
+* The relevant bits in the ctl register are HOB, SRST and nIEN.
+* HOB is only used by ata_tf_read().
+* For SRST, soft reset is not the duty of tf_load.
+* For nIEN, explicit ->irq_on() and ->irq_off are provided.
+* That's why tf->ctl is ignored here.
+*/
if (is_addr && (tf->flags & ATA_TFLAG_LBA48)) {
iowrite8(tf->hob_feature, ioaddr->feature_addr);
diff -Nrup 07_sata_promise_freeze/drivers/ata/pata_scc.c
08_tfload_cleanup/drivers/ata/pata_scc.c
--- 07_sata_promise_freeze/drivers/ata/pata_scc.c 2007-07-04
13:17:13.0 +0800
+++ 08_tfload_cleanup/drivers/ata/pata_scc.c2007-07-04 13:20:30.0
+0800
@@ -271,12 +271,6 @@ static void scc_tf_load (struct ata_port
struct ata_ioports *ioaddr = &ap->ioaddr;
unsigned int is_addr = tf->flags & ATA_TFLAG_ISADDR;
- if (tf->ctl != ap->last_ctl) {
- out_be32(ioaddr->ctl_addr, tf->ctl);
- ap->last_ctl = tf->ctl;
- ata_wait_idle(ap);
- }
-
if (is_addr && (tf->flags & ATA_TFLAG_LBA48)) {
out_be32(ioaddr->feature_addr, tf->hob_feature);
out_be32(ioaddr->nsect_addr, tf->hob_nsect);
diff -Nrup 07_sata_promise_freeze/drivers/ata/sata_svw.c
08_tfload_cleanup/drivers/ata/sata_svw.c
--- 07_sata_promise_freeze/drivers/ata/sata_svw.c 2007-07-04
12:09:29.0 +0800
+++ 08_tfload_cleanup/drivers/ata/sata_svw.c2007-07-04 13:20:30.0
+0800
@@ -125,11 +125,6 @@ static void k2_sata_tf_load(struct ata_p
struct ata_ioports *ioaddr = &ap->ioaddr;
unsigned int is_addr = tf->flags & ATA_TFLAG_ISADDR;
- if (tf->ctl != ap->last_ctl) {
- writeb(tf->ctl, ioaddr->ctl_addr);
- ap->last_ctl = tf->ctl;
- ata_wait_idle(ap);
- }
if (is_addr && (tf->flags & ATA_TFLAG_LBA48)) {
writew(tf->feature | (((u16)tf->hob_feature) << 8),
ioaddr->feature_addr);
diff -Nrup 07_sata_promise_freeze/drivers/ata/sata_vsc.c
08_tfload_cleanup/drivers/ata/sata_vsc.c
--- 07_sata_promise_freeze/drivers/ata/sata_vsc.c 2007-07-04
12:09:29.0 +0800
+++ 08_tfload_cleanup/drivers/ata/sata_vsc.c2007-07-04 13:20:30.0
+0800
@@ -137,36 +137,11 @@ static void vsc_thaw(struct ata_port *ap
}
-static void vsc_intr_mask_update(struct ata_port *ap, u8 ctl)
-{
- void __iomem *mask_addr;
- u8 mask;
-
- mask_addr = ap->host->iomap[VSC_MMIO_BAR] +
- VSC_SATA_INT_MASK_OFFSET + ap->port_no;
- mask = readb(mask_addr);
- if (ctl & ATA_NIEN)
- mask |= 0x80;
- else
- mask &= 0x7F;
- writeb(mask, mask_addr);
-}
-
-
static void vsc_sata_tf_load(struct ata_port *ap, const struct ata_taskfile
*tf)
{
struct ata_ioports *ioaddr = &ap->ioaddr;
unsigned int is_addr = tf->flags & ATA_TFLAG_ISADDR;
- /*
-* The only thing the ctl register is used for is SRST.
-* That is not enabled or disabled via tf_load.
-* However, if ATA_NIEN is changed, then we need to change the
interrupt register.
-*/
- if ((tf->ctl & ATA_NIEN) != (ap->last_ctl & ATA_NIEN)) {
- ap->last_ctl = tf->ctl;
- vsc_intr_mask_update(ap, tf->ctl & ATA_NIEN);
- }
if (is_addr && (tf->flags & ATA_TFLAG_LBA48)) {
writew(tf->feature | (((u16)tf->hob_feature) << 8),
ioaddr->feature_addr);
-
To unsubscribe from this list: send the line "unsubscribe linux-ide" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Linux Software RAID is really RAID?
> > A hard(ware) lockup, not software. > > That's why Intel says ICH5 doesn't do hotplug. > > OIC. I don't think there's much left to do from the driver side then. > Or is there any workaround? I'm not familiar with the ICH5 SATA side but on the PATA side we also need to run code to fix up chips on a hotplug (and *before* the plug in some cases) - eg the ICH2 requires we turn off IORDY. - To unsubscribe from this list: send the line "unsubscribe linux-ide" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: sata_sil, writing bug with multiple cards?
> # Make a RAID5 array of 3 out of the 4 drives I'll eventually be using > mdadm --create /dev/md6 --chunk=64 --level=raid5 --raid-devices=4 /dev/sda1 > /dev/sdb1 /dev/sdc1 missing > # Make the FS > mkfs.ext3 /dev/md6 > # Test > cp KNOPPIX_V5.1.0CD-2006-12-30-EN.iso kn1.iso > cp kn1.iso kn2.iso > cp kn2.iso kn3.iso > cp kn3.iso kn4.iso > # Check > md5sum *.iso > eea5ecb53f1c6a397bcfeedc2fd42c64 kn1.iso > 0360941210aa2d715e37c636f8cb kn2.iso > md5sum: kn3.iso: Input/output error > 86b008915fe02569a513b6c5ec45a523 kn4.iso Not suprised to be honest. We have a large number of reports that are all of the following form "Nvidia chipset, Silicon Image SATA, corruption" and several reports that BIOS updates fixed it. Unfortunately we don't know what the BIOS updates do (or indeed if what they do is board specific) or how to work around it otherwise. Alan - To unsubscribe from this list: send the line "unsubscribe linux-ide" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: sata_sil, writing bug with multiple cards?
Alan Cox wrote: >> # Make a RAID5 array of 3 out of the 4 drives I'll eventually be using >> mdadm --create /dev/md6 --chunk=64 --level=raid5 --raid-devices=4 /dev/sda1 >> /dev/sdb1 /dev/sdc1 missing >> # Make the FS >> mkfs.ext3 /dev/md6 >> # Test >> cp KNOPPIX_V5.1.0CD-2006-12-30-EN.iso kn1.iso >> cp kn1.iso kn2.iso >> cp kn2.iso kn3.iso >> cp kn3.iso kn4.iso >> # Check >> md5sum *.iso >> eea5ecb53f1c6a397bcfeedc2fd42c64 kn1.iso >> 0360941210aa2d715e37c636f8cb kn2.iso >> md5sum: kn3.iso: Input/output error >> 86b008915fe02569a513b6c5ec45a523 kn4.iso > > Not suprised to be honest. We have a large number of reports that are all > of the following form > > "Nvidia chipset, Silicon Image SATA, corruption" > > and several reports that BIOS updates fixed it. Unfortunately we don't > know what the BIOS updates do (or indeed if what they do is board > specific) or how to work around it otherwise. I thought good number of those were the IOMMU bug but I could be mistaken. Considering the large number of sata_sil's in the field, it's a bit surprising to see we still have this kind of problem. :-( -- tejun - To unsubscribe from this list: send the line "unsubscribe linux-ide" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Libata PATA status
> I'd love to try to poke holes in the libata PATA support, but sadly > it doesn't look like any of my systems built-in ATA chipsets are > supported yet. Has anyone started a rewrite of the PPC/PowerMac IDE > driver? The current one is in "drivers/ide/ppc/pmac.c", and supports > these chipsets: I'm not aware of anyone having done any PPC ports yet, although a couple of people have asked and said they would look at it. Currently our coverage is incomplete for some embedded and obscure platforms, of which the macintrash is probably the least 'obscure'. Alan - To unsubscribe from this list: send the line "unsubscribe linux-ide" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 9/10] libata: Integrate freeze/thaw with irq_on/off
Patch 9/10:
irq_on/irq_off are now only wrapped by freeze/thaw (and unused otherwise).
We can integrate freeze/thaw with irq_on/irq_off.
Signed-off-by: Albert Lee <[EMAIL PROTECTED]>
---
This is for libata-core. The LLDDs will be fixed in the next patch.
diff -Nrup 08_tfload_cleanup/drivers/ata/libata-core.c
09_integrate_irq_on_off/drivers/ata/libata-core.c
--- 08_tfload_cleanup/drivers/ata/libata-core.c 2007-07-04 13:13:56.0
+0800
+++ 09_integrate_irq_on_off/drivers/ata/libata-core.c 2007-07-04
13:35:05.0 +0800
@@ -4753,7 +4753,7 @@ static void ata_hsm_qc_complete(struct a
qc = ata_qc_from_tag(ap, qc->tag);
if (qc) {
if (likely(!(qc->err_mask & AC_ERR_HSM))) {
- ap->ops->thaw(ap);
+ ap->ops->irq_on(ap);
ata_qc_complete(qc);
} else
ata_port_freeze(ap);
@@ -4769,7 +4769,7 @@ static void ata_hsm_qc_complete(struct a
} else {
if (in_wq) {
spin_lock_irqsave(ap->lock, flags);
- ap->ops->thaw(ap);
+ ap->ops->irq_on(ap);
ata_qc_complete(qc);
spin_unlock_irqrestore(ap->lock, flags);
} else
@@ -5411,7 +5411,7 @@ unsigned int ata_qc_issue_prot(struct at
switch (qc->tf.protocol) {
case ATA_PROT_NODATA:
if (qc->tf.flags & ATA_TFLAG_POLLING)
- ap->ops->freeze(ap);
+ ap->ops->irq_off(ap);
ata_tf_to_host(ap, &qc->tf);
ap->hsm_task_state = HSM_ST_LAST;
@@ -5432,7 +5432,7 @@ unsigned int ata_qc_issue_prot(struct at
case ATA_PROT_PIO:
if (qc->tf.flags & ATA_TFLAG_POLLING)
- ap->ops->freeze(ap);
+ ap->ops->irq_off(ap);
ata_tf_to_host(ap, &qc->tf);
@@ -5461,7 +5461,7 @@ unsigned int ata_qc_issue_prot(struct at
case ATA_PROT_ATAPI:
case ATA_PROT_ATAPI_NODATA:
if (qc->tf.flags & ATA_TFLAG_POLLING)
- ap->ops->freeze(ap);
+ ap->ops->irq_off(ap);
ata_tf_to_host(ap, &qc->tf);
@@ -6758,8 +6758,6 @@ const struct ata_port_operations ata_dum
.dev_select = ata_noop_dev_select,
.qc_prep= ata_noop_qc_prep,
.qc_issue = ata_dummy_qc_issue,
- .freeze = ata_dummy_noret,
- .thaw = ata_dummy_noret,
.error_handler = ata_dummy_noret,
.post_internal_cmd = ata_dummy_qc_noret,
.irq_clear = ata_dummy_noret,
@@ -6821,8 +6819,6 @@ EXPORT_SYMBOL_GPL(ata_bmdma_start);
EXPORT_SYMBOL_GPL(ata_bmdma_irq_clear);
EXPORT_SYMBOL_GPL(ata_bmdma_status);
EXPORT_SYMBOL_GPL(ata_bmdma_stop);
-EXPORT_SYMBOL_GPL(ata_bmdma_freeze);
-EXPORT_SYMBOL_GPL(ata_bmdma_thaw);
EXPORT_SYMBOL_GPL(ata_bmdma_drive_eh);
EXPORT_SYMBOL_GPL(ata_bmdma_error_handler);
EXPORT_SYMBOL_GPL(ata_bmdma_post_internal_cmd);
diff -Nrup 08_tfload_cleanup/drivers/ata/libata-eh.c
09_integrate_irq_on_off/drivers/ata/libata-eh.c
--- 08_tfload_cleanup/drivers/ata/libata-eh.c 2007-07-04 11:26:30.0
+0800
+++ 09_integrate_irq_on_off/drivers/ata/libata-eh.c 2007-07-04
13:36:27.0 +0800
@@ -617,8 +617,7 @@ static void __ata_port_freeze(struct ata
{
WARN_ON(!ap->ops->error_handler);
- if (ap->ops->freeze)
- ap->ops->freeze(ap);
+ ap->ops->irq_off(ap);
ap->pflags |= ATA_PFLAG_FROZEN;
@@ -690,8 +689,7 @@ void ata_eh_thaw_port(struct ata_port *a
ap->pflags &= ~ATA_PFLAG_FROZEN;
- if (ap->ops->thaw)
- ap->ops->thaw(ap);
+ ap->ops->irq_on(ap);
spin_unlock_irqrestore(ap->lock, flags);
diff -Nrup 08_tfload_cleanup/drivers/ata/libata-sff.c
09_integrate_irq_on_off/drivers/ata/libata-sff.c
--- 08_tfload_cleanup/drivers/ata/libata-sff.c 2007-07-04 13:20:30.0
+0800
+++ 09_integrate_irq_on_off/drivers/ata/libata-sff.c2007-07-04
13:57:21.0 +0800
@@ -48,23 +48,20 @@
* LOCKING:
* Inherited from caller.
*/
-u8 ata_irq_on(struct ata_port *ap)
+void ata_irq_on(struct ata_port *ap)
{
struct ata_ioports *ioaddr = &ap->ioaddr;
- u8 tmp;
ap->ctl &= ~ATA_NIEN;
ap->last_ctl = ap->ctl;
iowrite8(ap->ctl, ioaddr->ctl_addr);
- tmp = ata_wait_idle(ap);
+ ata_wait_idle(ap);
ap->ops->irq_clear(ap);
-
- return tmp;
}
-u8 ata_dummy_irq_on (struct ata_port *ap) { return 0; }
+void ata_dummy_irq_on (struct ata_port *ap){ }
/**
* ata_irq_off - Disable interrupts on a port.
@@ -76,10 +73,9 @@ u8 ata_dumm
Re: Libata PATA status
On Tue, 3 Jul 2007 23:04:26 -0400, Kyle Moffett wrote: > Has anyone started a rewrite of the PPC/PowerMac IDE > driver? The current one is in "drivers/ide/ppc/pmac.c", and supports > these chipsets: >OHare ATA >Heathrow ATA >KeyLargo ATA-3 >KeyLargo ATA-4 >UniNorth ATA-6 (IE: Kauai) >K2 ATA-6 >Shasta ATA-6 > > I'd be willing to test drivers for the UniNorth ATA-6 and K2 ATA-6, > as well as possibly the KeyLargo ATA-3/4, depending on what the old > MDD G4 in my closet has. Sadly my libata-foo is insufficient for me > to do anything useful (other than thoroughly testing my backup- > restoration procedure, maybe :-D). And I'd be happy to test a libata pmac driver on Heathrow (Beige G3) and KeyLargo ATA-3/UniNorth ATA-6 (eMac G4). - To unsubscribe from this list: send the line "unsubscribe linux-ide" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: sata_sil, writing bug with multiple cards?
Alan Cox writes: Not suprised to be honest. We have a large number of reports that are all of the following form "Nvidia chipset, Silicon Image SATA, corruption" and several reports that BIOS updates fixed it. Unfortunately we don't know what the BIOS updates do (or indeed if what they do is board specific) or how to work around it otherwise. Alan Well, that's the thing, and one of the details that may have gotten a little lost in the long reply chain. The Silicon Image SATA ports on the motherboard work fine. Silicon Image SATA ports on addon cards are showing corrutpion. I have also flashed the Motherboard BIOS to the newest available version, which got the onboard ports, and the addon card got flashed as well. :( A very frustrating problem. - To unsubscribe from this list: send the line "unsubscribe linux-ide" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH libata-dev#upstream] libata: simplify PCI legacy SFF host handling
> Signed-off-by: Tejun Heo <[EMAIL PROTECTED]> > Cc: Alan Cox <[EMAIL PROTECTED]> > --- > Gee, I like it. The BAR fixup thing was a really good idea. :-) Told you it would 8) Looks good to me Acked-by: Alan Cox <[EMAIL PROTECTED]> [Jeff - this replaces the minimal tweak I sent out to use the PCI resources set by the pci layer and does the lot properly so drop the little patch of mine] - To unsubscribe from this list: send the line "unsubscribe linux-ide" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] libata_acpi: A different strategy for using ACPI information
> Looks fairly reasonable to me. However, I suspect any use of _GTM is > somewhat dangerous (at least after the resume) unless we use the _STM > and _GTF methods in the proper sequence when resuming. (Is that in the > -mm tree now?) Yes - and we only use it in these drivers to check for cable evidence not for anything more serious. > speed we give it is valid, since there is no sane way for the function > to indicate failure. (Thus the problem with the "cram in all possible > values to see what it supports" strategy for determining mode limits..) The spec I have says it'll hand back the mode it actually uses which is effectively a solution for 'failure' - To unsubscribe from this list: send the line "unsubscribe linux-ide" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Some NCQ numbers...
Tejun Heo wrote: > Hello, > > Michael Tokarev wrote: >> Well. It looks like the results does not depend on the >> elevator. Originally I tried with deadline, and just >> re-ran the test with noop (hence the long delay with >> the answer) - changing linux elevator changes almost >> nothing in the results - modulo some random "fluctuations". > > I see. Thanks for testing. Here are actual results - the tests were still running when I replied yesterday. Again, this is Seagate ST3250620AS "desktop" drive, 7200RPM, 16Mb cache, 250Gb capacity. The tests were performed with queue depth = 64 (on mptsas), drive write cache is turned off. noop scheduler: BlkSz Trd linRd rndRd linWr rndWr rndR/W 4k 1 12.8 0.3 0.4 0.3 0.1/ 0.1 4 0.3 0.3 0.1/ 0.1 32 0.3 0.3 0.1/ 0.1 8k 1 24.6 0.6 0.9 0.6 0.3/ 0.3 4 0.6 0.6 0.3/ 0.3 32 0.6 0.6 0.3/ 0.3 16k 1 41.3 1.2 1.8 1.1 0.6/ 0.6 4 1.2 1.1 0.6/ 0.6 32 1.2 1.1 0.6/ 0.6 32k 1 58.4 2.2 3.5 2.1 1.1/ 1.1 4 2.3 2.1 1.1/ 1.1 32 2.3 2.1 1.1/ 1.1 128k 1 80.4 8.1 12.5 7.2 3.8/ 3.8 4 8.1 7.2 3.8/ 3.8 32 8.1 7.2 3.8/ 3.8 1024k 1 80.5 33.9 33.8 24.5 14.3/14.3 434.124.6 14.3/14.2 3234.224.6 14.4/14.2 deadline scheduler: BlkSz Trd linRd rndRd linWr rndWr rndR/W 4k 1 12.8 0.3 0.4 0.3 0.1/ 0.1 4 0.3 0.3 0.1/ 0.1 32 0.3 0.3 0.1/ 0.1 8k 1 24.5 0.6 0.9 0.6 0.3/ 0.3 4 0.6 0.6 0.3/ 0.3 32 0.6 0.6 0.3/ 0.3 16k 1 41.3 1.2 1.8 1.1 0.6/ 0.6 4 1.2 1.1 0.6/ 0.6 32 1.2 1.1 0.6/ 0.6 32k 1 57.7 2.3 3.4 2.1 1.1/ 1.1 4 2.3 2.1 1.1/ 1.1 32 2.3 2.1 1.1/ 1.1 128k 1 79.4 8.1 12.5 7.2 3.8/ 3.8 4 8.1 7.3 3.8/ 3.8 32 8.2 7.3 3.9/ 3.8 1024k 1 79.4 33.7 33.8 24.5 14.2/14.2 433.924.6 14.3/14.2 3233.424.4 17.0/10.5 [] >> By the way, Seagate announced Barracuda ES 2 series >> (in range 500..1200Gb if memory serves) - maybe with >> those, NCQ will work better? > > No one would know without testing. Sure thing. I guess I'll set up a web page with all the results so far, in a hope someday it will be more complete (we don't have many different drives to test, but others do). By the way. Both SATA drives we have are single-platter ones (with 500Gb models they've 2 platters, and 750Gb ones are with 3 platters), while all SCSI drives I tested have more than one platters. Maybe this is yet another reason for NCQ failing. And another note. I heard somewhere that Seagate for one prohibits publishing of tests like this, however I haven't signed any NDAs and somesuch when purchased their drives in a nearest computer store... ;) >> Or maybe it's libata which does not implement NCQ >> "properly"? (As I shown before, with almost all >> ol'good SCSI drives TCQ helps alot - up to 2x the >> difference and more - with multiple I/O threads) > > Well, what the driver does is minimal. It just passes through all the > commands to the harddrive. After all, NCQ/TCQ gives the harddrive more > responsibility regarding request scheduling. Oh well, I see :( /mjt - To unsubscribe from this list: send the line "unsubscribe linux-ide" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Some NCQ numbers...
On Wed, 4 Jul 2007, Michael Tokarev wrote: Tejun Heo wrote: Hello, Michael Tokarev wrote: Well. It looks like the results does not depend on the elevator. Originally I tried with deadline, and just re-ran the test with noop (hence the long delay with the answer) - changing linux elevator changes almost nothing in the results - modulo some random "fluctuations". I see. Thanks for testing. Here are actual results - the tests were still running when I replied yesterday. Again, this is Seagate ST3250620AS "desktop" drive, 7200RPM, 16Mb cache, 250Gb capacity. The tests were performed with queue depth = 64 (on mptsas), drive write cache is turned off. I found AS scheduler to be the premium and best for single-user performance. You want speed? Use AS. http://home.comcast.net/~jpiszcz/sched/cfq_vs_as_vs_deadline_vs_noop.html - To unsubscribe from this list: send the line "unsubscribe linux-ide" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Some NCQ numbers...
On Wed, 4 Jul 2007, Justin Piszcz wrote: On Wed, 4 Jul 2007, Michael Tokarev wrote: > Tejun Heo wrote: >> Hello, >> >> Michael Tokarev wrote: >>> Well. It looks like the results does not depend on the >>> elevator. Originally I tried with deadline, and just >>> re-ran the test with noop (hence the long delay with >>> the answer) - changing linux elevator changes almost >>> nothing in the results - modulo some random "fluctuations". >> >> I see. Thanks for testing. > > Here are actual results - the tests were still running when > I replied yesterday. > > Again, this is Seagate ST3250620AS "desktop" drive, 7200RPM, > 16Mb cache, 250Gb capacity. The tests were performed with > queue depth = 64 (on mptsas), drive write cache is turned > off. I found AS scheduler to be the premium and best for single-user performance. You want speed? Use AS. http://home.comcast.net/~jpiszcz/sched/cfq_vs_as_vs_deadline_vs_noop.html Does not include noop-- tested the main three though, renamed :) http://home.comcast.net/~jpiszcz/sched/cfq_vs_as_vs_deadline.html And for the archives: p34-cfq,15696M,77114.3,99,311683,55.,184947,38.6667,79842.7,99,524065,41.,634.033,0.33,16:10:16/64,1043.33,8.3,4419.33,11.6667,2942,17.,1178,10.,4192.67,12.,2619.33,19 p34-as,15696M,76202.3,99,443103,85,189716,34.6667,79552,99,507271,39.6667,607.067,0,16:10:16/64,1153,10,13434,36,2769.67,16.,1201.67,10.6667,3951.33,12,2665.67,19 p34-deadline,15696M,76933.3,98.6667,386852,72,183016,29.6667,79530.7,99,512082,39.6667,678.567,0,16:10:16/64,1230.33,10.,12349,32.,2945,17.,1258,11,8183,22.,2867,20. Justin. - To unsubscribe from this list: send the line "unsubscribe linux-ide" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: ata1: soft resetting port
On Tue, 2007-07-03 at 15:40 +0900, Tejun Heo wrote: > Soeren Sonnenburg wrote: > > Dear List, > > > > since the switch to > > > > CONFIG_ATA=y > > CONFIG_ATA_ACPI=y > > CONFIG_ATA_PIIX=y, > > > > the ATA_PIIX driver manages both, internal sata disk aswell as cd/dvd > > rom. However I am being flooded with the error messages below (well they > > appear from time to time, dominating dmesg). > > > > This happens on kernel 2.6.22-rc5, I am copying relevant parts from dmesg: > > Does 2.6.22-rc7 fare better? Yes indeed. The only thing I've seen in the last two days was the following on resume: pci_express :00:1c.2:pcie03: resuming sr 0:0:0:0: resuming sd 2:0:1:0: resuming sd 2:0:1:0: [sda] Starting disk ata1.00: configured for UDMA/33 ata3.01: revalidation failed (errno=-2) ata3: failed to recover some devices, retrying in 5 secs ata3.01: configured for UDMA/133 Soeren -- Sometimes, there's a moment as you're waking, when you become aware of the real world around you, but you're still dreaming. - To unsubscribe from this list: send the line "unsubscribe linux-ide" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Libata PATA status
Alan Cox <[EMAIL PROTECTED]> writes: > > Post SRST What is SRST? My personal wish list feature would be a little forwarder driver to forward /dev/hd* to /dev/sd* for this; then old IDE could be disabled without risking breaking old root file systems. -Andi - To unsubscribe from this list: send the line "unsubscribe linux-ide" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Libata PATA status
On 04 Jul 2007 15:00:26 +0200 Andi Kleen <[EMAIL PROTECTED]> wrote: > Alan Cox <[EMAIL PROTECTED]> writes: > > > > Post SRST > What is SRST? > > My personal wish list feature would be a little forwarder driver > to forward /dev/hd* to /dev/sd* for this; then old IDE could be > disabled without risking breaking old root file systems. That would be udevd for new systems or "ln -s" for old ones ? I don't see a way to build that "simple" forwarder because the device allocation is now dynamic rather than tied to specific device on specific port - a concept with really no meaning any more. Alan - To unsubscribe from this list: send the line "unsubscribe linux-ide" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Libata PATA status
On 04 Jul 2007 15:00:26 +0200 Andi Kleen <[EMAIL PROTECTED]> wrote: > Alan Cox <[EMAIL PROTECTED]> writes: > > > > Post SRST > What is SRST? Sorry missed the first question. SRST is the reset signal used when you want to set up (or beat back into sanity) an IDE bus. It causes a specific set of actions that put the drives back into a partly known state and hopefully lets you sort problems out - much like a SCS bus reset. - To unsubscribe from this list: send the line "unsubscribe linux-ide" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Libata PATA status
On Wed, Jul 04, 2007 at 01:17:46PM +0100, Alan Cox wrote: > On 04 Jul 2007 15:00:26 +0200 > Andi Kleen <[EMAIL PROTECTED]> wrote: > > > Alan Cox <[EMAIL PROTECTED]> writes: > > > > > > Post SRST > > What is SRST? > > > > My personal wish list feature would be a little forwarder driver > > to forward /dev/hd* to /dev/sd* for this; then old IDE could be > > disabled without risking breaking old root file systems. > > That would be udevd for new systems or "ln -s" for old ones ? Then old kernels couldn't be booted anymore. > > I don't see a way to build that "simple" forwarder because the device > allocation is now dynamic rather than tied to specific device on specific > port - a concept with really no meaning any more. Sure for SATA. But surely for PATA it would be possible to fake the mapping of the old driver? Doing it simple minded (e.g. only for the builtin devices) would be probably sufficient. -Andi - To unsubscribe from this list: send the line "unsubscribe linux-ide" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Libata PATA status
> > > disabled without risking breaking old root file systems. > > > > That would be udevd for new systems or "ln -s" for old ones ? > > Then old kernels couldn't be booted anymore. Why not. I boot back and forth randomly between old and new IDE kernels without problems. The root fs loaded is set in kernel or grub (or on most distros nowdays by label scanning from initrd) so just works. Then mount label or uuid based mounting does the rest. > Sure for SATA. But surely for PATA it would be possible to fake > the mapping of the old driver? Doing it simple minded (e.g. only > for the builtin devices) would be probably sufficient. You could probably reliably map "hda/b/c/d" initially with some kind of forwarder providing nobody hot plugged them. Just not sure I see the point of doing it kernel side. Alan - To unsubscribe from this list: send the line "unsubscribe linux-ide" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Libata PATA status
> You could probably reliably map "hda/b/c/d" initially with some kind of > forwarder providing nobody hot plugged them. Just not sure I see the PATA hotplug? SATA systems typically already use /dev/sda*, it just applies to PATA. > point of doing it kernel side. The point would be that old user land just works without any changes. I know that is a virtue that has gone out of fashion recently with udev and sysfs, but older distributions that weren't that sysfs-layout-of-the-week dependent used to be fairly kernel version independent. I always found that very useful. The hda->sda move would be the only "radical" change that prevents booting for a long time (the last one before that was the 2.5 modutils transition) -Andi - To unsubscribe from this list: send the line "unsubscribe linux-ide" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [git patches] libata fixes
On Tue, 2007-07-03 at 18:21 +0100, Alan Cox wrote: > Chuck posted a link to an attachment in bugzilla not to anything from > version control. And the bugzilla bug clearly indicates who posted the > attachment. Probably Chuck should have posted the bug number as well. Perhaps it would have helped if the attachment itself contained a short comment and some information about its own provenance. It can be painful trawling through bugzilla to find the latest version of a patch -- a direct link to the attachment often is much nicer. And the person who attaches a bug to bugzilla isn't necessarily the author of it anyway. -- dwmw2 - To unsubscribe from this list: send the line "unsubscribe linux-ide" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Libata PATA status
On Wed, 4 Jul 2007 15:29:30 +0200 Andi Kleen <[EMAIL PROTECTED]> wrote: > > You could probably reliably map "hda/b/c/d" initially with some kind of > > forwarder providing nobody hot plugged them. Just not sure I see the > > PATA hotplug? > > SATA systems typically already use /dev/sda*, it just applies to PATA. We support PATA warm plugging sort of already and it'll go further in time. Mostly this is relevant to laptops - To unsubscribe from this list: send the line "unsubscribe linux-ide" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 9/15] ide: add PIO masks
Hello.
Alan Cox wrote:
.bootable = ON_BOARD, \
.enablebits = { {0x40, 1, 1}, {0x40, 0x10, 0x10} }, \
+ .pio_mask = ATA_PIO5, \
}
Just noticed that this driver does nothing in its tuneproc() method. So,
this mask is unrealistic. The method needs to be dropped for now along with
config-jmicron_chipset_for_pio()
It doesn't need to do anything.
Not true. It should call ide_config_drive_speed() at least, else PIO
autotuning won't actually work.
MBR, Sergei
-
To unsubscribe from this list: send the line "unsubscribe linux-ide" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 9/15] ide: add PIO masks
> > It doesn't need to do anything. > > Not true. It should call ide_config_drive_speed() at least, else PIO > autotuning won't actually work. Indeed - I forgot that old-ide doesn't do this itself but leaves it up to the driver to forget 8) - To unsubscribe from this list: send the line "unsubscribe linux-ide" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] pata_hpt3x3: Major reworking and testing
Hello. Bartlomiej Zolnierkiewicz wrote: Does anybody have DOS driver for HPT343? Google doesn't have it... I have the drivers for HPT34[35] -- tried dissassembling them some years ago... /me wants I tried sending binaries as is but GMail bounced them off. :-/ Will try to tar and feather them... ;-) Bart MBR, Sergei - To unsubscribe from this list: send the line "unsubscribe linux-ide" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Some NCQ numbers...
On Wed, 2007-07-04 at 10:19 +0900, Tejun Heo wrote: > Michael Tokarev wrote: > > Well. It looks like the results does not depend on the > > elevator. Originally I tried with deadline, and just > > re-ran the test with noop (hence the long delay with > > the answer) - changing linux elevator changes almost > > nothing in the results - modulo some random "fluctuations". > > I see. Thanks for testing. > > > In any case, NCQ - at least in this drive - just does > > not work. Linux with its I/O elevator may help to > > speed things up a bit, but the disk does nothing in > > this area. NCQ doesn't slow things down either - it > > just does not work. > > > > The same's for ST3250620NS "enterprise" drives. > > > > By the way, Seagate announced Barracuda ES 2 series > > (in range 500..1200Gb if memory serves) - maybe with > > those, NCQ will work better? > > No one would know without testing. > > > Or maybe it's libata which does not implement NCQ > > "properly"? (As I shown before, with almost all > > ol'good SCSI drives TCQ helps alot - up to 2x the > > difference and more - with multiple I/O threads) > > Well, what the driver does is minimal. It just passes through all the > commands to the harddrive. After all, NCQ/TCQ gives the harddrive more > responsibility regarding request scheduling. Actually, in many ways the result support a theory of SCSI TCQ Jens used when designing the block layer. The original TCQ theory held that the drive could make much better head scheduling decisions than the Operating System, so you just used TCQ to pass all the outstanding I/O unfiltered down to the drive to let it schedule. However, the I/O results always seemed to indicate that the effect of TCQ was negligible at around 4 outstanding commands, leading to the second theory that all TCQ was good for was saturating the transport, and making scheduling decisions was, indeed, better left to the OS (hence all our I/O schedulers). The key difference between NCQ and TCQ is that NCQ allows a non interlock setup and completion, but there can't be overlapping (or interrupted) data transfers. TCQ and Disconnect (for SPI although there are equivalents for most other transports) allow any style of overlap you can construct, so NCQ was really designed more to allow the drive to make the head scheduling decisions. Where SCSI TCQ seems to win is that most devices pull the incoming TCQ commands into a (usually quite large) pre-execute cache, which gives them streaming command execution (usually they're executing command n-2 or 3 while accepting the data for command n), so they're using the cache actually to smooth out internal latencies. One final question: have you tried SAS devices for comparison? The figures that give TCQ a 2x performance boost were with SPI and FC ... I'm not aware that anyone has actually done a SAS test. James - To unsubscribe from this list: send the line "unsubscribe linux-ide" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [patch 2.6.22-rc6] ATA: add a PCI ID for Intel Santa Rosa PATA controller
On 02.07.2007 16:36, Chr wrote:
> On Monday, 2. July 2007, Thorsten Leemhuis wrote:
>>> but Alan Cox wrote:
>>> http://www.mail-archive.com/linux-ide%40vger.kernel.org/msg07417.html
Its ich_pata_133 - all the newer chips are.
>> Intel afaik never supported Ultra ATA 133 officially in any of the
>> mainstream desktop or mobile chipsets.
> You're probably right! But, what about Intel's ICH5 and ICH7/7-R (i945, i975)?
>
> see ata_piix.c: line 193ff
> { 0x8086, 0x24DB, PCI_ANY_ID, PCI_ANY_ID, 0, 0, ich_pata_133 },
> [...]
> { 0x8086, 0x27DF, PCI_ANY_ID, PCI_ANY_ID, 0, 0, ich_pata_133 },
Maybe Alan or someone from Intel can answer that and thus tell us how to
move forward; it would be really nice to get the patch that started this
thread (it got posted by Chuck again today) could go into 2.6.22, but I
assume the time runs away...
> On the other hand, we can leave it, because of a "off-by-one error" in
> ata_piix.c,
> do_pata_set_dmamode, line ~770:
> [...]
/me gets confused by that stuff and leaves the answer to that part to
more knowledged people...
CU
thl
--
Thorsten Leemhuis
c't- Magazin für Computertechnik webhttp://www.heise.de/ct/
Heise Zeitschriften Verlag GmbH&Co.KG phone +49 (0)511 5352 666
Helstorfer Str. 7 icq140593172
D-30625 Hannover, Germany jabber [EMAIL PROTECTED]
/* Heise Zeitschriften Verlag GmbH & Co. KG, Registergericht:
Amtsgericht Hannover HRA 26709; Persönlich haftende Gesellschafterin:
Heise Zeitschriften Verlag Geschäftsführung GmbH, Registergericht:
Amtsgericht Hannover, HRB 60405 Geschäftsführer: Ansgar Heise,
Steven P. Steinkraus, Dr. Alfons Schräder */
-
To unsubscribe from this list: send the line "unsubscribe linux-ide" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 3/6] siimage: PIO mode setup fixes
Hello.
Bartlomiej Zolnierkiewicz wrote:
A lot to argue about here...
* Add sil_tuneproc() wrapper for siimage_tuneproc() which also sets
PIO mode on the device.
Planning on the global prefix change? :-)
Yep.
Well, it didn't work out with 'ata_'... ;-)
* Add code limiting maximum PIO mode according to the pair device capabilities
to sil_tuneproc().
Ugh... that part is terrible. :-/
Actually, we only need to limit the taskfile, not the data transfers --
unlike it was done before.
Fixed.
Let's see... :-)
Note that PIO setup keeps being somewhat borken IODRY-wise even with this
patch as sil_tune_pio() only controls taskfile IORDY sampling -- the Right
Thing could only be done via speedproc() method...
After rehashing the datasheet I see the source of the issue:
IORDY is controlled in two registers and moreover it is always enabled
if MDMA or UDMA transfer modes are selected.
Yeah. I drafted some patch for pata_sil.c but Alan fixed it first and in a
more simple way -- libata calls PIO/DMA setting methods in the strict
sequence, and that allowed to bypass some checks...
Index: b/drivers/ide/pci/siimage.c
===
--- a/drivers/ide/pci/siimage.c
+++ b/drivers/ide/pci/siimage.c
[...]
+ }
+
/* cheat for now and use the docs */
- switch (mode_wanted) {
+ switch (pio) {
case 4:
speedp = 0x10c1;
speedt = 0x10c1;
What I envisioned was putting speedt into drive->drive_data, calculating
the maximum value for 2 drives and using it to actually program the taskfile
timing. Either that or put PIO mode there, and add the second switch to
calculate the taskfile timings after getting the minimum PIO mode for 2 drives
(but that's not as neat).
I did something similar to the second solution (should be sufficient for now)
but improvenments are welcomed.
Thanks, looks good.
hwif->OUTW(hwif->INW(tfaddr-2)|0x200, tfaddr-2);
Erm, the same comments about taskfile IORDY as before: it should be
selected if the drive supports it. In fact, if either of 2 drives do.
else
hwif->OUTW(hwif->INW(tfaddr-2)&~0x200, tfaddr-2);
This is wrong logic: thus we may turn off IORDY although the 2nd drive may
support it.
Indeed, but since I don't want to be selfish and keep all bugfixes to myself
I'm giving other people opportunity to fix it. :-)
ditto for ->speedproc vs IORDY problems
Wow, drivers/ide/ is a land of opportunity. B-)
[...]
@@ -335,7 +299,7 @@ static int siimage_tune_chipset (ide_dri
case XFER_PIO_2:
case XFER_PIO_1:
case XFER_PIO_0:
- siimage_tuneproc(drive, (speed - XFER_PIO_0));
+ sil_tune_pio(drive, speed - XFER_PIO_0);
mode |= ((unit) ? 0x10 : 0x01);
The last line enables IORDY sampling for data transfers.
break;
case XFER_MW_DMA_2:
@@ -343,7 +307,7 @@ static int siimage_tune_chipset (ide_dri
case XFER_MW_DMA_0:
multi = dma[speed - XFER_MW_DMA_0];
mode |= ((unit) ? 0x20 : 0x02);
... and this line also enables IORDY. And the one in UltraDMA case group too.
- config_siimage_chipset_for_pio(drive, 0);
+ sil_tune_pio(drive, 4); /* FIXME */
Why we still need this nonsense here...
I was _really_ hoping that /* FIXME */ would make this clear. ;-)
You were under/over-etimatating me. ;-)
@@ -356,7 +320,7 @@ static int siimage_tune_chipset (ide_dri
ultra |= ((scsc) ? (ultra6[speed - XFER_UDMA_0]) :
(ultra5[speed - XFER_UDMA_0]));
mode |= ((unit) ? 0x30 : 0x03);
- config_siimage_chipset_for_pio(drive, 0);
+ sil_tune_pio(drive, 4); /* FIXME */
... and here? If we so desperately want to setup PIO data/taskfile
timings, it's better to do via setting the 'autotune' field unconditionally.
I had a follow-up patch doing exactly that (done later than this patch).
I integrated it into current patch since there was a need for respin...
Thanks, looks better now. :-)
take 2 follows:
[PATCH] siimage: PIO mode setup fixes (take 2)
* Add sil_tuneproc() wrapper for siimage_tuneproc() which also sets
PIO mode on the device.
* Add missing ide_get_best_pio_mode() call to sil_tuneproc() so
"pio" == 255 (autotune) is handled correctly (previously PIO0 was used)
and "pio" values > 4 && < 255 are filtered to PIO4 (instead of PIO0).
* Add code limiting maximum PIO mode according to the pair device capabilities
to sil_tuneproc().
* Convert users of config_siimage_chipset_for_pio() to use sil_tune_pio() and
Re: Some NCQ numbers...
Dan Aloni wrote: > On Thu, Jun 28, 2007 at 02:51:58PM +0400, Michael Tokarev wrote: >> [..] >> Test machine was using MPTSAS driver for the following card: >> SCSI storage controller: LSI Logic / Symbios Logic SAS1064E PCI-Express >> Fusion-MPT SAS (rev 02) >> >> Pretty similar results were obtained on an AHCI controller: >> SATA controller: Intel Corporation 82801GR/GH (ICH7 Family) Serial ATA >> Storage Controller AHCI (rev 01) >> on another machines. > > Are you sure that NCQ was enabled between the controller and drive? > Did you verify this? I know about some versions that disable NCQ > support internally in their firmware (something to do with bugs in > error handling). The next obvious question is: how to check/verify this? /mjt - To unsubscribe from this list: send the line "unsubscribe linux-ide" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 6/15] ide: ide_find_best_pio_mode() fixes
Hello. Bartlomiej Zolnierkiewicz wrote: [PATCH] ide: ide_find_best_pio_mode() fixes (take 2) * Check IORDY bit for PIO modes > 2. * Some devices claim maximum PIO mode > 2 in id->tPIO, they were punished too severly for this by being limited to PIO_SLOW. Limit them to PIO2 instead. v2: * Fix PIO number being returned incorrectly instead of PIO mode (Noticed by Sergei). Signed-off-by: Bartlomiej Zolnierkiewicz <[EMAIL PROTECTED]> Acked-by: Sergei Shtylyov <[EMAIL PROTECTED]> MBR, Sergei - To unsubscribe from this list: send the line "unsubscribe linux-ide" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 5/6] ide: add ata_dev_has_iordy() helper
Bartlomiej Zolnierkiewicz wrote: I was thinking of checking if the drive really supports IORDY before issuing a command to set PIO mode (and just skipping the command if there's no IORDY -- well, maybe adding an extra check that the passed mode is acceptable to the drive, i.e. <= its default one). Should be quite simple to do. Sounds fine. I'll look into doing this some time... :-) Cool. Unfortunately, got assigned to an urgent bug... been trying to pass it along but not much hope on this. :-/ Patches adding/removing items are welcomed. Patches fixing actual issues are welcomed even more. Sigh, I'm trying to get some time (more like time slices :-) off to deal with my own issues... By by "my own issues" I don't mean patches -- patches don't help me, it's rather injections and pills... +:-) Heh, sorry I didn't know about that. I hope that it is nothing serious and wish you quick recovery... From diabetes? Not bloody likely. :-D So you could hack some more... :-) That's why I now have to fix at least some consequencies (also of a hard hacking :-) MBR, Sergei - To unsubscribe from this list: send the line "unsubscribe linux-ide" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: BIOS does not recognize 500GB-disk
Justin Piszcz wrote: > > Turn off NCQ on the drive, limit to 1.5GBps operation, try again, I have > the same issue with a new RAPTOR (NCQ) and old motherboard. Yup, that was the problem. The VIA chipset did not support SATA-II. I had to set a jumper on the disk to slow it down to SATA-I. Unfortunately, they didn't tell that jumper setting on the disk's sticker, and the disk didn't come with a jumper, so it was not obvious. Thanks and regards Hadmut - To unsubscribe from this list: send the line "unsubscribe linux-ide" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Some NCQ numbers...
On Wed, Jul 04, 2007 at 08:17:35PM +0400, Michael Tokarev wrote: > Dan Aloni wrote: > > On Thu, Jun 28, 2007 at 02:51:58PM +0400, Michael Tokarev wrote: > >> [..] > >> Test machine was using MPTSAS driver for the following card: > >> SCSI storage controller: LSI Logic / Symbios Logic SAS1064E PCI-Express > >> Fusion-MPT SAS (rev 02) > >> > >> Pretty similar results were obtained on an AHCI controller: > >> SATA controller: Intel Corporation 82801GR/GH (ICH7 Family) Serial ATA > >> Storage Controller AHCI (rev 01) > >> on another machines. > > > > Are you sure that NCQ was enabled between the controller and drive? > > Did you verify this? I know about some versions that disable NCQ > > support internally in their firmware (something to do with bugs in > > error handling). > > The next obvious question is: how to check/verify this? On the lowest level, it's possible using a protocol analyzer. If you don't have one, you need to be familiar with the controller's driver or its firmware. If the driver is based on libata, I think it's possible to get this information easier. Otherwise, such as in the case of mptsas, it can be completely hidden by the firmware. -- Dan Aloni XIV LTD, http://www.xivstorage.com da-x (at) monatomic.org, dan (at) xiv.co.il - To unsubscribe from this list: send the line "unsubscribe linux-ide" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] ide: add ide_set{_max}_pio() (take 2)
Bartlomiej Zolnierkiewicz wrote:
reporting PIO mode selected from ->tuneproc implementations.
* Rename ->tuneproc hook to ->set_pio_mode
Well, tuneproc() went with speedproc() rather well. :-)
->set_pio_mode goes better with ->set_dma_mode ;-)
Ah, good to know where we're moving... :-)
and make 'pio' argument const.
Isn't it too strict, const value argument?
Not really, this is to prevent potential mistakes and catch them early.
Please note that this patch pushes all logic dealing with finding the best
PIO mode and also limiting PIO mode passed by the user from ->tuneproc
to the core code. Another logical step is to move ide_rate_filter() out
of ->speedproc to the core code (fixing ide_rate_filter() while at it)
and this step is alsmost done (I will post patch soon).
Too many patches recently. :-)
After ide_rate_filter() change is done we can start syncing code setting
PIO modes in ->set_pio_mode and ->speedproc (there are some suspicious
disrepancies in some drivers besides the usual bug of not setting transfer
mode on the device in ->tuneproc). Finally we can switch the core code to
just use ->set_pio_mode for PIO modes and turn ->speedproc into new shiny
->set_dma_mode method.
* Remove stale comment from ide_config_drive_speed().
Hm, the next logical step would be to remove a call to
ide_config_drive_speed() from the set_pio_mode() handler, wouldn't it?..
Yes.
Again, good to know. Too bad that these cleanups haven't happened until
now -- when libata PATA support seems already ripe enough. :-)
Index: b/drivers/ide/pci/it8213.c
===
--- a/drivers/ide/pci/it8213.c
+++ b/drivers/ide/pci/it8213.c
@@ -4,6 +4,8 @@
* Copyright (C) 2006 Jack Lee
* Copyright (C) 2006 Alan Cox
* Copyright (C) 2007 Bartlomiej Zolnierkiewicz
+ *
+ * TODO: make ->set_pio_mode method set transfer mode on the device
IMHO, this actually better be done outside of this method (if possible).
In the long-term, yes.
Sigh, that would undo many of my prior fixes...
It shouldn't if would be handled exactly as is currently done piix.c.
Well, that would turn piix_tune_drive() into completely useless wrapper to
piix_tune_pio() -- exactly what I mean.
it8213_set_pio_mode() will become a wrapper for it8213_tune_pio().
Hm, there are currently no it8213_tune_pio() -- and would be no need for
it if we start calling ide_config_drive_speed() outside the set_pio_mode()
method...
@@ -193,7 +194,9 @@ static int it8213_tune_chipset (ide_driv
if (reg55 & w_flag)
pci_write_config_byte(dev, 0x55, (u8) reg55 & ~w_flag);
}
- it8213_tuneproc(drive, it8213_dma_2_pio(speed));
+
+ it8213_set_pio_mode(drive, it8213_dma_2_pio(speed));
Bleh... Still haven't "divorced" PIO/DMA timings -- need to get this done
finally. :-/
Well, if you would spend some less time nitpicking about CodingStyle... ;-)
That's negligible compared to what I'd have to spend on piix.c (and even
on finding the real issues with these patches :-).
@@ -307,10 +306,11 @@ static void pdc202xx_reset (ide_drive_t
{
ide_hwif_t *hwif= HWIF(drive);
ide_hwif_t *mate= hwif->mate;
-
+
pdc202xx_reset_host(hwif);
pdc202xx_reset_host(mate);
Bleh... this double reset horror still needs to be sorted out as well. I'm
not at all sure it's useful -- its assumed purpose is to be able to set MWDMA
modes after UDMA (can't do this w/o reset).
I completely disliked this whole approach and just forbade the downgrade
from UDMA to MWDMA in the internal tree... never got to submitting this though.
- pdc202xx_tune_drive(drive, 255);
+
+ ide_set_max_pio(drive);
I wonder why the code doesn't retune all 4 drives? :-/
Because it is buggy/broken - all drives should be re-tuned but there
is no needed locking in the IDE core to achieve this currently.
Well, you have the spec... :-)
take 3
[PATCH] ide: add ide_set{_max}_pio() (take 3)
* Add IDE_HFLAG_ABUSE_{PREFETCH,FAST_DEVSEL,DMA_MODES} flags
and set them in ht6560, cmd640, cmd64x and sc1200 host drivers.
* Add set_pio_mode_abuse() for checking if host driver has a non-standard
->tuneproc() implementation and use it in do_special().
* Add ide_set_pio() for setting PIO mode (it uses hwif->pio_mask to find
the maximum PIO mode supported by the host), also add ide_set_max_pio()
wrapper for ide_set_pio() to use for auto-tuning. Convert users of
->tuneproc to use ide_set{_max}_pio() where possible. This leaves only
do_special(), set_using_pio(), ide_hwif_restore() and ide_set_pio() as
a direct users of ->tuneproc.
* Remove no longer needed ide_get_best_pio_mode() calls and printk-s
reporting PIO mode selected from ->tuneproc implementations.
* Rename ->tuneproc hook to ->set_pio_mode and make 'pio' argument const.
Re: ata1: soft resetting port
Soeren Sonnenburg wrote: > On Tue, 2007-07-03 at 15:40 +0900, Tejun Heo wrote: >> Soeren Sonnenburg wrote: >>> Dear List, >>> >>> since the switch to >>> >>> CONFIG_ATA=y >>> CONFIG_ATA_ACPI=y >>> CONFIG_ATA_PIIX=y, >>> >>> the ATA_PIIX driver manages both, internal sata disk aswell as cd/dvd >>> rom. However I am being flooded with the error messages below (well they >>> appear from time to time, dominating dmesg). >>> >>> This happens on kernel 2.6.22-rc5, I am copying relevant parts from dmesg: >> Does 2.6.22-rc7 fare better? > > Yes indeed. The only thing I've seen in the last two days was the > following on resume: > > pci_express :00:1c.2:pcie03: resuming > sr 0:0:0:0: resuming > sd 2:0:1:0: resuming > sd 2:0:1:0: [sda] Starting disk > ata1.00: configured for UDMA/33 > ata3.01: revalidation failed (errno=-2) > ata3: failed to recover some devices, retrying in 5 secs > ata3.01: configured for UDMA/133 Hmmm... That's NODEV_HINT being triggered after resume. Probably the device isn't ready to respond yet at that point. How reproducible is the problem? -- tejun - To unsubscribe from this list: send the line "unsubscribe linux-ide" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 3/6] siimage: PIO mode setup fixes
On Wednesday 04 July 2007, Sergei Shtylyov wrote:
> Hello.
>
> Bartlomiej Zolnierkiewicz wrote:
>
> >>A lot to argue about here...
>
> >>>* Add sil_tuneproc() wrapper for siimage_tuneproc() which also sets
> >>> PIO mode on the device.
>
> >>Planning on the global prefix change? :-)
>
> > Yep.
>
> Well, it didn't work out with 'ata_'... ;-)
Because of bad libata taking over our preciouss namespace... ;-)
Fortunately pata_sil680 driver uses "sil680_" prefix.
> >>>* Add code limiting maximum PIO mode according to the pair device
> >>>capabilities
> >>> to sil_tuneproc().
>
> >>Ugh... that part is terrible. :-/
> >>Actually, we only need to limit the taskfile, not the data transfers --
> >>unlike it was done before.
>
> > Fixed.
>
> Let's see... :-)
>
> >>Note that PIO setup keeps being somewhat borken IODRY-wise even with
> >> this
> >>patch as sil_tune_pio() only controls taskfile IORDY sampling -- the Right
> >>Thing could only be done via speedproc() method...
>
> > After rehashing the datasheet I see the source of the issue:
>
> > IORDY is controlled in two registers and moreover it is always enabled
> > if MDMA or UDMA transfer modes are selected.
>
> Yeah. I drafted some patch for pata_sil.c but Alan fixed it first and in
> a
> more simple way -- libata calls PIO/DMA setting methods in the strict
> sequence, and that allowed to bypass some checks...
I fail to see how this helps in this case, care to explain?
> > + /* cheat for now and use the docs */
> > + speedp = data_speed[pio];
> > + speedt = tf_speed[tf_pio];
> > +
> > if (hwif->mmio) {
> > hwif->OUTW(speedp, addr);
> > hwif->OUTW(speedt, tfaddr);
> > /* Now set up IORDY */
> > - if(mode_wanted == 3 || mode_wanted == 4)
> > + if (pio > 2)
>
> Not tf_pio? This IORDY bit is for taskfile accesses...
Would this be really OK (tf_pio takes minimum PIO mode)?
> > hwif->OUTW(hwif->INW(tfaddr-2)|0x200, tfaddr-2);
> > else
> > hwif->OUTW(hwif->INW(tfaddr-2)&~0x200, tfaddr-2);
> > @@ -245,42 +213,17 @@ static void siimage_tuneproc (ide_drive_
> > pci_read_config_word(hwif->pci_dev, tfaddr-2, &speedp);
> > speedp &= ~0x200;
> > /* Set IORDY for mode 3 or 4 */
> > - if(mode_wanted == 3 || mode_wanted == 4)
> > + if (pio > 2)
>
> Same question here.
> However... this logic should rely on both drives' PIO modes, so would be
> broken either way until this is fixed...
Yep.
Thanks,
Bart
-
To unsubscribe from this list: send the line "unsubscribe linux-ide" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 6/15] ide: ide_find_best_pio_mode() fixes
On Wednesday 04 July 2007, Sergei Shtylyov wrote: > Hello. > > Bartlomiej Zolnierkiewicz wrote: > > > [PATCH] ide: ide_find_best_pio_mode() fixes (take 2) > > > * Check IORDY bit for PIO modes > 2. > > > * Some devices claim maximum PIO mode > 2 in id->tPIO, they were punished > > too > > severly for this by being limited to PIO_SLOW. Limit them to PIO2 > > instead. > > > v2: > > * Fix PIO number being returned incorrectly instead of PIO mode > > (Noticed by Sergei). > > > Signed-off-by: Bartlomiej Zolnierkiewicz <[EMAIL PROTECTED]> > > Acked-by: Sergei Shtylyov <[EMAIL PROTECTED]> added - To unsubscribe from this list: send the line "unsubscribe linux-ide" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 9/15] ide: add PIO masks
On Wednesday 04 July 2007, Alan Cox wrote: > > > It doesn't need to do anything. > > > > Not true. It should call ide_config_drive_speed() at least, else PIO > > autotuning won't actually work. > > Indeed - I forgot that old-ide doesn't do this itself but leaves it up to > the driver to forget 8) OK, now that you both agree on the issue, could somebody please fix it? :-) Thanks, Bart - To unsubscribe from this list: send the line "unsubscribe linux-ide" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Linux Software RAID is really RAID?
Tejun Heo wrote:
Mark Lord wrote:
I believe he said it was ICH5 (different post/thread).
My observation on ICH5 is that if one unplugs a drive,
then the chipset/cpu locks up hard when toggling SRST
in the EH code.
Specifically, it locks up at the instruction
which restores SRST back to the non-asserted state,
which likely corresponds to the chipset finally actually
sending a FIS to the drive.
A hard(ware) lockup, not software.
That's why Intel says ICH5 doesn't do hotplug.
OIC. I don't think there's much left to do from the driver side then.
Or is there any workaround?
The workaround I have, for 2.6.18.8, is to provide an "offline()" method
for ICH5 that polls for device present before attempting SRST.
I hope to eventually clean this up and submit it for you,
after your existing polling-hp code goes upstream.
Here's my present hack (below). Feel free to use/ignore.
***
Implement ICH5 chipset handling for drive hot insertion/removal.
This cannot go upstream, as it conflicts with a more generic
polled-hotplug framework that is currently in development.
Hot-inserted drives are automatically detected within a second or two,
and are ready-to-use within 30 seconds or so.
Hot-removed drives are *not* noticed by the kernel until the next
time they are accessed. If you want this to happen quickly,
then just launch a script like this from /etc/inittab at boot time:
#!/bin/bash
( while ( /bin/true ) ; do /sbin/hdparm -C /dev/sd[a-z] ; sleep 5 ; done )
&>/dev/null &
Signed-off-by: Mark Lord <[EMAIL PROTECTED]>
---
diff -u --recursive --new-file --exclude-from=old/Documentation/dontdiff
old/drivers/scsi/ata_piix.c linux/drivers/scsi/ata_piix.c
--- old/drivers/scsi/ata_piix.c 2007-04-20 14:08:46.0 -0400
+++ linux/drivers/scsi/ata_piix.c 2007-06-26 07:23:21.0 -0400
@@ -106,6 +106,8 @@
PIIX_FLAG_AHCI = (1 << 27), /* AHCI possible */
PIIX_FLAG_CHECKINTR = (1 << 28), /* make sure PCI INTx enabled */
+ PIIX_HOTPLUG_POLL_TM= (2 * (HZ)), /* polling interval for hotplug
*/
+
/* combined mode. if set, PATA is channel 0.
* if clear, PATA is channel 1.
*/
@@ -150,6 +152,171 @@
const struct piix_map_db *map_db;
};
+struct piix_port_priv {
+ int pcs_hotplug_supported;
+ struct timer_list hotplug_timer;
+ u16 old_pcs;
+};
+
+static u32 ich_scr_read (struct ata_port *ap, unsigned int reg)
+{
+ u32 scr = 0;
+
+ if (reg == SCR_STATUS) {
+ struct piix_port_priv *pp = ap->private_data;
+ if (pp && pp->pcs_hotplug_supported) {
+ u16 pcs, port_bit = (1 << ap->hard_port_no);
+ struct pci_dev *pdev = to_pci_dev(ap->dev);
+
+ pci_read_config_word(pdev, ICH5_PCS, &pcs);
+ if (pcs & (port_bit << 4))
+ scr = 0x113;
+ }
+ }
+ return scr;
+}
+
+static int ich_port_offline (struct ata_port *ap)
+{
+ struct pci_dev *pdev;
+ u16 pcs, port_bit = (1 << ap->hard_port_no);
+ struct piix_port_priv *pp = ap->private_data;
+ u8 ostatus;
+ unsigned int offline;
+
+ if (!pp || !pp->pcs_hotplug_supported) {
+ u32 sstatus;
+ if (!sata_scr_read(ap, SCR_STATUS, &sstatus) && (sstatus & 0xf)
!= 0x3)
+ return 1;
+ return 0;
+ }
+
+ /*
+* ICH5 with a mostly good/working PCS register.
+* The only flaw is, it doesn't seem to detect *removed* drives
+* unless we toggle the enable line before checking.
+*/
+ ostatus = ata_altstatus(ap);
+ pdev = to_pci_dev(ap->dev);
+ pci_read_config_word(pdev, ICH5_PCS, &pcs);
+ offline = ((pcs & (port_bit << 4)) == 0);
+
+ if (!offline) {
+ unsigned int usecs;
+
+ /* Cycle PCS register to force it to redetect devices: */
+ pci_write_config_word(pdev, ICH5_PCS, pcs & ~port_bit);
+ udelay(1);
+ pci_write_config_word(pdev, ICH5_PCS, 0x0003);
+
+ /* Wait for SATA PHY to sync up; typically 5->6 usecs */
+ for (usecs = 0; usecs < 100; ++usecs) {
+ pci_read_config_word(pdev, ICH5_PCS, &pcs);
+ offline = ((pcs & (port_bit << 4)) == 0);
+ if (!offline)
+ break;
+ udelay(1);
+ }
+ if (!offline) {
+ unsigned int msecs;
+ /* Wait for drive to become not-BUSY, typically 10->62
msecs */
+ for (msecs = 1; msecs < 150; msecs += 3) {
+ u8 status;
+ msleep(3);
+ status = ata_altstatus(ap);
+ if (status && !(status & ATA_BUSY))
+
Re: [PATCH 3/6] siimage: PIO mode setup fixes
Bartlomiej Zolnierkiewicz wrote:
* Add sil_tuneproc() wrapper for siimage_tuneproc() which also sets
PIO mode on the device.
Planning on the global prefix change? :-)
Yep.
Well, it didn't work out with 'ata_'... ;-)
Because of bad libata taking over our preciouss namespace... ;-)
Thieve! 8-)
Fortunately pata_sil680 driver uses "sil680_" prefix.
We'll make Coxsss pay. 8-)
Note that PIO setup keeps being somewhat borken IODRY-wise even with this
patch as sil_tune_pio() only controls taskfile IORDY sampling -- the Right
Thing could only be done via speedproc() method...
After rehashing the datasheet I see the source of the issue:
IORDY is controlled in two registers and moreover it is always enabled
if MDMA or UDMA transfer modes are selected.
Yeah. I drafted some patch for pata_sil.c but Alan fixed it first and in a
more simple way -- libata calls PIO/DMA setting methods in the strict
sequence, and that allowed to bypass some checks...
I fail to see how this helps in this case, care to explain?
The whole reason for that resetproc() ceases to exist, no? At least that's
what I was able to grasp from looing at the older versions... And it's mean to
reset both channels just to be able to downgrade from UDMA to MWDMA (not a
thing routinely done anyway), so this needs to go.
Well, I'm seeing that it's also called from the ide_dma_timeout() and even
ide_dma_lostirq() methods; not sure how much necessary it is -- at least for
the latter case this seems just wrong...
+ /* cheat for now and use the docs */
+ speedp = data_speed[pio];
+ speedt = tf_speed[tf_pio];
+
if (hwif->mmio) {
hwif->OUTW(speedp, addr);
hwif->OUTW(speedt, tfaddr);
/* Now set up IORDY */
- if(mode_wanted == 3 || mode_wanted == 4)
+ if (pio > 2)
Not tf_pio? This IORDY bit is for taskfile accesses...
Would this be really OK (tf_pio takes minimum PIO mode)?
Well, probably not -- a slow mate drive could force IORDY disabled this
way... So, just 'pio' seems more correct.
Thanks,
Bart
MBR, Sergei
-
To unsubscribe from this list: send the line "unsubscribe linux-ide" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2.6.22-rc7] libata: fix assigned IRQ reporting
Tejun Heo <[EMAIL PROTECTED]> : > Tejun Heo wrote: > > Francois Romieu wrote: > >> I have rebuilt on top of 872aad45d6174570dd2e1defc3efee50f2cfcc72 and it > >> still seems bizarre: > > Okay, 872aad45 doesn't have the patch yet. Either apply the patch > manually or you need to wait a bit more. I am confused. 4031826b3ca40982880f6b9f2282c7d7fad60d77 appears in the log: Author: Tejun Heo <[EMAIL PROTECTED]> Date: Tue Jul 3 01:38:47 2007 +0900 libata: fix assigned IRQ reporting host->irq and host->irq2 should be set before ata_host_register() for IRQ reporting to work. Move up host->irq assignment in ata_host_activate() and add it to ata_pci_init_one() native path and pata_cs5520. The port info printing in ata_host_register() doesn't fit all the different controllers. It should probably be moved out to LLDs with some helpers in the future. Signed-off-by: Tejun Heo <[EMAIL PROTECTED]> Signed-off-by: Jeff Garzik <[EMAIL PROTECTED]> -> it is exactly the patch that you sent on 03/07/2007. -- Ueimor - To unsubscribe from this list: send the line "unsubscribe linux-ide" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: how to handle pata_via when controller not in fully-pci-native mode (two irqs?)
Tejun Heo wrote: > > I forgot about the PCI resource fix up done for legacy hosts. I think > making the host legacy is the best way to take here considering that - > no change for both ide and libata, just some fix up in platform code. > ATA native/legacy thing doesn't mean much. It's just how the resources > are allocated. Is there any specific reason to use native mode? Yes, legacy mode means there are several "io ports" mapped into the 0 thru 0x1000 addresses. This might work in Linux, granted, but I am not sure it is a good idea in the first place. Mapping io ports to anywhere but the PCI io space is just an ugly solution. The ATA native/legacy thing means a lot, as there is no "legacy" on PowerPC. It's a PCI device, so we should try and fix up it's actions as a PCI device, however, making it truly conform will break any "not entirely compatible" drivers break (via8cxxx being the biggest culprit). Therefore no firmware fixes for thee. I do think we can knock it into full PCI native mode from the platform fixups though, as a kernel option. Old drivers will work fine, old kernels will work fine, and optionally old behaviour can be left, but anyone building a new kernel with pata_via and no via8cxxx (i.e. all new distributions) can enable the new behaviour. Does that sound okay? No libata-level resource fixups need to be done for a real PCI device, do they? I think we should just coerce the controller to use a single interrupt and disable ISA interrupt steering, fix the class code, and see if libata handles it. -- Matt Sealey <[EMAIL PROTECTED]> Genesi, Manager, Developer Relations - To unsubscribe from this list: send the line "unsubscribe linux-ide" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 8/10] libata: remove writing of tf->ctl from ata_tf_load()
Albert Lee wrote: Patch 8/10: The relevant bits in the ctl register are HOB, SRST and nIEN. - HOB is only used by ata_tf_read(). - For SRST, soft reset is not the duty of tf_load. - For nIEN, explicit irq_on()/irq_off and freeze()/thaw() are provided. Since EH/HSM now call explicit freeze()/thaw() for irq off/on. Remove the implicit nIEN handling from ata_tf_load(). At some point soon, I hope to piece together enough old hardware here to reconnect my PCI-X sata_qstor card, and then fix the driver. It needs to have control over the nIEN bit, and currently that bit is not behaving as it did way back in 2.6.11(?) when the driver was first added. The qstor chip *requires* that nIEN be "1" during R/W commands. Is there a nice way to accomplish that here? Thanks - To unsubscribe from this list: send the line "unsubscribe linux-ide" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: ata1: soft resetting port
On Thu, 2007-07-05 at 03:01 +0900, Tejun Heo wrote: > Soeren Sonnenburg wrote: > > On Tue, 2007-07-03 at 15:40 +0900, Tejun Heo wrote: > >> Soeren Sonnenburg wrote: > >>> Dear List, > >>> > >>> since the switch to > >>> > >>> CONFIG_ATA=y > >>> CONFIG_ATA_ACPI=y > >>> CONFIG_ATA_PIIX=y, > >>> > >>> the ATA_PIIX driver manages both, internal sata disk aswell as cd/dvd > >>> rom. However I am being flooded with the error messages below (well they > >>> appear from time to time, dominating dmesg). > >>> > >>> This happens on kernel 2.6.22-rc5, I am copying relevant parts from dmesg: > >> Does 2.6.22-rc7 fare better? > > > > Yes indeed. The only thing I've seen in the last two days was the > > following on resume: > > > > pci_express :00:1c.2:pcie03: resuming > > sr 0:0:0:0: resuming > > sd 2:0:1:0: resuming > > sd 2:0:1:0: [sda] Starting disk > > ata1.00: configured for UDMA/33 > > ata3.01: revalidation failed (errno=-2) > > ata3: failed to recover some devices, retrying in 5 secs > > ata3.01: configured for UDMA/133 > > Hmmm... That's NODEV_HINT being triggered after resume. Probably the > device isn't ready to respond yet at that point. How reproducible is > the problem? quite reproducible: $ dmesg | grep 'revalidation failed' | wc -l 4 Soeren -- Sometimes, there's a moment as you're waking, when you become aware of the real world around you, but you're still dreaming. - To unsubscribe from this list: send the line "unsubscribe linux-ide" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] ide: add ide_set{_max}_pio() (take 2)
On Wednesday 04 July 2007, Sergei Shtylyov wrote:
> Bartlomiej Zolnierkiewicz wrote:
>
> >>> reporting PIO mode selected from ->tuneproc implementations.
>
> >>>* Rename ->tuneproc hook to ->set_pio_mode
>
> >>Well, tuneproc() went with speedproc() rather well. :-)
>
> > ->set_pio_mode goes better with ->set_dma_mode ;-)
>
> Ah, good to know where we're moving... :-)
>
> >>>and make 'pio' argument const.
>
> >>Isn't it too strict, const value argument?
>
> > Not really, this is to prevent potential mistakes and catch them early.
>
> > Please note that this patch pushes all logic dealing with finding the best
> > PIO mode and also limiting PIO mode passed by the user from ->tuneproc
> > to the core code. Another logical step is to move ide_rate_filter() out
> > of ->speedproc to the core code (fixing ide_rate_filter() while at it)
> > and this step is alsmost done (I will post patch soon).
>
> Too many patches recently. :-)
There is never too many patches!
Only too little time... :-)
> > After ide_rate_filter() change is done we can start syncing code setting
> > PIO modes in ->set_pio_mode and ->speedproc (there are some suspicious
> > disrepancies in some drivers besides the usual bug of not setting transfer
> > mode on the device in ->tuneproc). Finally we can switch the core code to
> > just use ->set_pio_mode for PIO modes and turn ->speedproc into new shiny
> > ->set_dma_mode method.
>
> >>>* Remove stale comment from ide_config_drive_speed().
>
> >>Hm, the next logical step would be to remove a call to
> >>ide_config_drive_speed() from the set_pio_mode() handler, wouldn't it?..
>
> > Yes.
>
> Again, good to know. Too bad that these cleanups haven't happened until
They were not possible before some massive bugfixing/rewritting of host
drivers and still wouldn't be possible if you didn't take care of some of
the worst (== most complicated ones) offenders like hpt366, sl82c105, etc.
Also some Alan's libata PATA changes were a great help. Maybe except the
fact that the changes needed to be reverse engineered from the new drivers
(because they lacked any changelog/patchlog) which was a major PITA.
It is to be regretted that help in fixing host drivers didn't come two-three
years ago. I had complete plan for IDE core rewrite with many changes already
done but I was still lacking some expertise (for some chipsets) and time to do
the needed changes to all host drivers.
> now -- when libata PATA support seems already ripe enough. :-)
libata PATA is quite mature but still lacks support for some popular chipsets
and have regressions for less common hardware so it may take a while.
Not to mention compulsory SCSI-emulation which I just find disgusting... ;-)
> >>>Index: b/drivers/ide/pci/it8213.c
> >>>===
> >>>--- a/drivers/ide/pci/it8213.c
> >>>+++ b/drivers/ide/pci/it8213.c
> >>>@@ -4,6 +4,8 @@
> >>> * Copyright (C) 2006 Jack Lee
> >>> * Copyright (C) 2006 Alan Cox
> >>> * Copyright (C) 2007 Bartlomiej Zolnierkiewicz
> >>>+ *
> >>>+ * TODO: make ->set_pio_mode method set transfer mode on the device
>
> >>IMHO, this actually better be done outside of this method (if possible).
>
> > In the long-term, yes.
>
> >>Sigh, that would undo many of my prior fixes...
>
> > It shouldn't if would be handled exactly as is currently done piix.c.
>
> Well, that would turn piix_tune_drive() into completely useless wrapper
> to
> piix_tune_pio() -- exactly what I mean.
>
> > it8213_set_pio_mode() will become a wrapper for it8213_tune_pio().
>
> Hm, there are currently no it8213_tune_pio() -- and would be no need for
> it if we start calling ide_config_drive_speed() outside the set_pio_mode()
> method...
Yes but iff we do this change before fixup change to add
ide_config_drive_speed() call.
Not a big issue really, the wrapper will disappear sooner than later.
> >>>@@ -193,7 +194,9 @@ static int it8213_tune_chipset (ide_driv
> >>> if (reg55 & w_flag)
> >>> pci_write_config_byte(dev, 0x55, (u8) reg55 & ~w_flag);
> >>> }
> >>>- it8213_tuneproc(drive, it8213_dma_2_pio(speed));
> >>>+
> >>>+ it8213_set_pio_mode(drive, it8213_dma_2_pio(speed));
> >>
> >>Bleh... Still haven't "divorced" PIO/DMA timings -- need to get this
> >> done
> >>finally. :-/
>
> > Well, if you would spend some less time nitpicking about CodingStyle... ;-)
>
> That's negligible compared to what I'd have to spend on piix.c (and even
> on finding the real issues with these patches :-).
Do not underestimate yourself. 8)
> >>>@@ -307,10 +306,11 @@ static void pdc202xx_reset (ide_drive_t
> >>> {
> >>> ide_hwif_t *hwif= HWIF(drive);
> >>> ide_hwif_t *mate= hwif->mate;
> >>>-
> >>>+
> >>> pdc202xx_reset_host(hwif);
> >>> pdc202xx_reset_host(mate);
>
> >>Bleh... this double reset horror still needs to be sorted out as well.
> >> I'm
> >>not at al
[PATCH 2.6.22-rc7-git1] sis5513: adding PCI-ID
The SiS966 has one additional PCI-ID 1180.
If the chipset is using this PCI-ID, the primary channel is connected to the
first
PATA-port. The secondary channel is connected to SATA-ports in IDE emulation
mode.
The legacy IO-ports are used.
the including of the PCI-ID into pata_sis is not sufficient, because the legacy
driver
in drivers/ide is initialized before pata_sis.
Signed-off-by: Uwe Koziolek <[EMAIL PROTECTED]>
--- a/include/linux/pci_ids.h 2007-07-03 19:17:44.0 +0200
+++ b/include/linux/pci_ids.h 2007-07-04 21:42:16.0 +0200
@@ -661,6 +661,7 @@
#define PCI_DEVICE_ID_SI_965 0x0965
#define PCI_DEVICE_ID_SI_966 0x0966
#define PCI_DEVICE_ID_SI_968 0x0968
+#define PCI_DEVICE_ID_SI_1180 0x1180
#define PCI_DEVICE_ID_SI_5511 0x5511
#define PCI_DEVICE_ID_SI_5513 0x5513
#define PCI_DEVICE_ID_SI_5517 0x5517
--- a/drivers/ide/pci/sis5513.c 2007-07-03 19:17:02.0 +0200
+++ b/drivers/ide/pci/sis5513.c 2007-07-04 21:34:56.0 +0200
@@ -872,6 +872,7 @@
static struct pci_device_id sis5513_pci_tbl[] = {
{ PCI_VENDOR_ID_SI, PCI_DEVICE_ID_SI_5513, PCI_ANY_ID, PCI_ANY_ID, 0,
0, 0},
{ PCI_VENDOR_ID_SI, PCI_DEVICE_ID_SI_5518, PCI_ANY_ID, PCI_ANY_ID, 0,
0, 0},
+ { PCI_VENDOR_ID_SI, PCI_DEVICE_ID_SI_1180, PCI_ANY_ID, PCI_ANY_ID, 0,
0, 0},
{ 0, },
};
MODULE_DEVICE_TABLE(pci, sis5513_pci_tbl);
-
To unsubscribe from this list: send the line "unsubscribe linux-ide" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
"libata ignore_hpa=1" doesn't wok on SATA ?
Hi, . I would like to see the whole disk area and erase the hpa area in my desktop. At first I tried "setmax.c" program but it didn't work on SATA at least. So I upgraeded it to FC7 and added "libata ignore_hpa=1" option on boot command and /etc/modprobe.conf. This option was accepted but still the kernel couldn't see the whole disk area even after reboot. I am using FC7, kernel-2.6.21 and 250 SATA disk. Could you please give me some more tips ? . Warm regards, Nobel 180도 달라진 야후! 메일 - 여러 개의 메시지를 동시에 확인? 새로운 야후! 메일의 탭으로 가능해집니다. http://kr.content.mail.yahoo.com/cgland - To unsubscribe from this list: send the line "unsubscribe linux-ide" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [1/2] 2.6.22-rc7: known regressions
On Tue, 2007-07-03 at 18:45 +0200, Michal Piotrowski wrote: > Subject: random invalid instruction occourances on sparc32 (sun4c) > References : http://lkml.org/lkml/2007/6/17/111 > Submitter : Mark Fortescue <[EMAIL PROTECTED]> > Status : problem is being debugged Hm, when testing the fix for that on ppc32, I stupidly built with Slub instead, and got this... radeonfb: Monitor 1 type LCD found radeonfb: EDID probed radeonfb: Monitor 2 type no found radeonfb: Using Firmware dividers 0x00040080 from PPLL 0 radeonfb: Dynamic Clock Power Management enabled *** SLUB kmalloc-32768: Poison check [EMAIL PROTECTED] slab 0xc04de400 [Not tainted] offset=0 flags=0x40c3 inuse=0 freelist=0xc1e2 Object 0xc1e2: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b Object 0xc1e20010: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b Object 0xc1e20020: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b Object 0xc1e20030: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b Object 0xc1e20040: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b Object 0xc1e20050: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b Object 0xc1e20060: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b Object 0xc1e20070: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b Redzone 0xc1e28000: bb bb bb bb FreePointer 0xc1e28004 -> 0x Last alloc: malloc+0x14/0x24 jiffies_ago=1382 cpu=0 pid=1 Last free : free+0x10/0x20 jiffies_ago=837 cpu=0 pid=1 Filler 0xc1e28028: 5a 5a 5a 5a 5a 5a 5a 5a Call Trace: [effc7b80] [c000893c] show_stack+0x50/0x184 (unreliable) [effc7ba0] [c009705c] object_err+0x178/0x18c [effc7bc0] [c0097380] check_object+0x180/0x2ec [effc7be0] [c0098320] __slab_alloc+0x5c8/0x5f4 [effc7c10] [c0098aa4] __kmalloc+0x64/0x9c [effc7c30] [c015f5dc] fbcon_startup+0x154/0x2c0 [effc7c60] [c01bb8ec] register_con_driver+0x94/0x164 [effc7c90] [c01bedc8] take_over_console+0x24/0x58 [effc7cb0] [c015b41c] fbcon_takeover+0x8c/0xec [effc7cc0] [c015d31c] fbcon_event_notify+0x1e0/0x6c8 [effc7d90] [c02d9490] notifier_call_chain+0x3c/0x94 [effc7db0] [c0045468] __blocking_notifier_call_chain+0x50/0x74 [effc7dd0] [c014f514] fb_notifier_call_chain+0x24/0x34 [effc7de0] [c0150590] register_framebuffer+0x190/0x1a8 [effc7e40] [c0185450] radeonfb_pci_register+0xe54/0xf50 [effc7e70] [c0145b04] pci_device_probe+0x6c/0xa0 [effc7e90] [c01d4108] driver_probe_device+0xfc/0x1a0 [effc7eb0] [c01d436c] __driver_attach+0xac/0x110 [effc7ed0] [c01d32f0] bus_for_each_dev+0x50/0x94 [effc7f00] [c01d3efc] driver_attach+0x24/0x34 [effc7f10] [c01d3710] bus_add_driver+0x78/0x1a0 [effc7f30] [c01d468c] driver_register+0x88/0x9c [effc7f40] [c0145900] __pci_register_driver+0x6c/0xb8 [effc7f60] [c03e8e4c] radeonfb_init+0x20c/0x220 [effc7f80] [c03c82e4] kernel_init+0xc8/0x284 [effc7ff0] [c0013e28] kernel_thread+0x44/0x60 @@@ SLUB kmalloc-32768: Restoring Poison (0x6b) from 0xc1e2-0xc1e27ffe @@@ SLUB kmalloc-32768: Restoring Poison (0xa5) from 0xc1e27fff-0xc1e27fff @@@ SLUB: kmalloc-32768 slab 0xc04de400. Marking all objects used. Console: switching to colour frame buffer device 180x56 -- dwmw2 - To unsubscribe from this list: send the line "unsubscribe linux-ide" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 2.6.22 REGRESSION] Fix slab redzone alignment
Commit b46b8f19c9cd435ecac4d9d12b39d78c137ecd66 fixed a couple of bugs
by switching the redzone to 64 bits. Unfortunately, it neglected to
ensure that the _second_ redzone, after the slab object, is aligned
correctly. This caused illegal instruction faults on sparc32, which for
some reason not entirely clear to me are not trapped and fixed up.
Two things need to be done to fix this:
- increase the object size, rounding up to alignof(long long) so
that the second redzone can be aligned correctly.
- If SLAB_STORE_USER is set but alignof(long long)==8, allow a
full 64 bits of space for the user word at the end of the buffer,
even though we may not _use_ the whole 64 bits.
This patch should be a no-op on any 64-bit architecture or any 32-bit
architecture where alignof(long long) == 4. Of the others, it's tested
on ppc32 by myself and a very similar patch was tested on sparc32 by
Mark Fortescue, who reported the new problem.
Also, fix the conditions for FORCED_DEBUG, which hadn't been adjusted to
the new sizes. Again noticed by Mark.
Signed-off-by: David Woodhouse <[EMAIL PROTECTED]>
diff --git a/mm/slab.c b/mm/slab.c
index a9c4472..b344e67 100644
--- a/mm/slab.c
+++ b/mm/slab.c
@@ -137,6 +137,7 @@
/* Shouldn't this be in a header file somewhere? */
#defineBYTES_PER_WORD sizeof(void *)
+#defineREDZONE_ALIGN max(BYTES_PER_WORD,
__alignof__(unsigned long long))
#ifndef cache_line_size
#define cache_line_size() L1_CACHE_BYTES
@@ -547,7 +548,7 @@ static unsigned long long *dbg_redzone2(struct kmem_cache
*cachep, void *objp)
if (cachep->flags & SLAB_STORE_USER)
return (unsigned long long *)(objp + cachep->buffer_size -
sizeof(unsigned long long) -
- BYTES_PER_WORD);
+ REDZONE_ALIGN);
return (unsigned long long *) (objp + cachep->buffer_size -
sizeof(unsigned long long));
}
@@ -2178,7 +2179,8 @@ kmem_cache_create (const char *name, size_t size, size_t
align,
* above the next power of two: caches with object sizes just above a
* power of two have a significant amount of internal fragmentation.
*/
- if (size < 4096 || fls(size - 1) == fls(size-1 + 3 * BYTES_PER_WORD))
+ if (size < 4096 || fls(size - 1) == fls(size-1 + REDZONE_ALIGN +
+ 2 * sizeof(unsigned long long)))
flags |= SLAB_RED_ZONE | SLAB_STORE_USER;
if (!(flags & SLAB_DESTROY_BY_RCU))
flags |= SLAB_POISON;
@@ -2219,12 +2221,20 @@ kmem_cache_create (const char *name, size_t size,
size_t align,
}
/*
-* Redzoning and user store require word alignment. Note this will be
-* overridden by architecture or caller mandated alignment if either
-* is greater than BYTES_PER_WORD.
+* Redzoning and user store require word alignment or possibly larger.
+* Note this will be overridden by architecture or caller mandated
+* alignment if either is greater than BYTES_PER_WORD.
*/
- if (flags & SLAB_RED_ZONE || flags & SLAB_STORE_USER)
- ralign = __alignof__(unsigned long long);
+ if (flags & SLAB_STORE_USER)
+ ralign = BYTES_PER_WORD;
+
+ if (flags & SLAB_RED_ZONE) {
+ ralign = REDZONE_ALIGN;
+ /* If redzoning, ensure that the second redzone is suitably
+* aligned, by adjusting the object size accordingly. */
+ size += REDZONE_ALIGN - 1;
+ size &= ~(REDZONE_ALIGN - 1);
+ }
/* 2) arch mandated alignment */
if (ralign < ARCH_SLAB_MINALIGN) {
@@ -2261,9 +2271,13 @@ kmem_cache_create (const char *name, size_t size, size_t
align,
}
if (flags & SLAB_STORE_USER) {
/* user store requires one word storage behind the end of
-* the real object.
+* the real object. But if the second red zone needs to be
+* aligned to 64 bits, we must allow that much space.
*/
- size += BYTES_PER_WORD;
+ if (flags & SLAB_RED_ZONE)
+ size += REDZONE_ALIGN;
+ else
+ size += BYTES_PER_WORD;
}
#if FORCED_DEBUG && defined(CONFIG_DEBUG_PAGEALLOC)
if (size >= malloc_sizes[INDEX_L3 + 1].cs_size
--
dwmw2
-
To unsubscribe from this list: send the line "unsubscribe linux-ide" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [1/2] 2.6.22-rc7: known regressions
On Tue, 2007-07-03 at 18:45 +0200, Michal Piotrowski wrote: > Hi all, > > Here is a list of some known regressions in 2.6.22-rc7. Oh, and here's another one for you. My Bluetooth mouse just stopped working and hidd is deadlocked... hidd D 1FE27798 5940 1695 1 (NOTLB) Call Trace: [ef3ddb70] [0004] 0x4 (unreliable) [ef3ddc30] [c0008e7c] __switch_to+0x50/0x68 [ef3ddc50] [c02d5998] schedule+0x3cc/0x480 [ef3ddc80] [c0137a20] rwsem_down_failed_common+0x1c4/0x1f4 [ef3ddcb0] [c02d7454] rwsem_down_write_failed+0x28/0x40 [ef3ddce0] [c004ff60] down_write+0x50/0x64 [ef3ddd00] [f27f2068] hidp_add_connection+0x168/0x75c [hidp] [ef3ddd40] [f27f2e44] hidp_sock_ioctl+0x140/0x414 [hidp] [ef3ddeb0] [c024da6c] sock_ioctl+0x248/0x284 [ef3dded0] [c00ab02c] do_ioctl+0x38/0x84 [ef3ddee0] [c00ab448] vfs_ioctl+0x3d0/0x404 [ef3ddf10] [c00ab4e4] sys_ioctl+0x68/0x98 -- dwmw2 - To unsubscribe from this list: send the line "unsubscribe linux-ide" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: ata1: soft resetting port
Soeren Sonnenburg wrote: >>> pci_express :00:1c.2:pcie03: resuming >>> sr 0:0:0:0: resuming >>> sd 2:0:1:0: resuming >>> sd 2:0:1:0: [sda] Starting disk >>> ata1.00: configured for UDMA/33 >>> ata3.01: revalidation failed (errno=-2) >>> ata3: failed to recover some devices, retrying in 5 secs >>> ata3.01: configured for UDMA/133 >> Hmmm... That's NODEV_HINT being triggered after resume. Probably the >> device isn't ready to respond yet at that point. How reproducible is >> the problem? > > quite reproducible: > > $ dmesg | grep 'revalidation failed' | wc -l > 4 Hmmm... Thanks. I think the best we can do is 1. don't wait for disk revalidation during resume 2. retry faster. Just in case, please post the result of "hdparm -I /dev/sdX" where sdX is the device at ata3.01. -- tejun - To unsubscribe from this list: send the line "unsubscribe linux-ide" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: how to handle pata_via when controller not in fully-pci-native mode (two irqs?)
Hello, Matt. Matt Sealey wrote: > Tejun Heo wrote: >> I forgot about the PCI resource fix up done for legacy hosts. I think >> making the host legacy is the best way to take here considering that - >> no change for both ide and libata, just some fix up in platform code. >> ATA native/legacy thing doesn't mean much. It's just how the resources >> are allocated. Is there any specific reason to use native mode? > > Yes, legacy mode means there are several "io ports" mapped into the > 0 thru 0x1000 addresses. This might work in Linux, granted, but I am > not sure it is a good idea in the first place. > > Mapping io ports to anywhere but the PCI io space is just an ugly > solution. The ATA native/legacy thing means a lot, as there is no > "legacy" on PowerPC. It's a PCI device, so we should try and fix up > it's actions as a PCI device, however, making it truly conform will > break any "not entirely compatible" drivers break (via8cxxx being > the biggest culprit). Therefore no firmware fixes for thee. For libata, being native or legacy doesn't really mean that much. With the patch posted yesterday[1], the only difference is how IRQs are requested. Other than that, libata initializes aa legacy controller the same way as a native controller, so you can use mmio exactly the same way. > I do think we can knock it into full PCI native mode from the platform > fixups though, as a kernel option. Old drivers will work fine, old > kernels will work fine, and optionally old behaviour can be left, but > anyone building a new kernel with pata_via and no via8cxxx (i.e. all > new distributions) can enable the new behaviour. That would work too but if you do PCI header fix up for legacy host, nothing needs to be changed and nothing needs to be selected during boot. Both via82cxxx and pata_via would just work. The controller's PCI BARs contain valid values on entering kernel, right? The only thing you have to do is flipping the legacy bit in platform PCI fix up code. -- tejun [1] http://article.gmane.org/gmane.linux.ide/20357 - To unsubscribe from this list: send the line "unsubscribe linux-ide" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2.6.22-rc7] libata: fix assigned IRQ reporting
Francois Romieu wrote: > Tejun Heo <[EMAIL PROTECTED]> : >> Tejun Heo wrote: >>> Francois Romieu wrote: I have rebuilt on top of 872aad45d6174570dd2e1defc3efee50f2cfcc72 and it still seems bizarre: >> Okay, 872aad45 doesn't have the patch yet. Either apply the patch >> manually or you need to wait a bit more. > > I am confused. 4031826b3ca40982880f6b9f2282c7d7fad60d77 appears in the log: > Author: Tejun Heo <[EMAIL PROTECTED]> > > Date: Tue Jul 3 01:38:47 2007 +0900 > > > > libata: fix assigned IRQ reporting > Apparently, I'm more confused than you are. My "master" was at 872aad45 but my index was at rc7. Can you please force checkout the head and re-test? I've tested both native and legacy modes and it's fixed here. Thanks. -- tejun - To unsubscribe from this list: send the line "unsubscribe linux-ide" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 8/10] libata: remove writing of tf->ctl from ata_tf_load()
Mark Lord wrote: > Albert Lee wrote: > >> Patch 8/10: >> >> The relevant bits in the ctl register are HOB, SRST and nIEN. >> - HOB is only used by ata_tf_read(). >> - For SRST, soft reset is not the duty of tf_load. >> - For nIEN, explicit irq_on()/irq_off and freeze()/thaw() are provided. >> >> Since EH/HSM now call explicit freeze()/thaw() for irq off/on. >> Remove the implicit nIEN handling from ata_tf_load(). > > > At some point soon, I hope to piece together enough old hardware here > to reconnect my PCI-X sata_qstor card, and then fix the driver. > > It needs to have control over the nIEN bit, and currently that bit > is not behaving as it did way back in 2.6.11(?) when the driver was > first added. > > The qstor chip *requires* that nIEN be "1" during R/W commands. > Is there a nice way to accomplish that here? > Does it mean that during the execution of PIO R/W commands, no interrupt will be generated? Currently the sata_qstor driver uses the ATA_FLAG_PIO_POLLING flag, does such polling pio fulfill the need of qstor? If not, maybe we could check what needs to be added and include them into consideration. Hmm, another consideration for qstor, irq_on/off do have their value for nIEN manipulation. The patchset maybe too far in scope. I will limit the scope of the patchset and leave irq_on/off alone (rather than integrate with thaw/freeze). Thanks for the comments. -- albert - To unsubscribe from this list: send the line "unsubscribe linux-ide" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 2.6.22-rc7] libata: quirk IOMEGA ZIP 250 ATAPI FLOPPY
The Zip 250 which chokes on MWDMA SET_XFERMODE sometimes have "Floppy"
appeneded to its model number. Quirk it too.
http://bugzilla.kernel.org/show_bug.cgi?id=8563
Signed-off-by: Tejun Heo <[EMAIL PROTECTED]>
Cc: Hans de Bruin <[EMAIL PROTECTED]>
---
It seems the Zip 250 mwdma failure on libata doesn't seem to be
libata's fault after all. IDE also fails SET_XFERMODE on this drive
but IDE simply ignores the error and continues to operate in MWDMA
mode, so I guess we can remove the 'temporary fix' comment or add
another quirk type - ATA_HORKAGE_SETXFER_MAY_FAIL - and use it.
Anyways, for the time being, this should do.
drivers/ata/libata-core.c |2 ++
1 file changed, 2 insertions(+)
Index: work/drivers/ata/libata-core.c
===
--- work.orig/drivers/ata/libata-core.c
+++ work/drivers/ata/libata-core.c
@@ -3774,6 +3774,8 @@ static const struct ata_blacklist_entry
{ "SAMSUNG CD-ROM SN-124","N001", ATA_HORKAGE_NODMA },
{ "Seagate STT2A", NULL,ATA_HORKAGE_NODMA },
{ "IOMEGA ZIP 250 ATAPI", NULL, ATA_HORKAGE_NODMA }, /*
temporary fix */
+ { "IOMEGA ZIP 250 ATAPI Floppy",
+ NULL, ATA_HORKAGE_NODMA },
/* Weird ATAPI devices */
{ "TORiSAN DVD-ROM DRD-N216", NULL, ATA_HORKAGE_MAX_SEC_128 },
-
To unsubscribe from this list: send the line "unsubscribe linux-ide" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 2.6.22-rc7 1/3] libata: clean up horkage handling
Horkage handling had the following problems.
* dev->horkage was positioned after ATA_DEVICE_CLEAR_OFFSET, so it was
cleared before the device is configured. This broke
HORKAGE_DIAGNOSTIC.
* Some used dev->horkage while others called ata_device_blacklisted()
directly. This was at best confusing.
This patch moves dev->horkage right after dev->flags and set the field
according to the blacklist during device configuration. All users
test against dev->horkage. ata_device_blacklisted() now has only one
user, make it static. While at it, rename it to ata_dev_blacklisted()
for consistency.
Signed-off-by: Tejun Heo <[EMAIL PROTECTED]>
---
drivers/ata/libata-core.c | 13 -
include/linux/libata.h|3 +--
2 files changed, 9 insertions(+), 7 deletions(-)
Index: work/drivers/ata/libata-core.c
===
--- work.orig/drivers/ata/libata-core.c
+++ work/drivers/ata/libata-core.c
@@ -71,6 +71,7 @@ static unsigned int ata_dev_init_params(
u16 heads, u16 sectors);
static unsigned int ata_dev_set_xfermode(struct ata_device *dev);
static void ata_dev_xfermask(struct ata_device *dev);
+static unsigned long ata_dev_blacklisted(const struct ata_device *dev);
unsigned int ata_print_id = 1;
static struct workqueue_struct *ata_wq;
@@ -1814,7 +1815,7 @@ static void ata_dev_config_ncq(struct at
desc[0] = '\0';
return;
}
- if (ata_device_blacklisted(dev) & ATA_HORKAGE_NONCQ) {
+ if (dev->horkage & ATA_HORKAGE_NONCQ) {
snprintf(desc, desc_sz, "NCQ (not used)");
return;
}
@@ -1862,6 +1863,9 @@ int ata_dev_configure(struct ata_device
if (ata_msg_probe(ap))
ata_dev_printk(dev, KERN_DEBUG, "%s: ENTER\n", __FUNCTION__);
+ /* set horkage */
+ dev->horkage |= ata_dev_blacklisted(dev);
+
/* set _SDD */
rc = ata_acpi_push_id(dev);
if (rc) {
@@ -2042,7 +2046,7 @@ int ata_dev_configure(struct ata_device
dev->max_sectors = ATA_MAX_SECTORS;
}
- if (ata_device_blacklisted(dev) & ATA_HORKAGE_MAX_SEC_128)
+ if (dev->horkage & ATA_HORKAGE_MAX_SEC_128)
dev->max_sectors = min_t(unsigned int, ATA_MAX_SECTORS_128,
dev->max_sectors);
@@ -3809,7 +3813,7 @@ static const struct ata_blacklist_entry
{ }
};
-unsigned long ata_device_blacklisted(const struct ata_device *dev)
+static unsigned long ata_dev_blacklisted(const struct ata_device *dev)
{
unsigned char model_num[ATA_ID_PROD_LEN + 1];
unsigned char model_rev[ATA_ID_FW_REV_LEN + 1];
@@ -3839,7 +3843,7 @@ static int ata_dma_blacklisted(const str
if ((dev->ap->flags & ATA_FLAG_PIO_POLLING) &&
(dev->flags & ATA_DFLAG_CDB_INTR))
return 1;
- return (ata_device_blacklisted(dev) & ATA_HORKAGE_NODMA) ? 1 : 0;
+ return (dev->horkage & ATA_HORKAGE_NODMA) ? 1 : 0;
}
/**
@@ -6875,7 +6879,6 @@ EXPORT_SYMBOL_GPL(ata_host_resume);
EXPORT_SYMBOL_GPL(ata_id_string);
EXPORT_SYMBOL_GPL(ata_id_c_string);
EXPORT_SYMBOL_GPL(ata_id_to_dma_mode);
-EXPORT_SYMBOL_GPL(ata_device_blacklisted);
EXPORT_SYMBOL_GPL(ata_scsi_simulate);
EXPORT_SYMBOL_GPL(ata_pio_need_iordy);
Index: work/include/linux/libata.h
===
--- work.orig/include/linux/libata.h
+++ work/include/linux/libata.h
@@ -428,6 +428,7 @@ struct ata_device {
struct ata_port *ap;
unsigned intdevno; /* 0 or 1 */
unsigned long flags; /* ATA_DFLAG_xxx */
+ unsigned inthorkage;/* List of broken features */
struct scsi_device *sdev; /* attached SCSI device */
/* n_sector is used as CLEAR_OFFSET, read comment above CLEAR_OFFSET */
u64 n_sectors; /* size of device, if ATA */
@@ -456,7 +457,6 @@ struct ata_device {
/* error history */
struct ata_eringering;
int spdn_cnt;
- unsigned inthorkage;/* List of broken features */
#ifdef CONFIG_ATA_ACPI
/* ACPI objects info */
acpi_handle obj_handle;
@@ -772,7 +772,6 @@ extern void ata_id_string(const u16 *id,
extern void ata_id_c_string(const u16 *id, unsigned char *s,
unsigned int ofs, unsigned int len);
extern void ata_id_to_dma_mode(struct ata_device *dev, u8 unknown);
-extern unsigned long ata_device_blacklisted(const struct ata_device *dev);
extern void ata_bmdma_setup (struct ata_queued_cmd *qc);
extern void ata_bmdma_start (struct ata_queued_cmd *qc);
extern void ata_bmdma_stop(struct ata_queued_cmd *qc);
-
To unsubscribe from this list: send the line "unsubscribe linux-ide" in
the body of a message to [EMAIL PROTECTED]
[PATCH 2.6.22-rc7 3/3] libata: pata_via CX700 quirks
For some reason, via decided that combined SATA/PATA setup in sata_via
isn't good enough and added a SATA port without SCR access to CX700.
For yet another unknown reason, slave slot of the SATA port dislikes
SETXFER.
This patch implements two quirks for CX700 - VIA_SATA_PATA and
VIA_BAD_SLAVE_SETXFER. SATA_PATA indicates that the first port is
SATA and BAD_SLAVE_SETXFER indicates slave port may fail SETXFER.
http://bugzilla.kernel.org/show_bug.cgi?id=8563
Signed-off-by: Tejun Heo <[EMAIL PROTECTED]>
---
drivers/ata/pata_via.c | 18 +-
1 file changed, 17 insertions(+), 1 deletion(-)
Index: work/drivers/ata/pata_via.c
===
--- work.orig/drivers/ata/pata_via.c
+++ work/drivers/ata/pata_via.c
@@ -84,6 +84,8 @@ enum {
VIA_BAD_ID = 0x100, /* Has wrong vendor ID (0x1107) */
VIA_BAD_AST = 0x200, /* Don't touch Address Setup Timing */
VIA_NO_ENABLES = 0x400, /* Has no enablebits */
+ VIA_BAD_SLAVE_SETXFER = 0x0800, /* SETXFER on slave device may fail */
+ VIA_SATA_PATA = 0x1000, /* SATA/PATA combined configuration */
};
/*
@@ -99,7 +101,7 @@ static const struct via_isa_bridge {
} via_isa_bridges[] = {
{ "vt8237s",PCI_DEVICE_ID_VIA_8237S,0x00, 0x2f, VIA_UDMA_133 |
VIA_BAD_AST },
{ "vt8251", PCI_DEVICE_ID_VIA_8251, 0x00, 0x2f, VIA_UDMA_133 |
VIA_BAD_AST },
- { "cx700", PCI_DEVICE_ID_VIA_CX700,0x00, 0x2f, VIA_UDMA_133 |
VIA_BAD_AST },
+ { "cx700", PCI_DEVICE_ID_VIA_CX700,0x00, 0x2f, VIA_UDMA_133 |
VIA_BAD_AST | VIA_SATA_PATA | VIA_BAD_SLAVE_SETXFER },
{ "vt6410", PCI_DEVICE_ID_VIA_6410, 0x00, 0x2f, VIA_UDMA_133 |
VIA_BAD_AST | VIA_NO_ENABLES},
{ "vt8237a",PCI_DEVICE_ID_VIA_8237A,0x00, 0x2f, VIA_UDMA_133 |
VIA_BAD_AST },
{ "vt8237", PCI_DEVICE_ID_VIA_8237, 0x00, 0x2f, VIA_UDMA_133 |
VIA_BAD_AST },
@@ -168,6 +170,9 @@ static int via_cable_detect(struct ata_p
if (via_cable_override(pdev))
return ATA_CBL_PATA40_SHORT;
+ if ((config->flags & VIA_SATA_PATA) && ap->port_no == 0)
+ return ATA_CBL_SATA;
+
/* Early chips are 40 wire */
if ((config->flags & VIA_UDMA) < VIA_UDMA_66)
return ATA_CBL_PATA40;
@@ -292,6 +297,15 @@ static void via_do_set_mode(struct ata_p
pci_write_config_byte(pdev, 0x50 + offset, ut);
}
+static void via_dev_config(struct ata_device *dev)
+{
+ const struct via_isa_bridge *config = dev->ap->host->private_data;
+
+ /* some new VIA chips have problem with SETXFER on slave slot */
+ if (dev->devno && (config->flags & VIA_BAD_SLAVE_SETXFER))
+ dev->horkage |= ATA_HORKAGE_SETXFER;
+}
+
static void via_set_piomode(struct ata_port *ap, struct ata_device *adev)
{
const struct via_isa_bridge *config = ap->host->private_data;
@@ -334,6 +348,7 @@ static struct scsi_host_template via_sht
static struct ata_port_operations via_port_ops = {
.port_disable = ata_port_disable,
+ .dev_config = via_dev_config,
.set_piomode= via_set_piomode,
.set_dmamode= via_set_dmamode,
.mode_filter= ata_pci_default_filter,
@@ -370,6 +385,7 @@ static struct ata_port_operations via_po
static struct ata_port_operations via_port_ops_noirq = {
.port_disable = ata_port_disable,
+ .dev_config = via_dev_config,
.set_piomode= via_set_piomode,
.set_dmamode= via_set_dmamode,
.mode_filter= ata_pci_default_filter,
-
To unsubscribe from this list: send the line "unsubscribe linux-ide" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 2.6.22-rc7 2/3] libata: implement HORKAGE_SETXFER
Make CFA SETXFER failure handling into HORKAGE. This will be used to
allow other cases to ignore SETXFER failure.
Signed-off-by: Tejun Heo <[EMAIL PROTECTED]>
---
drivers/ata/libata-core.c | 15 ++-
include/linux/libata.h|1 +
2 files changed, 11 insertions(+), 5 deletions(-)
Index: work/drivers/ata/libata-core.c
===
--- work.orig/drivers/ata/libata-core.c
+++ work/drivers/ata/libata-core.c
@@ -1898,7 +1898,7 @@ int ata_dev_configure(struct ata_device
* common ATA, ATAPI feature tests
*/
- /* find max transfer mode; for printk only */
+ /* determine xfermask */
xfer_mask = ata_id_xfermask(id);
if (ata_msg_probe(ap))
@@ -1919,8 +1919,13 @@ int ata_dev_configure(struct ata_device
"supports DRM functions and may "
"not be fully accessable.\n");
snprintf(revbuf, 7, "CFA");
- }
- else
+
+ /* Old CFA may refuse SETFEATURES_XFER, which
+* is just fine
+*/
+ if (!(xfer_mask & ~ATA_MASK_PIO))
+ dev->horkage |= ATA_HORKAGE_SETXFER;
+ } else
snprintf(revbuf, 7, "ATA-%d",
ata_id_major_version(id));
dev->n_sectors = ata_id_n_sectors(id);
@@ -2775,8 +2780,8 @@ static int ata_dev_set_mode(struct ata_d
dev->flags |= ATA_DFLAG_PIO;
err_mask = ata_dev_set_xfermode(dev);
- /* Old CFA may refuse this command, which is just fine */
- if (dev->xfer_shift == ATA_SHIFT_PIO && ata_id_is_cfa(dev->id))
+
+ if (dev->horkage & ATA_HORKAGE_SETXFER)
err_mask &= ~AC_ERR_DEV;
if (err_mask) {
Index: work/include/linux/libata.h
===
--- work.orig/include/linux/libata.h
+++ work/include/linux/libata.h
@@ -298,6 +298,7 @@ enum {
ATA_HORKAGE_NODMA = (1 << 1), /* DMA problems */
ATA_HORKAGE_NONCQ = (1 << 2), /* Don't use NCQ */
ATA_HORKAGE_MAX_SEC_128 = (1 << 3), /* Limit max sects to 128 */
+ ATA_HORKAGE_SETXFER = (1 << 4), /* SETFEATURES_XFER may fail */
};
enum hsm_task_states {
-
To unsubscribe from this list: send the line "unsubscribe linux-ide" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
