since the update to gentoo-sources-2.6.21-r4 (didn't try the other 2.6.21-revisions), my wlan-card works very poor ping to my WLAN-router, for example, takes 5s. host resolution takes so long, too I even tried the patchset proposed on http://de.gentoo-wiki.com/Broadcom_43xx (ftp://lwfinger.dynalias.org/patches/), but it didn't change anything lspci: 01:00.0 Network controller: Broadcom Corporation BCM4306 802.11b/g Wireless LAN Controller (rev 02) iwconfig: wlan0 IEEE 802.11b/g ESSID:"Connectionbgl03" Nickname:"Broadcom 4306" Mode:Managed Frequency=2.462 GHz Access Point: 00:01:E3:04:D1:A7 Bit Rate=11 Mb/s Tx-Power=15 dBm RTS thr:off Fragment thr:off Encryption key:617A-706F-646C-6D6B-7270-7065-71 Security mode:open Link Quality=75/100 Signal level=-49 dBm Noise level=-66 dBm Rx invalid nwid:0 Rx invalid crypt:0 Rx invalid frag:0 Tx excessive retries:0 Invalid misc:0 Missed beacon:0 lsmod: bcm43xx 431008 0 firmware_class 9536 1 bcm43xx Reproducible: Always
I just want to add some, maybe important, infos: fwcutter output: filename : bcmwl564.sys version : 3.70.17.5 MD5 : f5590c8784b91dfd9ee092d3040b6e40 microcodes : 2 4 5 pcms : 4 5 microcode : 2 revision : 0x0118 patchlevel : 0x0017 date : 2004-05-06 time : 21:34:00 microcode : 4 revision : 0x0118 patchlevel : 0x0017 date : 2004-05-06 time : 21:34:00 microcode : 5 revision : 0x0118 patchlevel : 0x0017 date : 2004-05-06 time : 21:34:00 extracting bcm43xx_microcode2.fw ... extracting bcm43xx_microcode4.fw ... extracting bcm43xx_microcode5.fw ... extracting bcm43xx_pcm4.fw ... extracting bcm43xx_pcm5.fw ... extracting bcm43xx_initval01.fw ... extracting bcm43xx_initval02.fw ... extracting bcm43xx_initval03.fw ... extracting bcm43xx_initval04.fw ... extracting bcm43xx_initval05.fw ... extracting bcm43xx_initval06.fw ... extracting bcm43xx_initval07.fw ... extracting bcm43xx_initval08.fw ... extracting bcm43xx_initval09.fw ... extracting bcm43xx_initval10.fw ... and I upgraded to newest (~amd64) version of wireless-tools, because the 2.6.21 kernel uses the wireless extension v22
Can you do the following for more info: Can you attach the output of emerge --info Also, can you test with gentoo-sources-2.6.22-r2 and if it fails, can you test the latest vanilla sources which at this time is 2.6.23_rc2? And what was the last working kernel?
I returned temporarily to the last working kernel, which is 2.6.20-r8 and as I'm normaly using paludis I don't know whether all those infos are correct: Portage 2.1.2.11 (default-linux/amd64/2007.0/desktop, gcc-4.1.2, glibc-2.5-r4, 2.6.20-gentoo-r8 x86_64) ================================================================= System uname: 2.6.20-gentoo-r8 x86_64 AMD Athlon(tm) 64 X2 Dual Core Processor 3800+ Gentoo Base System release 1.12.9 Timestamp of tree: Sun, 05 Aug 2007 04:50:01 +0000 distcc 2.18.3 x86_64-pc-linux-gnu (protocols 1 and 2) (default port 3632) [disabled] ccache version 2.4 [enabled] dev-java/java-config: 1.3.7, 2.0.33-r1 dev-lang/python: 2.4.4-r4 dev-python/pycrypto: 2.0.1-r6 dev-util/ccache: 2.4-r7 sys-apps/sandbox: 1.2.17 sys-devel/autoconf: 2.13, 2.61 sys-devel/automake: 1.4_p6, 1.5, 1.6.3, 1.7.9-r1, 1.8.5-r3, 1.9.6-r2, 1.10 sys-devel/binutils: 2.17 sys-devel/gcc-config: 1.3.16 sys-devel/libtool: 1.5.23b virtual/os-headers: 2.6.21 ACCEPT_KEYWORDS="amd64" AUTOCLEAN="yes" CBUILD="x86_64-pc-linux-gnu" CFLAGS="-march=athlon64 -O2 -pipe" CHOST="x86_64-pc-linux-gnu" CONFIG_PROTECT="/etc /usr/kde/3.5/env /usr/kde/3.5/share/config /usr/kde/3.5/shutdown /usr/share/X11/xkb /usr/share/config" CONFIG_PROTECT_MASK="/etc/env.d /etc/env.d/java/ /etc/gconf /etc/php/apache2-php5/ext-active/ /etc/php/cgi-php5/ext-active/ /etc/php/cli-php5/ext-active/ /etc/revdep-rebuild /etc/terminfo /etc/texmf/web2c" CXXFLAGS="-march=athlon64 -O2 -pipe" DISTDIR="/usr/portage/distfiles" FEATURES="ccache distlocks elog metadata-transfer parallel-fetch sandbox sfperms strict" GENTOO_MIRRORS="http://mirror.switch.ch/ftp/mirror/gentoo/ http://mirrors.sec.informatik.tu-darmstadt.de/gentoo/ http://gentoo.intergenia.de" LANG="de_DE.utf8" LC_ALL="de_DE.utf8" LINGUAS="de en en_GB" MAKEOPTS="-j8" PKGDIR="/usr/portage/packages" PORTAGE_RSYNC_OPTS="--recursive --links --safe-links --perms --times --compress --force --whole-file --delete --delete-after --stats --timeout=180 --exclude=/distfiles --exclude=/local --exclude=/packages --filter=H_**/files/digest-*" PORTAGE_TMPDIR="/var/tmp" PORTDIR="/usr/portage" PORTDIR_OVERLAY="/usr/portage/local/layman/xeffects /usr/portage/local/layman/armagetron /usr/local/portage" SYNC="rsync://rsync.europe.gentoo.org/gentoo-portage" USE="3dnow 3dnowext X a52 aac aalib acl acpi aim alsa amd64 amr apache2 apm avi bash-completion bcmath berkdb binary-drivers bitmap-fonts bzip2 cairo ccache cdr cli cracklib crypt cups dbus dlloader dri dvd dvdr dvdread eds emboss encode evo fam fat firefox fortran gd gdbm gif glib gpm gtk gtk2 hal hash haskell iconv icq ipv6 jack java javascript jpeg jpeg2k kde latin1 libcaca libg++ logitech-mouse logrotate mad midi mikmod mime mmx mmxext mp3 mpeg msn mudflap mysql mysqli ncurses nls nptl nptlonly nsplugin ntfs nvidia ogg openal opengl openmp oss pam pcre pdf pdflib perl php png ppds python qt3 qt3support qt4 quicktime readline reflection reiser4 reiserfs sdl session slang sockets spell spl sql sse sse2 ssl startup-notification svg tcpd tetex themes tiff tk truetype truetype-fonts type1-fonts udev unicode usb v4l vcd visualization vorbis wifi x264 xcomposite xine xml xorg xscreensaver xv xvid yahoo zlib" ALSA_CARDS="snd-intel-hda" ALSA_PCM_PLUGINS="adpcm alaw asym copy dmix dshare dsnoop empty extplug file hooks iec958 ioplug ladspa lfloat linear meter mulaw multi null plug rate route share shm softvol" ELIBC="glibc" INPUT_DEVICES="keyboard mouse evdev" KERNEL="linux" LCD_DEVICES="bayrad cfontz cfontz633 glk hd44780 lb216 lcdm001 mtxorb ncurses text" LINGUAS="de en en_GB" USERLAND="GNU" VIDEO_CARDS="nv nvidia vesa vga" Unset: CTARGET, EMERGE_DEFAULT_OPTS, INSTALL_MASK, LDFLAGS, PORTAGE_COMPRESS, PORTAGE_COMPRESS_FLAGS, PORTAGE_RSYNC_EXTRA_OPTS I will try the newer versions now.
it seems like this has also something todo with the amount of parallel requests wenn I just started without X and tried to ping, everything was fine in 2.6.22 and in 2.6.21 but when I now started firefox, opening my previous session, so 15 pages at once, it hang like I reported (not with 2.6.20 of course) I'm just going to try it with 2.6.22 and firefox...
with gentoo-sources-2.6.22 it doesn't work either this is what happens, when many webpages are loaded: 64 bytes from ug-in-f104.google.com (66.249.93.104): icmp_seq=9 ttl=244 time=25.1 ms 64 bytes from ug-in-f104.google.com (66.249.93.104): icmp_seq=10 ttl=244 time=26.5 ms 64 bytes from ug-in-f104.google.com (66.249.93.104): icmp_seq=11 ttl=244 time=26.3 ms 64 bytes from ug-in-f104.google.com (66.249.93.104): icmp_seq=12 ttl=244 time=64.1 ms 64 bytes from ug-in-f104.google.com (66.249.93.104): icmp_seq=13 ttl=244 time=26.4 ms 64 bytes from ug-in-f104.google.com (66.249.93.104): icmp_seq=14 ttl=244 time=43.3 ms 64 bytes from ug-in-f104.google.com (66.249.93.104): icmp_seq=15 ttl=244 time=25.2 ms 64 bytes from ug-in-f104.google.com (66.249.93.104): icmp_seq=16 ttl=244 time=35.0 ms 64 bytes from ug-in-f104.google.com (66.249.93.104): icmp_seq=17 ttl=244 time=24.9 ms 64 bytes from ug-in-f104.google.com (66.249.93.104): icmp_seq=18 ttl=244 time=32.6 ms 64 bytes from ug-in-f104.google.com (66.249.93.104): icmp_seq=19 ttl=244 time=422 ms 64 bytes from ug-in-f104.google.com (66.249.93.104): icmp_seq=20 ttl=244 time=966 ms 64 bytes from ug-in-f104.google.com (66.249.93.104): icmp_seq=21 ttl=244 time=1878 ms 64 bytes from ug-in-f104.google.com (66.249.93.104): icmp_seq=22 ttl=244 time=2064 ms 64 bytes from 66.249.93.104: icmp_seq=23 ttl=244 time=6640 ms 64 bytes from 66.249.93.104: icmp_seq=24 ttl=244 time=9048 ms 64 bytes from 66.249.93.104: icmp_seq=25 ttl=244 time=8705 ms 64 bytes from 66.249.93.104: icmp_seq=26 ttl=244 time=9796 ms 64 bytes from 66.249.93.104: icmp_seq=27 ttl=244 time=11345 ms 64 bytes from 66.249.93.104: icmp_seq=28 ttl=244 time=12487 ms 64 bytes from 66.249.93.104: icmp_seq=29 ttl=244 time=12843 ms 64 bytes from ug-in-f104.google.com (66.249.93.104): icmp_seq=30 ttl=244 time=8854 ms 64 bytes from ug-in-f104.google.com (66.249.93.104): icmp_seq=31 ttl=244 time=9339 ms 64 bytes from 66.249.93.104: icmp_seq=32 ttl=244 time=8995 ms 64 bytes from 66.249.93.104: icmp_seq=33 ttl=244 time=9514 ms 64 bytes from ug-in-f104.google.com (66.249.93.104): icmp_seq=34 ttl=244 time=9511 ms 64 bytes from ug-in-f104.google.com (66.249.93.104): icmp_seq=35 ttl=244 time=10181 ms 64 bytes from ug-in-f104.google.com (66.249.93.104): icmp_seq=36 ttl=244 time=10063 ms 64 bytes from 66.249.93.104: icmp_seq=37 ttl=244 time=10257 ms 64 bytes from 66.249.93.104: icmp_seq=38 ttl=244 time=10225 ms so there are where long ping times and from time to time no hostname resolution I'll go on and try with vanilla-2.6.23_rc2 now
that test, vanilla-sources-2.6.23_rc2, didn't go well either I couldn't even get the network working my guess is that the patch mentioned earlier (see gentoo-wiki), is really neccesary and that it is contained in the gentoo-patchset already whereas there are no patches for vanilla-2.6.23 btw: in the testings I noticed, that rebooting is the only way (ok I didn't try to wait several hours) to revise the problem so when I start firefox, with many pages loading at once, it doesn't help to stop the loading, close the tabs, close firefox or even restart the init-service. only after a reboot everything works again until, I guess, there are too many requests at once on the other hand downloading one file, with large bandwith, like the kernel-sources, worked without invoking the problematic behaviour
Can you attach your .config from the last working kernel and from 2.6.23._rc2 ?
Created attachment 127720 [details] My 2.6.20-r8 Kernel-config
Created attachment 127723 [details] My 2.6.23-rc2 Kernel-config
Have you tried patching the 2.6.23 with the patch from: ftp://lwfinger.dynalias.org/patches Specifically: BCM4301_for_2.6.23.patch Some info concerning patch 2.6.23 http://lists.berlios.de/pipermail/bcm43xx-dev/2007-July/005095.html
Actually I used the bcm43xx and not the bcm4301 driver ok, so I just had a try with vanilla-2.6.23-rc2, the patch and bcm4301 the kernel-module was loaded by udev alright, but when /etc/init.d/net.wlan0 startet the system hang and I had to hit the reset button. the syslog says (concerning wlan): Aug 22 01:08:37 nowhereland ssb: Core 0 found: ChipCommon (cc 0x800, rev 0x02, vendor 0x4243) Aug 22 01:08:37 nowhereland ssb: Core 1 found: IEEE 802.11 (cc 0x812, rev 0x04, vendor 0x4243) Aug 22 01:08:37 nowhereland ssb: Core 2 found: PCMCIA (cc 0x80D, rev 0x01, vendor 0x4243) Aug 22 01:08:37 nowhereland ssb: Core 3 found: V90 (cc 0x807, rev 0x01, vendor 0x4243) Aug 22 01:08:37 nowhereland ssb: Core 4 found: PCI (cc 0x804, rev 0x07, vendor 0x4243) Aug 22 01:08:37 nowhereland ssb: Core 5 found: IEEE 802.11 (cc 0x812, rev 0x04, vendor 0x4243) Aug 22 01:08:37 nowhereland ssb: Ignoring additional 802.11 core Aug 22 01:08:37 nowhereland ssb: Switching to PCI core, index 4 Aug 22 01:08:37 nowhereland ssb: Sonics Silicon Backplane found on PCI device 0000:01:00.0 Aug 22 01:08:37 nowhereland bcm4301-phy0: Broadcom 4306 WLAN found Aug 22 01:08:37 nowhereland ssb: Switching to IEEE 802.11 core, index 1 Aug 22 01:08:37 nowhereland bcm4301-phy0 debug: Found PHY: Analog 1, Type 2, Revision 1 Aug 22 01:08:37 nowhereland bcm4301-phy0 debug: Found Radio: Manuf 0x17F, Version 0x2050, Revision 2 Aug 22 01:08:37 nowhereland bcm4301-phy0 debug: Radio turned off Aug 22 01:08:37 nowhereland wmaster0: Selected rate control algorithm 'simple' I'll try the bcm4301-driver in gentoo-sources-2.6.22 now maybe that will work...
Unfortunately gentoo-sources-2.6.22-r2 and bcm4301 didn't work either. When trying to boot I got an kernel panic.
Possible similar bug report: https://bugs.launchpad.net/ubuntu/+source/linux-source-2.6.22/+bug/124159
Yes I agree. That could be something similar. After reading it, I just made speed comparison. Unfortunately I can't move my system as its not a notebook. Originaly I used ndiswrapper and had full speed up and down (down: 6000kbit/s, up ~600kbit/s). With the bcm43xx driver in gentoo-sources-2.6.20, up- and download are both about the same, nearly 600kbit/s. Sometimes when booting, the driver at first doesn't work, but after a few minutes it does and I can start the interface init script. I didn't regard this as a major problem as the speed was acceptable and the driver is marked as experimental. Finally, with the newer kernel versions, it's like in the ubuntu user's bug report, that the connection speed is very low. When having only one data transfer it's something about 10 kbit/s and when trying to load several things at once it of course doesn't work with that connection quality.
Bodo, please file an upstream bug at http://bugzilla.kernel.org and post the new bug URL here.
ok, I posted it at kernel.org: http://bugzilla.kernel.org/show_bug.cgi?id=8925 and there is a correction I have to make it seems like the slow download speed with 2.6.20 and bcm43xx is not due to the driver but a problem with my ISP I apologize that I didn't notice that at first
Bodo, According to the upstream bug, this has been fixed in 2.6.23_rc3. Can you attempt with vanilla-sources-2.6.23_rc4 (the latest development kernel) and post back the results?
Bodo, See comment #17. Please reopen if you have tested with latest development kernel.
Well I'm not quite sure if understood that comment by Larry Finger right: "The complete failure of driver bcm43xx for this particular device should be fixed by the above reversion in 2.6.23-rc3. The temporary driver that was called bcm4301 has been abandoned. That effort has resulted in a driver named b43legacy that is in the wireless-dev git tree. On my system, that driver handles the BCM4306/2 device. Performance is not as good as other chips, but it is being worked on. I will certainly investigate all the changes since 2.6.20 to see which might be causing a regression in performance." Does that mean, the official driver in 2.6.23 isn't supposed to work anyway and I have to get that b43legacy driver from that wireless-dev git tree? Actually thats not what I expected in the first place, but my latest test with the final release "gentoo-sources-2.6.23" didn't show much improvement...
Bodo, Can you try this potential workaround: $ sudo iwconfig eth1 rate 5.5M fixed (replacing eth1 with your wireless interface)
The newest development kernel now contains the b43 and b43legacy driver. It's available from portage as vanilla-sources-2.6.24_rc1. Would you mind testing this kernel with the new driver and post the results here? Some more info: http://linuxwireless.org/en/users/Drivers/b43#b43andb43legacy
Hi again, tried 5.5 M and it seems to fix the issue with bcm43xx. Unfortunately I couldn't get b43-legacy working, cause b43-fwcutter doesn't work somehow no matter which firmware-file I use, it always says "Sorry, the input file is either wrong or not supported by b43-fwcutter. This file has unknown MD5sum <someMD5sum>." I'll keep trying, but even the firmware from http://linuxwireless.org/en/users/Drivers/b43#b43andb43legacy doesn't work Bodo Graumann
Some people are reporting success using the new b43 driver in the 2.6.24 kernel. Can you test with the new b43 driver in the latest development kernel rc release which is vanilla-sources-2.6.24_rc6 as of this writing.
Please reopen if you find time to test using the new b43 driver in the latest development kernel release.
I now tried it with the latest kernel-version: gentoo-sources-2.6.24 and of course b43legacy but still no change same issue when using full speed (54Mbit) and good connection with 11Mbit fixed or less only there's another problem now: when stoping the init-script, txpower is set to off, but when starting it again, it is not set to on so in order to use the interface, I have to manually do a 'iwconfig wlan0 txpower on' some debugging output: HW CONFIG: channel=11 freq=2462 phymode=2 b43legacy-phy0 debug: Loading firmware version 0x127, patch level 14 (2005-04-18 02:36:27) b43legacy-phy0 debug: Chip initialized b43legacy-phy0 debug: 30-bit DMA initialized b43legacy-phy0 debug: Wireless interface started HW CONFIG: channel=11 freq=2462 phymode=2 b43legacy-phy0 debug: Adding Interface type 2 b43legacy-phy0 debug: Using software based encryption for mac: ff:ff:ff:ff:ff:ff ADDRCONF(NETDEV_UP): wlan0: link is not ready HW CONFIG: channel=11 freq=2462 phymode=2 wlan0: Initial auth_alg=0 wlan0: authenticate with AP 00:01:e3:04:d1:a7 phy0: TX to low-level driver (len=30) FC=0x00b0 DUR=0x013a A1=00:01:e3:04:d1:a7 A2=00:01:e3:01:4c:0d A3=00:01:e3:04:d1:a7 HW CONFIG: channel=11 freq=2462 phymode=2 wlan0: Initial auth_alg=0 wlan0: authenticate with AP 00:01:e3:04:d1:a7 phy0: TX to low-level driver (len=30) FC=0x00b0 DUR=0x013a A1=00:01:e3:04:d1:a7 A2=00:01:e3:01:4c:0d A3=00:01:e3:04:d1:a7 wmaster0: STA 00:01:e3:04:d1:a7 Average rate: 10 (10/1) wlan0: RX authentication from 00:01:e3:04:d1:a7 (alg=0 transaction=2 status=0) wlan0: authenticated wlan0: associate with AP 00:01:e3:04:d1:a7 phy0: TX to low-level driver (len=61) FC=0x0000 DUR=0x013a A1=00:01:e3:04:d1:a7 A2=00:01:e3:01:4c:0d A3=00:01:e3:04:d1:a7 wlan0: authentication frame received from 00:01:e3:04:d1:a7, but not in authenticate state - ignored wlan0: RX AssocResp from 00:01:e3:04:d1:a7 (capab=0x411 status=12 aid=0) wlan0: AP denied association (code=12) b43legacy-phy0 debug: Using software based encryption for mac: ff:ff:ff:ff:ff:ff HW CONFIG: channel=11 freq=2462 phymode=2 wlan0: Initial auth_alg=0 wlan0: authenticate with AP 00:01:e3:04:d1:a7 phy0: TX to low-level driver (len=30) FC=0x00b0 DUR=0x013a A1=00:01:e3:04:d1:a7 A2=00:01:e3:01:4c:0d A3=00:01:e3:04:d1:a7 wlan0: RX authentication from 00:01:e3:04:d1:a7 (alg=0 transaction=2 status=0) wlan0: authenticated wlan0: associate with AP 00:01:e3:04:d1:a7 phy0: TX to low-level driver (len=61) FC=0x0000 DUR=0x013a A1=00:01:e3:04:d1:a7 A2=00:01:e3:01:4c:0d A3=00:01:e3:04:d1:a7 wlan0: RX AssocResp from 00:01:e3:04:d1:a7 (capab=0x411 status=0 aid=3) wlan0: associated wlan0: switched to short barker preamble (BSSID=00:01:e3:04:d1:a7) ADDRCONF(NETDEV_CHANGE): wlan0: link becomes ready phy0: TX to low-level driver (len=116) FC=0x4108 DUR=0x00da A1=00:01:e3:04:d1:a7 A2=00:01:e3:01:4c:0d A3=33:33:00:00:00:16 phy0: TX to low-level driver (len=104) FC=0x4108 DUR=0x00da A1=00:01:e3:04:d1:a7 A2=00:01:e3:01:4c:0d A3=33:33:ff:01:4c:0d phy0: TX to low-level driver (len=96) FC=0x4108 DUR=0x00da A1=00:01:e3:04:d1:a7 A2=00:01:e3:01:4c:0d A3=33:33:00:00:00:02 phy0: TX to low-level driver (len=68) FC=0x4108 DUR=0x00da A1=00:01:e3:04:d1:a7 A2=00:01:e3:01:4c:0d A3=ff:ff:ff:ff:ff:ff phy0: TX to low-level driver (len=68) FC=0x4108 DUR=0x00da A1=00:01:e3:04:d1:a7 A2=00:01:e3:01:4c:0d A3=ff:ff:ff:ff:ff:ff phy0: TX to low-level driver (len=96) FC=0x4108 DUR=0x00da A1=00:01:e3:04:d1:a7 A2=00:01:e3:01:4c:0d A3=33:33:00:00:00:02
Can you attach a dmesg. I would like to see what firmware version you are using. There should be a line like "debug: Loading firmware version #"
Thats already in my last post, but I will of course repeat it, together with some more messages: b43legacy-phy0: Broadcom 4306 WLAN found b43legacy-phy0 debug: Found PHY: Analog 1, Type 2, Revision 1 b43legacy-phy0 debug: Found Radio: Manuf 0x17F, Version 0x2050, Revision 2 b43legacy-phy0 debug: Radio initialized __________________ b43legacy-phy0 debug: Loading firmware version 0x127, patch level 14 (2005-04-18 02:36:27) and whats strange, right after booting: b43legacy-phy0 debug: Radio initialized b43legacy-phy0: Radio turned off by software b43legacy-phy0 debug: Removing Interface type 2 b43legacy-phy0 debug: Wireless interface stopped
Haved you tried looking at http://linuxwireless.org/en/users/Drivers/b43#b43andb43legacy in firmware installation to make sure you are using all working versions? If so, try taking your issue upstream to the mailing list: http://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Please reopen and attach links once you have submitted this upstream
This has been reported upstream at https://bugzilla.kernel.org/show_bug.cgi?id=8925 as can be seen in the URL field of this bug, that bug has been CLOSED with CODE_FIX and John W. Linville signed this off thus it became fixed in 2.6.23-rc3, the 'watch-linux-bugzilla' whiteboard and 'NEEDINFO' status can be removed on this bug...
