System fails to connect to iHOS-104 DVD drive with nvidia MCP61 chipset.

On bootup, when trying to attach to a Lite-on iHOS-104 DVD drive, the kernel attempts to establish a connection to the CD drive at a variety of speeds. Ultimately it fails with a "TEST_UNIT_READY failed (err_mask=0x4)" message

****************************************************************
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1063474

****************************************************************
The relevant DMESG output is listed below:

watchtv@teevee:~$ dmesg|grep ata5
[    1.088342] ata5: SATA max UDMA/133 cmd 0x9e0 ctl 0xbe0 bmdma 0xc400
irq 23
[    1.556031] ata5: SATA link up 1.5 Gbps (SStatus 113 SControl 300)
[    1.564134] ata5.00: ATAPI: ATAPI   iHOS104, WL0F, max UDMA/100
[    1.580115] ata5.00: configured for UDMA/100
[    6.580029] ata5.00: qc timeout (cmd 0xa0)
[    6.580036] ata5.00: TEST_UNIT_READY failed (err_mask=0x4)
[    7.048044] ata5: SATA link up 1.5 Gbps (SStatus 113 SControl 300)
[    7.072129] ata5.00: configured for UDMA/100
[   29.856040] ata5.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x6
frozen
[   29.856063] ata5.00: cmd a0/01:00:00:60:00/00:00:00:00:00/a0 tag 0
dma 96 in
[   29.856065] ata5.00: status: { DRDY }
[   29.856071] ata5: hard resetting link
[   29.856073] ata5: nv: skipping hardreset on occupied port
[   30.324070] ata5: SATA link up 1.5 Gbps (SStatus 113 SControl 300)
[   30.348152] ata5.00: configured for UDMA/100
[   35.348125] ata5.00: qc timeout (cmd 0xa0)
[   35.348132] ata5.00: TEST_UNIT_READY failed (err_mask=0x4)
[   35.348139] ata5: hard resetting link
[   35.348141] ata5: nv: skipping hardreset on occupied port
[   35.816115] ata5: SATA link up 1.5 Gbps (SStatus 113 SControl 300)
[   35.840125] ata5.00: configured for UDMA/100
[   36.835824] ata5: EH complete
[   67.840151] ata5: limiting SATA link speed to 1.5 Gbps
[   67.840159] ata5.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x6
frozen
[   67.840178] ata5.00: cmd a0/01:00:00:80:00/00:00:00:00:00/a0 tag 0
dma 16512 in
[   67.840181] ata5.00: status: { DRDY }
[   67.840187] ata5: hard resetting link
[   67.840188] ata5: nv: skipping hardreset on occupied port
[   68.308056] ata5: SATA link up 1.5 Gbps (SStatus 113 SControl 300)
[   68.332176] ata5.00: configured for UDMA/100
[   68.343497] ata5: EH complete
[   75.808054] ata5.00: limiting speed to UDMA/66:PIO4
[   75.808061] ata5.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x6
frozen
[   75.808081] ata5.00: cmd a0/01:00:00:20:00/00:00:00:00:00/a0 tag 0
dma 16416 in
[   75.808084] ata5.00: status: { DRDY }
[   75.808089] ata5: hard resetting link
[   75.808091] ata5: nv: skipping hardreset on occupied port
[   76.276050] ata5: SATA link up 1.5 Gbps (SStatus 113 SControl 300)
[   76.300125] ata5.00: configured for UDMA/66
[   76.307490] ata5: EH complete
[  136.868049] ata5.00: limiting speed to UDMA/33:PIO4
[  136.868058] ata5.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x6
frozen

[  136.868078] ata5.00: cmd a0/01:00:00:20:00/00:00:00:00:00/a0 tag 0
dma 16416 in
[  136.868081] ata5.00: status: { DRDY }
[  136.868087] ata5: hard resetting link
[  136.868089] ata5: nv: skipping hardreset on occupied port
[  137.332073] ata5: SATA link up 1.5 Gbps (SStatus 113 SControl 300)
[  137.356170] ata5.00: configured for UDMA/33
[  137.866272] ata5: EH complete

Quoted 61 lines · Bruce Link

On bootup, when trying to attach to a Lite-on iHOS-104 DVD drive, the kernel attempts to establish a connection to the CD drive at a variety of speeds. Ultimately it fails with a "TEST_UNIT_READY failed (err_mask=0x4)" message

****************************************************************
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1063474

****************************************************************
The relevant DMESG output is listed below:

watchtv@teevee:~$ dmesg|grep ata5
[    1.088342] ata5: SATA max UDMA/133 cmd 0x9e0 ctl 0xbe0 bmdma 0xc400
irq 23
[    1.556031] ata5: SATA link up 1.5 Gbps (SStatus 113 SControl 300)
[    1.564134] ata5.00: ATAPI: ATAPI   iHOS104, WL0F, max UDMA/100
[    1.580115] ata5.00: configured for UDMA/100
[    6.580029] ata5.00: qc timeout (cmd 0xa0)
[    6.580036] ata5.00: TEST_UNIT_READY failed (err_mask=0x4)
[    7.048044] ata5: SATA link up 1.5 Gbps (SStatus 113 SControl 300)
[    7.072129] ata5.00: configured for UDMA/100
[   29.856040] ata5.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x6
frozen
[   29.856063] ata5.00: cmd a0/01:00:00:60:00/00:00:00:00:00/a0 tag 0
dma 96 in
[   29.856065] ata5.00: status: { DRDY }
[   29.856071] ata5: hard resetting link
[   29.856073] ata5: nv: skipping hardreset on occupied port
[   30.324070] ata5: SATA link up 1.5 Gbps (SStatus 113 SControl 300)
[   30.348152] ata5.00: configured for UDMA/100
[   35.348125] ata5.00: qc timeout (cmd 0xa0)
[   35.348132] ata5.00: TEST_UNIT_READY failed (err_mask=0x4)
[   35.348139] ata5: hard resetting link
[   35.348141] ata5: nv: skipping hardreset on occupied port
[   35.816115] ata5: SATA link up 1.5 Gbps (SStatus 113 SControl 300)
[   35.840125] ata5.00: configured for UDMA/100
[   36.835824] ata5: EH complete
[   67.840151] ata5: limiting SATA link speed to 1.5 Gbps
[   67.840159] ata5.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x6
frozen
[   67.840178] ata5.00: cmd a0/01:00:00:80:00/00:00:00:00:00/a0 tag 0
dma 16512 in
[   67.840181] ata5.00: status: { DRDY }
[   67.840187] ata5: hard resetting link
[   67.840188] ata5: nv: skipping hardreset on occupied port
[   68.308056] ata5: SATA link up 1.5 Gbps (SStatus 113 SControl 300)
[   68.332176] ata5.00: configured for UDMA/100
[   68.343497] ata5: EH complete
[   75.808054] ata5.00: limiting speed to UDMA/66:PIO4
[   75.808061] ata5.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x6
frozen
[   75.808081] ata5.00: cmd a0/01:00:00:20:00/00:00:00:00:00/a0 tag 0
dma 16416 in
[   75.808084] ata5.00: status: { DRDY }
[   75.808089] ata5: hard resetting link
[   75.808091] ata5: nv: skipping hardreset on occupied port
[   76.276050] ata5: SATA link up 1.5 Gbps (SStatus 113 SControl 300)
[   76.300125] ata5.00: configured for UDMA/66
[   76.307490] ata5: EH complete
[  136.868049] ata5.00: limiting speed to UDMA/33:PIO4
[  136.868058] ata5.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x6
frozen

Quoted 8 lines

[  136.868078] ata5.00: cmd a0/01:00:00:20:00/00:00:00:00:00/a0 tag 0
dma 16416 in
[  136.868081] ata5.00: status: { DRDY }
[  136.868087] ata5: hard resetting link
[  136.868089] ata5: nv: skipping hardreset on occupied port
[  137.332073] ata5: SATA link up 1.5 Gbps (SStatus 113 SControl 300)
[  137.356170] ata5.00: configured for UDMA/33
[  137.866272] ata5: EH complete

These NVIDIA SATA controllers are a pain as they all seem to have a different set of bugs related to hardreset, etc. What happens if you boot up without the drive connected and then plug in the cable after the system boots up?

Quoted 4 lines

