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

[Ivan Voras]

2009/5/2 Jack Vogel <jfvogel at 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 at 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 at 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 at 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?