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.
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
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.
"My stuff was already working...why would anyone else need updated code?" Nice attitude...
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".
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.
Say it again please? Reporting a bug is not enough - you users have to fix it. :)
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.
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.
Broadcom Corporation BCM4312 802.11a/b/g (rev 01) on Dell Inspiron 1500 So this update b43legacy (bug 389761), but broke b43.
2.6.23.9-80.fc8 from https://koji.fedoraproject.org/koji/buildinfo?buildID=26862 appers to fix it for me.
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.
I'll have to take comment 10 back, -80 worked last night on one reboot, but now it exhibits the same problem as -63.
A couple of very likely dups, so that we are not under impression that this bug is contained: bug 407311 bug 413781
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
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.
RE: Comment #14 was working yesterday, but not today, not sure why, I have not moved my laptop or AP.
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.
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.
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.
(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
Keep using WEP please.. It drops connection randomly... It may take one hour if you are (un)lucky.
(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..
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.
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
Created attachment 285041 [details] diff of b43 between 2.6.23.1-49 and 2.6.23.8-63
(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.
(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?
Any chance for those patches to be included in koji build?
(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?
developers develop builders build testers test How about this ages-old simple arrangement?
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?
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.
and still in denial :)
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.
Alexei, please confusing everything. If you can't be helpful, then wait and hope for a fix.
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.
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.
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)
(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.
I tried right now kernel 2.6.23.12-99.fc8 from Koji build and situation is back to normal for me on BCM4312!
-99 looks good here too.