r8169 MAC problem

r8169 MAC problem

[Tim Durack]

Looks like the r8169 MAC bug is still lurking:

CFG-1:~# uname -a
Linux CFG-1 2.6.29-rc7-686 #1 SMP Fri Mar 6 01:07:38 UTC 2009 i686 GNU/Linux

CFG-1:~# modprobe -r r8169
[  198.684076] r8169 0000:00:0c.0: PCI INT A disabled
[  198.944075] r8169 0000:00:0b.0: PCI INT A disabled
[  199.204080] r8169 0000:00:09.0: PCI INT A disabled

CFG-1:~# modprobe -i r8169
[  202.183521] r8169 Gigabit Ethernet driver 2.3LK-NAPI loaded
[  202.189230] r8169 0000:00:09.0: PCI INT A -> GSI 18 (level, low) -> IRQ 18
[  202.197440] r8169 0000:00:09.0: no PCI Express capability
[  202.203116] r8169 0000:00:09.0: MAC address found in EEPROM:
00:30:18:ab:f0:34
[  202.212721] eth0: RTL8169sc/8110sc at 0xf90b0000,
00:00:00:00:f0:34, XID 18000000 IRQ 18
[  202.221555] r8169 Gigabit Ethernet driver 2.3LK-NAPI loaded
[  202.227202] r8169 0000:00:0b.0: PCI INT A -> GSI 19 (level, low) -> IRQ 19
[  202.234202] r8169 0000:00:0b.0: no PCI Express capability
[  202.239859] r8169 0000:00:0b.0: MAC address found in EEPROM:
00:30:18:ab:f0:35
[  202.249413] eth1: RTL8169sc/8110sc at 0xf8012000,
00:00:00:00:f0:35, XID 18000000 IRQ 19
[  202.258267] r8169 Gigabit Ethernet driver 2.3LK-NAPI loaded
[  202.263911] r8169 0000:00:0c.0: PCI INT A -> GSI 16 (level, low) -> IRQ 16
[  202.270890] r8169 0000:00:0c.0: no PCI Express capability
[  202.276551] r8169 0000:00:0c.0: MAC address found in EEPROM:
00:30:18:ab:f0:36
[  202.286256] eth2: RTL8169sc/8110sc at 0xf8016000,
00:30:18:ab:f0:36, XID 18000000 IRQ 16

This obviously doesn't work very well. Full power-cycle back into
2.6.26 fixes the problem:

CFG-1:~# uname -a
Linux CFG-1 2.6.26-1-686 #1 SMP Sun Feb 8 02:27:05 UTC 2009 i686 GNU/Linux

CFG-1:~# modprobe -r r8169
[   83.220122] ACPI: PCI interrupt for device 0000:00:0c.0 disabled
[   83.252673] ACPI: PCI interrupt for device 0000:00:0b.0 disabled
[   83.285249] ACPI: PCI interrupt for device 0000:00:09.0 disabled

CFG-1:~# modprobe -i r8169
[   87.454505] r8169 Gigabit Ethernet driver 2.2LK-NAPI loaded
[   87.461284] ACPI: PCI Interrupt 0000:00:09.0[A] ->  a future
releasGSI 18 (level, low) -> IRQ 18
[   87.476007] eth0: RTL8169sc/8110sc at 0xf8832000,
00:30:18:ab:f0:34, XID 18000000 IRQ 18
[   87.484682] r8169 Gigabit Ethernet driver 2.2LK-NAPI loaded
[   87.489660] ACPI: PCI Interrupt 0000:00:0b.0[A] -> GSI 19 (level,
low) -> IRQ 19
[   87.500006] eth1: RTL8169sc/8110sc at 0xf8834000,
00:30:18:ab:f0:35, XID 18000000 IRQ 19
[   87.508675] r8169 Gigabit Ethernet driver 2.2LK-NAPI loaded
[   87.513633] ACPI: PCI Interrupt 0000:00:0c.0[A] -> GSI 16 (level,
low) -> IRQ 16
[   87.524006] eth2: RTL8169sc/8110sc at 0xf8f88000,
00:30:18:ab:f0:36, XID 18000000 IRQ 16

Based on googling around, I'm going to guess this might be related:

Ivan Vecera (1): r8169: read MAC address from EEPROM on init (2nd attempt)

Any ideas?

Tim:>

Re: r8169 MAC problem

[Francois Romieu]

Please Cc: Ivan.

Tim Durack <tdurack@gmail.com> :
[...]
> Any ideas?

Damn me, I should have noticed that the delay was below spec :o(

Can you try the patch below on top of the current git kernel ?

diff --git a/drivers/net/r8169.c b/drivers/net/r8169.c
index b347340..dfd42db 100644
--- a/drivers/net/r8169.c
+++ b/drivers/net/r8169.c
@@ -1970,9 +1970,14 @@ static const struct net_device_ops rtl8169_netdev_ops = {
 };
 
 /* Delay between EEPROM clock transitions. Force out buffered PCI writes. */
-#define RTL_EEPROM_DELAY()	RTL_R8(Cfg9346)
 #define RTL_EEPROM_READ_CMD	6
 
+static void rtl_eeprom_delay(void __iomem *ioaddr)
+{
+	RTL_R8(Cfg9346);
+	ndelay(450);
+}
+
 /* read 16bit word stored in EEPROM. EEPROM is addressed by words. */
 static u16 rtl_eeprom_read(void __iomem *ioaddr, int addr)
 {
@@ -1992,7 +1997,7 @@ static u16 rtl_eeprom_read(void __iomem *ioaddr, int addr)
 
 	/* enter programming mode */
 	RTL_W8(Cfg9346, Cfg9346_Program | Cfg9346_EECS);
-	RTL_EEPROM_DELAY();
+	rtl_eeprom_delay(ioaddr);
 
 	/* write command and requested address */
 	while (cmd_len--) {
@@ -2002,29 +2007,29 @@ static u16 rtl_eeprom_read(void __iomem *ioaddr, int addr)
 
 		/* write a bit */
 		RTL_W8(Cfg9346, x);
-		RTL_EEPROM_DELAY();
+		rtl_eeprom_delay(ioaddr);
 
 		/* raise clock */
 		RTL_W8(Cfg9346, x | Cfg9346_EESK);
-		RTL_EEPROM_DELAY();
+		rtl_eeprom_delay(ioaddr);
 	}
 
 	/* lower clock */
 	RTL_W8(Cfg9346, Cfg9346_Program | Cfg9346_EECS);
-	RTL_EEPROM_DELAY();
+	rtl_eeprom_delay(ioaddr);
 
 	/* read back 16bit value */
 	for (i = 16; i > 0; i--) {
 		/* raise clock */
 		RTL_W8(Cfg9346, Cfg9346_Program | Cfg9346_EECS | Cfg9346_EESK);
-		RTL_EEPROM_DELAY();
+		rtl_eeprom_delay(ioaddr);
 
 		result <<= 1;
 		result |= (RTL_R8(Cfg9346) & Cfg9346_EEDO) ? 1 : 0;
 
 		/* lower clock */
 		RTL_W8(Cfg9346, Cfg9346_Program | Cfg9346_EECS);
-		RTL_EEPROM_DELAY();
+		rtl_eeprom_delay(ioaddr);
 	}
 
 	RTL_W8(Cfg9346, Cfg9346_Program);
-- 
Ueimor

Re: r8169 MAC problem

[Tim Durack]

On Fri, Mar 6, 2009 at 3:05 PM, Francois Romieu <romieu@fr.zoreil.com> wrote:
> Please Cc: Ivan.
>
> Tim Durack <tdurack@gmail.com> :
> [...]
>> Any ideas?
>
> Damn me, I should have noticed that the delay was below spec :o(
>
> Can you try the patch below on top of the current git kernel ?

Patch didn't apply cleanly, so I did it by hand.

My kernel patch/compile skills are a little rusty, so I'm still in the
process of testing...

Tim:>

Re: r8169 MAC problem

[Ivan Vecera]

Francois Romieu wrote:
> Please Cc: Ivan.
> 
> Tim Durack <tdurack@gmail.com> :
> [...]
>> Any ideas?
> 
> Damn me, I should have noticed that the delay was below spec :o(
Francois, you are right, but IMHO there is no problem with reading of MAC from
EEPROM (see log... "MAC address found...") but there is a problem with assignment
of this MAC.
Interesting is that Tim's eth0 and eth1 are affected but eth2 is working well
thought all of them have the same XID. Maybe some delay after leaving of programming
mode could help.

Ivan
> 
> Can you try the patch below on top of the current git kernel ?
> 
> diff --git a/drivers/net/r8169.c b/drivers/net/r8169.c
> index b347340..dfd42db 100644
> --- a/drivers/net/r8169.c
> +++ b/drivers/net/r8169.c
> @@ -1970,9 +1970,14 @@ static const struct net_device_ops rtl8169_netdev_ops = {
>  };
>  
>  /* Delay between EEPROM clock transitions. Force out buffered PCI writes. */
> -#define RTL_EEPROM_DELAY()	RTL_R8(Cfg9346)
>  #define RTL_EEPROM_READ_CMD	6
>  
> +static void rtl_eeprom_delay(void __iomem *ioaddr)
> +{
> +	RTL_R8(Cfg9346);
> +	ndelay(450);
> +}
> +
>  /* read 16bit word stored in EEPROM. EEPROM is addressed by words. */
>  static u16 rtl_eeprom_read(void __iomem *ioaddr, int addr)
>  {
> @@ -1992,7 +1997,7 @@ static u16 rtl_eeprom_read(void __iomem *ioaddr, int addr)
>  
>  	/* enter programming mode */
>  	RTL_W8(Cfg9346, Cfg9346_Program | Cfg9346_EECS);
> -	RTL_EEPROM_DELAY();
> +	rtl_eeprom_delay(ioaddr);
>  
>  	/* write command and requested address */
>  	while (cmd_len--) {
> @@ -2002,29 +2007,29 @@ static u16 rtl_eeprom_read(void __iomem *ioaddr, int addr)
>  
>  		/* write a bit */
>  		RTL_W8(Cfg9346, x);
> -		RTL_EEPROM_DELAY();
> +		rtl_eeprom_delay(ioaddr);
>  
>  		/* raise clock */
>  		RTL_W8(Cfg9346, x | Cfg9346_EESK);
> -		RTL_EEPROM_DELAY();
> +		rtl_eeprom_delay(ioaddr);
>  	}
>  
>  	/* lower clock */
>  	RTL_W8(Cfg9346, Cfg9346_Program | Cfg9346_EECS);
> -	RTL_EEPROM_DELAY();
> +	rtl_eeprom_delay(ioaddr);
>  
>  	/* read back 16bit value */
>  	for (i = 16; i > 0; i--) {
>  		/* raise clock */
>  		RTL_W8(Cfg9346, Cfg9346_Program | Cfg9346_EECS | Cfg9346_EESK);
> -		RTL_EEPROM_DELAY();
> +		rtl_eeprom_delay(ioaddr);
>  
>  		result <<= 1;
>  		result |= (RTL_R8(Cfg9346) & Cfg9346_EEDO) ? 1 : 0;
>  
>  		/* lower clock */
>  		RTL_W8(Cfg9346, Cfg9346_Program | Cfg9346_EECS);
> -		RTL_EEPROM_DELAY();
> +		rtl_eeprom_delay(ioaddr);
>  	}
>  
>  	RTL_W8(Cfg9346, Cfg9346_Program);

Re: r8169 MAC problem

[Tim Durack]

On Mon, Mar 9, 2009 at 4:56 AM, Ivan Vecera <ivecera@redhat.com> wrote:
> Francois Romieu wrote:
>> Please Cc: Ivan.
>>
>> Tim Durack <tdurack@gmail.com> :
>> [...]
>>> Any ideas?
>>
>> Damn me, I should have noticed that the delay was below spec :o(
> Francois, you are right, but IMHO there is no problem with reading of MAC from
> EEPROM (see log... "MAC address found...") but there is a problem with assignment
> of this MAC.
> Interesting is that Tim's eth0 and eth1 are affected but eth2 is working well
> thought all of them have the same XID. Maybe some delay after leaving of programming
> mode could help.
>
> Ivan

Even on a "working" 2.6.26 I get strange behaviour with a modprobe -r/-i cycle:

CFG-1:~# ip link sh
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 16436 qdisc noqueue state UNKNOWN
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
2: eth0: <BROADCAST,MULTICAST,SLAVE,UP,LOWER_UP> mtu 1500 qdisc
pfifo_fast master bond0 state UNKNOWN qlen 1000
    link/ether 00:30:18:ab:f0:34 brd ff:ff:ff:ff:ff:ff
3: eth1: <BROADCAST,MULTICAST,SLAVE,UP,LOWER_UP> mtu 1500 qdisc
pfifo_fast master bond0 state UNKNOWN qlen 1000
    link/ether 00:30:18:ab:f0:35 brd ff:ff:ff:ff:ff:ff
4: eth2: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN qlen 1000
    link/ether 00:30:18:ab:f0:36 brd ff:ff:ff:ff:ff:ff
5: eth3: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN qlen 1000
    link/ether 00:30:18:a6:e7:de brd ff:ff:ff:ff:ff:ff
6: bond0: <BROADCAST,MULTICAST,MASTER,UP,LOWER_UP> mtu 1500 qdisc
noqueue state UP
    link/ether 00:30:18:ab:f0:34 brd ff:ff:ff:ff:ff:ff
7: bond0.16@bond0: <BROADCAST,MULTICAST,MASTER,UP,LOWER_UP> mtu 1500
qdisc noqueue state UP
    link/ether 00:30:18:ab:f0:34 brd ff:ff:ff:ff:ff:ff

CFG-1:~# ifdown bond0
Removed VLAN -:bond0.16:-
[   42.761683] bonding: bond0: Removing slave eth1
[   42.766343] bonding: bond0: releasing active interface eth1
[   42.787895] bonding: bond0: Removing slave eth0
[   42.791401] bonding: bond0: releasing active interface eth0

CFG-1:~# modprobe -r r8169
[   47.872121] ACPI: PCI interrupt for device 0000:00:0c.0 disabled
[   47.904198] ACPI: PCI interrupt for device 0000:00:0b.0 disabled
[   47.937215] ACPI: PCI interrupt for device 0000:00:09.0 disabled

B-25-1NOC-CFG-1:~# modprobe -i r8169
[   51.570902] r8169 Gigabit Ethernet driver 2.2LK-NAPI loaded
[   51.577122] ACPI: PCI Interrupt 0000:00:09.0[A] -> GSI 18 (level,
low) -> IRQ 18
[   51.592008] eth0: RTL8169sc/8110sc at 0xf8832000,
00:00:00:00:f0:34, XID 18000000 IRQ 18
[   51.600737] r8169 Gigabit Ethernet driver 2.2LK-NAPI loaded
e.
[   51.606996] ACPI: PCI Interrupt 0000:00:0b.0[A] -> GSI 19 (level,
low) -> IRQ 19
[   51.616772] eth1: RTL8169sc/8110sc at 0xf8834000,
00:00:00:00:f0:35, XID 18000000 IRQ 19
[   51.625557] r8169 Gigabit Ethernet driver 2.2LK-NAPI loaded
[   51.631198] ACPI: PCI Interrupt 0000:00:0c.0[A] -> GSI 16 (level,
low) -> IRQ 16
[   51.640850] eth2: RTL8169sc/8110sc at 0xf8f80000,
00:30:18:ab:f0:36, XID 18000000 IRQ 16

CFG-1:~# ip link sh
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 16436 qdisc noqueue state UNKNOWN
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
5: eth3: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN qlen 1000
    link/ether 00:30:18:a6:e7:de brd ff:ff:ff:ff:ff:ff
6: bond0: <BROADCAST,MULTICAST,MASTER> mtu 1500 qdisc noqueue state DOWN
    link/ether 00:00:00:00:00:00 brd ff:ff:ff:ff:ff:ff
8: eth0: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN qlen 1000
    link/ether 00:00:00:00:f0:34 brd ff:ff:ff:ff:ff:ff
9: eth1: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN qlen 1000
    link/ether 00:00:00:00:f0:35 brd ff:ff:ff:ff:ff:ff
10: eth2: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN qlen 1000
    link/ether 00:30:18:ab:f0:36 brd ff:ff:ff:ff:ff:ff

Requires a full power cycle to recover.

Tim:>