These NVIDIA SATA controllers are a pain as they all seem to have a different set of bugs related to hardreset, etc. What happens if you boot up without the drive connected and then plug in the cable after the system boots up?

Roughly the same error is returned. See below for the dmesg output.

root@teevee:/sys/devices/pci0000:00/0000:00:06.0/ata1/host0/scsi_host/host0# echo "- - -" > /sys/class/scsi_host/host4/scan root@teevee:/sys/devices/pci0000:00/0000:00:06.0/ata1/host0/scsi_host/host0# dmesg|grep ata5

[    1.030224] ata5: SATA max UDMA/133 cmd 0x9e0 ctl 0xbe0 bmdma 0xc400 irq
20
[    1.354216] ata5: SATA link down (SStatus 0 SControl 300)
[  944.773288] ata5: exception Emask 0x10 SAct 0x0 SErr 0x50000 action 0xf
[  944.773304] ata5: SError: { PHYRdyChg CommWake }
[  944.773322] ata5: hard resetting link
[  945.652070] ata5: SATA link up 1.5 Gbps (SStatus 113 SControl 300)
[  945.660176] ata5.00: ATAPI: ATAPI   iHOS104, WL0F, max UDMA/100
[  945.676165] ata5.00: configured for UDMA/100
[  950.676049] ata5.00: qc timeout (cmd 0xa0)
[  950.676056] ata5.00: TEST_UNIT_READY failed (err_mask=0x5)
[  950.676064] ata5: hard resetting link
[  950.676066] ata5: nv: skipping hardreset on occupied port
[  951.144073] ata5: SATA link up 1.5 Gbps (SStatus 113 SControl 300)
[  951.168168] ata5.00: configured for UDMA/100
[  956.168049] ata5.00: qc timeout (cmd 0xa0)
[  956.168057] ata5.00: TEST_UNIT_READY failed (err_mask=0x4)
[  956.168061] ata5: limiting SATA link speed to 1.5 Gbps
[  956.168064] ata5.00: limiting speed to UDMA/100:PIO3
[  956.168070] ata5: hard resetting link
[  956.168072] ata5: nv: skipping hardreset on occupied port
[  956.636056] ata5: SATA link up 1.5 Gbps (SStatus 113 SControl 300)
[  956.660169] ata5.00: configured for UDMA/100
[  961.660036] ata5.00: qc timeout (cmd 0xa0)
[  961.660044] ata5.00: TEST_UNIT_READY failed (err_mask=0x4)
[  961.660046] ata5.00: disabled
[  961.660061] ata5: hard resetting link
[  962.544045] ata5: SATA link up 1.5 Gbps (SStatus 113 SControl 310)
[  962.544061] ata5: EH complete

root@teevee:/sys/devices/pci0000:00/0000:00:06.0/ata1/host0/scsi_host/host0#

Quoted 39 lines · Bruce Link

Quoted 4 lines

These NVIDIA SATA controllers are a pain as they all seem to have a different set of bugs related to hardreset, etc. What happens if you boot up without the drive connected and then plug in the cable after the system boots up?

Roughly the same error is returned. See below for the dmesg output.

root@teevee:/sys/devices/pci0000:00/0000:00:06.0/ata1/host0/scsi_host/host0# echo "- - -" > /sys/class/scsi_host/host4/scan root@teevee:/sys/devices/pci0000:00/0000:00:06.0/ata1/host0/scsi_host/host0# dmesg|grep ata5

[    1.030224] ata5: SATA max UDMA/133 cmd 0x9e0 ctl 0xbe0 bmdma 0xc400 irq
20
[    1.354216] ata5: SATA link down (SStatus 0 SControl 300)
[  944.773288] ata5: exception Emask 0x10 SAct 0x0 SErr 0x50000 action 0xf
[  944.773304] ata5: SError: { PHYRdyChg CommWake }
[  944.773322] ata5: hard resetting link
[  945.652070] ata5: SATA link up 1.5 Gbps (SStatus 113 SControl 300)
[  945.660176] ata5.00: ATAPI: ATAPI   iHOS104, WL0F, max UDMA/100
[  945.676165] ata5.00: configured for UDMA/100
[  950.676049] ata5.00: qc timeout (cmd 0xa0)
[  950.676056] ata5.00: TEST_UNIT_READY failed (err_mask=0x5)
[  950.676064] ata5: hard resetting link
[  950.676066] ata5: nv: skipping hardreset on occupied port
[  951.144073] ata5: SATA link up 1.5 Gbps (SStatus 113 SControl 300)
[  951.168168] ata5.00: configured for UDMA/100
[  956.168049] ata5.00: qc timeout (cmd 0xa0)
[  956.168057] ata5.00: TEST_UNIT_READY failed (err_mask=0x4)
[  956.168061] ata5: limiting SATA link speed to 1.5 Gbps
[  956.168064] ata5.00: limiting speed to UDMA/100:PIO3
[  956.168070] ata5: hard resetting link
[  956.168072] ata5: nv: skipping hardreset on occupied port
[  956.636056] ata5: SATA link up 1.5 Gbps (SStatus 113 SControl 300)
[  956.660169] ata5.00: configured for UDMA/100
[  961.660036] ata5.00: qc timeout (cmd 0xa0)
[  961.660044] ata5.00: TEST_UNIT_READY failed (err_mask=0x4)
[  961.660046] ata5.00: disabled
[  961.660061] ata5: hard resetting link
[  962.544045] ata5: SATA link up 1.5 Gbps (SStatus 113 SControl 310)
[  962.544061] ata5: EH complete

Quoted 2 lines

root@teevee:/sys/devices/pci0000:00/0000:00:06.0/ata1/host0/scsi_host/host0#

Hmm, it did a hard reset on the hotplug with seemingly the same effect. Can we narrow down the problem any more: does this drive work on this machine under any Linux version, or in Windows? Can you try it in another Linux machine with a different controller to see if it works there?

Quoted 45 lines · Robert Hancock

Quoted 41 lines · Bruce Link

Quoted 4 lines

These NVIDIA SATA controllers are a pain as they all seem to have a different set of bugs related to hardreset, etc. What happens if you boot up without the drive connected and then plug in the cable after the system boots up?

Roughly the same error is returned. See below for the dmesg output.

root@teevee:/sys/devices/pci0000:00/0000:00:06.0/ata1/host0/scsi_host/host0#

echo "- - -" > /sys/class/scsi_host/host4/scan root@teevee:/sys/devices/pci0000:00/0000:00:06.0/ata1/host0/scsi_host/host0#

dmesg|grep ata5

[    1.030224] ata5: SATA max UDMA/133 cmd 0x9e0 ctl 0xbe0 bmdma 0xc400 irq
20
[    1.354216] ata5: SATA link down (SStatus 0 SControl 300)
[  944.773288] ata5: exception Emask 0x10 SAct 0x0 SErr 0x50000 action 0xf
[  944.773304] ata5: SError: { PHYRdyChg CommWake }
[  944.773322] ata5: hard resetting link
[  945.652070] ata5: SATA link up 1.5 Gbps (SStatus 113 SControl 300)
[  945.660176] ata5.00: ATAPI: ATAPI   iHOS104, WL0F, max UDMA/100
[  945.676165] ata5.00: configured for UDMA/100
[  950.676049] ata5.00: qc timeout (cmd 0xa0)
[  950.676056] ata5.00: TEST_UNIT_READY failed (err_mask=0x5)
[  950.676064] ata5: hard resetting link
[  950.676066] ata5: nv: skipping hardreset on occupied port
[  951.144073] ata5: SATA link up 1.5 Gbps (SStatus 113 SControl 300)
[  951.168168] ata5.00: configured for UDMA/100
[  956.168049] ata5.00: qc timeout (cmd 0xa0)
[  956.168057] ata5.00: TEST_UNIT_READY failed (err_mask=0x4)
[  956.168061] ata5: limiting SATA link speed to 1.5 Gbps
[  956.168064] ata5.00: limiting speed to UDMA/100:PIO3
[  956.168070] ata5: hard resetting link
[  956.168072] ata5: nv: skipping hardreset on occupied port
[  956.636056] ata5: SATA link up 1.5 Gbps (SStatus 113 SControl 300)
[  956.660169] ata5.00: configured for UDMA/100
[  961.660036] ata5.00: qc timeout (cmd 0xa0)
[  961.660044] ata5.00: TEST_UNIT_READY failed (err_mask=0x4)
[  961.660046] ata5.00: disabled
[  961.660061] ata5: hard resetting link
[  962.544045] ata5: SATA link up 1.5 Gbps (SStatus 113 SControl 310)
[  962.544061] ata5: EH complete

