Bug 30160

Summary: [panic] kernel panic when flash disk is removed and the flash disk is mounted.
Product: Base System Reporter: jonas <jonas>
Component: kernAssignee: freebsd-bugs (Nobody) <bugs>
Status: Closed FIXED    
Severity: Affects Only Me    
Priority: Normal    
Version: 4.3-STABLE   
Hardware: Any   
OS: Any   

Description jonas 2001-08-28 12:00:01 UTC
Kernel panics if a file system (FAT in this case)) is accessed and the underlying flash disk is removed. (/kernel: ad8: 15MB <SanDisk SDCFB-16> [490/2/32] at ata4-master BIOSPIO)

This happens, for instance, if a flash disk is used in a laptop and the laptop is suspended. When the laptop is resumed, the first access to the file system on the mounted flash disk will cause a kernel panic.

How-To-Repeat: See above.
Comment 1 iedowse freebsd_committer freebsd_triage 2002-12-01 12:23:56 UTC
State Changed
From-To: open->feedback


Do you have any details from the panic? I actually doubt that this 
has been fixed, but it would be useful to get the panic message and 
stack trace from a more recent release. You may find that using the 
mtools package to access the device instead of mounting it is an 
acceptable workaround.
Comment 2 iedowse 2002-12-01 16:11:00 UTC
Adding to the audit trail:

In message <3DEA2F2C.2010201@servicefactory.se>, =?ISO-8859-1?Q?Jonas_B=FClow?=
 writes:
>Hi!
>
>Ian Dowse wrote:
>> Synopsis: Kernel panic when flash disk is removed and the flash disk is moun
>ted.
>> 
>> State-Changed-From-To: open->feedback
>> State-Changed-By: iedowse
>> State-Changed-When: Sun Dec 1 04:23:56 PST 2002
>> State-Changed-Why: 
>> 
>> Do you have any details from the panic? I actually doubt that this
>> has been fixed, but it would be useful to get the panic message and
>> stack trace from a more recent release. You may find that using the
>> mtools package to access the device instead of mounting it is an
>> acceptable workaround.
>
>A triggered a kernel panic by:
>1. Insert flash disk
>2. Mount it as msdos fils system
>3. Access the all files from the mount point.
>4. Remove the flash disk
>5. Access the files from the mount point. Reading files not in cache 
>will show "Device not configured"
>6. Insert flash disk again.
>7. Access files now gives a kernel panic
>
>Backtrace:
>
>Program received signal SIGSEGV, Segmentation fault.
>dscheck (bp=0xc4d02634, ssp=0x0) at ../../kern/subr_diskslice.c:159
>159	../../kern/subr_diskslice.c: No such file or directory.
>(gdb) bt full
>#0  dscheck (bp=0xc4d02634, ssp=0x0) at ../../kern/subr_diskslice.c:159
>	blkno = 19641
>	endsecno = 18
>	labelsect = -889455588
>	lp = (struct disklabel *) 0xc4d02634
>	msg = 0x8c <Address 0x8c out of bounds>
>	nsec = 19641
>	pp = (struct partition *) 0x8c
>	secno = -992991692
>	slicerel_secno = -992991692
>	sp = (struct diskslice *) 0x8c
>	s = 0
>#1  0xc01629d2 in diskstrategy (bp=0xc4d02634) at ../../kern/subr_disk.c:246
>	bp = (struct buf *) 0xc4d02634
>	dp = (struct disk *) 0xc0f26d58
>#2  0xc0192b39 in spec_strategy (ap=0xcafbfc64)
>     at ../../miscfs/specfs/spec_vnops.c:479
>	ap = (struct vop_strategy_args *) 0xcb157540
>	bp = (struct buf *) 0xc4d02634
>	vp = (struct vnode *) 0xcb157540
>	mp = (struct mount *) 0x8c
>#3  0xc0192535 in spec_vnoperate (ap=0xcafbfc64)
>     at ../../miscfs/specfs/spec_vnops.c:119
>	ap = (struct vop_generic_args *) 0x0
>#4  0xc01d7225 in ufs_vnoperatespec (ap=0xcafbfc64)
>     at ../../ufs/ufs/ufs_vnops.c:2440
>	ap = (struct vop_generic_args *) 0x0
>#5  0xc017ec72 in bread (vp=0xcb157540, blkno=19641, size=4096, cred=0x0,
>     bpp=0xcafbfce4) at vnode_if.h:944
>	a = {a_desc = 0xc024fcc0, a_vp = 0xcb157540, a_bp = 0xc4d02634}
>	vp = (struct vnode *) 0xcb157540
>	bp = (struct buf *) 0xc4d02634
>	blkno = 140
>	size = 0
>	cred = (struct ucred *) 0x0
>	bpp = (struct buf **) 0xcafbfce4
>	bp = (struct buf *) 0xc4d02634
>#6  0xc0196d51 in readep (pmp=0xc1118800, dirclust=2450, diroffset=0,
>     bpp=0xcafbfce4, epp=0xcafbfce8) at ../../msdosfs/msdosfs_lookup.c:876
>	pmp = (struct msdosfsmount *) 0xc1118800
>	dirclust = 2450
>	error = 4096
>	bn = 0
>	blsize = 4096
>#7  0xc01942a6 in deget (pmp=0xc1118800, dirclust=2450, diroffset=0,
>     depp=0xcafbfd60) at ../../msdosfs/msdosfs_denode.c:329
>	dirclust = 2450
>	error = 1717986919
>	dev = 0xc0f65480
>	mntp = (struct mount *) 0x66666667
>	direntptr = (struct direntry *) 0x0
>	ldep = (struct denode *) 0xc10cf900
>	nvp = (struct vnode *) 0xcb197f00
>	bp = (struct buf *) 0xc4d02634
>	p = (struct proc *) 0xc9e1b8e0
>	tv = {tv_sec = 1, tv_usec = -889454924}
>#8  0xc019665d in msdosfs_lookup (ap=0xcafbfdc4)
>     at ../../msdosfs/msdosfs_lookup.c:539
>	ap = (struct vop_cachedlookup_args *) 0x8c
>	vdp = (struct vnode *) 0xcb196340
>	vpp = (struct vnode **) 0xcafbfea0
>	cnp = (struct componentname *) 0xcafbfeb4
>	bn = 65
>	error = -981147296
>	lockparent = 0
>	wantparent = 0
>	slotcount = 2450
>	slotoffset = 0
>	frcn = 0
>	cluster = 2450
>	blkoff = 0
>	diroff = 352
>	blsize = 4096
>	isadir = 16
>	scn = 2450
>	pdp = (struct vnode *) 0xcb196340
>	dp = (struct denode *) 0xc10cdf00
>	tdp = (struct denode *) 0x0
>	pmp = (struct msdosfsmount *) 0xc1118800
>	bp = (struct buf *) 0x0
>	dep = (struct direntry *) 0xc584e160
>	dosfilename = "XVPICS     "
>	flags = 49284
>	nameiop = 0
>	p = (struct proc *) 0xc9e1b8e0
>	unlen = 6
>	wincnt = 1
>	chksum = -1
>	olddos = 1
>#9  0xc0182a96 in vfs_cache_lookup (ap=0xcafbfe10) at vnode_if.h:77
>	rc = 140
>	a = {a_desc = 0xc024f500, a_dvp = 0xcb196340, a_vpp = 0xcafbfea0,
>   a_cnp = 0xcafbfeb4}
>	dvp = (struct vnode *) 0xcb196340
>	vpp = (struct vnode **) 0xcafbfea0
>	cnp = (struct componentname *) 0xcafbfeb4
>	ap = (struct vop_lookup_args *) 0x8c
>	dvp = (struct vnode *) 0xcb196340
>	vp = (struct vnode *) 0xc024fc00
>	lockparent = 0
>	error = 0
>	vpp = (struct vnode **) 0xcafbfea0
>	cnp = (struct componentname *) 0xcafbfeb4
>	cred = (struct ucred *) 0x0
>	flags = 49284
>	p = (struct proc *) 0xc9e1b8e0
>	vpid = 3222859177
>#10 0xc0185a75 in lookup (ndp=0xcafbfe8c) at vnode_if.h:52
>	a = {a_desc = 0xc024f4c0, a_dvp = 0xcb196340, a_vpp = 0xcafbfea0,
>   a_cnp = 0xcafbfeb4}
>	dvp = (struct vnode *) 0xcb196340
>	cnp = (struct componentname *) 0xcafbfeb4
>	cp = 0xcb046c06 ""
>	dp = (struct vnode *) 0xcb196340
>	tdp = (struct vnode *) 0x0
>	mp = (struct mount *) 0xcb046c06
>	docache = 32
>	wantparent = 0
>	rdonly = 0
>	trailing_slash = 0
>	error = 0
>	dpunlocked = 0
>	cnp = (struct componentname *) 0xcafbfeb4
>	p = (struct proc *) 0xc9e1b8e0
>#11 0xc0185560 in namei (ndp=0xcafbfe8c) at ../../kern/vfs_lookup.c:153
>	fdp = (struct filedesc *) 0xc118b100
>	cp = 0xc118b100 "0?\030?\200?\030?@c\031?"
>	dp = (struct vnode *) 0xcb196340
>	aiov = {iov_base = 0x0, iov_len = 0}
>	auio = {uio_iov = 0x0, uio_iovcnt = 0, uio_offset = 0, uio_resid = 0,
>   uio_segflg = UIO_USERSPACE, uio_rw = UIO_READ, uio_procp = 0x0}
>	error = -887528640
>	linklen = -887528640
>	cnp = (struct componentname *) 0xcafbfeb4
>	p = (struct proc *) 0xc9e1b8e0
>#12 0xc018b3d1 in lstat (p=0xc9e1b8e0, uap=0xcafbff80)
>     at ../../kern/vfs_syscalls.c:1823
>	p = (struct proc *) 0xc9e1b8e0
>	error = 2
>	vp = (struct vnode *) 0xc9e1b8e0
>	sb = {st_dev = 3387013344, st_ino = 4, st_mode = 65408,
>   st_nlink = 51963, st_uid = 0, st_gid = 3407438656, st_rdev = 0,
>   st_atimespec = {tv_sec = 134971624, tv_nsec = 3864}, st_mtimespec = {
>     tv_sec = -1054066688, tv_nsec = -1071317952}, st_ctimespec = {
>     tv_sec = -887528640, tv_nsec = 0}, st_size = -3820179583120852768,
>   st_blocks = 0, st_blksize = 3405512428, st_flags = 1, st_gen = 384,
>   st_lspare = 0, st_qspare = {3864, 11995447168}}
>	nd = {ni_dirp = 0x80b2740 "xvpics", ni_segflg = UIO_USERSPACE,
>   ni_startdir = 0x0, ni_rootdir = 0xcaba4e00, ni_topdir = 0x0, ni_vp = 
>0x0,
>   ni_dvp = 0xcb196340, ni_pathlen = 1, ni_next = 0xcb046c06 "",
>   ni_loopcnt = 0, ni_cnd = {cn_nameiop = 0, cn_flags = 49284,
>     cn_proc = 0xc9e1b8e0, cn_cred = 0xc104ef80,
>     cn_pnbuf = 0xcb046c00 "xvpics", cn_nameptr = 0xcb046c00 "xvpics",
>     cn_namelen = 6, cn_consume = 0}}
>#13 0xc02112a5 in syscall2 (frame={tf_fs = 47, tf_es = 47, tf_ds = 47,
>       tf_edi = 134971608, tf_esi = 1, tf_ebp = -1077939476,
>       tf_isp = -889454636, tf_ebx = 134948608, tf_edx = 0, tf_ecx = 
>134948608,
>       tf_eax = 190, tf_trapno = 12, tf_err = 2, tf_eip = 134594784,
>       tf_cs = 31, tf_eflags = 647, tf_esp = -1077939632, tf_ss = 47})
>     at ../../i386/i386/trap.c:1175
>	params = 0xbfbff254 "@'\013\b\210???\214???\025\211\b\b\200"
>	i = 140
>	callp = (struct sysent *) 0xc0253090
>	p = (struct proc *) 0xc9e1b8e0
>	orig_tf_eflags = 647
>	sticks = 0
>	error = 0
>	narg = 2
>	args = {134948672, -1077939576, 4096, 134930772, 0, 0, 0, 0}
>	code = 190
>#14 0xc0202065 in Xint0x80_syscall ()
>No symbol table info available.
>#15 0x805b897 in ?? ()
>No symbol table info available.
>#16 0x805b361 in ?? ()
>No symbol table info available.
>#17 0x8048d47 in ?? ()
>No symbol table info available.
>#18 0x8048b6b in ?? ()
>No symbol table info available.
>#19 0x8048180 in ?? ()
>No symbol table info available.
>
>Regards,
>	Jonas
>
>
>> 
>> http://www.freebsd.org/cgi/query-pr.cgi?pr=30160
>
>
Comment 3 Remko Lodder freebsd_committer freebsd_triage 2006-11-12 10:37:36 UTC
State Changed
From-To: feedback->open

Reset to open, the requested feedback had been recieved 


Comment 4 Remko Lodder freebsd_committer freebsd_triage 2006-11-12 10:37:36 UTC
Responsible Changed
From-To: freebsd-bugs->iedowse

Assign to iedowse, he had been working on this some italian time ago.
Comment 5 Mark Linimon freebsd_committer freebsd_triage 2007-07-31 15:54:40 UTC
Responsible Changed
From-To: iedowse->freebsd-bugs

With permission, reassign from committer who is away from FreeBSD work for now.
Comment 6 Scott Long freebsd_committer freebsd_triage 2007-11-16 04:36:46 UTC
State Changed
From-To: open->closed

Closing due to the age of this bug.  The stack trace goes into code that no 
longer exists in FreeBSD.