Re: kern/43375: panic when mount(8)ing umass(4) device (Sony DSC-H50 Digital Camera)

["Alan R. S. Bueno" <alan.bsd%gmail.com@localhost>]

The following reply was made to PR kern/43375; it has been noted by GNATS.

From: "Alan R. S. Bueno" <alan.bsd%gmail.com@localhost>
To: gnats-bugs%netbsd.org@localhost
Cc: 
Subject: Re: kern/43375: panic when mount(8)ing umass(4) device (Sony DSC-H50 
        Digital Camera)
Date: Mon, 31 May 2010 14:05:53 -0300

 On Sun, May 30, 2010 at 11:10 PM, David Holland
 <dholland-bugs%netbsd.org@localhost> wrote:
 > The following reply was made to PR kern/43375; it has been noted by GNATS=
 .
 >
 > From: David Holland <dholland-bugs%netbsd.org@localhost>
 > To: gnats-bugs%NetBSD.org@localhost
 > Cc:
 > Subject: Re: kern/43375: panic when mount(8)ing umass(4) device (Sony
 > =A0 =A0 =A0 =A0DSC-H50 Digital Camera)
 > Date: Mon, 31 May 2010 02:09:15 +0000
 >
 > =A0On Sat, May 29, 2010 at 07:25:02PM +0000, Alan R. S. Bueno wrote:
 > =A0> =A0> Do you have that traceback, or can you get one from the dump?
 > =A0>
 > =A0> =A0Yes. The system reboots after the panic, so no chance to ddb(4).
 > =A0>
 > =A0> =A0Let me know if I'm doing something wrong.
 >
 > =A0You may be, because the trace doesn't entirely make sense.
 >
 > =A0> =A0middle-earth# gunzip /var/crash/netbsd.5.core.gz
 > =A0> =A0middle-earth# crash -M netbsd.5.core
 > =A0> =A0Crash version 5.99.29, image version 5.99.29.
 > =A0> =A0System panicked: buf mem pool index %d
 > =A0> =A0Backtrace from time of crash is available.
 >
 > =A0This looks fine in principle; however, were you running the same
 > =A0kernel that generated the dump? If it's not quite the same it would
 > =A0explain the trace.
 >
 > =A0If in doubt use the -N /netbsd.whatever option to crash to feed it the
 > =A0same kernel that generated the core.
 >
 
 Oops! I think you're right. Trying again with updated kernel and
 modules (and after clean /var/crash/...), *without* the patches:
 
 [...mount_msdos and panic and reboot happens here...]
 # crash -M netbsd.0.core -N /netbsd
 Crash version 5.99.29, image version 5.99.29.
 System panicked: buf mem pool index %d
 Backtrace from time of crash is available.
 crash> trace
 _KERNEL_OPT_NVGA_RASTERCONSOLE(104,0,c049993b,c099cf47,0,ccb0694c,104,0,0,c=
 cb069
 4c) at 0
 end(104,0,c09bb200,cc91b2a0,0,2,0,ccb06958,0,0) at 0xcc91b2a0
 panic(c099cf47,17,c23c4790,0,0,cc5e0678,ccb0698c,c0678c83,cc5e0678,0) at 0x=
 c05bc
 782
 buf_mempoolidx(cc5e0678,0,b0,c23c4790,0,0,ccb069bc,c0679ffb,c23c4790,0) at =
 0xc06
 78292
 allocbuf(c23c4790,0,0,0,cc91b310,cc5e0678,0,ccb06a7c,cc5e0678,0) at 0xc0678=
 c83
 getblk(cc5e0678,7a0,0,0,0,0,ccb069fc,c06782fe,cc5e0678,cc5e0678) at 0xc0679=
 ffb
 bio_doread(0,ffffffff,0,c067853a,c23c4894,cc5e0678,cb18b100,f0000,0,c213760=
 0) at
  0xc067a10e
 bread(cc5e0678,7a0,0,0,ffffffff,0,ccb06a7c,c2137600,ccb06a8c,ccb72ccd) at 0=
 xc067
 a307
 end(c2137600,ccb79600,0,1,11,2,40,cb2efc00,cc5e0678,cb2efe0b) at 0xccb72cf4
 end(cc5e0678,ccb0b42c,cc91b2a0,ccb0b3a0,cc91b2a0,0,3,c05bcefc,ccb0bd28,2) a=
 t 0xc
 cb7536e
 end(ccb0b42c,bfbfe4cc,ccb0b3a0,ccb06cc0,0,ccb796c0,ccb06b8c,c0682841,c0a604=
 d0,cc
 b0b42c) at 0xccb7597d
 VFS_MOUNT(ccb0b42c,bfbfe4cc,ccb0b3a0,ccb06cc0,ccb0bd2c,ccb41a18,cc9f1e40,0,=
 67000
 ,0) at 0xc0680a94
 do_sys_mount(cc91b2a0,0,80492c5,bfbfe4cc,0,bfbfeccc,0,8c,ccb06d28,bbb30000)=
  at 0
 xc06898dc
 sys___mount50(cc91b2a0,ccb06d00,ccb06d28,ccb06d00,bbb30000,cc4f3784,19a,804=
 92c5,
 bfbfe4cc,0) at 0xc0689a8d
 syscall(ccb06d48,b3,ab,1f,1f,bfbfe8cc,bfbfe4cc,bfbfed68,bfbfeccc,bbbccbc0) =
 at 0x
 c05ceae9
 
 Question: is ps needed?
 
 
 > =A0There are two ways to go about debugging this further: one is to use
 > =A0rump_msdos, which should exhibit the same behavior but being entirely
 > =A0userlevel can be run in a debugger and also won't kill the system when
 > =A0it fails.
 >
 > =A0The other is to go ahead and boot and crash a test kernel; if you
 > =A0compile msdosfs in instead of loading it as a module, you'll probably
 > =A0get sane stuff out of crash; alternatively, if you include ddb and set
 > =A0the ddb.onpanic sysctl to 1, you may be able to get a working
 > =A0backtrace directly from ddb. Either way, enable DIAGNOSTIC for good
 > =A0measure.
 >
 
 Trying the 2nd way... With patches, msdosfs in kernel, DIAGNOSTIC,
 ddb.onpanic=3D1.
 
 I taked shots of the screen with my digital camera (neither serial console
 nor other way to get the output here...). I did my best to type without typ=
 os.
 
 # mount_msdos /dev/sd0e /mnt
 mount_msdos: "/mnt" is a non-resolved or relative path.
 mount_msdos: using "/mnt" instead.
 panic: bread: zero-length buf requested
 
 fatal breakpoint trap in supervisor mode
 trap type 1 code 0 eip c022d974 cs 8 eflags 246 cr2 bbb30a10 ilevel 0
 Stopped in pid 475.1 (mount_msdos) at   netbsd:breakpoint+0x4:  popl    %eb=
 p
 db{0}> trace
 breakpoint(cc680678,ccbb29fc,c0466b30,ccbb2a08,0,ccbb2a7c,ccbb2a2c,c06b0fa3=
 ,c09f
 18c0,ffffffff) at netbsd:breakpoint+0x4
 panic(c09f18c0,ffffffff,0,0,c2191600,c0100f4e,0,f0000,0,c2191600) at netbsd=
 :pani
 c+0x1f2
 bread(cc680678,7a0,0,0,ffffffff,0,ccbb2a7c,c2191600,ccbb2a8c,c04d9fad) at n=
 etbsd
 :bread+0x83
 fillinusemap(c2191600,c0a6aaa0,0,1,11,2,40,cb34fc00,cc680678,cb34fe0b) at n=
 etbsd
 :fillinusemap+0x144
 msdosfs_mountfs(cc680678,ccbbc000,cc9dc7e0,ccbbba00,cc9dc7e0,0,3,c05e428c,c=
 cbbc8
 fc,a) at netbsd:msdosfs_mountfs+0x5fa
 msdosfs_mount(ccbbc000,bfbfe4cc,ccbbba00,ccbb2cc0,0,c0a6ab60,ccbb2b8c,c06ba=
 8f9,c
 0ab8690,ccbbc000) at netbsd:msdosfs_mount+0x2f5
 VFS_MOUNT(ccbbc000,bfbfe4cc,ccbbba00,ccbb2cc0,ccbbc900,ccbefac8,ccab2e40,0,=
 bbb34
 000,0) at netbsd:VFS_MOUNT+0x24
 do_sys_mount(cc9dc7e0,0,80492c5,bfbfe4cc,0,bfbfeccc,0,8c,ccbb2d28,bbb30000)=
  at n
 etbsd:do_sys_mount+0x847
 sys___mount50(cc9dc7e0,ccbb2d00,ccbb2d28,bfbfe154,bbb30000,cc5931e4,19a,804=
 92c5,
 bfbfe4cc,0) at netbsd:sys___mount50+0x2d
 syscall(ccbb2d48,b3,ab,1f,1f,bfbfe8cc,bfbfe4cc,bfbfed68,bfbfeccc,bbbccbc0) =
 at ne
 tbsd:syscall+0xb9