r8169: NFG in 2.6.24-rc2

PATCH In review Mark Lord 4 participants 17 messages Nov 7, 2007 – Nov 8, 2007 Network drivers

Share & tools

Mark Lord

author

2007-11-07 16:07 UTC #0 lore raw

My ASUS board has one of these:

01:00.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL8111/8168B PCI Express Gigabit Ethernet controller (rev 01)
Subsystem: ASUSTeK Computer Inc. Unknown device 81aa
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-
Interrupt: pin A routed to IRQ 16
Region 0: I/O ports at 9800 [size=256]
Region 2: Memory at ff3ff000 (64-bit, non-prefetchable) [size=4K]
Expansion ROM at ff3c0000 [disabled] [size=128K]
Capabilities: [40] 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: [48] Vital Product Data
Capabilities: [50] Message Signalled Interrupts: Mask- 64bit+ Queue=0/1 Enable-
Address: 0000000000000000 Data: 0000
Capabilities: [60] Express Endpoint IRQ 0
Device: Supported: MaxPayload 1024 bytes, PhantFunc 0, ExtTag+
Device: Latency L0s <1us, L1 unlimited
Device: AtnBtn+ AtnInd+ PwrInd+
Device: Errors: Correctable- Non-Fatal- Fatal- Unsupported-
Device: RlxdOrd+ ExtTag- PhantFunc- AuxPwr- NoSnoop+
Device: MaxPayload 128 bytes, MaxReadReq 4096 bytes
Link: Supported Speed 2.5Gb/s, Width x4, ASPM L0s, Port 0
Link: Latency L0s unlimited, L1 unlimited
Link: ASPM Disabled RCB 64 bytes CommClk+ ExtSynch-
Link: Speed 2.5Gb/s, Width x1
Capabilities: [84] Vendor Specific Information

It works perfectly in 2.6.23.
It does not work in 2.6.24-rc2. Dunno about -rc1 or earlier -git*.

Without CONFIG_PCI_MSI, it works slightly, enough to ping it a couple of times, but it then dies when used for anything real:

	r8169 Gigabit Ethernet driver 2.2LK loaded
	r8169 0000:01:00.0: no MSI. Back to INTx.
	...
	eth0: RTL8168b/8111b at 0xf884a000, 00:17:31:64:e0:bc, XID 30000000 IRQ 16
	...
	r8169: eth0: link up
	...
	kernel: NETDEV WATCHDOG: eth0: transmit timed out
	r8169: eth0: link up
	...

Not usable from this point on.

With CONFIG_PCI_MSI=y, it also fails, and then isn't even detected (not in lspci) on subsequent reboots. A power cycle is required to get it to show up again.

Help?

Mark Lord

author

2007-11-07 17:11 UTC #1 lore raw

Quoted 5 lines · Mark Lord

My ASUS board has one of these:
01:00.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL8111/8168B PCI Express Gigabit Ethernet controller (rev 01)
Subsystem: ASUSTeK Computer Inc. Unknown device 81aa
Control: I/O+ Mem+ BusMaster- SpecCycle- MemWINV- VGASnoop-

Quoted 10 lines

    ...
    r8169: eth0: link up
    ...
    kernel: NETDEV WATCHDOG: eth0: transmit timed out
    r8169: eth0: link up
    ...
Not usable from this point on.
With CONFIG_PCI_MSI=y, it also fails, and then isn't even detected (not in lspci) on subsequent reboots. A power cycle is required to get it to show up again.

Ahh.. this seems to have been around for a while already, as there's an unresolved bug entry from -rc1 for this exact problem.

http://bugzilla.kernel.org/show_bug.cgi?id=9257

Mark Lord

author

2007-11-07 18:02 UTC #2 lore raw

PATCH 1/1 r8169 fix regression on ASUS motherboards

In reply to Mark Lord

Fix r8169 regression on ASUS motherboards.

