ALSA-CVS: Unbreakable "sfxload" process

ALSA-CVS: Unbreakable "sfxload" process

[Chris Rankin]

Hi,

I have just tried loading a sound-font file into my SB
Live! and ended up needing to reboot my machine when
the sfxload program grabbed hold of the CPU and
wouldn't give it back! Fortunately the machine is SMP,
and so I was able to shutdown cleanly using the other
one.

I think the problem happened because I was trying to
play a MID file at the time using:

$ pmidi -p 65:0 <file>

and didn't break this process before trying to load
the sound-font. Note also that the sfxload program
uses /dev/sequencer and so the OSS emulation modules
are also implicated.

And the reason I think that this is a kernel problem
is that the sfxload process survived repeated "kill
-9" attempts by root... ;-).

Cheers,
Chris


__________________________________________________
Do You Yahoo!?
Everything you'll ever need on one web page
from News and Sport to Email and Music Charts
http://uk.my.yahoo.com


-------------------------------------------------------
This SF.NET email is sponsored by: FREE  SSL Guide from Thawte
are you planning your Web Server Security? Click here to get a FREE
Thawte SSL guide and find the answers to all your  SSL security issues.
http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0026en

Re: ALSA-CVS: Unbreakable "sfxload" process

[Takashi Iwai]

At Sat, 15 Feb 2003 00:08:15 +0000 (GMT),
Chris Rankin wrote:
> 
> Hi,
> 
> I have just tried loading a sound-font file into my SB
> Live! and ended up needing to reboot my machine when
> the sfxload program grabbed hold of the CPU and
> wouldn't give it back! Fortunately the machine is SMP,
> and so I was able to shutdown cleanly using the other
> one.
> 
> I think the problem happened because I was trying to
> play a MID file at the time using:
> 
> $ pmidi -p 65:0 <file>
> 
> and didn't break this process before trying to load
> the sound-font. Note also that the sfxload program
> uses /dev/sequencer and so the OSS emulation modules
> are also implicated.
> 
> And the reason I think that this is a kernel problem
> is that the sfxload process survived repeated "kill
> -9" attempts by root... ;-).

hmm, i'm afraid that it's again because of damn kernel memory
allocator...
but, it could be a mutex deadlock of the emu10k1 driver, of course.
i'll take a look tomorrow.


ciao,

Takashi


-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf