Bug 194597

Summary: kernel BUG at include/linux/list.h:58 in rmmod snd_seq_oss
Product: [Fedora] Fedora Reporter: Leszek Matok <lam>
Component: kernelAssignee: Dave Jones <davej>
Status: CLOSED ERRATA QA Contact: Brian Brock <bbrock>
Severity: medium Docs Contact:
Priority: medium    
Version: 5CC: acoleman, byroniac, eric-bugs, knutjbj, mattdm, patrice, pfrields, vedran, wtogami
Target Milestone: ---   
Target Release: ---   
Hardware: All   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2006-09-17 03:22:38 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Attachments:
Description Flags
/var/log/messages fragment from the "halt" none

Description Leszek Matok 2006-06-14 09:57:40 UTC
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):
kernel-2.6.16-1.2133_FC5.i686

How reproducible:
Every time.

Steps to Reproduce:
1. rmmod snd_seq_oss
2. profit!

Actual results:
- stack dump
- 120 seconds of totally unresponsive system
- snd_seq_oss is still in place

Expected results:
- 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.

Comment 1 Leszek Matok 2006-06-14 09:57:40 UTC
Created attachment 130810 [details]
/var/log/messages fragment from the "halt"

Comment 2 Eric Hopper 2006-06-20 21:15:47 UTC
*** Bug 195898 has been marked as a duplicate of this bug. ***

Comment 3 Eric Hopper 2006-06-20 21:18:03 UTC
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
reproducible example.

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.

Comment 4 vvs 2006-06-22 11:57:52 UTC
*** Bug 196269 has been marked as a duplicate of this bug. ***

Comment 5 Knut J BJuland 2006-06-22 14:37:26 UTC
*** Bug 196149 has been marked as a duplicate of this bug. ***

Comment 6 Knut J BJuland 2006-06-23 12:34:19 UTC
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. 

Comment 7 Knut J BJuland 2006-06-23 12:36:07 UTC
 BY passing echo 0> /proc/sys/kernel/panic_on_oops I can prevent kernel panic.

Comment 8 Leszek Matok 2006-06-24 21:03:23 UTC
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.

Comment 9 Matthew Miller 2006-06-29 14:16:47 UTC
*** Bug 197159 has been marked as a duplicate of this bug. ***

Comment 10 Matthew Miller 2006-06-29 14:16:52 UTC
*** Bug 195266 has been marked as a duplicate of this bug. ***

Comment 11 Matthew Miller 2006-06-29 14:20:36 UTC
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.

Comment 12 Knut J BJuland 2006-06-29 17:33:47 UTC
This is fixed when using latest version of alsa-hg modules.

Comment 14 Vedran Miletić 2006-07-02 13:43:47 UTC
*** Bug 197449 has been marked as a duplicate of this bug. ***

Comment 15 Vedran Miletić 2006-07-02 13:44:03 UTC
Upstream bugzilla has this bug too: http://bugzilla.kernel.org/show_bug.cgi?id=6736

Comment 16 Matthew Miller 2006-07-03 14:10:39 UTC
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).



Comment 17 Vedran Miletić 2006-07-04 06:23:05 UTC
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?

Comment 18 Alan Coleman 2006-07-05 00:56:51 UTC
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
mouse pointer...

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.



Comment 19 Alan Coleman 2006-07-05 01:01:04 UTC
Oh, sorry.  To anticipate the question, that's the 2145 kernel on FC5.

Comment 20 Alan Coleman 2006-07-05 23:53:29 UTC
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
works fine.

Multiple stops and starts with no nasty kernel dumps.

The 2145 kernel seems to do the trick on FC5.

Comment 21 Eric Hopper 2006-07-06 00:01:05 UTC
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.

Comment 22 Alan Coleman 2006-07-06 00:07:18 UTC
:-)  Indeed.

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...

Comment 23 Dave Jones 2006-09-17 03:22:38 UTC
The original report filed in this bug is fixed in the current update kernel.
For other issues, please file separate bugs.

Thanks.