5.3-RELEASE: WARNING - WRITE_DMA interrupt timout

Scott Long scottl at freebsd.org
Sat Nov 13 02:08:06 PST 2004


Søren Schmidt wrote:
> Poul-Henning Kamp wrote:
> 
>> In message <4195D903.2090801 at DeepCore.dk>, 
>> =?ISO-8859-1?Q?S=F8ren_Schmidt?= wri
>> tes:
>>
>>> Zoltan Frombach wrote:
>>>
>>>> This is still an issue for me. Please read this post of mine:
>>>> http://lists.freebsd.org/pipermail/freebsd-stable/2004-November/009420.html 
>>>>
>>>>
>>>> Can anyone help? I would gladely install test patches to track this 
>>>> problem down. My system is 5.3-R. And the WRITE_DMA warning happens 
>>>> at least twice a day, it is so predictable. With thanks,
>>>
>>>
>>> Hmmm, that warning is issued from ATA when requests has been returned 
>>> to the systems bio_taskqueue but the system hasn't finished them 
>>> within the timeout. Now this is an indication of the system being 
>>> unresponsive already at that point, or at least that was the idea.
>>> It has nothing to do with a bad drive, since the interrupt was seen 
>>> the drive has finished the request it was asked, its the layers above 
>>> ATA that doesn't respond to the request beeing returned as finished.
>>
>>
>> It is not really the task of the ata driver to fail requests at that
>> time.   How long is the timeout anyway ?
> 
> 
> Oh, ATA doesn't fail them, it just yells that the request hasn't been 
> finished yet by the upper layers, it doesn't do anything to the request.
> 
> Timeout is 5 secs, which is a pretty long time in this context IMHO..
> 
> However, if it can take that long time to get data pushed up the chain, 
> it might also explain some of the reduced I/O performance reported ?
> 

I'm able to get 11,000+ transactions/sec and achieve PCI line rate with
the aac driver and a good version of an aac controller.  aac is a block 
driver just like ata, the only differnece is that it uses a fast 
interrupt handler to acknowledge the hardware, and batch-processes the
completions in a mpsafe (!Giant) taskqueue.  I don't see any performance
problems with this, and in fact it performs quite a bit better than
Linux and even Windows.  I see _no_ taskqueue stalls or other strange
timing or synchronization problems.

Scott


More information about the freebsd-current mailing list