forcedeth: fix MAC address detection on network card (regression in 2.6.23)
Subsystems (2)
PATCH 2/8 forcedeth: fix MAC address detection on network card (regression in 2.6.23)
From: Michael Pyne <[email protected]>
Partially revert a change to mac address detection introduced to the forcedeth driver. The change was intended to correct mac address detection for newer nVidia chipsets where the mac address was stored in reverse order. One of those chipsets appears to still have the mac address in reverse order (or at least, it does on my system).
The change that broke mac address detection for my card was commit ef756b3e56c68a4d76d9d7b9a73fa8f4f739180f "forcedeth: mac address correct"
My network card is an nVidia built-in Ethernet card, output from lspci as follows (with text and numeric ids):
$ lspci | grep Ethernet 00:07.0 Bridge: nVidia Corporation MCP61 Ethernet (rev a2) $ lspci -n | grep 07.0 00:07.0 0680: 10de:03ef (rev a2)
The vendor id is, of course, nVidia. The device id corresponds to the NVIDIA_NVENET_19 entry.
The included patch fixes the MAC address detection on my system. Interestingly, the MAC address appears to be in the range reserved for my motherboard manufacturer (Gigabyte) and not nVidia.
---
drivers/net/forcedeth.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
drivers/net/forcedeth.c renamed from drivers/net/forcedeth.c~forcedeth-fix-mac-address-detection-on-network-card-regression-in-2623 +1 -1
@@ -5555,7 +5555,7 @@ static struct pci_device_id pci_tbl[] = }, {/* MCP61 Ethernet Controller */ PCI_DEVICE(PCI_VENDOR_ID_NVIDIA, PCI_DEVICE_ID_NVIDIA_NVENET_19), - .driver_data =DEV_NEED_TIMERIRQ |DEV_NEED_LINKTIMER |DEV_HAS_HIGH_DMA |DEV_HAS_POWER_CNTRL |DEV_HAS_MSI |DEV_HAS_PAUSEFRAME_TX |DEV_HAS_STATISTICS_V2 |DEV_HAS_TEST_EXTENDED |DEV_HAS_MGMT_UNIT |DEV_HAS_CORRECT_MACADDR , + .driver_data =DEV_NEED_TIMERIRQ |DEV_NEED_LINKTIMER |DEV_HAS_HIGH_DMA |DEV_HAS_POWER_CNTRL |DEV_HAS_MSI |DEV_HAS_PAUSEFRAME_TX |DEV_HAS_STATISTICS_V2 |DEV_HAS_TEST_EXTENDED |DEV_HAS_MGMT_UNIT , }, { /* MCP65 Ethernet Controller */ PCI_DEVICE(PCI_VENDOR_ID_NVIDIA, PCI_DEVICE_ID_NVIDIA_NVENET_20),
_
The solution is to get the OEM to update their BIOS (instead of integrating this patch) since the MCP61 specs indicate that the MAC Address should be in correct order from BIOS.
By changing the feature DEV_HAS_CORRECT_MACADDR to all MCP61 boards, it could cause it to break on other OEM systems who have implemented it correctly.
Thanks,
Ayaz
-----Original Message-----
From: [email protected] [mailto:[email protected]]
Sent: Wednesday, November 21, 2007 3:03 PM
To: [email protected]
Cc: [email protected]; [email protected]; [email protected]; Ayaz Abdulla; [email protected]
Subject: [patch 2/8] forcedeth: fix MAC address detection on network card (regression in 2.6.23)
From: Michael Pyne <[email protected]>
Partially revert a change to mac address detection introduced to the forcedeth
driver. The change was intended to correct mac address detection for newer
nVidia chipsets where the mac address was stored in reverse order. One of
those chipsets appears to still have the mac address in reverse order (or at
least, it does on my system).
The change that broke mac address detection for my card was commit ef756b3e56c68a4d76d9d7b9a73fa8f4f739180f "forcedeth: mac address correct"
My network card is an nVidia built-in Ethernet card, output from lspci as
follows (with text and numeric ids):
$ lspci | grep Ethernet 00:07.0 Bridge: nVidia Corporation MCP61 Ethernet (rev a2) $ lspci -n | grep 07.0 00:07.0 0680: 10de:03ef (rev a2)
The vendor id is, of course, nVidia. The device id corresponds to the NVIDIA_NVENET_19 entry.
The included patch fixes the MAC address detection on my system. Interestingly, the MAC address appears to be in the range reserved for my
motherboard manufacturer (Gigabyte) and not nVidia.
---
drivers/net/forcedeth.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
diff -puN drivers/net/forcedeth.c~forcedeth-fix-mac-address-detection-on-network-c ard-regression-in-2623 drivers/net/forcedeth.c
---
a/drivers/net/forcedeth.c~forcedeth-fix-mac-address-detection-on-network -card-regression-in-2623
+++ a/drivers/net/forcedeth.c
@@ -5555,7 +5555,7 @@ static struct pci_device_id pci_tbl[] =
},
{ /* MCP61 Ethernet Controller */
PCI_DEVICE(PCI_VENDOR_ID_NVIDIA,PCI_DEVICE_ID_NVIDIA_NVENET_19),
- .driver_data =
DEV_NEED_TIMERIRQ|DEV_NEED_LINKTIMER|DEV_HAS_HIGH_DMA|DEV_HAS_POWER_CNTR L|DEV_HAS_MSI|DEV_HAS_PAUSEFRAME_TX|DEV_HAS_STATISTICS_V2|DEV_HAS_TEST_E XTENDED|DEV_HAS_MGMT_UNIT|DEV_HAS_CORRECT_MACADDR,
+ .driver_data =
DEV_NEED_TIMERIRQ|DEV_NEED_LINKTIMER|DEV_HAS_HIGH_DMA|DEV_HAS_POWER_CNTR L|DEV_HAS_MSI|DEV_HAS_PAUSEFRAME_TX|DEV_HAS_STATISTICS_V2|DEV_HAS_TEST_E XTENDED|DEV_HAS_MGMT_UNIT,
},
{ /* MCP65 Ethernet Controller */
PCI_DEVICE(PCI_VENDOR_ID_NVIDIA,PCI_DEVICE_ID_NVIDIA_NVENET_20),
_
-----------------------------------------------------------------------------------
This email message is for the sole use of the intended recipient(s) and may contain confidential information. Any unauthorized review, use, disclosure or distribution is prohibited. If you are not the intended recipient, please contact the sender by reply email and destroy all copies of the original message.
-----------------------------------------------------------------------------------
Quoted 8 lines · On Wed, 21 Nov 2007 15:34:52 -0800 "Ayaz Abdulla" <[email protected]> wrote:
The solution is to get the OEM to update their BIOS (instead of integrating this patch) since the MCP61 specs indicate that the MAC Address should be in correct order from BIOS.
By changing the feature
DEV_HAS_CORRECT_MACADDRto all MCP61 boards, it could cause it to break on other OEM systems who have implemented it correctly.
Getting an OEM to fix their BIOS isn't always a simple thing...
Perhaps Michael's change should be enabled by a module parameter for those who happen to have the busted BIOS?
Quoted 7 lines · Andrew Morton
On Wed, 21 Nov 2007 15:34:52 -0800
Quoted 4 lines · Ayaz Abdulla
The solution is to get the OEM to update their BIOS (instead of integrating this patch) since the MCP61 specs indicate that the MAC Address should be in correct order from BIOS.
Quoted 8 lines
Quoted 3 lines
By changing the feature
DEV_HAS_CORRECT_MACADDRto all MCP61 boards, it could cause it to break on other OEM systems who have implemented it correctly.Getting an OEM to fix their BIOS isn't always a simple thing...
Perhaps Michael's change should be enabled by a module parameter for those who happen to have the busted BIOS?
I have contacted the motherboard vendor about this a couple of weeks ago per Ayaz's request and have received no response. I've also upgraded to the latest firmware for this motherboard and the bug remains.
I think it would be ideal if there were a way to detect broken MCP61's (i.e. those with a Gigabyte MAC ID instead of the nVidia one) and only reverse the MAC address then. A module parameter would also work but then I'd need to remember to apply it. :)
Regards,
- Michael Pyne
Quoted 17 lines · Michael Pyne
Quoted 7 lines · Andrew Morton
On Wed, 21 Nov 2007 15:34:52 -0800
Quoted 4 lines · Ayaz Abdulla
The solution is to get the OEM to update their BIOS (instead of integrating this patch) since the MCP61 specs indicate that the MAC Address should be in correct order from BIOS.
Quoted 8 lines
Quoted 3 lines
By changing the feature
DEV_HAS_CORRECT_MACADDRto all MCP61 boards, it could cause it to break on other OEM systems who have implemented it correctly.Getting an OEM to fix their BIOS isn't always a simple thing...
Perhaps Michael's change should be enabled by a module parameter for those who happen to have the busted BIOS?
Quoted 9 lines
I have contacted the motherboard vendor about this a couple of weeks ago per Ayaz's request and have received no response. I've also upgraded to the latest firmware for this motherboard and the bug remains.
I think it would be ideal if there were a way to detect broken MCP61's (i.e. those with a Gigabyte MAC ID instead of the nVidia one) and only reverse the MAC address then. A module parameter would also work but then I'd need to remember to apply it. :)
Hmm, MAC address makeups are not my strong point, but are the no rules describing the various parts of the address that could perhaps be used to infer programatically if the address seems to be reversed or not, and then use that detection logic for all boards that are known to potentially have the issue?
A module parameter that overrules the automatic detection (for when it gets it wrong) would probably also be a good idea.
Signature · 3 lines
Jesper Juhl <[email protected]> Don't top-post http://www.catb.org/~esr/jargon/html/T/top-post.html Plain text mails only, please http://www.expita.com/nomime.html