Regression: em driver in -CURRENT, "Invalid MAC address"

[Jack Vogel]

Sigh.. both windows and linux have frozen drivers for this old hardware,
therefore they never see the regressions they cause in the current code :(

I will make a patch for you to test on Monday Mark, it will do the same
thing
that I did in the e1000_82540.c, basically change the read_mac function back
to the older way of doing it.

Regards,

Jack



On Sat, Jun 27, 2009 at 10:36 PM, Mark Atkinson <atkin901 at yahoo.com> wrote:

>
>
> ________________________________
> >From: Jack Vogel <jfvogel at gmail.com>
> >Oh, hmmm, so this card is completely broken with the new driver then?
>
> Completely, unfortunately (they don't show up in ifconfig, only in
> dmesg/pciconf).
>
> >What was the last working version you used?
>
> I was running a kernel from -current May 27th, 2009.   I don't recall
> any significant em updates between then and when the new driver went
> in.
>
> On Fri, Jun 26, 2009 at 11:36 AM, Mark Atkinson <atkin901 at yahoo.com>
> wrote:
> Jack Vogel wrote:
> > I'm willing to bet that its in fact the same problem that VMWare is
> > having. Our method of getting the mac address changed, and the emulations
> > seem to be unprepared for it.
> >
> > This was done for a real customer requirement to allow support of
> > alternate mac addressing in firmware. What happens now is a warm reset of
> > the hardware is done, followed by reading the RAR[0] register. In a real
> > Intel NIC the mac
> > address will be valid in that register, but in VMWare, and I'm willing to
> > bet in
> > VirtualBox as well, its 0.
> >
> > VMWare also has 3 choices of device (wow, amazing coincidence :), can
> > you tell me when you pick e1000 what real adapter it claims to emulate?
> >
> > I am considering options for this problem. The one I lean toward right
> now
> > is to make a "legacy" em driver, it will have support for ONLY pre-PCI
> > Express
> > hardware, it will be frozen as it were, the idea is that with no new work
> > on it
> > it will not suffer from any regression type failures. If I do this, there
> > are some
> > strategy issues, and its those I'm thinking about.
> >
> > In any case, I intend to have this problem resolved for 8's release. Stay
> > tuned.
>
> Just FYI.  this is a real machine with real cards.  Older fiber cards.
>
> em0: <Intel(R) PRO/1000 Network Connection 6.9.14> mem
> 0xdb000000-0xdb01ffff
> irq 28 at device 4.0 on pci19
> em0: Reserved 0x20000 bytes for rid 0x10 type 3 at 0xdb000000
>
> em0: Invalid MAC address
> device_attach: em0 attach returned 5
> em1: <Intel(R) PRO/1000 Network Connection 6.9.14> mem
> 0xdb020000-0xdb03ffff
> irq 29 at device 9.0 on pci19
> em1: Reserved 0x20000 bytes for rid 0x10 type 3 at 0xdb020000
>
> em1: Invalid MAC address
> device_attach: em1 attach returned 5
>
>
> $ pciconf -v -l |grep -A4 -e "^em"
> em0 at pci0:19:4:0:        class=0x020000 card=0x10008086 chip=0x10008086
> rev=0x03 hdr=0x00
>   vendor     = 'Intel Corporation'
>   device     = '82542 Gigabit Ethernet Controller'
>   class      = network
>   subclass   = ethernet
> em1 at pci0:19:9:0:        class=0x020000 card=0x10008086 chip=0x10008086
> rev=0x03 hdr=0x00
>   vendor     = 'Intel Corporation'
>   device     = '82542 Gigabit Ethernet Controller'
>   class      = network
>   subclass   = ethernet
>
>
>
> --
> Mark Atkinson
> atkin901 at yahoo.com
> (!wired)?(coffee++):(wired);
>
>
>
> _______________________________________________
> freebsd-net at freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-net
> To unsubscribe, send any mail to "freebsd-net-unsubscribe at freebsd.org"
>
>
>
>