Red Hat Bugzilla – Bug 194597
kernel BUG at include/linux/list.h:58 in rmmod snd_seq_oss
Last modified: 2016-03-27 10:29:10 EDT
Description of problem:
Every time I type in `rmmod snd_seq_oss`, the systems yells it hit a kernel bug,
then stops for 120 seconds.
Version-Release number of selected component (if applicable):
Steps to Reproduce:
1. rmmod snd_seq_oss
- stack dump
- 120 seconds of totally unresponsive system
- snd_seq_oss is still in place
- unlinked module
- no "kernel bug" messages, no stack traces
- DON'T make me wait 120 seconds! First time it happened I even didn't know
what's happening - I was under X (remember, Fedora defaults to graphical
sessions since few years now ;)), then suddenly everything froze, I got this
annoying looped fragment of currently played song and haven't got any clue
what's going on. Oh, and Sysrq is also off by default in Fedora 5, I ended up
simply hitting reset button after 30 seconds and losing much data because
someone thinks the system has to stop for two minutes after a kernel bug.
Also, when I did it the third time, which is the attached syslog fragment,
second bug appeared, I'm giving you the whole output of this "run". The last
line was logged short time later, but it's from the same stack trace. I figured
out the stack trace ended in the middle of line, so I did some other rmmod just
to spit it out to syslog.
Created attachment 130810 [details]
/var/log/messages fragment from the "halt"
*** Bug 195898 has been marked as a duplicate of this bug. ***
I've been seeing other odd sound problems in which an ALSA using application can
no longer use the sound card (acts like something else is using it) after an OSS
application has used it and is done with it. But I have no good, concrete
Anyway, just verifying that this happens on x86_64 as well. I don't know why I
didn't get the 120 second pause. Maybe because I have a dual processor system.
*** Bug 196269 has been marked as a duplicate of this bug. ***
*** Bug 196149 has been marked as a duplicate of this bug. ***
THe bug i still present in 2.6.17-1.2138 both smp and non smp i686. I provock it
by running a native alsa midi client. But by issuing echo 1 >
/proc/sys/kernel/panic_onopps. I can prevent the kernel from crashing.
BY passing echo 0> /proc/sys/kernel/panic_on_oops I can prevent kernel panic.
2.6.17-1.2139_FC5 does the same as 2138. At least 2.6.17 doesn't do this 120
second countdown (or didn't when I tried). There's also new bug detected, but it
looks like only a side-effect of the main problem in snd_seq_*. I removed the
"120 seconds" phrase from the summary as it looks fixed.
*** Bug 197159 has been marked as a duplicate of this bug. ***
*** Bug 195266 has been marked as a duplicate of this bug. ***
This also happens on FC4 (kernel-2.6.16-1.2115_FC4 or kernel-2.6.17-1.2139_FC4)
and in rawhide (2.6.17-1.2307_FC6). And as bug #195266 notes, one can also
trigger it by just running DOSBox from Extras.
This is fixed when using latest version of alsa-hg modules.
*** Bug 197449 has been marked as a duplicate of this bug. ***
Upstream bugzilla has this bug too: http://bugzilla.kernel.org/show_bug.cgi?id=6736
This appears to be fixed in kernel-2.6.17-1.2141_FC4 in the FC4 updates (and
presumably the corresponding FC5 and devel releases).
You can install kernel-2.6.17-1.2145_FC5 from updates-testing, that fixes this
too (or so it seems to me). Can anyone else verify?
I installed the 2145 kernel from updates-testing, and I get a hard hang of the
machine when starting Rosegarden. No log info, no nothing. Just a stationary
It happens after Rosegarden sets up sound - I see various messages about the
capabilities of the sound hardware on the console before it hangs.
Any way I can start this thing in a sandbox so I can get a stack trace? I tried
gdb, but it hangs the machine there as well.
All I did was install the new kernel itself. RPM didn't complain about missing
dependencies, so I assume that's ok.
Oh, sorry. To anticipate the question, that's the 2145 kernel on FC5.
I am happy to report that my previous issues appear to have been some sort of
user error. I guess the hangs left some cruft lying around or something. I
cleaned all the kde/DCOP/ICE files out of my home directory and now Rosegarden
Multiple stops and starts with no nasty kernel dumps.
The 2145 kernel seems to do the trick on FC5.
There is no such thing as a user error that causes a kernel dump. Especially a
user error that can be fixed by removing a few files in your home directory.
The latest lockup problem I had was a separate bug, though, not this particular
issue. I could hang my system on any number of kernel versions until I cleaned
out my home directory.
How one can remove some KDE/DCOP/ICE files from one's home directory and stop
hanging the system, though, is indeed a good question...
The original report filed in this bug is fixed in the current update kernel.
For other issues, please file separate bugs.