NetBSD Problem Report #40586

From gcw@primenet.com.au  Mon Feb  9 05:41:29 2009
Return-Path: <gcw@primenet.com.au>
Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11])
	by narn.NetBSD.org (Postfix) with ESMTP id 0DB3C63B882
	for <gnats-bugs@gnats.NetBSD.org>; Mon,  9 Feb 2009 05:41:29 +0000 (UTC)
Message-Id: <20090209052232.2476.qmail@g.primenet.com.au>
Date: 9 Feb 2009 16:22:32 +1100
From: gcw@primenet.com.au
Reply-To: gcw@primenet.com.au
To: gnats-bugs@gnats.NetBSD.org
Subject: rgephy(4) now selects incorrect speed for some re(4)
X-Send-Pr-Version: 3.95

>Number:         40586
>Category:       kern
>Synopsis:       rgephy(4) now selects an incorrect speed for some re(4)
>Confidential:   no
>Severity:       critical
>Priority:       low
>Responsible:    kern-bug-people
>State:          closed
>Class:          sw-bug
>Submitter-Id:   net
>Arrival-Date:   Mon Feb 09 05:45:00 +0000 2009
>Closed-Date:    Thu Feb 12 07:26:51 +0000 2009
>Last-Modified:  Thu Feb 12 07:26:51 +0000 2009
>Originator:     Geoff C. Wing
>Release:        NetBSD 5.99.7
>Organization:
>Environment:
System: NetBSD g.primenet.com.au 5.99.7 NetBSD 5.99.7 (G) #0: Thu Jan 29 14:22:50 EST 2009 gcw@g.primenet.com.au:/usr/netbsd/src/sys/arch/i386/compile/G i386
Architecture: i386
Machine: i386
>Description:
	rgephy(4) will now select "10baseT half-duplex" rather than
	"1000baseT full-duplex" for some re(4).  This is not desirable.

re0 at pci5 dev 4 function 0: RealTek 8169SC/8110SC Single-chip Gigabit Ethernet (rev. 0x10)
re0: interrupting at ioapic0 pin 16
re0: Ethernet address .................
re0: using 256 tx descriptors
rgephy0 at re0 phy 7: RTL8169S/8110S/8211 1000BASE-T media interface, rev. 2
rgephy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseT, 1000baseT-FDX, auto

>How-To-Repeat:
	.
>Fix:
	Repair the change made in rev 1.25 of sys/dev/mii/rgephy.c which
	ripped out the necessary initialisation.

>Release-Note:

>Audit-Trail:
From: Christoph Egger <Christoph_Egger@gmx.de>
To: gnats-bugs@NetBSD.org
Cc: kern-bug-people@netbsd.org, gnats-admin@netbsd.org, 
 netbsd-bugs@netbsd.org
Subject: Re: kern/40586: rgephy(4) now selects incorrect speed for some re(4)
Date: Mon, 09 Feb 2009 23:00:44 +0100

 I'm using rgephy(4) on nfe(4) and I can't reproduce
 the problem. Maybe rgephy.c triggers a bug in re(4) now ?

 Christoph

From: Geoff Wing <gcw@pobox.com>
To: gnats-bugs@NetBSD.org
Cc: 
Subject: Re: kern/40586: rgephy(4) now selects incorrect speed for some
	re(4)
