Opened 8 years ago

Last modified 5 months ago

#7669 in-progress bug

SCSI sync command hangs usb mass storage device

Reported by: pulkomandy Owned by: mmlr
Priority: normal Milestone: R1
Component: Drivers/Disk/USB Version: R1/Development
Keywords: Cc:
Blocked By: Blocking: #7673
Has a Patch: no Platform: All


I have a cheap MP3 player that works as an usb mass storage device. However, it seems it's too slow for Haiku to handle. When I plug it I get a panic : "Could not write back block nnn (operation timed out)"

I think the timeout delay should be increased to avoid this.

Currently running on pre-alpha3, up to 41941 merged from trunk.

Attachments (1)

P1100427.JPG (1.8 MB) - added by pulkomandy 8 years ago.
Panic and backtrace.

Download all attachments as: .zip

Change History (8)

Changed 8 years ago by pulkomandy

Attachment: P1100427.JPG added

Panic and backtrace.

comment:1 in reply to:  description Changed 8 years ago by mmlr

Owner: changed from marcusoverhagen to mmlr
Status: newin-progress

Replying to pulkomandy:

I think the timeout delay should be increased to avoid this.

The timeout is at 10 seconds right now, but the problem is that it is a fixed timeout, one that doesn't actually take the amount of data (or any other factors like slower partial block reads/writes) into account. In principle the timeout could be removed completely, I put it in there to avoid systems just hanging without an indication of what's going on. If it actually failed and the device stalled/stopped, it'll be stopped after 20, 30 seconds still, so increasing the timeout to some rather large value should be fine as well. I'd just hate to see people getting impatient and writing bug reports about generic hangs or worse yet no bug reports at all. A panic like this usually is easier to report.

I'll see about increasing the timeout at least in the alpha branch. However I'd not rule out that in your case there actually is a problem and the device stalled, or that there is a problem that makes the device so slow in the first place. So the panic might not be unjustified.

comment:2 Changed 8 years ago by korli

Blocking: 7673 added

comment:3 Changed 7 years ago by sepp

i hit the exact same bug with hrev42807 but for some reason it does not occur with the gcc4 hybrid build (same version). My hardware eee pc 701

comment:4 Changed 7 years ago by pulkomandy

Summary: Agressive timeout fails on slow USB deviceSCSI sync command hangs usb mass storage device

After a try to increase the timeout, I still got the bug. Further investigagion at BeGeistert showed that the problem is actually elsewhere. The SCSI Sync (0x35) command hangs this device. We notice it and won't use it again after the first try, but it's too late, the device is hanged and won't answer to anything else after that. Seems we need a quirk to reset the device or something.

Listusb for that device :

10d6:1101 /dev/bus/usb/4/0 "" "USB MASS STORAGE CLASS " ver. 0100

This device is an "s1mp3" MP3 player. It uses a fairly widespread chip (AK1025). I expect any device from the same vendor (10d6, Actions Ltd), to have the same problem.

comment:5 Changed 4 years ago by ithamar

We might have to consider (as much as I hate it) to have some kind of quirks / blacklist in the usb_disk driver or so to prevent certain devices from locking up like this. We had to resort to that in ZETA as well, to keep a large number of USB devices from locking up like this.

comment:6 Changed 4 years ago by pulkomandy

Some updates here. I tried your changes to handle the device stall more properly. The device still gets confused and apparently powers itself off or enters some kind of debug mode (I know there is a "firmware upgrade" mode reachable by sending specific SCSI commands to it).

After this, I get the "could not write back block" error only as a syslog message. Then I pressed "stop" in Tracker to stop the copy, and at that point I got a NULL pointer dereference in the FAT filesystem (_fat_ioctl_ does a memcpy with a NULL pointer).

Adding a quirk for this device is fine, but even without that, we should make sure the system doesn't crash. We made a small step towards that, but it may need some extra efforts before the error gets up to Tracker and can be reported as a BAlert.

comment:7 Changed 5 months ago by pulkomandy

Component: Drivers/DiskDrivers/Disk/USB
Note: See TracTickets for help on using tickets.