Bug 412861 - b43 regression in kernel-2.6.23.8-63.fc8
b43 regression in kernel-2.6.23.8-63.fc8
Status: CLOSED CURRENTRELEASE
Product: Fedora
Classification: Fedora
Component: kernel (Show other bugs)
8
All Linux
medium Severity medium
: ---
: ---
Assigned To: John W. Linville
Fedora Extras Quality Assurance
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2007-12-05 15:44 EST by Ville Skyttä
Modified: 2007-12-21 12:51 EST (History)
5 users (show)

See Also:
Fixed In Version: 2.6.23.12-99.fc8
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2007-12-20 08:50:06 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
diff of b43 between 2.6.23.1-49 and 2.6.23.8-63 (76.35 KB, text/x-patch)
2007-12-11 23:59 EST, Brennan Ashton
no flags Details

  None (edit)
Description Ville Skyttä 2007-12-05 15:44:15 EST
With kernel-2.6.23.8-63.fc8, I always get a 1 Mb/s bitrate and very flaky
networking with my Buffalo WLI2-PCI-G54S card on x86_64.  Connection is dropped
every minute or so, /etc/init.d/network restart restores it.  WEP, no
NetworkManager.

Under normal circumstances, I get almost always a 54 Mb/s bitrate, sometimes 48
Mb/s, and no networking glitches.  Downgrading to kernel-2.6.23.1-49.fc8 fixes it.

04:09.0 Network controller: Broadcom Corporation BCM4306 802.11b/g Wireless LAN
Controller (rev 03)
        Subsystem: Melco Inc Buffalo WLI2-PCI-G54S High Speed Mode Wireless
Desktop Adapter
        Flags: bus master, fast devsel, latency 64, IRQ 19
        Memory at faafc000 (32-bit, non-prefetchable) [size=8K]

/sbin/iwconfig (taken under normally working conditions with 2.6.23.1-49.fc8):

wlan0     IEEE 802.11g  ESSID:"..."
          Mode:Managed  Frequency:2.437 GHz  Access Point: 00:0D:0B:98:9A:16
          Bit Rate=54 Mb/s   Tx-Power=27 dBm
          Retry min limit:7   RTS thr:off   Fragment thr=2352 B
          Link Quality=86/100  Signal level=-47 dBm  Noise level=-64 dBm
          Rx invalid nwid:0  Rx invalid crypt:0  Rx invalid frag:0
          Tx excessive retries:0  Invalid misc:0   Missed beacon:0

With kernel-2.6.23.8-63.fc8+, as said, bit rate was always 1 Mb/s, and IIRC Link
Quality quite a bit lower, around 60/100.  Also tried with
kernel-2.6.23.9-78.fc8 from koji, same bad results.
Comment 1 Dario Castellarin 2007-12-05 19:30:08 EST
I confirm same behavior with a BCM4312 device, I can't move farer than 5 meters
from the AP without losing connection now!

05:00.0 Network controller: Broadcom Corporation BCM4312 802.11a/b/g (rev 01)
        Subsystem: Dell Unknown device 0007
        Flags: bus master, fast devsel, latency 0, IRQ 18
        Memory at c0200000 (32-bit, non-prefetchable) [size=16K]
        Capabilities: [40] Power Management version 2
        Capabilities: [58] Message Signalled Interrupts: Mask- 64bit- Queue=0/0
Enable-
        Capabilities: [d0] Express Legacy Endpoint IRQ 0
Comment 2 Alexei Podtelezhnikov 2007-12-06 13:08:04 EST
Same here. Very unstable especially with WEP encrypted network. Drops
connection. Keeps resetting.

This is how connection gets reset. No, I am not moving around the house at all.
The signal is at 66-80%

wlan0: association frame received from 00:11:11:11:11:11, but not in associate
state - ignored
wlan0: No ProbeResp from current AP 00:11:11:11:11:11 - assume out of range
wlan0: No STA entry for own AP 00:11:11:11:11:11
wlan0: No STA entry for own AP 00:11:11:11:11:11
b43-phy0 debug: Disabling hardware based encryption for keyidx: 0, mac:
ff:ff:ff:ff:ff:ff

