Re: NVIDIA Ethernet & invalid MAC
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.orig2007-10-17
11:07:09.0 +0400
+++ linux-2.6.21.x86_64/drivers/net/forcedeth.c 2007-10-17
11:07:32.0 +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");
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: NVIDIA Ethernet invalid MAC
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.orig2007-10-17
11:07:09.0 +0400
+++ linux-2.6.21.x86_64/drivers/net/forcedeth.c 2007-10-17
11:07:32.0 +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);
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: NVIDIA Ethernet & invalid MAC
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 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: NVIDIA Ethernet & invalid MAC
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 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: NVIDIA Ethernet & invalid MAC
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=11921571691=1=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 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: NVIDIA Ethernet & invalid MAC
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=11921571691=1=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 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: NVIDIA Ethernet & invalid MAC
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 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: NVIDIA Ethernet & invalid MAC
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 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: NVIDIA Ethernet & invalid MAC
Alan Cox wrote: See the below for another report of this: http://marc.info/?t=11921571691=1=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 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: NVIDIA Ethernet & invalid MAC
> See the below for another report of this: > > http://marc.info/?t=11921571691=1=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 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: NVIDIA Ethernet & invalid MAC
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=11921571691=1=2 And apparently some motherboard vendors have their own allocations for ethernet addresses? - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: NVIDIA Ethernet & invalid MAC
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 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
NVIDIA Ethernet & invalid MAC
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. [EMAIL PROTECTED] ~]# 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- SERR- 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- - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
NVIDIA Ethernet invalid MAC
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. [EMAIL PROTECTED] ~]# 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- - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: NVIDIA Ethernet invalid MAC
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 - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: NVIDIA Ethernet invalid MAC
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=11921571691r=1w=2 And apparently some motherboard vendors have their own allocations for ethernet addresses? - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: NVIDIA Ethernet invalid MAC
See the below for another report of this: http://marc.info/?t=11921571691r=1w=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 - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: NVIDIA Ethernet invalid MAC
Alan Cox wrote: See the below for another report of this: http://marc.info/?t=11921571691r=1w=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 - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: NVIDIA Ethernet invalid MAC
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 - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: NVIDIA Ethernet invalid MAC
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 - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: NVIDIA Ethernet invalid MAC
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=11921571691r=1w=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 - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: NVIDIA Ethernet invalid MAC
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=11921571691r=1w=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 - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: NVIDIA Ethernet invalid MAC
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 - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: NVIDIA Ethernet invalid MAC
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 - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
