FAT USB stick problem: "PANIC: could not write back block 7908 (General system error)"

[luroh]

When double clicking a USB disk (FAT formatted) icon, Haiku panics. cd'ing to the USB stick in the Terminal and then running ls works fine.

Running on real hardware (Lenovo T60 laptop), booted from a USB stick, hrev27178.

[emitrax]

I have the same error, but when mounting it in read only mode it works fine.

[luroh]

I confirm, read-only works fine.
Having spent some quality time with this ticket, I have tracked down some notable revision ranges that may or may not be of any help:

26000-26600: shows files on the stick
26900-27127: doesn't show any files on the stick
27128-27129: KDL (1)
27130-28005: KDL (2)

(1) "PANIC: ASSERT FAILED (src/system/kernel/fs/vfs.cpp:5163): entry->d_reclen >= sizeof(struct dirent)"
(2) "PANIC: could not write back block xxxx (General system error)"

[aldeck]

Happens here too since a few months:

"PANIC: could not write back block 493 (Operation timed out)" That's always the block 493, on the same usb stick. See attached serial log (was testing on hrev28274).

See also some of my comments in #2639.

a) I could succesfully read and write from the terminal, although very slow ex: 7sec for ls. In read only mode, it's much faster.

b) Trying to browse from tracker produces the panic.

c) Accessing the mount menu from context menu makes it unmount instantly without panicking, but producing several lines like this in the syslog:

[...]
KERN: usb_disk: receiving the command status wrapper failed
KERN: usb_uhci: td (0x0218e3c0) error: status: 0x394007ff; token: 0x01808969;
KERN: usb_uhci: td (0x0218e420) error: status: 0x394007ff; token: 0x01888969;
KERN: usb_disk: receiving the command status wrapper failed
KERN: usb_uhci: td (0x0218e7e0) error: status: 0x394007ff; token: 0x01808969;
KERN: usb_uhci: td (0x0218e840) error: status: 0x394007ff; token: 0x01888969;
[...]

I made an image of the usb stick with dd and mounted it as a disk in vmware, it works in read-write, so the fat filesystem on the stick appears to be ok. I will try with a bfs filesystem.

I'd really like to help digging this one as it's an important one IMO, flagging as R1/alpha1, feel free to disagree :)

[aldeck]

trying to open/browse with tracker

[aldeck]

trying to open/browse a newly created folder with tracker

[aldeck]

mounting a bfs usb stick read-write and opening it in the tracker works, but i had this panic trying to enter a freshly created directory on the stick. See attached log.

[kvdman]

I also get a crash when trying to write data to a FAT32 partition from tracker. Tested on real hardware and Vmware, with a SD card, and external hard drive. Attached 'fat.jpg'

[aldeck]

Tried again with hrev28514 . (not sure those changes are related though) But now i can't mount at all from tracker, it deadlocks trying to show the submenu (list of devices).

Had a quick look from kdl, not sure it's relevant, but the popup menu thread is blocking due to a call to get_device_icon on devfs_lookup.

[oco]

I think i have a simpler test case to reproduce this problem. I use a USB hard drive.

• initialize a 20 Go partition with DiskDrive (bfs with 2048 block size).
• mount this partition with read/write support
• put bonnie++ in a "test" directory on this new partition
• run bonnie++ in this directory with "bonnie++ -d . -u baron"
• once bonnie++ is launched then right click on the Desktop to browse the test partition.

The menu take some time to draw and after a few second, bonnie++ show an error : Can't putc() - disk full? A few second later, Haiku enter KDL with PANIC: could not write back block 65 (General system error)

Partial stack trace :
write_cached_block
block_notifier_and_writer
_create_kernel_thread_kentry
thread_kthread_exit

Tested with hrev28723

[kvdman]

I can duplicate that exactly when trying to access a FAT32 partition on an SD disk through my EeePC's card reader using tracker (through Terminal it works).

'could not write back block 65; bytes read: -1; error: General system error'

[mmlr]

Could you all please try with a revision >= 28930. hrev28929 fixed a problem that would cause many devices to never recover from error conditions. Also hrev28930 fixes a problem that could mess up active transfers and adds some more robustness.

[oco]

I still can reproduce the bonnie++ problem with the same error. Maybe, it took a little longer to crash the system.

Tested in hrev28915

[oco]

Oh sorry ! Don't see last change in the source tree... Will retry ASAP...

[oco]

After updating the usb bus manager and the usb disk driver, the problem is gone ! I can navigate all my partitions while bonnie++ still running.

Thank you mmlr !

[luroh]

Tried 28930 with exactly the same set of hardware and I can no longer repeat the original problem. Thanks!

[mmlr]

Great, thanks a lot for the quick feedback. Closing this one now.

[aldeck]

Kudos Michael, testing on real hw and vmware, read/write works perfectly.

All the problems are gone, except one (i think its another bug, iirc i mentioned it in another ticket), i can't unmount then mount the usb stick a second time via tracker, the context menu stays on screen, tracker is locked with no cpu usage. Don't have the time to investigate yet.

Kudos again!

[aldeck]

oh there it is, the problem was mentioned in this ticket, comment #7 :)

[mmlr]

Replying to aldeck:

All the problems are gone, except one (i think its another bug, iirc i mentioned it in another ticket), i can't unmount then mount the usb stick a second time via tracker, the context menu stays on screen, tracker is locked with no cpu usage. Don't have the time to investigate yet.

Yup, that was a stupid oversight fixed in hrev28934. Note though that unmounting will cause an eject event if you have "Eject when unmounting" selected in the Tracker preferences. This will cause the device to receive a stop unit and the volume will not be available anymore until you un- and replug the device.

[aldeck]

Just tested on vmware and real hw, it's fixed indeed :) As for the "Eject when unmounting" thing, thanks for the info, i was wondering...