r8169 MAC addresses broken

r8169 MAC addresses broken

[Simon Arlott]

Somewhere between 2.6.24 (it would take too long to bisect) and now 
(e013e13bf605b9e6b702adffbe2853cfc60e7806), 2/3 of my MAC addresses 
are getting set to zero:

[    1.533565] r8169 Gigabit Ethernet driver 2.3LK-NAPI loaded
[    1.539277] r8169 0000:00:09.0: PCI INT A -> Link[LNKC] -> GSI 10 (level, low) -> IRQ 10
[    1.547518] r8169 0000:00:09.0: PCI: Disallowing DAC for device
[    1.553569] r8169 0000:00:09.0: no PCI Express capability
[    1.559063] r8169 0000:00:09.0: VPD access disabled, enabling
[    1.565822] r8169 0000:00:09.0: MAC address found in EEPROM: 00:30:18:b0:25:c2
[    1.573873] eth0: RTL8169sc/8110sc at 0xbf6f8000, 00:00:00:00:25:c2, XID 18000000 IRQ 10

[    1.582877] r8169 Gigabit Ethernet driver 2.3LK-NAPI loaded
[    1.595795] r8169 0000:00:0b.0: PCI INT A -> Link[LNKD] -> GSI 11 (level, low) -> IRQ 11
[    1.604039] r8169 0000:00:0b.0: PCI: Disallowing DAC for device
[    1.610089] r8169 0000:00:0b.0: no PCI Express capability
[    1.615581] r8169 0000:00:0b.0: VPD access disabled, enabling
[    1.622336] r8169 0000:00:0b.0: MAC address found in EEPROM: 00:30:18:b0:25:c3
[    1.630854] eth1: RTL8169sc/8110sc at 0xbf6fc000, 00:00:00:00:25:c3, XID 18000000 IRQ 11

If I set the MAC address to the correct value it then ignores packets 
sent to it and I have to use promiscuous mode.

00:09.0 0200: 10ec:8167 (rev 10)
	Subsystem: 16f3:10ec
	Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV+ VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx-
	Status: Cap+ 66MHz+ UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
	Latency: 64 (8000ns min, 16000ns max), Cache Line Size: 32 bytes
	Interrupt: pin A routed to IRQ 10
	Region 0: I/O ports at f600 [size=256]
	Region 1: Memory at fdfff000 (32-bit, non-prefetchable) [size=256]
	[virtual] Expansion ROM at 40000000 [disabled] [size=128K]
	Capabilities: [dc] Power Management version 2
		Flags: PMEClk- DSI- D1+ D2+ AuxCurrent=375mA PME(D0-,D1+,D2+,D3hot+,D3cold+)
		Status: D0 PME-Enable+ DSel=0 DScale=0 PME-
	Capabilities: [60] Vital Product Data <?>
	Kernel driver in use: r8169

00:0b.0 0200: 10ec:8167 (rev 10)
	Subsystem: 16f3:10ec
	Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV+ VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx-
	Status: Cap+ 66MHz+ UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
	Latency: 64 (8000ns min, 16000ns max), Cache Line Size: 32 bytes
	Interrupt: pin A routed to IRQ 11
	Region 0: I/O ports at f800 [size=256]
	Region 1: Memory at fdffe000 (32-bit, non-prefetchable) [size=256]
	[virtual] Expansion ROM at 40020000 [disabled] [size=128K]
	Capabilities: [dc] Power Management version 2
		Flags: PMEClk- DSI- D1+ D2+ AuxCurrent=375mA PME(D0-,D1+,D2+,D3hot+,D3cold+)
		Status: D0 PME-Enable+ DSel=0 DScale=0 PME-
	Capabilities: [60] Vital Product Data <?>
	Kernel driver in use: r8169


-- 
Simon Arlott

Re: r8169 MAC addresses broken

[Jiri Slaby]

