From pkern@cns.utoronto.ca  Wed Aug 20 15:17:01 2003
Return-Path: <pkern@cns.utoronto.ca>
Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125])
	by hub.freebsd.org (Postfix) with ESMTP id 5902E16A4BF
	for <FreeBSD-gnats-submit@freebsd.org>; Wed, 20 Aug 2003 15:17:01 -0700 (PDT)
Received: from rodent.utcs.utoronto.ca (rodent.utcs.utoronto.ca [128.100.102.5])
	by mx1.FreeBSD.org (Postfix) with SMTP id 7B17F43FBF
	for <FreeBSD-gnats-submit@freebsd.org>; Wed, 20 Aug 2003 15:17:00 -0700 (PDT)
	(envelope-from pkern@cns.utoronto.ca)
Received: by rodent.utcs.utoronto.ca id <1649124>; Wed, 20 Aug 2003 18:16:56 -0400
Message-Id: <03Aug20.181656edt.1649124@rodent.utcs.utoronto.ca>
Date: Wed, 20 Aug 2003 18:16:56 -0400
From: pak@cns.utoronto.ca
Reply-To: pak@cns.utoronto.ca
To: FreeBSD-gnats-submit@freebsd.org
Cc: pak@cns.utoronto.ca
Subject: em(4) interfaces (Intel Gigabit) are mute/silent/dumb on reboot.
X-Send-Pr-Version: 3.113
X-GNATS-Notify:

>Number:         55823
>Category:       kern
>Synopsis:       em(4) interfaces (Intel Gigabit) are mute/silent/dumb on reboot.
>Confidential:   no
>Severity:       serious
>Priority:       high
>Responsible:    tackerman
>State:          closed
>Quarter:        
>Keywords:       
>Date-Required:  
>Class:          sw-bug
>Submitter-Id:   current-users
>Arrival-Date:   Wed Aug 20 15:20:11 PDT 2003
>Closed-Date:    Thu Sep 23 16:50:41 GMT 2004
>Last-Modified:  Thu Sep 23 16:50:41 GMT 2004
>Originator:     pak
>Release:        FreeBSD 4.8-RELEASE i386
>Organization:
Computing and Network Services, U Toronto
>Environment:
System: FreeBSD rodent.utcs 4.8-RELEASE FreeBSD 4.8-RELEASE #0: Mon Apr 7 11:38:19 EDT 2003 root@:/usr/src/sys-48/compile/RODENT i386

	  ---

	[ from "pciconf -l -v" on three(3) DELL GX 260's
	  each with an on-board Intel Gigabit NIC ... ]

	em0@pci2:12:0:  class=0x020000 card=0x002e1028 chip=0x100e8086 rev=0x02 hdr=0x00
	    vendor   = 'Intel Corporation'
	    device   = '82544XT PRO/1000 MT Gigabit Ethernet Controller'
	    class    = network
	    subclass = ethernet

	  ---

	[ from "pciconf -l -v" on a DELL Dimension XPS R450
	  with an Intel PRO/1000 MT Dual Port adapter ... ]

	em0@pci0:14:0:  class=0x020000 card=0x10118086 chip=0x10108086 rev=0x01 hdr=0x00
	    vendor   = 'Intel Corporation'
	    device   = '82546EB Gigabit Ethernet Controller (copper)'
	    class    = network
	    subclass = ethernet
	em1@pci0:14:1:  class=0x020000 card=0x10118086 chip=0x10108086 rev=0x01 hdr=0x00
	    vendor   = 'Intel Corporation'
	    device   = '82546EB Gigabit Ethernet Controller (copper)'
	    class    = network
	    subclass = ethernet

	  ---

