Re: UFS related panic (daily <-> find)
> On Wednesday, October 02, 2013 5:40:02 pm rank1see...@gmail.com wrote: > > > > > > Ok, here is another one, same case, just this time under > > 9.1-RELEASE-p7 > > > > > > > > > > > > == > > > > > > Fatal trap 12: page fault while in kernel mode > > > > > > fault virtual address = 0x25 > > > > > > fault code = supervisor read, page not present > > > > > > instruction pointer = 0x20:0xc082c552 > > > > > > stack pointer = 0x28:0xe7eed7a8 > > > > > > frame pointer = 0x28:0xe7eed7ac > > > > > > 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 = 63645 (find) > > > > > > trap number = 12 > > > > > > panic: page fault > > > > > > Uptime: 11h16m47s > > > > > > Physical memory: 1014 MB > > > > > > Dumping 143 MB: 128 112 96 80 64 48 32 16 > > > > > > > > > > > > #6 0xc0898d4c in calltrap () at > > /usr/src/sys/i386/i386/exception.s:169 > > > > > > #7 0xc082c552 in inodedep_find (inodedephd=Variable "inodedephd" > > is > > > > not > > > > > > available. > > > > > > ) > > > > > > at /usr/src/sys/ufs/ffs/ffs_softdep.c:2073 > > > > > > > > > > Please go to frame 7 and do 'x/i $rip'. > > > > > > > > > > > > > (kgdb) up 7 > > > > #7 0xc082c552 in inodedep_find (inodedephd=Variable "inodedephd" is > > not > > > > available. > > > > ) at /usr/src/sys/ufs/ffs/ffs_softdep.c:2073 > > > > 2073/usr/src/sys/ufs/ffs/ffs_softdep.c: No such file or directory. > > > > in /usr/src/sys/ufs/ffs/ffs_softdep.c > > > > (kgdb) x/i $rip > > > > Value can't be converted to integer. > > > > > > Oh, this is i386, use "$eip" instead of "$rip", so 'x/i $eip' at frame 7. > > > > > > (kgdb) x/i $eip > > 0xc082c552 : cmp%ecx,0x24(%eax) > > Ok, so %eax must be 1. I think you probably have failing RAM with a stuck bit > or some such. > Today I've just finished HDD scan with recoverdisk and there were 3 bad sectors. It was stuck on them for a 15 hrs, until it finally did read whole disk, Then I've run it again and it read HDD 100%, without a glitch. I don't know was it a firmware realocated those or those long read attempts fixed a thing. Then reboted into single user and run fsck, which detected a LOT unreferenced inodes at /usr, which it successfully reconected. Finally fsck again to get clean, non error output. Could that caused a panics? PS: I'll run a memtest86+ when I get some time. For how long do you advise? Domagoj ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: UFS related panic (daily <-> find)
On Wednesday, October 02, 2013 5:40:02 pm rank1see...@gmail.com wrote: > > > > > Ok, here is another one, same case, just this time under > 9.1-RELEASE-p7 > > > > > > > > > > == > > > > > Fatal trap 12: page fault while in kernel mode > > > > > fault virtual address = 0x25 > > > > > fault code = supervisor read, page not present > > > > > instruction pointer = 0x20:0xc082c552 > > > > > stack pointer = 0x28:0xe7eed7a8 > > > > > frame pointer = 0x28:0xe7eed7ac > > > > > 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 = 63645 (find) > > > > > trap number = 12 > > > > > panic: page fault > > > > > Uptime: 11h16m47s > > > > > Physical memory: 1014 MB > > > > > Dumping 143 MB: 128 112 96 80 64 48 32 16 > > > > > > > > > > #6 0xc0898d4c in calltrap () at > /usr/src/sys/i386/i386/exception.s:169 > > > > > #7 0xc082c552 in inodedep_find (inodedephd=Variable "inodedephd" > is > > > not > > > > > available. > > > > > ) > > > > > at /usr/src/sys/ufs/ffs/ffs_softdep.c:2073 > > > > > > > > Please go to frame 7 and do 'x/i $rip'. > > > > > > > > > > (kgdb) up 7 > > > #7 0xc082c552 in inodedep_find (inodedephd=Variable "inodedephd" is > not > > > available. > > > ) at /usr/src/sys/ufs/ffs/ffs_softdep.c:2073 > > > 2073/usr/src/sys/ufs/ffs/ffs_softdep.c: No such file or directory. > > > in /usr/src/sys/ufs/ffs/ffs_softdep.c > > > (kgdb) x/i $rip > > > Value can't be converted to integer. > > > > Oh, this is i386, use "$eip" instead of "$rip", so 'x/i $eip' at frame 7. > > > (kgdb) x/i $eip > 0xc082c552 : cmp%ecx,0x24(%eax) Ok, so %eax must be 1. I think you probably have failing RAM with a stuck bit or some such. -- John Baldwin ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: UFS related panic (daily <-> find)
> > > > Ok, here is another one, same case, just this time under 9.1-RELEASE-p7 > > > > > > > > == > > > > Fatal trap 12: page fault while in kernel mode > > > > fault virtual address = 0x25 > > > > fault code = supervisor read, page not present > > > > instruction pointer = 0x20:0xc082c552 > > > > stack pointer = 0x28:0xe7eed7a8 > > > > frame pointer = 0x28:0xe7eed7ac > > > > 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 = 63645 (find) > > > > trap number = 12 > > > > panic: page fault > > > > Uptime: 11h16m47s > > > > Physical memory: 1014 MB > > > > Dumping 143 MB: 128 112 96 80 64 48 32 16 > > > > > > > > #6 0xc0898d4c in calltrap () at /usr/src/sys/i386/i386/exception.s:169 > > > > #7 0xc082c552 in inodedep_find (inodedephd=Variable "inodedephd" is > > not > > > > available. > > > > ) > > > > at /usr/src/sys/ufs/ffs/ffs_softdep.c:2073 > > > > > > Please go to frame 7 and do 'x/i $rip'. > > > > > > > (kgdb) up 7 > > #7 0xc082c552 in inodedep_find (inodedephd=Variable "inodedephd" is not > > available. > > ) at /usr/src/sys/ufs/ffs/ffs_softdep.c:2073 > > 2073/usr/src/sys/ufs/ffs/ffs_softdep.c: No such file or directory. > > in /usr/src/sys/ufs/ffs/ffs_softdep.c > > (kgdb) x/i $rip > > Value can't be converted to integer. > > Oh, this is i386, use "$eip" instead of "$rip", so 'x/i $eip' at frame 7. (kgdb) x/i $eip 0xc082c552 : cmp%ecx,0x24(%eax) ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: UFS related panic (daily <-> find)
On Wednesday, October 02, 2013 4:32:56 pm rank1see...@gmail.com wrote: > > > Ok, here is another one, same case, just this time under 9.1-RELEASE-p7 > > > > > > == > > > Fatal trap 12: page fault while in kernel mode > > > fault virtual address = 0x25 > > > fault code = supervisor read, page not present > > > instruction pointer = 0x20:0xc082c552 > > > stack pointer = 0x28:0xe7eed7a8 > > > frame pointer = 0x28:0xe7eed7ac > > > 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 = 63645 (find) > > > trap number = 12 > > > panic: page fault > > > Uptime: 11h16m47s > > > Physical memory: 1014 MB > > > Dumping 143 MB: 128 112 96 80 64 48 32 16 > > > > > > #6 0xc0898d4c in calltrap () at /usr/src/sys/i386/i386/exception.s:169 > > > #7 0xc082c552 in inodedep_find (inodedephd=Variable "inodedephd" is > not > > > available. > > > ) > > > at /usr/src/sys/ufs/ffs/ffs_softdep.c:2073 > > > > Please go to frame 7 and do 'x/i $rip'. > > > > (kgdb) up 7 > #7 0xc082c552 in inodedep_find (inodedephd=Variable "inodedephd" is not > available. > ) at /usr/src/sys/ufs/ffs/ffs_softdep.c:2073 > 2073/usr/src/sys/ufs/ffs/ffs_softdep.c: No such file or directory. > in /usr/src/sys/ufs/ffs/ffs_softdep.c > (kgdb) x/i $rip > Value can't be converted to integer. Oh, this is i386, use "$eip" instead of "$rip", so 'x/i $eip' at frame 7. -- John Baldwin ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: UFS related panic (daily <-> find)
> > Ok, here is another one, same case, just this time under 9.1-RELEASE-p7 > > > > == > > Fatal trap 12: page fault while in kernel mode > > fault virtual address = 0x25 > > fault code = supervisor read, page not present > > instruction pointer = 0x20:0xc082c552 > > stack pointer = 0x28:0xe7eed7a8 > > frame pointer = 0x28:0xe7eed7ac > > 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 = 63645 (find) > > trap number = 12 > > panic: page fault > > Uptime: 11h16m47s > > Physical memory: 1014 MB > > Dumping 143 MB: 128 112 96 80 64 48 32 16 > > > > #6 0xc0898d4c in calltrap () at /usr/src/sys/i386/i386/exception.s:169 > > #7 0xc082c552 in inodedep_find (inodedephd=Variable "inodedephd" is not > > available. > > ) > > at /usr/src/sys/ufs/ffs/ffs_softdep.c:2073 > > Please go to frame 7 and do 'x/i $rip'. > (kgdb) up 7 #7 0xc082c552 in inodedep_find (inodedephd=Variable "inodedephd" is not available. ) at /usr/src/sys/ufs/ffs/ffs_softdep.c:2073 2073/usr/src/sys/ufs/ffs/ffs_softdep.c: No such file or directory. in /usr/src/sys/ufs/ffs/ffs_softdep.c (kgdb) x/i $rip Value can't be converted to integer. (kgdb) x $rip Value can't be converted to integer. (kgdb) i $rip Undefined info command: "$rip". Try "help info". (kgdb) x 0x0:Cannot access memory at address 0x0 I don't t think I understand 'x/i $rip' part ... Domagoj ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: UFS related panic (daily <-> find)
On Tuesday, October 01, 2013 9:15:33 pm rank1see...@gmail.com wrote: > Ok, here is another one, same case, just this time under 9.1-RELEASE-p7 > > == > Fatal trap 12: page fault while in kernel mode > fault virtual address = 0x25 > fault code = supervisor read, page not present > instruction pointer = 0x20:0xc082c552 > stack pointer = 0x28:0xe7eed7a8 > frame pointer = 0x28:0xe7eed7ac > 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 = 63645 (find) > trap number = 12 > panic: page fault > Uptime: 11h16m47s > Physical memory: 1014 MB > Dumping 143 MB: 128 112 96 80 64 48 32 16 > > #6 0xc0898d4c in calltrap () at /usr/src/sys/i386/i386/exception.s:169 > #7 0xc082c552 in inodedep_find (inodedephd=Variable "inodedephd" is not > available. > ) > at /usr/src/sys/ufs/ffs/ffs_softdep.c:2073 Please go to frame 7 and do 'x/i $rip'. -- John Baldwin ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: UFS related panic (daily <-> find)
Ok, here is another one, same case, just this time under 9.1-RELEASE-p7 == Fatal trap 12: page fault while in kernel mode fault virtual address = 0x25 fault code = supervisor read, page not present instruction pointer = 0x20:0xc082c552 stack pointer = 0x28:0xe7eed7a8 frame pointer = 0x28:0xe7eed7ac 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 = 63645 (find) trap number = 12 panic: page fault Uptime: 11h16m47s Physical memory: 1014 MB Dumping 143 MB: 128 112 96 80 64 48 32 16 No symbol "stopped_cpus" in current context. No symbol "stoppcbs" in current context. Reading symbols from /boot/kernel/nfscl.ko...Reading symbols from /boot/kernel/nfscl.ko.symbols...done. done. Loaded symbols for /boot/kernel/nfscl.ko Reading symbols from /boot/kernel/nfslock.ko...Reading symbols from /boot/kernel/nfslock.ko.symbols...done. done. Loaded symbols for /boot/kernel/nfslock.ko Reading symbols from /boot/kernel/nfssvc.ko...Reading symbols from /boot/kernel/nfssvc.ko.symbols...done. done. Loaded symbols for /boot/kernel/nfssvc.ko Reading symbols from /boot/kernel/krpc.ko...Reading symbols from /boot/kernel/krpc.ko.symbols...done. done. Loaded symbols for /boot/kernel/krpc.ko Reading symbols from /boot/kernel/nfscommon.ko...Reading symbols from /boot/kernel/nfscommon.ko.symbols...done. done. Loaded symbols for /boot/kernel/nfscommon.ko Reading symbols from /boot/kernel/nfsd.ko...Reading symbols from /boot/kernel/nfsd.ko.symbols...done. done. Loaded symbols for /boot/kernel/nfsd.ko Reading symbols from /boot/kernel/nfslockd.ko...Reading symbols from /boot/kernel/nfslockd.ko.symbols...done. done. Loaded symbols for /boot/kernel/nfslockd.ko Reading symbols from /usr/local/modules/fuse.ko...done. Loaded symbols for /usr/local/modules/fuse.ko Reading symbols from /usr/local/lib/oss/modules/osscore.ko...done. Loaded symbols for /usr/local/lib/oss/modules/osscore.ko Reading symbols from /usr/local/lib/oss/modules/oss_audigyls.ko...done. Loaded symbols for /usr/local/lib/oss/modules/oss_audigyls.ko Reading symbols from /boot/kernel/cpuctl.ko...Reading symbols from /boot/kernel/cpuctl.ko.symbols...done. done. Loaded symbols for /boot/kernel/cpuctl.ko #0 doadump (textdump=1) at pcpu.h:244 244 pcpu.h: No such file or directory. in pcpu.h (kgdb) #0 doadump (textdump=1) at pcpu.h:244 #1 0xc06564e9 in kern_reboot (howto=260) at /usr/src/sys/kern/kern_shutdown.c:448 #2 0xc065671f in panic (fmt=Variable "fmt" is not available. ) at /usr/src/sys/kern/kern_shutdown.c:636 #3 0xc08aa97a in trap_fatal (frame=0xe7eed768, eva=37) at /usr/src/sys/i386/i386/trap.c:1018 #4 0xc08aaa64 in trap_pfault (frame=0xe7eed768, usermode=0, eva=37) at /usr/src/sys/i386/i386/trap.c:870 #5 0xc08ab711 in trap (frame=0xe7eed768) at /usr/src/sys/i386/i386/trap.c:545 #6 0xc0898d4c in calltrap () at /usr/src/sys/i386/i386/exception.s:169 #7 0xc082c552 in inodedep_find (inodedephd=Variable "inodedephd" is not available. ) at /usr/src/sys/ufs/ffs/ffs_softdep.c:2073 #8 0xc0830bf0 in inodedep_lookup (mp=0xc47a77bc, inum=2051635, flags=0, inodedeppp=0xe7eed7f8) at /usr/src/sys/ufs/ffs/ffs_softdep.c:2105 #9 0xc0834c39 in softdep_load_inodeblock (ip=0xc6ca7658) at /usr/src/sys/ufs/ffs/ffs_softdep.c:11527 #10 0xc0843893 in ffs_vgetf (mp=0xc47a77bc, ino=2051635, flags=2097152, vpp=0xe7eed8ec, ffs_flags=Variable "ffs_flags" is not available. ) at /usr/src/sys/ufs/ffs/ffs_vfsops.c:1742 #11 0xc08439ae in ffs_vget (mp=0xc47a77bc, ino=2051635, flags=2097152, vpp=0xe7eed8ec) at /usr/src/sys/ufs/ffs/ffs_vfsops.c:1625 #12 0xc084ffc1 in ufs_lookup_ino (vdp=0xc704b990, vpp=0xe7eedae8, cnp=0xe7eedafc, dd_ino=0x0) at /usr/src/sys/ufs/ufs/ufs_lookup.c:749 #13 0xc0850054 in ufs_lookup (ap=0xe7eed954) at /usr/src/sys/ufs/ufs/ufs_lookup.c:214 #14 0xc08c2022 in VOP_CACHEDLOOKUP_APV (vop=0xc0983080, a=0xe7eed954) at vnode_if.c:187 #15 0xc06cb77b in vfs_cache_lookup (ap=0xe7eed9e4) at vnode_if.h:80 #16 0xc08c3f81 in VOP_LOOKUP_APV (vop=0xc0983520, a=0xe7eed9e4) at vnode_if.c:123 #17 0xc06d2e24 in lookup (ndp=0xe7eedabc) at vnode_if.h:54 #18 0xc06d3dd2 in namei (ndp=0xe7eedabc) at /usr/src/sys/kern/vfs_lookup.c:297 #19 0xc06e54e3 in kern_statat_vnhook (td=0xc4fae2e0, flag=512, fd=-100, path=0x28450638 , pathseg=UIO_USERSPACE, sbp=0xe7eedbe8, hook=0) at /usr/src/sys/kern/vfs_syscalls.c:2432 #20 0xc06e562c in kern_statat (td=0xc4fae2e0, flag=512, fd=-100, path=0x28450638 , pathseg=UIO_USERSPACE, sbp=0xe7eedbe8) at /usr/src/sys/kern/vfs_syscalls.c:2413 #21 0xc06e5664 in kern_lstat (td=0xc4fae2e0, path=0x28450638 , pathseg=UIO_USERSPACE, sbp=0xe7eedbe8) at /usr/src/sys/kern/vfs_syscalls.c:2486 #22 0xc06e56f8 in sys_lstat (td=0xc4fae2e
Re: UFS related panic (daily <-> find)
On Friday, July 26, 2013 3:00:33 pm rank1see...@gmail.com wrote:
> > > > > I had 2 panics: (Both occured at 3 AM, so had to be daily task)
> > > > >
> > > > > First (Jul 2 03:06:50 2013):
> > > > > --
> > > > > Fatal trap 12: page fault while in kernel mode
> > > > > fault virtual address = 0x19
> > > > > fault code = supervisor read, page not present
> > > > > instruction pointer = 0x20:0xc06caf34
> > > > > stack pointer = 0x28:0xe76248fc
> > > > > frame pointer = 0x28:0xe7624930
> > > > > 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 = 76562 (find)
> > > > > trap number = 12
> > > > > panic: page fault
> > > > > Uptime: 23h0m41s
> > > > > Physical memory: 1014 MB
> > > > > Dumping 186 MB: 171 155 139 123 107 91 75 59 43 27 11
> > > > >
> > > > > #7 0xc06caf34 in cache_lookup_times (dvp=0xc784a990,
> vpp=0xe7624ae8,
> > > > > cnp=0xe7624afc, tsp=0x0, ticksp=0x0) at
> > > > /usr/src/sys/kern/vfs_cache.c:547
> > > >
> > > > Can you go up to this frame and do 'l'?
> > > >
> > > > --
> > > > John Baldwin
> > >
> > >
> > > Sure,
> > >
> > > -
> > > (kgdb) up 7
> > > #7 0xc06caf34 in cache_lookup_times (dvp=0xc784a990, vpp=0xe7624ae8,
> cnp=0xe7624afc, tsp=0x0, ticksp=0x0) at /usr/src/sys/kern/vfs_cache.c:547
> > > 547 numchecks++;
> > > -
> > > (kgdb) l
> > > 542 }
> > > 543
> > > 544 hash = fnv_32_buf(cnp->cn_nameptr, cnp->cn_namelen,
> FNV1_32_INIT);
> > > 545 hash = fnv_32_buf(&dvp, sizeof(dvp), hash);
> > > 546 LIST_FOREACH(ncp, (NCHHASH(hash)), nc_hash) {
> > > 547 numchecks++;
> > > 548 if (ncp->nc_dvp == dvp && ncp->nc_nlen ==
> cnp->cn_namelen &&
> > > 549 !bcmp(nc_get_name(ncp), cnp->cn_nameptr,
> ncp->nc_nlen))
> > > 550 break;
> > > 551 }
> > > -
> >
> > Hmm, 'p ncp' and 'p *ncp' at that frame perhaps?
> >
>
> (kgdb) p ncp
> $1 = (struct namecache *) 0x1
> (kgdb) p *ncp
> Cannot access memory at address 0x1
Interesting. Maybe look at NCHHASH(hash) (you'll have to expand the macro
manually)
and see if the head node is corrupted or walk the list to find the corrupted
node.
Given that it is a single bit error, there is a chance this is a RAM problem.
If it
is in the hash table head entry then that would always be at the same physical
address
for the same kernel I think.
--
John Baldwin
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: UFS related panic (daily <-> find)
> > > > I had 2 panics: (Both occured at 3 AM, so had to be daily task)
> > > >
> > > > First (Jul 2 03:06:50 2013):
> > > > --
> > > > Fatal trap 12: page fault while in kernel mode
> > > > fault virtual address = 0x19
> > > > fault code = supervisor read, page not present
> > > > instruction pointer = 0x20:0xc06caf34
> > > > stack pointer = 0x28:0xe76248fc
> > > > frame pointer = 0x28:0xe7624930
> > > > 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 = 76562 (find)
> > > > trap number = 12
> > > > panic: page fault
> > > > Uptime: 23h0m41s
> > > > Physical memory: 1014 MB
> > > > Dumping 186 MB: 171 155 139 123 107 91 75 59 43 27 11
> > > >
> > > > #7 0xc06caf34 in cache_lookup_times (dvp=0xc784a990,
vpp=0xe7624ae8,
> > > > cnp=0xe7624afc, tsp=0x0, ticksp=0x0) at
> > > /usr/src/sys/kern/vfs_cache.c:547
> > >
> > > Can you go up to this frame and do 'l'?
> > >
> > > --
> > > John Baldwin
> >
> >
> > Sure,
> >
> > -
> > (kgdb) up 7
> > #7 0xc06caf34 in cache_lookup_times (dvp=0xc784a990, vpp=0xe7624ae8,
cnp=0xe7624afc, tsp=0x0, ticksp=0x0) at /usr/src/sys/kern/vfs_cache.c:547
> > 547 numchecks++;
> > -
> > (kgdb) l
> > 542 }
> > 543
> > 544 hash = fnv_32_buf(cnp->cn_nameptr, cnp->cn_namelen,
FNV1_32_INIT);
> > 545 hash = fnv_32_buf(&dvp, sizeof(dvp), hash);
> > 546 LIST_FOREACH(ncp, (NCHHASH(hash)), nc_hash) {
> > 547 numchecks++;
> > 548 if (ncp->nc_dvp == dvp && ncp->nc_nlen ==
cnp->cn_namelen &&
> > 549 !bcmp(nc_get_name(ncp), cnp->cn_nameptr,
ncp->nc_nlen))
> > 550 break;
> > 551 }
> > -
>
> Hmm, 'p ncp' and 'p *ncp' at that frame perhaps?
>
(kgdb) p ncp
$1 = (struct namecache *) 0x1
(kgdb) p *ncp
Cannot access memory at address 0x1
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: UFS related panic (daily <-> find)
On Friday, July 26, 2013 9:04:42 am rank1see...@gmail.com wrote:
> > > I had 2 panics: (Both occured at 3 AM, so had to be daily task)
> > >
> > > First (Jul 2 03:06:50 2013):
> > > --
> > > Fatal trap 12: page fault while in kernel mode
> > > fault virtual address = 0x19
> > > fault code = supervisor read, page not present
> > > instruction pointer = 0x20:0xc06caf34
> > > stack pointer = 0x28:0xe76248fc
> > > frame pointer = 0x28:0xe7624930
> > > 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 = 76562 (find)
> > > trap number = 12
> > > panic: page fault
> > > Uptime: 23h0m41s
> > > Physical memory: 1014 MB
> > > Dumping 186 MB: 171 155 139 123 107 91 75 59 43 27 11
> > >
> > > #7 0xc06caf34 in cache_lookup_times (dvp=0xc784a990, vpp=0xe7624ae8,
> > > cnp=0xe7624afc, tsp=0x0, ticksp=0x0) at
> > /usr/src/sys/kern/vfs_cache.c:547
> >
> > Can you go up to this frame and do 'l'?
> >
> > --
> > John Baldwin
>
>
> Sure,
>
> -
> (kgdb) up 7
> #7 0xc06caf34 in cache_lookup_times (dvp=0xc784a990, vpp=0xe7624ae8,
> cnp=0xe7624afc, tsp=0x0, ticksp=0x0) at /usr/src/sys/kern/vfs_cache.c:547
> 547 numchecks++;
> -
> (kgdb) l
> 542 }
> 543
> 544 hash = fnv_32_buf(cnp->cn_nameptr, cnp->cn_namelen,
> FNV1_32_INIT);
> 545 hash = fnv_32_buf(&dvp, sizeof(dvp), hash);
> 546 LIST_FOREACH(ncp, (NCHHASH(hash)), nc_hash) {
> 547 numchecks++;
> 548 if (ncp->nc_dvp == dvp && ncp->nc_nlen ==
> cnp->cn_namelen &&
> 549 !bcmp(nc_get_name(ncp), cnp->cn_nameptr,
> ncp->nc_nlen))
> 550 break;
> 551 }
> -
Hmm, 'p ncp' and 'p *ncp' at that frame perhaps?
--
John Baldwin
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: UFS related panic (daily <-> find)
> > I had 2 panics: (Both occured at 3 AM, so had to be daily task)
> >
> > First (Jul 2 03:06:50 2013):
> > --
> > Fatal trap 12: page fault while in kernel mode
> > fault virtual address = 0x19
> > fault code = supervisor read, page not present
> > instruction pointer = 0x20:0xc06caf34
> > stack pointer = 0x28:0xe76248fc
> > frame pointer = 0x28:0xe7624930
> > 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 = 76562 (find)
> > trap number = 12
> > panic: page fault
> > Uptime: 23h0m41s
> > Physical memory: 1014 MB
> > Dumping 186 MB: 171 155 139 123 107 91 75 59 43 27 11
> >
> > #7 0xc06caf34 in cache_lookup_times (dvp=0xc784a990, vpp=0xe7624ae8,
> > cnp=0xe7624afc, tsp=0x0, ticksp=0x0) at
> /usr/src/sys/kern/vfs_cache.c:547
>
> Can you go up to this frame and do 'l'?
>
> --
> John Baldwin
Sure,
-
(kgdb) up 7
#7 0xc06caf34 in cache_lookup_times (dvp=0xc784a990, vpp=0xe7624ae8,
cnp=0xe7624afc, tsp=0x0, ticksp=0x0) at /usr/src/sys/kern/vfs_cache.c:547
547 numchecks++;
-
(kgdb) l
542 }
543
544 hash = fnv_32_buf(cnp->cn_nameptr, cnp->cn_namelen,
FNV1_32_INIT);
545 hash = fnv_32_buf(&dvp, sizeof(dvp), hash);
546 LIST_FOREACH(ncp, (NCHHASH(hash)), nc_hash) {
547 numchecks++;
548 if (ncp->nc_dvp == dvp && ncp->nc_nlen ==
cnp->cn_namelen &&
549 !bcmp(nc_get_name(ncp), cnp->cn_nameptr,
ncp->nc_nlen))
550 break;
551 }
-
Domagoj Smolčić
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: UFS related panic (daily <-> find)
On Friday, July 19, 2013 1:45:11 pm rank1see...@gmail.com wrote: > I had 2 panics: (Both occured at 3 AM, so had to be daily task) > > First (Jul 2 03:06:50 2013): > -- > Fatal trap 12: page fault while in kernel mode > fault virtual address = 0x19 > fault code = supervisor read, page not present > instruction pointer = 0x20:0xc06caf34 > stack pointer = 0x28:0xe76248fc > frame pointer = 0x28:0xe7624930 > 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 = 76562 (find) > trap number = 12 > panic: page fault > Uptime: 23h0m41s > Physical memory: 1014 MB > Dumping 186 MB: 171 155 139 123 107 91 75 59 43 27 11 > > #7 0xc06caf34 in cache_lookup_times (dvp=0xc784a990, vpp=0xe7624ae8, > cnp=0xe7624afc, tsp=0x0, ticksp=0x0) at /usr/src/sys/kern/vfs_cache.c:547 Can you go up to this frame and do 'l'? -- John Baldwin ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
UFS related panic (daily <-> find)
I had 2 panics: (Both occured at 3 AM, so had to be daily task) First (Jul 2 03:06:50 2013): -- Fatal trap 12: page fault while in kernel mode fault virtual address = 0x19 fault code = supervisor read, page not present instruction pointer = 0x20:0xc06caf34 stack pointer = 0x28:0xe76248fc frame pointer = 0x28:0xe7624930 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 = 76562 (find) trap number = 12 panic: page fault Uptime: 23h0m41s Physical memory: 1014 MB Dumping 186 MB: 171 155 139 123 107 91 75 59 43 27 11 No symbol "stopped_cpus" in current context. No symbol "stoppcbs" in current context. Reading symbols from /boot/kernel/nfscl.ko...Reading symbols from /boot/kernel/nfscl.ko.symbols...done. done. Loaded symbols for /boot/kernel/nfscl.ko Reading symbols from /boot/kernel/nfslock.ko...Reading symbols from /boot/kernel/nfslock.ko.symbols...done. done. Loaded symbols for /boot/kernel/nfslock.ko Reading symbols from /boot/kernel/nfssvc.ko...Reading symbols from /boot/kernel/nfssvc.ko.symbols...done. done. Loaded symbols for /boot/kernel/nfssvc.ko Reading symbols from /boot/kernel/krpc.ko...Reading symbols from /boot/kernel/krpc.ko.symbols...done. done. Loaded symbols for /boot/kernel/krpc.ko Reading symbols from /boot/kernel/nfscommon.ko...Reading symbols from /boot/kernel/nfscommon.ko.symbols...done. done. Loaded symbols for /boot/kernel/nfscommon.ko Reading symbols from /boot/kernel/nfsd.ko...Reading symbols from /boot/kernel/nfsd.ko.symbols...done. done. Loaded symbols for /boot/kernel/nfsd.ko Reading symbols from /boot/kernel/nfslockd.ko...Reading symbols from /boot/kernel/nfslockd.ko.symbols...done. done. Loaded symbols for /boot/kernel/nfslockd.ko Reading symbols from /usr/local/modules/fuse.ko...done. Loaded symbols for /usr/local/modules/fuse.ko Reading symbols from /usr/local/lib/oss/modules/osscore.ko...done. Loaded symbols for /usr/local/lib/oss/modules/osscore.ko Reading symbols from /usr/local/lib/oss/modules/oss_audigyls.ko...done. Loaded symbols for /usr/local/lib/oss/modules/oss_audigyls.ko Reading symbols from /boot/kernel/cpuctl.ko...Reading symbols from /boot/kernel/cpuctl.ko.symbols...done. done. Loaded symbols for /boot/kernel/cpuctl.ko Reading symbols from /boot/kernel/nullfs.ko...Reading symbols from /boot/kernel/nullfs.ko.symbols...done. done. Loaded symbols for /boot/kernel/nullfs.ko Reading symbols from /boot/kernel/if_urtw.ko...Reading symbols from /boot/kernel/if_urtw.ko.symbols...done. done. Loaded symbols for /boot/kernel/if_urtw.ko #0 doadump (textdump=1) at pcpu.h:244 244 pcpu.h: No such file or directory. in pcpu.h (kgdb) #0 doadump (textdump=1) at pcpu.h:244 #1 0xc06564e9 in kern_reboot (howto=260) at /usr/src/sys/kern/kern_shutdown.c:448 #2 0xc065671f in panic (fmt=Variable "fmt" is not available. ) at /usr/src/sys/kern/kern_shutdown.c:636 #3 0xc08aa88a in trap_fatal (frame=0xe76248bc, eva=25) at /usr/src/sys/i386/i386/trap.c:1018 #4 0xc08aa974 in trap_pfault (frame=0xe76248bc, usermode=0, eva=25) at /usr/src/sys/i386/i386/trap.c:870 #5 0xc08ab621 in trap (frame=0xe76248bc) at /usr/src/sys/i386/i386/trap.c:545 #6 0xc0898c5c in calltrap () at /usr/src/sys/i386/i386/exception.s:169 #7 0xc06caf34 in cache_lookup_times (dvp=0xc784a990, vpp=0xe7624ae8, cnp=0xe7624afc, tsp=0x0, ticksp=0x0) at /usr/src/sys/kern/vfs_cache.c:547 #8 0xc06cb752 in vfs_cache_lookup (ap=0xe76249e4) at /usr/src/sys/kern/vfs_cache.c:1032 #9 0xc08c3e91 in VOP_LOOKUP_APV (vop=0xc0983520, a=0xe76249e4) at vnode_if.c:123 #10 0xc06d2e24 in lookup (ndp=0xe7624abc) at vnode_if.h:54 #11 0xc06d3dd2 in namei (ndp=0xe7624abc) at /usr/src/sys/kern/vfs_lookup.c:297 #12 0xc06e54e3 in kern_statat_vnhook (td=0xc47e35c0, flag=512, fd=-100, path=0x284f3cb8 , pathseg=UIO_USERSPACE, sbp=0xe7624be8, hook=0) at /usr/src/sys/kern/vfs_syscalls.c:2432 #13 0xc06e562c in kern_statat (td=0xc47e35c0, flag=512, fd=-100, path=0x284f3cb8 , pathseg=UIO_USERSPACE, sbp=0xe7624be8) at /usr/src/sys/kern/vfs_syscalls.c:2413 #14 0xc06e5664 in kern_lstat (td=0xc47e35c0, path=0x284f3cb8 , pathseg=UIO_USERSPACE, sbp=0xe7624be8) at /usr/src/sys/kern/vfs_syscalls.c:2486 #15 0xc06e56f8 in sys_lstat (td=0xc47e35c0, uap=0xe7624ccc) at /usr/src/sys/kern/vfs_syscalls.c:2476 #16 0xc08aae52 in syscall (frame=0xe7624d08) at subr_syscall.c:135 #17 0xc0898cc1 in Xint0x80_syscall () at /usr/src/sys/i386/i386/exception.s:267 #18 0x0033 in ?? () Previous frame inner to this frame (corrupt stack?) (kgdb) Second (Jul 18 03:06:38 2013): -- Fatal trap 12: page fault while in kernel mode fault virtual address = 0x19 fault code = supervisor read, page not present instruction pointer = 0x20:0xc06caf34 stack pointer = 0x28:0xe7
