Re: Page fault on disk-less machine
Terry Lambert wrote: Scott Long wrote: Guys, this problem has already been identified. I posted a patch last night to cvs-all@ that fixes this, although it's still not totally correct so I haven't committed it yet. This one, I imagine. Thanks! http://docs.freebsd.org/cgi/getmsg.cgi?fetch=1225336+0+current/cvs-all It wasn't clear that this was the same problem, with the other recent potentially destabilizing commits. I guess PHK, Lars, and Craig should try applying this, and seeing if it fixes things for them... Tried it, and it does not fix the panic for me. There must be another problem. Lars -- Lars Eggert [EMAIL PROTECTED] USC Information Sciences Institute smime.p7s Description: S/MIME Cryptographic Signature
Page fault on disk-less machine
Fatal trap 12: page fault while in kernel mode fault virtual address = 0x34 fault code = supervisor read, page not present instruction pointer = 0x8:0xc018fd20 stack pointer = 0x10:0xc5fd27a4 frame pointer = 0x10:0xc5fd27c0 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 = 414 (cron) kernel: type 12 trap, code=0 Stopped at 0xc018fd20 = _mtx_lock_flags+0x40: cmpl$0xc02c1160,0(%ecx) db trace _mtx_lock_flags(34,0,c02a5f56,9e,c0d9e1e0) at 0xc018fd20 = _mtx_lock_flags+0x40 namei(c5fd29b8,c5fd2c34,c044,c0570d00,c0d9e1e0) at 0xc01de06d = namei+0x16d vn_open_cred(c5fd29b8,c5fd2980,0,c0554e00,c02167cf) at 0xc01efce8 = vn_open_cred+0x258 nfs_dolock(c5fd2b98,758,c0e066a8,c0db3e10,c0e066a8) at 0xc02230f5 = nfs_dolock+0x2c5 nfs_advlock(c5fd2b98,0,c029ee60,761,c02b6800) at 0xc0222578 = nfs_advlock+0x58 fdrop_locked(c0db3e10,c0d9e1e0,c029ee60,69e,6002) at 0xc017fa28 = fdrop_locked+0x138 fdrop(c0db3e10,c0d9e1e0,c018fe06,c03b3e58,6002) at 0xc017f50e = fdrop+0x3e closef(c0db3e10,c0d9e1e0,c029ee60,595,0) at 0xc017f4bc = closef+0x12c fdfree(c0d9e1e0,0,c029f2f4,f2,1) at 0xc017ed46 = fdfree+0x116 exit1(c0d9e1e0,100,c029f2f4,73,c5fd2d40) at 0xc0184bc7 = exit1+0x3b7 sys_exit(c0d9e1e0,c5fd2d10,c02b0451,407,1) at 0xc0184801 = sys_exit+0x41 syscall(2f,2f,2f,0,) at 0xc027dc07 = syscall+0x257 Xint0x80_syscall() at 0xc026dabd = Xint0x80_syscall+0x1d --- syscall (1, FreeBSD ELF32, sys_exit), eip = 0x280c36bf, esp = 0xbfbffbec, ebp = 0xbfbffc08 --- db -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 [EMAIL PROTECTED] | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Page fault on disk-less machine
Poul-Henning Kamp wrote: Fatal trap 12: page fault while in kernel mode FWIW, Craig Boston and me see the same panics (threads on -current: panic starting gnome and VFS panic (possibly NFS-locking related?)). fault virtual address = 0x34 fault code = supervisor read, page not present instruction pointer = 0x8:0xc018fd20 stack pointer = 0x10:0xc5fd27a4 frame pointer = 0x10:0xc5fd27c0 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 = 414 (cron) kernel: type 12 trap, code=0 Stopped at 0xc018fd20 = _mtx_lock_flags+0x40: cmpl$0xc02c1160,0(%ecx) db trace _mtx_lock_flags(34,0,c02a5f56,9e,c0d9e1e0) at 0xc018fd20 = _mtx_lock_flags+0x40 namei(c5fd29b8,c5fd2c34,c044,c0570d00,c0d9e1e0) at 0xc01de06d = namei+0x16d vn_open_cred(c5fd29b8,c5fd2980,0,c0554e00,c02167cf) at 0xc01efce8 = vn_open_cred+0x258 nfs_dolock(c5fd2b98,758,c0e066a8,c0db3e10,c0e066a8) at 0xc02230f5 = nfs_dolock+0x2c5 nfs_advlock(c5fd2b98,0,c029ee60,761,c02b6800) at 0xc0222578 = nfs_advlock+0x58 fdrop_locked(c0db3e10,c0d9e1e0,c029ee60,69e,6002) at 0xc017fa28 = fdrop_locked+0x138 fdrop(c0db3e10,c0d9e1e0,c018fe06,c03b3e58,6002) at 0xc017f50e = fdrop+0x3e closef(c0db3e10,c0d9e1e0,c029ee60,595,0) at 0xc017f4bc = closef+0x12c fdfree(c0d9e1e0,0,c029f2f4,f2,1) at 0xc017ed46 = fdfree+0x116 exit1(c0d9e1e0,100,c029f2f4,73,c5fd2d40) at 0xc0184bc7 = exit1+0x3b7 sys_exit(c0d9e1e0,c5fd2d10,c02b0451,407,1) at 0xc0184801 = sys_exit+0x41 syscall(2f,2f,2f,0,) at 0xc027dc07 = syscall+0x257 Xint0x80_syscall() at 0xc026dabd = Xint0x80_syscall+0x1d --- syscall (1, FreeBSD ELF32, sys_exit), eip = 0x280c36bf, esp = 0xbfbffbec, ebp = 0xbfbffc08 --- db Lars -- Lars Eggert [EMAIL PROTECTED] USC Information Sciences Institute smime.p7s Description: S/MIME Cryptographic Signature
Re: Page fault on disk-less machine
On Wed, 2003-02-19 at 15:12, Lars Eggert wrote: Poul-Henning Kamp wrote: Fatal trap 12: page fault while in kernel mode FWIW, Craig Boston and me see the same panics (threads on -current: panic starting gnome and VFS panic (possibly NFS-locking related?)). When I get home tonight I'll try staticly compiling in the NFS client code and see if I can get a better crash dump to work with. I'm not too familiar with this part of the source tree, so no guarantees about my debugging skills ;) Craig To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Page fault on disk-less machine
Poul-Henning Kamp wrote: Fatal trap 12: page fault while in kernel mode fault virtual address = 0x34 This is the same problem that the other people were complaining about the other day. It's interesting to note the third argument to namei() is not zero in your case. _mtx_lock_flags(34,0,c02a5f56,9e,c0d9e1e0) at 0xc018fd20 = _mtx_lock_flags+0x40 namei(c5fd29b8,c5fd2c34,c044,c0570d00,c0d9e1e0) at 0xc01de06d = namei+0x16d Any chance of a gdb -k and a list namei+0x16d? -- Terry To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Page fault on disk-less machine
Lars Eggert wrote: Poul-Henning Kamp wrote: Fatal trap 12: page fault while in kernel mode FWIW, Craig Boston and me see the same panics (threads on -current: panic starting gnome and VFS panic (possibly NFS-locking related?)). Have you gdb -k list'ed the namei code in question yet? Per my last posting on this subject, note that Poul's offset into namei is different than the one you gave. If you could both provide this information, it would probably triangulate the problem immediately. Thanks, -- Terry To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Page fault on disk-less machine
On Wed, 2003-02-19 at 21:48, Terry Lambert wrote: Lars Eggert wrote: Poul-Henning Kamp wrote: Fatal trap 12: page fault while in kernel mode FWIW, Craig Boston and me see the same panics (threads on -current: panic starting gnome and VFS panic (possibly NFS-locking related?)). Have you gdb -k list'ed the namei code in question yet? Per my last posting on this subject, note that Poul's offset into namei is different than the one you gave. Mine is different as well: 0x12c, and on a cmpxchgl instruction (I know that doesn't help any ;) But: (kgdb) list namei+0x12c Junk at end of line specification. (kgdb) Am I doing something wrong? Craig To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Page fault on disk-less machine
Guys, this problem has already been identified. I posted a patch last night to cvs-all@ that fixes this, although it's still not totally correct so I haven't committed it yet. Scott Craig Boston wrote: On Wed, 2003-02-19 at 21:48, Terry Lambert wrote: Lars Eggert wrote: Poul-Henning Kamp wrote: Fatal trap 12: page fault while in kernel mode FWIW, Craig Boston and me see the same panics (threads on -current: panic starting gnome and VFS panic (possibly NFS-locking related?)). Have you gdb -k list'ed the namei code in question yet? Per my last posting on this subject, note that Poul's offset into namei is different than the one you gave. Mine is different as well: 0x12c, and on a cmpxchgl instruction (I know that doesn't help any ;) But: (kgdb) list namei+0x12c Junk at end of line specification. (kgdb) Am I doing something wrong? Craig To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Page fault on disk-less machine
Craig Boston wrote: On Wed, 2003-02-19 at 21:48, Terry Lambert wrote: Lars Eggert wrote: Poul-Henning Kamp wrote: Fatal trap 12: page fault while in kernel mode FWIW, Craig Boston and me see the same panics (threads on -current: panic starting gnome and VFS panic (possibly NFS-locking related?)). Have you gdb -k list'ed the namei code in question yet? Per my last posting on this subject, note that Poul's offset into namei is different than the one you gave. Mine is different as well: 0x12c, and on a cmpxchgl instruction (I know that doesn't help any ;) But: (kgdb) list namei+0x12c Junk at end of line specification. (kgdb) Am I doing something wrong? My bad: list *namei+0x12c Note the asterisk to dereference before the add. -- Terry To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Page fault on disk-less machine
Scott Long wrote: Guys, this problem has already been identified. I posted a patch last night to cvs-all@ that fixes this, although it's still not totally correct so I haven't committed it yet. This one, I imagine. Thanks! http://docs.freebsd.org/cgi/getmsg.cgi?fetch=1225336+0+current/cvs-all It wasn't clear that this was the same problem, with the other recent potentially destabilizing commits. I guess PHK, Lars, and Craig should try applying this, and seeing if it fixes things for them... -- Terry To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Page fault on disk-less machine
On 2/19/2003 8:23 PM, Scott Long wrote: Guys, this problem has already been identified. I posted a patch last night to cvs-all@ that fixes this, although it's still not totally correct so I haven't committed it yet. Great, thanks! Though it might have been a good idea to CC current@ - I'd have seen it there. (I filter cvs-all@ for pieces of the tree I'm interested in, and your mail must have been nuked.) Lars -- Lars Eggert [EMAIL PROTECTED] USC Information Sciences Institute smime.p7s Description: S/MIME Cryptographic Signature
