Deskbar freezes opening "Mount" menu after attaching unlocked ExFAT SD card reader

[jckarter]

On hrev58314, I tried the following:

• Attach a USB SD card reader, containing a 64GB ExFAT volume, where the SD card's lock switch is off (allowing writing).
• Click the feather button on the Deskbar, then try to open the Mount menu to mount the card.

The Deskbar freezes until either the USB card reader is detached, or after some timeout apparently occurs, leaving the SD card volume not found. If I try to mount the SD card locked, though, it appears to mount properly.

[jckarter]

Copy of the syslog, after several attempts to attach and detach the exFAT SD volume, with and without write locking.

[waddlesplash]

I see a number of EHCI errors in the syslog, but they appear to be before the usb_disk driver identifies the device and then after it's unplugged (in the latter case these are probably expected.)

The EXFAT driver doesn't have write support at all, so the underlying device being read-only or read-write should not make a difference. This sounds like a bug in the USB disk driver or the EHCI layer, probably the former.

[jckarter]

Not sure if this is Deskbar- or exFAT-specific, after doing some more experimentation. DriveSetup also appears to be stuck while the unlocked SD card is attached.

[waddlesplash]

#17287 seems related, but that was reported fixed after some refactors in the USB disk driver.

[waddlesplash]

Running a "tail -f" on the syslog in a Terminal window before opening Deskbar may be interesting; if the SD card reads are very slow for some reason, then the partition identification could just be taking longer than expected and thus the Deskbar hangs fetching the partition list.

If that's not it, then dropping to KDL (presuming you have a keyboard that works in KDL; either PS/2 or most USB keyboards, but there's caveats) via the keyboard shortcut Alt+SysRq+D and then poking around would be interesting. You'll want to find the hung Deskbar thread, backtrace it, and then get the backtrace of whatever thread holds the lock or condition it's waiting for, to see what it's actually stuck on. Then just "continue" from the KDL prompt; the KDL session should be written into the syslog.

Probably that KDL session will look something like this:

Keyboard Requested Halt.
Welcome to Kernel Debugging Land...
Thread 2 "idle thread 2" running on CPU 1
kdebug> teams | grep Deskbar
0xffffffff828a2800    114  0xffffffff828a4600  Deskbar
kdebug> threads 114
thread                 id  state     wait for  object              cpu pri  stack              team  name
0xffffffff8fad37c0    114  waiting   cvar:port 0xffffffff8fb6b518    -  10  0xffffffff82093000  114  Deskbar
0xffffffff8feba600    151  zzz                                       -   5  0xffffffff82742000  114  TrackerTaskLoop
0xffffffff82ad0000    172  waiting   cvar:port 0xffffffff8fb69b60    -  20  0xffffffff827c2000  114  _BMediaRoster_
0xffffffff90276f40    175  zzz                                       -   5  0xffffffff827d1000  114  Expando Window Watcher
0xffffffff90274600    178  waiting   cvar:port 0xffffffff8fb26820    -  15  0xffffffff827e0000  114  w>Twitcher
0xffffffff90273840    179  waiting   cvar:port 0xffffffff8fb80590    -  15  0xffffffff827ec000  114  w>Deskbar
kdebug> bt 179
stack trace for thread 179 "w>Deskbar"
    kernel stack: 0xffffffff827ec000 to 0xffffffff827f1000
      user stack: 0x00007f6fc4641000 to 0x00007f6fc4681000
frame                       caller             <image>:function + offset
 0 ffffffff827f0c00 (+  80) ffffffff8027ba10   <kernel_x86_64> arch_thread_context_switch + 0x170
 ...
kdebug> cvar 0xffffffff8fb80590
condition variable 0xffffffff8fb80590
  object:  0xffffffff8fb80508 (port read)
  threads: 179

Of course in your case the thread will be waiting on something besides "cvar:port"; probably a mutex or an rwlock (or at least an I/O condvar.) Use the "mutex" or "rwlock" commands rather than "cvar" in that case (or check "help" for other relevant commands.)