Opened 4 years ago

Closed 15 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

  1. Run USB watcher program (for example USBDeskbar or the attached sample code)
  2. Insert USB device
  3. 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)

syslog.txt (226.9 KB ) - added by madmax 4 years ago.
Full syslog with insert and removal and then again with the watcher running
watch.cpp (571 bytes ) - added by madmax 4 years ago.
Simple watcher program
kdl.txt (6.6 KB ) - added by madmax 4 years ago.
Relevant parts of the KDL session

Download all attachments as: .zip

Change History (9)

by madmax, 4 years ago

Attachment: syslog.txt added

Full syslog with insert and removal and then again with the watcher running

by madmax, 4 years ago

Attachment: watch.cpp added

Simple watcher program

comment:1 by waddlesplash, 4 years ago

Component: - GeneralDrivers/USB
Owner: changed from nobody to mmlr

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:2 by X512, 4 years ago

SystemManager can be also useful to investigate locks.

by madmax, 4 years ago

Attachment: kdl.txt added

Relevant parts of the KDL session

comment:3 by madmax, 4 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 waddlesplash, 3 years ago

Priority: normalhigh

comment:5 by waddlesplash, 15 months ago

Perhaps this was fixed by hrev57061?

comment:6 by madmax, 15 months ago

Milestone: UnscheduledR1/beta5
Resolution: fixed
Status: newclosed

So it seems, I can't reproduce it anymore. Thank you.

Note: See TracTickets for help on using tickets.