Bug 251754
| Summary: | Broadcom ethernet fails on 2.6.22-1.32.fc6 kernel update | ||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| Product: | [Fedora] Fedora | Reporter: | Mark Hittinger <bugs> | ||||||||||
| Component: | kernel | Assignee: | Kernel Maintainer List <kernel-maint> | ||||||||||
| Status: | CLOSED CURRENTRELEASE | QA Contact: | Fedora Extras Quality Assurance <extras-qa> | ||||||||||
| Severity: | medium | Docs Contact: | |||||||||||
| Priority: | low | ||||||||||||
| Version: | 6 | CC: | dmkahn, ergeller, linville, ramdyne | ||||||||||
| Target Milestone: | --- | ||||||||||||
| Target Release: | --- | ||||||||||||
| Hardware: | i686 | ||||||||||||
| OS: | Linux | ||||||||||||
| Whiteboard: | |||||||||||||
| Fixed In Version: | 2.6.22.2-42.fc6 | Doc Type: | Bug Fix | ||||||||||
| Doc Text: | Story Points: | --- | |||||||||||
| Clone Of: | Environment: | ||||||||||||
| Last Closed: | 2007-08-20 18:59:18 UTC | Type: | --- | ||||||||||
| Regression: | --- | Mount Type: | --- | ||||||||||
| Documentation: | --- | CRM: | |||||||||||
| Verified Versions: | Category: | --- | |||||||||||
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |||||||||||
| Cloudforms Team: | --- | Target Upstream Version: | |||||||||||
| Embargoed: | |||||||||||||
| Attachments: |
|
||||||||||||
|
Description
Mark Hittinger
2007-08-10 21:07:43 UTC
If you can, try a test kernel from: http://people.redhat.com/cebbert/kernels/FC6/ Otherwise, just try adding "pci=nomsi,nommconf" to the kernel boot parameters. the test kernel (2.6.22.2-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 under 2962. 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 /etc/modprobe.d/blacklist: blacklist ssb 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 without it? (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 /lib/modules/<kernelversion>/ 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 2.6.22.2-42.fc6 gets made available? The 2.6.22.2-42.fc6 kernel resolves the issue with the bcm4401 chip. The hardwired network is accessible again. Thanks! *** Bug 253327 has been marked as a duplicate of this bug. *** *** Bug 253378 has been marked as a duplicate of this bug. *** |