Date: Wed, 26 Dec 2012 03:48:04 -0500 From: "Dieter BSD" <dieterbsd@engineer.com> To: freebsd-hackers@freebsd.org Subject: Re: FreeBSD for serious performance? Message-ID: <20121226084805.91840@gmx.com>
next in thread | raw e-mail | index | archive | help
> If the driver is doing something daft like DELAY(x) in a fast > interrupt handler which would lead to that behaviour, it should be > fixed. > > If it's doing a DELAY(x) in a critical section, it shuld be fixed. They are doing *something* that completely locks out everything else. It is always a device driver. > Now, it's quite likely you hit some kind of ata(4) bug which kept it > in a tight loop Hard to imagine locking everything out for 19 minutes without being in a loop. > So it was likely just spun > in some high priority loop that nothing lower-priority could really do > anything about. Would several different drivers have this same bug? > The next time it happens, please break into the debugger and grab some > debugging output. Show alllocks, ps, should be a good couple of things > to start with. I've only caught it hanging forever once. It only takes a few milliseconds to cause incoming data to be lost, so I usually don't know about it until looking at the log file later. Not that I could jump into the debugger and gather data in a few milliseconds even if I knew when it was happening. BTW, how do I break into the debugger and gather data when all of the devices are locked out, including the console? I assume that once it recovers, there is no point in gathering data. > Alternately - please find a currently actively maintained SATA chipset. The ata controller is soldered to the mainboard, a gazillion pins I'm sure, and no doubt requires very specialized equipment to replace, and I don't know of any pin-compatable replacements. Besides the hardware itself has never caused any problems. The problem is caused by the software, it is the software that needs to be fixed. Ata isn't maintained? Why the bleep not? Disk drivers are essential. I was under the impression that siis(4) and ahci(4) were actively maintained? I'm running four sata controllers using three different drivers and all three drivers lock out other drivers for too long when something unusual happens. And other, non-disk drivers have the same problem of locking out other drivers, even during normal operation. And this happens on yet other drivers on other people's hardware, not just mine. > help migrate the nvidia chipset support out of ata(4) I've looked at several of FreeBSD's device drivers (including, as you might expect, ata, siis, and ahci) and I can't make heads or tails out of any of them. Back before FreeBSD existed, I did manage to make a significant improvement to a driver in a BSD-derived system, so I'm not a complete idiot. Several different drivers cause the same problem. Are they all making the same mistake? Or is there a problem in something they all use? Whether a design problem or an implementation bug.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20121226084805.91840>