From tege@gmp.tmg.se  Fri Apr 18 22:07:41 1997
Received: from gmp.tmg.se (quiet.matematik.su.se [130.237.198.146])
          by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id WAA26342
          for <FreeBSD-gnats-submit@freebsd.org>; Fri, 18 Apr 1997 22:07:38 -0700 (PDT)
Received: (from tege@localhost)
	by gmp.tmg.se (8.8.5/8.8.5) id HAA03203;
	Sat, 19 Apr 1997 07:06:35 +0200 (CEST)
Message-Id: <199704190506.HAA03203@gmp.tmg.se>
Date: Sat, 19 Apr 1997 07:06:35 +0200 (CEST)
From: Torbjorn Granlund <tege@gmp.tmg.se>
Reply-To: tege@nada.kth.se
To: FreeBSD-gnats-submit@freebsd.org
Subject: Panic when using tcpdump on fxp device
X-Send-Pr-Version: 3.2

>Number:         3329
>Category:       kern
>Synopsis:       Panic when using tcpdump on fxp device
>Confidential:   no
>Severity:       serious
>Priority:       high
>Responsible:    freebsd-bugs
>State:          closed
>Quarter:
>Keywords:
>Date-Required:
>Class:          sw-bug
>Submitter-Id:   current-users
>Arrival-Date:   Fri Apr 18 22:10:01 PDT 1997
>Closed-Date:    Tue Apr 22 20:08:48 PDT 1997
>Last-Modified:  Tue Apr 22 20:10:55 PDT 1997
>Originator:     Torbjorn Granlund
>Release:        FreeBSD 2.2.1-RELEASE i386
>Organization:
TMG Datakonsult
>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...  :-(
>Release-Note:
>Audit-Trail:

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
State-Changed-From-To: open->closed 
State-Changed-By: davidg 
State-Changed-When: Tue Apr 22 20:08:48 PDT 1997 
State-Changed-Why:  
This was fixed in revs 1.34/1.21.2.6 by checking the validity of the 
packet length provided by the interface. 
Thanks for the bug report! 
>Unformatted:
