Re: radio LED says active when radio disabled after resume

2008-11-20 Thread Richard Jonsson
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

2008-11-19 Thread Richard Jonsson
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

2008-11-19 Thread Richard Jonsson
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

2008-11-19 Thread Richard Jonsson
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

2008-11-18 Thread Richard Jonsson
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

2008-07-21 Thread Richard Jonsson
(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

2008-07-21 Thread Richard Jonsson
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

2008-06-27 Thread Richard Jonsson
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)

2008-05-30 Thread Richard Jonsson
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

2008-05-13 Thread Richard Jonsson
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

2008-05-12 Thread Richard Jonsson
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

2008-05-12 Thread Richard Jonsson
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

2008-04-27 Thread Richard Jonsson
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

2008-04-27 Thread Richard Jonsson
 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

2008-04-27 Thread Richard Jonsson
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

2008-04-26 Thread Richard Jonsson
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

2008-04-26 Thread Richard Jonsson
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

2008-04-26 Thread Richard Jonsson
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

2008-04-26 Thread Richard Jonsson

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

2008-04-25 Thread Richard Jonsson
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

2008-04-25 Thread Richard Jonsson
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

2008-04-25 Thread Richard Jonsson
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

2008-04-25 Thread Richard Jonsson
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

2008-04-25 Thread Richard Jonsson
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

2008-04-25 Thread Richard Jonsson
 
 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

2008-04-25 Thread Richard Jonsson
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

2008-04-25 Thread Richard Jonsson
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

2008-04-24 Thread Richard Jonsson
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

2008-03-08 Thread Richard Jonsson
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

2007-08-30 Thread Richard Jonsson
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

2007-08-29 Thread Richard Jonsson
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

2007-08-29 Thread Richard Jonsson
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

2007-08-29 Thread Richard Jonsson
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

2007-08-19 Thread Richard Jonsson
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

2007-08-18 Thread Richard Jonsson
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

2007-08-18 Thread Richard Jonsson
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?

2007-08-17 Thread Richard Jonsson
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

2007-08-09 Thread Richard Jonsson
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

2007-08-08 Thread Richard Jonsson
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

2007-08-06 Thread Richard Jonsson
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

2007-08-05 Thread Richard Jonsson
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)

2007-08-01 Thread Richard Jonsson
 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)

2007-07-31 Thread Richard Jonsson
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