Bug 525966 (BCM57780) - BCM57780 Not Detected
Summary: BCM57780 Not Detected
Keywords:
Status: CLOSED ERRATA
Alias: BCM57780
Product: Fedora
Classification: Fedora
Component: module-init-tools
Version: 11
Hardware: x86_64
OS: Linux
low
high
Target Milestone: ---
Assignee: Jon Masters
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
: 533524 552672 564283 638251 (view as bug list)
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2009-09-27 21:46 UTC by jon
Modified: 2013-01-23 02:03 UTC (History)
36 users (show)

Fixed In Version: kernel-2.6.33.2-57.fc13
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2010-04-25 13:56:02 UTC
Type: ---
Embargoed:


Attachments (Terms of Use)
complete dmesg (49.49 KB, application/octet-stream)
2009-10-18 14:12 UTC, Gen Zhang
no flags Details
complete iomem (1.70 KB, application/octet-stream)
2009-10-18 14:13 UTC, Gen Zhang
no flags Details
complete ioports (1.25 KB, application/octet-stream)
2009-10-18 14:13 UTC, Gen Zhang
no flags Details
loading broadcom before tg3; oops (51.89 KB, application/octet-stream)
2009-10-18 14:18 UTC, Gen Zhang
no flags Details
broadcom 2.6.32 kerneloopses (4.24 KB, application/zip)
2010-03-12 16:18 UTC, MarcH
no flags Details

Description jon 2009-09-27 21:46:00 UTC
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

Comment 1 Chuck Ebbert 2009-09-30 06:22:47 UTC
What is the numeric ID of that adapter (from the command 'lspci -nn')?

Comment 2 jon 2009-10-03 21:10:53 UTC
03:00.0 Ethernet controller [0200]: Broadcom Corporation NetLink BCM57780 Gigabit Ethernet PCIe [14e4:1692] (rev 01)

Comment 3 Chuck Ebbert 2009-10-08 13:51:36 UTC
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?

Comment 4 jon 2009-10-09 23:03:56 UTC
[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

Comment 5 Chuck Ebbert 2009-10-13 12:17:32 UTC
Does the original 2.6.29 kernel from F-11 work? Also, is the latest BIOS installed?

Comment 6 Chuck Ebbert 2009-10-16 12:04:14 UTC
Please attach the entire dmesg output from boot and the contents of /proc/iomem and /proc/ioports (separate plain-text attachments.)

Comment 7 Gen Zhang 2009-10-18 14:12:22 UTC
I'm seeing exactly the same problem here. Dmesg output looks the same. I'm using a Lenovo IdeaPad U350 (tis a notebook).

Comment 8 Gen Zhang 2009-10-18 14:12:52 UTC
Created attachment 365160 [details]
complete dmesg

Comment 9 Gen Zhang 2009-10-18 14:13:31 UTC
Created attachment 365161 [details]
complete iomem

Comment 10 Gen Zhang 2009-10-18 14:13:55 UTC
Created attachment 365162 [details]
complete ioports

Comment 11 Gen Zhang 2009-10-18 14:17:47 UTC
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.

Comment 12 Gen Zhang 2009-10-18 14:18:19 UTC
Created attachment 365163 [details]
loading broadcom before tg3; oops

Comment 13 Chuck Ebbert 2009-11-02 22:39:18 UTC
Possibly fixed by commit 521e6b90d ("tg3: fix 57780 asic rev PCIe link receiver errors") in 2.6.32?

Comment 14 Matt Carlson 2009-11-02 22:53:57 UTC
Nope.  The bug will be fixed by commit 24bb4fb6dac59f220f42fb375ba0e0f19365a227
"tg3: Fix phylib locking strategy".

Comment 15 Chuck Ebbert 2009-11-09 18:00:11 UTC
*** Bug 533524 has been marked as a duplicate of this bug. ***

Comment 16 Brian G. Anderson 2009-11-09 18:03:07 UTC
So is this fix in rawhide?  FC12 RC4?

Comment 17 Mike Ricketts 2010-01-05 08:00:28 UTC
I can confirm that this bug is currently still present in FC12 with full updates.

kernel = 2.6.31.9-174.fc12.i686.PAE

Comment 18 Matt Carlson 2010-01-05 17:21:07 UTC
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.

Comment 19 Matt Carlson 2010-01-07 23:18:20 UTC
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.

Comment 20 Erik Logtenberg 2010-01-08 20:24:22 UTC
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.

Comment 21 Meng Kai 2010-01-22 06:01:36 UTC
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

Comment 22 Meng Kai 2010-01-22 06:12:16 UTC
I can't solve this problem in the kernel 2.6.27

Comment 23 Steve 2010-01-22 07:37:16 UTC
I have the BCM57782. It is detected but does not work...

Comment 24 Gaël 2010-01-22 08:26:08 UTC
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
-------------------------------------------------------------------

Comment 25 Steve 2010-01-22 10:44:35 UTC
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

Comment 26 Brian G. Anderson 2010-01-22 10:53:21 UTC
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.

Comment 27 George C 2010-02-04 20:30:45 UTC
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.

Comment 28 Erik Logtenberg 2010-02-16 22:53:20 UTC
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 ;)

Comment 29 Jeff Otterson 2010-02-17 15:33:16 UTC
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...

Comment 30 Phil Oester 2010-02-27 00:10:45 UTC
This is a problem even with the rawhide kernel.  Anyone working on it?

Comment 31 Andy Gospodarek 2010-03-01 16:00:05 UTC
(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.

Comment 33 MarcH 2010-03-11 18:05:28 UTC
> 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)

Comment 34 Matt Carlson 2010-03-11 18:40:17 UTC
I haven't seen that before.  Can you post the stack trace?

Comment 35 MarcH 2010-03-12 16:18:57 UTC
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.

Comment 36 Matt Carlson 2010-03-12 19:53:23 UTC
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?

Comment 37 MarcH 2010-03-13 16:17:26 UTC
(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.

Comment 38 Andy Gospodarek 2010-03-15 02:01:16 UTC
(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.

Comment 39 John Levon 2010-03-15 16:59:40 UTC
*** Bug 552672 has been marked as a duplicate of this bug. ***

Comment 40 John Ruemker 2010-03-15 17:13:33 UTC
Problem still exists in the latest F12 kernel.  

-John

Comment 41 Matt Carlson 2010-03-15 19:40:36 UTC
(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.

Comment 42 David Woodhouse 2010-03-30 21:43:54 UTC
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.

Comment 43 Andy Gospodarek 2010-03-30 21:56:19 UTC
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?

Comment 44 Matt Carlson 2010-03-30 22:11:44 UTC
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.

Comment 46 David Woodhouse 2010-03-31 11:24:53 UTC
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.

Comment 47 Steve 2010-04-01 09:00:38 UTC
How to test (install) this kernel without kernel-firmware?

Comment 48 David Woodhouse 2010-04-01 09:56:12 UTC
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.

Comment 49 Steve 2010-04-01 10:24:28 UTC
Sorry about, i did't found it. Where is the kernel-firmware package?

Comment 50 Andy Gospodarek 2010-04-01 12:54:34 UTC
(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

Comment 51 Denie 2010-04-01 14:14:15 UTC
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

Comment 52 Steve 2010-04-01 14:30:21 UTC
Kernel-2.6.32.10-94.fc12 does not wor for my Compaq Wireless LAN Multiport W200 (57782 / OnBoard USB).

Comment 53 Phil Oester 2010-04-01 14:32:44 UTC
(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)

Comment 54 David Woodhouse 2010-04-01 15:49:49 UTC
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.

Comment 55 Phil Oester 2010-04-01 15:57:58 UTC
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.

Comment 56 Denie 2010-04-01 16:03:18 UTC
(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...

Comment 57 Phil Oester 2010-04-01 16:06:45 UTC
Denie - that is not the correct src rpm, nor the correct patches.

Comment 58 David Woodhouse 2010-04-01 16:23:25 UTC
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

Comment 59 Phil Oester 2010-04-01 16:32:03 UTC
Aha!  Thanks very much for the info...not sure I would have ever thought to look at the PPC binaries for the srpm.

Comment 60 Denie 2010-04-01 19:40:40 UTC
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

Comment 61 David Woodhouse 2010-04-01 20:19:12 UTC
Denie, is the broadcom.ko module loaded? Does it start working if you load that module before loading the tg3.ko module?

Comment 62 Denie 2010-04-02 09:09:50 UTC
(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

Comment 63 David Woodhouse 2010-04-02 09:43:07 UTC
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?

Comment 64 David Woodhouse 2010-04-02 14:41:59 UTC
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

Comment 65 Steve 2010-04-02 16:07:27 UTC
(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

Comment 66 Phil Oester 2010-04-02 18:35:02 UTC
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.

Comment 67 Denie 2010-04-03 03:40:18 UTC
Thanks David, it works now prefectly
On 20100406 I check it again, and will reply if anything fails.

Comment 68 David Woodhouse 2010-04-03 07:38:19 UTC
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.

Comment 69 Steve 2010-04-03 08:08:16 UTC
(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!

Comment 70 Matt Carlson 2010-04-05 16:56:41 UTC
(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.

Comment 71 Andy Gospodarek 2010-04-14 20:19:21 UTC
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?

Comment 72 David Woodhouse 2010-04-14 21:03:00 UTC
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

Comment 73 Andy Gospodarek 2010-04-14 21:07:07 UTC
Thanks, David.

Comment 74 David Woodhouse 2010-04-14 21:23:12 UTC
Um, make that http://koji.fedoraproject.org/koji/taskinfo?taskID=2115847 for the F-13 build.

Comment 75 Fedora Update System 2010-04-20 14:05:38 UTC
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

Comment 76 Fedora Update System 2010-04-21 02:18:55 UTC
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

Comment 77 Benjamin Kahn 2010-04-24 02:54:22 UTC
*** Bug 564283 has been marked as a duplicate of this bug. ***

Comment 78 Fedora Update System 2010-04-25 13:54:51 UTC
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.

Comment 79 Fedora Update System 2010-04-28 04:35:26 UTC
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

Comment 80 Fedora Update System 2010-05-17 05:49:53 UTC
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

Comment 81 Fedora Update System 2010-05-18 21:58:46 UTC
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.

Comment 82 Larry Gilbert 2010-05-19 17:08:28 UTC
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?

Comment 83 MarcH 2010-05-21 16:43:47 UTC
(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>

Comment 84 David Woodhouse 2010-05-21 17:30:56 UTC
(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.

Comment 85 Andy Gospodarek 2010-05-21 17:43:20 UTC
Marc, David is correct you should open a new bug.  Please include explicit steps to reproduce as well.

Comment 86 Adam Huffman 2010-06-09 09:35:06 UTC
I've created https://bugzilla.redhat.com/show_bug.cgi?id=602155 which seems to be a reincarnation of this bug.

Comment 87 MarcH 2010-06-11 15:32:08 UTC
(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.

Comment 88 Andriy Tsykholyas 2010-09-18 17:51:15 UTC
The problem is still present if F13.

Comment 89 MarcH 2010-09-20 10:11:22 UTC
(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.

Comment 90 Andriy Tsykholyas 2010-09-20 17:03:41 UTC
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?

Comment 91 David Woodhouse 2010-09-20 21:49:33 UTC
(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

Comment 92 Jon Masters 2010-09-21 04:55:18 UTC
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.

Comment 93 Jon Masters 2010-09-21 04:56:47 UTC
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.

Comment 94 Jeff Otterson 2010-09-21 13:54:01 UTC
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

Comment 95 Jon Masters 2010-09-21 16:33:55 UTC
Ah yes, thanks for pointing that out Jeff.

Comment 96 Andriy Tsykholyas 2010-09-21 22:00:28 UTC
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!

Comment 97 Jon Masters 2010-09-22 20:30:41 UTC
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).

Comment 98 Jon Masters 2010-09-24 17:52:07 UTC
Ok I think this is really closed now.

Comment 99 Eric Doutreleau 2010-09-29 07:28:49 UTC
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.

Comment 100 Jon Masters 2010-09-30 04:44:53 UTC
You could spin your own replacement vmlinuz setup from the kernel RPM for PXE booting.

Comment 101 Eric Doutreleau 2010-09-30 07:06:33 UTC
that would solve the problem
do u have some pointer about that?

Comment 102 Andy Gospodarek 2010-09-30 11:57:19 UTC
(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

Comment 103 Jon Masters 2010-09-30 19:02:53 UTC
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.

Comment 104 Eric Doutreleau 2010-10-05 09:12:56 UTC
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.

Comment 105 Jon Masters 2010-10-05 16:44:55 UTC
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?

Comment 106 Chuck Ebbert 2010-10-08 21:08:26 UTC
*** Bug 638251 has been marked as a duplicate of this bug. ***

Comment 107 Eric Doutreleau 2010-10-19 12:14:30 UTC
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.

Comment 108 Andy Gospodarek 2010-10-19 14:01:46 UTC
(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?

Comment 109 Eric Doutreleau 2010-10-19 14:58:53 UTC
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.

Comment 110 MarcH 2010-10-19 18:22:36 UTC
(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?

Comment 111 Oded Arbel 2010-11-07 18:45:07 UTC
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.


Note You need to log in before you can comment on or make changes to this bug.