netdev - Re: [PATCH] forcedeth: Fix MAC address detection on network card (regression in 2.6.23)

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Date:	Sun, 14 Oct 2007 17:57:37 -0400
From:	Ayaz Abdulla <aabdulla@...dia.com>
To:	Jeff Garzik <jgarzik@...ox.com>
CC:	Michael Pyne <michael.pyne@...mail.net>,
	Andrew Morton <akpm@...ux-foundation.org>,
	netdev@...r.kernel.org
Subject: Re: [PATCH] forcedeth: Fix MAC address detection on network card
 (regression in 2.6.23)



Jeff Garzik wrote:
> Michael Pyne wrote:
> 
>> 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).
>>
>> Signed-off-by: Michael J. Pyne <michael.pyne@...mail.net>
>> ---
>> 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.
>>
>> If you need any further information about my hardware configuration 
>> just let me know.
>>
>> Regards,
>>  - Michael Pyne
>>
>> --- a/drivers/net/forcedeth.c       2007-10-11 22:01:26 -0400
>> +++ b/drivers/net/forcedeth-new.c   2007-10-11 22:06:52 -0400
>> @@ -5513,7 +5513,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),
> 
> 
> your patch is word-wrapped.  Anyway...
> 
> Ayaz -- ACK this patch?

ASUS should be contacted to fix their SBIOS instead of patching the driver.

MCP61 reference has the correct address programmed by SBIOS. There are 
other vendor boards that will have correct address (as defined by MCP61 
reference).



> 
> 
> 

-----------------------------------------------------------------------------------
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.
-----------------------------------------------------------------------------------
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html