Re: NT filesystem panicking my current box

[Mark Huizer]

On Sat, Oct 20, 2001 at 08:18:35PM -0700, Matthew Dillon wrote:
 Try turning off vmiodirenable:
 
sysctl -w vfs.vmiodirenable=0
 
 And see if that makes a difference.
 
   -Matt

Nope, it crashes just as fast.
I am now turning on crash dumps, so I can at least give a backtrace

This is the crash message

IdlePTD 5226496
initial pcb at 3b3500
panicstr: bwrite: buffer is not busy???
panic messages:
---
panic: lockmgr: pid 556, not exclusive lock holder 536 unlocking

syncing disks... panic: bwrite: buffer is not busy???
Uptime: 8m48s
pfs_vncache_unload(): 1 entries remaining

This is the backtrace:

#0  0xc021013e in dumpsys ()
#1  0xc020ff2b in boot ()
#2  0xc0210338 in poweroff_wait ()
#3  0xc023c6cf in bwrite ()
#4  0xc023d958 in vfs_bio_awrite ()
#5  0xc01e9588 in spec_fsync ()
#6  0xc01e9171 in spec_vnoperate ()
#7  0xc02b95d8 in ffs_sync ()
#8  0xc0248ce9 in sync ()
#9  0xc020fb30 in boot ()
#10 0xc0210338 in poweroff_wait ()
#11 0xc0206b59 in lockmgr ()
#12 0xc02423f2 in vop_stdunlock ()
#13 0xc046bcbc in ?? ()
#14 0xc02461e3 in vput ()
#15 0xc024aba1 in lstat ()
#16 0xc02f19f4 in syscall ()
#17 0xc02e603d in syscall_with_err_pushed ()
#18 0x804b27a in ?? ()
#19 0x804a58d in ?? ()
#20 0x8052d19 in ?? ()
#21 0x8048135 in ?? ()

Unfortunately I've already done a cvsup since that build, so it will
take a buildworld cycle to get a kernel with more symbol information. I
will start that work now

Mark

 :2 seconds of testing showed that 'tar -czf /dev/null /nt' was enough for
 :a kernel panick within 2 seconds.
 :
 :A few upgrades later the problem still exists.
 :

-- 
Nice testing in little China...

To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message

Re: NT filesystem panicking my current box

[Matthew Dillon]

Try turning off vmiodirenable:

   sysctl -w vfs.vmiodirenable=0

And see if that makes a difference.

-Matt

:On one of my current boxes I run amanda, which some 2 weeks ago (after an
:upgrade to that current) started dying reliable when the backup started.
:
:the ntfs FS is mounted on /nt
:
:2 seconds of testing showed that 'tar -czf /dev/null /nt' was enough for
:a kernel panick within 2 seconds.
:
:A few upgrades later the problem still exists.
:
:Before I go through the trouble of collecting the backtraces and make
:kernel dumps and all: do other people have this problem as well? Or is
:this part of the NTFS module not really updated after the KSE happening?
:(I have now disabled all local filesystems from the backup, since only
:excluding the NTFS backup didn't solve the problem, still a crash, that
:one I haven't looked at later on)
:
:Mark

To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message