Date: Sun, 3 May 2009 01:15:16 +0200 From: Ivan Voras <ivoras@freebsd.org> To: Jack Vogel <jfvogel@gmail.com> Cc: freebsd-net@freebsd.org Subject: Re: Regression: em driver in -CURRENT, "Invalid MAC address" Message-ID: <9bbcef730905021615l21ef8a73hf26aca18f3230c3b@mail.gmail.com> In-Reply-To: <2a41acea0905020803s63b69b1awb39538f000f5bd5a@mail.gmail.com> References: <gthe3t$822$1@ger.gmane.org> <2a41acea0905020803s63b69b1awb39538f000f5bd5a@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
2009/5/2 Jack Vogel <jfvogel@gmail.com>:
> 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?
Here's the information on all three:
em0: <Intel(R) PRO/1000 Network Connection 6.9.9> port 0xc060-0xc067
mem 0xf0820000-0xf083ffff irq 16 at device 8.0 on pci0
em0: Invalid MAC address
device_attach: em0 attach returned 5
em1: <Intel(R) PRO/1000 Network Connection 6.9.9> port 0xc068-0xc06f
mem 0xf0840000-0xf085ffff irq 17 at device 9.0 on pci0
em1: Invalid MAC address
device_attach: em1 attach returned 5
em2: <Intel(R) PRO/1000 Network Connection 6.9.9> port 0xc070-0xc077
mem 0xf0860000-0xf087ffff irq 18 at device 10.0 on pci0
em2: Invalid MAC address
device_attach: em2 attach returned 5
em0@pci0:0:8:0: class=0x020000 card=0x001e8086 chip=0x100e8086 rev=0x02 hdr=0x00
vendor = 'Intel Corporation'
device = '82540EM Gigabit Ethernet Controller'
class = network
subclass = ethernet
cap 01[dc] = powerspec 2 supports D0 D3 current D0
cap 07[e4] = PCI-X supports 2048 burst read, 1 split transaction
em1@pci0:0:9:0: class=0x020000 card=0x10048086 chip=0x10048086 rev=0x02 hdr=0x00
vendor = 'Intel Corporation'
device = '82543GC Gigabit Ethernet Controller (Copper)'
class = network
subclass = ethernet
cap 01[dc] = powerspec 2 supports D0 D3 current D0
cap 07[e4] = PCI-X supports 2048 burst read, 1 split transaction
em2@pci0:0:10:0: class=0x020000 card=0x075015ad chip=0x100f8086
rev=0x02 hdr=0x00
vendor = 'Intel Corporation'
device = '82545EM Gigabit Ethernet Controller (copper)'
class = network
subclass = ethernet
cap 01[dc] = powerspec 2 supports D0 D3 current D0
cap 07[e4] = PCI-X supports 2048 burst read, 1 split transaction
> 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.
I think that would be a losing battle wrt future developments of both
the driver and the VM environments (too fragile state; anyway, other
OSes don't have the issue so why should we?).
I don't really know how it works but couldn't you use the information
talked about earlier (register is 0 after a warm reset) to detect the
general class of the problem and if detected conditionally proceed
with the old code / behaviour just for the initialization part?
Another possible route is to make use of VM detection present in HEAD
and just blindly use the old way if a VM environment is detected. I
think this is only slightly less bad than forking the driver since new
VM platforms are appearing all the time - is something like the middle
option doable?
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?9bbcef730905021615l21ef8a73hf26aca18f3230c3b>