Opened 11 years ago

Closed 10 years ago

Last modified 10 years ago

#2662 closed bug (fixed)

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

Reported by: luroh Owned by: mmlr
Priority: normal Milestone: R1/alpha1
Component: - General Version: R1/pre-alpha1
Keywords: Cc: adek336@…, olivier.coursiere@…
Blocked By: Blocking:
Has a Patch: no Platform: All

Description

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.

Attachments (4)

fat_usb_crash.jpg (331.6 KB) - added by luroh 11 years ago.
fat_usbdisk_read-write.txt (74.6 KB) - added by aldeck 11 years ago.
trying to open/browse with tracker
bfs_usbdisk_read-write.txt (39.5 KB) - added by aldeck 11 years ago.
trying to open/browse a newly created folder with tracker
fat.jpg (244.2 KB) - added by kvdman 11 years ago.

Download all attachments as: .zip

Change History (23)

Changed 11 years ago by luroh

Attachment: fat_usb_crash.jpg added

comment:1 Changed 11 years ago by emitrax

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

comment:2 Changed 11 years ago by 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)"

comment:3 Changed 11 years ago by aldeck

Milestone: R1R1/alpha1

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 :)

Changed 11 years ago by aldeck

Attachment: fat_usbdisk_read-write.txt added

trying to open/browse with tracker

Changed 11 years ago by aldeck

Attachment: bfs_usbdisk_read-write.txt added

trying to open/browse a newly created folder with tracker

comment:4 Changed 11 years ago by 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.

comment:5 Changed 11 years ago by Adek336

Cc: adek336@… added

comment:6 Changed 11 years ago by 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'

Changed 11 years ago by kvdman

Attachment: fat.jpg added

comment:7 Changed 11 years ago by 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.

comment:8 Changed 10 years ago by oco

Cc: olivier.coursiere@… added

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

comment:9 Changed 10 years ago by 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'

comment:10 Changed 10 years ago by mmlr

Owner: changed from axeld to mmlr
Status: newassigned

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.

comment:11 Changed 10 years ago by 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

comment:12 Changed 10 years ago by oco

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

comment:13 Changed 10 years ago by 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 !

comment:14 Changed 10 years ago by luroh

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

comment:15 Changed 10 years ago by mmlr

Resolution: fixed
Status: assignedclosed

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

comment:16 Changed 10 years ago by 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!

comment:17 Changed 10 years ago by aldeck

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

comment:18 in reply to:  16 Changed 10 years ago by 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.

comment:19 Changed 10 years ago by 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...

Note: See TracTickets for help on using tickets.