2.6.20 libata cdrom

I've been playing with libata on a few machines and I found that this machine (An old Dell Dimension L866r) gives me this when it loads and does not give me access to the cdrom. This is the only machine that I've tested that I know for a fact cannot do DMA on the cdrom. I searched and noticed a similar problem with 2.6.19-rc versions but I'm not sure if it's the same problem.

dmesg output:
libata version 2.00 loaded.
ata_piix 0000:00:1f.1: version 2.00ac7
PCI: Setting latency timer of device 0000:00:1f.1 to 64
ata1: PATA max UDMA/66 cmd 0x1F0 ctl 0x3F6 bmdma 0xFFA0 irq 14
ata2: PATA max UDMA/66 cmd 0x170 ctl 0x376 bmdma 0xFFA8 irq 15 scsi0 : ata_piix
ata1.00: ATA-4, max UDMA/33, 10018890 sectors: LBA ata1.00: ata1: dev 0 multi count 16
ata1.00: configured for UDMA/33
scsi1 : ata_piix
ata2.00: failed to IDENTIFY (I/O error, err_mask=0x1)

Quoted 6 lines · William Thompson

I've been playing with libata on a few machines and I found that this machine (An old Dell Dimension L866r) gives me this when it loads and does not give me access to the cdrom. This is the only machine that I've tested that I know for a fact cannot do DMA on the cdrom. I searched and noticed a similar problem with 2.6.19-rc versions but I'm not sure if it's the same problem.

Quoted 12 lines

dmesg output:
libata version 2.00 loaded.
ata_piix 0000:00:1f.1: version 2.00ac7
PCI: Setting latency timer of device 0000:00:1f.1 to 64
ata1: PATA max UDMA/66 cmd 0x1F0 ctl 0x3F6 bmdma 0xFFA0 irq 14
ata2: PATA max UDMA/66 cmd 0x170 ctl 0x376 bmdma 0xFFA8 irq 15 scsi0 : ata_piix
ata1.00: ATA-4, max UDMA/33, 10018890 sectors: LBA ata1.00: ata1: dev 0 multi count 16
ata1.00: configured for UDMA/33
scsi1 : ata_piix
ata2.00: failed to IDENTIFY (I/O error, err_mask=0x1)

Hmm... IDENTIFY failed on the second port. How reproducible is the problem? Every time? Does it work with the IDE driver? If so, please post the result of 'hdparm -I /dev/hdX'.

Quoted 19 lines · Tejun Heo

Quoted 6 lines · William Thompson

I've been playing with libata on a few machines and I found that this machine (An old Dell Dimension L866r) gives me this when it loads and does not give me access to the cdrom. This is the only machine that I've tested that I know for a fact cannot do DMA on the cdrom. I searched and noticed a similar problem with 2.6.19-rc versions but I'm not sure if it's the same problem.

Quoted 12 lines

dmesg output:
libata version 2.00 loaded.
ata_piix 0000:00:1f.1: version 2.00ac7
PCI: Setting latency timer of device 0000:00:1f.1 to 64
ata1: PATA max UDMA/66 cmd 0x1F0 ctl 0x3F6 bmdma 0xFFA0 irq 14
ata2: PATA max UDMA/66 cmd 0x170 ctl 0x376 bmdma 0xFFA8 irq 15 scsi0 : ata_piix
ata1.00: ATA-4, max UDMA/33, 10018890 sectors: LBA ata1.00: ata1: dev 0 multi count 16
ata1.00: configured for UDMA/33
scsi1 : ata_piix
ata2.00: failed to IDENTIFY (I/O error, err_mask=0x1)

Quoted 3 lines

Hmm... IDENTIFY failed on the second port. How reproducible is the problem? Every time? Does it work with the IDE driver? If so, please post the result of 'hdparm -I /dev/hdX'.

Reproducible? Everytime

Yes, it works fine with the IDE driver, so long as DMA is disabled.

hdparm -I:
/dev/hdc:

