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

NetBSD Home
NetBSD PR Database Search

(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.