On 10/25/2008 10:25 PM, Simon Arlott wrote:
> Somewhere between 2.6.24 (it would take too long to bisect) and now 
> (e013e13bf605b9e6b702adffbe2853cfc60e7806), 2/3 of my MAC addresses 
> are getting set to zero:
> 
> [    1.533565] r8169 Gigabit Ethernet driver 2.3LK-NAPI loaded
> [    1.539277] r8169 0000:00:09.0: PCI INT A -> Link[LNKC] -> GSI 10 (level, low) -> IRQ 10
> [    1.547518] r8169 0000:00:09.0: PCI: Disallowing DAC for device
> [    1.553569] r8169 0000:00:09.0: no PCI Express capability
> [    1.559063] r8169 0000:00:09.0: VPD access disabled, enabling
> [    1.565822] r8169 0000:00:09.0: MAC address found in EEPROM: 00:30:18:b0:25:c2
> [    1.573873] eth0: RTL8169sc/8110sc at 0xbf6f8000, 00:00:00:00:25:c2, XID 18000000 IRQ 10
> 
> [    1.582877] r8169 Gigabit Ethernet driver 2.3LK-NAPI loaded
> [    1.595795] r8169 0000:00:0b.0: PCI INT A -> Link[LNKD] -> GSI 11 (level, low) -> IRQ 11
> [    1.604039] r8169 0000:00:0b.0: PCI: Disallowing DAC for device
> [    1.610089] r8169 0000:00:0b.0: no PCI Express capability
> [    1.615581] r8169 0000:00:0b.0: VPD access disabled, enabling
> [    1.622336] r8169 0000:00:0b.0: MAC address found in EEPROM: 00:30:18:b0:25:c3
> [    1.630854] eth1: RTL8169sc/8110sc at 0xbf6fc000, 00:00:00:00:25:c3, XID 18000000 IRQ 11
> 
> If I set the MAC address to the correct value it then ignores packets 
> sent to it and I have to use promiscuous mode.

Ah, I thought I have broken hardware. I have similar problem, my mac is
initially all zeroes. When I set it up, it works until suspend. After that I
need to unbind the driver, bind it again, and it works then (mac is still the
set one).

I'm out of the notebook right now, but it is 10ec:8168:
06:00.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL8111/8168B PCI
Express Gigabit Ethernet controller (rev 01)
	Subsystem: ASUSTeK Computer Inc. Unknown device 11f5

I used it perfectly far later than 2.6.24 (maybe 2.6.26?), 2.6.27 is yet
defunct. This should be perfectly bisectable, would you, Simon? If this is not
fixed already -- I don't think so, mmotm few days ago is still broken. Francois,
anybody, does this ring bells anywhere?

Re: r8169 MAC addresses broken

[Francois Romieu]

Jiri Slaby <jirislaby@gmail.com> :
[...]
> Ah, I thought I have broken hardware. I have similar problem, my mac is
> initially all zeroes. When I set it up, it works until suspend. After that I
> need to unbind the driver, bind it again, and it works then (mac is still the
> set one).
> 
> I'm out of the notebook right now, but it is 10ec:8168:
> 06:00.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL8111/8168B PCI
> Express Gigabit Ethernet controller (rev 01)
> 	Subsystem: ASUSTeK Computer Inc. Unknown device 11f5
> 
> I used it perfectly far later than 2.6.24 (maybe 2.6.26?), 2.6.27 is yet
> defunct.

2.6.27 proper ? That's bad news.

Can you send a dmesg for 2.6.27 and 2.6.28-rc1 ?

> This should be perfectly bisectable, would you, Simon? If this is not
> fixed already -- I don't think so, mmotm few days ago is still broken.
> Francois, anybody, does this ring bells anywhere?

It may go away if one comments out rtl_init_mac_address in rtl8169_init_one
but I'd really like to figure why the driver loses the first 32 bits of the
mac address while it is perfectly able to read it correctly from the eeprom.

-- 
Ueimor

Re: r8169 MAC addresses broken

[Alistair John Strachan]

