libata: don't check whether to use DMA or not for no data commands

LG blueray drive GGW-H10N can't do ATAPI PIO. Implement ATAPI_HORKAGE_NOPIO and apply it to the drive. If the horkage is active, atapi_check_dma() always returns 0 and warns if the controller needs ATAPI PIO for certain commands.

LG blueray drive GGW-H10N can't do ATAPI PIO. Implement ATAPI_HORKAGE_NOPIO and apply it to the drive. If the horkage is active, atapi_check_dma() always returns 0 and warns if the controller needs ATAPI PIO for certain commands.

Quoted 4 lines · On Tue, 17 Jun 2008 12:37:24 +0900 Tejun Heo <[email protected]> wrote:

LG blueray drive GGW-H10N can't do ATAPI PIO. Implement ATAPI_HORKAGE_NOPIO and apply it to the drive. If the horkage is active, atapi_check_dma() always returns 0 and warns if the controller needs ATAPI PIO for certain commands.

This all seems wildly improbable as a drive with such a bug would not appear to be going to work in Windows. I'd like to know more and see more than one bug report for that drive before it goes in

You might even be looking at a single drive with a one off wiring flaw or chip fault at this point.

So in the absence of multiple reports of this drive failing, and of no other drive being tested on the same controller after the bug was seen I think this is a *very bad idea* as a patch.

Quoted 7 lines · Alan Cox

Quoted 4 lines · On Tue, 17 Jun 2008 12:37:24 +0900 Tejun Heo <[email protected]> wrote:

LG blueray drive GGW-H10N can't do ATAPI PIO. Implement ATAPI_HORKAGE_NOPIO and apply it to the drive. If the horkage is active, atapi_check_dma() always returns 0 and warns if the controller needs ATAPI PIO for certain commands.

Quoted 6 lines

This all seems wildly improbable as a drive with such a bug would not appear to be going to work in Windows. I'd like to know more and see more than one bug report for that drive before it goes in

You might even be looking at a single drive with a one off wiring flaw or chip fault at this point.

I thought it was improbable too but it's a brand new relatively cheap blueray writer so it's quite possible that they screwed up the firmware on this one as are often the cases for first gen devices.

Relatively cheap it may be, it's still around $300, so I don't think I'll get one for testing. The high price could probably explain low error report rate.

Originally the drive was bought for a different PC with a Silicon Image 3114 controller. The drive worked fine with this (sata_sil). Then I

Quoted 8 lines · Alan Cox

Quoted 4 lines · On Tue, 17 Jun 2008 12:37:24 +0900 Tejun Heo <[email protected]> wrote:

LG blueray drive GGW-H10N can't do ATAPI PIO. Implement ATAPI_HORKAGE_NOPIO and apply it to the drive. If the horkage is active, atapi_check_dma() always returns 0 and warns if the controller needs ATAPI PIO for certain commands.

Quoted 6 lines

This all seems wildly improbable as a drive with such a bug would not appear to be going to work in Windows. I'd like to know more and see more than one bug report for that drive before it goes in

You might even be looking at a single drive with a one off wiring flaw or chip fault at this point.

I thought it was improbable too but it's a brand new relatively cheap blueray writer so it's quite possible that they screwed up the firmware on this one as are often the cases for first gen devices.

Relatively cheap it may be, it's still around $300, so I don't think I'll get one for testing. The high price could probably explain low error report rate.

Luke, what happens if you use the drive on windows? Does it just work?

Quoted 2 lines

Originally the drive was bought for a different PC with a Silicon Image 3114 controller. The drive worked fine with this (sata_sil). Then I

Ok that proves the point quite nicely. If there is a problem it is not the one suggested.

Quoted 5 lines · Alan Cox

Quoted 2 lines

Originally the drive was bought for a different PC with a Silicon Image 3114 controller. The drive worked fine with this (sata_sil). Then I

Ok that proves the point quite nicely. If there is a problem it is not the one suggested.

Yeah, indeed. It's still weird tho. The difference between ATAPI_PROT_PIO and ATAPI_PROT_DMA is very small especially on ahci. The data are still transferred using the same FIS. Only the completion mechanism is different. It would be great to try the drive on another ahci controller preferably intel one. Luke, do you have access to any machine which has intel ahci?

Hi,

Quoted 11 lines · Tejun Heo

Quoted 4 lines · Alan Cox

Quoted 2 lines

Originally the drive was bought for a different PC with a Silicon Image 3114 controller. The drive worked fine with this (sata_sil). Then I

Ok that proves the point quite nicely. If there is a problem it is not the one suggested.

Yeah, indeed. It's still weird tho. The difference between ATAPI_PROT_PIO and ATAPI_PROT_DMA is very small especially on ahci. The data are still transferred using the same FIS. Only the completion mechanism is different. It would be great to try the drive on another ahci controller preferably intel one. Luke, do you have access to any machine which has intel ahci?

I tried it out on a machine with an Intel ICH7 controller using the AHCI driver (using a Fedora 9 LiveCD). On the ICH7 the drive wrote a CD
without issue, so possibly it's the drive/controller pair that causes
the problem. I was careful to ensure I was using the ahci driver and not the ata_piix driver.

There's no reason to check whether to use DMA or not for no data commands. Don't do it. While at it, make local variable using_pio in atapi_xlat() set iff ATAPI_PROT_PIO is going to be used and rename ata_check_atapi_dma() to atapi_check_dma() for consistency.

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

