Bug 30168

Summary: 4-stable, crash when writing to msdos fs
Product: Base System Reporter: Chris Pockele <chrisp>
Component: miscAssignee: Tom Rhodes <trhodes>
Status: Closed FIXED    
Severity: Affects Only Me    
Priority: Normal    
Version: Unspecified   
Hardware: Any   
OS: Any   

Description Chris Pockele 2001-08-28 21:30:01 UTC 
I have a FAT partition of about 4 GB on my hard disk (i think maybe
the size matters here)
It's a logical partition in a dos extended one, so it's /dev/ad0s5.

I can mount it correctly, and i can read files from it.
However, when i try to write to it, I get a Fatal trap 12
page fault while in kernel mode
all i can do is reboot :(

How-To-Repeat: mount the msdos partition e.g. mount -t msdos /dev/ad0s5 /mnt
(verifying that it's mounted can be done by reading - this works)

try to copy a file to it e.g. cp somefilename /mnt will trigger it
Comment 1 Kris Kennaway 2001-08-29 04:24:56 UTC 
On Tue, Aug 28, 2001 at 01:21:06PM -0700, Chris Pockele wrote:

> I can mount it correctly, and i can read files from it.
> However, when i try to write to it, I get a Fatal trap 12
> page fault while in kernel mode
> all i can do is reboot :(
> >How-To-Repeat:
> mount the msdos partition e.g. mount -t msdos /dev/ad0s5 /mnt
> (verifying that it's mounted can be done by reading - this works)

Do you have msdosfs compiled into your kernel?  Check by running
kldstat after you mount the volume.  If msdos.ko shows up in kldstat,
then check whether your /modules/msdos.ko is in sync with your kernel
(it should have the same date as /kernel if it was installed at the
same time).  Out of date modules can cause panics.

Kris
Comment 2 Chris Pockele 2001-08-29 09:27:13 UTC 
Kris Kennaway wrote:
> 
> Do you have msdosfs compiled into your kernel?  Check by running
> kldstat after you mount the volume.  If msdos.ko shows up in kldstat,
> then check whether your /modules/msdos.ko is in sync with your kernel
> (it should have the same date as /kernel if it was installed at the
> same time).  Out of date modules can cause panics.
> 
Yes, it's in the kernel (not in a module).
It happens with the GENERIC kernel too (even after a fresh install).

Chris
Comment 3 Kris Kennaway 2001-08-29 09:32:04 UTC 
On Wed, Aug 29, 2001 at 10:24:31AM +0200, Chris Pockele wrote:
> Kris Kennaway wrote:
> > 
> > Do you have msdosfs compiled into your kernel?  Check by running
> > kldstat after you mount the volume.  If msdos.ko shows up in kldstat,
> > then check whether your /modules/msdos.ko is in sync with your kernel
> > (it should have the same date as /kernel if it was installed at the
> > same time).  Out of date modules can cause panics.
> > 
> Yes, it's in the kernel (not in a module).
> It happened with the GENERIC kernel too, after a fresh install.


Ok, then please obtain a panic traceback from a debugging kernel (See
the handbook) and submit it as a followup to the PR.

Kris
Comment 4 Chris Pockele 2001-08-29 10:58:03 UTC 
(followup)

I compiled a kernel with the following extra options:

makeoptions     DEBUG=-g                #Build kernel with gdb(1) debug
symbols
options DDB
options DIAGNOSTIC
options DEBUG

The error is now:

Fatal trap 12: page fault while in kernel mode
fault virtual address = 0xe0b83ffc
fault code = supervisor read, page not present
instruction pointer = 0x8:0xc0190cc3
stack pointer = 0x10:0xc81cad14
code segment = base rx0, limit 0xfffff, type 0x1b
	     = BPL 0, pres 1, def32 1, gran 1
processor eflags = interrupt enabled, resume, IOPL=0
current process = 314 (cp)
interrupt mask = none

Stopped at updatefats+0x37: andl 0(%esi, %edx, 4),%eax


something else i did (as described in the FAQ):
freedaemon# nm -n /kernel | grep c0190cc3
freedaemon# nm -n /kernel | grep c0190cc
freedaemon# nm -n /kernel | grep c0190c
c0190c18 t fc_lookup
c0190c64 T fc_purge
c0190c8c t updatefats
Comment 5 Kris Kennaway 2001-08-29 11:19:22 UTC 
On Wed, Aug 29, 2001 at 11:58:03AM +0200, Chris Pockele wrote:
> (followup)

That's still not a traceback..please try and obtain that.

Kris
Comment 6 Chris Pockele 2001-08-29 12:43:33 UTC 
> That's still not a traceback..please try and obtain that.
> 
Here is the output of

gdb -k /sys/compile/DEBUG/kernel.debug /var/crash/vmcore.1

(kgdb) where

----
Script started on Wed Aug 29 13:34:24 2001
freedaemon# gdb -k /sys/compile/DEBUG/kernel.debug
/var/crash/vmESC[Kcore.1^M
GNU gdb 4.18
Copyright 1998 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you
are
welcome to change it and/or distribute copies of it under certain
conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB.  Type "show warranty" for
details.
This GDB was configured as "i386-unknown-freebsd"...
IdlePTD 4874240
initial pcb at 3ee7e0
panicstr: page fault
panic messages:
---
Fatal trap 12: page fault while in kernel mode
fault virtual address   = 0xe0f6effc
fault code              = supervisor read, page not present
instruction pointer     = 0x8:0xc01f8dd3
stack pointer           = 0x10:0xc8565d14
frame pointer           = 0x10:0xc8565d24
code segment            = base rx0, limit 0xfffff, type 0x1b
                        = DPL 0, pres 1, def32 1, gran 1
processor eflags        = interrupt enabled, resume, IOPL = 0
current process         = 273 (cp)
interrupt mask          = none
trap number             = 12
panic: page fault

syncing disks... 46 2 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 
1: dev:#ad/0x60002, flags:00100020, blkno:8344, lblkno:8344
giving up on 1 buffers
Uptime: 37s

dumping to dev #ad/0x30001, offset 269872
dump ata0: resetting devices .. done
128 127 126 125 124 123 122 121 120 119 118 117 116 115 114 113 112 111
110 109 
108 107 106 105 104 103 102 101 100 99 98 97 96 95 94 93 92 91 90 89 88
87 86 85
 84 83 82 81 80 79 78 77 76 75 74 73 72 71 70 69 68 67 66 65 64 63 62 61
60 59 5
8 57 56 55 54 53 52 51 50 49 48 47 46 45 44 43 42 41 40 39 38 37 36 35
34 33 32 
31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16 15 14 13 12 11 10 9 8 7
6 5 4 3 
2 1 
---
#0  dumpsys () at ../../kern/kern_shutdown.c:473
473             if (dumping++) {
(kgdb) where
#0  dumpsys () at ../../kern/kern_shutdown.c:473
#1  0xc01bda74 in boot (howto=256) at ../../kern/kern_shutdown.c:313
#2  0xc01bde54 in poweroff_wait (junk=0xc03a07ea, howto=-1069939985)
    at ../../kern/kern_shutdown.c:581
#3  0xc03339c3 in trap_fatal (frame=0xc8565cd4, eva=3774279676)
    at ../../i386/i386/trap.c:956
#4  0xc033367d in trap_pfault (frame=0xc8565cd4, usermode=0,
eva=3774279676)
    at ../../i386/i386/trap.c:849
#5  0xc03331e7 in trap (frame={tf_fs = -933887984, tf_es = -1071775728, 
      tf_ds = -933625840, tf_edi = 8344, tf_esi = -1057558528, 
      tf_ebp = -933864156, tf_isp = -933864192, tf_ebx = -1057562624, 
      tf_edx = 134217727, tf_ecx = 31, tf_eax = -2147483648, tf_trapno =
12, 
      tf_err = 0, tf_eip = -1071673901, tf_cs = 8, tf_eflags = 66182, 
      tf_esp = 268435455, tf_ss = 268435455}) at
../../i386/i386/trap.c:448
#6  0xc01f8dd3 in updatefats (pmp=0xc0f6e000, bp=0xc3703284, fatbn=8344)
    at ../../msdosfs/msdosfs_fat.c:353
#7  0xc01f947e in fatchain (pmp=0xc0f6e000, start=1064363, count=0, 
    fillwith=4294967295) at ../../msdosfs/msdosfs_fat.c:674
#8  0xc01f959a in chainalloc (pmp=0xc0f6e000, start=1064363, count=1, 
    fillwith=4294967295, retcluster=0xc8565df0, got=0xc8565dec)
    at ../../msdosfs/msdosfs_fat.c:748
#9  0xc01f979a in clusteralloc (pmp=0xc0f6e000, start=0, count=1, 
    fillwith=4294967295, retcluster=0xc8565df0, got=0xc8565dec)
    at ../../msdosfs/msdosfs_fat.c:842
