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>