Opened 13 years ago

Closed 12 years ago

Last modified 12 years ago

#3690 closed bug (fixed)

KDL when copying data to a FAT USB flash drive

Reported by: haiqu Owned by: axeld
Priority: critical Milestone: R1/alpha2
Component: File Systems/FAT Version: R1/Development
Keywords: Cc: beos.zealot@…, joe.prostko+haiku@…, Jens.Arm@…, lurohh@…, romain.haiku@…
Blocked By: Blocking: #4066, #5362
Platform: x86

Description (last modified by phoudoin)

Drag and drop a zipfile to my Toshiba 2Gb flash drive and the following crash message appears:

PANIC: ASSERT FAILED (src/add-ons/kernel/file_systems/fat/fat.c: 380) cluster != 0

I tried this with the flash drive formatted for both FAT and FAT32 and got the same results.

Attachments (5)

usb-flash-drive-FAT_KDL-on-write.jpg (336.1 KB ) - added by beos_zealot 13 years ago.
100_2604.jpg (285.9 KB ) - added by apn4m3rdrock 13 years ago.
KDMP on VFAT to VFAT file copy (hrev32063)
haikukernelpanicflashcopy.jpg (419.9 KB ) - added by damoklas 13 years ago.
MoveTask on flash kernel panic
fat_mirror.diff (633 bytes ) - added by romain 12 years ago.
dosfs_dir_flags.diff (307 bytes ) - added by romain 12 years ago.
Fix bad flags set

Download all attachments as: .zip

Change History (37)

comment:1 by haiqu, 13 years ago

Just tried to read a document from the same stick drive and that worked. I can also write to it now, but trying to delete a file still crashes the system. I didn't test whether I could read the file written from Haiku.

comment:2 by beos_zealot, 13 years ago

Cc: beos.zealot@… added

Same problem for me, too. Tested 2 USB flash drives (PQI 512MB and SanDisk Cruser 8Gb) formated both FAT and FAT32. Reading or copying from flash drives works correctly. If I mount them as read-write and try to write to them - copying dialog shows "Copying 1 of ...", progress bar grows by 1 file and stands in that position for few seconds - then drops to KDL.

Made photo of KDL with bt, will upload today...

by beos_zealot, 13 years ago


comment:3 by beos_zealot, 13 years ago

ATTACHED promised photo...

UPDATE: checked usb flash drive content after KDL on other computer (win xp). shows 1 copied file (the first in copying queue), even shows size of the file, but when i try to open - complains that file corrupted and size of the file becomes 0 kb. Can't delete this file (tried from win xp) only formatting of usb flash drive helps.

in reply to:  2 comment:4 by phoudoin, 13 years ago

Exact same problem seen a few hours ago, under a fresh hrev31238.

comment:5 by jprostko, 13 years ago

Cc: joe.prostko+haiku@… added

comment:6 by mmlr, 13 years ago

Blocking: 4066 added

comment:7 by jahaiku, 13 years ago

Cc: Jens.Arm@… added

comment:8 by phoudoin, 13 years ago

Milestone: R1R1/alpha1
Priority: normalcritical

Moved to critical for R1 alpha. John Doe will try to save some data on his usb stick. Let's not ruin his Haiku first experiences with losing his data.

comment:9 by phoudoin, 13 years ago

Summary: Copy file to USB flash drive causes KDLCopy file to a FAT USB flash drive causes KDL

comment:10 by phoudoin, 13 years ago

Description: modified (diff)

comment:11 by phoudoin, 13 years ago

Summary: Copy file to a FAT USB flash drive causes KDLKDL when copying data to a FAT USB flash drive

comment:12 by VinDuv, 13 years ago

This bug seems to have been fixed with the latest fatfs changes. I was able to copy the entire Haiku system/ folder to an USB key without any issues.
Can someone confirm this ?

comment:13 by axeld, 13 years ago

The bug disappeared for me to, but I don't know what is responsible for this; my FAT changes aren't to blame for this AFAICT.

comment:14 by phoudoin, 13 years ago

Last time I see it I was running a hrev31835 installed by Installer from a (hrev31835, obsiouvly) LiveUSB image donwloaded from

I'll tried with a more recent revision ASAP.

comment:15 by phoudoin, 13 years ago

How ironic if I've just installed exactly the previous revision before this bug were fixed... I'm still at work but I can't hardly wait to check!

comment:16 by axeld, 13 years ago

AFAICT this bug hasn't been fixed, it might just happen less often now.

in reply to:  16 comment:17 by phoudoin, 13 years ago

Replying to axeld:

AFAICT this bug hasn't been fixed, it might just happen less often now.

Indeed. I still haven't saw it again since I've updated hrev31835 to hrev32040. While it's not a proof the bug is fixed, it's a proof his reproductibility has greatly improve, switching from always to never so far.

