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
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?
Jiri Slaby <[email protected]> :
[...]
> 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
On Saturday 25 October 2008 23:34:43 Francois Romieu wrote:
> Jiri Slaby <[email protected]> :
> [...]
>
> > 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.
Francois Romieu napsal(a):
> Jiri Slaby <[email protected]> :
> [...]
>> 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).
Jiri Slaby <[email protected]> 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
Krzysztof Halasa <[email protected]> :
[...]
> 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
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.
On Sun, 26 Oct 2008 18:24:21 +0100
Jiri Slaby <[email protected]> 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
Jiri Slaby <[email protected]> :
[...]
> 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
Jiri Slaby <[email protected]> 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
On 26/10/08 12:52, Krzysztof Halasa wrote:
> Jiri Slaby <[email protected]> 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
On 10/26/2008 06:46 PM, Francois Romieu wrote:
> Jiri Slaby <[email protected]> :
> [...]
>> 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.
Jiri Slaby <[email protected]> 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
On 10/28/2008 02:45 PM, Krzysztof Halasa wrote:
> Jiri Slaby <[email protected]> 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.
Simon Arlott napsal(a):
> On 26/10/08 12:52, Krzysztof Halasa wrote:
>> Jiri Slaby <[email protected]> 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
>
Jiri Slaby <[email protected]> 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
Jiri Slaby wrote:
> On 10/28/2008 02:45 PM, Krzysztof Halasa wrote:
>> Jiri Slaby <[email protected]> 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.
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 <[email protected]> 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?
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 <[email protected]> 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
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
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