NVIDIA Ethernet & invalid MAC

NVIDIA Ethernet & invalid MAC

[Konstantin Kalin]

Hello,

Recently we've got some computers with new motherboard having NVidia 
chipset. The motherboard has nforce12 & nforce13 Ethernet cards. I've 
noticed that MAC address is setup random each boot. I debugged the 
driver and found that these cards have right-byte order of MAC address 
but the driver is expecting incorrect byte-order for these models. I 
made hardcode the driver and MAC address became valid. Also I tried  to 
understand that difference in this revision of the chipset. But I 
couldn't find anything interesting. I'm ready continue the investigation 
to do correct changes in the driver but I need an advice.

P.S. It's simple to add DEV_HAS_CORRECT_MACADDR to pci_device_tlb for 
these types of Ethernet. But I think it's not right decision because it 
would break older revisions of these models.

[root@tfm ~]# lspci -vvv
.....
00:14.0 Bridge: nVidia Corporation MCP51 Ethernet Controller (rev a1)
        Subsystem: ASUSTeK Computer Inc. Unknown device 816a
        Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- 
ParErr- Stepping- SERR- FastB2B-
        Status: Cap+ 66MHz+ UDF- FastB2B+ ParErr- DEVSEL=fast >TAbort- 
<TAbort- <MAbort- >SERR- <PERR-
        Latency: 0 (250ns min, 5000ns max)
        Interrupt: pin A routed to IRQ 201
        Region 0: Memory at fe02b000 (32-bit, non-prefetchable) [size=4K]
        Region 1: I/O ports at c800 [size=8]
        Capabilities: [44] Power Management version 2
                Flags: PMEClk- DSI- D1+ D2+ AuxCurrent=0mA 
PME(D0+,D1+,D2+,D3hot+,D3cold+)
                Status: D0 PME-Enable+ DSel=0 DScale=0 PME-
........

Re: NVIDIA Ethernet & invalid MAC

[Alan Cox]

On Tue, 16 Oct 2007 18:10:53 +0400
Konstantin Kalin <konstantin.kalin@gmail.com> wrote:

> Hello,
> 
> Recently we've got some computers with new motherboard having NVidia 
> chipset. The motherboard has nforce12 & nforce13 Ethernet cards. I've 
> noticed that MAC address is setup random each boot. I debugged the 
> driver and found that these cards have right-byte order of MAC address 
> but the driver is expecting incorrect byte-order for these models.

The only obvious thing I can think of to try would be to read the MAC
address both ways around.

The first 3 bytes of the resulting MAC should always be the Nvidia
allocation as I understand it and if so you can then decide which way
around is correct. 

