Date: Tue, 3 Mar 1998 04:50:01 -0800 (PST) From: Bruce Evans <bde@zeta.org.au> To: freebsd-bugs Subject: Re: kern/5904: panic: newfs Message-ID: <199803031250.EAA04670@hub.freebsd.org>
next in thread | raw e-mail | index | archive | help
The following reply was made to PR kern/5904; it has been noted by GNATS. From: Bruce Evans <bde@zeta.org.au> To: freebsd-gnats-submit@FreeBSD.ORG, jason_smethers@bigfoot.com Cc: Subject: Re: kern/5904: panic: newfs Date: Tue, 3 Mar 1998 23:36:08 +1100 >>Description: >When newfs a drive with: >su-2.01#umount /dev/wd3c >su-2.01#newfs -b 8192 -f 1024 /dev/wd3c > >the system panics with: >panic: bremfree removing a buffer whan not on a queue I think there is already a PR for this. It is caused by stale objects for the vnode of the device. Mounting a ufs file system provides an object, normally with a block size of 8K. The object doesn't go away on unmount, and a too-small block size of 2K is used for block devices, and either the different block sizes or the existence of the object cause the panic. Possible workaround: don't newfs the block device. (Never newfs a block device anyway. Block devices are normally slower (normally much slower for newfs) and always give worse error reporting.) I'm not sure if this actually avoids the problem. There may be a coherency problem when the new file system is mounted, or the block size of the new file system may be different A related problem: # mount -t msdosfs /dev/wd3c ... # umount /dev/wd3c # device containing an msdosfs file system # vnode doesn't have an object # mount -t ufs /dev/wd3c ... # oops # vnode now has an object # mount -t msdosfs /dev/wd3c ... # panic Here the existence of the object causes the panic. msdosfs requests misaligned blocks, and allocbuf() can't handle this. Bruce To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-bugs" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199803031250.EAA04670>