On Saturday 25 October 2008 23:34:43 Francois Romieu wrote:
> Jiri Slaby <jirislaby@gmail.com> :
> [...]
>
> > Ah, I thought I have broken hardware. I have similar problem, my mac is
> > initially all zeroes. When I set it up, it works until suspend. After
> > that I need to unbind the driver, bind it again, and it works then (mac
> > is still the set one).
> >
> > I'm out of the notebook right now, but it is 10ec:8168:
> > 06:00.0 Ethernet controller: Realtek Semiconductor Co., Ltd.
> > RTL8111/8168B PCI Express Gigabit Ethernet controller (rev 01)
> > 	Subsystem: ASUSTeK Computer Inc. Unknown device 11f5
> >
> > I used it perfectly far later than 2.6.24 (maybe 2.6.26?), 2.6.27 is yet
> > defunct.
>
> 2.6.27 proper ? That's bad news.

Just thought I'd chime in to report the same thing. I don't use the NICs very
frequently, so I didn't notice until I read the report.

On this machine, the NICs are never put through a suspend/resume cycle, so
that doesn't seem to be anything to do with it.

The NICs should have incremental MAC addresses, since they're mainboard
devices. Put it this way, they used to.

Now when they're detected, one has the correct MAC, and the second has the
first 32bits of its MAC corrupted.

eth0: RTL8169sc/8110sc at 0xffffc2000001e000, 00:50:8d:b3:5f:de, XID 18000000 IRQ 23                                                          
eth1: RTL8169sc/8110sc at 0xffffc20000070000, d8:81:ec:10:5f:df, XID 18000000 IRQ 22

d8:81:ec:10 is corruption; 00:50:8d:b3 is correct.

I can bisect pretty easily if this is helpful.

-- 
Cheers,
Alistair.

Re: r8169 MAC addresses broken

[Jiri Slaby]

Francois Romieu napsal(a):
> Jiri Slaby <jirislaby@gmail.com> :
> [...]
>> Ah, I thought I have broken hardware. I have similar problem, my mac is
>> initially all zeroes. When I set it up, it works until suspend. After that I
>> need to unbind the driver, bind it again, and it works then (mac is still the
>> set one).
>>
>> I'm out of the notebook right now, but it is 10ec:8168:
>> 06:00.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL8111/8168B PCI
>> Express Gigabit Ethernet controller (rev 01)
>> 	Subsystem: ASUSTeK Computer Inc. Unknown device 11f5
>>
>> I used it perfectly far later than 2.6.24 (maybe 2.6.26?), 2.6.27 is yet
>> defunct.
> 
> 2.6.27 proper ? That's bad news.
> 
> Can you send a dmesg for 2.6.27 and 2.6.28-rc1 ?

2.6.28-rc1 doesn't boot, the rest of dmesgs is at:
http://decibel.fi.muni.cz/~xslaby/r8169_mac/

However I may have a hw failure or some bug overwrote my eeprom, I see this
in current mmotm:
r8169 0000:06:00.0: PCI INT A disabled
r8169 Gigabit Ethernet driver 2.3LK-NAPI loaded
r8169 0000:06:00.0: PCI INT A -> GSI 18 (level, low) -> IRQ 18
r8169 0000:06:00.0: setting latency timer to 64
r8169: mac_version = 0x0c
r8169 0000:06:00.0: irq 43 for MSI/MSI-X
r8169: MAC address found in EEPROM: 00:00:00:00:00:00
eth0: RTL8168b/8111b at 0xffffc200042b0000, 00:00:00:00:00:00, XID 38000000
IRQ 43
r8169: mac_version = 0x0c

which looks like even in the eeprom are all zeroes now. Also 2.6.25 is
affected by this now and it worked (from_Jul dmesg).

Re: r8169 MAC addresses broken

[Krzysztof Halasa]

Jiri Slaby <jirislaby@gmail.com> writes:

> However I may have a hw failure or some bug overwrote my eeprom, I see this
> in current mmotm:
> r8169 0000:06:00.0: PCI INT A disabled
> r8169 Gigabit Ethernet driver 2.3LK-NAPI loaded
> r8169 0000:06:00.0: PCI INT A -> GSI 18 (level, low) -> IRQ 18
> r8169 0000:06:00.0: setting latency timer to 64
> r8169: mac_version = 0x0c
> r8169 0000:06:00.0: irq 43 for MSI/MSI-X
> r8169: MAC address found in EEPROM: 00:00:00:00:00:00
> eth0: RTL8168b/8111b at 0xffffc200042b0000, 00:00:00:00:00:00, XID 38000000

I think we need drivers or maybe some tool to save contents of those
little EEPROM / flash NVM configuration chips before it's too late.
First the ICH* e1000e corruption and now GbE RTL.
-- 
Krzysztof Halasa

Re: r8169 MAC addresses broken

[Francois Romieu]

Krzysztof Halasa <khc@pm.waw.pl> :
[...]
> First the ICH* e1000e corruption and now GbE RTL.

Ok, consider the whole thing reverted.

I thought this code could be made to work for -rc1 but new
failures keep appearing. Sorry for the mess.

-- 
Ueimor

Re: r8169 MAC addresses broken

[Jiri Slaby]

On 10/26/2008 12:34 AM, Francois Romieu wrote:
> It may go away if one comments out rtl_init_mac_address in rtl8169_init_one

Hmm, no. How can one restore eeprom contents without making a brick from the
notebook? I seem to have all zeroes in the eeprom mac address area.

Re: r8169 MAC addresses broken

[Arjan van de Ven]

On Sun, 26 Oct 2008 18:24:21 +0100
Jiri Slaby <jirislaby@gmail.com> wrote:

> On 10/26/2008 12:34 AM, Francois Romieu wrote:
> > It may go away if one comments out rtl_init_mac_address in
> > rtl8169_init_one
> 
> Hmm, no. How can one restore eeprom contents without making a brick
> from the notebook? I seem to have all zeroes in the eeprom mac
> address area. --