Quoted 3 lines

root@teevee:/sys/devices/pci0000:00/0000:00:06.0/ata1/host0/scsi_host/host0#

Quoted 5 lines

Hmm, it did a hard reset on the hotplug with seemingly the same effect. Can we narrow down the problem any more: does this drive work on this machine under any Linux version, or in Windows? Can you try it in another Linux machine with a different controller to see if it works there?

Well, this is embarrassing.

I've always assumed the problem was with the with the motherboard, as the DVD will always successfully boot a windows installer, so I assumed everything with the drive was OK. On further inspection, it appears that the drive falls down when being accessed from the WinPE environment, much the same as in linux. I've tested this on another PC and the result looks to be the same. I'm going to do some more testing, and will send another email if I find out otherwise. But I think we can consider this closed.

Sorry to be a bother.
Bruce

Quoted 69 lines · Bruce Link

Quoted 49 lines · Robert Hancock

Quoted 47 lines · Bruce Link

Quoted 6 lines

These NVIDIA SATA controllers are a pain as they all seem to have a different set of bugs related to hardreset, etc. What happens if you boot up
without the drive connected and then plug in the cable after the system boots up?

Roughly the same error is returned. See below for the dmesg output.

root@teevee:/sys/devices/pci0000:00/0000:00:06.0/ata1/host0/scsi_host/host0# echo "- - -" > /sys/class/scsi_host/host4/scan

root@teevee:/sys/devices/pci0000:00/0000:00:06.0/ata1/host0/scsi_host/host0# dmesg|grep ata5

[    1.030224] ata5: SATA max UDMA/133 cmd 0x9e0 ctl 0xbe0 bmdma 0xc400
irq
20
[    1.354216] ata5: SATA link down (SStatus 0 SControl 300)
[  944.773288] ata5: exception Emask 0x10 SAct 0x0 SErr 0x50000 action
0xf
[  944.773304] ata5: SError: { PHYRdyChg CommWake }
[  944.773322] ata5: hard resetting link
[  945.652070] ata5: SATA link up 1.5 Gbps (SStatus 113 SControl 300)
[  945.660176] ata5.00: ATAPI: ATAPI   iHOS104, WL0F, max UDMA/100
[  945.676165] ata5.00: configured for UDMA/100
[  950.676049] ata5.00: qc timeout (cmd 0xa0)
[  950.676056] ata5.00: TEST_UNIT_READY failed (err_mask=0x5)
[  950.676064] ata5: hard resetting link
[  950.676066] ata5: nv: skipping hardreset on occupied port
[  951.144073] ata5: SATA link up 1.5 Gbps (SStatus 113 SControl 300)
[  951.168168] ata5.00: configured for UDMA/100
[  956.168049] ata5.00: qc timeout (cmd 0xa0)
[  956.168057] ata5.00: TEST_UNIT_READY failed (err_mask=0x4)
[  956.168061] ata5: limiting SATA link speed to 1.5 Gbps
[  956.168064] ata5.00: limiting speed to UDMA/100:PIO3
[  956.168070] ata5: hard resetting link
[  956.168072] ata5: nv: skipping hardreset on occupied port
[  956.636056] ata5: SATA link up 1.5 Gbps (SStatus 113 SControl 300)
[  956.660169] ata5.00: configured for UDMA/100
[  961.660036] ata5.00: qc timeout (cmd 0xa0)
[  961.660044] ata5.00: TEST_UNIT_READY failed (err_mask=0x4)
[  961.660046] ata5.00: disabled
[  961.660061] ata5: hard resetting link
[  962.544045] ata5: SATA link up 1.5 Gbps (SStatus 113 SControl 310)
[  962.544061] ata5: EH complete

Quoted 7 lines

Quoted 2 lines

root@teevee:/sys/devices/pci0000:00/0000:00:06.0/ata1/host0/scsi_host/host0#

Hmm, it did a hard reset on the hotplug with seemingly the same effect. Can we narrow down the problem any more: does this drive work on this machine under any Linux version, or in Windows? Can you try it in another Linux machine with a different controller to see if it works there?

Well, this is embarrassing.

I've always assumed the problem was with the with the motherboard, as the DVD will always successfully boot a windows installer, so I assumed everything with the drive was OK. On further inspection, it appears that the drive falls down when being accessed from the WinPE environment, much the same as in linux. I've tested this on another PC and the result looks to be the same. I'm going to do some more testing, and will send another email if I find out otherwise. But I think we can consider this closed.

Quoted 2 lines

Sorry to be a bother.
Bruce

