Bug 431967 - crashes and wireless network failures using b43 on apple ibook g4 ppc (regression)
crashes and wireless network failures using b43 on apple ibook g4 ppc (regres...
Product: Fedora
Classification: Fedora
Component: kernel (Show other bugs)
powerpc Linux
low Severity high
: ---
: ---
Assigned To: John W. Linville
Fedora Extras Quality Assurance
Depends On:
  Show dependency treegraph
Reported: 2008-02-07 23:14 EST by Alex Markley
Modified: 2008-02-26 13:53 EST (History)
4 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2008-02-26 13:09:44 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)
sylog of badness (59.91 KB, text/plain)
2008-02-17 13:27 EST, Robert Story
no flags Details
requested objdump (8.20 KB, text/plain)
2008-02-18 11:14 EST, Robert Story
no flags Details
dump matching syslog (23.13 KB, text/plain)
2008-02-18 16:23 EST, Robert Story
no flags Details
objdump from the working ( kernel. (23.48 KB, text/plain)
2008-02-19 16:40 EST, Alex Markley
no flags Details
objdump from the broken ( kernel (8.51 KB, text/plain)
2008-02-19 16:42 EST, Alex Markley
no flags Details
screen capture of crashed powerpc (647.44 KB, image/jpeg)
2008-02-19 16:45 EST, Alex Markley
no flags Details

  None (edit)
Description Alex Markley 2008-02-07 23:14:39 EST
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux ppc; en-US; rv: Gecko/20071213 Fedora/ Firefox/

Description of problem:
When using the wireless network device built into my apple ibook g4, I experience intermittent but frequent crashes (at peak network activity) and network failures (no TCP/IP packets in or out of the interface) with various wireless network configurations.

My configuration is a fairly simple fedora 8 installation with network manager enabled and b43 firmware installed. (See below for some details on the b43 configuration.)

This is a REGRESSION because kernel version "kernel-" works quite reliably. The problem started with "kernel-" and still exists in the newly-released "kernel-".

Version-Release number of selected component (if applicable):

How reproducible:

Steps to Reproduce:
Reproducing the problem seems fairly easy. Certain network configurations seem more prone to errors than others, but going to the various neighborhood coffee shops always seems to encounter a fatal configuration. (Or three.)

If the problem is going to happen, it will happen immediately and it will manifest itself in one of two ways:

A) Network manager will perform a successful DHCP query, but no further IP packets will go across the interface. Pinging the gateway, performing a DNS request, etc. all fail.

B) Network manager performs a successful DHCP query, and the interface comes up successfully. Start firefox, thunderbird, or some other heavy net application, and the system will crash hard within seconds. (No response at console or over network, display has a nasty black band about an inch thick at the top, speckled with random dots of color.) Hard power off (power button down for 5+ seconds) is the only way to get out of it.

Actual Results:

Expected Results:

Additional info:
[root@localhost tmp]# dmesg | grep -i b43 | head
b43-phy0: Broadcom 4318 WLAN found
b43-phy0 debug: Found PHY: Analog 3, Type 2, Revision 7
b43-phy0 debug: Found Radio: Manuf 0x17F, Version 0x2050, Revision 8
b43-phy0 debug: Loading firmware version 351.126 (2006-07-29 05:54:02)
Registered led device: b43-phy0:tx
Registered led device: b43-phy0:rx
b43-phy0 debug: Chip initialized
b43-phy0 debug: 32-bit DMA initialized
b43-phy0 debug: Wireless interface started
b43-phy0 debug: Adding Interface type 2
[root@localhost tmp]#
Comment 1 Robert Story 2008-02-17 13:13:38 EST
I have a powerbook g4, and I get kernel panics as soon as I try to bring an
interface up with I'm getting ready to try a few older kernels..

# dmesg|grep b43
b43-phy0: Broadcom 4306 WLAN found
b43-phy0 debug: Found PHY: Analog 2, Type 2, Revision 2
b43-phy0 debug: Found Radio: Manuf 0x17F, Version 0x2050, Revision 2
Comment 2 Robert Story 2008-02-17 13:27:35 EST
Created attachment 295107 [details]
sylog of badness

I tried (the most recent I have before the breaking point
reported by OP, kernel-, and I get lots of 'badness' in the
syslog, which looks like the kernel panics I saw (which didn't make it into
Comment 3 John W. Linville 2008-02-18 09:15:39 EST
Would you mind helping me a bit by doing some disassembly?  I don't have a 
powerpc box handy...

You need to start by determining some addresses.  The examples are from an 
i686 box running Fedora 7, so you'll need to change the kernel version to

nm /lib/modules/ | grep 
0000f353 T b43_handle_txstatus

nm /lib/modules/ | grep 
0000f39a T b43_handle_hwtxstatus

Then do some disassembly -- use the actual address values you determined in 
the last step, and don't forget the "0x" at the beginning of the start and 
stop addresses:

objdump -d --start-address=0x0000f353 --stop-address=0x0000f39a /lib/modules/

Please attach the output to this bug...thanks!
Comment 4 Robert Story 2008-02-18 11:14:03 EST
Created attachment 295177 [details]
requested objdump
Comment 5 John W. Linville 2008-02-18 11:21:39 EST
Thanks!  But now I have to ask if the attachment in comment 2 came from 
running the kernel?  The numbers don't quite seem to 
match-up with what the objdump shows.

If the stuff in comment 2 came from a different kernel, could I impose upon 
you to repeat the exercise above but for the kernel which matches comment 2?  
Comment 6 Robert Story 2008-02-18 16:23:10 EST
Created attachment 295209 [details]
dump matching syslog

newer kernels panic and don't write anything to syslog, so the bandness stuff
is from the older kernel.. here is the objdump from the matching kernel..
Comment 7 Alex Markley 2008-02-19 16:40:00 EST
Created attachment 295339 [details]
objdump from the working ( kernel.

More information is attached. Two more comments+attachments immediately follow
Comment 8 Alex Markley 2008-02-19 16:42:01 EST
Created attachment 295340 [details]
objdump from the broken ( kernel

This attachment (and the attachment before it) should represent the information
you requested.

One more comment+attachment immediately follows.
Comment 9 Alex Markley 2008-02-19 16:45:37 EST
Created attachment 295341 [details]
screen capture of crashed powerpc

My last attachment for the day.

It's something of a miracle, but I figured out that if I enter text mode
immediately before the crash, I can see some of the debug output from the
powerpc monitor. (Apparently, the black bar I've been seeing is the monitor's
attempt to dump debugging information to the screen while the video hardware is
in video mode.)

I apologize for the low quality of the image. Let me know if it's not readable
enough, and I can borrow somebody else's camera.
Comment 10 Robert Story 2008-02-26 11:27:52 EST
did the info from comment 6 help? Anything else you need?
Comment 11 John W. Linville 2008-02-26 11:41:12 EST
Thanks for the information, I'm sure it will be helpful.  I'm sorry I have 
been too busy to deal with it in the last week.  I'll CC the upstream 
maintainer, in case he can provide a quick word of advise on the issue.

In the meantime, have you tried a later F8 kernel?


Do you get similar results with it?
Comment 12 Robert Story 2008-02-26 12:52:52 EST
I tried the kernel from comment 11, and was able to bring up the wireless
interface and get an ip address from dhcp.. no log warning messages, bandess or
Comment 13 John W. Linville 2008-02-26 13:09:44 EST
Ah, cool!
Comment 14 Alex Markley 2008-02-26 13:53:37 EST
This new kernel ( appears to solve the problem for me. I will
continue testing, but unless you hear from me again, the bug is resolved. :)

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