Opened 10 years ago

Closed 9 years ago

Last modified 9 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
Has a Patch: no 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 10 years ago.
USB-flash-drive-FAT_KDL-on-write
100_2604.jpg (285.9 KB) - added by apn4m3rdrock 10 years ago.
KDMP on VFAT to VFAT file copy (hrev32063)
haikukernelpanicflashcopy.jpg (419.9 KB) - added by damoklas 9 years ago.
MoveTask on flash kernel panic
fat_mirror.diff (633 bytes) - added by romain 9 years ago.
dosfs_dir_flags.diff (307 bytes) - added by romain 9 years ago.
Fix bad flags set

Download all attachments as: .zip

Change History (37)

comment:1 Changed 10 years ago by haiqu

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 Changed 10 years ago by beos_zealot

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...

Changed 10 years ago by beos_zealot

USB-flash-drive-FAT_KDL-on-write

comment:3 Changed 10 years ago by beos_zealot

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.

comment:4 in reply to:  2 Changed 10 years ago by phoudoin

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

comment:5 Changed 10 years ago by jprostko

Cc: joe.prostko+haiku@… added

comment:6 Changed 10 years ago by mmlr

Blocking: 4066 added

comment:7 Changed 10 years ago by jahaiku

Cc: Jens.Arm@… added

comment:8 Changed 10 years ago by phoudoin

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 Changed 10 years ago by phoudoin

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

comment:10 Changed 10 years ago by phoudoin

Description: modified (diff)

comment:11 Changed 10 years ago by phoudoin

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

comment:12 Changed 10 years ago by VinDuv

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 Changed 10 years ago by axeld

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 Changed 10 years ago by phoudoin

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

I'll tried with a more recent revision ASAP.

comment:15 Changed 10 years ago by phoudoin

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 Changed 10 years ago by axeld

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

comment:17 in reply to:  16 Changed 10 years ago by phoudoin

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 Changed 10 years ago by stippi

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

Changed 10 years ago by apn4m3rdrock

Attachment: 100_2604.jpg added

KDMP on VFAT to VFAT file copy (hrev32063)

comment:19 Changed 10 years ago by apn4m3rdrock

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 Changed 10 years ago by scottmc

Milestone: R1/alpha1R1/alpha2

Changed 9 years ago by damoklas

MoveTask on flash kernel panic

comment:21 Changed 9 years ago by luroh

Cc: lurohh@… added

Changed 9 years ago by romain

Attachment: fat_mirror.diff added

comment:22 Changed 9 years ago by romain

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 Changed 9 years ago by stippi

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 Changed 9 years ago by romain

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 Changed 9 years ago by romain

Cc: romain.haiku@… added

comment:26 Changed 9 years ago by andrewz

Blocking: 5362 added

(In #5362) Probably the same as ticket 3690

Changed 9 years ago by romain

Attachment: dosfs_dir_flags.diff added

Fix bad flags set

comment:27 Changed 9 years ago by romain

"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 Changed 9 years ago by anevilyak

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 Changed 9 years ago by beos_zealot

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 Changed 9 years ago by anevilyak

Resolution: fixed
Status: newclosed

comment:31 Changed 9 years ago by stippi

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 Changed 9 years ago by phoudoin

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.