---Type <return> to continue, or q <return> to quit---
#10 0xc01f9c2a in extendfile (dep=0xc0f5c400, count=1, bpp=0x0, ncp=0x0, 
    flags=0) at ../../msdosfs/msdosfs_fat.c:1034
#11 0xc01fcf0e in msdosfs_write (ap=0xc8565e78)
    at ../../msdosfs/msdosfs_vnops.c:725
#12 0xc01f28a2 in vn_write (fp=0xc0f69bc0, uio=0xc8565ee4,
cred=0xc0f64600, 
    flags=0, p=0xc7b665e0) at vnode_if.h:363
#13 0xc01cc93a in dofilewrite (p=0xc7b665e0, fp=0xc0f69bc0, fd=4, 
    buf=0x28058000, nbyte=187, offset=-1, flags=0) at
../../sys/file.h:162
#14 0xc01cc7eb in write (p=0xc7b665e0, uap=0xc8565f80)
    at ../../kern/sys_generic.c:329
#15 0xc0333c39 in syscall2 (frame={tf_fs = 47, tf_es = 47, tf_ds = 47, 
      tf_edi = 671449088, tf_esi = 671449088, tf_ebp = -1077937572, 
      tf_isp = -933863468, tf_ebx = 187, tf_edx = 4, tf_ecx = 1, tf_eax
