Art Haas wrote:
>>> Also, zero out the features register before issuing PACKET_IDENTIFY,
>>> if the code isn't already doing that.
>> Okay.
>>
>>> After the drive asserts BUSY, and later deasserts BUSY,
>>> there might be a slight delay before the drive asserts DRQ.
>>> So, it is possible for the status to read zeros in the important bits.
>>>
>>> My suggestion is to wait up to the infamous 50 milliseconds again here,
>>> if needed.
>> Okay, the attached patch does what Mark suggested.  Art, can you please
>> give it a shot and report dmesg?  My thanks for sticking around till now.
> 
> SUCCESS!!!!!

Yay!

[--snip--]
> ata_piix 0000:00:07.1: version 2.00ac7
> ata1: PATA max UDMA/33 cmd 0x1F0 ctl 0x3F6 bmdma 0xF000 irq 14
> ata2: PATA max UDMA/33 cmd 0x170 ctl 0x376 bmdma 0xF008 irq 15
> scsi0 : ata_piix
> ata1.00: ATA-2, max UDMA/33, 6303024 sectors: LBA 
> ata1.00: ata1: dev 0 multi count 16
> ata1.01: ATA-4, max UDMA/66, 16514064 sectors: LBA 
> ata1.01: ata1: dev 1 multi count 16
> ata1.00: configured for UDMA/33
> ata1.01: configured for UDMA/33
> scsi1 : ata_piix
> ata2.00: ATAPI, max MWDMA1
> ata2.00: configured for MWDMA1

So, it succeeded without any DRQ wait.  Can you please apply only the 
attached patch over vanilla 2.6.20 and see if your problem is fixed?

This problem has been around for quite a while now and there probably 
have been other users hit by this out there.  Thanks a lot, Mark.

-- 
tejun