Opened 12 years ago

Closed 11 years ago

Last modified 11 years ago

#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

  1. Booted from USB stick with "haiku-hrevr1alpha4-44597-releasecandidate-anyboot".
  2. When the Desktop appeared the system halted with a white bar at the top of screen. Maybe an abborted KDL?
  3. 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.
  4. After luckily "overcomming" the "white bar" state the system seems to be usable normally.
  5. That's when I was able to install Haiku to hd.
  6. Booting from hd exactly the same problem appeared again.
  7. 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
  1. 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)

syslog_failed_boot (150.9 KB ) - added by x-ist 12 years ago.
syslog_successful_boot (222.3 KB ) - added by x-ist 12 years ago.
white_bar.JPG (389.3 KB ) - added by x-ist 12 years ago.
unhandled_page_fault.JPG (1.9 MB ) - added by x-ist 12 years ago.
ubuntu_lspci (2.1 KB ) - added by x-ist 12 years ago.
kernel_debugger_freezes.JPG (1.7 MB ) - added by x-ist 12 years ago.

Change History (18)

by x-ist, 12 years ago

Attachment: syslog_failed_boot added

by x-ist, 12 years ago

Attachment: syslog_successful_boot added

by x-ist, 12 years ago

Attachment: white_bar.JPG added

by x-ist, 12 years ago

Attachment: unhandled_page_fault.JPG added

by x-ist, 12 years ago

Attachment: ubuntu_lspci added

comment:1 by umccullough, 12 years ago

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.

in reply to:  1 ; comment:2 by x-ist, 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 x-ist, 12 years ago

Attachment: kernel_debugger_freezes.JPG added

in reply to:  2 ; comment:3 by umccullough, 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.

in reply to:  3 ; comment:4 by x-ist, 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 anevilyak, 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.

in reply to:  4 ; comment:6 by umccullough, 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.

in reply to:  6 comment:7 by x-ist, 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

in reply to:  6 comment:8 by x-ist, 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 x-ist, 12 years ago

Component: Drivers/Network/atheroswifiDrivers/USB
Keywords: OHCI handover IRQ added
Owner: changed from nobody to mmlr

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.

comment:10 by x-ist, 11 years ago

Please close this ticket. It is resolved together with #8987, since hrev44689.

comment:11 by diver, 11 years ago

Resolution: fixed
Status: newclosed

Thanks for the update!

comment:12 by luroh, 11 years ago

Added to R1/Alpha4 in hrevr1alpha4-44643.

Note: See TracTickets for help on using tickets.