---
It's late in the -rc cycle but these two patches are to work around specific hardware and low risk. Thanks.

 drivers/ata/libata-core.c |    4 ++--
 drivers/ata/libata-scsi.c |   16 +++++++---------
 drivers/ata/libata.h      |    2 +-
 3 files changed, 10 insertions(+), 12 deletions(-)

I really think it's more generalized ATAPI brokenness, perhaps specific to AHCI.

I'm going to allocate some time to dig into this, if Tejun doesn't find the problem, because it's not just limited to a few models.  We've been getting _tons_ of timeout bug reports, and in fact, my own AHCI-based workstation cannot rip audio CDs at all:

Quoted 16 lines · Luke Ross

Hi,

Quoted 4 lines · Tejun Heo

Quoted 3 lines · Alan Cox

Quoted 3 lines

Originally the drive was bought for a different PC with a Silicon Image
3114 controller. The drive worked fine with this (sata_sil). Then I

Quoted 8 lines

Quoted 2 lines

Ok that proves the point quite nicely. If there is a problem it is not the one suggested.

Yeah, indeed. It's still weird tho. The difference between ATAPI_PROT_PIO and ATAPI_PROT_DMA is very small especially on ahci. The data are still transferred using the same FIS. Only the completion mechanism is different. It would be great to try the drive on another ahci controller preferably intel one. Luke, do you have access to any machine which has intel ahci?

Quoted 5 lines

I tried it out on a machine with an Intel ICH7 controller using the AHCI driver (using a Fedora 9 LiveCD). On the ICH7 the drive wrote a CD without issue, so possibly it's the drive/controller pair that causes the problem. I was careful to ensure I was using the ahci driver and not the ata_piix driver.

I really think it's more generalized ATAPI brokenness, perhaps specific to AHCI.

I'm going to allocate some time to dig into this, if Tejun doesn't find the problem, because it's not just limited to a few models. We've been getting _tons_ of timeout bug reports, and in fact, my own AHCI-based workstation cannot rip audio CDs at all:

ahci 0000:00:1f.2: AHCI 0001.0100 32 slots 4 ports 3 Gbps 0xf impl SATA mode
ahci 0000:00:1f.2: flags: 64bit ncq led clo pio slum part

...

ata4: SATA link up 1.5 Gbps (SStatus 113 SControl 300) ata4.00: ATAPI: PLEXTOR DVDR PX-755A, 1.03, max UDMA/66 ata4.00: configured for UDMA/66

...

scsi 3:0:0:0: CD-ROM PLEXTOR DVDR PX-755A 1.03 PQ: 0 ANSI: 5

...

ata4.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x2 frozen ata4.00: cmd a0/01:00:00:30:09/00:00:00:00:00/a0 tag 0 dma 2352 in cdb be 00 00 00 0d 6d 00 00 01 f8 00 00 00 00 00 00
res 40/00:03:00:00:00/00:00:00:00:00/a0 Emask 0x4 (timeout) ata4.00: status: { DRDY }
ata4: soft resetting link
ata4: port is slow to respond, please be patient (Status 0xd0)
ata4: softreset failed (device not ready)
ata4: hard resetting link
ata4: port is slow to respond, please be patient (Status 0x80)
ata4: COMRESET failed (errno=-16)
ata4: hard resetting link
ata4: SATA link up 1.5 Gbps (SStatus 113 SControl 300) ata4.00: configured for UDMA/66
ata4: EH complete

Luke/Tejun, do you have some error output from those wodim or growisofs errors? It would be useful to know what commands those were that failed and whether they were also an unusual data size.

Luke/Tejun, do you have some error output from those wodim or growisofs errors? It would be useful to know what commands those were that failed and whether they were also an unusual data size.

Hello,

Quoted 3 lines · Robert Hancock

Luke/Tejun, do you have some error output from those wodim or growisofs errors? It would be useful to know what commands those were that failed and whether they were also an unusual data size.

I don't have anything.  For some reason, ahci works fine on the setups here.  :-(

I'm waiting for Dan's further report.  I still am not sure whether we're actually seeing a lot of ahci ATAPI failures or it's just that a lot of reports are on ahci because it's the most often used driver now.  I don't think anything fundamental is broken.  The reports are too infrequent for that to be true.  It might have something to do with the buffer padding / draining we do or how the controller and driver react.

Quoted 18 lines · Tejun Heo

Hello,

Quoted 3 lines · Robert Hancock

Luke/Tejun, do you have some error output from those wodim or growisofs errors? It would be useful to know what commands those were that failed and whether they were also an unusual data size.

I don't have anything. For some reason, ahci works fine on the setups here. :-(

I'm waiting for Dan's further report. I still am not sure whether we're actually seeing a lot of ahci ATAPI failures or it's just that a lot of reports are on ahci because it's the most often used driver now. I don't think anything fundamental is broken. The reports are too infrequent for that to be true. It might have something to do with the buffer padding / draining we do or how the controller and driver react.

Quoted 1 line

From the bug 10091 it looks like the failing command was a MODE SELECT

with data transfer length of 66 bytes which is definitely odd..

My suspicion is that we're either padding out the data buffer and the indicated PRD length to a longer length than the drive actually wants to transfer, and the controller isn't happy with that, OR maybe vice-versa (i.e. we don't pad out the length and it wants us to). It's not clear if this and Jeff's issue are actually the same thing as the response is fairly different (interface fatal error and SError indications on the NV vs. a timeout on whatever chipset Jeff's using), but that may just be a chipset difference.

If Jeff has a repeatable test case then that's likely the most promising place to start poking at things..

I'm waiting for Dan's further report.