[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]
Re: System goes into complete hang
On 7-Apr-08, at 2:06 AM, D'Arcy J.M. Cain wrote:
On Sun, 6 Apr 2008 16:20:18 +0100 (BST)
Iain Hibbert <plunky%rya-online.net@localhost> wrote:
On Sun, 6 Apr 2008, D'Arcy J.M. Cain wrote:
options DEBUG # expensive debugging checks/support
this one really is expensive and would be my first guess.
Isn't that for compile time checks? I am going to start by removing
DIAGNOSTIC since that one specifies kernel checking.
I haven't played audio on a netbsd-based machine in a few months (my
NAS-capable X station is not set up since my move), and I've never
played audio on a netbsd machine with a built-in audio device, but I
can assure you that neither DEBUG nor DIAGNOSTICS are causes of any
major slowdowns, and neither has ever affected normal audio playback
via NAS over the network.
Perhaps one or the other turns on some periodic cleanup/check code in
the particular audio driver you are using. This kind of code should
be fairly easy to find though as it apparently isn't occurring in the
regular I/O operations, but rather on some kind of periodic timer or
some other such milestone event.
In fact I'd say that unless your system is truly starved for CPU then
you should _always_ enable both "options DEBUG" and "options
DIAGNOSTIC". DEBUG should always be the first to go when system
performance appears to be adversely affected. "options DIAGNOSTIC"
should probably always be enabled by default and only turned off by
users who have completely validated particular configurations for
something where space is critical such as embedded/appliance systems.
I'd also hope that kernel developers should continue to use these
compile-time options as appropriate to enable code that can help
detect runtime problems wherever and however possible so long as there
are no major impacts on system performance or usability. Really
intrusive checks should also continue to be enabled with #ifdef
BLAH_DEBUG where "BLAH" refers to the code/data being checked.
Greg A. Woods; Planix, Inc.
Main Index |
Thread Index |