* r8169 MAC problem [not found] <9e246b4d0903061127q7c82103dq88c5184765f3c17a@mail.gmail.com> @ 2009-03-06 19:29 ` Tim Durack 2009-03-06 20:05 ` Francois Romieu 0 siblings, 1 reply; 5+ messages in thread From: Tim Durack @ 2009-03-06 19:29 UTC (permalink / raw) To: linux-kernel; +Cc: netdev, Francois Romieu 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:> ^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: r8169 MAC problem 2009-03-06 19:29 ` r8169 MAC problem Tim Durack @ 2009-03-06 20:05 ` Francois Romieu 2009-03-07 14:48 ` Tim Durack 2009-03-09 8:56 ` Ivan Vecera 0 siblings, 2 replies; 5+ messages in thread From: Francois Romieu @ 2009-03-06 20:05 UTC (permalink / raw) To: Tim Durack; +Cc: linux-kernel, netdev, Ivan Vecera 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 ^ permalink raw reply related [flat|nested] 5+ messages in thread
* Re: r8169 MAC problem 2009-03-06 20:05 ` Francois Romieu @ 2009-03-07 14:48 ` Tim Durack 2009-03-09 8:56 ` Ivan Vecera 1 sibling, 0 replies; 5+ messages in thread From: Tim Durack @ 2009-03-07 14:48 UTC (permalink / raw) To: Francois Romieu; +Cc: linux-kernel, netdev, Ivan Vecera 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:> ^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: r8169 MAC problem 2009-03-06 20:05 ` Francois Romieu 2009-03-07 14:48 ` Tim Durack @ 2009-03-09 8:56 ` Ivan Vecera 2009-03-09 13:27 ` Tim Durack 1 sibling, 1 reply; 5+ messages in thread From: Ivan Vecera @ 2009-03-09 8:56 UTC (permalink / raw) To: Francois Romieu; +Cc: Tim Durack, linux-kernel, netdev 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); ^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: r8169 MAC problem 2009-03-09 8:56 ` Ivan Vecera @ 2009-03-09 13:27 ` Tim Durack 0 siblings, 0 replies; 5+ messages in thread From: Tim Durack @ 2009-03-09 13:27 UTC (permalink / raw) To: Ivan Vecera; +Cc: Francois Romieu, linux-kernel, netdev 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:> ^ permalink raw reply [flat|nested] 5+ messages in thread
end of thread, other threads:[~2009-03-09 13:27 UTC | newest]
Thread overview: 5+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
[not found] <9e246b4d0903061127q7c82103dq88c5184765f3c17a@mail.gmail.com>
2009-03-06 19:29 ` r8169 MAC problem Tim Durack
2009-03-06 20:05 ` Francois Romieu
2009-03-07 14:48 ` Tim Durack
2009-03-09 8:56 ` Ivan Vecera
2009-03-09 13:27 ` Tim Durack
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).