Re: kern/39094 (Add et (Agere ET1310/ET1301) network driver to NetBSD)

[jnemeth%victoria.tc.ca@localhost (John Nemeth)]

The following reply was made to PR kern/39094; it has been noted by GNATS.

From: jnemeth%victoria.tc.ca@localhost (John Nemeth)
To: gnats-bugs%NetBSD.org@localhost, netbsd-bugs%NetBSD.org@localhost,
        Kaspar Brand <netbsd+gnats%velox.ch@localhost>
Cc: 
Subject: Re: kern/39094 (Add et (Agere ET1310/ET1301) network driver to NetBSD)
Date: Mon, 5 Jan 2009 20:16:01 -0800

 On Apr 22,  6:22am, Kaspar Brand wrote:
 } 
 } From: Kaspar Brand <netbsd+gnats%velox.ch@localhost>
 } To: gnats-bugs%NetBSD.org@localhost
 } Cc: jnemeth%NetBSD.org@localhost
 } Subject: Re: kern/39094 (Add et (Agere ET1310/ET1301) network driver to 
NetBSD)
 } Date: Mon, 05 Jan 2009 19:12:13 +0100
 } 
 }  Ok, I've tested ET-i386 in the meantime, i.e.:
 }  
 }  NetBSD 5.99.5 (ET) #0: Wed Dec 31 10:56:30 PST 2008
 }      
jnemeth@P4-3679GHz:/usr/local/NetBSD-current/i386-objdir/sys/arch/i386/compile/ET
 }  
 }  everything was properly detected:
 }  
 }  et0 at pci1 dev 0 function 0: Lucent Technologies ET1310 10/100/1000 
Ethernet (rev. 0x01)
 }  et0: interrupting at ioapic0 pin 16
 }  et0: Ethernet address 00:0a:9d:09:2f:52
 }  etphy0 at et0 phy 0: Agere ET1011 10/100/1000baseT PHY, rev. 2
 }  etphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseT-FDX, auto
 }  
 }  and a couple of traffic tests (mainly with ttcp) also worked to
 }  my satisfaction - so yes, I think it's ready for being committed.
 
      Okay, thanks for testing.  I will add it to -current shortly.  I'm
 doing a NetBSD 5 build now, so that can be tested too.
 
 }  As an additional data point, note that I have been running a
 }  patched NetBSD 4.0 kernel with this driver for several months
 }  by now, and didn't experience any problems so far.
 
      That's good to know.  NetBSD 4 will take a bit longer.  NetBSD 5
 is rapidly approaching so I have to concentrate on it first.
 
 }  Finally, a last thing to note: I changed the device ID for the
 }  ET1301 controller on purpose - according to the data sheet, it's
 }  0xed01, not 0xed0a (as in the DragonFly/OpenBSD sources). I can't
 }  verify with a real controller, however, since I only have a system
 }  with an ET1310.
 
      Data sheets can be and are often wrong.  Can you check with some
 of the other people that have this driver to see if there is a reason
 for the discrepancy (such as empirical testing), please?
 
 }-- End of excerpt from Kaspar Brand