Date: Sat, 13 Nov 2004 11:24:13 +0100 From: =?ISO-8859-1?Q?S=F8ren_Schmidt?= <sos@DeepCore.dk> To: Scott Long <scottl@freebsd.org> Cc: Garance A Drosihn <drosih@rpi.edu> Subject: Re: 5.3-RELEASE: WARNING - WRITE_DMA interrupt timout Message-ID: <4195E0CD.40608@DeepCore.dk> In-Reply-To: <4195DD31.10201@freebsd.org> References: <25539.1100339599@critter.freebsd.dk> <4195DB3E.2040807@DeepCore.dk> <4195DD31.10201@freebsd.org>
index | next in thread | previous in thread | raw e-mail
Scott Long wrote: > 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. Well, with sufficiently fast ATA hardware you can easily get that many transactions through ATA as well, so there is nothing performance wise hindering that at all. -- -Sørenhelp
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?4195E0CD.40608>