The r8169 ethernet driver worked fine in 2.6.23, but fails in 2.6.24-rc* for the onboard ethernet of ASUS P5B series motherboards. This patch fixes it again.

Signed-off-by Mark Lord <[email protected]>

drivers/net/r8169.c +0 -0

@@ -1325,6 +1325,7 @@

		rtl8169sb_hw_phy_config(ioaddr);
		break;
	case RTL_GIGA_MAC_VER_11:
+		break;
	case RTL_GIGA_MAC_VER_12:
	case RTL_GIGA_MAC_VER_17:
		rtl8168b_hw_phy_config(ioaddr);

cecco

2007-11-07 21:12 UTC #13 lore raw

In reply to Mark Lord

Quoted 5 lines · Mark Lord <lkml <at> rtr.ca> writes:

My ASUS board has one of these:
Realtek Semiconductor Co., Ltd. RTL8111/8168B PCI Express Gigabit
With CONFIG_PCI_MSI=y, it also fails, and then isn't even

detected lspci)

Quoted 3 lines

on subsequent reboots. A power cycle is required to get it to show up again.
Help?

Hello,

I have a asus a6t with RTL8111/8168B
PCI Express Gigabit and I have had a similar problem.
PCI-MSI-edge seems to break this ethernet card. My card has stopped to work, I have powered off my notebook for hours, but I am not been lucky, because it has showed up only one time and then in next reboot with kernel 2.6.23 is disappeared again (in this kernel there is not problem with this ethernet card ).
I have reflashed bios and fortunately this card now works again. contacted one realtek developer, but he hasn't replied. I am been lucky
to not send my notebook in repairing.

It's very bad !

Francois Romieu

2007-11-07 22:05 UTC #3 lore raw

Re: [PATCH] r8169 fix regression on ASUS motherboards

In reply to Mark Lord

Mark Lord <[email protected]> :

Quoted 5 lines

Fix r8169 regression on ASUS motherboards.
The r8169 ethernet driver worked fine in 2.6.23, but fails in 2.6.24-rc* for the onboard ethernet of ASUS P5B series motherboards. This patch fixes it again.

[...]

drivers/net/r8169.c line 1331

Quoted 10 lines

drivers/net/r8169.c +1 -0

@@ -1325,6 +1325,7 @@
 		rtl8169sb_hw_phy_config(ioaddr);
 		break;
 	case RTL_GIGA_MAC_VER_11:
+		break;
 	case RTL_GIGA_MAC_VER_12:
 	case RTL_GIGA_MAC_VER_17:
 		rtl8168b_hw_phy_config(ioaddr);

I am not convinced, the broken ones include some RTL_GIGA_MAC_VER_12 too, namely XID = 0x38000000.

I would much prefer to revert the broken commit completely (which I am currently isolating).

Signature · 1 line

Ueimor

Francois Romieu

2007-11-07 22:08 UTC #14 lore raw

In reply to cecco

cecco <[email protected]> :
[...]

Quoted 10 lines

I have a asus a6t with RTL8111/8168B
PCI Express Gigabit and I have had a similar problem.
PCI-MSI-edge seems to break this ethernet card. My card has stopped to work, I have powered off my notebook for hours, but I am not been lucky, because it has showed up only one time and then in next reboot with kernel 2.6.23 is disappeared again (in this kernel there is not problem with this ethernet card ).

Did you unplug the battery ?

Signature · 1 line

Ueimor

Mark Lord

author

2007-11-07 22:21 UTC #4 lore raw

Re: [PATCH] r8169 fix regression on ASUS motherboards

In reply to Francois Romieu

Quoted 7 lines · Francois Romieu

Mark Lord <[email protected]> :
Quoted 5 lines
Fix r8169 regression on ASUS motherboards.
The r8169 ethernet driver worked fine in 2.6.23, but fails in 2.6.24-rc* for the onboard ethernet of ASUS P5B series motherboards. This patch fixes it again.
[...]

Quoted 13 lines

