Re: radio LED says active when radio disabled after resume
tor 2008-11-20 klockan 09:29 -0600 skrev Larry Finger: Richard Jonsson wrote: There is no difference, also I tested to unload and load b43 without suspend. The same thing happens. Turns out suspend has nothing to do with it. To summarize, every other load of b43 causes the LED to be always active. What format is your card - PCI, Cardbus, or what? 4311 on pci-express, lspci says 01:00.0 Network controller: Broadcom Corporation BCM4312 802.11a/b/g (rev 01) I noticed the ubuntu kernel doesn't have debugging on. I tried to dig up an old dmesg card id output to provide, but to no avail. When you do an lsmod command, do the following modules appear? b43, ssb, mac80211, cfg80211, led-class, input-polldev, rfkill_input, and rfkill b43 144424 0 ssb46340 1 b43 mac80211 253440 1 b43 cfg80211 37136 1 mac80211 led_class 13192 1 b43 input_polldev 12816 1 b43 rfkill_input 14080 0 rfkill 19364 3 b43,rfkill_input I diff'ed the output of lsmod in state LED works and LED always on and they are identical. Thanks, Larry regards, Richard ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: radio LED says active when radio disabled after resume
tis 2008-11-18 klockan 18:33 -0600 skrev Larry Finger: Richard Jonsson wrote: Hi! I recently made a fresh install of ubuntu hardy, upgraded weeks later to intrepid. I have not had a working suspend for some time, but now this works. Including b43. However, after every other suspend (to ram) the status led indicates that rf-kill switch is in wlan enabled state, although it is not. No matter if I switch it on and off will it change the LED status. The system log says that hw status changed, and indeed wlan0 will show AP's in enabled state, but not in disabled state. I compared the dmesg outputs (posted below), and the only thing that differs is the last lines: Working: wlan0: authentication with AP 00:14:c1:1d:19:f0 timed out b43-phy0: Radio hardware status changed to DISABLED Non-working (order changed): b43-phy0: Radio hardware status changed to DISABLED wlan0: authentication with AP 00:14:c1:1d:19:f0 timed out Also, when LED is working, I get these messages a few seconds after each DISABLE, but not when LED is stuck: [86215.196059] b43-phy0: Radio turned on by software [86215.196078] b43-phy0: The hardware RF-kill button still turns the radio physically off. Press the button to turn it on. The LED used to work fine, but that was with an older ubuntu version, and I believe it doesn't have to be a change in b43 that cause this issue. I don't even try suspend/resume so I cannot help you there, but b43 cannot control the radio hardware status enable/disable bit. It is read-only from the driver. It must be the RFKILL or LED subsystems that are getting lost and/or confused. If you unload b43 using 'sudo /sbin/modprobe -r b43' before suspending and 'sudo /sbin/modprobe b43' to load it after resuming, what happens? Larry Thanks for the quick reply. There is no difference, also I tested to unload and load b43 without suspend. The same thing happens. Turns out suspend has nothing to do with it. To summarize, every other load of b43 causes the LED to be always active. / Richard ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: radio LED says active when radio disabled after resume
ons 2008-11-19 klockan 09:23 + skrev Mark Hagger: On Tue, 2008-11-18 at 22:11 +0100, Richard Jonsson wrote: [86826.397250] input: b43-phy0 as /devices/virtual/input/input24 [86828.024071] b43-phy0: Loading firmware version 351.126 (2006-07-29 05:54:02) [86828.024082] b43-phy0 warning: You are using an old firmware image. Support for old firmware will be removed in July 2008. [86828.024087] b43-phy0 warning: You must go to http://linuxwireless.org/en/users/Drivers/b43#devicefirmware and download the latest firmware (version 4). I assume this has no impact at all on your particular problem, but is there any reason why you are still using the old firmware version? You do know we're quite a long way past July 2008? Mark To be honest it's both laziness and ignorance. Ubuntu has a scripted firmware install, which I used to get mine. Since you mention it I will test just to be sure. thanks, Richard ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: radio LED says active when radio disabled after resume
I've now upgraded the firmware, no difference. Also considering filing a bug report about fw to ubuntu. / Richard ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
radio LED says active when radio disabled after resume
Hi! I recently made a fresh install of ubuntu hardy, upgraded weeks later to intrepid. I have not had a working suspend for some time, but now this works. Including b43. However, after every other suspend (to ram) the status led indicates that rf-kill switch is in wlan enabled state, although it is not. No matter if I switch it on and off will it change the LED status. The system log says that hw status changed, and indeed wlan0 will show AP's in enabled state, but not in disabled state. I compared the dmesg outputs (posted below), and the only thing that differs is the last lines: Working: wlan0: authentication with AP 00:14:c1:1d:19:f0 timed out b43-phy0: Radio hardware status changed to DISABLED Non-working (order changed): b43-phy0: Radio hardware status changed to DISABLED wlan0: authentication with AP 00:14:c1:1d:19:f0 timed out Also, when LED is working, I get these messages a few seconds after each DISABLE, but not when LED is stuck: [86215.196059] b43-phy0: Radio turned on by software [86215.196078] b43-phy0: The hardware RF-kill button still turns the radio physically off. Press the button to turn it on. The LED used to work fine, but that was with an older ubuntu version, and I believe it doesn't have to be a change in b43 that cause this issue. $ uname -a Linux richie-laptop 2.6.27-7-generic #1 SMP Tue Nov 4 19:33:06 UTC 2008 x86_64 GNU/Linux $ lspci -nnv -s 01:00.0 01:00.0 Network controller [0280]: Broadcom Corporation BCM4312 802.11a/b/g [14e4:4312] (rev 01) Subsystem: Hewlett-Packard Company Device [103c:1361] Flags: bus master, fast devsel, latency 0, IRQ 19 Memory at b300 (32-bit, non-prefetchable) [size=16K] Capabilities: access denied Kernel driver in use: b43-pci-bridge Kernel modules: ssb, wl Computer is a HP dv2140eu (dv2000) laptop. Suspend-resume cycle after which LED is working: $ dmesg [86186.424108] PM: Syncing filesystems ... done. [86186.424170] PM: Preparing system for mem sleep [86186.424174] Freezing user space processes ... (elapsed 0.05 seconds) done. [86186.476709] Freezing remaining freezable tasks ... (elapsed 0.00 seconds) done. [86186.476816] PM: Entering mem sleep [86186.476819] Suspending console(s) (use no_console_suspend to debug) [86186.477279] sd 2:0:0:0: [sda] Synchronizing SCSI cache [86186.801333] sd 2:0:0:0: [sda] Stopping disk [86187.773538] ACPI handle has no context! [86187.773547] sdhci-pci :05:09.1: PCI INT B disabled [86187.773552] ACPI handle has no context! [86187.792067] ACPI handle has no context! [86187.808090] b43-pci-bridge :01:00.0: PCI INT A disabled [86187.824284] forcedeth :00:14.0: wake-up capability disabled by ACPI [86187.824288] forcedeth :00:14.0: PME# disabled [86187.856294] HDA Intel :00:10.1: PCI INT B disabled [86187.872145] sata_nv :00:0e.0: PCI INT A disabled [86187.904075] ehci_hcd :00:0b.1: PCI INT B disabled [86187.920066] ohci_hcd :00:0b.0: PCI INT A disabled [86187.936051] ohci_hcd :00:0b.0: PME# enabled [86187.936056] ohci_hcd :00:0b.0: PME# enabled [86187.936227] NVRM: RmPowerManagement: 4 [86189.254369] PM: suspend devices took 2.776 seconds [86189.332103] ACPI: Preparing to enter system sleep state S3 [86189.452347] Disabling non-boot CPUs ... [86189.452524] kvm: disabling virtualization on CPU1 [86189.454755] CPU 1 is now offline [86189.454757] SMP alternatives: switching to UP code [86189.470859] CPU0 attaching NULL sched-domain. [86189.470863] CPU1 attaching NULL sched-domain. [86189.484044] CPU0 attaching sched-domain: [86189.484047] domain 0: span 0 level NODE [86189.484050] groups: 0 [86189.484355] CPU1 is down [86189.484491] Extended CMOS year: 2000 [86189.484491] Back to C! [86189.484491] Extended CMOS year: 2000 [86189.488346] Enabling non-boot CPUs ... [86189.488637] SMP alternatives: switching to SMP code [86189.504900] Booting processor 1/1 ip 6000 [86189.456517] Initializing CPU#1 [86189.456517] Calibrating delay using timer specific routine.. 3214.72 BogoMIPS (lpj=6429457) [86189.456517] CPU: L1 I Cache: 64K (64 bytes/line), D cache 64K (64 bytes/line) [86189.456517] CPU: L2 Cache: 512K (64 bytes/line) [86189.456517] CPU 1/1 - Node 0 [86189.456517] CPU: Physical Processor ID: 0 [86189.456517] CPU: Processor Core ID: 1 [86189.456517] Switch to broadcast mode on CPU1 [86189.592230] CPU1: AMD Turion(tm) 64 X2 stepping 02 [86189.592237] kvm: enabling virtualization on CPU1 [86189.592272] CPU0 attaching NULL sched-domain. [86189.596039] Switched to high resolution mode on CPU 1 [86189.604050] CPU0 attaching sched-domain: [86189.604054] domain 0: span 0-1 level MC [86189.604056] groups: 0 1 [86189.604059] domain 1: span 0-1 level CPU [86189.604061]groups: 0-1 [86189.604064]domain 2: span 0-1 level NODE [86189.604066] groups: 0-1 [86189.604069] CPU1 attaching sched-domain: [86189.604071] domain 0: span 0-1 level MC [86189.604073] groups: 1 0 [86189.604076] domain 1: span 0-1 level CPU
FYI: Disabled by hardware, but switch is on
(originally sent July 12 from a different mail addy, apparently the mail didn't make it then, but I got a copy back.. also I see at least one message didn't get delivered to me from berlios) ---8---[snip]- I've been unplugged for a few days now with everything b43 related working great, then today I put away the laptop for a few minutes, and when I came back the signal appeared to be lost. Knetworkmanager indicates that no network is present by showing the unplugged icon. Also it shows no scan results. dmesg shows that I disabled radio (attached), but I didn't, and the led tells it's active. There is no reaction whatsoever when switching on and off. Also lspci shows a borked output: 01:00.0 0280: 14e4:4312 (rev ff) (prog-if ff) !!! Unknown header type 7f Kernel is a stock ubuntu 8.04: Linux laptop 2.6.24-19-generic #1 SMP Wed Jun 18 14:15:37 UTC 2008 x86_64 GNU/Linux The computer had gotten through about 5 suspend/resume cycles before the above happened. After a soft reboot the card behaves again. If you think I left out some information, feel free to flame me :) Unless this issue appears again, I will not persuade it further. But if you want me to test something I'll gladly help. regards / Richard ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: FYI: Disabled by hardware, but switch is on
Richard Jonsson skrev: (originally sent July 12 from a different mail addy, apparently the mail didn't make it then, but I got a copy back.. also I see at least one message didn't get delivered to me from berlios) Just to clarify I just realized that I didn't get a copy back from berlios at all, but a bcc from my other account, sorry about the noise / Richard ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: More discrepancies in ssb-sprom
You should really take Ehuds advice, Dale. But I fear you can't because you really must have the last word, don't you? Since you pissed off everyone who could possibly help you out, you don't have anything to gain from staying here. I suggest you re-read this discussion and figure out why you get the replies you get. I guess you're welcome back when you've learned to behave and keep a decent discussion level. Until then, Richard ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: wireless trouble (bcm43xx)
Florin Acatrinei skrev: Hi, I'm new to Linux and I'm having trouble with my wireless NIC. To be precise i don't have the firmware for my NIC. Nothing on the web for me(nothing that I've found). The Ethernet card is ok but I need my wireless up and running. Thanks for your time. Hi! If you indeed have a broadcom device, you will find your questions answered here: http://wireless.kernel.org/en/users/Drivers/b43 hth, Richard ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: sucess with HP-laptop dv6057ea
Michael Buesch skrev: On Monday 12 May 2008 22:42:51 Richard Jonsson wrote: Michael Buesch skrev: On Monday 12 May 2008 22:25:50 Richard Jonsson wrote: If the bug worked with earlier kernels, but has since stopped working, a bisection is of great value. If the _driver_ worked with earlier... Probably :) Maybe somebody might also complain about a bug that stopped working :P Oops, well, that's for tomorrow. I'll see if I can get it up on linuxwireless.org, or if I need to ask someone to add it for me. It's a wiki. Just register and add it. It's added now. I changed it slightly, maybe someone should see if the text makes sense. http://linuxwireless.org/en/users/Drivers/b43#bugreporting http://linuxwireless.org/en/users/Drivers/b43/faq#Q.3AIfoundabuginthedriver.2Cnowwhat.3F ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: sucess with HP-laptop dv6057ea
Michael Buesch skrev: On Monday 12 May 2008 18:06:51 Richard Jonsson wrote: A) Start a mailing list bcm43xx-users with a nicer and more forgiving tone that doesn't scare away bug reporters and testers. Creating a new mainlinglist won't help anyone. It will just split up developers and users to seperate lists. That's the opposite of what you want. Agreed B) If it's not already done, on linux-wireless / b43 site: Tell how to report bugs, with directions on what info is relevant. Feel free to write a bug-report HOWTO. I'm not sure I am the right person for this task, as I can't file a proper report myself :) Something like this? In qa section: Q: I found a bug in the driver, now what? A: See link to topic Bug reporting --- topic Bug reporting: Bug reporting You should send a message to the b43/b43legacy mailinglist at [EMAIL PROTECTED] containing ALL of the following: A description of the problem at hand: * When does it happen. * How to reproduce * If performance is poor; What environment is your wlan in, walls, distance etc. uname -a lspci -vvn|grep 43 -A7 dmesg wlan configuration, authentication/encryption type In addition this may be of interest to the developers: If you have built the kernel from git: Tell which tree, and the output of git describe If the bug is a regression, ie the driver worked with earlier kernels, but stopped working, a bisection is of great value. (I probably missed a few relevant points) C) Set up a bug report form on linux-wireless/b43 site that force needed info to be included. Cool. Please implement that. Was afraid of that answer, don't have the resources atm, maybe later, no promises. Also I don't know what drives that site. And maintenance != me Testers is one of the most needed resource in software development, why throw it all away with hostility. I've seen a lot of that on this list, which in comparison to lkml is a nightmare No wait. LKML is the actual nightmare. It's one of the best examples for the worst mailinglist ever. ;) On LKML I find no question is to stupid to be answered in a polite manner. OTOH it's a nightmare traffic wise. To be fair I know exactly how frustrating it is to get incomplete reports over and over again. Maybe I'm naive to think it can be worked around and minimized. Yeah well. People should read the list archives or use google before asking questions. The traffic could be reduced by 50%. The signal/noise ratio is very bad on this list. Maybe I'm the only person in the world finding it more or less impossible to find anything in mailing list archives, unless you find it through a search engine. Besides most messages on a ML get obsolete very quickly. ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: sucess with HP-laptop dv6057ea
Michael Buesch skrev: On Monday 12 May 2008 22:25:50 Richard Jonsson wrote: If the bug worked with earlier kernels, but has since stopped working, a bisection is of great value. If the _driver_ worked with earlier... Probably :) Maybe somebody might also complain about a bug that stopped working :P Oops, well, that's for tomorrow. I'll see if I can get it up on linuxwireless.org, or if I need to ask someone to add it for me. ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: Tons of interrupts on driver load
Larry Finger skrev: Richard Jonsson wrote: Larry Finger skrev: Richard Jonsson wrote: Larry Finger skrev: If Linus's latest git still has the problem, please do a bisection. I I've now completed the bisection, result below. I'm not really sure this is the bad commit, as v2.6.25 is fine, and this commit is from february. But then again, I don't fully understand how git does it's bisection. I've also tried a few kernels in the 2.6.25-rc series that don't show this problem. That part is not too difficult to understand. When the commit was made in February, it was to the wireless-testing tree for inclusion in 2.6.26. Only when Linus went to the 2.6.25-git kernels in the process of getting to 2.6.26-rc1 did that commit make it to mainline. Oh, I see. Do you have the ssb and b43 debug info from one of the bad kernels? Please post that info from /var/log/messages. It seems as though this problem shows on your system because you have a multi-band device. Attached. To my knowledge this card (4311) has B/G support=2.4GHz only, whereas 4312 has A/B/G support=2.4/5GHz. In a previous post, you gave the following output: [EMAIL PROTECTED]:~$ lspci -vv -d :4312 01:00.0 Network controller: Broadcom Corporation BCM4312 802.11a/b/g (rev 01) Subsystem: Hewlett-Packard Company Unknown device 1361 Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast TAbort- TAbort- MAbort- SERR- PERR- Latency: 0, Cache Line Size: 64 bytes Interrupt: pin A routed to IRQ 19 Region 0: Memory at b300 (32-bit, non-prefetchable) [size=16K] Capabilities: access denied Did this come from your computer? If so, the PCI information is that it is as 4312, but the chip id, which is what b43 prints out, identifies it as a 4311. Curious. Yes, this is from my computer, the pci id is 4312. I assumed my card is a 4311 as even bcm43xx driver recognized it as such. My memory is faint, but I seem to recall there were a few posts on the list back then about the confusion. Also if I recall correctly you had the same card then. Also this link lists a few 4311 rev1 cards with pci id=4312 http://bcm-specs.sipsolutions.net/report.cgi/devices/byradio/1 I have no idea as to why the interface is switching from 5 to 2.4 GHz, and back endlessly. Perhaps Michael knows. It is also possible that the bug is in the new mac80211 band API, which isn't used by b43 when the bad commit is backed out. The patch contained in http://lists.berlios.de/pipermail/bcm43xx-dev/2008-April/007423.html should fix the PHY transmission errors, at least it fixed the one that was thrown by a BCM4311/2. I'll try this, does it make sense to apply to mainline, or should I build from wireless-testing? BTW, a patch to fix the LED configuration was submitted earlier today on the linux-wireless mailing list. It should fix the problems you had in getting the proper config. Good to hear. regards, Richard ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: Tons of interrupts on driver load
I have no idea as to why the interface is switching from 5 to 2.4 GHz, and back endlessly. Perhaps Michael knows. It is also possible that the bug is in the new mac80211 band API, which isn't used by b43 when the bad commit is backed out. The patch contained in http://lists.berlios.de/pipermail/bcm43xx-dev/2008-April/007423.html should fix the PHY transmission errors, at least it fixed the one that was thrown by a BCM4311/2. I'll try this, does it make sense to apply to mainline, or should I build from wireless-testing? With the reverted commit b43: Fix bandswitch back in, and the above patch applied the bad behavior is back. This is on mainline. regards, Richard ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: Tons of interrupts on driver load
Michael Buesch skrev:
Please test whether this fixes the regression.
Index: wireless-testing/drivers/net/wireless/b43/main.c
===
--- wireless-testing.orig/drivers/net/wireless/b43/main.c 2008-04-27
17:47:49.0 +0200
+++ wireless-testing/drivers/net/wireless/b43/main.c 2008-04-27
17:47:50.0 +0200
@@ -4308,12 +4308,20 @@ static int b43_wireless_core_attach(stru
if (dev-phy.type == B43_PHYTYPE_A) {
/* FIXME */
b43err(wl, IEEE 802.11a devices are unsupported\n);
err = -EOPNOTSUPP;
goto err_powerdown;
}
+ if (1 /* disable A-PHY */) {
+ /* FIXME: For now we disable the A-PHY on multi-PHY devices. */
+ if (dev-phy.type != B43_PHYTYPE_N) {
+ have_2ghz_phy = 1;
+ have_5ghz_phy = 0;
+ }
+ }
+
dev-phy.gmode = have_2ghz_phy;
tmp = dev-phy.gmode ? B43_TMSLOW_GMODE : 0;
b43_wireless_core_reset(dev, tmp);
err = b43_validate_chipaccess(dev);
if (err)
Vielen Dank! This does the trick. Applied to a clean mainline, and
behaves as mainline without the b43: Fix bandswitch commit.
regards, Richard
___
Bcm43xx-dev mailing list
Bcm43xx-dev@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: Tons of interrupts on driver load
Larry Finger skrev: If Linus's latest git still has the problem, please do a bisection. I I've now completed the bisection, result below. I'm not really sure this is the bad commit, as v2.6.25 is fine, and this commit is from february. But then again, I don't fully understand how git does it's bisection. I've also tried a few kernels in the 2.6.25-rc series that don't show this problem. bb1eeff12d4cd6c706ef9fae340a9c93bb41ad05 is first bad commit commit bb1eeff12d4cd6c706ef9fae340a9c93bb41ad05 Author: Michael Buesch [EMAIL PROTECTED] Date: Sat Feb 9 12:08:58 2008 +0100 b43: Fix bandswitch This fixes bandswitching for the new mac80211 band API. Signed-off-by: Michael Buesch [EMAIL PROTECTED] Signed-off-by: John W. Linville [EMAIL PROTECTED] :04 04 643bf335db6d1a73422b558eb32384d525e8151c 63b464db5df11152d9f98269bf2263e2a1080e2e Mdrivers - $ git bisect log: git-bisect start # good: [4b119e21d0c66c22e8ca03df05d9de623d0eb50f] Linux 2.6.25 git-bisect good 4b119e21d0c66c22e8ca03df05d9de623d0eb50f # bad: [87322bc1b815e0262a703e08c5d5ec0fb68c8352] Merge branch 'master' of git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6 git-bisect bad 87322bc1b815e0262a703e08c5d5ec0fb68c8352 # bad: [9d722c04a4afdc26441ec643dd13dd7c7910cb97] Revert libata: unify mechanism to request follow-up SRST I had to revert a patch here, my harddrive is not found otherwise, unrelated issue. git-bisect bad 9d722c04a4afdc26441ec643dd13dd7c7910cb97 # good: [94adf110402761347838ef1f78cc68c93e394e4b] Revert libata: unify mechanism to request follow-up SRST Same as previous. git-bisect good 94adf110402761347838ef1f78cc68c93e394e4b # bad: [e0e0a67e44ce13e34f553b6ab6377560fa9813f1] iwlwifi: do not register bands with no supported channels git-bisect bad e0e0a67e44ce13e34f553b6ab6377560fa9813f1 # bad: [e0e0a67e44ce13e34f553b6ab6377560fa9813f1] iwlwifi: do not register bands with no supported channels git-bisect bad e0e0a67e44ce13e34f553b6ab6377560fa9813f1 # bad: [903b474efabab6a4ce697063c367afd8e2ad83f3] ath5k: more RF2413 stuff git-bisect bad 903b474efabab6a4ce697063c367afd8e2ad83f3 # bad: [43ba7e958f2ca05e4e9171a15402288419289d71] mac80211: atomically check whether STA exists already git-bisect bad 43ba7e958f2ca05e4e9171a15402288419289d71 # good: [9ae54c8463691b64ca6e6d8680787a6527810984] mac80211: split ieee80211_txrx_result git-bisect good 9ae54c8463691b64ca6e6d8680787a6527810984 # skip: [6f865c0ab9318cd4c357654e460cb4c9aaf23a92] prism54: Convert acl-sem in a mutex git-bisect skip 6f865c0ab9318cd4c357654e460cb4c9aaf23a92 # skip: [5c05863d0346c025a712b57622efe7828b29758e] ipw2200: le*_add_cpu conversion git-bisect skip 5c05863d0346c025a712b57622efe7828b29758e I skipped twice here because kernel would not build, complaining of CONFIG_MAC80211_IBSS_DEBUG undeclared. I enabled that config option for the next build, which would also fail otherwise. I then disabled this option again. # bad: [f8139218b32e9a68fc6779fa0ce45c5078c23c8a] prism54: Convert stats_sem in a mutex git-bisect bad f8139218b32e9a68fc6779fa0ce45c5078c23c8a # bad: [5c1b09581ba91d156ec907f5cbad07d33bf9e2ed] iwlwifi: change iwl-priv iwl_priv * type in iwl-YYY-io.h git-bisect bad 5c1b09581ba91d156ec907f5cbad07d33bf9e2ed # good: [eed0fd2102206bf6108460274c40ee6b8e863369] b43legacy: add definitions for MAC control register git-bisect good eed0fd2102206bf6108460274c40ee6b8e863369 # bad: [bb1eeff12d4cd6c706ef9fae340a9c93bb41ad05] b43: Fix bandswitch git-bisect bad bb1eeff12d4cd6c706ef9fae340a9c93bb41ad05 # good: [4688be308f35f1e0099140a179d95c5e63b2319d] b43legacy: fix B43legacy_WARN_ON macro git-bisect good 4688be308f35f1e0099140a179d95c5e63b2319d # good: [96d510566e4908f77f03ff1436c78ae7162a17d0] mac80211: defer master netdev allocation to ieee80211_register_hw git-bisect good 96d510566e4908f77f03ff1436c78ae7162a17d0 # good: [b9e0b449aef50aabc295e4487a7a030a0d358367] iwlwifi: Update iwlwifi version stamp to 1.2.26 git-bisect good b9e0b449aef50aabc295e4487a7a030a0d358367 regards, Richard ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: Tons of interrupts on driver load
Richard Jonsson skrev: Larry Finger skrev: If Linus's latest git still has the problem, please do a bisection. I I've now completed the bisection, result below. I'm not really sure this is the bad commit, as v2.6.25 is fine, and this commit is from february. But then again, I don't fully understand how git does it's bisection. I've also tried a few kernels in the 2.6.25-rc series that don't show this problem. bb1eeff12d4cd6c706ef9fae340a9c93bb41ad05 is first bad commit commit bb1eeff12d4cd6c706ef9fae340a9c93bb41ad05 Author: Michael Buesch [EMAIL PROTECTED] Date: Sat Feb 9 12:08:58 2008 +0100 b43: Fix bandswitch I reverted the commit above from v2.6.25-4571-g87322bc and b43 now acts normal. from /proc/interrupts: 19: 0267 IO-APIC-fasteoi b43 from dmesg (no phy errors, no reloads): [ 21.449377] ssb: Core 0 found: ChipCommon (cc 0x800, rev 0x11, vendor 0x4243) [ 21.449446] ssb: Core 1 found: IEEE 802.11 (cc 0x812, rev 0x0A, vendor 0x4243) [ 21.449515] ssb: Core 2 found: USB 1.1 Host (cc 0x817, rev 0x03, vendor 0x4243) [ 21.449587] ssb: Core 3 found: PCI-E (cc 0x820, rev 0x01, vendor 0x4243) [ 21.479202] ssb: SPROM revision 2 detected. [ 21.497398] PM: Adding info for ssb:ssb0:0 [ 21.497431] PM: Adding info for ssb:ssb0:1 [ 21.497443] ssb: Sonics Silicon Backplane found on PCI device :01:00.0 [ 21.852393] b43-phy0: Broadcom 4311 WLAN found [ 21.905761] b43-phy0 debug: Found PHY: Analog 4, Type 2, Revision 8 [ 21.905779] b43-phy0 debug: Found Radio: Manuf 0x17F, Version 0x2050, Revision 2 [ 29.254634] input: b43-phy0 as /class/input/input7 [ 29.389874] PM: Adding info for No Bus:ssb0:0 [ 29.466246] PM: Removing info for No Bus:ssb0:0 [ 29.466316] PM: Adding info for No Bus:ssb0:0 [ 29.474993] PM: Removing info for No Bus:ssb0:0 [ 29.475060] PM: Adding info for No Bus:ssb0:0 [ 29.486030] PM: Removing info for No Bus:ssb0:0 [ 29.486102] PM: Adding info for No Bus:ssb0:0 [ 29.494083] PM: Removing info for No Bus:ssb0:0 [ 29.609875] b43-phy0: Loading firmware version 351.126 (2006-07-29 05:54:02) [ 29.609885] b43-phy0 warning: You are using an old firmware image. Support for old firmware will be removed in July 2008. [ 29.609890] b43-phy0 warning: You must go to http://linuxwireless.org/en/users/Drivers/b43#devicefirmware and download the latest firmware (version 4). [ 30.534466] b43-phy0 debug: Chip initialized [ 30.534725] b43-phy0 debug: 32-bit DMA initialized [ 30.570356] b43-phy0 debug: Wireless interface started [ 30.570362] b43-phy0 debug: Adding Interface type 2 [ 30.570386] b43-phy0: Radio hardware status changed to DISABLED [ 30.653921] b43-phy0: Radio turned on by software [ 30.653930] b43-phy0: The hardware RF-kill button still turns the radio physically off. Press the button to turn it on. regards, Richard ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: Tons of interrupts on driver load
Larry Finger skrev: Richard Jonsson wrote: Larry Finger skrev: Richard Jonsson wrote: flipping switch a few times, led unchanged [ 1534.770048] b43-phy0: Radio hardware status changed to ENABLED [ 1550.778511] b43-phy0: Radio hardware status changed to DISABLED [ 1562.783474] b43-phy0: Radio hardware status changed to ENABLED [ 1565.788237] b43-phy0: Radio hardware status changed to DISABLED This sounds like an rfkill/led configuration problem. In your .config, you should have CONFIG_MAC80211_LEDS=y CONFIG_RFKILL=m CONFIG_RFKILL_INPUT=m CONFIG_RFKILL_LEDS=y CONFIG_B43_LEDS=y CONFIG_B43_RFKILL=y Confirmed, but the problem for me is how to select MAC80211_LEDS and B43_LEDS. Searching in menuconfig I found this: Symbol: B43_LEDS [=n] Symbol: RFKILL_LEDS [=n] with no more info below them. Then MAC80211_LEDS turned up this: Symbol: MAC80211_LEDS [=n] Prompt: Enable LED triggers Defined at net/mac80211/Kconfig:74 Depends on: NET !S390 MAC80211 LEDS_TRIGGERS Location: - Networking - Networking support (NET [=y]) - Wireless - Generic IEEE 802.11 Networking Stack (mac80211) (MAC80211 [=y]) Selected by: IWL4965_LEDS NETDEVICES !S390 IWL4965 || IWL3945_LEDS NETDEVICES !S390 IWL3945 So without IWL4965 / IWL3945 MAC80211_LEDS can't be selected!! Selecting IWL3945 and IWL3945_LEDS and reloading menuconfig gives me: I duplicate your results from menuconfig; however, the appropriate stanza in net/mac80211/Kconfig is config MAC80211_LEDS bool Enable LED triggers depends on MAC80211 LEDS_TRIGGERS ---help--- This option enables a few LED triggers for different packet receive/transmit events. There is no mention of IWL3945, etc, and only MAC80211 and LEDS_TRIGGERS (discussed below) are needed. CONFIG_MAC80211_LEDS=y CONFIG_RFKILL=m CONFIG_RFKILL_INPUT=m CONFIG_RFKILL_LEDS=n CONFIG_B43_LEDS=y CONFIG_B43_RFKILL=y I still can't enable RFKILL_LEDS because I have no clue as to what else needs to be enabled :/ You get CONFIG_RFKILL_LEDS from Networking - RF Switch subsystem support, which has an M, and the Input layer to RF switch connector in the sub-menu, which also should be M. This section is the one that has LEDS_TRIGGERS. That section has only Input layer to RF switch connector. I tried with make xconfig, same story. I have these set to M, still no option for RFKILL_LEDS show up. I only use menuconfig for systems that don't run X, and have never noticed that the dependencies in the help are messed up there. AFAIK, To clarify, I grabbed those lines from the search feature in menuconfig. When searching for B43_LEDS in xconfig, there are no hits at all. In menuconfig the same search shows up as Symbol: B43_LEDS [=n] with no more info. the Kconfig files are OK, and the problem is in menuconfig's parsing of those files. I grepped the .config and see that B43_RFKILL is somehow enabled. I don't think I had LED_TRIGGERS enabled before. The led now reacts to the switch, thanks! regards, Richard ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: Tons of interrupts on driver load
Larry Finger skrev: Richard Jonsson wrote: Larry Finger skrev: If Linus's latest git still has the problem, please do a bisection. I I've now completed the bisection, result below. I'm not really sure this is the bad commit, as v2.6.25 is fine, and this commit is from february. But then again, I don't fully understand how git does it's bisection. I've also tried a few kernels in the 2.6.25-rc series that don't show this problem. That part is not too difficult to understand. When the commit was made in February, it was to the wireless-testing tree for inclusion in 2.6.26. Only when Linus went to the 2.6.25-git kernels in the process of getting to 2.6.26-rc1 did that commit make it to mainline. Oh, I see. Do you have the ssb and b43 debug info from one of the bad kernels? Please post that info from /var/log/messages. It seems as though this problem shows on your system because you have a multi-band device. Attached. To my knowledge this card (4311) has B/G support=2.4GHz only, whereas 4312 has A/B/G support=2.4/5GHz. regards, Richard [ 21.435367] ssb: Core 0 found: ChipCommon (cc 0x800, rev 0x11, vendor 0x4243) [ 21.435435] ssb: Core 1 found: IEEE 802.11 (cc 0x812, rev 0x0A, vendor 0x4243) [ 21.435505] ssb: Core 2 found: USB 1.1 Host (cc 0x817, rev 0x03, vendor 0x4243) [ 21.435575] ssb: Core 3 found: PCI-E (cc 0x820, rev 0x01, vendor 0x4243) [ 21.459105] ssb: SPROM revision 2 detected. [ 21.489484] PM: Adding info for ssb:ssb0:0 [ 21.489504] PM: Adding info for ssb:ssb0:1 [ 21.489515] ssb: Sonics Silicon Backplane found on PCI device :01:00.0 [ 21.877727] b43-phy0: Broadcom 4311 WLAN found [ 21.937251] b43-phy0 debug: Found PHY: Analog 4, Type 2, Revision 8 [ 21.937272] b43-phy0 debug: Found Radio: Manuf 0x17F, Version 0x2050, Revision 2 [ 29.557703] input: b43-phy0 as /class/input/input7 [ 29.673737] PM: Adding info for No Bus:ssb0:0 [ 29.727250] PM: Removing info for No Bus:ssb0:0 [ 29.727330] PM: Adding info for No Bus:ssb0:0 [ 29.766160] PM: Removing info for No Bus:ssb0:0 [ 29.766231] PM: Adding info for No Bus:ssb0:0 [ 29.770747] PM: Removing info for No Bus:ssb0:0 [ 29.770818] PM: Adding info for No Bus:ssb0:0 [ 29.787375] PM: Removing info for No Bus:ssb0:0 [ 29.906425] b43-phy0: Loading firmware version 351.126 (2006-07-29 05:54:02) [ 29.906436] b43-phy0 warning: You are using an old firmware image. Support for old firmware will be removed in July 2008. [ 29.906440] b43-phy0 warning: You must go to http://linuxwireless.org/en/users/Drivers/b43#devicefirmware and download the latest firmware (version 4). [ 30.774037] b43-phy0 debug: Chip initialized [ 30.774277] b43-phy0 debug: 32-bit DMA initialized [ 30.793997] PM: Adding info for No Bus:b43-phy0::tx [ 30.794014] Registered led device: b43-phy0::tx [ 30.794024] PM: Adding info for No Bus:b43-phy0::rx [ 30.794036] Registered led device: b43-phy0::rx [ 30.794047] PM: Adding info for No Bus:b43-phy0::radio [ 30.794059] Registered led device: b43-phy0::radio [ 30.794089] b43-phy0 debug: Wireless interface started [ 30.794095] b43-phy0 debug: Adding Interface type 2 [ 30.794110] b43-phy0: Radio hardware status changed to DISABLED [ 30.885777] b43-phy0: Radio turned on by software [ 30.885786] b43-phy0: The hardware RF-kill button still turns the radio physically off. Press the button to turn it on. [ 32.273863] b43-phy0 debug: Switching to 5-GHz band [ 32.273886] b43-phy0 debug: Wireless interface stopped [ 32.273898] PM: Removing info for No Bus:b43-phy0::tx [ 32.273943] PM: Removing info for No Bus:b43-phy0::rx [ 32.273970] PM: Removing info for No Bus:b43-phy0::radio [ 32.274017] b43-phy0 debug: DMA-32 rx_ring: Used slots 0/64, Failed frames 0/0 = 0.0%, Average tries 0.00 [ 32.274053] b43-phy0 debug: DMA-32 tx_ring_AC_BK: Used slots 0/128, Failed frames 0/0 = 0.0%, Average tries 0.00 [ 32.281867] b43-phy0 debug: DMA-32 tx_ring_AC_BE: Used slots 0/128, Failed frames 0/0 = 0.0%, Average tries 0.00 [ 32.289861] b43-phy0 debug: DMA-32 tx_ring_AC_VI: Used slots 0/128, Failed frames 0/0 = 0.0%, Average tries 0.00 [ 32.297862] b43-phy0 debug: DMA-32 tx_ring_AC_VO: Used slots 2/128, Failed frames 0/11 = 0.0%, Average tries 1.00 [ 32.305862] b43-phy0 debug: DMA-32 tx_ring_mcast: Used slots 0/128, Failed frames 0/0 = 0.0%, Average tries 0.00 [ 32.473900] b43-phy0: Loading firmware version 351.126 (2006-07-29 05:54:02) [ 32.473909] b43-phy0 warning: You are using an old firmware image. Support for old firmware will be removed in July 2008. [ 32.473914] b43-phy0 warning: You must go to http://linuxwireless.org/en/users/Drivers/b43#devicefirmware and download the latest firmware (version 4). [ 33.185972] b43-phy0 debug: Chip initialized [ 33.186129] b43-phy0 debug: 32-bit DMA initialized [ 33.206147] PM: Adding info for No Bus:b43-phy0::tx [ 33.206165] Registered led device: b43-phy0::tx [ 33.206175] PM: Adding info
Re: Tons of interrupts on driver load
Pavel Roskin skrev: On Thu, 2008-04-24 at 21:48 +0200, Richard Jonsson wrote: Hello, First some background: I am currently running latest mainline from git. This kernel suffers from a scheduler? I think this question is more suited for LKML. I'm sorry for being a bit vague. I'm just trying to describe the circumstances surrounding the issue. I and others have reported the scheduler oddity to LKML and it's being dealt with. My question to this list could be condensed to: Is it normal that over 25000 interrupts are generated when loading b43, or is the driver or something else broken? I believe you guys are the best suited to answer this question. While trying to find what these hickups come from I ran watch --interval .1 cat /proc/interrupts. I can see there that the b43 disappears, gets unloaded probably, and then reappears. You should probably show the exact contents of /proc/interrupts and provide some details about the systems (architecture, CPU speed, contents of /proc/sched_debug, lspci output, dmesg output). When b43 reappears in the interrupt listing, that line generates some 25000 irq's within a fraction of a second. Is this a bug somewhere or by design? It's possible that the interrupt count is not shown when the driver disappears, but is not reset to 0. Once the interrupt has a handler, the original count is shown. This is on a HP DV2140eu laptop, 1GB ram, amd turion64 TL52 x2 (1600MHz), kubuntu 8.04 broadcom flavor: 4311 $ uname -a Linux laptop 2.6.25 #38 SMP Thu Apr 24 16:45:44 CEST 2008 x86_64 GNU/Linux I was trying to make a testcase, but can't find how to disable networkmanager, nor how to control if from a terminal. Just inactivating knetworkmanager and rmmod b43 results in a segfault. Anyway networkmanager seems to reload the driver periodically for some reason. Probably because it's stupid and unaware that the radio is disabled by hardware button. b43 is loaded, not associated since wired networking is used. $ date cat /proc/interrupts |grep 19: fre apr 25 15:12:50 CEST 2008 19:813 210843 IO-APIC-fasteoi b43 a few moments later: $ date cat /proc/interrupts |grep 19: fre apr 25 15:13:15 CEST 2008 19:813 210843 IO-APIC-fasteoi b43 $ date cat /proc/interrupts |grep 19: fre apr 25 15:13:16 CEST 2008 19:813 210851 IO-APIC-fasteoi b43 $ date cat /proc/interrupts |grep 19: fre apr 25 15:13:17 CEST 2008 19:813 210854 IO-APIC-fasteoi -- b43 reloaded by nm $ date cat /proc/interrupts |grep 19: fre apr 25 15:13:18 CEST 2008 19:856 232101 IO-APIC-fasteoi b43 $ date cat /proc/interrupts |grep 19: fre apr 25 15:13:19 CEST 2008 19:871 236961 IO-APIC-fasteoi $ date cat /proc/interrupts |grep 19: fre apr 25 15:13:20 CEST 2008 19:871 236969 IO-APIC-fasteoi b43 $ date cat /proc/interrupts |grep 19: fre apr 25 15:13:26 CEST 2008 19:871 236969 IO-APIC-fasteoi b43 within a fraction of a second was a slight exaggregation by me, but most of the interrupts happens within a second. regards, Richard ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: Tons of interrupts on driver load
Larry Finger skrev: Richard Jonsson wrote: Pavel Roskin skrev: On Thu, 2008-04-24 at 21:48 +0200, Richard Jonsson wrote: Hello, First some background: I am currently running latest mainline from git. This kernel suffers from a scheduler? I think this question is more suited for LKML. I'm sorry for being a bit vague. I'm just trying to describe the circumstances surrounding the issue. I and others have reported the scheduler oddity to LKML and it's being dealt with. My question to this list could be condensed to: Is it normal that over 25000 interrupts are generated when loading b43, or is the driver or something else broken? I believe you guys are the best suited to answer this question. While trying to find what these hickups come from I ran watch --interval .1 cat /proc/interrupts. I can see there that the b43 disappears, gets unloaded probably, and then reappears. You should probably show the exact contents of /proc/interrupts and provide some details about the systems (architecture, CPU speed, contents of /proc/sched_debug, lspci output, dmesg output). When b43 reappears in the interrupt listing, that line generates some 25000 irq's within a fraction of a second. Is this a bug somewhere or by design? It's possible that the interrupt count is not shown when the driver disappears, but is not reset to 0. Once the interrupt has a handler, the original count is shown. This is on a HP DV2140eu laptop, 1GB ram, amd turion64 TL52 x2 (1600MHz), kubuntu 8.04 broadcom flavor: 4311 $ uname -a Linux laptop 2.6.25 #38 SMP Thu Apr 24 16:45:44 CEST 2008 x86_64 GNU/Linux I was trying to make a testcase, but can't find how to disable networkmanager, nor how to control if from a terminal. Just inactivating knetworkmanager and rmmod b43 results in a segfault. Anyway networkmanager seems to reload the driver periodically for some reason. Probably because it's stupid and unaware that the radio is disabled by hardware button. b43 is loaded, not associated since wired networking is used. $ date cat /proc/interrupts |grep 19: fre apr 25 15:12:50 CEST 2008 19:813 210843 IO-APIC-fasteoi b43 a few moments later: $ date cat /proc/interrupts |grep 19: fre apr 25 15:13:15 CEST 2008 19:813 210843 IO-APIC-fasteoi b43 $ date cat /proc/interrupts |grep 19: fre apr 25 15:13:16 CEST 2008 19:813 210851 IO-APIC-fasteoi b43 $ date cat /proc/interrupts |grep 19: fre apr 25 15:13:17 CEST 2008 19:813 210854 IO-APIC-fasteoi -- b43 reloaded by nm I'm a little confused. Why do you think that b43 was reloaded? Is there I took it for granted since it disappears from the interrupt listing. a corresponding output in dmesg. Oh, I forgot - Ubuntu doesn't enable the ssb or b43 debug output! Larry I use a custom kernel, but I think I turned off b43/ssb debugging some time ago. Anyway dmesg is drowning in this: [ 7389.533848] b43-phy0 warning: You must go to http://linuxwireless.org/en/users/Drivers/b43#devicefirmware and download the latest firmware (version 4). [ 7390.282233] PM: Adding info for No Bus:hw_random [ 7390.993977] PM: Removing info for No Bus:hw_random [ 7391.193935] b43-phy0: Loading firmware version 351.126 (2006-07-29 05:54:02) [ 7391.193947] b43-phy0 warning: You are using an old firmware image. Support for old firmware will be removed in July 2008. [ 7391.193953] b43-phy0 warning: You must go to http://linuxwireless.org/en/users/Drivers/b43#devicefirmware and download the latest firmware (version 4). [ 7392.151174] PM: Adding info for No Bus:hw_random [ 7518.285906] PM: Removing info for No Bus:hw_random [ 7518.485886] b43-phy0: Loading firmware version 351.126 (2006-07-29 05:54:02) [ 7518.485898] b43-phy0 warning: You are using an old firmware image. Support for old firmware will be removed in July 2008. [ 7518.485904] b43-phy0 warning: You must go to http://linuxwireless.org/en/users/Drivers/b43#devicefirmware and download the latest firmware (version 4). [ 7519.254126] PM: Adding info for No Bus:hw_random [ 7519.254195] printk: 2250 messages suppressed. [ 7519.254200] b43-phy0 ERROR: PHY transmission error [ 7519.254255] b43-phy0 ERROR: PHY transmission error [ 7519.254266] b43-phy0 ERROR: PHY transmission error [ 7519.254275] b43-phy0 ERROR: PHY transmission error [ 7519.254285] b43-phy0 ERROR: PHY transmission error [ 7519.254295] b43-phy0 ERROR: PHY transmission error [ 7519.254304] b43-phy0 ERROR: PHY transmission error [ 7519.254313] b43-phy0 ERROR: PHY transmission error [ 7519.254323] b43-phy0 ERROR: PHY transmission error [ 7519.254332] b43-phy0 ERROR: PHY transmission error [ 7519.294071] b43-phy0: Radio hardware status changed to DISABLED [ 7519.294131] PM: Removing info for No Bus:hw_random [ 7519.493955] b43-phy0: Loading firmware version 351.126 (2006-07-29 05:54:02) [ 7519.493968] b43-phy0 warning: You are using an old firmware image
Re: Tons of interrupts on driver load
Michael Buesch skrev: On Friday 25 April 2008 17:21:00 Richard Jonsson wrote: I use a custom kernel, but I think I turned off b43/ssb debugging some time ago. Anyway dmesg is drowning in this: Oh, finally something useful. Great! [ 7389.533848] b43-phy0 warning: You must go to http://linuxwireless.org/en/users/Drivers/b43#devicefirmware and download the latest firmware (version 4). [ 7390.282233] PM: Adding info for No Bus:hw_random [ 7390.993977] PM: Removing info for No Bus:hw_random [ 7391.193935] b43-phy0: Loading firmware version 351.126 (2006-07-29 05:54:02) [ 7391.193947] b43-phy0 warning: You are using an old firmware image. Support for old firmware will be removed in July 2008. [ 7391.193953] b43-phy0 warning: You must go to http://linuxwireless.org/en/users/Drivers/b43#devicefirmware and download the latest firmware (version 4). [ 7392.151174] PM: Adding info for No Bus:hw_random [ 7518.285906] PM: Removing info for No Bus:hw_random [ 7518.485886] b43-phy0: Loading firmware version 351.126 (2006-07-29 05:54:02) [ 7518.485898] b43-phy0 warning: You are using an old firmware image. Support for old firmware will be removed in July 2008. [ 7518.485904] b43-phy0 warning: You must go to http://linuxwireless.org/en/users/Drivers/b43#devicefirmware and download the latest firmware (version 4). [ 7519.254126] PM: Adding info for No Bus:hw_random [ 7519.254195] printk: 2250 messages suppressed. [ 7519.254200] b43-phy0 ERROR: PHY transmission error [ 7519.254255] b43-phy0 ERROR: PHY transmission error [ 7519.254266] b43-phy0 ERROR: PHY transmission error [ 7519.254275] b43-phy0 ERROR: PHY transmission error [ 7519.254285] b43-phy0 ERROR: PHY transmission error [ 7519.254295] b43-phy0 ERROR: PHY transmission error [ 7519.254304] b43-phy0 ERROR: PHY transmission error [ 7519.254313] b43-phy0 ERROR: PHY transmission error [ 7519.254323] b43-phy0 ERROR: PHY transmission error [ 7519.254332] b43-phy0 ERROR: PHY transmission error [ 7519.294071] b43-phy0: Radio hardware status changed to DISABLED [ 7519.294131] PM: Removing info for No Bus:hw_random [ 7519.493955] b43-phy0: Loading firmware version 351.126 (2006-07-29 05:54:02) [ 7519.493968] b43-phy0 warning: You are using an old firmware image. Support for old firmware will be removed in July 2008. [ 7519.493973] b43-phy0 warning: You must go to http://linuxwireless.org/en/users/Drivers/b43#devicefirmware and download the latest firmware (version 4). [ 7520.230371] PM: Adding info for No Bus:hw_random [ 7520.974090] PM: Removing info for No Bus:hw_random [ 7521.174058] b43-phy0: Loading firmware version 351.126 (2006-07-29 05:54:02) [ 7521.174069] b43-phy0 warning: You are using an old firmware image. Support for old firmware will be removed in July 2008. [ 7521.174074] b43-phy0 warning: You must go to http://linuxwireless.org/en/users/Drivers/b43#devicefirmware and download the latest firmware (version 4). [ 7522.058469] PM: Adding info for No Bus:hw_random [ 7648.318039] PM: Removing info for No Bus:hw_random [ 7648.518013] b43-phy0: Loading firmware version 351.126 (2006-07-29 05:54:02) [ 7648.518025] b43-phy0 warning: You are using an old firmware image. Support for old firmware will be removed in July 2008. [ 7648.518030] b43-phy0 warning: You must go to http://linuxwireless.org/en/users/Drivers/b43#devicefirmware and download the latest firmware (version 4). [ 7649.266421] PM: Adding info for No Bus:hw_random [ 7649.306162] printk: 2287 messages suppressed. [ 7649.306170] b43-phy0 ERROR: PHY transmission error [ 7649.410123] b43-phy0: Radio hardware status changed to DISABLED [ 7650.006181] PM: Removing info for No Bus:hw_random [ 7650.206122] b43-phy0: Loading firmware version 351.126 (2006-07-29 05:54:02) [ 7650.206133] b43-phy0 warning: You are using an old firmware image. Support for old firmware will be removed in July 2008. [ 7650.206138] b43-phy0 warning: You must go to http://linuxwireless.org/en/users/Drivers/b43#devicefirmware and download the latest firmware (version 4). [ 7651.110535] PM: Adding info for No Bus:hw_random [ 7651.122202] b43-phy0: Radio hardware status changed to DISABLED The device is throwing too many PHY errors and the driver decides to restart it. What does happen when you press rfkill? Actually rfkill is on all the time, as in radio disabled. Since you ask about rfkill I should say that the led says wireless enabled (blue light), briefly flashes red twice while the driver reloads. Afaik it should be red as in disabled all the time when disabled. To answer your question: [10364.180078] PM: Adding info for No Bus:hw_random [10364.252000] b43-phy0: Radio hardware status changed to DISABLED -- Flipping the switch -- [10481.471061] b43-phy0: Radio hardware status changed to ENABLED [10491.247684] PM: Removing info for No Bus:hw_random [10491.491674] b43-phy0: Loading firmware version 351.126 (2006-07-29
Re: Tons of interrupts on driver load
Michael Buesch skrev: On Friday 25 April 2008 18:09:27 Richard Jonsson wrote: To add, I thought that my hardware had died judging by the messages above, so I temporarily connected to an access point in the area and could successfully load a few webpages before I disconnected. You really need to be a bit more descriptive with your explanations. How, with which driver on which operating system did you connect to which AP? You need to _talk_ to us and show _logs_. cut'n'paste from earlier in the thread: This is on a HP DV2140eu laptop, 1GB ram, amd turion64 TL52 x2 (1600MHz), kubuntu 8.04 broadcom flavor: 4311 $ uname -a Linux laptop 2.6.25 #38 SMP Thu Apr 24 16:45:44 CEST 2008 x86_64 GNU/Linux Kernel pulled from mainline git yesterday. I use the b43 driver exclusively. The wireless works despite the messages about phy transmission errors the driver prints out. Below is dmesg from moment of killswitch disabled to killswitch enabled, when connecting to an AP. [10738.487135] b43-phy0: Radio hardware status changed to ENABLED [10751.323930] PM: Removing info for No Bus:hw_random [10751.567928] b43-phy0: Loading firmware version 351.126 (2006-07-29 05:54:02) [10751.567940] b43-phy0 warning: You are using an old firmware image. Support for old firmware will be removed in July 2008. [10751.567946] b43-phy0 warning: You must go to http://linuxwireless.org/en/users/Drivers/b43#devicefirmware and download the latest firmware (version 4). [10752.348174] PM: Adding info for No Bus:hw_random [10752.348229] b43-phy0 ERROR: PHY transmission error [10752.391990] b43-phy0 ERROR: PHY transmission error [10752.404023] b43-phy0 ERROR: PHY transmission error [10753.144094] PM: Removing info for No Bus:hw_random [10753.388042] b43-phy0: Loading firmware version 351.126 (2006-07-29 05:54:02) [10753.388053] b43-phy0 warning: You are using an old firmware image. Support for old firmware will be removed in July 2008. [10753.388058] b43-phy0 warning: You must go to http://linuxwireless.org/en/users/Drivers/b43#devicefirmware and download the latest firmware (version 4). [10754.560488] PM: Adding info for No Bus:hw_random [10781.409821] PM: Removing info for No Bus:hw_random [10781.658044] b43-phy0: Loading firmware version 351.126 (2006-07-29 05:54:02) [10781.658057] b43-phy0 warning: You are using an old firmware image. Support for old firmware will be removed in July 2008. [10781.658061] b43-phy0 warning: You must go to http://linuxwireless.org/en/users/Drivers/b43#devicefirmware and download the latest firmware (version 4). [10782.438219] PM: Adding info for No Bus:hw_random [10782.438285] b43-phy0 ERROR: PHY transmission error [10782.481915] b43-phy0 ERROR: PHY transmission error [10782.493957] b43-phy0 ERROR: PHY transmission error [10783.246016] PM: Removing info for No Bus:hw_random [10783.489928] b43-phy0: Loading firmware version 351.126 (2006-07-29 05:54:02) [10783.489940] b43-phy0 warning: You are using an old firmware image. Support for old firmware will be removed in July 2008. [10783.489946] b43-phy0 warning: You must go to http://linuxwireless.org/en/users/Drivers/b43#devicefirmware and download the latest firmware (version 4). [10784.639743] PM: Adding info for No Bus:hw_random [10811.427696] PM: Removing info for No Bus:hw_random [10811.671684] b43-phy0: Loading firmware version 351.126 (2006-07-29 05:54:02) [10811.671695] b43-phy0 warning: You are using an old firmware image. Support for old firmware will be removed in July 2008. [10811.671699] b43-phy0 warning: You must go to http://linuxwireless.org/en/users/Drivers/b43#devicefirmware and download the latest firmware (version 4). [10812.455923] PM: Adding info for No Bus:hw_random [10812.455976] b43-phy0 ERROR: PHY transmission error [10812.499746] b43-phy0 ERROR: PHY transmission error [10812.511780] b43-phy0 ERROR: PHY transmission error [10813.255854] PM: Removing info for No Bus:hw_random [10813.499798] b43-phy0: Loading firmware version 351.126 (2006-07-29 05:54:02) [10813.499808] b43-phy0 warning: You are using an old firmware image. Support for old firmware will be removed in July 2008. [10813.499813] b43-phy0 warning: You must go to http://linuxwireless.org/en/users/Drivers/b43#devicefirmware and download the latest firmware (version 4). [10814.672249] PM: Adding info for No Bus:hw_random [10826.700977] eth0: link down. [10830.532898] PM: Removing info for No Bus:hw_random [10830.772881] b43-phy0: Loading firmware version 351.126 (2006-07-29 05:54:02) [10830.772894] b43-phy0 warning: You are using an old firmware image. Support for old firmware will be removed in July 2008. [10830.772900] b43-phy0 warning: You must go to http://linuxwireless.org/en/users/Drivers/b43#devicefirmware and download the latest firmware (version 4). [10831.561285] PM: Adding info for No Bus:hw_random [10831.561353] b43-phy0 ERROR: PHY transmission error [10831.604949] b43-phy0 ERROR: PHY transmission error [10831.617031] b43-phy0
Re: Tons of interrupts on driver load
Richard Jonsson skrev: Larry Finger skrev: Richard Jonsson wrote: [10493.303801] b43-phy0 warning: You are using an old firmware image. Support for old firmware will be removed in July 2008. [10493.303807] b43-phy0 warning: You must go to http://linuxwireless.org/en/users/Drivers/b43#devicefirmware and download the latest firmware (version 4). [10494.452216] PM: Adding info for No Bus:hw_random -- Restoring the switch to disabled again -- [10506.472673] b43-phy0: Radio hardware status changed to DISABLED and then it goes on as before.. To add, I thought that my hardware had died judging by the messages above, so I temporarily connected to an access point in the area and could successfully load a few webpages before I disconnected. I'm trying to duplicate your setup as closely as possible. I'm running kernel 2.6.25-Linus-git-04569-gb69d398, which is Linus's current git tree. My interface is a BCM4311 rev 2. When I boot up with a wire in eth0 and the rfkill switch off, the dmesg output for networking contains ssb: Core 0 found: ChipCommon (cc 0x800, rev 0x13, vendor 0x4243) ssb: Core 1 found: IEEE 802.11 (cc 0x812, rev 0x0D, vendor 0x4243) ssb: Core 2 found: USB 1.1 Host (cc 0x817, rev 0x04, vendor 0x4243) ssb: Core 3 found: PCI-E (cc 0x820, rev 0x05, vendor 0x4243) input: Power Button (FF) as /class/input/input4 ssb: SPROM revision 3 detected. ssb: Sonics Silicon Backplane found on PCI device :04:00.0 ACPI: Power Button (FF) [PWRF] input: Lid Switch as /class/input/input5 ACPI: Lid Switch [LID0] input: Sleep Button (CM) as /class/input/input6 ACPI: Sleep Button (CM) [SLPB] input: Power Button (CM) as /class/input/input7 ACPI: Power Button (CM) [PWRB] forcedeth: Reverse Engineered nForce ethernet driver. Version 0.61. ACPI: PCI Interrupt Link [LMAC] enabled at IRQ 21 ACPI: PCI Interrupt :00:0a.0[A] - Link [LMAC] - GSI 21 (level, low) - IRQ 21 PCI: Setting latency timer of device :00:0a.0 to 64 mm/memory.c:127: bad pmd 81207808(9090909090909090). b43-phy0: Broadcom 4311 WLAN found b43-phy0 debug: Found PHY: Analog 4, Type 2, Revision 9 b43-phy0 debug: Found Radio: Manuf 0x17F, Version 0x2050, Revision 2 phy0: Selected rate control algorithm 'pid' --snip-- Broadcom 43xx driver loaded [ Features: PLR, Firmware-ID: FW13 ] forcedeth :00:0a.0: ifname eth0, PHY OUI 0x5043 @ 1, addr 00:1d:72:4c:a5:52 forcedeth :00:0a.0: highdma pwrctl mgmt timirq lnktim msi desc-v3 --snip-- udev: renamed network interface wlan0 to eth1 --snip-- input: b43-phy0 as /class/input/input8 b43-phy0: Loading firmware version 410.2160 (2007-05-26 15:32:10) b43-phy0 debug: Chip initialized b43-phy0 debug: 64-bit DMA initialized Registered led device: b43-phy0::tx Registered led device: b43-phy0::rx Registered led device: b43-phy0::radio b43-phy0 debug: Wireless interface started b43-phy0 ERROR: PHY transmission error b43-phy0: Radio hardware status changed to DISABLED b43-phy0 debug: Adding Interface type 2 b43-phy0: Radio turned on by software b43-phy0: The hardware RF-kill button still turns the radio physically off. Press the button to turn it on. Note that I get one PHY ERROR - that is something that shows up for the 64-bit DMA of this card. We don't know if your 4311 is rev 1 or 2. If it is rev 1, then it has 32-bit DMA, and shouldn't get even this one PHY error. When I change the rfkill switch, the radio LED changes from red to blue, and one line is added to the dmesg output b43-phy0: Radio hardware status changed to ENABLED Nothing else happens. When I cause the NM applet to switch from the wired to the wireless interface, I then get the following: eth1: Initial auth_alg=0 eth1: authenticate with AP 00:1a:70:46:ba:b1 eth1: RX authentication from 00:1a:70:46:ba:b1 (alg=0 transaction=2 status=0) eth1: authenticated eth1: associate with AP 00:1a:70:46:ba:b1 eth1: RX AssocResp from 00:1a:70:46:ba:b1 (capab=0x411 status=0 aid=1) eth1: associated eth1: switched to short barker preamble (BSSID=00:1a:70:46:ba:b1) Could you please switch on the debug options for ssb and b43? It will make sorting out this problem a lot easier. Thanks, Larry OK so maybe my card is getting bad after all. It's from a HP DV2140 laptop, and I noticed you message to this list some time ago about HP repair program, I actually got a mail from HP the other day, regarding this. [EMAIL PROTECTED]:~$ lspci -vv -d :4312 01:00.0 Network controller: Broadcom Corporation BCM4312 802.11a/b/g (rev 01) Subsystem: Hewlett-Packard Company Unknown device 1361 Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast TAbort- TAbort- MAbort- SERR- PERR- Latency: 0, Cache Line Size: 64 bytes Interrupt: pin A routed to IRQ 19 Region 0: Memory at b300 (32-bit, non-prefetchable
Re: Tons of interrupts on driver load
OK, after bootup with v2.5.25-rc3-git I get this, looks sane to me: [ 32.474786] b43-phy0: Loading firmware version 351.126 (2006-07-29 05:54:02) [ 32.474797] b43-phy0 warning: You are using an old firmware image. Support for old firmware will be removed in July 2008. [ 32.474802] b43-phy0 warning: You must go to http://linuxwireless.org/en/users/Drivers/b43#devicefirmware and download the latest firmware (version 4). [ 30.137115] warning: `avahi-daemon' uses 32-bit capabilities (legacy support in use) [ 32.774279] PM: Adding info for No Bus:vcs7 [ 32.774317] PM: Adding info for No Bus:vcsa7 [ 31.049445] PM: Adding info for No Bus:hw_random [ 31.062460] b43-phy0: Radio hardware status changed to DISABLED [ 31.773470] b43-phy0: Radio turned on by software [ 31.773475] b43-phy0: The hardware RF-kill button still turns the radio physically off. Press the button to turn it on. [ 45.919959] NET: Registered protocol family 17 [ 54.874707] NET: Registered protocol family 10 [ 54.875253] lo: Disabled Privacy Extensions [ 54.878600] ADDRCONF(NETDEV_UP): wlan0: link is not ready [ 67.096841] eth0: no IPv6 routers present As for the original question I had, interrupts seem sane too. [EMAIL PROTECTED]:~$ cat /proc/interrupts|grep 19: 19: 0185 IO-APIC-fasteoi b43 Forgot to mension that rfkill-led is behaving as I described earlier, and has been for as long as I can remember. I don't have specific kernel versions, sorry. It is always blue, as in wlan active, except if I disable wireless in knetworkmanager. Killswitch doesn't affect the led. disable wireless in knetworkmanager, radio hw disabled, led turns red [ 1333.692522] PM: Removing info for No Bus:event7 [ 1333.716523] PM: Removing info for No Bus:input7 [ 1333.716600] PM: Removing info for No Bus:rfkill0 [ 1333.728542] PM: Removing info for No Bus:hw_random [ 1378.346660] PM: Adding info for No Bus:rfkill1 [ 1378.708529] PM: Adding info for No Bus:input8 [ 1378.708568] input: b43-phy0 as /class/input/input8 [ 1378.757574] PM: Adding info for No Bus:event7 [ 1378.949550] b43-phy0: Loading firmware version 351.126 (2006-07-29 05:54:02) [ 1378.949563] b43-phy0 warning: You are using an old firmware image. Support for old firmware will be removed in July 2008. [ 1378.949567] b43-phy0 warning: You must go to http://linuxwireless.org/en/users/Drivers/b43#devicefirmware and download the latest firmware (version 4). enable wireless again, radio hw still disabled, led turns blue [ 1380.606214] PM: Adding info for No Bus:hw_random [ 1380.685925] b43-phy0: Radio hardware status changed to DISABLED [ 1380.698005] ADDRCONF(NETDEV_UP): wlan0: link is not ready flipping switch a few times, led unchanged [ 1534.770048] b43-phy0: Radio hardware status changed to ENABLED [ 1550.778511] b43-phy0: Radio hardware status changed to DISABLED [ 1562.783474] b43-phy0: Radio hardware status changed to ENABLED [ 1565.788237] b43-phy0: Radio hardware status changed to DISABLED regards, Richard ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: Tons of interrupts on driver load
Here comes a slice of dmesg with debugging turned on. This is from v2.6.25-4571-g87322bc of mainline. Same as before. Richard Jonsson skrev: OK, after bootup with v2.5.25-rc3-git I get this, looks sane to me: [ 32.474786] b43-phy0: Loading firmware version 351.126 (2006-07-29 05:54:02) [ 32.474797] b43-phy0 warning: You are using an old firmware image. Support for old firmware will be removed in July 2008. [ 32.474802] b43-phy0 warning: You must go to http://linuxwireless.org/en/users/Drivers/b43#devicefirmware and download the latest firmware (version 4). [ 30.137115] warning: `avahi-daemon' uses 32-bit capabilities (legacy support in use) [ 32.774279] PM: Adding info for No Bus:vcs7 [ 32.774317] PM: Adding info for No Bus:vcsa7 [ 31.049445] PM: Adding info for No Bus:hw_random [ 31.062460] b43-phy0: Radio hardware status changed to DISABLED [ 31.773470] b43-phy0: Radio turned on by software [ 31.773475] b43-phy0: The hardware RF-kill button still turns the radio physically off. Press the button to turn it on. [ 45.919959] NET: Registered protocol family 17 [ 54.874707] NET: Registered protocol family 10 [ 54.875253] lo: Disabled Privacy Extensions [ 54.878600] ADDRCONF(NETDEV_UP): wlan0: link is not ready [ 67.096841] eth0: no IPv6 routers present As for the original question I had, interrupts seem sane too. [EMAIL PROTECTED]:~$ cat /proc/interrupts|grep 19: 19: 0185 IO-APIC-fasteoi b43 Forgot to mension that rfkill-led is behaving as I described earlier, and has been for as long as I can remember. I don't have specific kernel versions, sorry. It is always blue, as in wlan active, except if I disable wireless in knetworkmanager. Killswitch doesn't affect the led. disable wireless in knetworkmanager, radio hw disabled, led turns red [ 1333.692522] PM: Removing info for No Bus:event7 [ 1333.716523] PM: Removing info for No Bus:input7 [ 1333.716600] PM: Removing info for No Bus:rfkill0 [ 1333.728542] PM: Removing info for No Bus:hw_random [ 1378.346660] PM: Adding info for No Bus:rfkill1 [ 1378.708529] PM: Adding info for No Bus:input8 [ 1378.708568] input: b43-phy0 as /class/input/input8 [ 1378.757574] PM: Adding info for No Bus:event7 [ 1378.949550] b43-phy0: Loading firmware version 351.126 (2006-07-29 05:54:02) [ 1378.949563] b43-phy0 warning: You are using an old firmware image. Support for old firmware will be removed in July 2008. [ 1378.949567] b43-phy0 warning: You must go to http://linuxwireless.org/en/users/Drivers/b43#devicefirmware and download the latest firmware (version 4). enable wireless again, radio hw still disabled, led turns blue [ 1380.606214] PM: Adding info for No Bus:hw_random [ 1380.685925] b43-phy0: Radio hardware status changed to DISABLED [ 1380.698005] ADDRCONF(NETDEV_UP): wlan0: link is not ready flipping switch a few times, led unchanged [ 1534.770048] b43-phy0: Radio hardware status changed to ENABLED [ 1550.778511] b43-phy0: Radio hardware status changed to DISABLED [ 1562.783474] b43-phy0: Radio hardware status changed to ENABLED [ 1565.788237] b43-phy0: Radio hardware status changed to DISABLED regards, Richard ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: Tons of interrupts on driver load
Larry Finger skrev: Richard Jonsson wrote: flipping switch a few times, led unchanged [ 1534.770048] b43-phy0: Radio hardware status changed to ENABLED [ 1550.778511] b43-phy0: Radio hardware status changed to DISABLED [ 1562.783474] b43-phy0: Radio hardware status changed to ENABLED [ 1565.788237] b43-phy0: Radio hardware status changed to DISABLED This sounds like an rfkill/led configuration problem. In your .config, you should have CONFIG_MAC80211_LEDS=y CONFIG_RFKILL=m CONFIG_RFKILL_INPUT=m CONFIG_RFKILL_LEDS=y CONFIG_B43_LEDS=y CONFIG_B43_RFKILL=y Confirmed, but the problem for me is how to select MAC80211_LEDS and B43_LEDS. Searching in menuconfig I found this: Symbol: B43_LEDS [=n] Symbol: RFKILL_LEDS [=n] with no more info below them. Then MAC80211_LEDS turned up this: Symbol: MAC80211_LEDS [=n] Prompt: Enable LED triggers Defined at net/mac80211/Kconfig:74 Depends on: NET !S390 MAC80211 LEDS_TRIGGERS Location: - Networking - Networking support (NET [=y]) - Wireless - Generic IEEE 802.11 Networking Stack (mac80211) (MAC80211 [=y]) Selected by: IWL4965_LEDS NETDEVICES !S390 IWL4965 || IWL3945_LEDS NETDEVICES !S390 IWL3945 So without IWL4965 / IWL3945 MAC80211_LEDS can't be selected!! Selecting IWL3945 and IWL3945_LEDS and reloading menuconfig gives me: CONFIG_MAC80211_LEDS=y CONFIG_RFKILL=m CONFIG_RFKILL_INPUT=m CONFIG_RFKILL_LEDS=n CONFIG_B43_LEDS=y CONFIG_B43_RFKILL=y I still can't enable RFKILL_LEDS because I have no clue as to what else needs to be enabled :/ I think those are all the configuration parameters relating to operation of the LED. If you had the problem related to the HP recall, your interface wouldn't show up in the lspci output. It might be intermittent. Furthermore, if it were present at boot time so that b43 got loaded, and then disappeared, the kernel would abort with the caps lock light flashing at 1 Hz. Thanks for the clarification. Will probably flash the bios at least to prevent a future failure. If Linus's latest git still has the problem, please do a bisection. I had a problem with interrupt routing on my other laptop, which kept it from booting. That problem is now fixed. I thought it only affected the PCMCIA bridges, but there could have been other side affects. I built other kernels in the 2.6.25-git sequence, but never booted any of them till this morning. I will do a bisection then, as the problem is still present. regards, Richard ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Tons of interrupts on driver load
Hello, First some background: I am currently running latest mainline from git. This kernel suffers from a scheduler? issue where keys get stuck and audio skips every now and then. Confirmed to be triggered by a commit named sched: fix fair sleepers. I am currently on wired lan and have the wireless disabled via hardware button. The b43 module is still loaded. While trying to find what these hickups come from I ran watch --interval .1 cat /proc/interrupts. I can see there that the b43 disappears, gets unloaded probably, and then reappears. When b43 reappears in the interrupt listing, that line generates some 25000 irq's within a fraction of a second. Is this a bug somewhere or by design? Note that I wouldn't ever see this if the kernel was behaving as normal. I have no idea if the b43 driver has always behaved like this. I could of course test an older kernel on request. regards, Richard ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: b43 on gutsy using 2.6.24 doesn't work
Peter Diesner skrev: Hi, I downloaded, compiled and installed http://linuxwireless.org/download/compat-wireless-2.6/compat-wireless-2.6.tar.bz2 following the instruction at http://www.linuxwireless.org/en/users/Download. I also installed the firmware from http://mirror2.openwrt.org/sources/broadcom-wl-4.150.10.5.tar.bz2 Now dmesg | grep b43 throws the following messages: [ 39.044712] b43: disagrees about version of symbol ssb_device_is_enabled [ 39.044717] b43: Unknown symbol ssb_device_is_enabled [ 39.044857] b43: disagrees about version of symbol ssb_pcicore_dev_irqvecs_enable [ 39.044859] b43: Unknown symbol ssb_pcicore_dev_irqvecs_enable [ 39.044939] b43: disagrees about version of symbol ssb_bus_may_powerdown [ 39.044941] b43: Unknown symbol ssb_bus_may_powerdown [ 39.045234] b43: disagrees about version of symbol ssb_bus_unregister [ 39.045235] b43: Unknown symbol ssb_bus_unregister Hi Peter, You probably use a kernel that has the option Module versioning support, CONFIG_MODVERSIONS in .config. IMHO you need to disable that option to use modules built after the kernel, or it will spit out those messages. hth, Richard ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: fetching wireless dev
John W. Linville skrev: On Wed, Aug 29, 2007 at 09:54:16PM +0200, Richard Jonsson wrote: [EMAIL PROTECTED]:/usr/src/git/wireless-dev$ git checkout -b everything origin/everything Switched to a new branch everything [EMAIL PROTECTED]:/usr/src/git/wireless-dev$ git branch * everything master [EMAIL PROTECTED]:/usr/src/git/wireless-dev$ git pull Warning: No merge candidate found because value of config option branch.everything.merge does not match any remote branch fetched. No changes. Well, you did just clone the repository -- no new changes since your clone... John Makes sense I guess, but I got this exact message with my cloned tree that was not up to date, including the No changes. part. Anyway, it works now, but the message is still there at the end of the pull command. Thank you for getting me on track. ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
fetching wireless dev
I can't figure out how to keep up to date with the wireless dev tree. I've set up as told by John W. Linville in a post here and use the everything branch. When browsing the tree at kernel.org I see changes from 24'th of august, but my local copy is from 15'th (when I first fetched) even after git fetch. What command am I supposed to use? What is the best practice to apply patches not yet in Linvilles tree? My purpose is to test patches from the list and will probably not do patches myself. Richard ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: fetching wireless dev
Larry Finger skrev: Richard Jonsson wrote: I can't figure out how to keep up to date with the wireless dev tree. I've set up as told by John W. Linville in a post here and use the everything branch. When browsing the tree at kernel.org I see changes from 24'th of august, but my local copy is from 15'th (when I first fetched) even after git fetch. What command am I supposed to use? 'git pull' will get any updates. What is the best practice to apply patches not yet in Linvilles tree? My purpose is to test patches from the list and will probably not do patches myself. The best practice is probably in the eye of the user. What I do is to get the patch text into my wireless-dev tree by downloading or by saving the email containing the patch. If you do the latter, be careful about the white space. Too many mailers change tabs into spaces that kills the application of the patch. To apply patches, I use quilt. With it, you can quilt import the file and apply the patch with quilt push. To remove the patch, use the quilt pop command. In case you do want to write your own patches, start with the quilt new command, then modify the source using the quilt edit command, followed by quilt refresh. You can find a description of quilt from 'man quilt' or on-line. Larry Sorry Larry, I realised I sent you a private copy of this message. --- Thank you both, but with git pull I get this instead: $ git pull Warning: No merge candidate found because value of config option branch.everything.merge does not match any remote branch fetched. A google search turned up one relevant result, but it didn't help. ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: fetching wireless dev
Larry Finger skrev: Richard Jonsson wrote: --- Thank you both, but with git pull I get this instead: $ git pull Warning: No merge candidate found because value of config option branch.everything.merge does not match any remote branch fetched. A google search turned up one relevant result, but it didn't help Did you do the steps that Linville outlined? I reproduce his notes below: /home/linville/git/wireless-dev [linville-t43.mobile]: git branch * master /home/linville/git/wireless-dev [linville-t43.mobile]: git branch -r origin/HEAD origin/adm8211 origin/b43 origin/everything origin/iwlwifi origin/mac80211 origin/master origin/merged-upstream origin/mm-master origin/p54 origin/rt2x00 origin/ssb origin/zd1211rw /home/linville/git/wireless-dev [linville-t43.mobile]: git checkout -b everything origin/everything Switched to a new branch everything /home/linville/git/wireless-dev [linville-t43.mobile]: git branch * everything master Is this what you see with a 'git branch' command? Larry Yes, that's exactly what I see. Just started over with a fresh tree by following Linvilles instructions in this topic/thread. I also typed the additional commands you said, and got the exact same output, reproduced below: [EMAIL PROTECTED]:/usr/src/git$ rm -rf wireless-dev/ [EMAIL PROTECTED]:/usr/src/git$ git clone --reference linux-2.6 git://git.kernel.org/pub/scm/linux/kernel/git/linville/wireless-dev.git wireless-dev Initialized empty Git repository in /usr/src/git/wireless-dev/.git/ remote: Generating pack... remote: Done counting 3229 objects. remote: Deltifying 3229 objects... remote: 100% (3229/3229) done Indexing 3229 objects... remote: Total 3229 (delta 2651), reused 3098 (delta 2614) 100% (3229/3229) done Resolving 2651 deltas... 100% (2651/2651) done Checking 22461 files out... 100% (22461/22461) done [EMAIL PROTECTED]:/usr/src/git$ cd wireless-dev/ [EMAIL PROTECTED]:/usr/src/git/wireless-dev$ git branch * master [EMAIL PROTECTED]:/usr/src/git/wireless-dev$ git branch -r origin/HEAD origin/adm8211 origin/at76 origin/ath5k origin/b43 origin/everything origin/iwlwifi origin/mac80211 origin/master origin/merged-upstream origin/mm-master origin/p54 origin/pending-upstream origin/rt2x00 origin/ssb origin/zd1211rw [EMAIL PROTECTED]:/usr/src/git/wireless-dev$ git checkout -b everything origin/everything Switched to a new branch everything [EMAIL PROTECTED]:/usr/src/git/wireless-dev$ git branch * everything master [EMAIL PROTECTED]:/usr/src/git/wireless-dev$ git pull Warning: No merge candidate found because value of config option branch.everything.merge does not match any remote branch fetched. No changes. [EMAIL PROTECTED]:/usr/src/git/wireless-dev$ ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: b43 and knetworkmanager
On Sunday 19 August 2007 02:45:17 you wrote: On 8/18/07, Richard Jonsson [EMAIL PROTECTED] wrote: On Saturday 18 August 2007 22:17:22 you wrote: It's a bug in mac80211 Ok, is it a known bug, and is there a patch? Should I bother finding it? And finally, is this the wrong list to ask these questions beeing a mac80211 bug? Thanks in advance, Richard ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev I also reported this a few weeks ago, you will note that it is not knetworkmanager specific, also happens with GNOME. Yes I remember, do you know in what circumstances this happens for you? What distro are you using, and are you using a networkmanager? I can poweroff my system properly if I don't attempt to unload the b43 module first. I'm trying to track down where this happens, but I'm not that good, it may take some time. ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
b43 and knetworkmanager
Background: I have this problem with mac80211 based drivers, but not with softmac drivers. When unloading the module rmmod never quits and this message is repeated in dmesg: unregister_netdevice: waiting for eth1 to become free. Usage count = 1 This only happens when logged in to kde, not in a runlevel3 terminal. I have found that knetworkmanager has to do with this. If I have not associated to a network through knetworkmanager, unloading works fine. If I associate once, usage count in dmesg is reported as 1. If I associate 5 times then usage count=5, etc. I believe knetworkmanager or some tool it uses doesn't release a handle, but that brings the question: why does it work with the softmac drivers? Any suggestions how I can proceed to find the broken code? I don't even know if it's knetworkmanagers fault, mac80211, b43 or something else. ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: b43 and knetworkmanager
On Saturday 18 August 2007 22:17:22 you wrote: It's a bug in mac80211 Ok, is it a known bug, and is there a patch? Should I bother finding it? And finally, is this the wrong list to ask these questions beeing a mac80211 bug? Thanks in advance, Richard ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: Does auto-loading of b43 work for you?
On Friday 17 August 2007 01:40:23 Larry Finger wrote: Has anyone used the new driver variation known as b43 from that branch of wireless-dev and gotten auto-loading at bootup of the b43 module on i386 or x86_64 platforms. It still doesn't work here even after upgrading to the latest version of udev. Before I post to LKML regarding this problem, I would like to get an idea if is restricted to my system, or if it is a general problem with x86 architectures. We know it works on PPC platforms. If your system is also failing, I would like to know your distro. Thanks, Larry It does NOT load for me on ubuntu feisty (uptodate). uname -a: Linux richie-laptop 2.6.23-rc3-wlgit-1 #1 SMP Thu Aug 16 18:26:42 CEST 2007 x86_64 GNU/Linux ssb is loaded though.. ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: Port of bcm43xx from softmac to mac80211 is available for testing
On Wednesday 08 August 2007 22:49:17 you wrote: Richard Jonsson wrote: On Monday 06 August 2007 03:21:11 you wrote: Richard Jonsson wrote: Isn't Desired TX power supposed to adapt so that higher bitrates are possible, with Bit Rate going lower if that is not enough to keep a good connection? Richard, Please grab a new copy of the port_to_mac80211 patch, and try the patch below. It boosts the desired power by up to 5 dBm as signal - noise decreases from 20 to 0. Larry Hard to say if there is a difference. I've noticed that signal quality changes between reboots. When I first tried this patch I couldn't get above 36M even at the AP, so I loaded the version without the patch. Same thing. So I rebooted and then all rates worked, even 11M. Even for the driver version that didn't work a few days ago. That is scary! That may mean that something is not being reset. The real question is whether warm reboots are intrinsically different than cold (power-off) reboots. I've power cycled between reboots, unsure if I would get the same results on a soft reset. New/updated observations: Rate scaling seems to work, but if it gets down to 1M it will not rise again unless I force it to a higher bitrate and run iperf for a few seconds before setting it to auto. This is even when signal is -5dBm and noise is -80dBm. I get a feeling it's a bit to sensitive as it will drop quickly at a few meters away. At this distance forced 54M still works well. Maybe this is due to small dips (0.5sec) in traffic flow?! I'm surprised that you get signal values as high as -5 dBm. My maximum is about -35. I'm usually in the -40 range, even at 2 m from the AP. That -5dBm signal is best case when AP's antenna is a few cm from the computers lid. In this position it often reads between -15 - -20dBm. If I move just a cm further away it drops to -30dBm which gradually decreases with distance. With the patch applied power is reported as 27dB in debugfs. With debug_xmitpower dmesg reports desired power to be 16.5 and actual 16.25. This is max when I manually set power through debugfs. After a while it's down to 10dB, even though only 1M works where I sit. Range seems to be higher for B-rates. Maybe this is just how things are, I lack experience. The CCCK (B) encoding is much different than OFDM (G) transmissions. I would not be surprised to learn that its range were longer. The power setting that comes from mac80211 is 27 dBm, which is completely bogus for what is supposed to be the FCC table. The regulatory limit is 20 dBm EIRP (a fancy acronym that means take the antenna into account). I've sent a fix for comment, but as is the usual case for mac80211, it will take several days or weeks to get a response. The maximum power that a bcm43xx device can use is encoded in the sprom. For most of them that quantity is 18.5 dBm, corresponding to the regulatory limit of 20 minus a safety factor of 1.5. I think that is there to prevent setting the power too high and flunking the certification tests. The output that goes to the radio is thus 18.5 less the gain of the antenna, which is also in the sprom with a usual value of 2 dBm. That is why you see the code setting a Desired power of 16.5 dBm. I see! I expected it to go to 18dBm. Initially, I thought that the performance of my BCM4311 fell off as the power increased; however, that no longer happens. As a result, we can push full power at all times and there seems to be no need to use the kind of algorithm that you were testing. Don't tell the FCC, but we could relax IMHO there should eventually be some power scaling, as I understand wlan takes a fair amount of power. Ideally there should be different modes (powersave, performance) preferrably as an API common to all networking, at least wireless. Getting offtopic, just a thought. that upper power limit as we will never try to get the device certified, but then we would use extra power, and run the risk of burning out the radio. If you decide to do that, please tell me the power setting at which it fried! Heh, I might have tried if it was a usb stick ;) Since it's usable and since I got 54M/36M rate under no/high load in winxp under the same circumstances I believe power output is sufficient. With the patches that were pushed into wireless-dev a few minutes ago, I suggest that you try bcm43xx-mac80211. It is getting at least as good, if not better, performance than the BCM4301 or the softmac port to mac80211 drivers do. We would also appreciate as much testing as possible as it will help getting it merged into mainstream. That driver will require V4 firmware. Thanks for your report, Larry Sure, I'll do that. Where do I get a current source? By git? (I forgot to add the mailinglist in the original mail, sorry) ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de
Re: Port of bcm43xx from softmac to mac80211 is available for testing
On Monday 06 August 2007 03:21:11 you wrote: Richard Jonsson wrote: Isn't Desired TX power supposed to adapt so that higher bitrates are possible, with Bit Rate going lower if that is not enough to keep a good connection? Richard, Please grab a new copy of the port_to_mac80211 patch, and try the patch below. It boosts the desired power by up to 5 dBm as signal - noise decreases from 20 to 0. Larry Hard to say if there is a difference. I've noticed that signal quality changes between reboots. When I first tried this patch I couldn't get above 36M even at the AP, so I loaded the version without the patch. Same thing. So I rebooted and then all rates worked, even 11M. Even for the driver version that didn't work a few days ago. New/updated observations: Rate scaling seems to work, but if it gets down to 1M it will not rise again unless I force it to a higher bitrate and run iperf for a few seconds before setting it to auto. This is even when signal is -5dBm and noise is -80dBm. I get a feeling it's a bit to sensitive as it will drop quickly at a few meters away. At this distance forced 54M still works well. Maybe this is due to small dips (0.5sec) in traffic flow?! With the patch applied power is reported as 27dB in debugfs. With debug_xmitpower dmesg reports desired power to be 16.5 and actual 16.25. This is max when I manually set power through debugfs. After a while it's down to 10dB, even though only 1M works where I sit. Range seems to be higher for B-rates. Maybe this is just how things are, I lack experience. ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: Port of bcm43xx from softmac to mac80211 is available for testing
On Sunday 05 August 2007 23:11:33 you wrote: Richard Jonsson wrote: Isn't Desired TX power supposed to adapt so that higher bitrates are possible, with Bit Rate going lower if that is not enough to keep a good connection? It should, but this feature is not yet implemented. I have some test code to do this, but it is not ready. When it is, I'll send you a trial patch. Check if your system has a file names /sys/kernel/debug/bcm43xx/phyX/power_level. If it does, you can write new values for the Desired power into it. Values up to 18 are allowed. I see, and thank you for the tip. I thought power_level was read-only. 11M mode is unusable at all distances, 12M works fine. This probably breaks rate scaling for me. Yes, it certainly would. My 4311 shows a little dip at 11 Mbs, but not as big as yours. Is your AP using b/g mode, or just g mode? What is the make and model of the AP? It's a netgear wgt634u, most recent stable firmware, configured for B/G. rmmod bcm43xx when kde is running hangs rmmod and prevents a clean shutdown. I tried to find which program causes this while using bcm4301 driver, but so far no luck. System shuts down fine if I don't try to rmmod first. rmmod works fine from runlevel 3 aside from this message when inserting module again: net eth1: device_rename: sysfs_create_symlink failed (-17) On my system, I routinely unload the module using 'modprobe -r bcm43xx'. Sometimes, it happens 20 or 30 times between reboots. These are always at runlevel 5. Only once or twice has it not completed. Are you using NetworkManager or using the traditional ifup/ifdown methods? Networkmanager+knetworkmanager. killing these before rmmod doesn't help. Nitpicking: When changing bitrate manually it will not show up with iwconfig before any traffic has occured. This is a mac80211 problem. My original version of the patch that implemented the set rate function loaded the new rate so that it would show up immediately, but that part was nixed. Complain on [EMAIL PROTECTED] Maybe I will. It's not that big of an issue, but still confusing for those unknowing. Sometimes iwconfig link quality shows values in the whole 0-255 range. Do the Signal and Noise levels show -256 dBm at the same time? If so, mac80211 has not received any data. Sometimes signal fluctuates at the same time, noise is pretty much always around -70dBm. I can't recall I've seen it show -256 for this driver. Larry ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: Port of bcm43xx from softmac to mac80211 is available for testing
On Sunday 05 August 2007 01:26:52 Larry Finger wrote: The port of bcm43xx from softmac to mac80211 is available for testing. There are two patch sets that can be downloaded from ftp://lwfinger.dynalias.org/patches and be applied to kernel 2.6.23-rc1 or -rc2, the mainstream git tree (Linus's), and Linville's wireless-2.6 git tree. The two files are ftp://lwfinger.dynalias.org/patches/SSB_Final, which installs the SSB driver, and ftp://lwfinger.dynalias.org/patches/port_to_mac80211, which has the changes for the bcm43xx driver. The resulting driver will use V3 firmware. These patches are similar to the 4301 test driver that was circulated earlier. The major change is that the earlier version was trying to set the power too low. Once that was fixed, performance has become quite good, as shown below. I'm still working on the power setup, which may help the BCM4306. Transker rates (xmit/recv in Mbs), obtained by using an Iperf server on my LAN Bit Rate BCM4311 BCM4318 BCM4306 set (Mbs) 1 1.17/8.66 1.22/9.39 1.22/3.73 2 1.96/11.2 1.98/12.5 1.90/4.98 5.5 4.15/17.7 4.19/17.7 3.98/5.09 6 4.86/17.3 4.86/19.9 2.66/4.94 9 6.58/17.7 6.56/19.9 3.26/5.01 116.57/14.2 6.54/18.5 6.07/5.20 1810.7/19.6 10.7/20.2 4.74/5.05 2412.6/19.6 12.8/20.0 4.12/5.34 3616.2/20.1 15.9/20.1 4.76/4.90 4817.9/20.0 15.1/19.6 3.70/4.18 5419.0/19.8 15.1/20.0 1.83/2.64 These results look rather good for the later models - my BCM4306 has a PHY rev of 1. On this version, much more is required in the PHY setup, and we clearly have more work for that device. Please let me know of any problems in applying the patches, or any oops's that occur. Larry I have tried these patches on 2.6.23-rc2 and find perceived performance to be about the same as for the bcm4301 mac80211 driver. I use this script to stresstest the connection: iperf -c 192.168.0.1 -t 3600 /dev/null watch --interval .1 dmesg|grep phy[0-9]|tail -n1 \ ifconfig eth1 \ iwconfig eth1 21 iwconfig: eth1 IEEE 802.11g ESSID:NETGEAR Mode:Managed Frequency:2.442 GHz Access Point: 00:0F:B5:3D:4B:E2 Bit Rate=2 Mb/s Retry min limit:7 RTS thr:off Fragment thr=2346 B Encryption key:off Link Quality=65/100 Signal level=-60 dBm Noise level=-70 dBm Rx invalid nwid:0 Rx invalid crypt:0 Rx invalid frag:0 Tx excessive retries:0 Invalid misc:0 Missed beacon:0 dmesg|grep TX power [ 755.816434] bcm43xx-phy0 debug: Current TX power output: 10.25 dBm, Desired TX power output: 10.0 dBm [ 763.339286] bcm43xx-phy0 debug: Current TX power output: 9.0 dBm, Desired TX power output: 10.0 dBm [ 770.840137] bcm43xx-phy0 debug: Current TX power output: 10.50 dBm, Desired TX power output: 10.0 dBm [ 778.343126] bcm43xx-phy0 debug: Current TX power output: 9.0 dBm, Desired TX power output: 10.0 dBm [ 785.842109] bcm43xx-phy0 debug: Current TX power output: 10.50 dBm, Desired TX power output: 10.0 dBm [ 793.347213] bcm43xx-phy0 debug: Current TX power output: 10.25 dBm, Desired TX power output: 10.0 dBm Isn't Desired TX power supposed to adapt so that higher bitrates are possible, with Bit Rate going lower if that is not enough to keep a good connection? When next to AP I get 54Mbps when connection is idle or has low utilisation, but when running iperf the Bit rate instantly changes to 1Mbps. While running iperf it jumps between 1, 2, 5.5 and 11Mbps. When manually setting it to 54M it will work with good thoughput. I think it fails at 11M and starts over from 1 again. Performance next to AP (iperf -c 192.168.0.1): 1M 721K 2M 1.64M 5.5M3.72M 6M 5.66M 9M 7.62M 11M --- 12M 9.28M 18M 11.9M 24M 14.0M 36M 17.2M 48M 18.5M 54M 18.4M auto451K When 10 meters away from AP anything higher than 5.5 is unusable, often 5.5M too. 11M mode is unusable at all distances, 12M works fine. This probably breaks rate scaling for me. rmmod bcm43xx when kde is running hangs rmmod and prevents a clean shutdown. I tried to find which program causes this while using bcm4301 driver, but so far no luck. System shuts down fine if I don't try to rmmod first. rmmod works fine from runlevel 3 aside from this message when inserting module again: net eth1: device_rename: sysfs_create_symlink failed (-17) Nitpicking: When changing bitrate manually it will not show up with iwconfig before any traffic has occured. Sometimes iwconfig link quality shows values in the whole 0-255 range. ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: Patch for bcm4301 driver (PHY and radio from bcm43xx, uses mac80211 as MAC layer)
Please enter the command 'echo 1 /sys/kernel/debug/bcm43xx/phyX/debug_xmitpower', where X is the correct value. It will start at 0 when just booted and increase by 1 each time the modules is reloaded. Send me the TX power output from dmesg. Larry Just for reference: For me /sys/kernel/debug was empty, although I had all required settings in the kernel. Turns out debugfs needs to be mounted, obvious to most, but not to me. Maybe this is handled automatically for most distros. Run mount debugfs -t debugfs /sys/kernel/debug and it should work. ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: Patch for bcm4301 driver (PHY and radio from bcm43xx, uses mac80211 as MAC layer)
I found the problem. I didn't have CONFIG_DEBUG_FS which seems to be needed. IMHO it should be selected automatically when debug is selected. With debug_fs enabled I can remove and insert the module, scan network and associate just fine. When 0-4 meters away from AP I get a steady rate of 18.5Mbps with iperf. When walking further away the transmission stops completely. This is when module is loaded and interface brought up next to the AP. I then get 54Mbit connection. When loading the module from 5 metres away I get 1Mbit connection which is not very stable, but still usable. Rate doesn't seem to change when signal drops. If it were I'm sure bcm4301 would be on par or better than the driver for that other os. I feel it's very close with this driver. I've never got more than 500kbit TX speed with the bcm43xx driver. Keep up the good work! ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
