ssb: Core 0 found: ChipCommon (cc 0x800, rev 0x04, vendor 0x4243)
ssb: Core 1 found: IEEE 802.11 (cc 0x812, rev 0x05, vendor 0x4243)
MAC core ID
MAC core revision
According to
On Monday 17 December 2007 08:17:58 [EMAIL PROTECTED] wrote:
On Dec 17, 2007 1:52 AM, Larry Finger [EMAIL PROTECTED] wrote:
One major difference between bcm43xx-SoftMAC and b43-mac80211 is that the
former always used a fixed
rate; whereas mac80211 tries to adjust the bit rate according
On Monday 17 December 2007 02:46:29 Robert Allerstorfer wrote:
On Thu, 13 Dec 2007, 00:20 GMT+01 Michael Buesch wrote:
On Wednesday 12 December 2007 23:48:10 Robert Allerstorfer wrote:
Before starting wpa_supplicant:
[EMAIL PROTECTED] ~]# dmesg | egrep 'b43|ssb|wlan0|wmaster0'
ssb:
On Mon, 17 Dec 2007, 10:05 GMT+01 Johannes Berg wrote:
ssb: Core 1 found: IEEE 802.11 (cc 0x812, rev 0x05, vendor 0x4243)
MAC core ID
MAC core revision
The MAC core revision is =5 so you need b43.
Thank you for making this
On Mon, 17 Dec 2007, 11:00 GMT+01 Michael Buesch wrote:
On Monday 17 December 2007 02:46:29 Robert Allerstorfer wrote:
The strange thing is that the b43-phy0 debug: !WARNING!... line
disappeared from the dmesg output after I replaced ssb.ko by a
self-compiled version (and - of course -
On Monday 17 December 2007 13:49:00 Robert Allerstorfer wrote:
On Mon, 17 Dec 2007, 11:00 GMT+01 Michael Buesch wrote:
On Monday 17 December 2007 02:46:29 Robert Allerstorfer wrote:
The strange thing is that the b43-phy0 debug: !WARNING!... line
disappeared from the dmesg output after I
On Mon, 17 Dec 2007, 13:53 GMT+01 Michael Buesch wrote:
On Monday 17 December 2007 13:49:00 Robert Allerstorfer wrote:
After
rebooting several times, the output of dmesg | egrep
'b43|ssb|wlan0|wmaster0' sometimes contains such a warning line and
sometimes it doesn't.
Expected. So try the
On Monday 17 December 2007 14:43:37 Robert Allerstorfer wrote:
On Mon, 17 Dec 2007, 13:53 GMT+01 Michael Buesch wrote:
On Monday 17 December 2007 13:49:00 Robert Allerstorfer wrote:
After
rebooting several times, the output of dmesg | egrep
'b43|ssb|wlan0|wmaster0' sometimes contains
On Mon, 17 Dec 2007, 14:46 GMT+01 Michael Buesch wrote:
On Monday 17 December 2007 14:43:37 Robert Allerstorfer wrote:
But shouldn't setting/unsetting B43_DEBUG only affect the verbosity
level of the kernel messages, but not change any functionality?
No.
Aha, reading the corresponding
On Monday 17 December 2007 15:09:32 Robert Allerstorfer wrote:
On Mon, 17 Dec 2007, 14:46 GMT+01 Michael Buesch wrote:
On Monday 17 December 2007 14:43:37 Robert Allerstorfer wrote:
But shouldn't setting/unsetting B43_DEBUG only affect the verbosity
level of the kernel messages, but not
On Monday 17 December 2007 15:09:32 Robert Allerstorfer wrote:
But shouldn't setting/unsetting B43_DEBUG only affect the
verbosity level of the kernel messages, but not change any
functionality?
No.
So that means enabling Broadcom 43xx debugging may disable
functionality?
You're confused
On Mon, 2007-12-17 at 15:28 +0100, Holger Schurig wrote:
Note that there might be rare situations where turning on debug
messages change functionality: in the case of race-conditions.
I'll leave the explanation of this to your google skills :-)
It is of course a, shall we say, not
Larry Finger wrote:
Ehud Gavron wrote:
...
If I use the kill-switch both the WiFi and the BT LEDs go off.
When I switch back on the BT LED lights but the WiFi does not.
As long as you are using the latest everything branch wireless-2.6, and
rfkill-input is built for
your system, it
Ehud,
One possibility that I didn't think about before is that your LED mapping in
the SPROM has some
quirk that is not handled properly. Please run the following two commands
SSB_SPROM=$(find /sys -name ssb_sprom)
sudo cat $SSB_SPROM sprom.txt
and mail me the file sprom.txt that results.
On Monday 17 December 2007 23:04:37 [EMAIL PROTECTED] wrote:
On Dec 17, 2007 5:35 AM, [EMAIL PROTECTED] wrote:
If this is a mac80211 related problem, then other systems connecting
to the same ap and using mac80211 would also be affected? Like I said
earlier, there are five machines
On Tuesday 18 December 2007 00:12:30 [EMAIL PROTECTED] wrote:
On Dec 17, 2007 5:45 PM, Michael Buesch [EMAIL PROTECTED] wrote:
Ehm, excuse me.
What are you doing exactly? In this thread you told me you have
a device which requires b43:
Well, I'm not sure what you mean by requires
[EMAIL PROTECTED] wrote:
I don't know what happened before, but after a reboot, I can't repeat
the 200 kB/s speed. It's back down to 40 kB/s, just like originally. I
didn't move the laptop, or the ap, the only thing I can think of that
might have changed is the noise level. FWIW, link
Larry, I know I am waking up an old thread, but I have a development I
thought was interesting and I need some guidance.
This device:
03:00.0 Network controller: Broadcom Corporation Dell Wireless 1390
WLAN Mini-PCI Card (rev 01)
quit showing up in fedora 7 and never appeared in fedora 8,
We worked out the SPROM is the same... but here are some interesting twists.
When switched off
1. The LED is switched off by hardware, not b43
2. B43 does send the event as expected but the LED is already off
When switch on
1. The LED is not switched on by hardware
2. B43 does send the event as
A little test code answered my own question. I don't know if this is
the best way to do it, but this patch fixes the problem.
Ehud
--- drivers/net/wireless/b43/rfkill.c.orig 2007-12-17
22:39:31.0 -0700
+++ drivers/net/wireless/b43/rfkill.c 2007-12-17 22:39:54.0 -0700
@@
20 matches
Mail list logo
