cvs commit: src/sys/dev/ata ata-all.h ata-chipset.c ata-dma.c ata-pci.c ata-pci.h atapi-cd.c atapi-fd.c atapi-tape.c

[Nate Lawson]

Maxim Sobolev wrote:
> Robert Watson wrote:
>> On Thu, 22 Nov 2007, Søren Schmidt wrote:
>>
>>>>>>   FreeBSD src repository
>>>>>>
>>>>>>   Modified files:  (Branch: RELENG_7)
>>>>>>     sys/dev/ata ata-all.h ata-chipset.c ata-dma.c ata-pci.c
>>>>>> ata-pci.h atapi-cd.c atapi-fd.c atapi-tape.c Log:
>>>>>>   Update with the latest fixes from -current.
>>>>>
>>>>> Please don't forget to merge at least atapi-cd.c fix into RELENG_6.
>>>>> Currently CD is not working in Parallels with 6.3-PRERELEASE.
>>>>
>>>> Also, I see some "ad0: TIMEOUT - WRITE_DMA (retrying)" messages with
>>>> Parallels using latest 6.3-PRERELEASE snapshot. Not sure if it's due
>>>> to some changes between 6.2 and 6.3, but I've never seen this with
>>>> 6.2. Any ideas?
>>>
>>> I have a complete backport of all the latest fixes done for 6.3
>>> awaiting approval.
>>>
>>> I've seen such a timeout once on 6.3 before I merged the latest
>>> changes, since then I've not seen any, not that it means much though :)
>>
>> I see them any time I do anything involving significant disk load
>> under Parallels--I've always assumed it was because there are several
>> layers of indirection, including HFS+ and an expanding Parallels disk
>> image, beween the FreeBSD ATA driver and hardware, leading to
>> significantly longer delays than the ATA driver would expect from
>> normal hardware.  That said, I'm fine with being wrong and seeing a
>> bug fixed :-).  I usually get several each time I buildkernel, such as
>> last night:
>>
>> ad0: TIMEOUT - READ_DMA retrying (1 retry left) LBA=5208191
>> ad0: TIMEOUT - READ_DMA retrying (1 retry left) LBA=23670111
>> ad0: TIMEOUT - READ_DMA retrying (1 retry left) LBA=5843715
>> ad0: TIMEOUT - WRITE_DMA retrying (1 retry left) LBA=40407615
> 
> Assuming that there are no actual bugs in the code, should not it make
> sense to detect virtual hardware and treat it a little bit differently
> with respect to timeouts? Given the growing popularity of virtualization
> technology it's doesn't sound like a worthless project.

Last time I looked at the ata code, I found the timeout was much too low
for common drives (non-virtual).  Anything that took a little longer to
spin up from idle or under heavy shared irq load would time out and
retry.  I think I bumped it up to 30 seconds and kept retry count at 5.

-- 
Nate