Panic with msdosfs vs 1.3TB FAT32

[Mario Sergio Fujikawa Ferreira]

On 06/10/2010 00:36, Paul B Mahol wrote:
> On 10/6/10, Mario Sergio Fujikawa Ferreira<lioux-list at uol.com.br>  wrote:
>> Hi,
>>
>> 	I mounted a 1.3TB FAT32 (32k cluster) filesystem on esata
>> /dev/ada4s1 under /media/esata/ with the '-l' (large option).
>>
>> 	I tried to create a directory and files but got errors:
>>
>> ------
>>
>> g_vfs_done():ada4s1[WRITE(offset=-980247646208, length=32768)]error = 5
>> g_vfs_done():ada4s1[WRITE(offset=-980247646208, length=32768)]error = 5
>> g_vfs_done():ada4s1[WRITE(offset=-980247613440, length=32768)]error = 5
>> g_vfs_done():ada4s1[WRITE(offset=-980247646208, length=32768)]error = 5
>> g_vfs_done():ada4s1[WRITE(offset=-980247613440, length=32768)]error = 5
>> g_vfs_done():ada4s1[WRITE(offset=-980247580672, length=32768)]error = 5
>> g_vfs_done():ada4s1[WRITE(offset=-980247646208, length=32768)]error = 5
>> g_vfs_done():ada4s1[WRITE(offset=-980247613440, length=32768)]error = 5
>> g_vfs_done():ada4s1[WRITE(offset=-980247580672, length=32768)]error = 5
>> g_vfs_done():ada4s1[WRITE(offset=-980247646208, length=32768)]error = 5
>> g_vfs_done():ada4s1[WRITE(offset=-980247613440, length=32768)]error = 5
>> g_vfs_done():ada4s1[WRITE(offset=-980247580672, length=32768)]error = 5
>>
>> ------
>>
>> 	Then, I tried unmounting the filesystem which resulted on
>>
>> ------
>>
>> fsync: giving up on dirty
>> 0xffffff01bad6e1d8: tag devfs, type VCHR
>>      usecount 1, writecount 0, refcount 38253 mountedhere 0xffffff00ac899600
>>      flags ()
>>      v_object 0xffffff008b839ca8 ref 0 pages 44786
>>      lock type devfs: EXCL by thread 0xffffff016506cba0 (pid 76462)
>>          dev ada4s1
>> g_vfs_done():ada4s1[WRITE(offset=-980247646208, length=32768)]error = 5
>> g_vfs_done():ada4s1[WRITE(offset=-980247613440, length=32768)]error = 5
>> g_vfs_done():ada4s1[WRITE(offset=-980247580672, length=32768)]error = 5
>> fsync: giving up on dirty
>> 0xffffff01bad6e1d8: tag devfs, type VCHR
>>      usecount 1, writecount 0, refcount 38253 mountedhere 0xffffff00ac899600
>>      flags ()
>>      v_object 0xffffff008b839ca8 ref 0 pages 44786
>>      lock type devfs: UNLOCKED
>>          dev ada4s1
>>
>> Fatal trap 12: page fault while in kernel mode
>> cpuid = 1; apic id = 01
>> fault virtual address   = 0x4
>> fault code              = supervisor read data, page not present
>> instruction pointer     = 0x20:0xffffffff803e60e4
>> stack pointer           = 0x28:0xffffff80e79ba860
>> frame pointer           = 0x28:0xffffff80e79ba8a0
>> code segment            = base 0x0, limit 0xfffff, type 0x1b
>>                          = DPL 0, pres 1, long 1, def32 0, gran 1
>> processor eflags        = interrupt enabled, resume, IOPL = 0
>> current process         = 25 (syncer)
>>
>> ------
>>
>> 	The filesystem is clean since I find no errors under Windows
>> ('chkdsk /f').
>>
>> 	I can otherwise mount, read and write on smaller FAT32
>> filesystems.  I think there might be a problem with the handling
>> of such a big FAT32 filesystem.
>>
>> 	A complete textdump is available at
>>
>> http://people.freebsd.org/~lioux/panic/2010100500/textdump.tar.2
>>
>> 	Is this kind of error expected? Is there anything I can do
>> to help?
>>
>> 	I can reproduce this error with the 1.3TB fs easily.
>
> Comment in source claims that support for large fs are experimental
> and safe only in read only mode.
>
> Looking at your output it is obvious that offset should not be negative...

   Now that you mention it... :)

   I guess I might have overflown some internal variable, possibly a 32 
bit integer.

   I checked

http://www.freebsd.org/cgi/cvsweb.cgi/src/sys/fs/msdosfs/msdosfs_vfsops.c?rev=1.199

but it did not make much sense to me. :(

   Any ideas where I might look or for a patch? Unfortunately, I am not 
kernel knowledgeable but I'll help however I can.

   Regards,

--
Mario S F Ferreira - DF - Brazil - "I guess this is a signature."
feature, n: a documented bug | bug, n: an undocumented feature