Maybe the vfs or block cache changes were indirectly reponsible for this.

comment:18 by stippi, 13 years ago

IIRC, Michael definitely saw it again on one of his devices after the last round of fixes.

by apn4m3rdrock, 13 years ago

Attachment: 100_2604.jpg added

KDMP on VFAT to VFAT file copy (hrev32063)

comment:19 by apn4m3rdrock, 13 years ago

Build: hrev32063-gcc4 ( Aug 1 2009)

Initial error message read : /home/haiku/Haiku/trunk/headers/private/kernel/util/DoublyLinkedList.h:467): fFrist!=NULL &&fLast !=NULL thread 340 MoveTask

Reproducing: Transfer file from one mounted vfat partition to another mounted vfat partition ( both of them were mounted as RW ). Copying large file (ISO image approx 700Mb, kdumped in seconds though) from one vfat partition to another vfat partition and the kernel dumped core.

PS: Photo of KDMP Attached: 100_2604.jpg

comment:20 by scottmc, 13 years ago

Milestone: R1/alpha1R1/alpha2

by damoklas, 13 years ago

MoveTask on flash kernel panic

comment:21 by luroh, 12 years ago

Cc: lurohh@… added

by romain, 12 years ago

Attachment: fat_mirror.diff added

comment:22 by romain, 12 years ago

fat_mirror.diff is a first first against fat mirroring. By increasing the fat block buffer, we copy invalid data to the backup fats.

comment:23 by stippi, 12 years ago

romain, have you tracked the changes to the file when it was converted from the BeOS block cache API to Haiku's version? I am wondering whether mirror_fats() is supposed to copy the same block over and over, or a range of blocks and the problem was introduced when converting the file to use Haiku's block cache. Or in the case that there was no conversion, and Haiku's block cache is supposed to work the same as BeOS, that there is perhaps an incompatibility. Or maybe you have a deeper understanding of what mirror_fats() needs to do and already know your patch is correct. I am just asking for a more verbose explanation, in case you have one ready. :-)

comment:24 by romain, 12 years ago

I did not look at the changes between BeOS/Haiku. However AFAIK, the different fats are located side by side on disk. So each time a fat block is updated, it must be synced on the other fat backups. This seems to be exactly what the mirroring tries to do, and it is called for each block that is modified. On the other side, the FreeBSD fat filesystem does the same thing on fat mirroring, so I am pretty confident on this fix. However I can look at the code before the Haiku port. This might also help me to find other problems/changes.

But for sure, increasing the block_buffer in mirror_fats makes it point to invalid data (Unless I missed how this code is working :).

This point is only a part of the issues on fat filesystem. I did not found all of them yet. Especially I am still tracking:

  • Inconsistent file structure when creating files.
  • NULL pointer dereference when opening files.
  • I created another ticket on an issue when using the block cache.

comment:25 by romain, 12 years ago

Cc: romain.haiku@… added

comment:26 by andrewz, 12 years ago

Blocking: 5362 added

(In #5362) Probably the same as ticket 3690

by romain, 12 years ago

Attachment: dosfs_dir_flags.diff added

Fix bad flags set

comment:27 by romain, 12 years ago

"dosfs_dir_flags.diff" fixes a bad assignment in the get_vnode hook. Since the flags where not filled, they are randomly set to B_VNODE_PUBLISH_REMOVED, i.e 1. This makes the vfs call the remove_vnode hook, which removes the node fat entries. Later access to these nodes trigger errors like the ones of ticket #5362.

Concerning the fat mirror patch, the buffer increment code was added when porting the BeOS code to Haiku, and this can only be a mistake.

I will do more tests, but with these two patches, and #5340 I had no crash until now; and Windows checkdisk is happy with my usb stick after 70MB of file copy.

comment:28 by anevilyak, 12 years ago

Version: R1/pre-alpha1R1/Development

Thanks! Applied in hrev35434. Can those CC'd on this ticket please verify so I can close it? Also, romain: do you have a real name you'd like to be credited under?

comment:29 by beos_zealot, 12 years ago

Tested in HAIKU hrev35441 gcc4 build: wrote 320MB file to read/write mounted FAT32 formatted 512MB usb stick without KDL, so it's seems that this bug fixed.

Thanks romain !!!

comment:30 by anevilyak, 12 years ago

Resolution: fixed
Status: newclosed

comment:31 by stippi, 12 years ago

Awesome, awesome, awesome. I am really glad I put out my "call for help" back then! Thanks for stepping up, Romain, and congratulations on landing all your patches!

comment:32 by phoudoin, 12 years ago

Most Haiku's annoying bug ever is fixed here too!

Congratulations Romain, you're my hero of the day. Well, yesterday, that is. ;-)

Note: See TracTickets for help on using tickets.