ie if it starts 00:04:0B then you know which way around it goes. (there
is one address that is the same either way around but clearly that one
doesn't matter).

So perhaps do that and for the afflicted parts add an EITHER_WAY_AROUND
flag ?

Alan

Re: NVIDIA Ethernet & invalid MAC

[Chuck Ebbert]

On 10/16/2007 10:43 AM, Alan Cox wrote:
> On Tue, 16 Oct 2007 18:10:53 +0400
> Konstantin Kalin <konstantin.kalin@gmail.com> wrote:
> 
>> Hello,
>>
>> Recently we've got some computers with new motherboard having NVidia 
>> chipset. The motherboard has nforce12 & nforce13 Ethernet cards. I've 
>> noticed that MAC address is setup random each boot. I debugged the 
>> driver and found that these cards have right-byte order of MAC address 
>> but the driver is expecting incorrect byte-order for these models.
> 
> The only obvious thing I can think of to try would be to read the MAC
> address both ways around.
> 
> The first 3 bytes of the resulting MAC should always be the Nvidia
> allocation as I understand it and if so you can then decide which way
> around is correct. 
> 
> ie if it starts 00:04:0B then you know which way around it goes. (there
> is one address that is the same either way around but clearly that one
> doesn't matter).
> 
> So perhaps do that and for the afflicted parts add an EITHER_WAY_AROUND
> flag ?
> 

See the below for another report of this:

http://marc.info/?t=119215716900001&r=1&w=2

And apparently some motherboard vendors have their own allocations for ethernet
addresses?

Re: NVIDIA Ethernet & invalid MAC

[Alan Cox]

> See the below for another report of this:
> 
> http://marc.info/?t=119215716900001&r=1&w=2
> 
> And apparently some motherboard vendors have their own allocations for ethernet
> addresses?

We can teach it two ranges. I doubt anyone will be unlucky enough to have
the one which could be either Nvidia or Gigabyte and have it matter.

The "go complain to the BIOS vendor" comment from Nvidia to me isn't an
answer. Maybe Nvidia can complain to BIOS vendors but end user complaints
of that form rarely have any effect.

Alan

Re: NVIDIA Ethernet & invalid MAC

[Chris Snook]

Konstantin Kalin wrote:
> P.S. It's simple to add DEV_HAS_CORRECT_MACADDR to pci_device_tlb for 
> these types of Ethernet. But I think it's not right decision because it 
> would break older revisions of these models.

Any reason you can't distinguish based on PCI ID?

	-- Chris

Re: NVIDIA Ethernet & invalid MAC

[Jeff Garzik]

Alan Cox wrote:
>> See the below for another report of this:
>>
>> http://marc.info/?t=119215716900001&r=1&w=2
>>
>> And apparently some motherboard vendors have their own allocations for ethernet
>> addresses?
> 
> We can teach it two ranges. I doubt anyone will be unlucky enough to have
> the one which could be either Nvidia or Gigabyte and have it matter.
> 
> The "go complain to the BIOS vendor" comment from Nvidia to me isn't an
> answer. Maybe Nvidia can complain to BIOS vendors but end user complaints
> of that form rarely have any effect.

That wasn't the point of the response at all.  The datum is that set of 
users where DEV_HAS_CORRECT_MACADDR is accurately set or clear is vast 
majority of cases.

For the rest, we'll want to look at adjusting DEV_HAS_CORRECT_MACADDR 
based on DMI strings or a hueristic like you suggested.

	Jeff

Re: NVIDIA Ethernet & invalid MAC

[Jeff Garzik]

Chris Snook wrote:
> Konstantin Kalin wrote:
>> P.S. It's simple to add DEV_HAS_CORRECT_MACADDR to pci_device_tlb for 
>> these types of Ethernet. But I think it's not right decision because 
>> it would break older revisions of these models.
> 
> Any reason you can't distinguish based on PCI ID?

That's presumably what he means, when he references the PCI device ID table.

But to establish that on a per-ID basis, we have to get some idea of the 
sample set.  You cannot just make the decision based on PCI ID alone, 
because that PCI ID can (and does) apply to multiple BIOS vendors.

	Jeff

Re: NVIDIA Ethernet & invalid MAC

[YOSHIFUJI Hideaki / 吉藤英明]

In article <4714E02D.7040804@garzik.org> (at Tue, 16 Oct 2007 12:00:45 -0400), Jeff Garzik <jeff@garzik.org> says:

> Alan Cox wrote:
> >> See the below for another report of this:
> >>
> >> http://marc.info/?t=119215716900001&r=1&w=2
> >>
> >> And apparently some motherboard vendors have their own allocations for ethernet
> >> addresses?
> > 
> > We can teach it two ranges. I doubt anyone will be unlucky enough to have
> > the one which could be either Nvidia or Gigabyte and have it matter.
> > 
> > The "go complain to the BIOS vendor" comment from Nvidia to me isn't an
> > answer. Maybe Nvidia can complain to BIOS vendors but end user complaints
> > of that form rarely have any effect.
> 
> That wasn't the point of the response at all.  The datum is that set of 
> users where DEV_HAS_CORRECT_MACADDR is accurately set or clear is vast 
> majority of cases.
> 
> For the rest, we'll want to look at adjusting DEV_HAS_CORRECT_MACADDR 
> based on DMI strings or a hueristic like you suggested.

I think we could have kernel parameter as well.

--yoshfuji

Re: NVIDIA Ethernet & invalid MAC

[Konstantin Kalin]

Hello,

I'm sorry, but I think that Alan proposed in the first email is more 
than a hack. It would solve the issue for different versions and the 
check is trivial. Or am I mistaken?

Thank you,
Kostya.

Jeff Garzik wrote:
> Alan Cox wrote:
>>> See the below for another report of this:
>>>
>>> http://marc.info/?t=119215716900001&r=1&w=2
>>>
>>> And apparently some motherboard vendors have their own allocations 
>>> for ethernet
>>> addresses?
>>
>> We can teach it two ranges. I doubt anyone will be unlucky enough to 
>> have
>> the one which could be either Nvidia or Gigabyte and have it matter.
>>
>> The "go complain to the BIOS vendor" comment from Nvidia to me isn't an
>> answer. Maybe Nvidia can complain to BIOS vendors but end user 
>> complaints
>> of that form rarely have any effect.
>
> That wasn't the point of the response at all.  The datum is that set 
> of users where DEV_HAS_CORRECT_MACADDR is accurately set or clear is 
> vast majority of cases.
>
> For the rest, we'll want to look at adjusting DEV_HAS_CORRECT_MACADDR 
> based on DMI strings or a hueristic like you suggested.
>
>     Jeff
>
>
>

Re: NVIDIA Ethernet & invalid MAC

[Jeff Garzik]

Konstantin Kalin wrote:
> I'm sorry, but I think that Alan proposed in the first email is more 
> than a hack. It would solve the issue for different versions and the 
> check is trivial. Or am I mistaken?

It assumes a constant MAC address vendor ID.

	Jeff

Re: NVIDIA Ethernet & invalid MAC

[Konstantin Kalin]

Well, I'm understanding it...and there needs three bytes. But looks like 
there is no other way to fix it taking into account other complaints.
Anyhow I couldn't find difference in this motherboard today  :(

Thank you,
Kostya.
 
Jeff Garzik wrote:
> Konstantin Kalin wrote:
>> I'm sorry, but I think that Alan proposed in the first email is more 
>> than a hack. It would solve the issue for different versions and the 
>> check is trivial. Or am I mistaken?
>
> It assumes a constant MAC address vendor ID.
>
>     Jeff
>
>
>

Re: NVIDIA Ethernet & invalid MAC

[Konstantin Kalin]

Alan Cox wrote:
> On Tue, 16 Oct 2007 18:10:53 +0400
> Konstantin Kalin <konstantin.kalin@gmail.com> wrote:
>
>   
>> Hello,
>>
>> Recently we've got some computers with new motherboard having NVidia 
>> chipset. The motherboard has nforce12 & nforce13 Ethernet cards. I've 
>> noticed that MAC address is setup random each boot. I debugged the 
>> driver and found that these cards have right-byte order of MAC address 
>> but the driver is expecting incorrect byte-order for these models.
>>     
>
> The only obvious thing I can think of to try would be to read the MAC
> address both ways around.
>
> The first 3 bytes of the resulting MAC should always be the Nvidia
> allocation as I understand it and if so you can then decide which way
> around is correct. 
>
> ie if it starts 00:04:0B then you know which way around it goes. (there
> is one address that is the same either way around but clearly that one
> doesn't matter).
>
> So perhaps do that and for the afflicted parts add an EITHER_WAY_AROUND
> flag ?
>
> Alan
>
>   

Hello,

I thought a bit today and made a patch. The patch adds new parameter to 
the driver that allows initializing MAC by manually. There is an issue 
that I didn't fix - if the driver has been loaded with wrong MAC 
detection when the parameter works inversely due to the driver replaces 
original mac. Please look at these line in "nv_probe" function:
 /* set permanent address to be correct aswell */
     np->orig_mac[0] = (dev->dev_addr[0] << 0) + (dev->dev_addr[1] << 8) +
....

P.S. The patch is based on vanila 2.6.21-7 because we use it in our 
servers.

Thank you,
Kostya.

-------------------------------------------------------------------------------------------------

--- linux-2.6.21.x86_64/drivers/net/forcedeth.c.orig    2007-10-17 
11:07:09.000000000 +0400
+++ linux-2.6.21.x86_64/drivers/net/forcedeth.c 2007-10-17 
11:07:32.000000000 +0400
@@ -850,6 +850,15 @@
 };
 static int dma_64bit = NV_DMA_64BIT_ENABLED;

+enum {
+       NV_FORCING_MAC_DISABLED = 0,
+       NV_FORCE_MAC_CORRECT_ORDER,
+       NV_FORCE_MAC_INVERSE_ORDER
+};
+
+static int force_mac = NV_FORCING_MAC_DISABLED;
+
+
 static inline struct fe_priv *get_nvpriv(struct net_device *dev)
 {
        return netdev_priv(dev);
@@ -4844,6 +4853,7 @@
        u32 powerstate, txreg;
        u32 phystate_orig = 0, phystate;
        int phyinitialized = 0;
+       bool mac_address_correct = false;

        dev = alloc_etherdev(sizeof(struct fe_priv));
        err = -ENOMEM;
@@ -5032,7 +5043,16 @@

        /* check the workaround bit for correct mac address order */
        txreg = readl(base + NvRegTransmitPoll);
-       if (txreg & NVREG_TRANSMITPOLL_MAC_ADDR_REV) {
+
+       /* Since Vendors begin fixing MAC address in oldest version of 
Etherenet card we should provide a way to initialize MAC by parameter */
+       mac_address_correct = (txreg & NVREG_TRANSMITPOLL_MAC_ADDR_REV) 
|| (force_mac == NV_FORCE_MAC_CORRECT_ORDER);
+       printk(KERN_DEBUG "force_mac=%d, txreg=%d, 
mac_address_correct=%d\n", force_mac, txreg, mac_address_correct);
+       if (force_mac == NV_FORCE_MAC_INVERSE_ORDER)
+       {
+               mac_address_correct = false;
+       }
+
+       if (mac_address_correct) {
                /* mac address is already in correct order */
                dev->dev_addr[0] = (np->orig_mac[0] >>  0) & 0xff;
                dev->dev_addr[1] = (np->orig_mac[0] >>  8) & 0xff;
@@ -5444,6 +5461,8 @@
 MODULE_PARM_DESC(msix, "MSIX interrupts are enabled by setting to 1 and 
disabled by setting to 0.");
 module_param(dma_64bit, int, 0);
 MODULE_PARM_DESC(dma_64bit, "High DMA is enabled by setting to 1 and 
disabled by setting to 0.");
+module_param(force_mac, int, 0);
+MODULE_PARM_DESC(force_mac, "Force MAC address in correct/inverse byte 
order. 0 - do nothing, 1 - correct order, 2 -inverse order");

 MODULE_AUTHOR("Manfred Spraul <manfred@colorfullife.com>");
 MODULE_DESCRIPTION("Reverse Engineered nForce ethernet driver");