KDL when copying data to a FAT USB flash drive

[haiqu]

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.

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

[beos_zealot]

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

[beos_zealot]

USB-flash-drive-FAT_KDL-on-write

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

[phoudoin]

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

[phoudoin]

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.

[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 ?

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

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

[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!

[axeld]

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

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

[stippi]

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

[apn4m3rdrock]

KDMP on VFAT to VFAT file copy (hrev32063)

[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

[damoklas]

MoveTask on flash kernel panic

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

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

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

[andrewz]

(In #5362) Probably the same as ticket 3690

[romain]

Fix bad flags set

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

[anevilyak]

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?

[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 !!!

[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!

[phoudoin]

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

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