Description of problem:
Systems with Broadcom 4401 ethernet chips fail to access hardwired lan.
OK on 2.6.20-1.2962.fc6
Version-Release number of selected component (if applicable):
Update system with broadcom 4401 ethernet chip and boot.
Steps to Reproduce:
Aug 10 11:24:54 nlp17 kernel: b44: eth0: transmit timed out, resetting
Aug 10 11:24:55 nlp17 kernel: b44: eth0: Link is down.
ethernet never comes ready
If you can, try a test kernel from:
Otherwise, just try adding "pci=nomsi,nommconf" to the kernel boot parameters.
the test kernel (188.8.131.52-39.fc6) also fails in the same way. the device is
seen/probed but I suspect it isn't being initialized correctly.
pci=nomsi,nommconf options don't have an effect on this.
With the 2962 kernel on BCM4401 systems during a boot with 8 or so NFS mounts
the first mount attempt always fails but the remaining ones succeed. This
might be related - after some accesses the device begins to respond properly
Please post the boot messages (file /var/log/dmesg) after booting the latest kernel.
Created attachment 161119 [details]
dmesg from kernel 2.6.22-1.32.fc6
Created attachment 161120 [details]
dmesg from kernel 2.6.22-2.39.fc6
Created attachment 161121 [details]
dmesg from kernel 2.6.20-1.2962.fc6
Created attachment 161122 [details]
lspci -vvv for all 3 kernels tested
Try blacklisting the ssb driver by adding this line to
Oh I like that idea - that another device probe may have messed it up.
Unfortunately blacklist ssb doesn't help. The behavior was the same.
The dmesg still talked about ssb - so maybe the blacklisting didn't work.
Is there another way to disable the ssb driver short of recompiling a kernel
(In reply to comment #9)
> The dmesg still talked about ssb - so maybe the blacklisting didn't work.
> Is there another way to disable the ssb driver short of recompiling a kernel
> without it?
make a backup copy of it, then delete it from wherever it lives in
Removing the ssb driver causes unknown ssb_* symbols when b44.ko tries to load.
Maybe thats why blacklisting didn't work.
Looks like the b44 bits of git-wireless-dev.patch in those FC6 kernels are
broken. Since they aren't needed, I removed them.
I'm not sure what the process is nowadays to get FC6 stuff out to the
public -- Chuck, can you make sure 184.108.40.206-42.fc6 gets made available?
The 220.127.116.11-42.fc6 kernel resolves the issue with the bcm4401
chip. The hardwired network is accessible again.
*** Bug 253327 has been marked as a duplicate of this bug. ***
*** Bug 253378 has been marked as a duplicate of this bug. ***