Red Hat Bugzilla – Bug 463120
b43 driver unstable on PowerPC
Last modified: 2009-05-24 20:45:38 EDT
Description of problem:
I have found that the b43 driver is unstable when it processes a lot of network data. Eventually network access will hang.
Version-Release number of selected component (if applicable):
Steps to Reproduce:
1. Configure b43 to use WPA. Works fine for a while.
2. Store a very large mailspool (240+ MB) on an NFS share.
3. Open the mail spool using mutt.
Mutt will display the progress as it reads the mail spool over the network. Eventually, this will hang. Once this happens, the wireless network connection is no longer usable. Trying to "ifdown / ifup" the connection fails (no reply to DHCPDISCOVER). I am unable to ifup my wireless network until I reboot.
The network connectivity should be stable.
I am using a PowerPC G4 iBook with a Broadcom 4306 chipset (Airport Extreme).
Are you using NetworkManager? Please post the output of "service NetworkManager status".
(In reply to comment #1)
> Are you using NetworkManager? Please post the output of "service
> NetworkManager status".
Not really. I have tried to configure NetworkManager but need my network to work before I log in (I use Kerberos, etc.). This is broken; see bug #448760.
I use "ifup wlan0" to bring my network interface up manually.
Then you need to make sure you have disable NetworkManager:
chkconfig NetworkManager off # disable it starting at boot
service NetworkManager stop # turn it off now
A reboot after that wouldn't hurt either.
> Then you need to make sure you have disable NetworkManager:
> chkconfig NetworkManager off # disable it starting at boot
> service NetworkManager stop # turn it off now
> A reboot after that wouldn't hurt either.
Okay, I did that. However, I don't see why this would help. As I said, I'm bringing up the interface manually. I open mutt, and try to open a big mail spool over NFS. It starts loading, then hangs. Once the mail spool hangs, the interface in no longer responsive. It can't even be brought down and back up again.
I'm unable to test this at the moment because the most recent ppc kernel package crashes on boot.
NetworkManager thinks it "owns" the interface. When it is running and you try to configure the interface manually, then you have two entities trying to control the interface at the same time. So if you want to configure it manually, you need to make sure to disable NetworkManager.
Where did you get the firmware you are using for b43?
I am using firmware broadcom-wl-188.8.131.52, from (as I remember) http://downloads.openwrt.org.
I understand your comments regarding NetworkManager. I'm pretty certain my troubleshooting took into account the dynamics of NetworkManager vs. manual interface configuration.
The b43 driver as been flakey for me since it has existed. But, being that I am on PowerPC, I have to accept that my hardware is not quite the most common. In fact, I am having other problems with the PowerPC kernel right now, too.
I will keep updating this with additional information as I can.
This may be due to some kind of interaction with my wireless router, a Belkin Wireless G Router with the latest firmware installed.
I now have two computers on my wireless network: my iBook (Fedora) and an iMac (Mac OS X).
When my iBook's wireless interface freezes as described above, the iMac's interface does too. I have to restart the router to fix this.
I have installed mutt on my Mac OS X iMac. I can open the big NFS mailspool just fine from this machine. When I try to do the same using my iBook / Fedora, the process fails as documented in the original report.
1) This is simply a problem in my wireless router
2) There is a problem in the b43 driver that is causing, e.g., a bad frame to exasperate a problem in my router.
Either way, this is difficult to debug.
It is possible that whatever is happening causes your b43 device to generate interference on the network. It might be interesting to know what happens if you hit your rfkill button/switch after the hang to see if it restores communications between your router and the iMac.
Please attach the output of dmesg and/or the contents of /var/log/messages directly after the network hang. Also, please include the output of the 'lspci -n' command.
Created attachment 323986 [details]
Output from dmesg following a network hang
/var/log/messages has nothing interesting logged at the time of the hang.
0000:00:0b.0 0600: 106b:0034
0000:00:10.0 0300: 1002:5c63 (rev 01)
0001:10:0b.0 0600: 106b:0035
0001:10:12.0 0280: 14e4:4320 (rev 03)
0001:10:17.0 ff00: 106b:003e
0001:10:18.0 0c03: 106b:003f
0001:10:19.0 0c03: 106b:003f
0001:10:1a.0 0c03: 106b:003f
0001:10:1b.0 0c03: 1033:0035 (rev 43)
0001:10:1b.1 0c03: 1033:0035 (rev 43)
0001:10:1b.2 0c03: 1033:00e0 (rev 04)
0002:20:0b.0 0600: 106b:0036
0002:20:0d.0 ff00: 106b:003b
0002:20:0e.0 0c00: 106b:0031 (rev 81)
0002:20:0f.0 0200: 106b:0032 (rev ff)
This bug appears to have been reported against 'rawhide' during the Fedora 10 development cycle.
Changing version to '10'.
More information and reason for this action is here:
Are you still experiencing this issue? What is the latest kernel you have tried? I've been using b43 quite a lot lately with kernels basically equivalent to rawhide, and I'm not really seeing any problems like this.
I still have the problem (Fedora 10 up to date as of 13 Feb 09). I'd like to test against a different wireless router, but have not yet been able to do this.
OK, can you give some more objective definition to the problem? What messages do you see in /var/log/messages? What exactly do you do to experience the problem?
Closing due to lack of response...
This seems to have been a bug in my wireless router (Belkin Wireless G Router), not the kernel.