drivers/net/r8169.c line 1331
Quoted 10 lines
drivers/net/r8169.c +1 -0
@@ -1325,6 +1325,7 @@
 		rtl8169sb_hw_phy_config(ioaddr);
 		break;
 	case RTL_GIGA_MAC_VER_11:
+		break;
 	case RTL_GIGA_MAC_VER_12:
 	case RTL_GIGA_MAC_VER_17:
 		rtl8168b_hw_phy_config(ioaddr);
I am not convinced, the broken ones include some RTL_GIGA_MAC_VER_12 too, namely XID = 0x38000000.

Tested and working here on VER_11. I don't have a VER_12, so I left that as-is. If you want to fix that as well, just move the new "break;" down one line.

The rest of the broken commit works fine without the new call to rtl8168b_hw_phy_config(ioaddr).

It's been weeks now, so please FIX it now.

Thanks.

Mark Lord

author

2007-11-07 22:25 UTC #5 lore raw

PATCH 1/1 r8169 fix regression on ASUS motherboards (updated)

Quoted 4 lines · Mark Lord

Francois Romieu wrote:
..
Quoted 2 lines
I am not convinced, the broken ones include some RTL_GIGA_MAC_VER_12 too, namely XID = 0x38000000.

Here is the updated patch for both VER_11 and VER_12. Let's get this in, as the driver has been broken for weeks now.

* * * *

Fix r8169 regression on ASUS motherboards.

Second attempt. This one fixes both VER_11 and VER_12 MACs.

The r8169 ethernet driver worked fine in 2.6.23, but fails in 2.6.24-rc* for the onboard ethernet of ASUS P5B series motherboards. This patch fixes it again.

Signed-off-by Mark Lord <[email protected]>

drivers/net/r8169.c +0 -0

@@ -1326,6 +1326,7 @@

		break;
	case RTL_GIGA_MAC_VER_11:
	case RTL_GIGA_MAC_VER_12:
+		break;
	case RTL_GIGA_MAC_VER_17:
		rtl8168b_hw_phy_config(ioaddr);
		break;

Francois Romieu

2007-11-07 22:49 UTC #6 lore raw

Re: [PATCH] r8169 fix regression on ASUS motherboards (updated)

Mark Lord <[email protected]> :

Quoted 9 lines

Quoted 4 lines · Mark Lord
Francois Romieu wrote:
..
Quoted 2 lines
I am not convinced, the broken ones include some RTL_GIGA_MAC_VER_12 too, namely XID = 0x38000000.
..
Here is the updated patch for both VER_11 and VER_12. Let's get this in, as the driver has been broken for weeks now.

I have not been waiting for you and I am not interested in your controversy.

I'll find the offending commit and revert it. It is that simple.

Signature · 1 line

Ueimor

Mark Lord

author

2007-11-07 23:20 UTC #8 lore raw

Re: [PATCH] r8169 fix regression on ASUS motherboards (updated)

In reply to Mark Lord

Quoted 25 lines · Mark Lord

Quoted 4 lines · Mark Lord
Francois Romieu wrote:
..
Quoted 2 lines
I am not convinced, the broken ones include some RTL_GIGA_MAC_VER_12 too, namely XID = 0x38000000.
..
Here is the updated patch for both VER_11 and VER_12. Let's get this in, as the driver has been broken for weeks now.
* * * *
Fix r8169 regression on ASUS motherboards.
Second attempt. This one fixes both VER_11 and VER_12 MACs.
The r8169 ethernet driver worked fine in 2.6.23, but fails in 2.6.24-rc* for the onboard ethernet of ASUS P5B series motherboards. This patch fixes it again.
Signed-off-by Mark Lord <[email protected]>

drivers/net/r8169.c 2007-11-07 17:22:59.000000000 -0500 line 1332

Quoted 7 lines