>Description:

	On reboot, an em(4) interface will not transmit until its
	twisted-pair cable is physically disconnected and then reconnected.

	While the em(4) interface is mute, a tcpdump will indicate that
	traffic is being received from the NIC (so it's not deaf) and
	traffic is being sent the NIC.  However, listening to the wire
	on a neighbouring system shows that em(4) NIC isn't actually
	transmitting anything.  Only after the em(4) NIC's cable is
	disconnected and reconnected does the expected traffic actually
	appear on the wire.

>How-To-Repeat:

	Using 2 machines, a system with an em(4) interface (box1) and
	a neighbouring system (box2) which can see all traffic coming
	from box1's em(4) interface (eg. via "tcpdump").
	Ideally, both systems are connected to the same hub or switch.

	- reboot box1.

	- run "tcpdump -n -l -e -t -i em0" on box1 to see that traffic
	  meant for transmission is being sent to the NIC (ARPs, etc.)
	  and that traffic is also being received by the NIC.

	- watch on box2 for any traffic coming from box1.
	    [ at this point, as far as box2 can tell, box1 should be silent ]

	- if no traffic from box1 is visible to box2, unplug and then
	  reconnect the twisted-pair cable attached to box1's Gigabit NIC.

	- watch on box2 for any traffic coming from box1.
	    [ box1 should be transmitting traffic that can now be seen by box2 ]

>Fix:

	


>Release-Note:
>Audit-Trail:
Responsible-Changed-From-To: freebsd-bugs->tackerman 
Responsible-Changed-By: dwmalone 
Responsible-Changed-When: Sun May 30 09:22:13 PDT 2004 
Responsible-Changed-Why:  
Tony is looking after the em driver now. 

http://www.freebsd.org/cgi/query-pr.cgi?pr=55823 

From: "Ackerman, Tony" <tony.ackerman@intel.com>
To: <freebsd-gnats-submit@FreeBSD.org>, <pak@cns.utoronto.ca>
Cc:  
Subject: Re: misc/55823: em(4) interfaces (Intel Gigabit) are mute/silent/dumb on reboot.
Date: Wed, 2 Jun 2004 15:47:20 -0700

 This is a multi-part message in MIME format.
 
 ------_=_NextPart_001_01C448F3.9017383C
 Content-Type: text/plain;
 	charset="us-ascii"
 Content-Transfer-Encoding: quoted-printable
 
 I'm unable to reproduce this problem.  Per the PR, I used 4.8 RELEASE
 and 1.4.10 em driver.  DUT was connected to an Intel 480T GbE switch and
 did not require any intervention at all to communicate after a re-boot.
 Since there a lots of systems with these adapters and this operating
 system which have not complained of this issue I suspect that there may
 be something specific to your network configuration.  Please provide
 more information about what type of switch you are connected to and
 verify that you are using CAT-5 cables.
 
 
 ------_=_NextPart_001_01C448F3.9017383C
 Content-Type: text/html;
 	charset="us-ascii"
 Content-Transfer-Encoding: quoted-printable
 
 <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
 <HTML>
 <HEAD>
 <META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
 charset=3Dus-ascii">
 <META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
 6.5.6944.0">
 <TITLE>Re: misc/55823: em(4) interfaces (Intel Gigabit) are =
 mute/silent/dumb on reboot.</TITLE>
 </HEAD>
 <BODY>
 <!-- Converted from text/rtf format -->
 
 <P><FONT SIZE=3D2 FACE=3D"Arial">I'm unable to reproduce this =
 problem.&nbsp; Per the PR, I used 4.8 RELEASE and 1.4.10 em =
 driver.&nbsp; DUT was connected to an Intel 480T GbE switch and did not =
 require any intervention at all to communicate after a re-boot.&nbsp; =
 Since there a lots of systems with these adapters and this operating =
 system which have not complained of this issue I suspect that there may =
 be something specific to your network configuration.&nbsp; Please =
 provide more information about what type of switch you are connected to =
 and verify that you are using CAT-5 cables.</FONT></P>
 
 </BODY>
 </HTML>
 ------_=_NextPart_001_01C448F3.9017383C--

From: pak@cns.utoronto.ca
To: freebsd-gnats-submit@FreeBSD.org, tony.ackerman@intel.com
Cc: pak@cns.utoronto.ca
Subject: Re: misc/55823: em(4) interfaces (Intel Gigabit) are mute/silent/dumb on reboot.
Date: Thu, 3 Jun 2004 09:30:23 -0400

 Hi.
 
 Ummm ... yes.  Wow, that's quite an old bug report.  I had completely
 forgotten about it.  It's quite possible that it was caused by a bad
 port on the hub.  That hub was replaced long ago.  And I haven't had
 that problem for quite some time.  Although the two events (a new hub,
 a working em(4) interface) didn't seem to be connected at the time.
 
 Thanks for the follow-up.
 pak.
 
 
 > From intel.com!tony.ackerman Wed Jun  2 19:26:17 2004
 > Content-class: urn:content-classes:message
 > MIME-Version: 1.0
 > Content-Type: multipart/alternative;
 > 	boundary="----_=_NextPart_001_01C448F3.9017383C"
 > Thread-Topic: Re: misc/55823: em(4) interfaces (Intel Gigabit) are mute/silent/dumb on reboot.
 > Thread-Index: AcRI84/NbQMIwg99Rd2Vbt8UOOwtug==
 > From:	"Ackerman, Tony" <tony.ackerman@intel.com>
 > To:	<freebsd-gnats-submit@FreeBSD.org>, <pak@cns.utoronto.ca>
 > X-OriginalArrivalTime: 02 Jun 2004 22:47:21.0180 (UTC) FILETIME=[908059C0:01C448F3]
 >
 > This is a multi-part message in MIME format.
 >
 > ------_=_NextPart_001_01C448F3.9017383C
 > Content-Type: text/plain;
 > 	charset="us-ascii"
 > Content-Transfer-Encoding: quoted-printable
 >
 > I'm unable to reproduce this problem.  Per the PR, I used 4.8 RELEASE
 > and 1.4.10 em driver.  DUT was connected to an Intel 480T GbE switch and
 > did not require any intervention at all to communicate after a re-boot.
 > Since there a lots of systems with these adapters and this operating
 > system which have not complained of this issue I suspect that there may
 > be something specific to your network configuration.  Please provide
 > more information about what type of switch you are connected to and
 > verify that you are using CAT-5 cables.
 >
 >
 > ------_=_NextPart_001_01C448F3.9017383C
 > Content-Type: text/html;
 > 	charset="us-ascii"
 > Content-Transfer-Encoding: quoted-printable
 >
 > <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
 > <HTML>
 > <HEAD>
 > <META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
 > charset=3Dus-ascii">
 > <META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
 > 6.5.6944.0">
 > <TITLE>Re: misc/55823: em(4) interfaces (Intel Gigabit) are =
 > mute/silent/dumb on reboot.</TITLE>
 > </HEAD>
 > <BODY>
 > <!-- Converted from text/rtf format -->
 >
 > <P><FONT SIZE=3D2 FACE=3D"Arial">I'm unable to reproduce this =
 > problem.&nbsp; Per the PR, I used 4.8 RELEASE and 1.4.10 em =
 > driver.&nbsp; DUT was connected to an Intel 480T GbE switch and did not =
 > require any intervention at all to communicate after a re-boot.&nbsp; =
 > Since there a lots of systems with these adapters and this operating =
 > system which have not complained of this issue I suspect that there may =
 > be something specific to your network configuration.&nbsp; Please =
 > provide more information about what type of switch you are connected to =
 > and verify that you are using CAT-5 cables.</FONT></P>
 >
 > </BODY>
 > </HTML>
 > ------_=_NextPart_001_01C448F3.9017383C--
 >
State-Changed-From-To: open->feedback 
State-Changed-By: tackerman 
State-Changed-When: Thu Sep 16 23:31:02 GMT 2004 
State-Changed-Why:  
This bug is stale and we're unable to reproduce.  I suspect that it may 
have been fixed.  If not we'll address it again. 

http://www.freebsd.org/cgi/query-pr.cgi?pr=55823 
State-Changed-From-To: feedback->closed 
State-Changed-By: tackerman 
State-Changed-When: Thu Sep 23 16:47:49 GMT 2004 
State-Changed-Why:  
PR closed as not reproducible.   
Originator reports that issue may have been caused by a bad hub. 

http://www.freebsd.org/cgi/query-pr.cgi?pr=55823 
>Unformatted:
It is possible that this behavior was caused by an issue that we had where
the gratiutious arp was being sent while the device was resetting and was
often missed.  However, I was not able to reproduce the problem so I can't
say for sure.  At any rate, please try again with the current driver and we'll
either close this PR or dig a bit deeper to reproduce.

