Date: Sat, 19 Apr 1997 07:06:35 +0200 (CEST) From: Torbjorn Granlund <tege@gmp.tmg.se> To: FreeBSD-gnats-submit@freebsd.org Subject: kern/3329: Panic when using tcpdump on fxp device Message-ID: <199704190506.HAA03203@gmp.tmg.se> Resent-Message-ID: <199704190510.WAA26397@freefall.freebsd.org>
next in thread | raw e-mail | index | archive | help
>Number: 3329
>Category: kern
>Synopsis: Panic when using tcpdump on fxp device
>Confidential: no
>Severity: serious
>Priority: high
>Responsible: freebsd-bugs
>State: open
>Class: sw-bug
>Submitter-Id: current-users
>Arrival-Date: Fri Apr 18 22:10:01 PDT 1997
>Last-Modified:
>Originator: Torbjorn Granlund
>Organization:
TMG Datakonsult
>Release: FreeBSD 2.2.1-RELEASE i386
>Environment:
NFS server:
CPU: P6 200MHz
Main memory: 128MB FPM DRAM
Motherboard: ASUS P6RP4 (Orion)
Ethernet card 1: Intel Etherexpress Pro/100B "fxp"
(Ethernet card 2: 21040A-based noname "de")
SCSI card #1: Adaptec 2940UW
(SCSI card #2: Adaptec 2940)
SCSI devices: Disks, tapedrives, CDROMs
NFS client:
CPU: P54 166MHz
Main memory: 64MB EDO DRAM
Motherboard: ASUS P55T2P4 (Triton-II 430HX)
Ethernet card 1: Intel Etherexpress Pro/100B "fxp"
(Ethernet card 2: SMC 8216 "ed")
(IDE hard drive)
Devices that are not involved in the operation that triggers the bug are
between parentheses. There are dual ethernet interfaces on the machines
because the 100Mb cards where just installed (one of them is also used for
forwarding packets between theses machines and the 10Mb/s network).
The fxp cards are connected to each other without a hub with a crossed
category 5 UTP cable.
>Description:
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.)
When doing the exact same operation using the other ethernet controllers
(i.e., the 10Mb/s channel between the ed and de interfaces) there are no
problems, with or without tcpdump running.
Also, I cannot provoke any hangs when using the fxp drivers for non-NFS
traffic, even if the traffix is made intensive.
>How-To-Repeat:
Probably sufficient to use an fxp device on an FreeBSD NFS server and run
tcpdump and then do some NFS reads and/or NFS writes. I haven't
investigated the envelope of this error, since I am uncertain if it will
help track it down. I am more than willing to assist attempts at
reproducing the panic, if these instructions would turn out to be
insufficient.
>Fix:
Disable BPF. Unfortunately the fxp driver and NFS writes seem incompatible.
With BPF disabled, the difference is that the client hangs on NFS
operations... :-(
>Audit-Trail:
>Unformatted:
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199704190506.HAA03203>