Skip site navigation (1)Skip section navigation (2)
Date:      Sat, 19 Apr 1997 00:30:01 -0700 (PDT)
From:      David Greenman <dg@root.com>
To:        freebsd-bugs
Subject:   Re: kern/3329: Panic when using tcpdump on fxp device 
Message-ID:  <199704190730.AAA00313@freefall.freebsd.org>

next in thread | raw e-mail | index | archive | help
The following reply was made to PR kern/3329; it has been noted by GNATS.

From: David Greenman <dg@root.com>
To: tege@nada.kth.se
Cc: FreeBSD-gnats-submit@freebsd.org
Subject: Re: kern/3329: Panic when using tcpdump on fxp device 
Date: Sat, 19 Apr 1997 00:23:38 -0700

 >A `cp foo bar' command issued at the NFS client where both foo and bar lives
 >at the same NFS server triggers an immediate panic in the NFS server when a
 >tcpdump of the fxp device is running on the server.
 >
 >The NFS server panics with:
 >
 >        Fatal trap 12: page fault while in kernel mode
 >        fault virtual address   = 0x37353a40
 >        fault code              = supervisor read, page not present
 >        instruction pointer     = 0x8:0xf013e3dd
 >        stack pointer           = 0x10:0xf01e7ec4
 >        frame pointer           = 0x10:0xf01e7ecc
 >        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         = Idle
 >        interrupt mask          = not tty
 >        panic: page fault
 >
 >Running gdb on the kernel reveals that the crash happens in bpf_filter.c:
 >
 >        0xf013e3dd <m_xhalf+49>:        movw   (%ebx),%ax
 >
 >Both machines were rebooted immediately prior to this crash.  (BPF was
 >enabled in order to track down a hang in the client when using the fxp
 >devices for the NFS traffic.  The problem described in this report inhibited
 >my investigation of the hang--I will resume it if the BPF problem is
 >resolved.  I might also try doing the tcpdump on the client and see if it
 >panics like the server or if it merely hangs.)
 
    I'm not able to reproduce either the hang or panic problems here. I just
 did a code review of the fxp driver's handling of the bpf_tap call and there's
 nothing wrong with it. In short, I'm at a complete loss to explain the problem
 you're having. A complete traceback with function arguments might be useful.
 
 -DG
 
 David Greenman
 Core-team/Principal Architect, The FreeBSD Project



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199704190730.AAA00313>