Rockbox

This is the bug/patch tracker for Rockbox. Click here for more information.

Quick links: Bugs · Patches · Rockbox frontpage

Tasklist

FS#10011 - The USB disconnect feature disconnects without prior ejecting or savely removing in Windows

Attached to Project: Rockbox
Opened by Martin Ritter (MartinR) - Thursday, 12 March 2009, 11:17 GMT+2
Last edited by Frank Gevaerts (fg) - Wednesday, 09 September 2009, 20:34 GMT+2
Task Type Bugs
Category Operating System/Drivers
Status Closed
Assigned To No-one
Player Type Sansa e200
Severity Low
Priority Normal
Reported Version Daily build (which?)
Due in Version Undecided
Due Date Undecided
Percent Complete 100%
Private No

Details

The USB disconnect feature introduced in r20244 disconnects even if the drives are currently in use by Windows. Unlike said in the manual, no eject or savely remove is needed. When pressing Select while copying a file from DAP to PC, it immediately leaves the USB screen and I can browse the menu while the copy operation still goes on. Right after the file has finished (no corruption), the drives get inaccessible.

Also, this feature doesn't respect the 'First Keypress Enables Backlight Only' option. I used to press Select to turn on the backlight to see how far the charging is (or to test the backlight fading). This now kicks me out of MSC mode every time.
This task depends upon

Closed by  Frank Gevaerts (fg)
Wednesday, 09 September 2009, 20:34 GMT+2
Reason for closing:  Fixed
Additional comments about closing:  Disconnect was removed a while ago
Comment by Frank Gevaerts (fg) - Thursday, 12 March 2009, 22:31 GMT+2
The current code releases locks when a bus reset occurs. That's probably not a very smart thing to do (I'll fix). For some reason some people are seeing those again...
The second issue is because I just check for button status in the USB screen event loop, I don't actually get a button press from the button queue. I wouldn't mind (someone) doing this differently, but I definitely don't know much about UI code
Comment by Frank Gevaerts (fg) - Friday, 13 March 2009, 22:15 GMT+2
Can you check if this patch fixes the locking issue?
   unlock.diff (1.5 KiB) 
 firmware/usbstack/usb_storage.c |   33 +++++++++++++++++++--------------
 1 file changed, 19 insertions(+), 14 deletions(-)

Comment by Martin Ritter (MartinR) - Monday, 16 March 2009, 10:41 GMT+2
Unfortunately, your patch doesn't change anything for me. I investigated a bit and found out that Windows uses SCSI_ALLOW_MEDIUM_REMOVAL only during write operations. So, the code actually behaves as intended, but Windows doesn't.
Comment by Martin Ritter (MartinR) - Thursday, 19 March 2009, 10:10 GMT+2
Some thoughts about this. Windows seems to put the device in suspend mode on "safely removing". USBSTS_SUSPEND is set and USBINTR_DEVICE_SUSPEND is fired then.
IIUC, we should be able to automatically leave MSC mode if either all LUNs are ejected or the USB controller enters suspend mode. But Linux usually doesn't suspend the device on dismounting. We would still have to use the button there. But as Windows doesn't lock the LUNs properly, the button has to be blocked with Windows. So we would need to distinguish between Windows and Linux within Rockbox, which I think is somehow fishy.

Loading...