drivers/net/r8169.c 2007-11-07 17:22:59.000000000 -0500 renamed from drivers/net/r8169.c 2007-11-03 16:24:16.000000000 -0400 +1 -0
@@ -1326,6 +1326,7 @@
        break;
    case RTL_GIGA_MAC_VER_11:
    case RTL_GIGA_MAC_VER_12:
+        break;
    case RTL_GIGA_MAC_VER_17:
        rtl8168b_hw_phy_config(ioaddr);
        break;

I've now received a couple of private emails from people reporting full success with this patch.

Cheers

Mark Lord

author

2007-11-07 23:23 UTC #7 lore raw

Re: [PATCH] r8169 fix regression on ASUS motherboards (updated)

In reply to Francois Romieu

Quoted 8 lines · Francois Romieu

Mark Lord <[email protected]> :
Quoted 7 lines
Quoted 4 lines · Mark Lord
Francois Romieu wrote:
..
Quoted 2 lines
I am not convinced, the broken ones include some RTL_GIGA_MAC_VER_12 too, namely XID = 0x38000000.
..

Quoted 7 lines

Quoted 2 lines
Here is the updated patch for both VER_11 and VER_12. Let's get this in, as the driver has been broken for weeks now.
I have not been waiting for you and I am not interested in your controversy.
I'll find the offending commit and revert it. It is that simple.

I think the rest of the commit was fine -- there seems to be some nice cleanups there to make it easier to maintain.

Just the new register writes (rtl8168b_hw_phy_config()) are mucking things up. Prevent those from happening, and all is well.

Cheers

Francois Romieu

2007-11-08 00:21 UTC #9 lore raw

Re: [PATCH] r8169 fix regression on ASUS motherboards (updated)

In reply to Mark Lord

Mark Lord <[email protected]> :
[...]

Quoted 2 lines

I've now received a couple of private emails from people reporting full success with this patch.

Ok, I have pushed the patch below for Jeff to pull at korg.

Quoted 1 line

From 1dd7681bc2ff171341ea5cae957f8ecb5c0c102e Mon Sep 17 00:00:00 2001

From: Mark Lord <[email protected]>
Date: Thu, 8 Nov 2007 01:03:04 +0100
Subject: [PATCH] r8169: revert 7da97ec96a0934319c7fbedd3d38baf533e20640 (partly)

Various symptoms depending on the .config options:
- the card stops working after some (short) time
- the card does not work at all
- the card disappears (nothing in lspci/dmesg)

A real power-off is needed to recover the card.

Signed-off-by Mark Lord <[email protected]>

Signed-off-by Francois Romieu <[email protected]>

---
 drivers/net/r8169.c |    1 +
 1 files changed, 1 insertions(+), 0 deletions(-)

drivers/net/r8169.c +1 -0

index 9dbab3f..a37cf82 100644
@@ -1328,6 +1328,7 @@ static void rtl_hw_phy_config(struct net_device *dev)
 		break;
 	case RTL_GIGA_MAC_VER_11:
 	case RTL_GIGA_MAC_VER_12:
+		break;
 	case RTL_GIGA_MAC_VER_17:
 		rtl8168b_hw_phy_config(ioaddr);
 		break;

Signature · 4 lines

1.5.3.3

-- 
Ueimor

Hans-Jürgen Koch

2007-11-08 07:53 UTC #15 lore raw

In reply to Mark Lord

Am Wed, 07 Nov 2007 11:07:07 -0500
schrieb Mark Lord <[email protected]>:

Quoted 46 lines

