Skip site navigation (1)Skip section navigation (2)
Date:      Sat, 13 Nov 2004 03:08:49 -0700
From:      Scott Long <scottl@freebsd.org>
To:        =?ISO-8859-1?Q?S=F8ren_Schmidt?= <sos@DeepCore.dk>
Cc:        Garance A Drosihn <drosih@rpi.edu>
Subject:   Re: 5.3-RELEASE: WARNING - WRITE_DMA interrupt timout
Message-ID:  <4195DD31.10201@freebsd.org>
In-Reply-To: <4195DB3E.2040807@DeepCore.dk>
References:  <25539.1100339599@critter.freebsd.dk> <4195DB3E.2040807@DeepCore.dk>

next in thread | previous in thread | raw e-mail | index | archive | help
Søren Schmidt wrote:
> Poul-Henning Kamp wrote:
> 
>> In message <4195D903.2090801@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



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?4195DD31.10201>