#8984 closed bug (fixed)
More than 99% interrupts of vector 18 are unhandled
Reported by: | x-ist | Owned by: | mmlr |
---|---|---|---|
Priority: | normal | Milestone: | R1 |
Component: | Drivers/USB | Version: | R1/Development |
Keywords: | OHCI handover IRQ | Cc: | |
Blocked By: | Blocking: | ||
Platform: | x86 |
Description
This is haiku-hrevr1alpha4-44597.
Tested on
Acer Aspire 7551G Phenom N390 2GHz
WiFi: Atheros Communications Inc. AR928X Wireless Network Adapter
- Booted from USB stick with "haiku-hrevr1alpha4-44597-releasecandidate-anyboot".
- When the Desktop appeared the system halted with a white bar at the top of screen. Maybe an abborted KDL?
- After trying different boot options I noticed that often (not allways) the system boots to a usable state when user addons are disabled. Mostly I get so see the white bar.
- After luckily "overcomming" the "white bar" state the system seems to be usable normally.
- That's when I was able to install Haiku to hd.
- Booting from hd exactly the same problem appeared again.
- Long story short I have now two syslogs, one for a failed boot and a successful (so to say) boot.
The logs show lots of issues with "atheroswifi":
KERN: More than 99% interrupts of vector 18 are unhandled KERN: [net/atheroswifi/0] ieee80211_ref_node (ieee80211_send_probereq:1748) 0x827f2000<78:e4:00:15:57:07> refcnt 3 KERN: More than 99% interrupts of vector 18 are unhandled KERN: [net/atheroswifi/0] ieee80211_ref_node (ieee80211_send_probereq:1748) 0x827f2000<78:e4:00:15:57:07> refcnt 3 Last message repeated 1 time KERN: More than 99% interrupts of vector 18 are unhandled
- After one of the successful boot attempts I tried to connect to my wifi AP and after entering the credentials the system entered KDL with a "unhandled page fault".
Attachments (6)
Change History (18)
by , 12 years ago
Attachment: | syslog_failed_boot added |
---|
by , 12 years ago
Attachment: | syslog_successful_boot added |
---|
by , 12 years ago
Attachment: | white_bar.JPG added |
---|
by , 12 years ago
Attachment: | unhandled_page_fault.JPG added |
---|
by , 12 years ago
Attachment: | ubuntu_lspci added |
---|
follow-up: 2 comment:1 by , 12 years ago
follow-up: 3 comment:2 by , 12 years ago
Replying to umccullough:
That suggests perhaps you have installed something in addition to the default drivers. Perhaps you have installed a bad driver which is conflicting with the atheros driver? Do you have any hardware that is sharing interrupts?
Nothing additional installed. This is a fresh Haiku installation.
You can go to kernel debugger and type "ints" to find out what hardware is on which interrupts - that might help narrow down any other offending hardware and/or drivers.
Did that. See the screenshot. At that stage the system freezes including the keyboard.
by , 12 years ago
Attachment: | kernel_debugger_freezes.JPG added |
---|
follow-up: 4 comment:3 by , 12 years ago
Replying to x-ist:
Nothing additional installed. This is a fresh Haiku installation.
Are these images you're building yourself? If so, I'd be curious to see what your UserBuildConfig looks like (to see which optional packages you're including).
Did that. See the screenshot. At that stage the system freezes including the keyboard.
Can you actually pass a command to the debugger from the terminal? I've never tried that.
In any case, are you using a USB keyboard? That could be the cause of your KDL "freeze" - since it doesn't always work with USB keyboards depending on your USB controller. The lack of "ints" output implies that the command didn't execute.
follow-up: 6 comment:4 by , 12 years ago
Replying to umccullough:
Are these images you're building yourself? If so, I'd be curious to see what your UserBuildConfig looks like (to see which optional packages you're including).
I got the image from http://www.haiku-files.org/haiku/development/haiku-hrevr1alpha4-44597-releasecandidate-anyboot.tar.xz Did dd to USB stick. That's it.
Can you actually pass a command to the debugger from the terminal? I've never tried that.
It was not the first time I tried using kernel_debugger, which then froze the system. So I figured I should pass "ints" as parameter :)
In any case, are you using a USB keyboard? That could be the cause of your KDL "freeze" - since it doesn't always work with USB keyboards depending on your USB controller.
Indeed I use a USB keybaord, but just for the sake of convenience. The built-in notebook-keyboard does not work as well. However, I could try to boot with the keyboard unplugged. IIRC there was once a post in the ML stating that in KDL only PS2 keyboards are working, but maybe I'm confusing something here.
The lack of "ints" output implies that the command didn't execute.
Either that or the kernel_debugger does not (yet) process command parameters?
comment:5 by , 12 years ago
That command's purpose is simply to enter the kernel debugger, nothing more. It doesn't pass along another command, the parameter it takes is simply a message to print. It's expected that the commands would be entered at the actual debugger prompt, but that's of course problematic if your keyboard doesn't work in it.
follow-ups: 7 8 comment:6 by , 12 years ago
Replying to x-ist:
It was not the first time I tried using kernel_debugger, which then froze the system. So I figured I should pass "ints" as parameter :)
You do realize that "kernel_debugger" puts you into the kernel debugger...which is supposed to freeze the entire system. Once in KDL, you can only use a keyboard (PS2 usually, but some USB keyboards if you have a certain type of USB controller).
Once in kdebug, you will need to use your laptop's built-in keyboard probably. Either that or try entering KDL using the ALT+SysRq+D command instead.
The lack of "ints" output implies that the command didn't execute.
Either that or the kernel_debugger does not (yet) process command parameters?
Right, it looks like the <message> parameter is simply to publish a message once the kernel_debugger enters KDL... nothing more.
Please run the "ints" command from the kdebug> prompt instead. As mentioned above, you may need to do this using a non-USB keyboard.
comment:7 by , 12 years ago
You do realize that "kernel_debugger" puts you into the kernel debugger...which is supposed to freeze the entire system. Once in KDL, you can only use a keyboard (PS2 usually, but some USB keyboards if you have a certain type of USB controller).
Here is the issue it seems: Without the USB keyboard (which is in fact a wireless keyboard + mouse combo) Haiku boots fine (yeah :)), but the built-in keyboard still doesn't work! Hence I can't enter anything in KDL, which led me to the wrong conclusion KDL itself was frozen too.
Now can it be assumed that the built-in keyboard is being "blocked" by something (atheros wifi maybe)?
At least I just saw in the syslog the following line:
KERN: ps2: initial setup of command byte failed
comment:8 by , 12 years ago
Is there something I can do now? The built-in touchpad and keyboard on the laptop do not work. My idea was to make a debug built of the PS2 driver to get some more info in the syslog. Suggestions?
comment:9 by , 12 years ago
Component: | Drivers/Network/atheroswifi → Drivers/USB |
---|---|
Keywords: | OHCI handover IRQ added |
Owner: | changed from | to
For the notes:
See the log https://dev.haiku-os.org/attachment/ticket/8987/syslog_ohci_debug
USB OHCI is working on IRQ 18.
Then "usb error ohci -1: smm does not respond. resetting..." is reported.
The system stops responding somewhere between the lines 830 - 840 in syslog when using debug screen logging.
As suggested by mmlr in http://dev.haiku-os.org/ticket/8987#comment:5 that might be a problem in handover from SMM to USB OHCI.
It boots more often with user addons disabled?
That suggests perhaps you have installed something in addition to the default drivers. Perhaps you have installed a bad driver which is conflicting with the atheros driver? Do you have any hardware that is sharing interrupts?
You can go to kernel debugger and type "ints" to find out what hardware is on which interrupts - that might help narrow down any other offending hardware and/or drivers.