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
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
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
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
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
(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,
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
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
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.
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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.
[
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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),
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
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
43 matches
Mail list logo