Now... I understand the desire to push updates scheduled for 2.4.25 2-3 months
ahead of time. Maybe, Fedora Release is not the place for such bold experiments.
let's keep them to rawhide.
Comment 3 John W. Linville 2007-12-06 13:44:53 EST
"My stuff was already working...why would anyone else need updated code?"

Nice attitude...
Comment 4 Alexei Podtelezhnikov 2007-12-06 14:45:24 EST
In case you missed it, regressions are less and less tolerated in official
kernel too. So you had to skip that inconvenience altogether. 
My attitude is "you introduced a regression". 
Your attitude is "who cares, fedora is my playground".
Comment 5 Michael Buesch 2007-12-06 15:15:51 EST
I introduced the regression to fool ya _all_. :P

Come on. What's this? It doesn't matter AT ALL why and how this happened.
It would be cool if you could bisect the bug to find out which patch broke it.
Otherwise we can not help you. It's still a fact that we don't know what large
amounts of the code do. So a change in these parts of the code could easily
trigger a regression on one device, where it works fine on 100 other devices.
If you want regressions to be impossible to happen on your device, please send
us your device and we can test it before releasing patches.
Comment 6 Alexei Podtelezhnikov 2007-12-06 16:26:16 EST
Say it again please? Reporting a bug is not enough - you users have to fix 
it. :)
Comment 7 Michael Buesch 2007-12-06 16:42:25 EST
In case what I said was not clear enough I'll say it again:
I can not reproduce your bug on any of my devices. Nor do you supply information
on what caused this bug for you.
I have a BCM 4306 (rev 03) and the bug does not happen there.

Please suggest what I should do now. Some magic voodoo?

And yes, reporting a bug sometimes _is_ not enough. And this is the case here.

So please find out which patch broke it (by bisecting).
Alternatively you can buy a Buffalo WLI2-PCI-G54S and send it to me so I can
bisect it.
Comment 8 Ville Skyttä 2007-12-06 17:22:23 EST
FWIW, as noted in the initial comment, my Buffalo WLI2-PCI-G54S is a BCM 4306
(rev 03) too - I'm not sure if you missed that, so I thought I'd note it again.

Oh, and the firmware I use is version 351.126, locally rpmbuilt from the package
in bug 383271.

Bisecting might not mean anything to an average Fedora user, and in any case
even for people who know it means I suppose it's not that easy.  As far as I can
tell, one would have to first look at the CVS tags of the working and
non-working Fedora kernels, find out (guess) the culprit patch, track down the
upstream repository where the patch originates from, and then start a manual
bisection process by retrieving changesets from the upstream repository,
comparing them with the Fedora patchkit, applying each of them in turn,
rpmbuilding in between etc.

If there's an easier way to do this for Fedora kernels, please let us know.
Comment 9 Alexei Podtelezhnikov 2007-12-06 18:00:47 EST
Broadcom Corporation BCM4312 802.11a/b/g (rev 01) on Dell Inspiron 1500

So this update b43legacy (bug 389761), but broke b43.


