I assume this might end up NEEDSINFO, but I'll report it in any case, so others can find it if this happens to them. I was using an X session and playing some music using audacious and my Creative Labs SB Live! EMU10k1 soundcard. Suddenly, my system became extremely sluggish. Mouse movement worked with some lag, ticker kept ticking, changing windows took rather long. A short time later, the system became completely unresponsive: frozen ticker, no mouse cursor movement, no updates. Switching to console failed. I logged in via ssh from another machine. Establishing the connection took over than a minute, I'd estimate. In that time, the machine at times played my music normally, at times stopped playing. Alternating every 10 seconds or so, very rough estimate. Once I got my ssh connection established, I fired up top. Listed ksoftirqd/0 with 100%CPU load, followed by metalog with around 55%. This is because it's a hyperthreading P4, so top displays two CPUs. While I was watching ksoftirqd/0 got replaced by kblockd/0, again hugging 100% CPU. I had a second ssh connection open, but su ran several minutes without ever even reaching the password prompt. In the end, I decided that I wouldn't get much more information with such an unresponsive system. I tried an emergency sync via magic sysrequest key, got no beep for it, and pressed reset. When the system was back on line, it had 5 kernel log files, dated within 15 seconds, each about 1MB in size. So the logs had reached the configured limits from metalog, and the original cause of the problem was lost. The kernel log lines filling up those logs looked like this: [18383.180499] emu10k1: unhandled interrupt: 0x00400000 Probably due to the time stamps, they were not collected as repeated messages, but kept filling the logs. Some lines are garbled, missing part of their content, indicating that metalog or the kernel had trouble keeping up. I'm wondering how much the high volume of metalog activity was at least partially cause of this whole issue. Conclusion: * There might be something wrong with the emu10k1 driver in that kernel. If it happens to someone else, we could compare configurations. * There should be a rate limit for metalog. Will write a feature request later.
Please post your "emerge --info" and attach your kernel's config file as well as the output of lspci -nnv to this bug. Do you use the alsa-driver package or the sound-drivers from within the kernel package?
Created attachment 188977 [details] emerge --info
Created attachment 188979 [details] lspci -nnv
Created attachment 188981 [details] kernel .config
(In reply to comment #1) > Do you use the alsa-driver package or the sound-drivers from > within the kernel package? The in-kernel alsa drivers, not the alsa-driver package.
Is this reproducible?
(In reply to comment #6) > Is this reproducible? No, hasn't happened again, and I have no clue what caused it. BTW: I've submitted a rate limiting patch to metalog upstream: http://sourceforge.net/tracker/?func=detail&aid=2777251&group_id=30635&atid=399904
OK. Thanks for reporting, but there's not much we can do in that case. Notified upstream here: http://mailman.alsa-project.org/pipermail/alsa-devel/2009-May/017216.html Please reopen this bug if it reoccurs with any kind of frequency, or if you figure out a way to reproduce it!
btw, you should also report this to the emu10k1 authors. if this is part of the official kernel.org sources, you can use their bug tracker. the driver should be using the printk_ratelimit() helper function
