Opened 17 years ago
Closed 14 years ago
#1323 closed bug (fixed)
unhandled interrupts
Reported by: | jonas.kirilla | Owned by: | axeld |
---|---|---|---|
Priority: | normal | Milestone: | R1 |
Component: | - General | Version: | R1/pre-alpha1 |
Keywords: | Cc: | ||
Blocked By: | Blocking: | ||
Platform: | All |
Description
Pressing F12 (not crashing) and typing ints:
Welcome to Kernel Debugging Land... Running on CPU 0 kdebug> ints int 0, enabled 1, handled 302944, unhandled 0 int 1, enabled 1, handled 1872, unhandled 0, ACTIVE int 3, enabled 2, handled 16101, unhandled 0 int 7, enabled 1, handled 331, unhandled 0 int 9, enabled 2, handled 0, unhandled 214127 int 10, enabled 2, handled 0, unhandled 0 int 11, enabled 1, handled 46124, unhandled 0 int 12, enabled 2, handled 0, unhandled 0 int 14, enabled 1, handled 6291, unhandled 2 int 15, enabled 1, handled 40, unhandled 0
It doesn't seem to happen all of the time, but when it starts the numbers grow seemingly fast, IMO. Only happens with int 9 on my system, AFAIK.
Change History (4)
comment:1 by , 17 years ago
comment:2 by , 17 years ago
This is with hrev21691 on real hardware, same hardware as with #1322. I think it is the SoundBlaster Live card (emuxki), as restarting the media services reliably stops the unhandled interrupt count from increasing.
However, neither of my audio devices, the integrated auhci and the emuxki, remain in the Media Preferences, having restarted the services. Something is wrong somewhere.
I don't know if it's related but when Haiku has seen some use and the UI responsiveness is clearly degraded, the emuxki media_addon_server thread, IIRC, (at prio 120) consumes a much larger percentage of CPU time than it did on bootup. (~10% vs ~1%). I don't know why this happens. (Can the userland-available timeslice decrease over time, inflating the percentage, or does the thread actually use more CPU time? Just thinking out loud, FWIW.)
comment:4 by , 14 years ago
Resolution: | → fixed |
---|---|
Status: | new → closed |
I'm not using that hardware anymore, but I assume it was fixed a long time ago. Thanks!
Is that with the same hardware exposed by the KDL logs from bug #1322? If so, it's either the sound card or the USB device that produces those. You could remove one or even both drivers serving these devices to see if that helps. I guess this is on real hardware? And can you also add the revision you are using for reference? Thanks!