Date: Sat, 28 Oct 2006 16:41:40 +0900 (JST) From: Hiroki Sato <hrs@FreeBSD.org> To: jfvogel@gmail.com Cc: jfv@FreeBSD.org, cvs-src@FreeBSD.org, src-committers@FreeBSD.org, cvs-all@FreeBSD.org Subject: Re: cvs commit: src/sys/dev/em if_em.c if_em.h if_em_hw.c if_em_hw.h if_em_osdep.h Message-ID: <20061028.164140.102116870.hrs@allbsd.org> In-Reply-To: <2a41acea0610280019r15d1e40bgbec37d9e0f72633e@mail.gmail.com> References: <200610280137.k9S1bFq2089275@repoman.freebsd.org> <20061028.161036.78701604.hrs@allbsd.org> <2a41acea0610280019r15d1e40bgbec37d9e0f72633e@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
----Security_Multipart(Sat_Oct_28_16_41_40_2006_504)--
Content-Type: Text/Plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
"Jack Vogel" <jfvogel@gmail.com> wrote
in <2a41acea0610280019r15d1e40bgbec37d9e0f72633e@mail.gmail.com>:
jf> On 10/28/06, Hiroki Sato <hrs@freebsd.org> wrote:
jf> > Jack F Vogel <jfv@FreeBSD.org> wrote
jf> > in <200610280137.k9S1bFq2089275@repoman.freebsd.org>:
jf> >
jf> > jf> jfv 2006-10-28 01:37:14 UTC
jf> > jf>
jf> > jf> FreeBSD src repository
jf> > jf>
jf> > jf> Modified files: (Branch: RELENG_6)
jf> > jf> sys/dev/em if_em.c if_em.h if_em_hw.c if_em_hw.h
jf> > jf> if_em_osdep.h
jf> > jf> Log:
jf> > jf> Merge of Intel 6.2.9 em driver code.
jf> > jf> Approved by: re, scottl, jhb, pdeuskar
jf> > jf>
jf> > jf> Revision Changes Path
jf> > jf> 1.65.2.19 +731 -589 src/sys/dev/em/if_em.c
jf> > jf> 1.32.2.5 +97 -71 src/sys/dev/em/if_em.h
jf> > jf> 1.16.2.4 +574 -531 src/sys/dev/em/if_em_hw.c
jf> > jf> 1.15.2.5 +96 -148 src/sys/dev/em/if_em_hw.h
jf> > jf> 1.14.2.3 +46 -52 src/sys/dev/em/if_em_osdep.h
jf> >
jf> > Just wanted to make sure, but is the following change in if_em.c
jf> > really intentional? This means that the new version no longer
jf> > supports 82542...
jf> >
jf> > Index: if_em.c
jf> > @@ -116,8 +117,6 @@
jf> > { 0x8086, E1000_DEV_ID_82541GI_LF, PCI_ANY_ID, PCI_ANY_ID, 0},
jf> > { 0x8086, E1000_DEV_ID_82541GI_MOBILE, PCI_ANY_ID, PCI_ANY_ID, 0},
jf> >
jf> > - { 0x8086, E1000_DEV_ID_82542, PCI_ANY_ID, PCI_ANY_ID, 0},
jf> > -
jf> > { 0x8086, E1000_DEV_ID_82543GC_FIBER, PCI_ANY_ID, PCI_ANY_ID, 0},
jf> > { 0x8086, E1000_DEV_ID_82543GC_COPPER, PCI_ANY_ID, PCI_ANY_ID, 0},
jf>
jf> Yes that was intentional, its an ID that the Intel source has not
jf> had for some time. When I put it back in our source a while back
jf> due to a merge our test group came to me and said these adapters
jf> dont even work with the driver, so clearly no one is using them :)
jf>
jf> I asked about dropping the ID to a set of developers and got the OK to drop
jf> it.
jf>
jf> If someone actually speaks up about having hardware that was working and
jf> now is broken I'll take it all back and we can put the ID back in, is that good
jf> enough? :)
So here is the report (from nyan@):
em0@pci1:1:0: class=0x020000 card=0x10008086 chip=0x10008086 rev=0x03 hdr=0x00
vendor = 'Intel Corporation'
device = '82542 Gigabit Ethernet Controller'
class = network
subclass = ethernet
It is not recognized by the new driver at boot time while worked fine
with the old one. I think we should not remove the existing
hardware support (especially in -STABLE) if possible.
--
| Hiroki SATO
----Security_Multipart(Sat_Oct_28_16_41_40_2006_504)--
Content-Type: application/pgp-signature
Content-Transfer-Encoding: 7bit
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2 (FreeBSD)
iD8DBQBFQwm0TyzT2CeTzy0RAnLLAJ9PhxxczQY/tGdazIx56Kx+LfU5hQCfeQJi
GUoghxqg1pYh/SJD3WQ23go=
=7uEI
-----END PGP SIGNATURE-----
----Security_Multipart(Sat_Oct_28_16_41_40_2006_504)----
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20061028.164140.102116870.hrs>