From owner-freebsd-fs@FreeBSD.ORG Wed Oct 6 10:34:40 2010 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A80EE1065697 for ; Wed, 6 Oct 2010 10:34:40 +0000 (UTC) (envelope-from lioux-list@uol.com.br) Received: from goat.gigo.com (ipv6.gigo.com [IPv6:2001:470:1:18::2]) by mx1.freebsd.org (Postfix) with ESMTP id 891088FC1C for ; Wed, 6 Oct 2010 10:34:40 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by goat.gigo.com (Postfix) with ESMTP id 5427811624 for ; Wed, 6 Oct 2010 03:34:40 -0700 (PDT) Received: from goat.gigo.com ([127.0.0.1]) by localhost (vette.gigo.com [127.0.0.1]) (amavisd-new, port 10023) with ESMTP id iGr8uw-Zr646 for ; Wed, 6 Oct 2010 03:34:40 -0700 (PDT) Received: from 200.181.39.170 (200-181-39-170.bsace702.dsl.brasiltelecom.net.br [200.181.39.170]) by goat.gigo.com (Postfix) with ESMTPSA id 3A27811618 for ; Wed, 6 Oct 2010 03:34:39 -0700 (PDT) Received: (qmail 48371 invoked from network); 6 Oct 2010 07:32:47 -0300 Received: from unknown (HELO exxodus.fedaykin.here) (127.0.0.1) by exxodus.fedaykin.here with SMTP; 6 Oct 2010 07:32:47 -0300 Message-ID: <4CAC5067.3090106@uol.com.br> Date: Wed, 06 Oct 2010 07:32:47 -0300 From: Mario Sergio Fujikawa Ferreira User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; pt-BR; rv:1.9.1.12) Gecko/20101005 Thunderbird/3.0.8 MIME-Version: 1.0 To: Paul B Mahol References: <20101006005350.62837.qmail@exxodus.fedaykin.here> (sfid-20101006_00540_26A53ED6) In-Reply-To: (sfid-20101006_00540_26A53ED6) Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-fs@freebsd.org Subject: Re: Panic with msdosfs vs 1.3TB FAT32 X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Oct 2010 10:34:40 -0000 On 06/10/2010 00:36, Paul B Mahol wrote: > On 10/6/10, Mario Sergio Fujikawa Ferreira 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