same here...  :(

-- 
Arjan van de Ven 	Intel Open Source Technology Centre
For development, discussion and tips for power savings, 
visit http://www.lesswatts.org

Re: r8169 MAC addresses broken

[Francois Romieu]

Jiri Slaby <jirislaby@gmail.com> :
[...]
> Hmm, no. How can one restore eeprom contents without making a brick from the
> notebook? I seem to have all zeroes in the eeprom mac address area.

:o(

Same thing if you unplug the battery ?

-- 
Ueimor

Re: r8169 MAC addresses broken

[Krzysztof Halasa]

Jiri Slaby <jirislaby@gmail.com> writes:

> However I may have a hw failure or some bug overwrote my eeprom, I see this
> in current mmotm:
> r8169 0000:06:00.0: PCI INT A disabled
> r8169 Gigabit Ethernet driver 2.3LK-NAPI loaded
> r8169 0000:06:00.0: PCI INT A -> GSI 18 (level, low) -> IRQ 18
> r8169 0000:06:00.0: setting latency timer to 64
> r8169: mac_version = 0x0c
> r8169 0000:06:00.0: irq 43 for MSI/MSI-X
> r8169: MAC address found in EEPROM: 00:00:00:00:00:00

Note there is no msg about missing EEPROM signature. I wonder what
exactly is in the EEPROM. A modified (and again reversed) "[PATCH 1/1]
r8169: revert "read MAC address from EEPROM on init" should be able to
show it.

There seem to be a DOS tool on RTL WWW to change the EEPROM data.
-- 
Krzysztof Halasa

Re: r8169 MAC addresses broken

[Simon Arlott]

On 26/10/08 12:52, Krzysztof Halasa wrote:
> Jiri Slaby <jirislaby@gmail.com> writes:
> 
>> However I may have a hw failure or some bug overwrote my eeprom, I see this
>> in current mmotm:
>> r8169 0000:06:00.0: PCI INT A disabled
>> r8169 Gigabit Ethernet driver 2.3LK-NAPI loaded
>> r8169 0000:06:00.0: PCI INT A -> GSI 18 (level, low) -> IRQ 18
>> r8169 0000:06:00.0: setting latency timer to 64
>> r8169: mac_version = 0x0c
>> r8169 0000:06:00.0: irq 43 for MSI/MSI-X
>> r8169: MAC address found in EEPROM: 00:00:00:00:00:00
>> eth0: RTL8168b/8111b at 0xffffc200042b0000, 00:00:00:00:00:00, XID 38000000
> 
> I think we need drivers or maybe some tool to save contents of those
> little EEPROM / flash NVM configuration chips before it's too late.
> First the ICH* e1000e corruption and now GbE RTL.

With the reverted patch my MAC addresses are still broken:

[    1.527660] r8169 Gigabit Ethernet driver 2.3LK-NAPI loaded
[    1.533421] r8169 0000:00:09.0: PCI INT A -> Link[LNKC] -> GSI 10 (level, low) -> IRQ 10
[    1.541743] r8169 0000:00:09.0: PCI: Disallowing DAC for device
[    1.547799] r8169 0000:00:09.0: no PCI Express capability
[    1.554519] eth0: RTL8169sc/8110sc at 0xbf6f8000, 00:00:00:00:25:c2, XID 18000000 IRQ 10

[    1.563480] r8169 Gigabit Ethernet driver 2.3LK-NAPI loaded
[    1.570525] ACPI: PCI Interrupt Link [LNKD] enabled at IRQ 11
[    1.576363] r8169 0000:00:0b.0: PCI INT A -> Link[LNKD] -> GSI 11 (level, low) -> IRQ 11
[    1.584597] r8169 0000:00:0b.0: PCI: Disallowing DAC for device
[    1.590651] r8169 0000:00:0b.0: no PCI Express capability
[    1.596659] eth1: RTL8169sc/8110sc at 0xbf6fc000, 00:00:00:00:25:c3, XID 18000000 IRQ 11

-- 
Simon Arlott

Re: r8169 MAC addresses broken

[Ivan Vecera]

Simon Arlott napsal(a):
> On 26/10/08 12:52, Krzysztof Halasa wrote:
>> Jiri Slaby <jirislaby@gmail.com> writes:
>>
>>> However I may have a hw failure or some bug overwrote my eeprom, I see this
>>> in current mmotm:
>>> r8169 0000:06:00.0: PCI INT A disabled
>>> r8169 Gigabit Ethernet driver 2.3LK-NAPI loaded
>>> r8169 0000:06:00.0: PCI INT A -> GSI 18 (level, low) -> IRQ 18
>>> r8169 0000:06:00.0: setting latency timer to 64
>>> r8169: mac_version = 0x0c
>>> r8169 0000:06:00.0: irq 43 for MSI/MSI-X
>>> r8169: MAC address found in EEPROM: 00:00:00:00:00:00
>>> eth0: RTL8168b/8111b at 0xffffc200042b0000, 00:00:00:00:00:00, XID 38000000
>> I think we need drivers or maybe some tool to save contents of those
>> little EEPROM / flash NVM configuration chips before it's too late.
>> First the ICH* e1000e corruption and now GbE RTL.
> 
> With the reverted patch my MAC addresses are still broken:
Try full power-off (disconnect power supply/remove battery).

> 
> [    1.527660] r8169 Gigabit Ethernet driver 2.3LK-NAPI loaded
> [    1.533421] r8169 0000:00:09.0: PCI INT A -> Link[LNKC] -> GSI 10 (level, low) -> IRQ 10
> [    1.541743] r8169 0000:00:09.0: PCI: Disallowing DAC for device
> [    1.547799] r8169 0000:00:09.0: no PCI Express capability
> [    1.554519] eth0: RTL8169sc/8110sc at 0xbf6f8000, 00:00:00:00:25:c2, XID 18000000 IRQ 10
> 
> [    1.563480] r8169 Gigabit Ethernet driver 2.3LK-NAPI loaded
> [    1.570525] ACPI: PCI Interrupt Link [LNKD] enabled at IRQ 11
> [    1.576363] r8169 0000:00:0b.0: PCI INT A -> Link[LNKD] -> GSI 11 (level, low) -> IRQ 11
> [    1.584597] r8169 0000:00:0b.0: PCI: Disallowing DAC for device
> [    1.590651] r8169 0000:00:0b.0: no PCI Express capability
> [    1.596659] eth1: RTL8169sc/8110sc at 0xbf6fc000, 00:00:00:00:25:c3, XID 18000000 IRQ 11
> 

Re: r8169 MAC addresses broken

[Jiri Slaby]

On 10/26/2008 06:46 PM, Francois Romieu wrote:
> Jiri Slaby <jirislaby@gmail.com> :
> [...]
>> Hmm, no. How can one restore eeprom contents without making a brick from the
>> notebook? I seem to have all zeroes in the eeprom mac address area.
> 
> :o(
> 
> Same thing if you unplug the battery ?

Thanks, now it seems to be OK.

Re: r8169 MAC addresses broken

[Krzysztof Halasa]

Jiri Slaby <jirislaby@gmail.com> writes:

>> Same thing if you unplug the battery ?
>
> Thanks, now it seems to be OK.

Well, perhaps reverting that patch was a bit premature?

If removing battery fixes the problem then it's not the EEPROM.
Perhaps the chip can go into some VPD-zeroed state? The first
32-bits corruption seems unrelated to the patch, it still needs
bisecting or debugging, right?
-- 
Krzysztof Halasa

Re: r8169 MAC addresses broken

[Jiri Slaby]

On 10/28/2008 02:45 PM, Krzysztof Halasa wrote:
> Jiri Slaby <jirislaby@gmail.com> writes:
> 
>>> Same thing if you unplug the battery ?
>> Thanks, now it seems to be OK.
> 
> Well, perhaps reverting that patch was a bit premature?

No, it helped after reverting that patch. I think we don't want defunct 2.6.28
with these nics.

> If removing battery fixes the problem then it's not the EEPROM.

Agreed.

Re: r8169 MAC addresses broken

[Krzysztof Halasa]

Jiri Slaby <jirislaby@gmail.com> writes:

> No, it helped after reverting that patch. I think we don't want defunct 2.6.28
> with these nics.

No doubt.

Just to be sure, with the patch back, is the MAC read as zero again?
I'll check it too, have 8111.
-- 
Krzysztof Halasa

Re: r8169 MAC addresses broken

[Ivan Vecera]

Jiri Slaby wrote:
> On 10/28/2008 02:45 PM, Krzysztof Halasa wrote:
>> Jiri Slaby <jirislaby@gmail.com> writes:
>>
>>>> Same thing if you unplug the battery ?
>>> Thanks, now it seems to be OK.
>> Well, perhaps reverting that patch was a bit premature?
> 
> No, it helped after reverting that patch. I think we don't want defunct 2.6.28
> with these nics.
I cannot agree. IMO the problem was in the first version of the patch that didn't
check for invalid (zeroed) MAC address. In this case is necessary to power-off (desktop
case) or unplug the battery (notebook case).

> 
>> If removing battery fixes the problem then it's not the EEPROM.
> 
> Agreed.

Re: r8169 MAC addresses broken

[Jiri Slaby]

On 11/03/2008 10:04 AM, Ivan Vecera wrote:
> Jiri Slaby wrote:
>> On 10/28/2008 02:45 PM, Krzysztof Halasa wrote:
>>> Jiri Slaby <jirislaby@gmail.com> writes:
>>>
>>>>> Same thing if you unplug the battery ?
>>>> Thanks, now it seems to be OK.
>>> Well, perhaps reverting that patch was a bit premature?
>> No, it helped after reverting that patch. I think we don't want defunct 2.6.28
>> with these nics.
> I cannot agree.

You want defunct r8169 in 2.6.28? Or cannot agree with what?

> IMO the problem was in the first version of the patch that didn't
> check for invalid (zeroed) MAC address. In this case is necessary to power-off (desktop
> case) or unplug the battery (notebook case).

I see no updated patch in this thread to test -- am I missing something?

Re: r8169 MAC addresses broken

[Ivan Vecera]

Jiri Slaby wrote:
> On 11/03/2008 10:04 AM, Ivan Vecera wrote:
>> Jiri Slaby wrote:
>>> On 10/28/2008 02:45 PM, Krzysztof Halasa wrote:
>>>> Jiri Slaby <jirislaby@gmail.com> writes:
>>>>
>>>>>> Same thing if you unplug the battery ?
>>>>> Thanks, now it seems to be OK.
>>>> Well, perhaps reverting that patch was a bit premature?
>>> No, it helped after reverting that patch. I think we don't want defunct 2.6.28
>>> with these nics.
>> I cannot agree.
> 
> You want defunct r8169 in 2.6.28? Or cannot agree with what?
> 
>> IMO the problem was in the first version of the patch that didn't
>> check for invalid (zeroed) MAC address. In this case is necessary to power-off (desktop
>> case) or unplug the battery (notebook case).
> 
> I see no updated patch in this thread to test -- am I missing something?
Francois has fix for this problem (zeroed MAC address) in his repository:
http://git.kernel.org/?p=linux/kernel/git/romieu/netdev-2.6.git;a=commitdiff;h=9b1abbccf53ef1a1213b159d56257b535c599f07

snippet:
...
-       /* Write MAC address */
-       rtl_rar_set(tp, mac);
+       if (is_valid_ether_addr(mac))
+               rtl_rar_set(tp, mac);
...


When MAC only zeros then it is not assigned. Pulling this commit is better than reverting whole patch.

Ivan

Re: r8169 MAC addresses broken

[Jiri Slaby]

Ivan Vecera napsal(a):
> Francois has fix for this problem (zeroed MAC address) in his repository:
> http://git.kernel.org/?p=linux/kernel/git/romieu/netdev-2.6.git;a=commitdiff;h=9b1abbccf53ef1a1213b159d56257b535c599f07

I've applied the 2 patches with this result:
r8169 Gigabit Ethernet driver 2.3LK-NAPI loaded
r8169 0000:06:00.0: PCI INT A -> GSI 18 (level, low) -> IRQ 18
r8169 0000:06:00.0: setting latency timer to 64
r8169 0000:06:00.0: irq 43 for MSI/MSI-X
r8169 0000:06:00.0: Missing EEPROM signature: 00000000
eth0: RTL8168b/8111b at 0xffffc20000038000, 00:18:f3:f8:e1:ca, XID 38000000
IRQ 43

Re: r8169 MAC addresses broken

[Ivan Vecera]

Jiri Slaby wrote:
> Ivan Vecera napsal(a):
>> Francois has fix for this problem (zeroed MAC address) in his repository:
>> http://git.kernel.org/?p=linux/kernel/git/romieu/netdev-2.6.git;a=commitdiff;h=9b1abbccf53ef1a1213b159d56257b535c599f07
> 
> I've applied the 2 patches with this result:
> r8169 Gigabit Ethernet driver 2.3LK-NAPI loaded
> r8169 0000:06:00.0: PCI INT A -> GSI 18 (level, low) -> IRQ 18
> r8169 0000:06:00.0: setting latency timer to 64
> r8169 0000:06:00.0: irq 43 for MSI/MSI-X
> r8169 0000:06:00.0: Missing EEPROM signature: 00000000
> eth0: RTL8168b/8111b at 0xffffc20000038000, 00:18:f3:f8:e1:ca, XID 38000000
> IRQ 43
So, no MAC was read from EEPROM but it's is correct. Please try to change
MAC address by ifconfig or ip and then reboot (no power-off). What's in dmesg
now?

Ivan