= 4, 
      tf_trapno = 12, tf_err = 2, tf_eip = 134561808, tf_cs = 31, 
      tf_eflags = 663, tf_esp = -1077937632, tf_ss = 47})
    at ../../i386/i386/trap.c:1155
#16 0xc0324d75 in Xint0x80_syscall ()
#17 0x8048989 in ?? ()
#18 0x804851a in ?? ()
#19 0x8048135 in ?? ()
(kgdb) exit
Undefined command: "exit".  Try "help".
(kgdb) quit
freedaemon# exit

Script done on Wed Aug 29 13:35:00 2001
Comment 7 Kris Kennaway 2001-08-29 21:36:03 UTC 
On Wed, Aug 29, 2001 at 01:43:33PM +0200, Chris Pockele wrote:
> > That's still not a traceback..please try and obtain that.
> > 
> Here is the output of
> 
> gdb -k /sys/compile/DEBUG/kernel.debug /var/crash/vmcore.1

Thanks, that was what's needed.  Now to find an msdosfs guru to debug
this :)

Kris

> 
> (kgdb) where
> 
> ----
> Script started on Wed Aug 29 13:34:24 2001
> freedaemon# gdb -k /sys/compile/DEBUG/kernel.debug
> /var/crash/vmESC[Kcore.1^M
> GNU gdb 4.18
> Copyright 1998 Free Software Foundation, Inc.
> GDB is free software, covered by the GNU General Public License, and you
> are
> welcome to change it and/or distribute copies of it under certain
> conditions.
> Type "show copying" to see the conditions.
> There is absolutely no warranty for GDB.  Type "show warranty" for
> details.
> This GDB was configured as "i386-unknown-freebsd"...
> IdlePTD 4874240
> initial pcb at 3ee7e0
> panicstr: page fault
> panic messages:
> ---
> Fatal trap 12: page fault while in kernel mode
> fault virtual address   = 0xe0f6effc
> fault code              = supervisor read, page not present
> instruction pointer     = 0x8:0xc01f8dd3
> stack pointer           = 0x10:0xc8565d14
> frame pointer           = 0x10:0xc8565d24
> code segment            = base rx0, limit 0xfffff, type 0x1b
>                         = DPL 0, pres 1, def32 1, gran 1
> processor eflags        = interrupt enabled, resume, IOPL = 0
> current process         = 273 (cp)
> interrupt mask          = none
> trap number             = 12
> panic: page fault
> 
> syncing disks... 46 2 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 
> 1: dev:#ad/0x60002, flags:00100020, blkno:8344, lblkno:8344
> giving up on 1 buffers
> Uptime: 37s
> 
> dumping to dev #ad/0x30001, offset 269872
> dump ata0: resetting devices .. done
> 128 127 126 125 124 123 122 121 120 119 118 117 116 115 114 113 112 111
> 110 109 
> 108 107 106 105 104 103 102 101 100 99 98 97 96 95 94 93 92 91 90 89 88
> 87 86 85
>  84 83 82 81 80 79 78 77 76 75 74 73 72 71 70 69 68 67 66 65 64 63 62 61
> 60 59 5
> 8 57 56 55 54 53 52 51 50 49 48 47 46 45 44 43 42 41 40 39 38 37 36 35
> 34 33 32 
> 31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16 15 14 13 12 11 10 9 8 7
> 6 5 4 3 
> 2 1 
> ---
> #0  dumpsys () at ../../kern/kern_shutdown.c:473
> 473             if (dumping++) {
> (kgdb) where
> #0  dumpsys () at ../../kern/kern_shutdown.c:473
> #1  0xc01bda74 in boot (howto=256) at ../../kern/kern_shutdown.c:313
> #2  0xc01bde54 in poweroff_wait (junk=0xc03a07ea, howto=-1069939985)
>     at ../../kern/kern_shutdown.c:581
> #3  0xc03339c3 in trap_fatal (frame=0xc8565cd4, eva=3774279676)
>     at ../../i386/i386/trap.c:956
> #4  0xc033367d in trap_pfault (frame=0xc8565cd4, usermode=0,
> eva=3774279676)
>     at ../../i386/i386/trap.c:849
> #5  0xc03331e7 in trap (frame={tf_fs = -933887984, tf_es = -1071775728, 
>       tf_ds = -933625840, tf_edi = 8344, tf_esi = -1057558528, 
>       tf_ebp = -933864156, tf_isp = -933864192, tf_ebx = -1057562624, 
>       tf_edx = 134217727, tf_ecx = 31, tf_eax = -2147483648, tf_trapno =
> 12, 
>       tf_err = 0, tf_eip = -1071673901, tf_cs = 8, tf_eflags = 66182, 
>       tf_esp = 268435455, tf_ss = 268435455}) at
> ../../i386/i386/trap.c:448
> #6  0xc01f8dd3 in updatefats (pmp=0xc0f6e000, bp=0xc3703284, fatbn=8344)
>     at ../../msdosfs/msdosfs_fat.c:353
> #7  0xc01f947e in fatchain (pmp=0xc0f6e000, start=1064363, count=0, 
>     fillwith=4294967295) at ../../msdosfs/msdosfs_fat.c:674
> #8  0xc01f959a in chainalloc (pmp=0xc0f6e000, start=1064363, count=1, 
>     fillwith=4294967295, retcluster=0xc8565df0, got=0xc8565dec)
>     at ../../msdosfs/msdosfs_fat.c:748
> #9  0xc01f979a in clusteralloc (pmp=0xc0f6e000, start=0, count=1, 
>     fillwith=4294967295, retcluster=0xc8565df0, got=0xc8565dec)
>     at ../../msdosfs/msdosfs_fat.c:842
> ---Type <return> to continue, or q <return> to quit---
> #10 0xc01f9c2a in extendfile (dep=0xc0f5c400, count=1, bpp=0x0, ncp=0x0, 
>     flags=0) at ../../msdosfs/msdosfs_fat.c:1034
> #11 0xc01fcf0e in msdosfs_write (ap=0xc8565e78)
>     at ../../msdosfs/msdosfs_vnops.c:725
> #12 0xc01f28a2 in vn_write (fp=0xc0f69bc0, uio=0xc8565ee4,
> cred=0xc0f64600, 
>     flags=0, p=0xc7b665e0) at vnode_if.h:363
> #13 0xc01cc93a in dofilewrite (p=0xc7b665e0, fp=0xc0f69bc0, fd=4, 
>     buf=0x28058000, nbyte=187, offset=-1, flags=0) at
> ../../sys/file.h:162
> #14 0xc01cc7eb in write (p=0xc7b665e0, uap=0xc8565f80)
>     at ../../kern/sys_generic.c:329
> #15 0xc0333c39 in syscall2 (frame={tf_fs = 47, tf_es = 47, tf_ds = 47, 
>       tf_edi = 671449088, tf_esi = 671449088, tf_ebp = -1077937572, 
>       tf_isp = -933863468, tf_ebx = 187, tf_edx = 4, tf_ecx = 1, tf_eax
> = 4, 
>       tf_trapno = 12, tf_err = 2, tf_eip = 134561808, tf_cs = 31, 
>       tf_eflags = 663, tf_esp = -1077937632, tf_ss = 47})
>     at ../../i386/i386/trap.c:1155
> #16 0xc0324d75 in Xint0x80_syscall ()
> #17 0x8048989 in ?? ()
> #18 0x804851a in ?? ()
> #19 0x8048135 in ?? ()
> (kgdb) exit
> Undefined command: "exit".  Try "help".
> (kgdb) quit
> freedaemon# exit
> 
> Script done on Wed Aug 29 13:35:00 2001
Comment 8 Chris Pockele 2001-08-30 15:24:32 UTC 
Kris Kennaway wrote:
> 
> On Wed, Aug 29, 2001 at 01:43:33PM +0200, Chris Pockele wrote:
> > > That's still not a traceback..please try and obtain that.
> > >
some "phenomenon" i observed today:

