NetBSD Problem Report #43375
From www@NetBSD.org Fri May 28 12:11:51 2010
Return-Path: <www@NetBSD.org>
Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11])
by www.NetBSD.org (Postfix) with ESMTP id 531DB63B879
for <gnats-bugs@gnats.NetBSD.org>; Fri, 28 May 2010 12:11:51 +0000 (UTC)
Message-Id: <20100528121151.1AC8E63B873@www.NetBSD.org>
Date: Fri, 28 May 2010 12:11:51 +0000 (UTC)
From: alan.bsd@gmail.com
Reply-To: alan.bsd@gmail.com
To: gnats-bugs@NetBSD.org
Subject: panic when mount(8)ing umass(4) device (Sony DSC-H50 Digital Camera)
X-Send-Pr-Version: www-1.0
>Number: 43375
>Category: kern
>Synopsis: panic when mount(8)ing umass(4) device (Sony DSC-H50 Digital Camera)
>Confidential: no
>Severity: non-critical
>Priority: low
>Responsible: kern-bug-people
>State: open
>Class: sw-bug
>Submitter-Id: net
>Arrival-Date: Fri May 28 12:15:00 +0000 2010
>Last-Modified: Sun Jun 19 14:25:00 +0000 2011
>Originator: Alan Bueno
>Release: NetBSD -current
>Organization:
>Environment:
NetBSD middle-earth.arda.net 5.99.29 NetBSD 5.99.29 (CUSTOM) #0: Mon May 24 17:37:51 BRT 2010 root@middle-earth.arda.net:/usr/obj/sys/arch/i386/compile/CUSTOM i386
>Description:
The umass(4) manual page says that Sony DSC Digital Cameras are known to work, but when I try to mount the device (DSC-H50) the kernel panic.
On FreeBSD, OpenBSD, and Linux the device works ok.
When I plug the digital camera, kernel says:
--------------------------------------------
umass0 at uhub4 port 4 configuration 1 interface 0
umass0: Sony DSC-H50, rev 2.00/1.00, addr 4
umass0: using ATAPI over Bulk-Only
atapibus1 at umass0: 2 targets
sd0 at atapibus1 drive 0: <Sony, DSC, 1.00> disk removable
sd0: fabricating a geometry
sd0: 7693 MB, 7693 cyl, 64 head, 32 sec, 512 bytes/sect x 15755264 sectors
fabricating a geometry
fdisk(8) says:
--------------
$ fdisk /dev/sd0
fdisk: Cannot determine the number of heads
Disk: /dev/sd0d
NetBSD disklabel disk geometry:
cylinders: 7693, heads: 64, sectors/track: 32 (2048 sectors/cylinder)
total sectors: 15755264
BIOS disk geometry:
cylinders: 980, heads: 255, sectors/track: 63 (16065 sectors/cylinder)
total sectors: 15755264
Partitions aligned to 16065 sector boundaries, offset 63
Partition table:
0: Primary DOS with 32 bit FAT - LBA (sysid 12)
start 192, size 15755046 (7693 MB, Cyls 0/3/4-980/183/9), Active
1: <UNUSED>
2: <UNUSED>
3: <UNUSED>
First active partition: 0
$
disklabel(8) says:
------------------
$ disklabel /dev/sd0
# /dev/sd0d:
type: ATAPI
disk: DSC
label: fictitious
flags: removable
bytes/sector: 512
sectors/track: 32
tracks/cylinder: 64
sectors/cylinder: 2048
cylinders: 7693
total sectors: 15755264
rpm: 3600
interleave: 1
trackskew: 0
cylinderskew: 0
headswitch: 0 # microseconds
track-to-track seek: 0 # microseconds
drivedata: 0
5 partitions:
# size offset fstype [fsize bsize cpg/sgs]
d: 15755264 0 unused 0 0 # (Cyl. 0 - 7692)
e: 15755046 192 MSDOS # (Cyl. 0*- 7692*)
disklabel: boot block size 0
disklabel: super block size 0
$
The panic:
----------
# mount_msdos /dev/sd0e /mnt
mount_msdos: "/mnt/" is a non-resolved or relative path.
mount_msdos: using "/mnt" instead.
panic: buf mem pool index 23
cpu0: Begin traceback...
cpu0: End traceback...
dumping to dev 0,1 offset 20063
dump 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 succeeded
rebooting...
>How-To-Repeat:
>Fix:
>Audit-Trail:
From: David Holland <dholland-bugs@netbsd.org>
To: gnats-bugs@NetBSD.org
Cc:
Subject: Re: kern/43375: panic when mount(8)ing umass(4) device (Sony
DSC-H50 Digital Camera)
Date: Sat, 29 May 2010 18:34:07 +0000
On Fri, May 28, 2010 at 12:15:00PM +0000, alan.bsd@gmail.com wrote:
> # mount_msdos /dev/sd0e /mnt
> mount_msdos: "/mnt/" is a non-resolved or relative path.
> mount_msdos: using "/mnt" instead.
> panic: buf mem pool index 23
> cpu0: Begin traceback...
> cpu0: End traceback...
Do you have that traceback, or can you get one from the dump? That
panic's from inside the filesystem I/O logic (in vfs_bio.c) and it
would be very helpful to know how we got there.
It is probably something about the msdos filesystem on the camera
that's breaking things and not a USB problem per se at all.
--
David A. Holland
dholland@netbsd.org
From: "Alan R. S. Bueno" <alan.bsd@gmail.com>
To: gnats-bugs@netbsd.org
Cc:
Subject: Re: kern/43375: panic when mount(8)ing umass(4) device (Sony DSC-H50
Digital Camera)
Date: Sat, 29 May 2010 16:23:44 -0300
On Sat, May 29, 2010 at 3:35 PM, David Holland <dholland-bugs@netbsd.org> w=
rote:
>
> =A0Do you have that traceback, or can you get one from the dump?
Yes. The system reboots after the panic, so no chance to ddb(4).
Let me know if I'm doing something wrong.
middle-earth# gunzip /var/crash/netbsd.5.core.gz
middle-earth# crash -M netbsd.5.core
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_NAPMBIOS(104,0,c0491beb,c09938a7,0,ccafb94c,104,0,0,ccafb94c) a=
t 0
procfs_vnodeop_p(104,0,c09b2180,cc91b2a0,0,2,0,ccafb958,0,0) at 0xcc91b2a0
panic(c09938a7,17,c23c32d0,0,0,cc5e0678,ccafb98c,c06707f3,cc5e0678,0)
at 0xc05b4582
buf_mempoolidx(cc5e0678,0,b0,c23c32d0,0,0,ccafb9bc,c0671b6b,c23c32d0,0)
at 0xc066fe02
allocbuf(c23c32d0,0,0,0,cc91b310,cc5e0678,0,ccafba7c,cc5e0678,0) at 0xc0670=
7f3
getblk(cc5e0678,7a0,0,0,0,0,ccafb9fc,c066fe6e,cc5e0678,cc5e0678) at 0xc0671=
b6b
bio_doread(0,ffffffff,0,c06700aa,c23c33d4,cc5e0678,cb18ce00,f0000,0,c204a60=
0)
at 0xc0671c7e
bread(cc5e0678,7a0,0,0,ffffffff,0,ccafba7c,c204a600,ccafba8c,ccb52ccd)
at 0xc0671e77
procfs_vnodeop_p(c204a600,ccb59620,0,1,10,2,40,cb2efc00,cc5e0678,cb2efe0b)
at 0xccb52cf4
procfs_vnodeop_p(cc5e0678,ccaf9200,cc91b2a0,ccafd5a0,cc91b2a0,0,3,c05b4cfc,=
ccaf9afc,2)
at 0xccb5536e
procfs_vnodeop_p(ccaf9200,bfbfe4dc,ccafd5a0,ccafbcc0,0,ccb596e0,ccafbb8c,c0=
67a3b1,c0a57390,ccaf9200)
a
t 0xccb5597d
VFS_MOUNT(ccaf9200,bfbfe4dc,ccafd5a0,ccafbcc0,ccaf9b00,ccb21f1c,cca080c0,0,=
67000,0)
at 0xc0678604
do_sys_mount(cc91b2a0,0,80492c5,bfbfe4dc,0,bfbfecdc,0,8c,ccafbd28,bbb30000)
at 0xc068144c
sys___mount50(cc91b2a0,ccafbd00,ccafbd28,ccafbd00,bbb30000,cb19d960,19a,804=
92c5,bfbfe4dc,0)
at 0xc0681
5fd
syscall(ccafbd48,b3,ab,1f,1f,bfbfe8dc,bfbfe4dc,bfbfed78,bfbfecdc,bbbccbc0)
at 0xc05c68e9
crash> ps
PID LID S CPU FLAGS STRUCT LWP * NAME WAIT
509 > 1 7 0 0 cc91b2a0 mount_msdos
559 1 3 0 80 cc4f5020 mount wait
515 1 3 0 80 cc48dd20 ksh pause
530 1 3 0 80 cc48d000 getty ttyraw
542 1 3 0 80 cc48d540 getty ttyraw
536 1 3 0 80 cc48da80 getty ttyraw
526 1 3 0 80 cc3e5020 login wait
516 1 3 0 80 cc4f52c0 cron nanoslp
517 1 3 0 80 cc48d2a0 inetd kqueue
505 1 3 0 80 cc91ba80 qmgr kqueue
479 1 3 0 80 cc91bd20 pickup kqueue
496 1 3 0 80 cc4f5560 master kqueue
213 1 3 0 80 cc4f5d40 syslogd kqueue
1 1 3 0 80 cb19cd20 init wait
0 50 3 0 200 cc48d7e0 atapibus1 sccomp
0 49 3 0 200 cc91b7e0 acpitz0 acpitz0
0 48 3 0 200 cc91b540 acpibat1 acpibat1
0 47 3 0 200 cc4f5800 acpibat0 acpibat0
0 46 3 0 200 cc4f5aa0 physiod physiod
0 45 3 0 200 cc3e52c0 aiodoned aiodoned
0 44 3 0 200 cc3e5560 ioflush syncer
0 43 3 0 200 cc3e5800 pgdaemon pgdaemon
0 42 3 0 200 cb19b020 cryptoret crypto_wai=
t
0 41 3 0 200 cc3e5aa0 atapibus0 sccomp
0 38 3 0 200 cb19b2c0 usb4 usbevt
0 37 3 0 200 cb19b560 usb3 usbevt
0 36 3 0 200 cb19b800 usb2 usbevt
0 35 3 0 200 cb19baa0 usb1 usbevt
0 34 3 0 200 cc3e5d40 usbtask-dr usbtsk
0 33 3 0 200 cb19c000 usbtask-hc usbtsk
0 32 3 0 200 cb19c2a0 usb0 usbevt
0 31 3 0 200 cb19ca80 unpgc unpgc
0 30 3 0 200 cb19c7e0 vmem_rehash vmem_rehas=
h
0 29 3 0 200 cb19c540 coretemp0 coretemp0
0 20 3 0 200 cb19bd40 iic0 iicintr
0 19 3 0 200 cb19a000 atabus1 atath
0 18 3 0 200 cb19a2a0 atabus0 atath
0 17 3 0 200 cb19a540 cardslot0 cardslotev
0 16 3 0 280 cb19a7e0 fw0probe ieee1394
0 15 3 0 200 cb19aa80 pms0 pmsreset
0 14 3 0 200 cb19ad20 apm0 apmev
0 13 3 0 200 cb191020 sysmon smtaskq
0 12 3 0 200 cb1912c0 pmfsuspend pmfsuspend
0 11 3 0 200 cb191560 pmfevent pmfevent
0 10 3 0 200 cb191800 cachegc cachegc
0 9 3 0 200 cb191aa0 vrele vrele
0 8 3 0 200 cb191d40 modunload modunload
0 7 3 0 200 cb18e000 xcall/0 xcall
0 6 1 0 200 cb18e2a0 softser/0
0 5 1 0 200 cb18e540 softclk/0
0 4 1 0 200 cb18e7e0 softbio/0
0 3 1 0 200 cb18ea80 softnet/0
0 2 1 0 201 cb18ed20 idle/0
0 1 3 0 200 c0a07e60 swapper uvm
Thank you!
From: David Holland <dholland-bugs@netbsd.org>
To: gnats-bugs@NetBSD.org
Cc:
Subject: Re: kern/43375: panic when mount(8)ing umass(4) device (Sony
DSC-H50 Digital Camera)
Date: Mon, 31 May 2010 02:09:15 +0000
On Sat, May 29, 2010 at 07:25:02PM +0000, Alan R. S. Bueno wrote:
> > Do you have that traceback, or can you get one from the dump?
>
> Yes. The system reboots after the panic, so no chance to ddb(4).
>
> Let me know if I'm doing something wrong.
You may be, because the trace doesn't entirely make sense.
> middle-earth# gunzip /var/crash/netbsd.5.core.gz
> middle-earth# crash -M netbsd.5.core
> Crash version 5.99.29, image version 5.99.29.
> System panicked: buf mem pool index %d
> Backtrace from time of crash is available.
This looks fine in principle; however, were you running the same
kernel that generated the dump? If it's not quite the same it would
explain the trace.
If in doubt use the -N /netbsd.whatever option to crash to feed it the
same kernel that generated the core.
> crash> trace
> _KERNEL_OPT_NAPMBIOS(104,0,c0491beb,c09938a7,0,ccafb94c,104,0,0,ccafb94c) a=
> t 0
> procfs_vnodeop_p(104,0,c09b2180,cc91b2a0,0,2,0,ccafb958,0,0) at 0xcc91b2a0
These don't make sense being here, but might just be junk left on the
stack (that's one of the hazards with ddb...)
procfs_vnodeop_p does not make sense either because it's data.
> panic(c09938a7,17,c23c32d0,0,0,cc5e0678,ccafb98c,c06707f3,cc5e0678,0)
> at 0xc05b4582
> buf_mempoolidx(cc5e0678,0,b0,c23c32d0,0,0,ccafb9bc,c0671b6b,c23c32d0,0)
> at 0xc066fe02
If buf_mempoolidx was really passed 0xcc5e0678, it's no wonder it
paniced. And this would in fact produce "index 23". However, I wonder
about this, for the reasons outlined below... but I don't know why ddb
would get the argument list wrong here, or if it did, why this would
be wrong and not any of the others.
> allocbuf(c23c32d0,0,0,0,cc91b310,cc5e0678,0,ccafba7c,cc5e0678,0) at 0xc06707f3
allocbuf doesn't call buf_mempoolidx, but it does call all three of
the functions that do, two of which aren't called anywhere else, so
let's assume one of those was inlined.
The second argument is the new buffer size, and it's apparently 0.
If passed to buf_mempoolidx, this would cause the same panic, also
with index 23.
However, this isn't consistent with the previous line: while
0xcc5e0678 is in the argument list here allocbuf only actually takes
three arguments, and it looks unlikely that it or any of the inlined
functions could synthesize 0xcc5e0678 to pass through to
buf_mempoolidx. Especially since that that same value appears further
down as the first argument to getblk and bread, which suggests that
it's a vnode.
> getblk(cc5e0678,7a0,0,0,0,0,ccafb9fc,c066fe6e,cc5e0678,cc5e0678) at 0xc0671b6b
This appears to be asking for a buffer of length 0 for block 0x7a0 of
vnode 0xcc5e0678.
> bio_doread(0,ffffffff,0,c06700aa,c23c33d4,cc5e0678,cb18ce00,f0000,0,c204a600)
> at 0xc0671c7e
This makes no sense at all (block -1, size 0, of a null vnode) but one
needs to go through bio_doread to get to getblk from bread.
> bread(cc5e0678,7a0,0,0,ffffffff,0,ccafba7c,c204a600,ccafba8c,ccb52ccd)
> at 0xc0671e77
This one, however, is consistent with the call to getblk.
> procfs_vnodeop_p(c204a600,ccb59620,0,1,10,2,40,cb2efc00,cc5e0678,cb2efe0b)
> at 0xccb52cf4
> procfs_vnodeop_p(cc5e0678,ccaf9200,cc91b2a0,ccafd5a0,cc91b2a0,0,3,c05b4cfc,ccaf9afc,2)
> at 0xccb5536e
> procfs_vnodeop_p(ccaf9200,bfbfe4dc,ccafd5a0,ccafbcc0,0,ccb596e0,ccafbb8c,c067a3b1,c0a57390,ccaf9200)
> at 0xccb5597d
These make no sense whatsoever; procfs_vnodeop_p is not some mystical
internal function inside procfs but procfs's array of vnode op
pointers, which is data. This suggests that the code address is out of
range.
Oh, maybe these are in the msdosfs kernel module and crash doesn't
know how to cope with that? I thought someone had taught ddb about
modules, but maybe it doesn't work for crash.
> VFS_MOUNT(ccaf9200,bfbfe4dc,ccafd5a0,ccafbcc0,ccaf9b00,ccb21f1c,cca080c0,0,67000,0)
> at 0xc0678604
> do_sys_mount(cc91b2a0,0,80492c5,bfbfe4dc,0,bfbfecdc,0,8c,ccafbd28,bbb30000)
> at 0xc068144c
> sys___mount50(cc91b2a0,ccafbd00,ccafbd28,ccafbd00,bbb30000,cb19d960,19a,80492c5,bfbfe4dc,0)
> at 0xc06815fd
> syscall(ccafbd48,b3,ab,1f,1f,bfbfe8dc,bfbfe4dc,bfbfed78,bfbfecdc,bbbccbc0)
> at 0xc05c68e9
and that looks all perfectly reasonable.
ok, I think the most likely interpretation (despite the parts that
don't make sense) is that msdosfs asked for a zero-length buffer and
this caused the buffer cache code to panic.
There are two ways to go about debugging this further: one is to use
rump_msdos, which should exhibit the same behavior but being entirely
userlevel can be run in a debugger and also won't kill the system when
it fails.
The other is to go ahead and boot and crash a test kernel; if you
compile msdosfs in instead of loading it as a module, you'll probably
get sane stuff out of crash; alternatively, if you include ddb and set
the ddb.onpanic sysctl to 1, you may be able to get a working
backtrace directly from ddb. Either way, enable DIAGNOSTIC for good
measure.
It may also be helpful to add this:
if (size == 0) {
panic("bread: zero-length buf requested\n");
}
to the top of bread() (at around line 732 of sys/kern/vfs_bio.c),
because if that goes off it will save the trouble of wading through
the buffer code.
--
David A. Holland
dholland@netbsd.org
From: David Holland <dholland-bugs@netbsd.org>
To: gnats-bugs@netbsd.org
Cc:
Subject: Re: kern/43375: panic when mount(8)ing umass(4) device (Sony
DSC-H50 Digital Camera)
Date: Mon, 31 May 2010 02:19:05 +0000
On Mon, May 31, 2010 at 02:10:05AM +0000, David Holland wrote:
> It may also be helpful to add this:
>
> if (size == 0) {
> panic("bread: zero-length buf requested\n");
> }
>
> to the top of bread() (at around line 732 of sys/kern/vfs_bio.c),
> because if that goes off it will save the trouble of wading through
> the buffer code.
also try this patch:
Index: fs/msdosfs/msdosfs_vfsops.c
===================================================================
RCS file: /cvsroot/src/sys/fs/msdosfs/msdosfs_vfsops.c,v
retrieving revision 1.85
diff -u -p -r1.85 msdosfs_vfsops.c
--- sys/fs/msdosfs/msdosfs_vfsops.c 13 Apr 2010 10:12:43 -0000 1.85
+++ sys/fs/msdosfs/msdosfs_vfsops.c 31 May 2010 02:15:45 -0000
@@ -498,6 +498,10 @@ msdosfs_mountfs(struct vnode *devvp, str
psize = 0;
error = 0;
}
+ if (secsize == 0) {
+ printf("msdosfs: getdisksize said the sector size was 0\n");
+ secsize = DEV_BSIZE;
+ }
if (argp->flags & MSDOSFSMNT_GEMDOSFS) {
bsize = secsize;
I don't know if this is where the zero-length read is coming from, but
it's not a bad bet.
--
David A. Holland
dholland@netbsd.org
From: Antti Kantee <pooka@cs.hut.fi>
To: gnats-bugs@netbsd.org
Cc:
Subject: Re: kern/43375
Date: Mon, 31 May 2010 12:29:58 +0300
This problem happens when some garbage parameter is read by mountfs and
subsequent calculations for file system access go wrong. The easiest
way, apart from an educated guess, is to single step the mountfs and/or
inspect the contents of pmp at the end.
It's also another good reminder that one should not mount file systems
from an untrusted source with an in-kernel driver for security reasons.
From: "Alan R. S. Bueno" <alan.bsd@gmail.com>
To: gnats-bugs@netbsd.org
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> wrote:
> The following reply was made to PR kern/43375; it has been noted by GNATS=
.
>
> From: David Holland <dholland-bugs@netbsd.org>
> To: gnats-bugs@NetBSD.org
> 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
From: "Alan R. S. Bueno" <alan.bsd@gmail.com>
To: gnats-bugs@netbsd.org
Cc:
Subject: Re: kern/43375: panic when mount(8)ing umass(4) device (Sony DSC-H50
Digital Camera)
Date: Sun, 19 Jun 2011 11:13:46 -0300
Additional info from FreeBSD (9.0-CURRENT, 2011-06-10).
*Maybe* the FreeBSD's dmesg(1) messages can help to solve the problem.
As was said, the camera works ok with FreeBSD, OpenBSD, and GNU/Linux.
After plug the camera:
----------------------
ugen4.4: <Sony> at usbus4
umass0: <Sony DSC-H50, class 0/0, rev 2.00/1.00, addr 4> on usbus4
umass0: 8070i (ATAPI) over Bulk-Only; quirks = 0x0000
umass0:3:0:-1: Attached to scbus3
da0 at umass-sim0 bus 0 scbus3 target 0 lun 0
da0: <Sony DSC 1.00> Removable Direct Access SCSI-0 device
da0: 40.000MB/s transfers
da0: 7693MB (15755264 512 byte sectors: 255H 63S/T 980C)
GEOM: da0s1: EBR has non empty bootcode.
GEOM: msdosfs/ : EBR has non empty bootcode.
mount -t msdosfs /dev/da0s1 /mnt:
---------------------------------
Warning: number of clusters (246114) exceeds FAT capacity (245760)
umount /mnt:
------------
GEOM: da0s1: EBR has non empty bootcode.
GEOM: msdosfs/ : EBR has non empty bootcode.
After unplug the camera:
------------------------
ugen4.4: <Sony> at usbus4 (disconnected)
umass0: at uhub4, port 4, addr 4 (disconnected)
(da0:umass-sim0:0:0:0): lost device
(da0:umass-sim0:0:0:0): removing device entry
(Contact us)
$NetBSD: query-full-pr,v 1.39 2013/11/01 18:47:49 spz Exp $
$NetBSD: gnats_config.sh,v 1.8 2006/05/07 09:23:38 tsutsui Exp $
Copyright © 1994-2007
The NetBSD Foundation, Inc. ALL RIGHTS RESERVED.