From owner-freebsd-net@FreeBSD.ORG  Tue Apr 22 07:29:14 2003
Return-Path: <owner-freebsd-net@FreeBSD.ORG>
Delivered-To: freebsd-net@freebsd.org
Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125])
	by hub.freebsd.org (Postfix) with ESMTP id A24E937B401
	for <freebsd-net@freebsd.org>; Tue, 22 Apr 2003 07:29:14 -0700 (PDT)
Received: from mail.sandvine.com (sandvine.com [199.243.201.138])
	by mx1.FreeBSD.org (Postfix) with ESMTP id ECF1E43FA3
	for <freebsd-net@freebsd.org>; Tue, 22 Apr 2003 07:29:13 -0700 (PDT)
	(envelope-from ddolson@sandvine.com)
Received: by mail.sandvine.com with Internet Mail Service (5.5.2653.19)
	id <HS8WRLC8>; Tue, 22 Apr 2003 10:29:13 -0400
Message-ID: <FE045D4D9F7AED4CBFF1B3B813C8533701918A83@mail.sandvine.com>
From: Dave Dolson <ddolson@sandvine.com>
To: freebsd-net@freebsd.org
Date: Tue, 22 Apr 2003 10:29:09 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain;
	charset="iso-8859-1"
Subject: em net (optical GigE) driver hangs?
X-BeenThere: freebsd-net@freebsd.org
X-Mailman-Version: 2.1.1
Precedence: list
List-Id: Networking and TCP/IP with FreeBSD <freebsd-net.freebsd.org>
List-Unsubscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-net>,
	<mailto:freebsd-net-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-net>
List-Post: <mailto:freebsd-net@freebsd.org>
List-Help: <mailto:freebsd-net-request@freebsd.org?subject=help>
List-Subscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-net>,
	<mailto:freebsd-net-request@freebsd.org?subject=subscribe>
X-List-Received-Date: Tue, 22 Apr 2003 14:29:14 -0000


Has anyone experienced em interface hangs after approx several days of heavy
operation?

We are using a system which is mostly RELENG_4_7, using multiple optical em
GigE devices.

The symptom is that the interface stops transmitting or receiving, reporting
drops on output (no tx descriptors) and input errors (MPC stat-->no receive
descriptors).

It turns out that all but 64 transmit descriptors are in use.  The driver is
waiting for the "done" flag to be set so it can clean the descriptors.
The device is also in the OACTIVE state at this time.

After the interface is brought down (or unplugged), the em watchdog timer
goes off 5s later.

We are trying to figure out two things:
1. why did the driver lock up?
2. why didn't the watchdog timer go off earlier?

I think we would be happy to solve #2 given the rarity of the event.
Is the RELENG_4 version likely to fix the problem?

Any help or similar reports would be appreciated.

Thanks,
David Dolson (ddolson@sandvine.com, www.sandvine.com)