[vox-tech] ac97 sound problems

[vox-tech@lists.lugod.org]

On Thu, Apr 25, 2002 at 11:05:43AM -0700, Peter Jay Salzman wrote:
> begin msimons@moria.simons-clan.com <msimons@moria.simons-clan.com> 
> >   If you send a "kill -9" and the process does not die instantly, then 
> > you have a kernel bug... there is no way to "block" or "hide" from 
> > kill -9.
> 
> as you point out, processes in "uninterruptable sleep" can't be killed
> with SIGKILL.  the process is put to sleep while the kernel waits for
> some event to happen.  this corresponds to process status "D".

  It is true that processes in state D don't die instantly, I had not
considered them.  Even processes in state D should die in a few seconds 
or _maybe_ a minute for a very slow device... but I can't think of any 
thing at the moment that is a _valid_ reason to lock a process in 
uninterruptable sleep forever.

  Realize that when the kernel exposes a method to become "stuck" forever
in that state a malicious program can do great evil things to the machine
by for example sucking up as much memory as possible and any other 
critical resources it can get, then calling the magic "lock me" method
and the only way out would be a power cycle.

  Processes that get wedged in state D can also prevent the filesystems
from unmounting... 

  If you think of a few cases that locking the process is valid please
let me know, I probably overlooked something...


> as you point out, it can be kernel bug.  often a race condition.
> but it can also be caused by hardware failure.

  Most any hardware bugs can be worked around in software...

  The kernel is still alive and functioning, the driver knows
how much data is queued on the device, it knows what data rate is
being played and it could easily determine that the device has locked
up... and reset the device.  Most drivers will reset their devices
when they detect a timeout or other "shouldn't happen" sort of 
error condition... if the device doesn't respond to the reset
report that and return IO error messages to user space.

  A work around as drastic as blacklisting the buggy chipset is
acceptable if the authors can't figure out how to dance around
the problem.


> the chipset in question is known to have issues in both linux and
> windows.

  Hrmmm... I agree that I see reports of problems with the "via chipsets"
even in the kernel documentation directory... 
  /usr/src/linux/Documentation/sound/VIA-chipset
saying that there was no word back from VIA but that file is ancient
... dated Jan 1999.

  I had heard via was much more active supporting linux, and
now that I look further they appear to have step by step directions 
for enabling their chipsets in Linux...
  http://www.viaarena.com/?PageID=88
also public support forums available, possibly looking there would be 
another good place.

    Later,
      Mike