Opened 13 years ago

Closed 10 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


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 axeld, 13 years ago

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!

comment:2 by jonas.kirilla, 13 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:3 by luroh, 10 years ago

Any progress here, kirilla?

comment:4 by jonas.kirilla, 10 years ago

Resolution: fixed
Status: newclosed

I'm not using that hardware anymore, but I assume it was fixed a long time ago. Thanks!

Note: See TracTickets for help on using tickets.