Summary: | Intel D945GCLF NIC Failure w/ gentoo-sources-2.6.26 | ||
---|---|---|---|
Product: | Gentoo Linux | Reporter: | Alex Howells <alex> |
Component: | [OLD] Core system | Assignee: | Gentoo Kernel Bug Wranglers and Kernel Maintainers <kernel> |
Status: | RESOLVED UPSTREAM | ||
Severity: | normal | CC: | momesso.andrea |
Priority: | Normal | ||
Version: | 2008.0 | ||
Hardware: | AMD64 | ||
OS: | Linux | ||
URL: | http://bugzilla.kernel.org/show_bug.cgi?id=11157 | ||
Whiteboard: | upstream | ||
Package list: | Runtime testing required: | --- | |
Attachments: |
kernel configuration, gentoo-sources-2.6.26, amd64
boot log failing boot sequence, amd64 config-2.6.26-rc6 which seems to work just dandy. git-sources latest amd64 stable kernel, configuration latest amd64 stable kernel, boot sequence gentoo-sources-2.6.26 x86 kernel config gentoo-sources-2.6.26 x86 boot sequence |
Description
Alex Howells
2008-07-24 17:37:40 UTC
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. |