My ASUS board has one of these:
01:00.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL8111/8168B PCI Express Gigabit Ethernet controller (rev 01)
Subsystem: ASUSTeK Computer Inc. Unknown device 81aa Control: I/O+ Mem+ BusMaster- SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast
Quoted 2 lines
TAbort- <TAbort- <MAbort- >SERR- <PERR- Interrupt: pin A routed to IRQ 16 Region 0: I/O ports at 9800 [size=256]
Region 2: Memory at ff3ff000 (64-bit, non-prefetchable)
[size=4K] Expansion ROM at ff3c0000 [disabled] [size=128K]
Capabilities: [40] 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: [48] Vital Product Data
Capabilities: [50] Message Signalled Interrupts: Mask- 64bit+
Queue=0/1 Enable- Address: 0000000000000000 Data: 0000
Capabilities: [60] Express Endpoint IRQ 0
Device: Supported: MaxPayload 1024 bytes, PhantFunc
0, ExtTag+ Device: Latency L0s <1us, L1 unlimited
Device: AtnBtn+ AtnInd+ PwrInd+
Device: Errors: Correctable- Non-Fatal- Fatal-
Unsupported- Device: RlxdOrd+ ExtTag- PhantFunc- AuxPwr- NoSnoop+
Device: MaxPayload 128 bytes, MaxReadReq 4096 bytes
Link: Supported Speed 2.5Gb/s, Width x4, ASPM L0s,
Port 0 Link: Latency L0s unlimited, L1 unlimited
Link: ASPM Disabled RCB 64 bytes CommClk+ ExtSynch-
Link: Speed 2.5Gb/s, Width x1
Capabilities: [84] Vendor Specific Information
It works perfectly in 2.6.23.
It does not work in 2.6.24-rc2. Dunno about -rc1 or earlier -git*.
Without CONFIG_PCI_MSI, it works slightly, enough to ping it a couple of times, but it then dies when used for anything real:
	r8169 Gigabit Ethernet driver 2.2LK loaded
	r8169 0000:01:00.0: no MSI. Back to INTx.
	...
	eth0: RTL8168b/8111b at 0xf884a000, 00:17:31:64:e0:bc, XID
30000000 IRQ 16 ...
	r8169: eth0: link up
	...
	kernel: NETDEV WATCHDOG: eth0: transmit timed out
	r8169: eth0: link up
	...

Quoted 1 line

Not usable from this point on.

