USB mouse doesn't work on boot

[FreeFull]

When I boot into Haiku with my USB mouse plugged in, the mouse doesn't work until I unplug it and plug it back in. The mouse does receive power, but it doesn't affect the cursor. I have also tested booting with a USB stick plugged in, and Haiku does detect the USB stick without me having to unplug and replug it.

Haiku hrev50317 hybrid USB controller: AMD SB7x0/SB8x0/SB9x0 USB EHCI Controller

[FreeFull]

syslog

[waddlesplash]

Assuming EHCI bug for the time being. If you could provide the output of the listusb command while the computer is started but before you unplug/replug the mouse, that would help us diagnose which component this really belongs to.

[FreeFull]

Here is the output right after boot, before I unplug and replug the mouse:

~/Desktop> listusb
0000:0000 /dev/bus/usb/0/hub "HAIKU Inc." "OHCI RootHub" ver. 0110
03f0:311d /dev/bus/usb/1/1 "Hewlett-Packard" "Atheros AR9285 Malbec Bluetooth Adapter" ver. 0001
0000:0000 /dev/bus/usb/1/hub "HAIKU Inc." "OHCI RootHub" ver. 0110
0000:0000 /dev/bus/usb/2/hub "HAIKU Inc." "OHCI RootHub" ver. 0110
0000:0000 /dev/bus/usb/3/hub "HAIKU Inc." "EHCI RootHub" ver. 0200
04f2:b249 /dev/bus/usb/4/1 "Chicony Electronics Co., Ltd" "HP Webcam-101" ver. 1204
0000:0000 /dev/bus/usb/4/hub "HAIKU Inc." "EHCI RootHub" ver. 0200

Here is the output after replugging the mouse:

0000:0538 /dev/bus/usb/0/0 "" " USB OPTICAL MOUSE" ver. 0100
0000:0000 /dev/bus/usb/0/hub "HAIKU Inc." "OHCI RootHub" ver. 0110
03f0:311d /dev/bus/usb/1/1 "Hewlett-Packard" "Atheros AR9285 Malbec Bluetooth Adapter" ver. 0001
0000:0000 /dev/bus/usb/1/hub "HAIKU Inc." "OHCI RootHub" ver. 0110
0000:0000 /dev/bus/usb/2/hub "HAIKU Inc." "OHCI RootHub" ver. 0110
0000:0000 /dev/bus/usb/3/hub "HAIKU Inc." "EHCI RootHub" ver. 0200
04f2:b249 /dev/bus/usb/4/1 "Chicony Electronics Co., Ltd" "HP Webcam-101" ver. 1204
0000:0000 /dev/bus/usb/4/hub "HAIKU Inc." "EHCI RootHub" ver. 0200

[mmlr]

This is the same as #12409. In both cases there is a continuous loop of detecting a device on EHCI and handing it over to the companion host controller because it is low speed, only for it not to actually arrive there and showing up in EHCI again. Since in the other ticket we have Intel hardware with UHCI whereas here it is AMD with OHCI this suggests that it is indeed a problem of the handover within EHCI and not a failure of the companion host controller driver to "get" the device. In both cases we also have low speed devices (vs. full speed once) which take an earlier exit in the reset path. This might hint in the direction that the port reset should always take place, regardless of the detection of a low speed device which wouldn't be the interpretation of section 4.2 of the EHCI specs that I arrive at. It might also be a problem of not enabling port power explicitly. Other EHCI implementations should be compared. Right now I unfortunately don't have the time to do that.

[mmlr]

(In #12409) I'm going to close this one as a duplicate of #12783. Even though this ticket is older, the new one has the syslog more easily available.

[Ketsuban]

Sorry for the spam. I filed #12409 and would like to be kept abreast of progress here, but I can't find any other way to subscribe but to comment.