#14096 closed bug (duplicate)
USB mouse stops working when moving mouse during haiku start up
Reported by: | andreas_dr | Owned by: | nobody |
---|---|---|---|
Priority: | normal | Milestone: | Unscheduled |
Component: | Drivers/USB/XHCI | Version: | R1/Development |
Keywords: | Cc: | ||
Blocked By: | #13767 | Blocking: | |
Platform: | All |
Description
This sounds strange, but it really happens from time to time. If I am moving mouse during haiku start up (shortly after app server started and still busy loading) my USB mouse stops working.
If you need any additional information do not hesitate to ask.
Attachments (2)
Change History (13)
comment:1 by , 7 years ago
Component: | - General → Drivers/USB/XHCI |
---|
comment:2 by , 7 years ago
by , 7 years ago
Attachment: | haiku-51883-syslog-usb-bug.txt.txt added |
---|
comment:3 by , 7 years ago
Hi,
its even reproducable. I have this issue with rev 51883 and older revisions.
Many thanx and
Best regards Andras
comment:5 by , 7 years ago
It looks like some transfers time out and they are not correctly retired/cleaned up inside the XHCI bus driver. This then leads to a state where the maximum number of concurrent active transfers is reached and no further transfers can be scheduled. This is probably an missing/incomplete or buggy error code path.
comment:6 by , 7 years ago
Confirmed with hrev51894 x86 using AMD SB4x0 host controller (see syslog). ~> uname -a Haiku shredder 1 hrev51894 Apr 22 2018 17:05:26 BePC x86 Haiku ~> listimage |grep driver
59 0x81f7a000 0x81f81000 0 0 /boot/system/add-ons/kernel/drivers/disk/virtual/ram_disk 69 0x81bd5000 0x81bde000 0 0 /boot/system/add-ons/kernel/drivers/dev/tty 70 0x81cf6000 0x81cf7000 0 0 /boot/system/add-ons/kernel/drivers/dev/null 71 0x81d1b000 0x81d1d000 0 0 /boot/system/add-ons/kernel/drivers/dev/console 72 0x81cca000 0x81ccb000 0 0 /boot/system/add-ons/kernel/drivers/dev/zero 73 0x81d1e000 0x81d1f000 0 0 /boot/system/add-ons/kernel/drivers/dev/dprintf
769 0x81f44000 0x81f46000 0 0 /boot/system/add-ons/kernel/drivers/power/acpi_button
1465 0x81c8f000 0x81c93000 0 0 /boot/system/add-ons/kernel/drivers/dev/graphics/vesa 1519 0xddd13000 0xddd35000 0 0 /boot/system/add-ons/kernel/drivers/dev/net/broadcom570x 1621 0x82527000 0x82536000 0 0 /boot/system/add-ons/kernel/drivers/dev/graphics/radeon 2189 0x81d13000 0x81d15000 0 0 /boot/system/add-ons/kernel/drivers/dev/input/wacom 2817 0xddd61000 0xddd63000 0 0 /boot/system/add-ons/kernel/drivers/dev/bus/usb_raw
~>
comment:7 by , 7 years ago
Component: | Drivers/USB/XHCI → Drivers/USB |
---|---|
Owner: | changed from | to
Ah yes, an SB400. The SB400/600 chipsets have always been problemantic. The syslog shows that there is an initial timeout that then gets things stuck and the USB drive ejected. These issues are usually related to undelivered interrupts, but it's hard to tell if this is the case here.
comment:8 by , 6 years ago
Component: | Drivers/USB → Drivers/USB/XHCI |
---|---|
Owner: | changed from | to
Platform: | x86-64 → All |
That issue also looks entirely unrelated to the one in this ticket, which is definitely an XHCI bug.
comment:9 by , 6 years ago
Please retest under a recent nightly; quite a lot of XHCI issues were resolved recently.
comment:10 by , 6 years ago
Blocked By: | 13767 added |
---|---|
Resolution: | → duplicate |
Status: | new → closed |
comment:11 by , 5 years ago
Remove milestone for tickets with status = closed and resolution != fixed
Please attach a syslog, found in /var/log, to the ticket. It may show what is going on. Also, what revision of Haiku did you encounter this with?