Comment 10 Ville Skyttä 2007-12-06 18:49:46 EST
2.6.23.9-80.fc8 from 
https://koji.fedoraproject.org/koji/buildinfo?buildID=26862 appers to fix it 
for me.
Comment 11 Dario Castellarin 2007-12-06 19:04:14 EST
I tracked down Koji builds, as far as I can tell, first kernel to show this bug
is build -58, while -49 introduced another regression related to wireless led
(<url=https://bugzilla.redhat.com/show_bug.cgi?id=374871>bug 374871</url>).
Initial F8 kernel (build -42?) was working flawlessly.

Build -80 doesn't appear to work for me, too bad.
Comment 12 Ville Skyttä 2007-12-07 02:20:40 EST
I'll have to take comment 10 back, -80 worked last night on one reboot, but 
now it exhibits the same problem as -63.
Comment 13 Alexei Podtelezhnikov 2007-12-08 17:53:14 EST
A couple of very likely dups, so that we are not under impression that this bug
is contained:

bug 407311
bug 413781
Comment 14 Brennan Ashton 2007-12-08 19:42:10 EST
Broadcom 4311
03:00.0 0280: 14e4:4311 (rev 01)
also is having this regressions, it is however fixed with 2.6.23.9-85.fc8
http://koji.fedoraproject.org/koji/buildinfo?buildID=27294
Comment 15 Alexei Podtelezhnikov 2007-12-09 18:29:48 EST
I tried 2.6.23.9-85.fc8 too. It hasn't improved for me.
2.6.23.1-49  was much much much more stable.
Comment 16 Brennan Ashton 2007-12-10 19:02:57 EST
RE: Comment #14
was working yesterday, but not today, not sure why, I have not moved my laptop
or AP.
Comment 17 Ville Skyttä 2007-12-11 02:43:15 EST
I've had the same experience with -80 and -85 (and -63 IIRC): worked ok when
booting with them for the first time, but not with any following reboots.  Weird.
Comment 18 Alexei Podtelezhnikov 2007-12-11 11:39:41 EST
We know that BCM4306, BCM4311, and BCM4312 are broken.

Michael Buesch (the developer) claims that BCM4306 works for him somehow.
I am not sure that he tried WEP encrypted connections. The woodoo magic for him
to try is to enable WEP.
Comment 19 Michael Buesch 2007-12-11 12:18:46 EST
I just tried WEP and it works fine.
So what's your next voodoo suggestion?

Please try to track down which change in your kernel introduced the bug. That's
really the only way to go.

Thanks.
Comment 20 Michael Buesch 2007-12-11 12:21:05 EST
(In reply to comment #17)
> I've had the same experience with -80 and -85 (and -63 IIRC): worked ok when
> booting with them for the first time, but not with any following reboots.  Weird.

Try these patches, please: (to be applied in that order)
http://bu3sch.de/patches/wireless-2.6/20071211-1622/patches/004-b43-fix-ofdmtab-stuff.patch
http://bu3sch.de/patches/wireless-2.6/20071211-1622/patches/005-b43-fix-init-rewrite-breakage.patch
Comment 21 Alexei Podtelezhnikov 2007-12-11 12:56:57 EST
Keep using WEP please.. It drops connection randomly... It may take one hour if
you are (un)lucky.
Comment 22 Michael Buesch 2007-12-11 17:55:16 EST
(In reply to comment #21)
> Keep using WEP please.. It drops connection randomly... It may take one hour if
> you are (un)lucky.

Ok, I tested the shit out of 40bit and 104bit WEP.
It doesn't break for me. Do you trust me now?

So now it's your turn to track down the bug..
Comment 23 Brennan Ashton 2007-12-11 21:01:16 EST
It is not localized to WEP, i have it happen with WPA2. I am working on tracking
it down, but this is finals weeks so my time is limited.
Comment 24 Brennan Ashton 2007-12-11 23:57:46 EST
after banging on 1-58 for a while, i think that is where it stops working i was
getting ready to do a diff on it when the src.rpm and rpm was pulled from koji,
John any chance that could go back up on koji so i could do a diff of b43
between it an 1-49? The results on 1-58 are identical to what is happening on
the 8-63 kernel.

I have a diff of b43 for 1-49 and 8-63 but the file is very large, it looks like
a fair amount of changes were made.

We should be able to avoid a lot of extra debugging if the src.rpm can be made
re-available http://koji.fedoraproject.org/koji/buildinfo?buildID=24568
Comment 25 Brennan Ashton 2007-12-11 23:59:00 EST
Created attachment 285041 [details]
diff of b43 between 2.6.23.1-49 and 2.6.23.8-63
Comment 26 Ville Skyttä 2007-12-12 02:58:02 EST
(In reply to comment #20)

> Try these patches, please: (to be applied in that order)
>
http://bu3sch.de/patches/wireless-2.6/20071211-1622/patches/004-b43-fix-ofdmtab-stuff.patch
>
http://bu3sch.de/patches/wireless-2.6/20071211-1622/patches/005-b43-fix-init-rewrite-breakage.patch
> 

A locally rebuilt -87 from CVS plus these patches worked for me on two quick
successive reboots, thanks.  I'll use it more later today and report back how it
looks.
Comment 27 Michael Buesch 2007-12-12 05:46:40 EST
(In reply to comment #25)
> Created an attachment (id=285041) [edit]
> diff of b43 between 2.6.23.1-49 and 2.6.23.8-63
> 

Did you try the patches I posted?
Comment 28 Alexei Podtelezhnikov 2007-12-12 15:11:46 EST
Any chance for those patches to be included in koji build?
Comment 29 Michael Buesch 2007-12-12 15:21:37 EST
(In reply to comment #28)
> Any chance for those patches to be included in koji build?

Do they fix your problem? Did you test them?
Comment 30 Alexei Podtelezhnikov 2007-12-12 18:01:22 EST
developers develop
builders build
testers test

How about this ages-old simple arrangement?
Comment 31 Alexei Podtelezhnikov 2007-12-12 18:08:53 EST
I am very frustrated with this team... there are 3 duplicates already, which i
pointed out already. 

bug 407311
bug 413781
bug 419871

This makes it one bug every other day since the release of this kernel.
The duplicates are not being marked. Do you still not believe that there are
very serious issues with b43?

Comment 32 Michael Buesch 2007-12-12 18:12:17 EST
I won't contribute to this idiotic discussion anymore.
Thanks for your nonexisting help.

Try to fix your things yourself. It works fine for me. I'm not payed or
otherwise forced to help idiots.
Comment 33 Alexei Podtelezhnikov 2007-12-12 18:30:08 EST
and still in denial :)
Comment 34 Brennan Ashton 2007-12-12 18:42:19 EST
Alexei Podtelezhnikov,
What is your problem, I am working to get this fixed, but it takes time, I spent
4 hours last night working on this when I should have been studying for my
finals. If you want to pay me at the rate my clients pay, fine i will put it on
the top of my pile. Until then be patient, and we will work on this as time permits.

Michael I will apply the patches and see what happens.
Comment 35 John W. Linville 2007-12-12 19:36:31 EST
Alexei, please confusing everything.  If you can't be helpful, then wait and 
hope for a fix.
Comment 36 Alexei Podtelezhnikov 2007-12-12 22:33:15 EST
I am sorry for my outbursts. I am trying to be helpful. This bug is very
unpredictable indeed. I swear I was using 2.6.23.9-90 for 3 hours tonight
without any connection drops. Then I rebooted, noticed that link quality has
come up a bit worse and connection dropped shortly thereafter. Then I rebooted
again, connection quality somehow improved, and I think I am ok for the next 3
hours :) 

BTW, my AP is Linksys WRT54G firmware 8.00.2. 

Could the driver set the power too low after overestimating link quality for
whatever reason? I am just guessing, because I obviously don't know how it works.

Thanks for your efforts.
Comment 37 Brennan Ashton 2007-12-12 23:11:36 EST
That first patch appears to already be applied, the second one not.

patching file drivers/net/wireless/b43/b43.h
Hunk #1 FAILED at 545.
1 out of 1 hunk FAILED -- saving rejects to file drivers/net/wireless/b43/b43.h.rej
patching file drivers/net/wireless/b43/main.c
Reversed (or previously applied) patch detected! 

I am building the RPM currently.
Comment 38 Brennan Ashton 2007-12-13 01:18:03 EST
well the build failed,
drivers/net/wireless/b43/tables.c: In function 'b43_ofdmtab_read16':
drivers/net/wireless/b43/tables.c:384: error: 'struct b43_phy' has no member
named 'ofdmtab_addr_direction'
drivers/net/wireless/b43/tables.c:384: error: 'B43_OFDMTAB_DIRECTION_READ'
undeclared (first use in this function)
drivers/net/wireless/b43/tables.c:384: error: (Each undeclared identifier is
reported only once
drivers/net/wireless/b43/tables.c:384: error: for each function it appears in.)
drivers/net/wireless/b43/tables.c:385: error: 'struct b43_phy' has no member
named 'ofdmtab_addr'
drivers/net/wireless/b43/tables.c:388: error: 'struct b43_phy' has no member
named 'ofdmtab_addr_direction'
drivers/net/wireless/b43/tables.c:390: error: 'struct b43_phy' has no member
named 'ofdmtab_addr'
drivers/net/wireless/b43/tables.c: In function 'b43_ofdmtab_write16':
drivers/net/wireless/b43/tables.c:405: error: 'struct b43_phy' has no member
named 'ofdmtab_addr_direction'
drivers/net/wireless/b43/tables.c:405: error: 'B43_OFDMTAB_DIRECTION_WRITE'
undeclared (first use in this function)
drivers/net/wireless/b43/tables.c:406: error: 'struct b43_phy' has no member
named 'ofdmtab_addr'
drivers/net/wireless/b43/tables.c:409: error: 'struct b43_phy' has no member
named 'ofdmtab_addr_direction'
drivers/net/wireless/b43/tables.c:411: error: 'struct b43_phy' has no member
named 'ofdmtab_addr'
drivers/net/wireless/b43/tables.c: In function 'b43_ofdmtab_read32':
drivers/net/wireless/b43/tables.c:422: error: 'struct b43_phy' has no member
named 'ofdmtab_addr_direction'
drivers/net/wireless/b43/tables.c:422: error: 'B43_OFDMTAB_DIRECTION_READ'
undeclared (first use in this function)
drivers/net/wireless/b43/tables.c:423: error: 'struct b43_phy' has no member
named 'ofdmtab_addr'
drivers/net/wireless/b43/tables.c:426: error: 'struct b43_phy' has no member
named 'ofdmtab_addr_direction'
drivers/net/wireless/b43/tables.c:428: error: 'struct b43_phy' has no member
named 'ofdmtab_addr'
drivers/net/wireless/b43/tables.c: In function 'b43_ofdmtab_write32':
drivers/net/wireless/b43/tables.c:443: error: 'struct b43_phy' has no member
named 'ofdmtab_addr_direction'
drivers/net/wireless/b43/tables.c:443: error: 'B43_OFDMTAB_DIRECTION_WRITE'
undeclared (first use in this function)
drivers/net/wireless/b43/tables.c:444: error: 'struct b43_phy' has no member
named 'ofdmtab_addr'
drivers/net/wireless/b43/tables.c:447: error: 'struct b43_phy' has no member
named 'ofdmtab_addr_direction'
drivers/net/wireless/b43/tables.c:449: error: 'struct b43_phy' has no member
named 'ofdmtab_addr'
make[4]: *** [drivers/net/wireless/b43/tables.o] Error 1
make[3]: *** [drivers/net/wireless/b43] Error 2
make[2]: *** [drivers/net/wireless] Error 2
make[1]: *** [drivers/net] Error 2
make[1]: *** Waiting for unfinished jobs....
make: *** [drivers] Error 2
+ exit 1
error: Bad exit status from /var/tmp/rpm-tmp.12561 (%build)
Comment 39 Ville Skyttä 2007-12-13 02:50:39 EST
(In reply to comment #26)

> A locally rebuilt -87 from CVS plus these patches worked for me on two quick
> successive reboots, thanks.  I'll use it more later today and report back how it
> looks.

Looks very good, I haven't noticed a single problem.
Comment 40 Dario Castellarin 2007-12-20 05:06:12 EST
I tried right now kernel 2.6.23.12-99.fc8 from Koji build and situation is back
to normal for me on BCM4312!
Comment 41 Ville Skyttä 2007-12-21 12:51:04 EST
-99 looks good here too.

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