I compiled a kernel without MSDOSFS support included, so msdos.ko
is now loaded when mounting the partition.  Now it does NOT crash
when trying to write a file.

Chris
Comment 9 Chris Pockele 2001-10-28 17:38:06 UTC 
> Thanks, that was what's needed.  Now to find an msdosfs guru to debug
> this :)
> 
> Kris
> 
Compiling msdosfs support as a module has solved the problem
for a long time (don't know why, but it didn't crash).
But after doing a cvsup + makeworld today,
it occured again (mounting & reading the msdos partition is ok,
panic when writing).
I searched the GNATS database and i found a few pr's that
seem to describe the same problem.
I applied the following patch from pr i386/28536, and it did
give me the error message (Next free cluster in FSInfo (%u)
exceeds maxcluster (%u)) when trying to mount the partition.

The scandisk programs from win98 and w2k don't report any
errors on the partitions, and Linux can write to them, too.

Should I recompile with unpatched sources and submit another
traceback?

Here's the patch:

/*
                * Check and validate (or perhaps invalidate?) the fsinfo
structure?            XXX
                */
       +     if (pmp->pm_fsinfo && pmp->pm_nxtfree > pmp->pm_maxcluster)
{
       +         printf ("
       +                pmp->pm_nxtfree, pmp->pm_maxcluster);
       +         error = EINVAL;
       +         goto error_exit;
       +     }
         
               /*
                * Allocate memory for the bitmap of allocated clusters,
and then


Here are the error messages (with patch applied):

Oct 28 18:33:35 freedaemon /kernel: Next free cluster in FSInfo
(4294967295) exceeds maxcluster (1148401)
Oct 28 18:33:49 freedaemon /kernel: Next free cluster in FSInfo
(4294967295) exceeds maxcluster (1467070)

(there are two msdos partitions which i tried to mount)
Maybe it's because the partitions are bigger than 2 or 8 GB?
Comment 10 Tom Rhodes freebsd_committer freebsd_triage 2002-08-22 23:23:27 UTC 
State Changed
From-To: open->patched

Just applied a patch to current which seems to fix this problem.  MFC is 
in 1 week, thanks.
Comment 11 Tom Rhodes freebsd_committer freebsd_triage 2002-08-22 23:23:27 UTC 
Responsible Changed
From-To: freebsd-bugs->trhodes

Just applied a patch to current which seems to fix this problem.  MFC is 
in 1 week, thanks.
Comment 12 Tom Rhodes freebsd_committer freebsd_triage 2002-09-12 23:11:19 UTC 
State Changed
From-To: patched->feedback

Patch applied to STABLE, please let me know if you continue to have problems.
Comment 13 Tom Rhodes freebsd_committer freebsd_triage 2002-12-12 06:19:49 UTC 
State Changed
From-To: feedback->closed

Closed.  I can not reproduce this, and it has been in feedback for 
awhile now.