ATAPI CD-ROM, with removable media
Model Number: Lite-On LTN483S 48x Max
Serial Number:
Firmware Revision: PD02
Standards:
Used: ATAPI for CD-ROMs, SFF-8020i, r2.5
Supported: CD-ROM ATAPI-1
Configuration:
DRQ response: <=10ms with INTRQ
Packet size: 12 bytes
Capabilities:
LBA, IORDY(can be disabled)
DMA: sdma0 sdma1 sdma2 mdma0 mdma1 mdma2 udma0 udma1 *udma2
Cycle time: min=120ns recommended=120ns
PIO: pio0 pio1 pio2 pio3 pio4
Cycle time: no flow control=120ns IORDY flow control=120ns

[cc'ing linux-ide and Albert, Hi!]

Quoted 31 lines · William Thompson

Quoted 19 lines · Tejun Heo

Quoted 6 lines · William Thompson

I've been playing with libata on a few machines and I found that this machine (An old Dell Dimension L866r) gives me this when it loads and does not give me access to the cdrom. This is the only machine that I've tested that I know for a fact cannot do DMA on the cdrom. I searched and noticed a similar problem with 2.6.19-rc versions but I'm not sure if it's the same problem.

Quoted 12 lines

dmesg output:
libata version 2.00 loaded.
ata_piix 0000:00:1f.1: version 2.00ac7
PCI: Setting latency timer of device 0000:00:1f.1 to 64
ata1: PATA max UDMA/66 cmd 0x1F0 ctl 0x3F6 bmdma 0xFFA0 irq 14
ata2: PATA max UDMA/66 cmd 0x170 ctl 0x376 bmdma 0xFFA8 irq 15 scsi0 : ata_piix
ata1.00: ATA-4, max UDMA/33, 10018890 sectors: LBA ata1.00: ata1: dev 0 multi count 16
ata1.00: configured for UDMA/33
scsi1 : ata_piix
ata2.00: failed to IDENTIFY (I/O error, err_mask=0x1)

Quoted 3 lines

Hmm... IDENTIFY failed on the second port. How reproducible is the problem? Every time? Does it work with the IDE driver? If so, please post the result of 'hdparm -I /dev/hdX'.

Reproducible? Everytime

Yes, it works fine with the IDE driver, so long as DMA is disabled.

hdparm -I:
/dev/hdc:

Quoted 16 lines

ATAPI CD-ROM, with removable media
Model Number: Lite-On LTN483S 48x Max
Serial Number:
Firmware Revision: PD02
Standards:
Used: ATAPI for CD-ROMs, SFF-8020i, r2.5
Supported: CD-ROM ATAPI-1
Configuration:
DRQ response: <=10ms with INTRQ
Packet size: 12 bytes
Capabilities:
LBA, IORDY(can be disabled)
DMA: sdma0 sdma1 sdma2 mdma0 mdma1 mdma2 udma0 udma1 *udma2
Cycle time: min=120ns recommended=120ns
PIO: pio0 pio1 pio2 pio3 pio4
Cycle time: no flow control=120ns IORDY flow control=120ns

The err_mask is AC_ERR_DEV indicating that the device raised aborted the IDENTIFY command. I wonder what's going on.

Can you change "#undef ATA_DEBUG" in include/linux/libata.h to "#define ATA_DEBUG" and report the resulting dmesg? There will be a LOT of messages so you probably want to increase printk buffer size and detach other devices if possible. It would be best if your root device isn't driven by libata so that you can just insert the module and store the resulting dmesg.

libata-atapiix renamed from noata +22 -0

+scsi2 : ata_piix
+ata_port_schedule_eh: port EH scheduled
+ata_scsi_error: ENTER
+ata_port_flush_task: ENTER
+ata_port_flush_task: flush #1
+ata2: ata_port_flush_task: flush #2
+ata2: ata_port_flush_task: EXIT
+ata_eh_autopsy: ENTER
+ata_eh_recover: ENTER
+ata_eh_prep_resume: ENTER
+ata_eh_prep_resume: EXIT
+__ata_port_freeze: ata2 port frozen
+ata_std_softreset: ENTER
+ata_std_softreset: about to softreset, devmask=1
+ata_bus_softreset: ata2: bus reset via SRST
+ata_dev_classify: found ATA device by sig
+ata_dev_classify: unknown device
+ata_std_softreset: EXIT, classes[0]=1 [1]=5
+ata_std_postreset: ENTER
+ata_std_postreset: EXIT
+ata_eh_thaw_port: ata2 port thawed
+ata_eh_revalidate_and_attach: ENTER

Quoted 33 lines · William Thompson

libata-atapiix renamed from noata +32 -0

+scsi2 : ata_piix
+ata_port_schedule_eh: port EH scheduled
+ata_scsi_error: ENTER
+ata_port_flush_task: ENTER
+ata_port_flush_task: flush #1
+ata2: ata_port_flush_task: flush #2
+ata2: ata_port_flush_task: EXIT
+ata_eh_autopsy: ENTER
+ata_eh_recover: ENTER
+ata_eh_prep_resume: ENTER
+ata_eh_prep_resume: EXIT
+__ata_port_freeze: ata2 port frozen
+ata_std_softreset: ENTER
+ata_std_softreset: about to softreset, devmask=1
+ata_bus_softreset: ata2: bus reset via SRST
+ata_dev_classify: found ATA device by sig
+ata_dev_classify: unknown device
+ata_std_softreset: EXIT, classes[0]=1 [1]=5
+ata_std_postreset: ENTER
+ata_std_postreset: EXIT
+ata_eh_thaw_port: ata2 port thawed
+ata_eh_revalidate_and_attach: ENTER
+ata2.00: ata_dev_read_id: ENTER, host 2, dev 0
+ata_exec_command_pio: ata2: cmd 0xEC
+ata_hsm_move: ata2: protocol 2 task_state 1 (dev_stat 0x51)
+ata_hsm_move: ata2: protocol 2 task_state 3 (dev_stat 0x51)
+ata_port_flush_task: ENTER
+ata_port_flush_task: flush #1
+ata2: ata_port_flush_task: flush #2
+ata2: ata_port_flush_task: EXIT
+ata2.00: failed to IDENTIFY (I/O error, err_mask=0x1)
+ata_eh_revalidate_and_attach: EXIT

..

Yep. Libata seems to be treating the ATAPI drive as ATA.

Tejun, don't we have a fallback for when IDENTIFY fails?
If the drive rejects it (err=0x04), then this can mean only one thing:
unsupported command, so we next must try PACKET_IDENTIFY.

The one thing I do know, the machine with the non-working libata cdrom also does not work with the ide driver *ONLY IF* DMA is turned on.

But libata might actually be able to use mdma2 with it, as I believe (unsubstantiated) that Alan may have done a better implementation of setting the timings than what we had with our old IDE drivers.

Quoted 19 lines · Mark Lord

Quoted 17 lines

libata-atapiix renamed from noata +17 -0

+ata_dev_classify: found ATA device by sig
+ata_dev_classify: unknown device
+ata_std_softreset: EXIT, classes[0]=1 [1]=5
+ata_std_postreset: ENTER
+ata_std_postreset: EXIT
+ata_eh_thaw_port: ata2 port thawed
+ata_eh_revalidate_and_attach: ENTER
+ata2.00: ata_dev_read_id: ENTER, host 2, dev 0
+ata_exec_command_pio: ata2: cmd 0xEC
+ata_hsm_move: ata2: protocol 2 task_state 1 (dev_stat 0x51)
+ata_hsm_move: ata2: protocol 2 task_state 3 (dev_stat 0x51)
+ata_port_flush_task: ENTER
+ata_port_flush_task: flush #1
+ata2: ata_port_flush_task: flush #2
+ata2: ata_port_flush_task: EXIT
+ata2.00: failed to IDENTIFY (I/O error, err_mask=0x1)
+ata_eh_revalidate_and_attach: EXIT

..

Quoted 1 line

Yep. Libata seems to be treating the ATAPI drive as ATA.

Quoted 3 lines

Tejun, don't we have a fallback for when IDENTIFY fails?
If the drive rejects it (err=0x04), then this can mean only one thing:
unsupported command, so we next must try PACKET_IDENTIFY.

Is it doing that just for this drive? I use libata on another machine (Dell Dimension 2400) and it finds the cdrom just fine.

The one thing I do know, the machine with the non-working libata cdrom also does not work with the ide driver *ONLY IF* DMA is turned on.

Gee... Two crazy screwed up devices today. What's going on?

Quoted 1 line

Gee... Two crazy screwed up devices today. What's going on?

libata is finally seeing use by non-kernel developers.

Quoted 3 lines · Mark Lord

Quoted 1 line

Gee... Two crazy screwed up devices today. What's going on?

libata is finally seeing use by non-kernel developers.

Amusing but factually incorrect. libata has been shipping in major distros for years, with bazoodles of active users.

Quoted 3 lines · Mark Lord

Quoted 1 line

Gee... Two crazy screwed up devices today. What's going on?

libata is finally seeing use by non-kernel developers.

Amusing but factually incorrect. libata has been shipping in major distros for years, with bazoodles of active users.

Quoted 3 lines

Quoted 3 lines

Tejun, don't we have a fallback for when IDENTIFY fails?
If the drive rejects it (err=0x04), then this can mean only one thing:
unsupported command, so we next must try PACKET_IDENTIFY.

Up until now, we've been depending on the device giving us the correct signature on reset. This is the first reported case which screws that up. Gee... Two crazy screwed up devices today. What's going on?

Quoted 2 lines

Is it doing that just for this drive? I use libata on another machine (Dell Dimension 2400) and it finds the cdrom just fine.

That specific cdrom is crazy. It's telling libata that it's a disk when it apparently isn't.

Quoted 2 lines

The one thing I do know, the machine with the non-working libata cdrom also does not work with the ide driver *ONLY IF* DMA is turned on.

This is probably as Mark explained in the other thread.

Anyways, oh well, it looks like we need fallback mechanism to the other IDENTIFY command after all. Jeff, any ideas or objections?

It seems the world isn't as frank as we thought and some devices lie about who they are. Fallback to the other IDENTIFY if IDENTIFY fails with device error. As this is the strategy used by IDE for a long time, it shouldn't cause too much problem.

Signed-off-by Tejun Heo <[email protected]>

Cc William Thompson <[email protected]>

---
Willam, please verify this fixes your problem. Jeff, after all, we seem to need this. :-(

It seems the world isn't as frank as we thought and some devices lie about who they are. Fallback to the other IDENTIFY if IDENTIFY fails with device error. As this is the strategy used by IDE for a long time, it shouldn't cause too much problem.

Signed-off-by Tejun Heo <[email protected]>

Cc William Thompson <[email protected]>

---
Willam, please verify this fixes your problem. Jeff, after all, we seem to need this. :-(

Quoted 5 lines · Tejun Heo

It seems the world isn't as frank as we thought and some devices lie about who they are. Fallback to the other IDENTIFY if IDENTIFY fails with device error. As this is the strategy used by IDE for a long time, it shouldn't cause too much problem.

Quoted 5 lines

Signed-off-by Tejun Heo <[email protected]>

Cc William Thompson <[email protected]>

---
Willam, please verify this fixes your problem. Jeff, after all, we seem to need this. :-(

Even though you have a different libata-core.c than I, the patch does work!

It seems the world isn't as frank as we thought and some devices lie about who they are. Fallback to the other IDENTIFY if IDENTIFY fails with device error. As this is the strategy used by IDE for a long time, it shouldn't cause too much problem.

Signed-off-by Tejun Heo <[email protected]>

Cc William Thompson <[email protected]>

---
Willam, please verify this fixes your problem. Jeff, after all, we seem to need this. :-(

drivers/ata/libata-core.c +2 -1

index ca67484..f543109 100644
@@ -1652,7 +1652,7 @@ int ata_dev_read_id(struct ata_device *d
 	struct ata_taskfile tf;
 	unsigned int err_mask = 0;
 	const char *reason;
-	int tried_spinup = 0;
+	int may_fallback = 1, tried_spinup = 0;
 	int rc;
 
 	if (ata_msg_ctl(ap))

@@ -1696,11 +1696,30 @@ int ata_dev_read_id(struct ata_device *d
 			return -ENOENT;
 		}
 
+		if (may_fallback && (err_mask == AC_ERR_DEV)) {

It seems the world isn't as frank as we thought and some devices lie about who they are. Fallback to the other IDENTIFY if IDENTIFY is aborted by the device. As this is the strategy used by IDE for a long time, it shouldn't cause too much problem.

Signed-off-by Tejun Heo <[email protected]>

Cc William Thompson <[email protected]>

---
Updated to fallback iff IDENTIFY is aborted by the device.

drivers/ata/libata-core.c int ata_dev_read_id(struct ata_device *d · line 1712

Quoted 4 lines · Tejun Heo

drivers/ata/libata-core.c +4 -0

+            if (class == ATA_DEV_ATA)
+                class = ATA_DEV_ATAPI;
+            else
+                class = ATA_DEV_ATA;

the 'else' branch is obviously redundant

Quoted 8 lines · Jeff Garzik

drivers/ata/libata-core.c int ata_dev_read_id(struct ata_device *d · line 1712

Quoted 4 lines · Tejun Heo

drivers/ata/libata-core.c +4 -0

+            if (class == ATA_DEV_ATA)
+                class = ATA_DEV_ATAPI;
+            else
+                class = ATA_DEV_ATA;

the 'else' branch is obviously redundant

Why? We can also fallback from ATAPI to ATA.

Quoted 11 lines · Tejun Heo

Quoted 8 lines · Jeff Garzik

drivers/ata/libata-core.c int ata_dev_read_id(struct ata_device *d · line 1712

Quoted 4 lines · Tejun Heo

drivers/ata/libata-core.c +4 -0

+            if (class == ATA_DEV_ATA)
+                class = ATA_DEV_ATAPI;
+            else
+                class = ATA_DEV_ATA;

the 'else' branch is obviously redundant

Why? We can also fallback from ATAPI to ATA.

Then did you mean to write..

drivers/ata/libata-core.c +4 -0

+            if (class == ATA_DEV_ATA)
+                class = ATA_DEV_ATAPI;
+            else if (class == ATA_DEV_ATAPI)
+                class = ATA_DEV_ATA;

?

Otherwise, as Jeff mentions, you're doing a redundant assignment in the else branch.

Quoted 2 lines

Otherwise, as Jeff mentions, you're doing a redundant assignment in the else branch.

Hmmm... I'm feeling very dense today. At that point, class is either ATA_DEV_ATA or ATA_DEV_ATAPI. The if-else clause tries to flip between the two.

1. if class == ATA_DEV_ATA, the 'if' test succeeds and "class = ATA_DEV_ATAPI" runs, so it flips correctly.

2. if class == ATA_DEV_ATAPI, the 'if' test fails and "class = ATA_DEV_ATA" runs, so it flips correctly.

What am I missing here? Feel free to scream at me and hammer me into senses. :-)

Quoted 36 lines · Mark Lord

Quoted 33 lines · William Thompson

libata-atapiix renamed from noata +32 -0

+scsi2 : ata_piix
+ata_port_schedule_eh: port EH scheduled
+ata_scsi_error: ENTER
+ata_port_flush_task: ENTER
+ata_port_flush_task: flush #1
+ata2: ata_port_flush_task: flush #2
+ata2: ata_port_flush_task: EXIT
+ata_eh_autopsy: ENTER
+ata_eh_recover: ENTER
+ata_eh_prep_resume: ENTER
+ata_eh_prep_resume: EXIT
+__ata_port_freeze: ata2 port frozen
+ata_std_softreset: ENTER
+ata_std_softreset: about to softreset, devmask=1
+ata_bus_softreset: ata2: bus reset via SRST
+ata_dev_classify: found ATA device by sig
+ata_dev_classify: unknown device
+ata_std_softreset: EXIT, classes[0]=1 [1]=5
+ata_std_postreset: ENTER
+ata_std_postreset: EXIT
+ata_eh_thaw_port: ata2 port thawed
+ata_eh_revalidate_and_attach: ENTER
+ata2.00: ata_dev_read_id: ENTER, host 2, dev 0
+ata_exec_command_pio: ata2: cmd 0xEC
+ata_hsm_move: ata2: protocol 2 task_state 1 (dev_stat 0x51)
+ata_hsm_move: ata2: protocol 2 task_state 3 (dev_stat 0x51)
+ata_port_flush_task: ENTER
+ata_port_flush_task: flush #1
+ata2: ata_port_flush_task: flush #2
+ata2: ata_port_flush_task: EXIT
+ata2.00: failed to IDENTIFY (I/O error, err_mask=0x1)
+ata_eh_revalidate_and_attach: EXIT

..

Quoted 5 lines

Yep. Libata seems to be treating the ATAPI drive as ATA.

Tejun, don't we have a fallback for when IDENTIFY fails?
If the drive rejects it (err=0x04), then this can mean only one thing:
unsupported command, so we next must try PACKET_IDENTIFY.

Is it doing that just for this drive? I use libata on another machine (Dell Dimension 2400) and it finds the cdrom just fine.

The one thing I do know, the machine with the non-working libata cdrom also does not work with the ide driver *ONLY IF* DMA is turned on.

Quoted 2 lines

Quoted 2 lines

Quoted 2 lines

scsi1 : ata_piix
ata2.00: failed to IDENTIFY (I/O error, err_mask=0x1)

The err_mask is AC_ERR_DEV indicating that the device raised aborted the IDENTIFY command. I wonder what's going on.

Can you change "#undef ATA_DEBUG" in include/linux/libata.h to "#define ATA_DEBUG" and report the resulting dmesg? There will be a LOT of messages so you probably want to increase printk buffer size and detach other devices if possible. It would be best if your root device isn't driven by libata so that you can just insert the module and store the resulting dmesg.

Tejun Heo wrote:
..

Quoted 2 lines

Quoted 2 lines

Quoted 2 lines

Quoted 2 lines

scsi1 : ata_piix
ata2.00: failed to IDENTIFY (I/O error, err_mask=0x1)

..

Quoted 9 lines

The err_mask is AC_ERR_DEV indicating that the device raised aborted the IDENTIFY command. I wonder what's going on.

Can you change "#undef ATA_DEBUG" in include/linux/libata.h to "#define ATA_DEBUG" and report the resulting dmesg? There will be a LOT of messages so you probably want to increase printk buffer size and detach other devices if possible. It would be best if your root device isn't driven by libata so that you can just insert the module and store the resulting dmesg.

If the command really was "IDENTIFY", then of course it failed. This is an ATAPI device, and it wants "PACKET_IDENTIFY".

Maybe libata somehow thinks it's ATA rather than ATAPI?

And this is the second one today where it would be very useful to see a tf dump. It's time to add one to that code patch, methinks.

Quoted 2 lines · Mark Lord

And this is the second one today where it would be very useful to see a tf dump. It's time to add one to that code patch, methinks.

Yeah, we have all these fancy ata_msg_() thingies which can be used to provide a lot of debugging info without affecting hot path. We're just too lazy to actually use it. :-( Putting it on my ever growing to-do list.