Bug 194597
Summary: | kernel BUG at include/linux/list.h:58 in rmmod snd_seq_oss | ||||||
---|---|---|---|---|---|---|---|
Product: | [Fedora] Fedora | Reporter: | Leszek Matok <lam> | ||||
Component: | kernel | Assignee: | Dave Jones <davej> | ||||
Status: | CLOSED ERRATA | QA Contact: | Brian Brock <bbrock> | ||||
Severity: | medium | Docs Contact: | |||||
Priority: | medium | ||||||
Version: | 5 | CC: | 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
Leszek Matok
2006-06-14 09:57:40 UTC
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 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. *** 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 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. 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 works fine. 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. :-) 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... The original report filed in this bug is fixed in the current update kernel. For other issues, please file separate bugs. Thanks. |