Same problem here with a MSI K9AGM2 board. The problem appeared in 2.6.24-rc1 (http://bugzilla.kernel.org/show_bug.cgi?id=9257).

It seems to be better in -rc2, at least the chip is detected again. I can assign an IP to that interface and bring it up, but no data traffic is possible. After some tests in both directions, ifconfig reports 157.6 KiB RX bytes, but TX bytes is 0, so sent packets seem to disappear quite early.

Thanks,
Hans

Hans-Jürgen Koch

2007-11-08 08:45 UTC #16 lore raw

Am Thu, 8 Nov 2007 08:52:56 +0100
schrieb Hans-Jürgen Koch <[email protected]>:

Quoted 51 lines

Am Wed, 07 Nov 2007 11:07:07 -0500
schrieb Mark Lord <[email protected]>:
Quoted 46 lines
My ASUS board has one of these:
01:00.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL8111/8168B PCI Express Gigabit Ethernet controller (rev 01)
Subsystem: ASUSTeK Computer Inc. Unknown device 81aa Control: I/O+ Mem+ BusMaster- SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast
Quoted 2 lines
TAbort- <TAbort- <MAbort- >SERR- <PERR- Interrupt: pin A routed to IRQ 16 Region 0: I/O ports at 9800 [size=256]
Region 2: Memory at ff3ff000 (64-bit, non-prefetchable)
[size=4K] Expansion ROM at ff3c0000 [disabled] [size=128K]
Capabilities: [40] 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: [48] Vital Product Data
Capabilities: [50] Message Signalled Interrupts: Mask-
64bit+ Queue=0/1 Enable- Address: 0000000000000000 Data: 0000
Capabilities: [60] Express Endpoint IRQ 0
Device: Supported: MaxPayload 1024 bytes, PhantFunc
0, ExtTag+ Device: Latency L0s <1us, L1 unlimited
Device: AtnBtn+ AtnInd+ PwrInd+
Device: Errors: Correctable- Non-Fatal- Fatal-
Unsupported- Device: RlxdOrd+ ExtTag- PhantFunc- AuxPwr- NoSnoop+
Device: MaxPayload 128 bytes, MaxReadReq 4096 bytes
Link: Supported Speed 2.5Gb/s, Width x4, ASPM L0s,
Port 0 Link: Latency L0s unlimited, L1 unlimited
Link: ASPM Disabled RCB 64 bytes CommClk+ ExtSynch-
Link: Speed 2.5Gb/s, Width x1
Capabilities: [84] Vendor Specific Information
It works perfectly in 2.6.23.
It does not work in 2.6.24-rc2. Dunno about -rc1 or earlier -git*.
Without CONFIG_PCI_MSI, it works slightly, enough to ping it a couple of times, but it then dies when used for anything real:
	r8169 Gigabit Ethernet driver 2.2LK loaded
	r8169 0000:01:00.0: no MSI. Back to INTx.
	...
	eth0: RTL8168b/8111b at 0xf884a000, 00:17:31:64:e0:bc, XID
30000000 IRQ 16 ...
	r8169: eth0: link up
	...
	kernel: NETDEV WATCHDOG: eth0: transmit timed out
	r8169: eth0: link up
	...
Quoted 1 line
Not usable from this point on.

Quoted 8 lines

Same problem here with a MSI K9AGM2 board. The problem appeared in 2.6.24-rc1 (http://bugzilla.kernel.org/show_bug.cgi?id=9257).
It seems to be better in -rc2, at least the chip is detected again. I can assign an IP to that interface and bring it up, but no data traffic is possible. After some tests in both directions, ifconfig reports 157.6 KiB RX bytes, but TX bytes is 0, so sent packets seem to disappear quite early.

The patch just submitted by Francois Romieu fixes the problem.

Thanks,
Hans

Hans-Jürgen Koch

Acked-by

2007-11-08 08:50 UTC #10 lore raw

Re: [PATCH] r8169 fix regression on ASUS motherboards (updated)

In reply to Francois Romieu

Am Thu, 8 Nov 2007 01:21:12 +0100
schrieb Francois Romieu <[email protected]>:

Quoted 14 lines

Mark Lord <[email protected]> :
[...]
Quoted 2 lines
I've now received a couple of private emails from people reporting full success with this patch.
Ok, I have pushed the patch below for Jeff to pull at korg.
Quoted 2 lines
From 1dd7681bc2ff171341ea5cae957f8ecb5c0c102e Mon Sep 17 00:00:00 2001
From: Mark Lord <[email protected]>
Date: Thu, 8 Nov 2007 01:03:04 +0100
Subject: [PATCH] r8169: revert 7da97ec96a0934319c7fbedd3d38baf533e20640 (partly)

Quoted 6 lines

Various symptoms depending on the .config options:
- the card stops working after some (short) time
- the card does not work at all
- the card disappears (nothing in lspci/dmesg)
A real power-off is needed to recover the card.

This patch fixes the same problem on my MSI board.

Quoted 3 lines

Signed-off-by Mark Lord <[email protected]>
Signed-off-by Francois Romieu <[email protected]>

Acked-by Hans J. Koch <[email protected]>

Quoted 16 lines

---
 drivers/net/r8169.c |    1 +
 1 files changed, 1 insertions(+), 0 deletions(-)

drivers/net/r8169.c +1 -0

index 9dbab3f..a37cf82 100644
@@ -1328,6 +1328,7 @@ static void rtl_hw_phy_config(struct net_device
 *dev) break;
 	case RTL_GIGA_MAC_VER_11:
 	case RTL_GIGA_MAC_VER_12:
+		break;
 	case RTL_GIGA_MAC_VER_17:
 		rtl8168b_hw_phy_config(ioaddr);
 		break;

Mark Lord

author

2007-11-08 14:16 UTC #11 lore raw

PATCH 1/1 r8169 fix regression on ASUS motherboards (updated again)

In reply to Francois Romieu

Quoted 26 lines · Francois Romieu

Ok, I have pushed the patch below for Jeff to pull at korg.
Quoted 1 line
From 1dd7681bc2ff171341ea5cae957f8ecb5c0c102e Mon Sep 17 00:00:00 2001
From: Mark Lord <[email protected]>
Date: Thu, 8 Nov 2007 01:03:04 +0100
Subject: [PATCH] r8169: revert 7da97ec96a0934319c7fbedd3d38baf533e20640 (partly)
Various symptoms depending on the .config options:
- the card stops working after some (short) time
- the card does not work at all
- the card disappears (nothing in lspci/dmesg)
A real power-off is needed to recover the card.
Signed-off-by Mark Lord <[email protected]>
Signed-off-by Francois Romieu <[email protected]>
---
 drivers/net/r8169.c |    1 +
 1 files changed, 1 insertions(+), 0 deletions(-)
drivers/net/r8169.c +0 -0
index 9dbab3f..a37cf82 100644

drivers/net/r8169.c static void rtl_hw_phy_config(struct net_device *dev) · line 1334

Quoted 7 lines

drivers/net/r8169.c +1 -0

@@ -1328,6 +1328,7 @@ static void rtl_hw_phy_config(struct net_device *dev)
 		break;
 	case RTL_GIGA_MAC_VER_11:
 	case RTL_GIGA_MAC_VER_12:
+		break;
 	case RTL_GIGA_MAC_VER_17:
 		rtl8168b_hw_phy_config(ioaddr);
 		break;

Stop the presses: Another person has now reported back to me. This guy has the VER_17 chip inside a notebook, and the same problem.

So the unified fix for all of these is to just get rid of rtl8168b_hw_phy_config(), as that code is all that is really different from 2.6.23 (where all is okay).

Updated patch below.

* * * * *

Fix r8169B regression on ASUS motherboards (and MSI, and..)

Third/final iteration.
This replaces the earlier versions of this patch. This one fixes *all* versions of r6169 *B* variant, restoring the init code back to what it was in 2.6.23.

The r8169 ethernet driver worked fine in 2.6.23, but fails in 2.6.24-rc* for the onboard ethernet of some ASUS (MAC_VER_11) and MSI (MAC_VER_12) motherboards, and also for some notebooks (MAC_VER_17) that use this chip.

Various symptoms depending on the .config options:
- the card stops working after some (short) time
- the card does not work at all
- the card disappears (nothing in lspci/dmesg)

A real power-off is needed to recover the card.

This patch fixes it again.

Signed-off-by Mark Lord <[email protected]>

drivers/net/r8169.c +0 -0

@@ -1247,13 +1247,6 @@

}
static void rtl8168b_hw_phy_config(void __iomem *ioaddr) {
- struct phy_reg phy_reg_init[] = {
- { 0x1f, 0x0000 },
- { 0x10, 0xf41b },
- { 0x1f, 0x0000 }
- };
-
- rtl_phy_write(ioaddr, phy_reg_init, ARRAY_SIZE(phy_reg_init));
}

static void rtl8168cp_hw_phy_config(void __iomem *ioaddr)

Francois Romieu

2007-11-08 21:08 UTC #12 lore raw

Re: [PATCH] r8169 fix regression on ASUS motherboards (updated again)

Mark Lord <[email protected]> :
[snip snip]

Quoted 9 lines

Stop the presses: Another person has now reported back to me. This guy has the VER_17 chip inside a notebook, and the same problem.
So the unified fix for all of these is to just get rid of rtl8168b_hw_phy_config(),
as that code is all that is really different from 2.6.23 (where all is okay).
Updated patch below.

Thanks. I'll push an update for it and probably a fix for a different annoyance before going to bed.

It will help future developments if you can convince the shadow man to send a few informations: I have no known tester for the VER_17 chip.

As a side note, people should really really really consider posting on [email protected] when reporting test results.

Signature · 1 line

Ueimor