From: Konstantin Kalin <konstantin.kalin@gmail.com>
To: Alan Cox <alan@lxorguk.ukuu.org.uk>
Cc: linux-kernel@vger.kernel.org
Subject: Re: NVIDIA Ethernet & invalid MAC
Date: Wed, 17 Oct 2007 17:08:49 +0400 [thread overview]
Message-ID: <47160961.7040607@gmail.com> (raw)
In-Reply-To: <20071016154313.53d19c43@the-village.bc.nu>
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");
next prev parent reply other threads:[~2007-10-17 13:07 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-10-16 14:10 NVIDIA Ethernet & invalid MAC Konstantin Kalin
2007-10-16 14:43 ` Alan Cox
2007-10-16 15:16 ` Chuck Ebbert
2007-10-16 15:43 ` Alan Cox
2007-10-16 16:00 ` Jeff Garzik
2007-10-16 16:20 ` YOSHIFUJI Hideaki / 吉藤英明
2007-10-16 16:35 ` Konstantin Kalin
2007-10-16 16:41 ` Jeff Garzik
2007-10-16 16:52 ` Konstantin Kalin
2007-10-17 13:08 ` Konstantin Kalin [this message]
2007-10-16 16:00 ` Chris Snook
2007-10-16 16:07 ` Jeff Garzik
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=47160961.7040607@gmail.com \
--to=konstantin.kalin@gmail.com \
--cc=alan@lxorguk.ukuu.org.uk \
--cc=linux-kernel@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.