Date: Tue, 10 Feb 2009 09:53:24 +1100

 On Monday 2009-02-09 22:05 +0000, Christoph Egger output:
 : I'm using rgephy(4) on nfe(4) and I can't reproduce
 : the problem. Maybe rgephy.c triggers a bug in re(4) now ?
 : 
 : Christoph

 It only applies to some chips.  The hack I'm using (see below)
 reintroduces some of the previous version which initialised the
 chip differently.  The rgephy_load_dspcode() path doesn't do
 the same PHY_WRITE()s.

 Regards,
 Geoff

 --- rgephy.c.orig	2009-02-09 10:45:34.000000000 +1100
 +++ rgephy.c	2009-01-20 12:33:49.000000000 +1100
 @@ -593,17 +593,20 @@
  	struct rgephy_softc *rsc;
  	uint16_t ssr;

 +	mii_phy_reset(sc);
 +	DELAY(1000);
 +
  	rsc = (struct rgephy_softc *)sc;
 -	if (rsc->mii_revision == 3) {
 +	if (rsc->mii_revision < 2) {
 +		rgephy_load_dspcode(sc);
 +	} else if (rsc->mii_revision == 3) {
  		/* RTL8211C(L) */
  		ssr = PHY_READ(sc, RGEPHY_MII_SSR);
  		if ((ssr & RGEPHY_SSR_ALDPS) != 0) {
  			ssr &= ~RGEPHY_SSR_ALDPS;
  			PHY_WRITE(sc, RGEPHY_MII_SSR, ssr);
  		}
 -	}
 -#if 0
 -	else {
 +	} else {
  		PHY_WRITE(sc, 0x1F, 0x0001);
  		PHY_WRITE(sc, 0x09, 0x273a);
  		PHY_WRITE(sc, 0x0e, 0x7bfb);
 @@ -629,9 +632,5 @@
  	/* NWay enable and Restart NWay */
  	PHY_WRITE(sc, RGEPHY_MII_BMCR,
  	    RGEPHY_BMCR_RESET | RGEPHY_BMCR_AUTOEN | RGEPHY_BMCR_STARTNEG);
 -#endif

 -	mii_phy_reset(sc);
 -	DELAY(1000);
 -	rgephy_load_dspcode(sc);
  }

From: Christoph Egger <Christoph_Egger@gmx.de>
To: gnats-bugs@NetBSD.org
Cc: kern-bug-people@netbsd.org, gnats-admin@netbsd.org, 
 netbsd-bugs@netbsd.org, gcw@primenet.com.au
Subject: Re: kern/40586: rgephy(4) now selects incorrect speed for some	re(4)
Date: Tue, 10 Feb 2009 00:36:09 +0100

 Geoff Wing wrote:
 > The following reply was made to PR kern/40586; it has been noted by GNATS.
 > 
 > From: Geoff Wing <gcw@pobox.com>
 > To: gnats-bugs@NetBSD.org
 > Cc: 
 > Subject: Re: kern/40586: rgephy(4) now selects incorrect speed for some
 > 	re(4)
 > Date: Tue, 10 Feb 2009 09:53:24 +1100
 > 
 >  On Monday 2009-02-09 22:05 +0000, Christoph Egger output:
 >  : I'm using rgephy(4) on nfe(4) and I can't reproduce
 >  : the problem. Maybe rgephy.c triggers a bug in re(4) now ?
 >  : 
 >  : Christoph
 >  
 >  It only applies to some chips.  The hack I'm using (see below)
 >  reintroduces some of the previous version which initialised the
 >  chip differently.  The rgephy_load_dspcode() path doesn't do
 >  the same PHY_WRITE()s.
 >  
 >  Regards,
 >  Geoff
 >  
 >  --- rgephy.c.orig	2009-02-09 10:45:34.000000000 +1100
 >  +++ rgephy.c	2009-01-20 12:33:49.000000000 +1100
 >  @@ -593,17 +593,20 @@
 >   	struct rgephy_softc *rsc;
 >   	uint16_t ssr;
 >   
 >  +	mii_phy_reset(sc);
 >  +	DELAY(1000);
 >  +
 >   	rsc = (struct rgephy_softc *)sc;
 >  -	if (rsc->mii_revision == 3) {
 >  +	if (rsc->mii_revision < 2) {
 >  +		rgephy_load_dspcode(sc);

 rgephy_load_dspcode() already does this revision check.
 You can safely call it unconditionally.

 >  +	} else if (rsc->mii_revision == 3) {
 >   		/* RTL8211C(L) */
 >   		ssr = PHY_READ(sc, RGEPHY_MII_SSR);
 >   		if ((ssr & RGEPHY_SSR_ALDPS) != 0) {
 >   			ssr &= ~RGEPHY_SSR_ALDPS;
 >   			PHY_WRITE(sc, RGEPHY_MII_SSR, ssr);
 >   		}
 >  -	}
 >  -#if 0
 >  -	else {
 >  +	} else {
 >   		PHY_WRITE(sc, 0x1F, 0x0001);
 >   		PHY_WRITE(sc, 0x09, 0x273a);
 >   		PHY_WRITE(sc, 0x0e, 0x7bfb);
 >  @@ -629,9 +632,5 @@
 >   	/* NWay enable and Restart NWay */
 >   	PHY_WRITE(sc, RGEPHY_MII_BMCR,
 >   	    RGEPHY_BMCR_RESET | RGEPHY_BMCR_AUTOEN | RGEPHY_BMCR_STARTNEG);
 >  -#endif
 >   
 >  -	mii_phy_reset(sc);
 >  -	DELAY(1000);
 >  -	rgephy_load_dspcode(sc);
 >   }
 >  

From: Geoff Wing <gcw@pobox.com>
To: gnats-bugs@NetBSD.org
Cc: 
Subject: Re: kern/40586: rgephy(4) now selects incorrect speed for some
	re(4)
Date: Tue, 10 Feb 2009 10:45:46 +1100

 On Monday 2009-02-09 23:40 +0000, Christoph Egger output:
 : rgephy_load_dspcode() already does this revision check.
 : You can safely call it unconditionally.

 I guess my patch doesn't clearly indicate the revival of all the
 code that is now "#if 0"d out, some being initial different
 PHY_WRITE() values and then the following PHY_WRITE()s in:

         /* Reset capabilities */
         /* Step1: write our capability */
         /* 10/100 capability */
         /* 1000 capability */
         /* Step2: Restart NWay */
         /* NWay enable and Restart NWay */

 which isn't handled by rgephy_load_dspcode().

 Regards,
 Geoff

From: Izumi Tsutsui <tsutsui@ceres.dti.ne.jp>
To: Christoph_Egger@gmx.de
Cc: gnats-bugs@NetBSD.org, kern-bug-people@NetBSD.org, gnats-admin@NetBSD.org,
        netbsd-bugs@NetBSD.org, tsutsui@ceres.dti.ne.jp
Subject: Re: kern/40586: rgephy(4) now selects incorrect speed for some re(4)
Date: Wed, 11 Feb 2009 10:30:40 +0900

 Christoph_Egger@gmx.de wrote:

 > I'm using rgephy(4) on nfe(4) and I can't reproduce
 > the problem. Maybe rgephy.c triggers a bug in re(4) now ?

 It's a quite bad idea to blindly "sync" sources without tests
 or proper analysis. As you can see in cvs logs, you just reverted
 some our local changes that were there since our initial revision.

 Please back it out and confirm which change actually improves
 your (rev 3 only?) hardware.  Functional changes and cosmetic ones
 should not be mixed as commit guideline says.
 ---
 Izumi Tsutsui

From: Christoph Egger <cegger@netbsd.org>
To: gnats-bugs@gnats.NetBSD.org
Cc: 
Subject: PR/40586 CVS commit: src/sys/dev/mii
Date: Wed, 11 Feb 2009 23:01:07 +0000 (UTC)

 Module Name:	src
 Committed By:	cegger
 Date:		Wed Feb 11 23:01:07 UTC 2009

 Modified Files:
 	src/sys/dev/mii: rgephy.c

 Log Message:
 revert changes in rgephy_reset() done in rev. 1.25.
 Should fix PR 40586


 To generate a diff of this commit:
 cvs rdiff -r1.25 -r1.26 src/sys/dev/mii/rgephy.c

 Please note that diffs are not public domain; they are subject to the
 copyright notices on the relevant files.

State-Changed-From-To: open->feedback
State-Changed-By: cegger@NetBSD.org
State-Changed-When: Thu, 12 Feb 2009 07:18:14 +0000
State-Changed-Why:
A question has been asked.


From: Christoph Egger <Christoph_Egger@gmx.de>
To: gnats-bugs@NetBSD.org
Cc: kern-bug-people@netbsd.org, gnats-admin@netbsd.org, 
 netbsd-bugs@netbsd.org, gcw@primenet.com.au
Subject: Re: kern/40586: rgephy(4) now selects incorrect speed for some re(4)
Date: Thu, 12 Feb 2009 08:16:46 +0100

 Does rgephy.c, rev. 1.26 fix the problem ?

From: Geoff Wing <gcw@pobox.com>
To: gnats-bugs@NetBSD.org
Cc: 
Subject: Re: kern/40586 (rgephy(4) now selects an incorrect speed for some
	re(4))
Date: Thu, 12 Feb 2009 18:20:32 +1100

 On Thursday 2009-02-12 07:18 +0000, cegger@NetBSD.org output:
 :State-Changed-From-To: open->feedback
 :A question has been asked.

 The change is the same as the one I've been using successfully.
 The PR may be closed.

 Regards,
 Geoff

State-Changed-From-To: feedback->closed
State-Changed-By: cegger@NetBSD.org
State-Changed-When: Thu, 12 Feb 2009 07:26:51 +0000
State-Changed-Why:
Submitter confirms bug fixed.


>Unformatted:

Home	PR Database Search