Opened 9 years ago

Last modified 9 months ago

#6041 new bug

Haiku hangs on boot with wireless keyboard+mouse

Reported by: franxico Owned by: mmlr
Priority: normal Milestone: R1
Component: Drivers/USB Version: R1/alpha2
Keywords: boot-failure Cc:
Blocked By: Blocking:
Has a Patch: no Platform: x86

Description

Haiku Alpha 2 hangs after the 4th icon. Sensor leds go on and then boot process stops.

I had the same problem in the past. It used to work unplugging the USB sensor during boot time. It doesn't work anymore. Tried every safe mode option. It's a Logitech Cordless Desktop EX110 on a Dell Vostro 410.

Hopefully I could install Haiku and safe debug info.

Attachments (2)

tmp.zip (744 bytes) - added by franxico 9 years ago.
USB_HID debug information
haiku debug franxico.zip (2.6 MB) - added by franxico 8 years ago.
Pictures - Debug info

Change History (9)

Changed 9 years ago by franxico

Attachment: tmp.zip added

USB_HID debug information

comment:1 Changed 9 years ago by franxico

Hi. Should I give more info? Maybe debug pictures? Thanks

comment:2 Changed 8 years ago by scottmc

Can you recheck this with a recent Haiku build?

comment:3 Changed 8 years ago by scottmc

Blocking: 7665 added

comment:4 Changed 8 years ago by franxico

Just tried the hrev42190 booting from CD. Still same thing. Tried some safe mode options, but it hangs always on the 4th icons. Do you want debug info pictures? Thanks for the help!

Changed 8 years ago by franxico

Attachment: haiku debug franxico.zip added

Pictures - Debug info

comment:5 Changed 8 years ago by mmlr

Please attach photos individually in the future, resizing them so that they are < 500k if possible. This makes it possible to look at them directly from trac and greatly increases the likelihood of someone looking at them.

In this case, what happens seems to be a lot of unhandled interrupts on UHCI startup, leading to IRQ 19 being disabled. That one is shared between the SATA, IDE and two UHCI controllers. The disable happens before all UHCI controllers are fully initialized which probably explains why the interrupt is disabled, as the controller driver that would handle them isn't yet installed. Since we don't yet re-enable an IRQ when a new handler is installed, the disabled IRQ sticks and probably causes the SATA or IDE controller to fail later on, stalling the boot process.

It's difficult to handle differently. A possibility would be to scan the USB controllers first, initializing them only to the point where the interrupts can be masked, do that for all controllers and only do the full initialization in a second step. The other way (and this one will have to be implemented anyway) is to just re-enable a disabled IRQ whenever a new handler is installed. This still has the problem that there will be an interrupt storm early on (until the IRQ is disabled eventually) which'll introduce needless delays.

comment:6 Changed 9 months ago by waddlesplash

Keywords: boot-failure added

comment:7 Changed 9 months ago by waddlesplash

Blocking: 7665 removed
Note: See TracTickets for help on using tickets.