Possibly related to: http://bugs.gentoo.org/show_bug.cgi?id=229315 http://lkml.org/lkml/2008/4/17/298 We're seeing a but with Intel Atom (D945GCLF) systems with R8102-E NICs (driver is r8169) where via PXE boot they will grab kernel just fine from TFTP server, however when they come to DHCP lease to mount NFS root filesystem, it fails. [ 13.792600] r8169: eth0: link up [ 14.801649] Sending DHCP requests ...<7>eth0: no IPv6 routers present [ 30.940638] ... timed out! [ 101.922419] IP-Config: Retrying forever (NFS root)... Interestingly enough an older git-sources from ~5-6 weeks ago compiled for x86 works just dandy, with almost identical configuration (32bit vs. 64bit only). About to proceed and test stable kernel (2.6.25-r7) and will build a new gentoo-sources ~arch kernel for x86 and see if that works ~6 weeks on now .26 is out! Any thoughts? I'll attach boot log, kernel config and other bits in a moment. Alex
Created attachment 161288 [details] kernel configuration, gentoo-sources-2.6.26, amd64 Kernel configuration which fails.
Created attachment 161290 [details] boot log boot sequence for working 2.6.26-rc6 kernel, built a few weeks ago
Created attachment 161292 [details] failing boot sequence, amd64 Boot sequence for kernel config (amd64) attached earlier. Fails.
Created attachment 161294 [details] config-2.6.26-rc6 which seems to work just dandy. git-sources
(In reply to comment #4) > Created an attachment (id=161294) [edit] > config-2.6.26-rc6 which seems to work just dandy. git-sources This is x86 though and I'm trying to fix amd64 to work for me :)
Created attachment 161299 [details] latest amd64 stable kernel, configuration
Created attachment 161301 [details] latest amd64 stable kernel, boot sequence This also fails :(
Created attachment 161306 [details] gentoo-sources-2.6.26 x86 kernel config Just to confirm this wasn't git-sources related, this is a x86 kernel config for the latest available gentoo-sources and associated boot sequence log. Works just fine and dandy. Something with amd64 is "fscked" :(
Created attachment 161307 [details] gentoo-sources-2.6.26 x86 boot sequence This is what I *expect* to happen!
Oh, also worth mentioning I've tried vanilla kernel sources (2.6.25 and 2.6.26) too and I get identical problems; on amd64 it fails and on x86 it works. Therefore I surmise this was not introduced by a gentoo-sources patch, and will probably need to be raised as a bug with upstream at some point? Not posting configs and boot logs for vanilla as its pointless :)
http://git.kernel.org/?p=linux/kernel/git/stable/linux-2.6.25.y.git;a=commit;h=fa5c104c2465470dc316bf211257f9e67e0ba602 http://git.kernel.org/?p=linux/kernel/git/stable/linux-2.6.25.y.git;a=commit;h=05d5b6cf37de1a9ceb873b770de113861a5b3df9 Tried both of these plus a more general one from Ubuntu: --- linux-2.6.24.orig/drivers/net/r8169.c +++ linux-2.6.24/drivers/net/r8169.c @@ -1139,6 +1139,10 @@ { 0x7cf00000, 0x34000000, RTL_GIGA_MAC_VER_13 }, { 0x7cf00000, 0x34200000, RTL_GIGA_MAC_VER_16 }, { 0x7c800000, 0x34000000, RTL_GIGA_MAC_VER_16 }, + /* 8102EL */ + { 0x7c800000, 0x24800000, RTL_GIGA_MAC_VER_16 }, + /* 8102E */ + { 0x7c800000, 0x34800000, RTL_GIGA_MAC_VER_16 }, /* FIXME: where did these entries come from ? -- FR */ { 0xfc800000, 0x38800000, RTL_GIGA_MAC_VER_15 }, { 0xfc800000, 0x30800000, RTL_GIGA_MAC_VER_14 }, @@ -1299,6 +1303,21 @@ rtl_phy_write(ioaddr, phy_reg_init, ARRAY_SIZE(phy_reg_init)); } +static void rtl8101_hw_phy_config(void __iomem *ioaddr) +{ + struct phy_reg phy_reg_init[] = { + { 0x1f, 0x0000 }, + { 0x11, mdio_read(ioaddr,0x11) | 0x1000 }, + { 0x19, mdio_read(ioaddr,0x19) | 0x2000 }, + { 0x1f, 0x0003 }, + { 0x08, 0x441D }, + { 0x01, 0x9100 }, + { 0x1f, 0x0000 } + }; + + rtl_phy_write(ioaddr, phy_reg_init, ARRAY_SIZE(phy_reg_init)); +} + static void rtl_hw_phy_config(struct net_device *dev) { struct rtl8169_private *tp = netdev_priv(dev); @@ -1316,6 +1335,9 @@ case RTL_GIGA_MAC_VER_04: rtl8169sb_hw_phy_config(ioaddr); break; + case RTL_GIGA_MAC_VER_13: + case RTL_GIGA_MAC_VER_16: + rtl8101_hw_phy_config(ioaddr); case RTL_GIGA_MAC_VER_18: rtl8168cp_hw_phy_config(ioaddr); break; @@ -1438,8 +1460,11 @@ rtl_hw_phy_config(dev); - dprintk("Set MAC Reg C+CR Offset 0x82h = 0x01h\n"); - RTL_W8(0x82, 0x01); + if (tp->mac_version != RTL_GIGA_MAC_VER_13 && tp->mac_version != RTL_GIGA_MAC_VER_16) + { + dprintk("Set MAC Reg C+CR Offset 0x82h = 0x01h\n"); + RTL_W8(0x82, 0x01); + } pci_write_config_byte(tp->pci_dev, PCI_LATENCY_TIMER, 0x40); @@ -1617,6 +1642,7 @@ SET_NETDEV_DEV(dev, &pdev->dev); tp = netdev_priv(dev); tp->dev = dev; + tp->pci_dev = pdev; tp->msg_enable = netif_msg_init(debug.msg_enable, R8169_MSG_DEFAULT); /* enable device (incl. PCI PM wakeup and hotplug setup) */ @@ -1776,8 +1802,14 @@ dev->poll_controller = rtl8169_netpoll; #endif + /* Ubuntu temporary workaround for bug #76489, disable + * NETIF_F_TSO by default for RTL8111/8168B chipsets. + * People can re-enable if required */ + if (tp->mac_version == RTL_GIGA_MAC_VER_11 + || tp->mac_version == RTL_GIGA_MAC_VER_12) + dev->features &= ~NETIF_F_TSO; + tp->intr_mask = 0xffff; - tp->pci_dev = pdev; tp->mmio_addr = ioaddr; tp->align = cfg->align; tp->hw_start = cfg->hw_start; No fix so far :) They all apply "fairly" cleanly to 2.6.26 and don't cause any compile/boot issues but the DHCP issue remains with amd64 and not x86.
Bug filed upstream at request of dsd.
Thanks, Alex, I've added the kernel alias to the upstream bug for tracking. Hopefully, those patches work for you and we'll have something to backport for .26.
