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-
........
On Tue, 16 Oct 2007 18:10:53 +0400
Konstantin Kalin <[email protected]> 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
On 10/16/2007 10:43 AM, Alan Cox wrote:
> On Tue, 16 Oct 2007 18:10:53 +0400
> Konstantin Kalin <[email protected]> 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?
> 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
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
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
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
In article <[email protected]> (at Tue, 16 Oct 2007 12:00:45 -0400), Jeff Garzik <[email protected]> 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
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
>
>
>
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
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
>
>
>
Alan Cox wrote:
> On Tue, 16 Oct 2007 18:10:53 +0400
> Konstantin Kalin <[email protected]> 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 <[email protected]>");
MODULE_DESCRIPTION("Reverse Engineered nForce ethernet driver");