Opened 3 years ago
Closed 8 months ago
#16691 closed bug (fixed)
Lock when watching USB devices on removal
| Reported by: | madmax | Owned by: | mmlr |
|---|---|---|---|
| Priority: | high | Milestone: | R1/beta5 |
| Component: | Drivers/USB | Version: | R1/beta2 |
| Keywords: | Cc: | ||
| Blocked By: | Blocking: | ||
| Platform: | All |
Description
hrev54805 x86_64
- Run USB watcher program (for example USBDeskbar or the attached sample code)
- Insert USB device
- Remove device
Got the same result with a flash "disk" and a keyboard, I guess the type of device is not important.
It's not a full desktop lock. The pointer moves, windows get focus, you can invoke KDL and even the task list with Ctrl-Alt-Supr. But you can't launch new apps (or at least they don't get a window drawn; I can see a Terminal entry in Deskbar when launching it with a key combo, and they appear in ProcessController if it is still responsive) and you can't quit or kill current ones (or at least it doesn't get reflected in the tasklist). Sooner or later the whole Deskbar freezes.
Only happens if the program asks to notified of removals, and after it is notified (that is, REMOVE is pronted in the sample program).
Might be related to #14835. I get similar errors, but also when not watching devices and I'm not locked there, so I guess it's not a dupe. The patches linked in that report https://review.haiku-os.org/c/haiku/+/1424 do not help here.
Attachments (3)
Change History (9)
by , 3 years ago
| Attachment: | syslog.txt added |
|---|
comment:1 by , 3 years ago
| Component: | - General → Drivers/USB |
|---|---|
| Owner: | changed from to |
This sounds like multiple bugs, to me; a deadlock in usb_raw should not cause the entire OS to lock up, only the relevant applications. If you can drop into KDL, see if you can find what all those applications get stuck waiting on, and then who is holding it (via bt and then mutex/semaphore/cvar/etc. commands.)
comment:3 by , 3 years ago
It seems we have the BUSBRoster looper waiting for the legacy driver mutex, which is held by the usb explore thread, that is waiting on the devfs lock mutex, that is held by the BUSBRoster looper. This is when the BUSBRoster is removing a WatchedEntry leading to closing the file descriptor of the USB device, if I'm reading it correctly.
comment:4 by , 3 years ago
| Priority: | normal → high |
|---|
comment:6 by , 8 months ago
| Milestone: | Unscheduled → R1/beta5 |
|---|---|
| Resolution: | → fixed |
| Status: | new → closed |
So it seems, I can't reproduce it anymore. Thank you.
Full syslog with insert and removal and then again with the watcher running