Re: R e: VFS panic is now fixed.
if i can help, please let me know! all im doing is: newfs /dev/ad0s2a mount /dev/ad0s2a /mnt-root rsh dev -n dump 0f - /c/4 | restore rf - and after a short while it panics. with today's cvsup, and with this 'fix': *** vfs_subr.c 2002/09/29 08:16:40 1.1 --- vfs_subr.c 2002/09/29 10:36:04 *** *** 877,883 s = splbio(); mtx_lock(&vnode_free_list_mtx); ! /* * Try to reuse vnodes if we hit the max. This situation only * occurs in certain large-memory (2G+) situations. We cannot --- 877,883 s = splbio(); mtx_lock(&vnode_free_list_mtx); ! vnmp = 0; /* * Try to reuse vnodes if we hit the max. This situation only * occurs in certain large-memory (2G+) situations. We cannot im now getting a differnet panic :-) lock order reversal 1st 0xc058fd20 vnode_free_list (vnode_free_list) @ /r+d/5.0/src/sys/kern/vfs_subr.c:879 2nd 0xc26653d8 process lock (process lock) @ /r+d/5.0/src/sys/i386/i386/trap.c :731 Fatal trap 12: page fault while in kernel mode fault virtual address = 0x48 fault code = supervisor read, page not present instruction pointer = 0x8:0xc03268d6 stack pointer = 0x10:0xcc8287e0 frame pointer = 0x10:0xcc82882c code segment= base 0x0, limit 0xf, type 0x1b = DPL 0, pres 1, def32 1, gran 1 processor eflags= interrupt enabled, resume, IOPL = 0 current process = 267 (restore) kernel: type 12 trap, code=0 Stopped at getnewvnode+0xc6: cmpl$0,0x48(%ebx) db> trace getnewvnode(c04d18c9,c25d3a00,c2301700,cc828884,c757d0ae) at getnewvnode+0xc6 ffs_vget(c25d3a00,8cdd,2,cc8288f4,8180) at ffs_vget+0x93 ffs_valloc(c2a04de0,8180,c2741400,cc8288f4,cc8288f8) at ffs_valloc+0x100 ufs_makeinode(8180,c2a04de0,cc828bec,cc828c00,602) at ufs_makeinode+0x69 ufs_create(cc828a48,cc828a68,c0334919,cc828a48,c04e7780) at ufs_create+0x39 ufs_vnoperate(cc828a48,c04e7780,c2a04de0,cc828bec,cc828c00) at ufs_vnoperate+0x18 VOP_CREATE(c2a04de0,cc828bec,cc828c00,cc828aac,2) at VOP_CREATE+0x39 vn_open_cred(cc828bd8,cc828cd8,180,c2741400,cc828cc4) at vn_open_cred+0x179 vn_open(cc828bd8,cc828cd8,180,28f,c056a5c0) at vn_open+0x29 kern_open(c22a1480,80b32d3,0,602,1b6) at kern_open+0x183 open(c22a1480,cc828d10,c04de480,418,3) at open+0x30 syscall(2f,2f,2f,80b32d3,0) at syscall+0x2be Xint0x80_syscall() at Xint0x80_syscall+0x1d --- syscall (5, FreeBSD ELF32, open), eip = 0x8054953, esp = 0xbfbff41c, ebp = 0xbfbff468 --- db> To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: R e: VFS panic is now fixed.
> > On Thu, 26 Sep 2002, Danny Braniss wrote: > I am not able to reproduce this. Can you tell me how your kernel conf > differs from GENERIC as well as provide some details on how you trigered > this? > > Jeff > sure, the kernel is GENERIC, no changes. (with one change, in /sys/kern/vfs_subr.c i added in getnewvnode: vnmp = 0; because it seems suspiciosly not initialized. but it also panics - differently - without it. the host is diskless, as long as the disk is not touched, all seems ok. i can reproduce the panic so: shuttle# newfs /dev/ad0s2a /dev/ad0s2a: 500.0MB (1024000 sectors) block size 16384, fragment size 2048 using 4 cylinder groups of 125.02MB, 8001 blks, 16128 inodes. super-block backups (for fsck -b #) at: 32, 256064, 512096, 768128 shuttle# mount /dev/ad0s2a /mnt-root shuttle# cd /mnt-root shuttle# rsh dev -n dump 0f - /c/4 | restore rf - DUMP: Date of this level 0 dump: Fri Sep 27 09:54:49 2002 DUMP: Date of last level 0 dump: the epoch DUMP: Dumping /dev/aacd0s4e (/c/4) to standard output DUMP: mapping (Pass I) [regular files] DUMP: mapping (Pass II) [directories] DUMP: estimated 377991 tape blocks. DUMP: dumping (Pass III) [directories] DUMP: dumping (Pass IV) [regular files] and after short while: lock order reversal 1st 0xc058bfe0 vnode_free_list (vnode_free_list) @ /r+d/5.0/src/sys/kern/vfs_subr.c:880 2nd 0xc23fbab8 process lock (process lock) @ /r+d/5.0/src/sys/i386/i386/trap.c :731 Fatal trap 12: page fault while in kernel mode fault virtual address = 0x48 fault code = supervisor read, page not present instruction pointer = 0x8:0xc0325226 stack pointer = 0x10:0xcfbca7e0 frame pointer = 0x10:0xcfbca82c code segment= base 0x0, limit 0xf, type 0x1b = DPL 0, pres 1, def32 1, gran 1 processor eflags= interrupt enabled, resume, IOPL = 0 current process = 2651 (restore) kernel: type 12 trap, code=0 Stopped at getnewvnode+0xc6: cmpl$0,0x48(%ebx) db> trace getnewvnode(c04ce4e9,c2453200,c1fbc500,cfbca884,c6c450ae) at getnewvnode+0xc6 ffs_vget(c2453200,5f9,2,cfbca8f4,8180) at ffs_vget+0x93 ffs_valloc(c293f000,8180,c241,cfbca8f4,cfbca8f8) at ffs_valloc+0x100 ufs_makeinode(8180,c293f000,cfbcabec,cfbcac00,602) at ufs_makeinode+0x69 ufs_create(cfbcaa48,cfbcaa68,c0333259,cfbcaa48,c04e3e80) at ufs_create+0x39 ufs_vnoperate(cfbcaa48,c04e3e80,c293f000,cfbcabec,cfbcac00) at ufs_vnoperate+0x18 VOP_CREATE(c293f000,cfbcabec,cfbcac00,cfbcaaac,2) at VOP_CREATE+0x39 vn_open_cred(cfbcabd8,cfbcacd8,180,c241,cfbcacc4) at vn_open_cred+0x179 vn_open(cfbcabd8,cfbcacd8,180,28f,0) at vn_open+0x29 kern_open(c23fa000,80b32b3,0,602,1b6) at kern_open+0x183 open(c23fa000,cfbcad10,c04daba0,418,3) at open+0x30 syscall(2f,2f,2f,80b32b3,0) at syscall+0x2be Xint0x80_syscall() at Xint0x80_syscall+0x1d --- syscall (5, FreeBSD ELF32, open), eip = 0x8054953, esp = 0xbfbff75c, ebp = 0xbfbff7a8 --- db> To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: R e: VFS panic is now fixed.
On Thu, 26 Sep 2002, Danny Braniss wrote:
> if this is of any help:
>
> panic: vn_finished_write: neg cnt
> Debugger("panic")
> Stopped at Debugger+0x54: xchgl %ebx,in_Debugger.0
> db> trace
> Debugger(c04b2d1c,c05664e0,c04bcd6b,cb4607d8,1) at Debugger+0x54
> panic(c04bcd6b,cb46082c,c0325417,c05298e0,0) at panic+0xab
> vn_finished_write(c05298e0,0,c04bc4e0,3ad,c03deb2b) at vn_finished_write+0x22
> getnewvnode(c04ce4c9,c240fe00,c1fbc500,cb460884,c67a10ae) at getnewvnode+0x2b7
> ffs_vget(c240fe00,831a,2,cb4608f4,8180) at ffs_vget+0x93
> ffs_valloc(c25c2940,8180,c241af00,cb4608f4,cb4608f8) at ffs_valloc+0x100
> ufs_makeinode(8180,c25c2940,cb460bec,cb460c00,602) at ufs_makeinode+0x69
> ufs_create(cb460a48,cb460a68,c0333249,cb460a48,c04e3e60) at ufs_create+0x39
> ufs_vnoperate(cb460a48,c04e3e60,c25c2940,cb460bec,cb460c00) at
> ufs_vnoperate+0x18
> VOP_CREATE(c25c2940,cb460bec,cb460c00,cb460aac,2) at VOP_CREATE+0x39
> vn_open_cred(cb460bd8,cb460cd8,180,c241af00,cb460cc4) at vn_open_cred+0x179
> vn_open(cb460bd8,cb460cd8,180,28f,0) at vn_open+0x29
> kern_open(c1f5d240,80b32e0,0,602,1b6) at kern_open+0x183
> open(c1f5d240,cb460d10,c04dab80,418,3) at open+0x30
> syscall(2f,2f,2f,80b32e0,0) at syscall+0x2be
> Xint0x80_syscall() at Xint0x80_syscall+0x1d
> --- syscall (5, FreeBSD ELF32, open), eip = 0x8054953, esp = 0xbfbff75c, ebp =
> 0xbfbff7a8 ---
I am not able to reproduce this. Can you tell me how your kernel conf
differs from GENERIC as well as provide some details on how you trigered
this?
Jeff
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
R e: VFS panic is now fixed.
if this is of any help:
panic: vn_finished_write: neg cnt
Debugger("panic")
Stopped at Debugger+0x54: xchgl %ebx,in_Debugger.0
db> trace
Debugger(c04b2d1c,c05664e0,c04bcd6b,cb4607d8,1) at Debugger+0x54
panic(c04bcd6b,cb46082c,c0325417,c05298e0,0) at panic+0xab
vn_finished_write(c05298e0,0,c04bc4e0,3ad,c03deb2b) at vn_finished_write+0x22
getnewvnode(c04ce4c9,c240fe00,c1fbc500,cb460884,c67a10ae) at getnewvnode+0x2b7
ffs_vget(c240fe00,831a,2,cb4608f4,8180) at ffs_vget+0x93
ffs_valloc(c25c2940,8180,c241af00,cb4608f4,cb4608f8) at ffs_valloc+0x100
ufs_makeinode(8180,c25c2940,cb460bec,cb460c00,602) at ufs_makeinode+0x69
ufs_create(cb460a48,cb460a68,c0333249,cb460a48,c04e3e60) at ufs_create+0x39
ufs_vnoperate(cb460a48,c04e3e60,c25c2940,cb460bec,cb460c00) at
ufs_vnoperate+0x18
VOP_CREATE(c25c2940,cb460bec,cb460c00,cb460aac,2) at VOP_CREATE+0x39
vn_open_cred(cb460bd8,cb460cd8,180,c241af00,cb460cc4) at vn_open_cred+0x179
vn_open(cb460bd8,cb460cd8,180,28f,0) at vn_open+0x29
kern_open(c1f5d240,80b32e0,0,602,1b6) at kern_open+0x183
open(c1f5d240,cb460d10,c04dab80,418,3) at open+0x30
syscall(2f,2f,2f,80b32e0,0) at syscall+0x2be
Xint0x80_syscall() at Xint0x80_syscall+0x1d
--- syscall (5, FreeBSD ELF32, open), eip = 0x8054953, esp = 0xbfbff75c, ebp =
0xbfbff7a8 ---
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
