Opened 15 years ago
Closed 14 years ago
#4835 closed bug (fixed)
r33626 causes interrupt trouble
Reported by: | brecht | Owned by: | marcusoverhagen |
---|---|---|---|
Priority: | blocker | Milestone: | R1 |
Component: | Drivers/Disk | Version: | R1/Development |
Keywords: | Cc: | ||
Blocked By: | Blocking: | #4836 | |
Platform: | All |
Description
hrev33626 causes the system to become unresponsive. Syslog reports:
KERN: More than 99% interrupts of vector 11 are unhandled
Attachments (2)
Change History (12)
by , 15 years ago
Attachment: | ata.syslog added |
---|
comment:1 by , 15 years ago
comment:2 by , 15 years ago
FWIW, I am seeing this "KERN: More than 99% interrupts of vector 11 are unhandled" message too in my syslog when using recent trunk revs.
In my case, the system briefly freezes for a few seconds every 10 - 20 seconds; when that happens, one of the CPU core spikes to 100% load and remains there during the few seconds that the system is unresponsive.
This is on hardware that has always worked well with Haiku (last working rev was hrev33574), so it is definitely a recent change that is triggering this to happen.
comment:3 by , 15 years ago
Version: | R1/alpha1 → R1/Development |
---|
I can confirm that #4836 is a dup of this, so I'd appreciate it if someone could mark it.
hrev33625 works fine, hrev33626 exhibits the CPU spikes, and "ints" in KDL shows lots of unhandled interrupts. On my system these are IRQ 10, which is shared with USB, networking and sound. hrev33625 shows 0 unhandled interupts on this IRQ, 33626 shows over 100,000 unhandled within a minute of use. I'd guess this is one of the "interupt storms" mmlr mentions above.
Let me know if you need more debug info (I can compile with tracing if someone can give me some quick instructions on that).
ps: Changed version, as I think the alpha works fine.
comment:4 by , 15 years ago
Blocking: | 4836 added |
---|
comment:5 by , 15 years ago
I'm too seeing the mentioned behaviour, with hda, ata_adapter and uhci on vector 10. See attached file. (KDL 'ints' and some messages from the syslog.)
by , 15 years ago
Attachment: | serial_kdl_and_log_r33768_kirilla.txt added |
---|
comment:6 by , 15 years ago
Same problem here with an ICH7 chipset. Eventually, Haiku will lock up completely.
comment:7 by , 15 years ago
Priority: | high → blocker |
---|
comment:10 by , 14 years ago
Resolution: | → fixed |
---|---|
Status: | new → closed |
Since enabling interrupts is now done earlier, i.e. before device selection and writing the command, the devices might just fire interrupts on selection/writing the command which we don't "expect" yet. We do unconditionally read the status register to acknowledge in this case though to avoid generating interrupt storms. Still it could explain the output, as we also return B_UNHANDLED_INTERRUPT in such a case because we have no way of figuring out if it was our interrupt.