svn commit: r190872 - head/sys/dev/e1000

[Jack Vogel]

There is quite a bit of shared code changes to support alternate mac
addressing, if
you look at the diffs you'll notice in attach I inserted a reset, and then
also moved
where hardware init is called, this is because the shared code now requires
RAR(0)
to have a valid address in it when it does setup, reset causes that, but
init_hardware
will zero the RAR array out.

I have no idea what your environment is, but it sounds like it may be
related.

If you have a driver that works, you could try taking the new if_em.* and
drop
them in, see if that solves it. But right now my guess is this issue is in
the shared
code and not the core.

Let me know what you find,

Jack


On Sun, Apr 12, 2009 at 10:08 PM, Mike Silbersack <silby at silby.com> wrote:

>
> Jack, either this or some other recent change to the em driver caused it to
> stop working correctly on the e1000 virtual device inside VMware ESX.
> Unfortunately, I have not updated my 8.x VMs recently, so I don't know when
> this broke.
>
> I got the message about an invalid MAC address.  I modified
> em_is_valid_ether_addr to always return True, but it looks like the effect
> of that was to cause the driver to load, but give the NIC a MAC of
> 00:00:00:00:00:00.  However, if I manually set a MAC after that, the virtual
> NIC IS functional.  So I think the sole problem may just be that the code
> which reads the MAC is incompatible with the ESX emulation.
>
> Do you want me to try a kernel from immediately before this change to
> confirm that this was the cause of the problem?
>
> Mike "Silby" Silbersack
>
>
> On Fri, 10 Apr 2009, Jack F Vogel wrote:
>
>  Author: jfv
>> Date: Fri Apr 10 00:05:46 2009
>> New Revision: 190872
>> URL: http://svn.freebsd.org/changeset/base/190872
>>
>> Log:
>>  This delta syncs the em and igb drivers with Intel,
>>  adds header split and SCTP support into the igb driver.
>>  Various small improvements and fixes.
>>
>>