Skip site navigation (1)Skip section navigation (2)
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>