Description of problem: Onboard gigabit ethernet driver not detected (Foxconn P55A-S motherboard) 03:00.0 Ethernet controller: Broadcom Corporate NetLink BCM57780 Gigabit Ethernet PCIe (rev 01) Version-Release number of selected component (if applicable): 2.6.30.5-43.fc11.x86_64 How reproducible: Always, reinstalled f11 3 times so far Steps to Reproduce: 1. Install f11 2. 3. Actual results: No ethernet interface created other than loopback Expected results: eth0 interface created and visible from ifconfig -a Additional info: None
What is the numeric ID of that adapter (from the command 'lspci -nn')?
03:00.0 Ethernet controller [0200]: Broadcom Corporation NetLink BCM57780 Gigabit Ethernet PCIe [14e4:1692] (rev 01)
It's in the list of devices for that driver. Does the command 'modprobe tg3' give any output? Is there anything in the logs about the tg3 driver failing to load?
[root@pc002 ~]# lsmod | grep tg3 tg3 110852 0 ------------------------------ [root@pc002 ~]# dmesg | grep -i tg3 tg3.c:v3.98 (February 25, 2009) tg3 0000:03:00.0: PCI INT A -> GSI 16 (level, low) -> IRQ 16 tg3 0000:03:00.0: setting latency timer to 64 tg3 0000:03:00.0: wake-up capability disabled by ACPI tg3 0000:03:00.0: PME# disabled tg3 mdio bus: probed tg3: Problem fetching invariants of chip, aborting. tg3 0000:03:00.0: PCI INT A disabled ------------------------------ [root@pc002 ~]# cat /var/log/messages | grep -i tg3 Oct 6 09:40:32 pc002 kernel: tg3.c:v3.98 (February 25, 2009) Oct 6 09:40:32 pc002 kernel: tg3 0000:03:00.0: PCI INT A -> GSI 16 (level, low) -> IRQ 16 Oct 6 09:40:32 pc002 kernel: tg3 0000:03:00.0: wake-up capability disabled by ACPI Oct 6 09:40:32 pc002 kernel: tg3 0000:03:00.0: PME# disabled Oct 6 09:40:32 pc002 kernel: tg3 mdio bus: probed Oct 6 09:40:32 pc002 kernel: tg3: Problem fetching invariants of chip, aborting. Oct 6 09:40:32 pc002 kernel: tg3 0000:03:00.0: PCI INT A disabled Oct 7 17:41:06 pc002 kernel: tg3.c:v3.98 (February 25, 2009) Oct 7 17:41:06 pc002 kernel: tg3 0000:03:00.0: PCI INT A -> GSI 16 (level, low) -> IRQ 16 Oct 7 17:41:06 pc002 kernel: tg3 0000:03:00.0: wake-up capability disabled by ACPI Oct 7 17:41:06 pc002 kernel: tg3 0000:03:00.0: PME# disabled Oct 7 17:41:06 pc002 kernel: tg3 mdio bus: probed Oct 7 17:41:06 pc002 kernel: tg3: Problem fetching invariants of chip, aborting. Oct 7 17:41:06 pc002 kernel: tg3 0000:03:00.0: PCI INT A disabled Oct 8 18:11:18 pc002 kernel: tg3.c:v3.98 (February 25, 2009) Oct 8 18:11:18 pc002 kernel: tg3 0000:03:00.0: PCI INT A -> GSI 16 (level, low) -> IRQ 16 Oct 8 18:11:18 pc002 kernel: tg3 0000:03:00.0: wake-up capability disabled by ACPI Oct 8 18:11:18 pc002 kernel: tg3 0000:03:00.0: PME# disabled Oct 8 18:11:18 pc002 kernel: tg3 mdio bus: probed Oct 8 18:11:18 pc002 kernel: tg3: Problem fetching invariants of chip, aborting. Oct 8 18:11:18 pc002 kernel: tg3 0000:03:00.0: PCI INT A disabled Oct 9 17:54:40 pc002 kernel: tg3.c:v3.98 (February 25, 2009) Oct 9 17:54:40 pc002 kernel: tg3 0000:03:00.0: PCI INT A -> GSI 16 (level, low) -> IRQ 16 Oct 9 17:54:40 pc002 kernel: tg3 0000:03:00.0: wake-up capability disabled by ACPI Oct 9 17:54:40 pc002 kernel: tg3 0000:03:00.0: PME# disabled Oct 9 17:54:40 pc002 kernel: tg3 mdio bus: probed Oct 9 17:54:40 pc002 kernel: tg3: Problem fetching invariants of chip, aborting. Oct 9 17:54:40 pc002 kernel: tg3 0000:03:00.0: PCI INT A disabled
Does the original 2.6.29 kernel from F-11 work? Also, is the latest BIOS installed?
Please attach the entire dmesg output from boot and the contents of /proc/iomem and /proc/ioports (separate plain-text attachments.)
I'm seeing exactly the same problem here. Dmesg output looks the same. I'm using a Lenovo IdeaPad U350 (tis a notebook).
Created attachment 365160 [details] complete dmesg
Created attachment 365161 [details] complete iomem
Created attachment 365162 [details] complete ioports
Partial solution: http://www.linlap.com/wiki/lenovo+ideapad+u350 As suggested there, inserting the broadcom module before tg3 makes things appear to load. But then an oops occurs.
Created attachment 365163 [details] loading broadcom before tg3; oops
Possibly fixed by commit 521e6b90d ("tg3: fix 57780 asic rev PCIe link receiver errors") in 2.6.32?
Nope. The bug will be fixed by commit 24bb4fb6dac59f220f42fb375ba0e0f19365a227 "tg3: Fix phylib locking strategy".
*** Bug 533524 has been marked as a duplicate of this bug. ***
So is this fix in rawhide? FC12 RC4?
I can confirm that this bug is currently still present in FC12 with full updates. kernel = 2.6.31.9-174.fc12.i686.PAE
John, the easy fix is just to pivot the tg3 driver to use the internal phy code over phylib for this device. I included this change in my recent patchset.
In the meantime, you can make the 57780 usable by unloading the tg3 driver, modprobing the broadcom.ko module, and then reloading the tg3 driver.
Happy to report that the workaround mentioned by Matt Carlson (#19) works for me. However this needs to be done on every boot, so it would be nice to see Matt's real fix pushed to F12 stable.
This bug is also present in FC12,which kernel is 2.6.31.12-174.2.3.fc12.i686.PAE. You can resolve this problem by modifying the file "/etc/rc.local". #!/bin/sh # # This script will be executed *after* all the other init scripts. # You can put your own initialization stuff in here if you don't # want to do the full Sys V style init stuff. touch /var/lock/subsys/local modprobe -r tg3 modprobe broadcom modprobe tg3
I can't solve this problem in the kernel 2.6.27
I have the BCM57782. It is detected but does not work...
I met the same problem with a Mandriva 2010.0 on a Dell Vostro 430 with this network card : Broadcom Corporation|NetLink BCM57780 Gigabit Ethernet PCIe Extract of the dmesg about it : ------------------------------------------------------------------- tg3.c:v3.99 (April 20, 2009) tg3 0000:02:00.0: PCI INT A -> GSI 16 (level, low) -> IRQ 16 tg3 0000:02:00.0: setting latency timer to 64 tg3 0000:02:00.0: PME# disabled tg3 mdio bus: probed eth%d: No PHY devices tg3: Problem fetching invariants of chip, aborting. tg3 0000:02:00.0: PCI INT A disabled ------------------------------------------------------------------- lspcidrake : ------------------------------------------------------------------- snd_hda_intel : Creative Labs|[SB X-Fi Xtreme Audio] CA0110-IBG (vendor:1102 device:0009 subv:1102 subd:0018) shpchp : Creative Labs|[SB X-Fi Xtreme Audio] CA0110-IBG PCI to PCIe Bridge [BRIDGE_PCI] (vendor:1102 device:7006) tg3 : Broadcom Corporation|NetLink BCM57780 Gigabit Ethernet PCIe [NETWORK_ETHERNET] (vendor:14e4 device:1692 subv:1028 subd:02ec) (rev: 01) snd_hda_intel : ATI Technologies Inc|R700 Audio Device [Radeon HD 4000 Series] (vendor:1002 device:aa38 subv:1028 subd:aa38) Card:ATI Radeon HD 2000 and later (radeon/fglrx): ATI Technologies Inc|RV710 [Radeon HD 4350] [DISPLAY_VGA] (vendor:1002 device:954f subv:1028 subd:904e) i2c_i801 : Intel Corporation|5 Series/3400 Series Chipset SMBus Controller [SERIAL_SMBUS] (vendor:8086 device:3b30 subv:1028 subd:02ec) (rev: 05) ahci : Intel Corporation|5 Series/3400 Series Chipset 6 port SATA AHCI Controller [STORAGE_SATA] (vendor:8086 device:3b22 subv:1028 subd:02ec) (rev: 05) unknown : Intel Corporation|5 Series Chipset LPC Interface Controller [BRIDGE_ISA] (vendor:8086 device:3b02 subv:1028 subd:02ec) (rev: 05) unknown : Intel Corporation|82801 PCI Bridge [BRIDGE_PCI] (vendor:8086 device:244e) (rev: a5) ehci_hcd : Intel Corporation|5 Series/3400 Series Chipset USB2 Enhanced Host Controller [SERIAL_USB] (vendor:8086 device:3b34 subv:1028 subd:02ec) (rev: 05) shpchp : Intel Corporation|5 Series/3400 Series Chipset PCI Express Root Port 4 [BRIDGE_PCI] (vendor:8086 device:3b48) (rev: 05) shpchp : Intel Corporation|5 Series/3400 Series Chipset PCI Express Root Port 1 [BRIDGE_PCI] (vendor:8086 device:3b42) (rev: 05) ehci_hcd : Intel Corporation|5 Series/3400 Series Chipset USB2 Enhanced Host Controller [SERIAL_USB] (vendor:8086 device:3b3c subv:1028 subd:02ec) (rev: 05) unknown : Intel Corporation|Core Processor QPI Routing and Protocol Registers [SYSTEM_OTHER] (vendor:8086 device:d151 subv:0028 subd:00ec) (rev: 11) unknown : Intel Corporation|Core Processor QPI Link [SYSTEM_OTHER] (vendor:8086 device:d150 subv:0028 subd:00ec) (rev: 11) unknown : Intel Corporation|Core Processor Miscellaneous Registers [SYSTEM_OTHER] (vendor:8086 device:d158 subv:0028 subd:00ec) (rev: 11) unknown : Intel Corporation|Core Processor System Control and Status Registers [SYSTEM_OTHER] (vendor:8086 device:d157 subv:0028 subd:00ec) (rev: 11) unknown : Intel Corporation|Core Processor Semaphore and Scratchpad Registers [SYSTEM_OTHER] (vendor:8086 device:d156 subv:0028 subd:00ec) (rev: 11) unknown : Intel Corporation|Core Processor System Management Registers [SYSTEM_OTHER] (vendor:8086 device:d155 subv:0028 subd:00ec) (rev: 11) shpchp : Intel Corporation|Core Processor PCI Express Root Port 1 [BRIDGE_PCI] (vendor:8086 device:d138) (rev: 11) unknown : Intel Corporation|Core Processor DMI [BRIDGE_HOST] (vendor:8086 device:d131 subv:1028 subd:02ec) (rev: 11) hub : Linux 2.6.31.5-server-1mnb ehci_hcd|EHCI Host Controller [Hub|Unused|Full speed (or root) hub] (vendor:1d6b device:0002) hub : Unknown|Unknown [Hub|Unused|Full speed (or root) hub] (vendor:8087 device:0020) usbhid : Dell|Dell USB Optical Mouse [Human Interface Device|Boot Interface Subclass|Mouse] (vendor:413c device:3012) usbhid : Dell|Dell QuietKey Keyboard [Human Interface Device|Boot Interface Subclass|Keyboard] (vendor:413c device:2106) hub : Linux 2.6.31.5-server-1mnb ehci_hcd|EHCI Host Controller [Hub|Unused|Full speed (or root) hub] (vendor:1d6b device:0002) hub : Unknown|Unknown [Hub|Unused|Full speed (or root) hub] (vendor:8087 device:0020) usb_storage : USB|Flash Disk [Mass Storage|SCSI|Bulk (Zip)] (vendor:090c device:1000) ------------------------------------------------------------------- To resolv it for the moment, i put this sentence at the end of the modprobe.conf : ------------------------------------------------------------------- install tg3 /sbin/modprobe broadcom; /sbin/modprobe --ignore-install tg3 -------------------------------------------------------------------
The 57782 is detected without writing something to /etc/rc.local, but does not work. kernel-PAE-2.6.31.12-174.2.3.fc12.i686
I can confirm that adding "install tg3 /sbin/modprobe broadcom; /sbin/modprobe --ignore-install tg3" to /etc/modprobe.d/local.conf has fixed it so the interface now is found and available at boot time.
Confirmed, ethernet card was not working out of the box on a FC12 Kernel 2.6.31.12-174.2.3.fc12.x86_64. After adding the commands to /etc/rc.local to load broadcom driver first, now works.
Please note that the latest updates in Fedora 12 don't fix this issue yet. Even though adding the abovementioned lines to /etc/rc.local does fix the drivers to some degree, this is not a satisfactory workaround. The /etc/rd.local file is only executed after all other services have already been started. However there are several services that require an enabled network device, including IP-address et cetera, which is not available at that time, even with this workaround. Also especially the dhcp-client is a bad case, since it won't immediately give an error, but wait for (almost) ever before finally timing out. I suppose on most systems the dhcp-client would immediately bail out, or not even be started since eth0 wouldn't come up to begin with. However in my setup, to facilitate virtualisation, I have eth0 in a bridge, and because of limitations of the bridge implementation in Linux, this makes is necessary to run the dhcp-client on the bridge device itself instead of on eth0. As an unwanted side-effect, this causes the dhcp-client to run regardless of whether or not the eth0 device is available. To cut a long story short, having eth0 available only as the final step in the boot process, is way to late, and causes a lot of troubles with booting. Is there another workaround that fixes this driver issue (way) earlier in the boot process? An actual bug fix would be great too ;)
The solution shown in comment 26 (adding "install tg3 /sbin/modprobe broadcom; /sbin/modprobe --ignore-install tg3" to /etc/modprobe.d/local.conf has fixed it so the interface now is found and available at boot time) works for me. IMHO, this is a better solution than the rc.local change...
This is a problem even with the rawhide kernel. Anyone working on it?
(In reply to comment #30) > This is a problem even with the rawhide kernel. Anyone working on it? Phil, I do not know of anyone actively working on the kernel portion. Until the necessary changes to the phy/mdio code are done upstream, you will need to use the workaround mentioned in comment #26. It simply indicates that you should add these lines: install tg3 /sbin/modprobe broadcom; /sbin/modprobe --ignore-install tg3 install skfp /sbin/modprobe marvell; /sbin/modprobe --ignore-install skfp to the end of /etc/modprobe.d/dist.conf.
> inserting the broadcom module before tg3 makes things > appear to load. But then an oops occurs. The "broadcom pre-load" workaround also caused various kernel oops with kernel 2.6.31.12-174.2.22.fc12.x86_64. Thanks to 2.6.32.9-70.fc12.x86_64 it now looks much more stable. However, even with the more recent kernel I still need to make sure that the tg3 driver is NEVER loaded before loading the broadcom driver. I mean: "rmmod tg3 && modprobe broadcom && modprobe tg3" is still causing kernel crashes. Tigon3 [partno(BCM57780) rev 57780001] lspci = 14e4:1692 (rev 01)
I haven't seen that before. Can you post the stack trace?
Created attachment 399687 [details] broadcom 2.6.32 kerneloopses (In reply to comment #33) > However, even with the more recent kernel I still need to make sure that the > tg3 driver is NEVER loaded before loading the broadcom driver. I mean: "rmmod > tg3 && modprobe broadcom && modprobe tg3" is still causing kernel crashes. Well, not exactly. I confused myself with too much random testing. At this moment the only reliable (!) way to oops the 2.6.32 kernel is to do something admittedly stupid: rmmod broadcom while tg3 is loaded. And then ifup/down the interface. I am pretty sure I have also seen oopses in more sensible use cases but cannot find which.
These kinds of problems should be caught and handled correctly though. When you did that, the stack trace shows the topmost function is phy_connect(), right?
(In reply to comment #36) > These kinds of problems should be caught and handled correctly though. I thought that the broadcom module should just be a hard dependency of the tg3 module, shouldn't it? > When you did that, the stack trace shows the topmost function is phy_connect(), > right? I do not see "phy_connect" in any of the three kerneloopses I attached. (In reply to comment #35) > Created an attachment (id=399687) [details] > broadcom 2.6.32 kerneloopses > > At this moment the only reliable (!) way to oops the 2.6.32 kernel is to do > something admittedly stupid: rmmod broadcom while tg3 is loaded. And then > ifup/down the interface. The corresponding oops is the one with "Process ifconfig pid: 2971" I think that the two other, extremely similar oopses attached were also caused by removing the broadcom module while the tg3 is loaded. And then doing something else like sleeping/waking up or letting NetworkManager fiddle with the interface. If you want a kerneloops in very well defined conditions just give them to me. Probably in private email; this bug is already quite noisy.
(In reply to comment #37) > > If you want a kerneloops in very well defined conditions just give them to me. > Probably in private email; this bug is already quite noisy. We don't mind the 'noise' at all (in fact we like it), so feel free to continue using this bug to track and diagnose the problem.
*** Bug 552672 has been marked as a duplicate of this bug. ***
Problem still exists in the latest F12 kernel. -John
(In reply to comment #37) > I thought that the broadcom module should just be a hard dependency of the tg3 > module, shouldn't it? To make a long story short, that isn't how phylib should work, but perhaps that is the best interim strategy to use until the correct solution is in place. This bug highlights the fact that phylib isn't really ready to take on module management capabilities. The phylib can either choose to tolerate module unloads like this, or it can do proper module management and lock phy modules into the kernel itself. Both solutions will require quite a bit of coding though. Making the broadcom module a hard dependency should lock the module in place implicitly. I'll have to bring this up on netdev. > > When you did that, the stack trace shows the topmost function is > > phy_connect(), right? > > I do not see "phy_connect" in any of the three kerneloopses I attached. Nope. You are right. The offending functions are phy_start() and phy_start_aneg(). Both of these fail because they are trying to dereference a NULL function pointer used by the phylib module. > If you want a kerneloops in very well defined conditions just give them to me. > Probably in private email; this bug is already quite noisy. This is good enough. Thanks.
Still broken in rawhide 2.6.33-0.44.rc8.git0.fc13.x86_64 and the current FC12 kernel 2.6.32.10-90.fc12.x86_64.
Matt, do you want to go with a possibly non-existent kernel patch or have Jon patch up module-init-tools with the lines discussed in comment #31?
MarcH can produce a kernel panic with the fix in comment #31 in place. I think the kernel patch is the only path that makes sense. This is the direction I will likely be taking the upstream driver too.
These patches should fix it: http://marc.info/?l=linux-netdev&m=126999834304330&w=1 http://marc.info/?l=linux-netdev&m=126999839404391&w=1
F12 scratch kernel build with these patches at http://koji.fedoraproject.org/koji/taskinfo?taskID=2086332 It now works on my shiny new Dell box.
How to test (install) this kernel without kernel-firmware?
Why would you install this kernel without kernel-firmware? If for some reason you don't want to install the kernel-firmware package that's part of the build I linked in comment #46, then just install the new kernel package with --nodeps.
Sorry about, i did't found it. Where is the kernel-firmware package?
(In reply to comment #49) > Sorry about, i did't found it. Where is the kernel-firmware package? kernel-firmware is in the noarch build: http://koji.fedoraproject.org/koji/taskinfo?taskID=2086335
Same with Dell Optiplex 780 onboard network card (BCM57780, 14e4:1692). I don't compile the tg3 as a module, but inside the kernel (PXE boot kernel) kernels tried: up to 2.6.34-rc3 with and without patches next-20100331/next-20100401 (32.1, 32.7, 32.9, 32.10, 33.1) 2.6.32.10 also patched with: - linux-2.6-tg3-netpoll.patch - tg3-05-assign-flags-to-fixes-in-start_xmit_dma_bug.patch - tg3-06-fix-5906-transmit-hangs.patch (From http://koji.fedoraproject.org/koji/taskinfo?taskID=2086332 ) All result in: tg3: Problem fetching invariants of chip, aborting
Kernel-2.6.32.10-94.fc12 does not wor for my Compaq Wireless LAN Multiport W200 (57782 / OnBoard USB).
(In reply to comment #45) > These patches should fix it: > http://marc.info/?l=linux-netdev&m=126999834304330&w=1 > http://marc.info/?l=linux-netdev&m=126999839404391&w=1 Those patches apparently only work with current -git. Could we get the patches you applied to build that F12 kernel? (can't seem to download the SRPM for it)
No, that machine is off right now. I could download the srpm from the above-linked koji build for you, or I could do the trivial changes again, but I don't feel like pandering to lazy people today. It's only a single line in each patch, iirc -- it's so simple you don't even need to re-diff it; just edit the patch by hand. Remove one line of context in the first patch which was added since 2.6.32, and remove (or change to hex) one PHY ID from the second so that it actually builds. C'mon people, try to do _something_ for yourselves.
Nice. Not being lazy here David, I have been trying to get the SRPM from koji myself for a couple days, but can't figure out how to download anything but the compiled rpms (I've never used the koji interface). Guess I'm an idiot, as it isn't readily apparent to me. Anyway, I'll keep plugging away at it and if I don't keel over due to my incredible stupidity eventually I'll figure it out, thanks.
(In reply to comment #55) I got the from this src.rpm: http://kojipkgs.fedoraproject.org/packages/kernel/2.6.32.10/94.fc12/src/kernel-2.6.32.10-94.fc12.src.rpm I patched a vanilla 2.6.32.10 with: - linux-2.6-tg3-netpoll.patch - tg3-05-assign-flags-to-fixes-in-start_xmit_dma_bug.patch - tg3-06-fix-5906-transmit-hangs.patch (all in the rpm) and compiled.. For me it didn't have any effect...
Denie - that is not the correct src rpm, nor the correct patches.
The srpms are always with the ppc binaries for some reason. http://koji.fedoraproject.org/koji/getfile?taskID=2086333&name=kernel-2.6.32.10-94.fc12.src.rpm
Aha! Thanks very much for the info...not sure I would have ever thought to look at the PPC binaries for the srpm.
Phils - Thanks for pointing that out, I mistaked as the name is identical, Sorry, my mistake. Applied the patches in the last link (ppc binaries for the x86 source) - 0001-phylib-Support-phy-module-autoloading.patch - 0002-phylib-Add-module-table-to-all-existing-phy-drivers.patch Retried, with modules and driver in kernel on both 2.6.32.10 and 2.6.34-rc3, still unable to use the onboard card. -------------- # dmesg: tg3.c:v3.108 (February 17, 2010) tg3 0000:02:00.0: found PCI INT A -> IRQ 11 tg3 0000:02:00.0: sharing IRQ 11 with 0000:00:01.0 tg3 0000:02:00.0: sharing IRQ 11 with 0000:00:02.0 tg3 0000:02:00.0: sharing IRQ 11 with 0000:00:1b.0 tg3 0000:02:00.0: sharing IRQ 11 with 0000:00:1c.0 tg3 0000:02:00.0: sharing IRQ 11 with 0000:00:1f.1 tg3 0000:02:00.0: setting latency timer to 64 tg3 mdio bus: probed tg3 0000:02:00.0: (unregistered net_device): No PHY devices tg3 0000:02:00.0: (unregistered net_device): Problem fetching invariants of chip, aborting -------------- #lspci -vvv -d 14e4:1692: 02:00.0 Class 0200: 14e4:1692 (rev 01) Subsystem: 1028:0400 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 11 Region 0: Memory at fe4f0000 (64-bit, non-prefetchable) [size=64K] Capabilities: [48] Power Management version 3 Flags: PMEClk- DSI- D1- D2- AuxCurrent=0mA PME(D0-,D1-,D2-,D3hot+,D3cold+) Status: D0 PME-Enable- DSel=0 DScale=1 PME- Capabilities: [60] #09 [006c] Capabilities: [50] Message Signalled Interrupts: 64bit+ Queue=0/0 Enable- Address: 44fbcf7ffbedefa8 Data: d878 Capabilities: [cc] #10 [0002] -------------- #grep 14e41692 /proc/bus/pci/devices 0200 14e41692 b fe4f0004 0 0 0 0 0 0 10000 0 0 0 0 0 0
Denie, is the broadcom.ko module loaded? Does it start working if you load that module before loading the tg3.ko module?
(In reply to comment #61) > Denie, is the broadcom.ko module loaded? Does it start working if you load that > module before loading the tg3.ko module? Yes ! Not it works. Both for 2.6.32.10 and 2.6.34-rc3 tg3.c:v3.108 (February 17, 2010) tg3 0000:02:00.0: found PCI INT A -> IRQ 11 tg3 0000:02:00.0: sharing IRQ 11 with 0000:00:01.0 tg3 0000:02:00.0: sharing IRQ 11 with 0000:00:02.0 tg3 0000:02:00.0: sharing IRQ 11 with 0000:00:1b.0 tg3 0000:02:00.0: sharing IRQ 11 with 0000:00:1c.0 tg3 0000:02:00.0: sharing IRQ 11 with 0000:00:1f.1 tg3 0000:02:00.0: setting latency timer to 64 tg3 mdio bus: probed tg3 0000:02:00.0: eth0: Tigon3 [partno(BCM57780) rev 57780001] (PCI Express) MAC address 00:25:64:bf:83:7b tg3 0000:02:00.0: eth0: attached PHY driver [Broadcom BCM57780] (mii_bus:phy_addr=200:01) tg3 0000:02:00.0: eth0: RXcsums[1] LinkChgREG[0] MIirq[0] ASF[0] TSOcap[1] tg3 0000:02:00.0: eth0: dma_rwctrl[76180000] dma_mask[64-bit] tg3 0000:02:00.0: eth0: Link is down tg3 0000:02:00.0: eth0: Link is up at 1000 Mbps, full duplex tg3 0000:02:00.0: eth0: Flow control is on for TX and on for RX
That probably means that you haven't applied the patches properly, or haven't installed the resulting kernel and modules properly. Can you try 'modinfo broadcom' -- does it have a bunch of aliases starting 'phy:' followed by 32 binary digits and question marks? Can you unload the broadcom.ko module, then try 'modprobe phy:00000011011000100101110110010001' and see if it gets loaded? Can you mv /sbin/modprobe to /sbin/modprobe.real and then make a shell script /sbin/modprobe which is executable and looks like this: #!/bin/sh logger -- modprobe "$@" /sbin/modprobe.real "$@" When the tg3 module gets loaded, do you see in /var/log/messages that the modprobe has happened? It should look something like... Apr 2 10:39:49 i7 kernel: tg3.c:v3.102 (September 1, 2009) Apr 2 10:39:49 i7 kernel: tg3 0000:05:00.0: PCI INT A -> GSI 17 (level, low) -> IRQ 17 Apr 2 10:39:49 i7 logger: modprobe -q -- phy:00000011011000100101110110010001 Apr 2 10:39:49 i7 kernel: tg3 mdio bus: probed Edit drivers/net/phy_device.c and immediately before the request_module() I added, add a printk("Loading "PHYID_FMT, PHYID_ARGS(phy_id));. Do you see that in dmesg?
Revised version of the patches (cosmetic fixes from upstream review) F12: http://koji.fedoraproject.org/koji/taskinfo?taskID=2090985 F13: http://koji.fedoraproject.org/koji/taskinfo?taskID=2090991
(In reply to comment #64) > Revised version of the patches (cosmetic fixes from upstream review) > > F12: http://koji.fedoraproject.org/koji/taskinfo?taskID=2090985 This kernel does not work for me... no wireless extension
Thanks David, these patches work for me on 2.6.33.x. One thing I noticed was this difference: -eth2: Tigon3 [partno(BCM95784M) rev 5784100] (PCI Express) MAC address 00:23:ae:83:52:e4 +eth2: Tigon3 [partno(none) rev 5784100] (PCI Express) MAC address 00:23:ae:83:52:e4 Note how partno is missing now. Not sure if this is relevant, or matters at all. Thanks again.
Thanks David, it works now prefectly On 20100406 I check it again, and will reply if anything fails.
Steve, I haven't changed anything to do with wireless; if it's really broken in this kernel, then it's broken in the F12 kernel in CVS already. Please test the 'real' 2.6.32.10-94.fc12 or later kernel from koji, and report any failure as a separate bug.
(In reply to comment #68) > Steve, I haven't changed anything to do with wireless; if it's really broken in > this kernel, then it's broken in the F12 kernel in CVS already. Please test the > 'real' 2.6.32.10-94.fc12 or later kernel from koji, and report any failure as a > separate bug. Aha, ok, will do that, thank you!
(In reply to comment #66) > Thanks David, these patches work for me on 2.6.33.x. One thing I noticed was > this difference: > > -eth2: Tigon3 [partno(BCM95784M) rev 5784100] (PCI Express) MAC address > 00:23:ae:83:52:e4 > +eth2: Tigon3 [partno(none) rev 5784100] (PCI Express) MAC address > 00:23:ae:83:52:e4 > > Note how partno is missing now. Not sure if this is relevant, or matters at > all. The change in the partno string shouldn't have anything to do with David's patch. For some reason, the driver is having trouble accessing the VPD region of the device. This change in behavior is benign though and does (or should) not otherwise affect the operation of the device.
David [Woodhouse], do you want to just take this bug and add your patch to CVS so that this is fixed until this hits in 2.6.35?
F-12: 2.6.32.11-103.fc12 http://koji.fedoraproject.org/koji/taskinfo?taskID=2115778 F-13: 2.6.33.2-47.fc13 http://koji.fedoraproject.org/koji/taskinfo?taskID=2115797
Thanks, David.
Um, make that http://koji.fedoraproject.org/koji/taskinfo?taskID=2115847 for the F-13 build.
kernel-2.6.33.2-57.fc13 has been submitted as an update for Fedora 13. http://admin.fedoraproject.org/updates/kernel-2.6.33.2-57.fc13
kernel-2.6.33.2-57.fc13 has been pushed to the Fedora 13 testing repository. If problems still persist, please make note of it in this bug report. If you want to test the update, you can install it with su -c 'yum --enablerepo=updates-testing update kernel'. You can provide feedback for this update here: http://admin.fedoraproject.org/updates/kernel-2.6.33.2-57.fc13
*** Bug 564283 has been marked as a duplicate of this bug. ***
kernel-2.6.33.2-57.fc13 has been pushed to the Fedora 13 stable repository. If problems still persist, please make note of it in this bug report.
kernel-2.6.32.12-114.fc12 has been submitted as an update for Fedora 12. http://admin.fedoraproject.org/updates/kernel-2.6.32.12-114.fc12
kernel-2.6.32.12-115.fc12 has been submitted as an update for Fedora 12. http://admin.fedoraproject.org/updates/kernel-2.6.32.12-115.fc12
kernel-2.6.32.12-115.fc12 has been pushed to the Fedora 12 stable repository. If problems still persist, please make note of it in this bug report.
Would like to test this as a fresh install from an ISO, but I don't think any have been built since 13-Beta (which was before this bug fix). Is this correct?
(In reply to comment #81) > kernel-2.6.32.12-115.fc12 has been pushed to the Fedora 12 stable repository. > If problems still persist, please make note of it in this bug report. I can still trigger oopses with kernel-2.6.32.12-115.fc12 by just messing with rmmod and modprobe. Here is one example. Should this bug be re-opened? BUG: unable to handle kernel NULL pointer dereference at 0000000000000040 IP: [<ffffffff81319799>] phy_start_aneg+0x39/0x87 PGD 13a569067 PUD 1382ac067 PMD 0 Oops: 0000 [#1] SMP last sysfs file: /sys/devices/pci0000:00/0000:00:1c.0/0000:02:00.0/net/eth1/address CPU 0 Modules linked in: cpufreq_ondemand acpi_cpufreq freq_table ipv6 dm_multipath snd_hda_codec_atihdmi snd_hda_codec_realtek snd_hda_intel snd_hda_codec snd_hwdep snd_seq snd_seq_device snd_pcm e1000 snd_timer snd soundcore tg3 iTCO_wdt iTCO_vendor_support i2c_i801 snd_page_alloc serio_raw dcdbas raid0 radeon ttm drm_kms_helper drm i2c_algo_bit i2c_core [last unloaded: broadcom] Pid: 11244, comm: ip Not tainted 2.6.32.12-115.fc12.x86_64 #1 Vostro 430 RIP: 0010:[<ffffffff81319799>] [<ffffffff81319799>] phy_start_aneg+0x39/0x87 RSP: 0018:ffff88013a0dd738 EFLAGS: 00010202 RAX: 0000000000000000 RBX: ffff880137e79000 RCX: 0000000000000000 RDX: 0000000000000000 RSI: 0000000000000000 RDI: ffff880137e79000 RBP: ffff88013a0dd758 R08: ffff880005615740 R09: 0000000000000000 R10: ffff88013a4efd40 R11: 0000000000000001 R12: ffff880137e792f0 R13: ffff880137e79000 R14: 0000000000000001 R15: 0000000000000001 FS: 00007f938f071700(0000) GS:ffff880005600000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 000000008005003b CR2: 0000000000000040 CR3: 000000013a2e8000 CR4: 00000000000006f0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400 Process ip (pid: 11244, threadinfo ffff88013a0dc000, task ffff8801381a8000) Stack: 0000000000000003 0000000000001003 ffff880137e56680 0000000000000003 ffff88013a0dd7a8 ffffffffa012f5d6 ffff880137e56680 0000014300000001 ffff88013a0dd7a8 ffff880137e56680 00000000ffffffff 0000000000001003 Call Trace: [<ffffffffa012f5d6>] tg3_set_power_state+0x1d8/0x963 [tg3] [<ffffffffa01367e0>] tg3_close+0x125/0x135 [tg3] [<ffffffff813b59ee>] dev_close+0x86/0xa6 [<ffffffff813b538d>] dev_change_flags+0xad/0x16d [<ffffffff813be94e>] do_setlink+0x26c/0x33d [<ffffffff813bee02>] rtnl_newlink+0x2bd/0x48f [<ffffffff813bebea>] ? rtnl_newlink+0xa5/0x48f [<ffffffff811ef3bf>] ? selinux_netlink_recv+0x6a/0x8a [<ffffffff813be399>] rtnetlink_rcv_msg+0x1c6/0x1e3 [<ffffffff813be1d3>] ? rtnetlink_rcv_msg+0x0/0x1e3 [<ffffffff813cf91f>] netlink_rcv_skb+0x43/0x94 [<ffffffff813be1cc>] rtnetlink_rcv+0x26/0x2d [<ffffffff813cf6ee>] netlink_unicast+0x125/0x18e [<ffffffff813cfeab>] netlink_sendmsg+0x25c/0x26b [<ffffffff813a43e6>] __sock_sendmsg+0x61/0x6c [<ffffffff813a4b49>] sock_sendmsg+0xcc/0xe5 [<ffffffff813a4a1e>] ? sock_recvmsg+0xcf/0xe8 [<ffffffff810748f7>] ? autoremove_wake_function+0x0/0x39 [<ffffffff810d613a>] ? find_get_page+0x55/0x80 [<ffffffff810d6317>] ? lock_page+0x29/0x41 [<ffffffff810d6a53>] ? filemap_fault+0xc3/0x317 [<ffffffff813a56e5>] ? move_addr_to_kernel+0x48/0x4d [<ffffffff813ae057>] ? verify_iovec+0x51/0x8e [<ffffffff813a4d83>] sys_sendmsg+0x221/0x2a5 [<ffffffff810f0537>] ? handle_mm_fault+0x35a/0x7bd [<ffffffff810f50e4>] ? __vma_link+0x57/0x5b [<ffffffff814591ef>] ? do_page_fault+0x270/0x2a0 [<ffffffff810a9215>] ? audit_syscall_entry+0x11e/0x14a [<ffffffff81011d32>] system_call_fastpath+0x16/0x1b Code: 00 00 4c 8d a7 f0 02 00 00 48 89 fb 4c 89 e7 e8 30 c7 13 00 83 bb 44 02 00 00 00 75 08 48 89 df e8 8e fd ff ff 48 8b 03 48 89 df <ff> 50 40 85 c0 78 32 83 bb 14 02 00 00 0a 74 29 83 bb 44 02 00 RIP [<ffffffff81319799>] phy_start_aneg+0x39/0x87 RSP <ffff88013a0dd738>
(In reply to comment #83) > (In reply to comment #81) > > kernel-2.6.32.12-115.fc12 has been pushed to the Fedora 12 stable repository. > > If problems still persist, please make note of it in this bug report. > > I can still trigger oopses with kernel-2.6.32.12-115.fc12 by just messing with > rmmod and modprobe. Here is one example. > > Should this bug be re-opened? No. AFAICT the oops was always off-topic. Kind of related, but not actually the subject of this bug. Please file a new bug, and then someone might actually look at it.
Marc, David is correct you should open a new bug. Please include explicit steps to reproduce as well.
I've created https://bugzilla.redhat.com/show_bug.cgi?id=602155 which seems to be a reincarnation of this bug.
(In reply to comment #84) > No. AFAICT the oops was always off-topic. Kind of related, but not actually the > subject of this bug. Please file a new bug, and then someone might actually > look at it. So this bug should be strictly restricted to automatically pre-loading the broadcom module, correct? Now I experience oopses with kernel-2.6.32.12-115.fc12 even without running any command; just by removing the modprobe.d install workaround of comment 31. Sorry but there are now 87 comments in this bug so it has become hard to follow. Some people like the noise but I do not; noise is confusing to me.
The problem is still present if F13.
(In reply to comment #88) > The problem is still present if F13. This problem was fixed in F13 for me (and the broadcom driver is automatically loaded without any modprobe hacks). You should probably provide more details.
Machine: Acer Aspire 5551G. Clean installation of Fedora 13 Desktop Edition 64-bit. No updates,because of no networking :) Please, let me know which particular details should I provide?
(In reply to comment #90) > Machine: Acer Aspire 5551G. > Clean installation of Fedora 13 Desktop Edition 64-bit. No updates,because of > no networking :) > Please, let me know which particular details should I provide? dmesg; lsmod
Can you at least provide us with the output from "dmesg", "lspci -vvv", and any configuration changes you made under /etc/modprobe.d or /etc/depmod.d? Jon.
I see David answered already. I had this window open since earlier today, when there wasn't a comment from David - then let it add my comment when the "mid air collision" happened. In either case, yes, also include lsmod output. Jon.
Andriy, I thought I would add my $0.02 to this, perhaps it will help. With a "clean install" of F13 on x64 from an ISO image this is going to happen. That install will not include the updated kernel, and the BCM57780 is not going to work... You will need to either fetch the latest kernel RPM and transfer it by cdrom or usb flash drive, or install another network adapter to use long enough to bring in the updates. I've done it both ways now, I think that the CD or USB flash drive is the easiest. Jeff
Ah yes, thanks for pointing that out Jeff.
Many thanks to Mark, David, Jon and Jeff for your help. After updating kernel to 2.6.34.6-47.fc13.x86_64 (and linux-firmware to 20100806-4.fc13.noarch) the problem was still present. But after creating a new device in System > Administration > Network Devices tab I got the connection. Connection is also present if I boot with previous kernel. So, it looks like the problem was fixed by either adding new device alone or together with updating linux-firmware. Anyway the problem was with me and not with Fedora :) I expected that network device should be created automatically and not by hand. And I was wrong. I believe dmesg; lsmod and lspci -vvv are not needed any more. I case they are needed, please, let me know. Thanks!
Nope. We don't need anything else. Sounds like NetworkManager was causing some more fun - it won't connect by default out of the box (yea, I know).
Ok I think this is really closed now.
well is there a way to have the update in the pxeboot kernel? because i can't install my dell optiplex with the BCM57780 through cobbler as that card is not detected by the pxe boot kernel.
You could spin your own replacement vmlinuz setup from the kernel RPM for PXE booting.
that would solve the problem do u have some pointer about that?
(In reply to comment #101) > that would solve the problem > do u have some pointer about that? A new vmlinuz will not make a difference. You will need to make a new initrd. You can probably follow the instructions here: http://fedoraproject.org/wiki/Anaconda/Updates
Oh good point, it was probably a bad idea to add a comment when I was in the middle of something else late at night ;) Indeed, follow the Anaconda instructions to add the new module into the initramfs.
Hi I have looked carefully at your pointer but i didn't find a way to replace the kernel and the inited of the pxeboot with an updated version. making an updates driver disk is not really an option.
Ouch. It is possible, I'm sorry that I don't have time to walk through it right now. Perhaps ping me by email (jcm) in a few days if you're still having troubles?
*** Bug 638251 has been marked as a duplicate of this bug. ***
well i have updated the images with the kernel kernel-PAE-2.6.34.7-56.fc13.i686.rpm but it still doesn't work the network card is not detected then i can't install this computer.
(In reply to comment #107) > well i have updated the images with the kernel > kernel-PAE-2.6.34.7-56.fc13.i686.rpm but it still doesn't work > the network card is not detected then i can't install this computer. You have updated your PXE boot images with this kernel and the 57780 still isn't detected? Does the card work with any of the F13 LiveCD or LiveUSB images?
if i install the machine with the iso dvd and i update mannually to this kernel it works but it s not an option for me as i have numerous computer with this hardware and i have a lot of customisation in my cobbler server. THat s why i need to install through pxe.
(In reply to comment #109) > if i install the machine with the iso dvd and i update mannually to this kernel > it works. THat s why i need to install through pxe. Is this bug really the place to discuss generic "upgrade PXE kernel" issues?
It seems this problem is still present in the official Fedora 14 release: after booting with the live KDE spin I had no network connection. Instead of trying to debug this on the live image I installed to disk (new installation, not an upgrade) after which the network also didn't work. I had to open system-config-network and add a new device by hand. IIRC this was never the case with Fedora, so unless Fedora 14 got the new feature of "user has to create network device by hand after install" then this is a serious issue.