Date: Sat, 27 Jun 2009 22:36:08 -0700 (PDT) From: Mark Atkinson <atkin901@yahoo.com> To: Jack Vogel <jfvogel@gmail.com> Cc: freebsd-net@freebsd.org Subject: Re: Regression: em driver in -CURRENT, "Invalid MAC address" Message-ID: <688430.20427.qm@web37906.mail.mud.yahoo.com> In-Reply-To: <2a41acea0906261725x57e6903br9f3f42b55f3a3d30@mail.gmail.com> References: <gthe3t$822$1@ger.gmane.org> <2a41acea0905020803s63b69b1awb39538f000f5bd5a@mail.gmail.com> <h234fa$cob$1@ger.gmane.org> <2a41acea0906261725x57e6903br9f3f42b55f3a3d30@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
________________________________ >From: Jack Vogel <jfvogel@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@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@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@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@yahoo.com (!wired)?(coffee++):(wired); _______________________________________________ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org"
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?688430.20427.qm>