I hooked up the DVD drive to a USB-SATA adapter to a PC and the DVD drive works great (under both windows and linux). I was able to copy a large number of files with no performance issues.
The PC that I did the second test on turns out to have a nVidia MCP51 chipset (It's a gateway GT4016 with a KTBC51G-LF motherboard). I should have checked this beforehand.

So this problem looks to persist across different nVidia chipsets.

Quoted 74 lines · Bruce Link

Quoted 64 lines · Bruce Link

Quoted 46 lines · Robert Hancock

Quoted 45 lines · Bruce Link

Quoted 5 lines

These NVIDIA SATA controllers are a pain as they all seem to have a different set of bugs related to hardreset, etc. What happens if you boot up
without the drive connected and then plug in the cable after the system boots up?

Roughly the same error is returned. See below for the dmesg output.

root@teevee:/sys/devices/pci0000:00/0000:00:06.0/ata1/host0/scsi_host/host0# echo "- - -" > /sys/class/scsi_host/host4/scan

root@teevee:/sys/devices/pci0000:00/0000:00:06.0/ata1/host0/scsi_host/host0# dmesg|grep ata5

[    1.030224] ata5: SATA max UDMA/133 cmd 0x9e0 ctl 0xbe0 bmdma 0xc400
irq
20
[    1.354216] ata5: SATA link down (SStatus 0 SControl 300)
[  944.773288] ata5: exception Emask 0x10 SAct 0x0 SErr 0x50000 action
0xf
[  944.773304] ata5: SError: { PHYRdyChg CommWake }
[  944.773322] ata5: hard resetting link
[  945.652070] ata5: SATA link up 1.5 Gbps (SStatus 113 SControl 300)
[  945.660176] ata5.00: ATAPI: ATAPI   iHOS104, WL0F, max UDMA/100
[  945.676165] ata5.00: configured for UDMA/100
[  950.676049] ata5.00: qc timeout (cmd 0xa0)
[  950.676056] ata5.00: TEST_UNIT_READY failed (err_mask=0x5)
[  950.676064] ata5: hard resetting link
[  950.676066] ata5: nv: skipping hardreset on occupied port
[  951.144073] ata5: SATA link up 1.5 Gbps (SStatus 113 SControl 300)
[  951.168168] ata5.00: configured for UDMA/100
[  956.168049] ata5.00: qc timeout (cmd 0xa0)
[  956.168057] ata5.00: TEST_UNIT_READY failed (err_mask=0x4)
[  956.168061] ata5: limiting SATA link speed to 1.5 Gbps
[  956.168064] ata5.00: limiting speed to UDMA/100:PIO3
[  956.168070] ata5: hard resetting link
[  956.168072] ata5: nv: skipping hardreset on occupied port
[  956.636056] ata5: SATA link up 1.5 Gbps (SStatus 113 SControl 300)
[  956.660169] ata5.00: configured for UDMA/100
[  961.660036] ata5.00: qc timeout (cmd 0xa0)
[  961.660044] ata5.00: TEST_UNIT_READY failed (err_mask=0x4)
[  961.660046] ata5.00: disabled
[  961.660061] ata5: hard resetting link
[  962.544045] ata5: SATA link up 1.5 Gbps (SStatus 113 SControl 310)
[  962.544061] ata5: EH complete

Quoted 7 lines

Quoted 2 lines

root@teevee:/sys/devices/pci0000:00/0000:00:06.0/ata1/host0/scsi_host/host0#

Hmm, it did a hard reset on the hotplug with seemingly the same effect. Can we narrow down the problem any more: does this drive work on this machine under any Linux version, or in Windows? Can you try it in another Linux machine with a different controller to see if it works there?

Well, this is embarrassing.

I've always assumed the problem was with the with the motherboard, as the DVD will always successfully boot a windows installer, so I assumed everything with the drive was OK. On further inspection, it appears that the drive falls down when being accessed from the WinPE environment, much the same as in linux. I've tested this on another PC and the result looks to be the same. I'm going to do some more testing, and will send another email if I find out otherwise. But I think we can consider this closed.

Quoted 2 lines

Sorry to be a bother.
Bruce

I hooked up the DVD drive to a USB-SATA adapter to a PC and the DVD drive works great (under both windows and linux). I was able to copy a large number of files with no performance issues.
The PC that I did the second test on turns out to have a nVidia MCP51 chipset (It's a gateway GT4016 with a KTBC51G-LF motherboard). I should have checked this beforehand.

Quoted 1 line

So this problem looks to persist across different nVidia chipsets.

Given that it fails in Windows as well on those machines, it sounds like there's some kind of compatibility issue between this drive and the NV chipsets. I don't know why their SATA chipsets (at least the pre-AHCI ones) have some many issues, but they do seem to.

Quoted 92 lines · Robert Hancock

Quoted 89 lines · Bruce Link

Quoted 74 lines · Bruce Link

Quoted 69 lines · Robert Hancock

Quoted 49 lines · Bruce Link

Quoted 47 lines

Quoted 6 lines

These NVIDIA SATA controllers are a pain as they all seem to have a different set of bugs related to hardreset, etc. What happens if you boot up
without the drive connected and then plug in the cable after the system boots up?

Roughly the same error is returned. See below for the dmesg output.

root@teevee:/sys/devices/pci0000:00/0000:00:06.0/ata1/host0/scsi_host/host0# echo "- - -" > /sys/class/scsi_host/host4/scan

root@teevee:/sys/devices/pci0000:00/0000:00:06.0/ata1/host0/scsi_host/host0# dmesg|grep ata5

[    1.030224] ata5: SATA max UDMA/133 cmd 0x9e0 ctl 0xbe0 bmdma 0xc400
irq
20
[    1.354216] ata5: SATA link down (SStatus 0 SControl 300)
[  944.773288] ata5: exception Emask 0x10 SAct 0x0 SErr 0x50000 action
0xf
[  944.773304] ata5: SError: { PHYRdyChg CommWake }
[  944.773322] ata5: hard resetting link
[  945.652070] ata5: SATA link up 1.5 Gbps (SStatus 113 SControl 300)
[  945.660176] ata5.00: ATAPI: ATAPI   iHOS104, WL0F, max UDMA/100
[  945.676165] ata5.00: configured for UDMA/100
[  950.676049] ata5.00: qc timeout (cmd 0xa0)
[  950.676056] ata5.00: TEST_UNIT_READY failed (err_mask=0x5)
[  950.676064] ata5: hard resetting link
[  950.676066] ata5: nv: skipping hardreset on occupied port
[  951.144073] ata5: SATA link up 1.5 Gbps (SStatus 113 SControl 300)
[  951.168168] ata5.00: configured for UDMA/100
[  956.168049] ata5.00: qc timeout (cmd 0xa0)
[  956.168057] ata5.00: TEST_UNIT_READY failed (err_mask=0x4)
[  956.168061] ata5: limiting SATA link speed to 1.5 Gbps
[  956.168064] ata5.00: limiting speed to UDMA/100:PIO3
[  956.168070] ata5: hard resetting link
[  956.168072] ata5: nv: skipping hardreset on occupied port
[  956.636056] ata5: SATA link up 1.5 Gbps (SStatus 113 SControl 300)
[  956.660169] ata5.00: configured for UDMA/100
[  961.660036] ata5.00: qc timeout (cmd 0xa0)
[  961.660044] ata5.00: TEST_UNIT_READY failed (err_mask=0x4)
[  961.660046] ata5.00: disabled
[  961.660061] ata5: hard resetting link
[  962.544045] ata5: SATA link up 1.5 Gbps (SStatus 113 SControl 310)
[  962.544061] ata5: EH complete

Quoted 7 lines

Quoted 2 lines

root@teevee:/sys/devices/pci0000:00/0000:00:06.0/ata1/host0/scsi_host/host0#

Hmm, it did a hard reset on the hotplug with seemingly the same effect. Can we narrow down the problem any more: does this drive work on this machine under any Linux version, or in Windows? Can you try it in another Linux machine with a different controller to see if it works there?

Well, this is embarrassing.

I've always assumed the problem was with the with the motherboard, as the DVD will always successfully boot a windows installer, so I assumed everything with the drive was OK. On further inspection, it appears that the drive falls down when being accessed from the WinPE environment, much the same as in linux. I've tested this on another PC and the result looks to be the same. I'm going to do some more testing, and will send another email if I find out otherwise. But I think we can consider this closed.

Quoted 2 lines

Sorry to be a bother.
Bruce

Quoted 8 lines

I hooked up the DVD drive to a USB-SATA adapter to a PC and the DVD drive works great (under both windows and linux). I was able to copy a large number of files with no performance issues.
The PC that I did the second test on turns out to have a nVidia MCP51 chipset (It's a gateway GT4016 with a KTBC51G-LF motherboard). I should have checked this beforehand.

So this problem looks to persist across different nVidia chipsets.

Given that it fails in Windows as well on those machines, it sounds like there's some kind of compatibility issue between this drive and the NV chipsets. I don't know why their SATA chipsets (at least the pre-AHCI ones) have some many issues, but they do seem to.

Quoted 5 lines

I've located a spare HDD and loaded Windows 7 on it. In Windows 7 (not WinPE), I am able to successfully use the BD-ROM drive on both computers (MCP61 and MCP51 chipsets). So it appears there is a difference in the drivers between the Windows 7 and WinPE driver. News to me.

I believe this rules out a general hardware incompatibility.

What further can I do?

Quoted 85 lines · Bruce Link

Quoted 85 lines · Robert Hancock

Quoted 75 lines · Bruce Link

Quoted 74 lines · Bruce Link

Quoted 64 lines · Robert Hancock

Quoted 46 lines · Bruce Link

Quoted 45 lines

Quoted 5 lines

These NVIDIA SATA controllers are a pain as they all seem to have a different set of bugs related to hardreset, etc. What happens if you boot up
without the drive connected and then plug in the cable after the system boots up?

Roughly the same error is returned. See below for the dmesg output.

root@teevee:/sys/devices/pci0000:00/0000:00:06.0/ata1/host0/scsi_host/host0# echo "- - -" > /sys/class/scsi_host/host4/scan

root@teevee:/sys/devices/pci0000:00/0000:00:06.0/ata1/host0/scsi_host/host0# dmesg|grep ata5

[    1.030224] ata5: SATA max UDMA/133 cmd 0x9e0 ctl 0xbe0 bmdma 0xc400
irq
20
[    1.354216] ata5: SATA link down (SStatus 0 SControl 300)
[  944.773288] ata5: exception Emask 0x10 SAct 0x0 SErr 0x50000 action
0xf
[  944.773304] ata5: SError: { PHYRdyChg CommWake }
[  944.773322] ata5: hard resetting link
[  945.652070] ata5: SATA link up 1.5 Gbps (SStatus 113 SControl 300)
[  945.660176] ata5.00: ATAPI: ATAPI   iHOS104, WL0F, max UDMA/100
[  945.676165] ata5.00: configured for UDMA/100
[  950.676049] ata5.00: qc timeout (cmd 0xa0)
[  950.676056] ata5.00: TEST_UNIT_READY failed (err_mask=0x5)
[  950.676064] ata5: hard resetting link
[  950.676066] ata5: nv: skipping hardreset on occupied port
[  951.144073] ata5: SATA link up 1.5 Gbps (SStatus 113 SControl 300)
[  951.168168] ata5.00: configured for UDMA/100
[  956.168049] ata5.00: qc timeout (cmd 0xa0)
[  956.168057] ata5.00: TEST_UNIT_READY failed (err_mask=0x4)
[  956.168061] ata5: limiting SATA link speed to 1.5 Gbps
[  956.168064] ata5.00: limiting speed to UDMA/100:PIO3
[  956.168070] ata5: hard resetting link
[  956.168072] ata5: nv: skipping hardreset on occupied port
[  956.636056] ata5: SATA link up 1.5 Gbps (SStatus 113 SControl 300)
[  956.660169] ata5.00: configured for UDMA/100
[  961.660036] ata5.00: qc timeout (cmd 0xa0)
[  961.660044] ata5.00: TEST_UNIT_READY failed (err_mask=0x4)
[  961.660046] ata5.00: disabled
[  961.660061] ata5: hard resetting link
[  962.544045] ata5: SATA link up 1.5 Gbps (SStatus 113 SControl 310)
[  962.544061] ata5: EH complete

Quoted 7 lines

Quoted 2 lines

root@teevee:/sys/devices/pci0000:00/0000:00:06.0/ata1/host0/scsi_host/host0#

Hmm, it did a hard reset on the hotplug with seemingly the same effect. Can we narrow down the problem any more: does this drive work on this machine under any Linux version, or in Windows? Can you try it in another Linux machine with a different controller to see if it works there?

Well, this is embarrassing.

I've always assumed the problem was with the with the motherboard, as the DVD will always successfully boot a windows installer, so I assumed everything with the drive was OK. On further inspection, it appears that the drive falls down when being accessed from the WinPE environment, much the same as in linux. I've tested this on another PC and the result looks to be the same. I'm going to do some more testing, and will send another email if I find out otherwise. But I think we can consider this closed.

Quoted 2 lines

Sorry to be a bother.
Bruce

I hooked up the DVD drive to a USB-SATA adapter to a PC and the DVD drive works great (under both windows and linux). I was able to copy a large number of files with no performance issues.
The PC that I did the second test on turns out to have a nVidia MCP51 chipset (It's a gateway GT4016 with a KTBC51G-LF motherboard). I should have checked this beforehand.

Quoted 5 lines

Quoted 1 line

So this problem looks to persist across different nVidia chipsets.

Given that it fails in Windows as well on those machines, it sounds like there's some kind of compatibility issue between this drive and the NV chipsets. I don't know why their SATA chipsets (at least the pre-AHCI ones) have some many issues, but they do seem to.

I've located a spare HDD and loaded Windows 7 on it. In Windows 7 (not WinPE), I am able to successfully use the BD-ROM drive on both computers (MCP61 and MCP51 chipsets). So it appears there is a difference in the drivers between the Windows 7 and WinPE driver. News to me.

I believe this rules out a general hardware incompatibility.

Quoted 1 line

Quoted 1 line

What further can I do?

(Forgot to CC the list previously)

It would likely help to confirm whether the driver that was working was provided by NVIDIA (which may be the case even if the driver was automatically installed by Windows setup) or was a default Microsoft one. If it's using an NVIDIA driver then it's quite likely they're somehow working around whatever problem we're running into.

Quoted 89 lines · Robert Hancock

Quoted 88 lines · Bruce Link

Quoted 88 lines · Robert Hancock

Quoted 78 lines · Bruce Link

Quoted 77 lines · Bruce Link

Quoted 67 lines · Robert Hancock

Quoted 48 lines · Bruce Link

Quoted 47 lines

Quoted 5 lines

These NVIDIA SATA controllers are a pain as they all seem to have a different set of bugs related to hardreset, etc. What happens if you boot up
without the drive connected and then plug in the cable after the system boots up?

Roughly the same error is returned. See below for the dmesg output.

root@teevee:/sys/devices/pci0000:00/0000:00:06.0/ata1/host0/scsi_host/host0#

echo "- - -" > /sys/class/scsi_host/host4/scan

root@teevee:/sys/devices/pci0000:00/0000:00:06.0/ata1/host0/scsi_host/host0#

dmesg|grep ata5

[    1.030224] ata5: SATA max UDMA/133 cmd 0x9e0 ctl 0xbe0 bmdma 0xc400
irq
20
[    1.354216] ata5: SATA link down (SStatus 0 SControl 300)
[  944.773288] ata5: exception Emask 0x10 SAct 0x0 SErr 0x50000 action
0xf
[  944.773304] ata5: SError: { PHYRdyChg CommWake }
[  944.773322] ata5: hard resetting link
[  945.652070] ata5: SATA link up 1.5 Gbps (SStatus 113 SControl 300)
[  945.660176] ata5.00: ATAPI: ATAPI   iHOS104, WL0F, max UDMA/100
[  945.676165] ata5.00: configured for UDMA/100
[  950.676049] ata5.00: qc timeout (cmd 0xa0)
[  950.676056] ata5.00: TEST_UNIT_READY failed (err_mask=0x5)
[  950.676064] ata5: hard resetting link
[  950.676066] ata5: nv: skipping hardreset on occupied port
[  951.144073] ata5: SATA link up 1.5 Gbps (SStatus 113 SControl 300)
[  951.168168] ata5.00: configured for UDMA/100
[  956.168049] ata5.00: qc timeout (cmd 0xa0)
[  956.168057] ata5.00: TEST_UNIT_READY failed (err_mask=0x4)
[  956.168061] ata5: limiting SATA link speed to 1.5 Gbps
[  956.168064] ata5.00: limiting speed to UDMA/100:PIO3
[  956.168070] ata5: hard resetting link
[  956.168072] ata5: nv: skipping hardreset on occupied port
[  956.636056] ata5: SATA link up 1.5 Gbps (SStatus 113 SControl 300)
[  956.660169] ata5.00: configured for UDMA/100
[  961.660036] ata5.00: qc timeout (cmd 0xa0)
[  961.660044] ata5.00: TEST_UNIT_READY failed (err_mask=0x4)
[  961.660046] ata5.00: disabled
[  961.660061] ata5: hard resetting link
[  962.544045] ata5: SATA link up 1.5 Gbps (SStatus 113 SControl 310)
[  962.544061] ata5: EH complete

Quoted 8 lines

Quoted 3 lines

root@teevee:/sys/devices/pci0000:00/0000:00:06.0/ata1/host0/scsi_host/host0#

Hmm, it did a hard reset on the hotplug with seemingly the same effect. Can we narrow down the problem any more: does this drive work on this machine under any Linux version, or in Windows? Can you try it in another Linux machine with a different controller to see if it works there?

Well, this is embarrassing.

I've always assumed the problem was with the with the motherboard, as the DVD will always successfully boot a windows installer, so I assumed everything with the drive was OK. On further inspection, it appears that the drive falls down when being accessed from the WinPE environment, much the same as in linux. I've tested this on another PC and the result looks to be the same. I'm going to do some more testing, and will send another email if I find out otherwise. But I think we can consider this closed.

Quoted 2 lines

Sorry to be a bother.
Bruce

I hooked up the DVD drive to a USB-SATA adapter to a PC and the DVD drive works great (under both windows and linux). I was able to copy a large number of files with no performance issues.
The PC that I did the second test on turns out to have a nVidia MCP51 chipset (It's a gateway GT4016 with a KTBC51G-LF motherboard). I should have checked this beforehand.

Quoted 5 lines

Quoted 1 line

So this problem looks to persist across different nVidia chipsets.

Given that it fails in Windows as well on those machines, it sounds like there's some kind of compatibility issue between this drive and the NV chipsets. I don't know why their SATA chipsets (at least the pre-AHCI ones) have some many issues, but they do seem to.

I've located a spare HDD and loaded Windows 7 on it. In Windows 7 (not WinPE), I am able to successfully use the BD-ROM drive on both computers (MCP61 and MCP51 chipsets). So it appears there is a difference in the drivers between the Windows 7 and WinPE driver. News to me.

I believe this rules out a general hardware incompatibility.

Quoted 8 lines

Quoted 1 line

Quoted 1 line

What further can I do?

(Forgot to CC the list previously)

It would likely help to confirm whether the driver that was working was provided by NVIDIA (which may be the case even if the driver was automatically installed by Windows setup) or was a default Microsoft one. If it's using an NVIDIA driver then it's quite likely they're somehow working around whatever problem we're running into.

The driver information as supplied by windows is:
filename: nvstor.sys
Provider: NVIDIA Corporation
File Version: 10.6.0.18 (NT.091202-1659)

Quoted 136 lines · Bruce Link

Quoted 133 lines · Robert Hancock

Quoted 115 lines · Bruce Link

Quoted 115 lines · Robert Hancock

Quoted 112 lines · Bruce Link

Quoted 104 lines · Bruce Link

Quoted 89 lines · Robert Hancock

Quoted 64 lines · Bruce Link

Quoted 60 lines

Quoted 9 lines

These NVIDIA SATA controllers are a pain as they all seem to have a
different set of bugs related to hardreset, etc. What happens if you
boot up
without the drive connected and then plug in the cable after the system
boots up?

Roughly the same error is returned. See below for the dmesg output.

root@teevee:/sys/devices/pci0000:00/0000:00:06.0/ata1/host0/scsi_host/host0# echo "- - -" > /sys/class/scsi_host/host4/scan

root@teevee:/sys/devices/pci0000:00/0000:00:06.0/ata1/host0/scsi_host/host0# dmesg|grep ata5

[    1.030224] ata5: SATA max UDMA/133 cmd 0x9e0 ctl 0xbe0 bmdma
0xc400
irq
20
[    1.354216] ata5: SATA link down (SStatus 0 SControl 300)
[  944.773288] ata5: exception Emask 0x10 SAct 0x0 SErr 0x50000
action
0xf
[  944.773304] ata5: SError: { PHYRdyChg CommWake }
[  944.773322] ata5: hard resetting link
[  945.652070] ata5: SATA link up 1.5 Gbps (SStatus 113 SControl
300)
[  945.660176] ata5.00: ATAPI: ATAPI   iHOS104, WL0F, max UDMA/100
[  945.676165] ata5.00: configured for UDMA/100
[  950.676049] ata5.00: qc timeout (cmd 0xa0)
[  950.676056] ata5.00: TEST_UNIT_READY failed (err_mask=0x5)
[  950.676064] ata5: hard resetting link
[  950.676066] ata5: nv: skipping hardreset on occupied port
[  951.144073] ata5: SATA link up 1.5 Gbps (SStatus 113 SControl
300)
[  951.168168] ata5.00: configured for UDMA/100
[  956.168049] ata5.00: qc timeout (cmd 0xa0)
[  956.168057] ata5.00: TEST_UNIT_READY failed (err_mask=0x4)
[  956.168061] ata5: limiting SATA link speed to 1.5 Gbps
[  956.168064] ata5.00: limiting speed to UDMA/100:PIO3
[  956.168070] ata5: hard resetting link
[  956.168072] ata5: nv: skipping hardreset on occupied port
[  956.636056] ata5: SATA link up 1.5 Gbps (SStatus 113 SControl
300)
[  956.660169] ata5.00: configured for UDMA/100
[  961.660036] ata5.00: qc timeout (cmd 0xa0)
[  961.660044] ata5.00: TEST_UNIT_READY failed (err_mask=0x4)
[  961.660046] ata5.00: disabled
[  961.660061] ata5: hard resetting link
[  962.544045] ata5: SATA link up 1.5 Gbps (SStatus 113 SControl
310)
[  962.544061] ata5: EH complete

Quoted 2 lines

root@teevee:/sys/devices/pci0000:00/0000:00:06.0/ata1/host0/scsi_host/host0#

Quoted 7 lines

Hmm, it did a hard reset on the hotplug with seemingly the same effect. Can we narrow down the problem any more: does this drive work
on this machine under any Linux version, or in Windows? Can you try it
in another Linux machine with a different controller to see if it works there?

Well, this is embarrassing.

I've always assumed the problem was with the with the motherboard, as the
DVD will always successfully boot a windows installer, so I assumed everything with the drive was OK. On further inspection, it appears that the
drive falls down when being accessed from the WinPE environment, much the
same as in linux. I've tested this on another PC and the result looks to be
the same. I'm going to do some more testing, and will send another email if
I find out otherwise. But I think we can consider this closed.

Quoted 2 lines

Sorry to be a bother.
Bruce

I hooked up the DVD drive to a USB-SATA adapter to a PC and the DVD drive
works great (under both windows and linux). I was able to copy a large
number of files with no performance issues.
The PC that I did the second test on turns out to have a nVidia MCP51 chipset (It's a gateway GT4016 with a KTBC51G-LF motherboard). I should have
checked this beforehand.

Quoted 1 line

So this problem looks to persist across different nVidia chipsets.

Given that it fails in Windows as well on those machines, it sounds like there's some kind of compatibility issue between this drive and the NV chipsets. I don't know why their SATA chipsets (at least the pre-AHCI ones) have some many issues, but they do seem to.

Quoted 8 lines

Quoted 8 lines

I've located a spare HDD and loaded Windows 7 on it. In Windows 7 (not WinPE), I am able to successfully use the BD-ROM drive on both computers (MCP61 and MCP51 chipsets). So it appears there is a difference in the drivers between the Windows 7 and WinPE driver. News to me.

I believe this rules out a general hardware incompatibility.

What further can I do?

(Forgot to CC the list previously)

It would likely help to confirm whether the driver that was working was provided by NVIDIA (which may be the case even if the driver was automatically installed by Windows setup) or was a default Microsoft one. If it's using an NVIDIA driver then it's quite likely they're somehow working around whatever problem we're running into.

Quoted 4 lines

The driver information as supplied by windows is:
filename: nvstor.sys
Provider: NVIDIA Corporation
File Version: 10.6.0.18 (NT.091202-1659)

Robert,

Is there any more information I can supply that would be helpful?

Quoted 1 line

Is there any more information I can supply that would be helpful?

I'm not quite sure what the next step would be. It's quite possible that the NVIDIA driver in Windows is doing some magic to work around the problem that we don't know about, but it's hard to say what that might be. The fact that the default drivers used in the WinPE boot don't seem to work would tend to point toward some kind of hardware incompatibility issue.

Tejun, think you poked with some of this stuff before - any ideas?

Hello,

Quoted 10 lines · Robert Hancock

Quoted 1 line

Is there any more information I can supply that would be helpful?

I'm not quite sure what the next step would be. It's quite possible that the NVIDIA driver in Windows is doing some magic to work around the problem that we don't know about, but it's hard to say what that might be. The fact that the default drivers used in the WinPE boot don't seem to work would tend to point toward some kind of hardware incompatibility issue.

Tejun, think you poked with some of this stuff before - any ideas?

It has been years since I looked at MCP quirks, of which there are too many. It's likely another quirk on the controller side that nvidia worked around somehow without telling anyone. Given the history and that nvidia is out of chipset market, I think it's highly unlikely to learn what the issue and workaround are without reverse engineering it. So, um, no idea.

Thanks.

Signature · 2 lines

tejun
--

Quoted 21 lines

Hello,

Quoted 10 lines · Robert Hancock

Quoted 1 line

Is there any more information I can supply that would be helpful?

I'm not quite sure what the next step would be. It's quite possible that the NVIDIA driver in Windows is doing some magic to work around the problem that we don't know about, but it's hard to say what that might be. The fact that the default drivers used in the WinPE boot don't seem to work would tend to point toward some kind of hardware incompatibility issue.

Tejun, think you poked with some of this stuff before - any ideas?

It has been years since I looked at MCP quirks, of which there are too many. It's likely another quirk on the controller side that nvidia worked around somehow without telling anyone. Given the history and that nvidia is out of chipset market, I think it's highly unlikely to learn what the issue and workaround are without reverse engineering it. So, um, no idea.

Quoted 5 lines

Thanks.

--
tejun
--

Robert,

I've inquired about this problem with Allen Martin at Nvidia, he had the following reply:

/--------SNIP---------------/
Hi Bruce, I did work on the Windows SATA driver for those chipsets, so I’m familiar with it. I’m not aware of any of any timing workarounds for any devices in the driver, but it’s certainly true that there are devices that have timing sensitivity, especially around the IDENTIFY command and it may inadvertently work with one driver and not another.

From the bug reports it looks like it’s always timing out on a TEST_UNIT_READY command? I assume this is probably the first command sent down after IDENTIFY to check for presense of a CD in the drive? If so it’s likely the drive is locked up and any command at that point will fail. If you want to test out the theory about it being a timing issue, I would stick some udelay()s in the identify code path, both before and after starting the transfer to see if it makes any difference. Also do you know if the driver does a PHY reset when it resets the link? If not, you can try doing that by writing a 0 to SControl and then restoring it with the original value.

Hope this helps,

-Allen
/--------SNIP---------------/

Does this provide any actionable information? I've tried searching for the proper location to impliment these delays in the sata_nv.c and libata-eh.c files but admittedly, am in over my head.

Quoted 47 lines · Bruce Link

Quoted 19 lines

Hello,

Quoted 9 lines · Robert Hancock

Quoted 1 line

Is there any more information I can supply that would be helpful?

I'm not quite sure what the next step would be. It's quite possible that the NVIDIA driver in Windows is doing some magic to work around the problem that we don't know about, but it's hard to say what that might be. The fact that the default drivers used in the WinPE boot don't seem to work would tend to point toward some kind of hardware incompatibility issue.

Tejun, think you poked with some of this stuff before - any ideas?

It has been years since I looked at MCP quirks, of which there are too many. It's likely another quirk on the controller side that nvidia worked around somehow without telling anyone. Given the history and that nvidia is out of chipset market, I think it's highly unlikely to learn what the issue and workaround are without reverse engineering it. So, um, no idea.

Quoted 5 lines

Thanks.

--
tejun
--

Robert,

I've inquired about this problem with Allen Martin at Nvidia, he had the following reply:

/--------SNIP---------------/
Hi Bruce, I did work on the Windows SATA driver for those chipsets, so I’m familiar with it. I’m not aware of any of any timing workarounds for any devices in the driver, but it’s certainly true that there are devices that have timing sensitivity, especially around the IDENTIFY command and it may inadvertently work with one driver and not another.

From the bug reports it looks like it’s always timing out on a
TEST_UNIT_READY command? I assume this is probably the first command sent down after IDENTIFY to check for presense of a CD in the drive? If so it’s likely the drive is locked up and any command at that point will fail. If you want to test out the theory about it being a timing issue, I would stick some udelay()s in the identify code path, both before and after starting the transfer to see if it makes any difference. Also do you know if the driver does a PHY reset when it resets the link? If not, you can try doing that by writing a 0 to SControl and then restoring it with the original value.

Quoted 8 lines

Hope this helps,

-Allen
/--------SNIP---------------/

Does this provide any actionable information? I've tried searching for the proper location to impliment these delays in the sata_nv.c and libata-eh.c files but admittedly, am in over my head.

Don't think there's any earth-shaking revelations but it might be a few things to try. First, though, apparently there is a firmware update for this drive of at least one revision up (WL0G) available from Lite-ON that you could try updating to. (You'll likely need to use Windows for that.) Given that it seems broken in at least two different environments on this controller, it's possible they fixed something related in the drive.

Quoted 56 lines · Robert Hancock

Quoted 47 lines · Bruce Link

Quoted 12 lines

Hello,

Quoted 9 lines · Robert Hancock

Quoted 1 line

Is there any more information I can supply that would be helpful?

I'm not quite sure what the next step would be. It's quite possible that the NVIDIA driver in Windows is doing some magic to work around the problem that we don't know about, but it's hard to say what that might be. The fact that the default drivers used in the WinPE boot don't seem to work would tend to point toward some kind of hardware incompatibility issue.

Tejun, think you poked with some of this stuff before - any ideas?

Quoted 12 lines

It has been years since I looked at MCP quirks, of which there are too many. It's likely another quirk on the controller side that nvidia worked around somehow without telling anyone. Given the history and that nvidia is out of chipset market, I think it's highly unlikely to learn what the issue and workaround are without reverse engineering it. So, um, no idea.

Thanks.

Signature · 2 lines

tejun
-- 

Robert,

I've inquired about this problem with Allen Martin at Nvidia, he had the following reply:

/--------SNIP---------------/
Hi Bruce, I did work on the Windows SATA driver for those chipsets, so I’m familiar with it. I’m not aware of any of any timing workarounds for any devices in the driver, but it’s certainly true that there are devices that have timing sensitivity, especially around the IDENTIFY command and it may inadvertently work with one driver and not another.

From the bug reports it looks like it’s always timing out on a
TEST_UNIT_READY command? I assume this is probably the first command sent down after IDENTIFY to check for presense of a CD in the drive? If so it’s likely the drive is locked up and any command at that point will fail. If you want to test out the theory about it being a timing issue, I would stick some udelay()s in the identify code path, both before and after starting the transfer to see if it makes any difference. Also do you know if the driver does a PHY reset when it resets the link? If not, you can try doing that by writing a 0 to SControl and then restoring it with the original value.

Quoted 8 lines

Hope this helps,

-Allen
/--------SNIP---------------/

Does this provide any actionable information? I've tried searching for the proper location to impliment these delays in the sata_nv.c and libata-eh.c files but admittedly, am in over my head.

Quoted 7 lines

Don't think there's any earth-shaking revelations but it might be a few things to try. First, though, apparently there is a firmware update for this drive of at least one revision up (WL0G) available from Lite-ON that you could try updating to. (You'll likely need to use Windows for that.) Given that it seems broken in at least two different environments on this controller, it's possible they fixed something related in the drive.

Robert,

I can report that the new firmware for the drive does not solve the problem.

watchtv@teevee:~$ dmesg |grep ata5
[    1.090360] ata5: SATA max UDMA/133 cmd 0x9e0 ctl 0xbe0 bmdma 0xc400 irq 20
[    1.556044] ata5: SATA link up 1.5 Gbps (SStatus 113 SControl 300)
[    1.564199] ata5.00: ATAPI: ATAPI   iHOS104, WL0G, max UDMA/100
[    1.580140] ata5.00: configured for UDMA/100
[    6.580035] ata5.00: qc timeout (cmd 0xa0)
[    6.580043] ata5.00: TEST_UNIT_READY failed (err_mask=0x4)
[    7.048042] ata5: SATA link up 1.5 Gbps (SStatus 113 SControl 300)
[    7.072124] ata5.00: configured for UDMA/100
[   12.072029] ata5.00: qc timeout (cmd 0xa0)
[   12.072037] ata5.00: TEST_UNIT_READY failed (err_mask=0x4)
[   12.072041] ata5: limiting SATA link speed to 1.5 Gbps
[   12.072043] ata5.00: limiting speed to UDMA/100:PIO3
[   12.540058] ata5: SATA link up 1.5 Gbps (SStatus 113 SControl 300)
[   12.564141] ata5.00: configured for UDMA/100
[   17.564038] ata5.00: qc timeout (cmd 0xa0)
[   17.564045] ata5.00: TEST_UNIT_READY failed (err_mask=0x4)
[   17.564048] ata5.00: disabled
[   17.564063] ata5: hard resetting link
[   17.564065] ata5: nv: skipping hardreset on occupied port
[   18.032068] ata5: SATA link up 1.5 Gbps (SStatus 113 SControl 300)
[   18.032082] ata5: EH complete
watchtv@teevee:~$

My apologies for not noticing the firmware update earlier. I do recall checking at one time, though it may have been prior to Sept. 2011.

Bruce

Quoted 118 lines · Bruce Link

Quoted 75 lines · Robert Hancock

Quoted 64 lines · Bruce Link

Quoted 23 lines

Hello,

Quoted 11 lines · Robert Hancock

Quoted 2 lines

Is there any more information I can supply that would be helpful?

I'm not quite sure what the next step would be. It's quite possible that the NVIDIA driver in Windows is doing some magic to work around the problem that we don't know about, but it's hard to say what that might be. The fact that the default drivers used in the WinPE boot don't seem to work would tend to point toward some kind of hardware incompatibility issue.

Tejun, think you poked with some of this stuff before - any ideas?

It has been years since I looked at MCP quirks, of which there are too many. It's likely another quirk on the controller side that nvidia worked around somehow without telling anyone. Given the history and that nvidia is out of chipset market, I think it's highly unlikely to learn what the issue and workaround are without reverse engineering it. So, um, no idea.

Quoted 5 lines

Thanks.

--
tejun
--

Robert,

I've inquired about this problem with Allen Martin at Nvidia, he had the following reply:

/--------SNIP---------------/
Hi Bruce, I did work on the Windows SATA driver for those chipsets, so I’m
familiar with it. I’m not aware of any of any timing workarounds for any devices in the driver, but it’s certainly true that there are devices that
have timing sensitivity, especially around the IDENTIFY command and it may
inadvertently work with one driver and not another.

From the bug reports it looks like it’s always timing out on a
TEST_UNIT_READY command? I assume this is probably the first command sent
down after IDENTIFY to check for presense of a CD in the drive? If so it’s
likely the drive is locked up and any command at that point will fail. If
you want to test out the theory about it being a timing issue, I would stick
some udelay()s in the identify code path, both before and after starting the
transfer to see if it makes any difference. Also do you know if the driver
does a PHY reset when it resets the link? If not, you can try doing that by
writing a 0 to SControl and then restoring it with the original value.

Hope this helps,

Quoted 8 lines

-Allen
/--------SNIP---------------/

Does this provide any actionable information? I've tried searching for the
proper location to impliment these delays in the sata_nv.c and libata-eh.c
files but admittedly, am in over my head.

Quoted 7 lines

Don't think there's any earth-shaking revelations but it might be a few things to try. First, though, apparently there is a firmware update for this drive of at least one revision up (WL0G) available from Lite-ON that you could try updating to. (You'll likely need to use Windows for that.) Given that it seems broken in at least two different environments on this controller, it's possible they fixed something related in the drive.

Robert,

I can report that the new firmware for the drive does not solve the problem.

watchtv@teevee:~$ dmesg |grep ata5
[    1.090360] ata5: SATA max UDMA/133 cmd 0x9e0 ctl 0xbe0 bmdma 0xc400
irq 20
[    1.556044] ata5: SATA link up 1.5 Gbps (SStatus 113 SControl 300)
[    1.564199] ata5.00: ATAPI: ATAPI   iHOS104, WL0G, max UDMA/100
[    1.580140] ata5.00: configured for UDMA/100
[    6.580035] ata5.00: qc timeout (cmd 0xa0)
[    6.580043] ata5.00: TEST_UNIT_READY failed (err_mask=0x4)
[    7.048042] ata5: SATA link up 1.5 Gbps (SStatus 113 SControl 300)
[    7.072124] ata5.00: configured for UDMA/100
[   12.072029] ata5.00: qc timeout (cmd 0xa0)
[   12.072037] ata5.00: TEST_UNIT_READY failed (err_mask=0x4)
[   12.072041] ata5: limiting SATA link speed to 1.5 Gbps
[   12.072043] ata5.00: limiting speed to UDMA/100:PIO3
[   12.540058] ata5: SATA link up 1.5 Gbps (SStatus 113 SControl 300)
[   12.564141] ata5.00: configured for UDMA/100
[   17.564038] ata5.00: qc timeout (cmd 0xa0)
[   17.564045] ata5.00: TEST_UNIT_READY failed (err_mask=0x4)
[   17.564048] ata5.00: disabled
[   17.564063] ata5: hard resetting link
[   17.564065] ata5: nv: skipping hardreset on occupied port
[   18.032068] ata5: SATA link up 1.5 Gbps (SStatus 113 SControl 300)
[   18.032082] ata5: EH complete
watchtv@teevee:~$

My apologies for not noticing the firmware update earlier. I do recall checking at one time, though it may have been prior to Sept. 2011.

Quoted 1 line

Bruce

Robert,

Writing to you to bump this thread. Is there anything more I can do to troubleshoot this issue?

Quoted 107 lines · Bruce Link

Quoted 106 lines · Bruce Link

Quoted 68 lines · Robert Hancock

Quoted 59 lines · Bruce Link

Quoted 19 lines

Hello,

Quoted 9 lines · Robert Hancock

Quoted 1 line

Is there any more information I can supply that would be helpful?

I'm not quite sure what the next step would be. It's quite possible that the NVIDIA driver in Windows is doing some magic to work around the problem that we don't know about, but it's hard to say what that might be. The fact that the default drivers used in the WinPE boot don't seem to work would tend to point toward some kind of hardware incompatibility issue.

Tejun, think you poked with some of this stuff before - any ideas?

It has been years since I looked at MCP quirks, of which there are too many. It's likely another quirk on the controller side that nvidia worked around somehow without telling anyone. Given the history and that nvidia is out of chipset market, I think it's highly unlikely to learn what the issue and workaround are without reverse engineering it. So, um, no idea.

Quoted 5 lines

Thanks.

--
tejun
--

Robert,

I've inquired about this problem with Allen Martin at Nvidia, he had the following reply:

/--------SNIP---------------/
Hi Bruce, I did work on the Windows SATA driver for those chipsets, so I’m
familiar with it. I’m not aware of any of any timing workarounds for any devices in the driver, but it’s certainly true that there are devices that
have timing sensitivity, especially around the IDENTIFY command and it may
inadvertently work with one driver and not another.

From the bug reports it looks like it’s always timing out on a
TEST_UNIT_READY command? I assume this is probably the first command sent
down after IDENTIFY to check for presense of a CD in the drive? If so it’s
likely the drive is locked up and any command at that point will fail. If
you want to test out the theory about it being a timing issue, I would stick
some udelay()s in the identify code path, both before and after starting the
transfer to see if it makes any difference. Also do you know if the driver
does a PHY reset when it resets the link? If not, you can try doing that by
writing a 0 to SControl and then restoring it with the original value.

Hope this helps,

Quoted 8 lines

-Allen
/--------SNIP---------------/

Does this provide any actionable information? I've tried searching for the
proper location to impliment these delays in the sata_nv.c and libata-eh.c
files but admittedly, am in over my head.

Quoted 7 lines

Don't think there's any earth-shaking revelations but it might be a few things to try. First, though, apparently there is a firmware update for this drive of at least one revision up (WL0G) available from Lite-ON that you could try updating to. (You'll likely need to use Windows for that.) Given that it seems broken in at least two different environments on this controller, it's possible they fixed something related in the drive.

Robert,

I can report that the new firmware for the drive does not solve the problem.

watchtv@teevee:~$ dmesg |grep ata5
[    1.090360] ata5: SATA max UDMA/133 cmd 0x9e0 ctl 0xbe0 bmdma 0xc400
irq 20
[    1.556044] ata5: SATA link up 1.5 Gbps (SStatus 113 SControl 300)
[    1.564199] ata5.00: ATAPI: ATAPI   iHOS104, WL0G, max UDMA/100
[    1.580140] ata5.00: configured for UDMA/100
[    6.580035] ata5.00: qc timeout (cmd 0xa0)
[    6.580043] ata5.00: TEST_UNIT_READY failed (err_mask=0x4)
[    7.048042] ata5: SATA link up 1.5 Gbps (SStatus 113 SControl 300)
[    7.072124] ata5.00: configured for UDMA/100
[   12.072029] ata5.00: qc timeout (cmd 0xa0)
[   12.072037] ata5.00: TEST_UNIT_READY failed (err_mask=0x4)
[   12.072041] ata5: limiting SATA link speed to 1.5 Gbps
[   12.072043] ata5.00: limiting speed to UDMA/100:PIO3
[   12.540058] ata5: SATA link up 1.5 Gbps (SStatus 113 SControl 300)
[   12.564141] ata5.00: configured for UDMA/100
[   17.564038] ata5.00: qc timeout (cmd 0xa0)
[   17.564045] ata5.00: TEST_UNIT_READY failed (err_mask=0x4)
[   17.564048] ata5.00: disabled
[   17.564063] ata5: hard resetting link
[   17.564065] ata5: nv: skipping hardreset on occupied port
[   18.032068] ata5: SATA link up 1.5 Gbps (SStatus 113 SControl 300)
[   18.032082] ata5: EH complete
watchtv@teevee:~$

Quoted 8 lines

Quoted 4 lines

My apologies for not noticing the firmware update earlier. I do recall checking at one time, though it may have been prior to Sept. 2011.

Bruce

Robert,

Writing to you to bump this thread. Is there anything more I can do to troubleshoot this issue?

A couple of things you could try:

(quoted diff) +0 -2

-Does the behavior change if you boot with vs. without a disc in the drive?
 
-You could try building a kernel with something like adding

mdelay(1000) at the start of the atapi_eh_clear_ua function in drivers/ata/libata-eh.c.You should see an extra 1 second delay (so at the very least it should take 6 seconds to timeout rather than 5). If that changes anything then perhaps some kind of timing quirk would help the problem.