Date: Fri, 15 Mar 2002 15:55:38 -0800 (PST) From: Holt Grendal <holtor@yahoo.com> To: "Jan L. Peterson" <jlp@softhome.net> Cc: stable@freebsd.org Subject: Re: Further Page Fault Details Message-ID: <20020315235538.92601.qmail@web11608.mail.yahoo.com> In-Reply-To: <20020315234655.0A74C422E2@mail.flipdog.com>
next in thread | previous in thread | raw e-mail | index | archive | help
Nope.. I've got an fxp in the box, no NFS at all. I've got softupdates enabled
and i've tried disabling them and crashes continued.
I have been unable to get a core file from the system after compiling
the debug kernel and enabling the proper things in /etc/rc.conf.
Nothing ever dumped for me.
Holt
--- "Jan L. Peterson" <jlp@softhome.net> wrote:
> By chance, do you have an xl ethernet adapter in that box? Can you
> send a dmesg and debugger trace? Also, are you doing heavy NFS on that
> box? Do you have softupdates enabled? These are all problems that
> have been seen/mentioned on the list lately.
>
> My own system is crashing again. It only happens on heavy NFS usage.
> I've been going the rounds with this box for several weeks, have
> swapped entire machines (it's a laptop) as well as RAM and hard drive.
> I have a kernel.debug and vmcore.0 file from the most recent crash.
>
> gdb says:
>
> Fatal trap 12: page fault while in kernel mode
> fault virtual address = 0xc0f8222e
> fault code = supervisor write, page not present
> instruction pointer = 0x8:0xc0205a7b
> stack pointer = 0x10:0xce1e1b04
> frame pointer = 0x10:0xce1e1b18
> code segment = base 0x0, limit 0xfffff, type 0x1b
> = DPL 0, pres 1, def32 1, gran 1
> processor eflags = interrupt enabled, resume, IOPL = 0
> current process = 13452 (ld)
> interrupt mask = net tty
>
> (I'm leaving off the traceback stuff that's in the kernel debugger if
> you're wondering why the trace starts at frame 11.)
>
> (kgdb) where
> [...]
> #11 0xc0205a7b in nfs_realign (pm=0xc0e90800, hsiz=20)
> at ../../nfs/nfs_socket.c:1733
> #12 0xc0203dbd in nfs_receive (rep=0xc18c0380, aname=0xce1e1ba0, mp=0xce1e1ba4)
> at ../../nfs/nfs_socket.c:746
> #13 0xc0203e0d in nfs_reply (myrep=0xc18c0380) at ../../nfs/nfs_socket.c:792
> #14 0xc0204502 in nfs_request (vp=0xcdfc8600, mrest=0xc0e49200, procnum=7,
> procp=0xce082080, cred=0xc18cb900, mrp=0xce1e1c94, mdp=0xce1e1c98,
> dposp=0xce1e1c9c) at ../../nfs/nfs_socket.c:1080
> #15 0xc02123f9 in nfs_writerpc (vp=0xcdfc8600, uiop=0xce1e1d00,
> cred=0xc18cb900, iomode=0xce1e1cf0, must_commit=0xce1e1cec)
> at ../../nfs/nfs_vnops.c:1197
> #16 0xc01eb7d0 in nfs_doio (bp=0xc68f5e58, cr=0xc18cb900, p=0xce082080)
> at ../../nfs/nfs_bio.c:1530
> #17 0xc021e3c0 in nfs_strategy (ap=0xce1e1d60) at ../../nfs/nfs_vnops.c:2752
> #18 0xc021ecf4 in nfs_writebp (bp=0xc68f5e58, force=1, procp=0xce082080)
> at vnode_if.h:944
> #19 0xc021ec16 in nfs_bwrite (ap=0xce1e1dd8) at ../../nfs/nfs_vnops.c:3117
> #20 0xc01eacc4 in nfs_write (ap=0xce1e1e64) at vnode_if.h:1193
> #21 0xc01a0cea in vn_write (fp=0xc18c0140, uio=0xce1e1ed4, cred=0xc18cb900,
> flags=0, p=0xce082080) at vnode_if.h:363
> #22 0xc017b5f1 in dofilewrite (p=0xce082080, fp=0xc18c0140, fd=7,
> buf=0x80c4200, nbyte=20, offset=-1, flags=0) at ../../sys/file.h:162
> #23 0xc017b4aa in write (p=0xce082080, uap=0xce1e1f80)
> at ../../kern/sys_generic.c:329
> #24 0xc02be441 in syscall2 (frame={tf_fs = 47, tf_es = 47, tf_ds = 47,
> tf_edi = 134984096, tf_esi = 135021056, tf_ebp = -1077940628,
> tf_isp = -836886572, tf_ebx = 134984096, tf_edx = 134984096,
> tf_ecx = 134984096, tf_eax = 4, tf_trapno = 7, tf_err = 2,
> tf_eip = 134815572, tf_cs = 31, tf_eflags = 663, tf_esp = -1077940672,
> tf_ss = 47}) at ../../i386/i386/trap.c:1167
> #25 0xc02af515 in Xint0x80_syscall ()
>
> (kgdb) up 11
> #11 0xc0205a7b in nfs_realign (pm=0xc0e90800, hsiz=20)
> at ../../nfs/nfs_socket.c:1733
> 1733 MCLGET(n, M_WAIT);
>
> (kgdb) list
> 1728
> 1729 while ((m = *pm) != NULL) {
> 1730 if ((m->m_len & 0x3) || (mtod(m, intptr_t) & 0x3)) {
> 1731 MGET(n, M_WAIT, MT_DATA);
> 1732 if (m->m_len >= MINCLSIZE) {
> 1733 MCLGET(n, M_WAIT);
> 1734 }
> 1735 n->m_len = 0;
> 1736 break;
> 1737 }
>
> (kgdb) p *n
> $1 = {m_hdr = {mh_next = 0x0, mh_nextpkt = 0x0,
> mh_data = 0xc0e94114 "\020\002\b\001\nE\002\024", mh_len = 16,
> mh_type = 1, mh_flags = 0}, M_dat = {MH = {MH_pkthdr = {rcvif = 0x1080210,
> len = 335693066, header = 0x0, csum_flags = 0, csum_data = 335693066,
> aux = 0x5002450a}, MH_dat = {MH_ext = {
> ext_buf = 0x3194635 <Address 0x3194635 out of bounds>, ext_free = 0,
> ext_size = 33554432, ext_ref = 0xa3860100},
> [... ton of other hud removed ...]
>
> notice that ext_buf "Address out of bounds" up there? I'd bet a nickle
> that's the problem. Now what is causing that bad buffer to get on the
> list I don't know. Any ideas from kernel developers? Anyone want more
> info out of this vmcore?
>
> -jan-
> --
> Jan L. Peterson
> <jlp@softhome.net>
>
>
__________________________________________________
Do You Yahoo!?
Yahoo! Sports - live college hoops coverage
http://sports.yahoo.com/
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-stable" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20020315235538.92601.qmail>