This adds some definitions for the MAC Control register
and uses them.
This basically is no functional change.
Signed-off-by: Michael Buesch [EMAIL PROTECTED]
---
John, this can probably be applied for 2.6.25. I don't care much.
This is some pre-work to get to get AP and IBSS working better
This adds some definitions for the MAC Control register
and uses them.
This basically is no functional change.
Signed-off-by: Michael Buesch [EMAIL PROTECTED]
---
This is patch version 2.
Forgot to run a quilt refresh. Sorry.
John, this can probably be applied for 2.6.25. I don't care much
This fixes uploading of the beacon data and writing of the
TIM and DTIM offsets.
Signed-off-by: Michael Buesch [EMAIL PROTECTED]
---
John, this is 2.6.25 stuff.
Index: wireless-2.6/drivers/net/wireless/b43/main.c
===
--- wireless
This fixes the template upload locking.
Signed-off-by: Michael Buesch [EMAIL PROTECTED]
---
John, this is 2.6.25 stuff.
Index: wireless-2.6/drivers/net/wireless/b43/main.c
===
--- wireless-2.6.orig/drivers/net/wireless/b43/main.c
This queues frames flagged as send after DTIM by mac80211
on the special multicast queue. The firmware will take care
to send the packet after the DTIM.
Signed-off-by: Michael Buesch [EMAIL PROTECTED]
---
John, this is 2.6.25 stuff.
Index: wireless-2.6/drivers/net/wireless/b43/b43.h
Use the length of the variable section of the beacon instead of the
whole beacon length for bounds checking.
Signed-off-by: Michael Buesch [EMAIL PROTECTED]
Index: wireless-2.6/drivers/net/wireless/b43/main.c
===
--- wireless-2.6
. They will be fixed later.
Signed-off-by: Michael Buesch [EMAIL PROTECTED]
---
John, as this is a bugfix, it should go into 2.6.24 if still possible.
Index: wireless-2.6/drivers/net/wireless/b43/xmit.c
===
--- wireless-2.6.orig
On Wednesday 02 January 2008 19:52:08 Larry Finger wrote:
Michael Buesch wrote:
This patch fixes the parsing of the RX data header channel field.
The current code parses the header incorrectly and passes a wrong
channel number and frequency for each frame to mac80211.
The FIXMEs added
On Wednesday 02 January 2008 20:37:41 Ehud Gavron wrote:
Happy New Year, Michael!
:)
Yeah, thanks. :)
Happy New Year to everyone on the list.
Let's work on making The Linux Wireless Year (tm) out of it.
--
Greetings Michael.
___
Bcm43xx-dev
On Wednesday 02 January 2008 21:18:29 David Ellingsworth wrote:
While using the b43legacy driver with my 4306 card, wpa_supplicant and
iwconfig both report that the device is busy when trying to switch from
monitor mode to managed mode after having used kismet or airodump-ng. So far
the
.vserver.de with esmtpa (Exim 4.63)
(envelope-from [EMAIL PROTECTED])
id 1JAAl5-0004Yv-Ft; Wed, 02 Jan 2008 21:04:15 +
From: Michael Buesch [EMAIL PROTECTED]
To: bcm43xx-dev@lists.berlios.de,
[EMAIL PROTECTED]
Subject: Re: Device busy error
Date: Wed, 2 Jan 2008 22:03:40 +0100
This will make sure that always the correct core is selected, even if
there are both a PCI and PCI-E core on a PCI or PCI-E card.
Signed-off-by: Michael Buesch [EMAIL PROTECTED]
---
John, as this is a bugfix it should probably go into 2.6.24.
Index: wireless-2.6/drivers/ssb/scan.c
This adds the PCI ID 0x4329 for the BCM43XG.
Signed-off-by: Michael Buesch [EMAIL PROTECTED]
---
John, this is stuff for 2.6.25
Index: wireless-2.6/drivers/ssb/b43_pci_bridge.c
===
--- wireless-2.6.orig/drivers/ssb
simply remove the BROKEN dependency
and enable the option in the kernel config.
Signed-off-by: Michael Buesch [EMAIL PROTECTED]
---
2.6.25 stuff.
Index: wireless-2.6/drivers/net/wireless/b43/Kconfig
===
--- wireless-2.6.orig/drivers/net
This fixes all WARN_ON()s in the attach stage.
Signed-off-by: Michael Buesch [EMAIL PROTECTED]
---
This is stuff for 2.6.25
Index: wireless-2.6/drivers/net/wireless/b43/b43.h
===
--- wireless-2.6.orig/drivers/net/wireless/b43/b43
On Friday 04 January 2008, Michael Buesch wrote:
This fixes all WARN_ON()s in the attach stage.
Signed-off-by: Michael Buesch [EMAIL PROTECTED]
---
This is stuff for 2.6.25
I'm sorry, this patch was the wrong one.
I'll immediately send the correct one
This fixes all WARN_ON()s in the attach stage.
Signed-off-by: Michael Buesch [EMAIL PROTECTED]
---
This is stuff for 2.6.25
This is patch version 2. Sorry for the inconvenience.
Index: wireless-2.6/drivers/net/wireless/b43/b43.h
The b43 driver will need an incompatible firmware upgrade, soon.
I'm probably going to do this in 2.6.25 or 2.6.26.
The update will require people to download and extract updated
officially supported firmware. The firmware will be linked to
from the usual place at linuxwireless.org.
The driver
On Sunday 06 January 2008 21:05:23 Hendrik Sattler wrote:
Am Sonntag 06 Januar 2008 schrieb Michael Buesch:
The b43 driver will need an incompatible firmware upgrade, soon.
I'm probably going to do this in 2.6.25 or 2.6.26.
The update will require people to download and extract updated
On Sunday 06 January 2008 22:35:51 Pavel Roskin wrote:
Quoting Michael Buesch [EMAIL PROTECTED]:
see fwpostfix module parameter
Can we please avoid this annoyance this time?
Go and complain at Broadcom please.
--
Greetings Michael.
___
Bcm43xx
On Sunday 06 January 2008 21:34:35 John W. Linville wrote:
On Sun, Jan 06, 2008 at 06:02:38PM +0100, Michael Buesch wrote:
This is needed in order to add support for new devices (N-PHY).
Broadcom changed the ABI of the firmware, so we are forced to also
change the ABI of the driver.
Do
On Sunday 06 January 2008 23:01:00 John W. Linville wrote:
On Sun, Jan 06, 2008 at 10:38:43PM +0100, Michael Buesch wrote:
On Sunday 06 January 2008 22:35:51 Pavel Roskin wrote:
Quoting Michael Buesch [EMAIL PROTECTED]:
see fwpostfix module parameter
Can we please avoid
On Monday 07 January 2008 00:28:15 Rafael J. Wysocki wrote:
On Monday, 7 of January 2008, Michael Buesch wrote:
On Sunday 06 January 2008 23:01:00 John W. Linville wrote:
On Sun, Jan 06, 2008 at 10:38:43PM +0100, Michael Buesch wrote:
On Sunday 06 January 2008 22:35:51 Pavel Roskin wrote
On Monday 07 January 2008 00:51:55 Rafael J. Wysocki wrote:
On Monday, 7 of January 2008, Michael Buesch wrote:
On Monday 07 January 2008 00:28:15 Rafael J. Wysocki wrote:
On Monday, 7 of January 2008, Michael Buesch wrote:
On Sunday 06 January 2008 23:01:00 John W. Linville wrote
On Monday 07 January 2008 01:12:25 Rafał Miłecki wrote:
2008/1/7, Michael Buesch [EMAIL PROTECTED]:
People don't want N-PHY support?
Well, if your definition of people is similar to my one, they
definitely want it! :-) I think we are just a little afraid of
_possible_ problem with a few
This adds the initval filenames for the N-PHY firmware.
Signed-off-by: Michael Buesch [EMAIL PROTECTED]
---
Stuff for 2.6.25
Index: wireless-2.6/drivers/net/wireless/b43/main.c
===
--- wireless-2.6.orig/drivers/net/wireless/b43
On Tuesday 08 January 2008 16:31:53 David Ellingsworth wrote:
mac80211 supposedly has support for packet injection. Like you however, I
have have not been able to get packet injection to work with the
b43/b43legacy drivers and the developers have expressed that they are not
interested in
On Tuesday 08 January 2008 21:23:18 Daniel wrote:
Hello,
Johannes Berg wrote:
mac80211 has support for packet injection and people say it works.
This is a very good point, mac80211 (if patched) can handle packet
injection.
It should work without any patches.
The patch is in the
This patch adds all register definitions for the N-PHY.
This adds two new files: nphy.h and nphy.c
No functional changes to existing code.
Signed-off-by: Michael Buesch [EMAIL PROTECTED]
---
Stuff for 2.6.25
Index: wireless-2.6/drivers/net/wireless/b43/nphy.h
This fixes a sparse warning about weird locking.
The spinlock is not needed, so simply remove it.
This also adds some sanity checks to the PHY and radio locking
to protect against recursive locking.
Signed-off-by: Michael Buesch [EMAIL PROTECTED]
---
This patch is only compiletime tested
readability/maintainability
+ and slightly hurts runtime performance. Bugfixes for the old firmware
+ are not provided by Broadcom anymore.
+Who: Michael Buesch [EMAIL PROTECTED]
Index: wireless-2.6/drivers/net/wireless/b43/phy.h
On Friday 11 January 2008 17:40:04 Larry Finger wrote:
Michael Buesch wrote:
This patch adds support for new firmware.
Please test this on old and new firmware.
I have tested this patch with old firmware. It seems to work; however my
testing is not complete as
my computer has started
This fixes reading of the high 16 bits of the radio ID
on new devices. 2055 radios want lo16 to be read first.
Signed-off-by: Michael Buesch [EMAIL PROTECTED]
---
For 2.6.25
Index: wireless-2.6/drivers/net/wireless/b43/main.c
Add the register definitions for the Broadcom 2055 N-radio.
Signed-off-by: Michael Buesch [EMAIL PROTECTED]
---
For 2.6.25
Index: wireless-2.6/drivers/net/wireless/b43/nphy.h
===
--- wireless-2.6.orig/drivers/net/wireless/b43
On Sunday 13 January 2008 18:08:57 Alan Stern wrote:
On Sun, 13 Jan 2008, Rafael J. Wysocki wrote:
On Sunday, 13 of January 2008, Michael Buesch wrote:
On Sunday 13 January 2008 00:08:29 Rafael J. Wysocki wrote:
There is a problem with b43_suspend() that it (indirectly) causes
rfkill_unregister(rfk-rfkill);
input_free_polled_device(rfk-poll_dev);
rfk-poll_dev = NULL;
- rfkill_free(rfk-rfkill);
rfk-rfkill = NULL;
}
Acked-by: Michael Buesch [EMAIL PROTECTED]
--
Greetings Michael.
___
Bcm43xx-dev
Add boardflags-high.
Signed-off-by: Michael Buesch [EMAIL PROTECTED]
---
For 2.6.25
Index: wireless-2.6/drivers/ssb/pci.c
===
--- wireless-2.6.orig/drivers/ssb/pci.c 2008-01-09 16:59:33.0 +0100
+++ wireless-2.6/drivers/ssb
On Sunday 13 January 2008 22:20:52 Eric Paris wrote:
inside b43_rfkill_exit() we call rfkill_unregister() which puts the last
reference and frees the rfkill struct. Then just 3 lines later the code
explicitly calls rfkill_free() on the struct we already freed. This
showed up as slub
On Tuesday 15 January 2008 20:15:38 Stefano Brivio wrote:
On Tue, 15 Jan 2008 13:27:42 -0500
Pavel Roskin [EMAIL PROTECTED] wrote:
I have finally found some time and hardware to test it, but the tarball
is overwhelming at its 186M. And the worst thing, the server
disconnected after 30M
On Tuesday 15 January 2008 23:21:40 Michael Buesch wrote:
Yep, the berlios stuff is dropped completely, except the download
section for the fwcutter tarballs. But that may also change in future.
We will announce that on linuxwireless.org.
Actually, I think I will change that _now_.
I'll simply
This adds lots of N-PHY related lookup tables.
Signed-off-by: Michael Buesch [EMAIL PROTECTED]
---
For 2.6.25
Index: wireless-2.6/drivers/net/wireless/b43/tables_nphy.c
===
--- wireless-2.6.orig/drivers/net/wireless/b43
We must reject new incompatible firmware early to avoid
running into strange transmission failures.
Signed-off-by: Michael Buesch [EMAIL PROTECTED]
---
John, this must _only_ be applied to 2.6.24.
2.6.25 does have actual support for the new firmware.
Index: wireless-2.6/drivers/net/wireless
On Wednesday 16 January 2008 17:58:26 Gavin McCullagh wrote:
Hi,
On Wed, 16 Jan 2008, Larry Finger wrote:
Please check that modules rfkill and rfkill-input are configured and loaded
on your system. In your dmesg output, you are missing lines that look like
Registered led device:
On Wednesday 16 January 2008 23:00:09 Gavin McCullagh wrote:
Hi,
On Wed, 16 Jan 2008, Michael Buesch wrote:
dmesg | grep led
produces no output whatsoever.
Can you please post the SPROM data?
$ cat $(find /sys -name ssb_sprom)
[EMAIL PROTECTED]:~# cat $(find /sys
This also adds lots of TODOs. Oh well. Lots of work. :)
Signed-off-by: Michael Buesch [EMAIL PROTECTED]
---
For 2.6.25
Index: wireless-2.6/drivers/net/wireless/b43/nphy.c
===
--- wireless-2.6.orig/drivers/net/wireless/b43/nphy.c
On Sunday 20 January 2008, Rafael J. Wysocki wrote:
Nah, please don't obfuscate the code.
Better add a flag to struct b43_wldev and check that in the few places
that need different behaviour.
I can do that, if you prefer, but that will look worse, IMHO.
I'm pretty sure it won't. We had
On Monday 21 January 2008, Rafael J. Wysocki wrote:
I modified the patch to implement something like this. This still is one big
patch against everything what's necessary. [BTW, in the current version
of the code, b43_resume() may leave wl-mutex locked in the error paths,
which also is fixed
-by: Michael Buesch [EMAIL PROTECTED]
---
John, as we don't support A-PHY operation, yet, we don't need to
apply this patch to 2.6.24. Please queue this patch for 2.6.25.
Index: wireless-2.6/drivers/net/wireless/b43/b43.h
On Tuesday 22 January 2008 00:36:45 Rafael J. Wysocki wrote:
I still don't like this function wrapping.
I'm pretty sure the additional parameter to the function is not
needed. We can check dev-suspend_in_progress to find out
if we are in a up/down or in a suspend/resume cycle.
You're
.
Better safe than sorry.
Signed-off-by: Michael Buesch [EMAIL PROTECTED]
---
John, this bugfix should go into 2.6.24.
Stefano, this must be ported to b43legacy.
Index: wireless-2.6/drivers/net/wireless/b43/main.c
===
--- wireless
We must kill rfkill in any error paths that trigger after rfkill init.
Signed-off-by: Michael Buesch [EMAIL PROTECTED]
---
John, please try to push this for 2.6.24. Seems quite important,
as it leaks resources and might crash the kernel.
Index: wireless-2.6/drivers/net/wireless/b43/main.c
We must kill rfkill in any error paths that trigger after rfkill init.
Signed-off-by: Michael Buesch [EMAIL PROTECTED]
---
John, please try to push this for 2.6.24. Seems quite important,
as it leaks resources and might crash the kernel.
Index: wireless-2.6/drivers/net/wireless/b43legacy
This fixes suspend/resume.
We must not overwrite the MAC addresses on resume. Otherwise
the card won't ACK any packets anymore.
Signed-off-by: Michael Buesch [EMAIL PROTECTED]
---
John, this is a bugfix that makes suspend/resume working. Without this
people need to do an interface up/down
the DMA slots in any DMA
allocation error path.
Signed-off-by: Michael Buesch [EMAIL PROTECTED]
---
This is _not_ only a theoretical problem. I saw a few packets hitting
this race condition.
John, please try to push for 2.6.24, as this is a security fix.
Stefano, this might need porting to legacy
On Thursday 24 January 2008 10:13:01 Johannes Berg wrote:
This also adds a longer delay for waiting for the microcode
to initialize itself. It seems that the current timeout is sufficient
on all available devices, but there's no real reason why we shouldn't
wait for up to one second.
locked by the PM core during suspend/resume cycles. Also, make it
use a suspend-safe method of unregistering device object in the
resume error path.
Signed-off-by: Rafael J. Wysocki [EMAIL PROTECTED]
Acked-by: Michael Buesch [EMAIL PROTECTED]
Maybe we should have global
This fixes four resource leakages.
In any error path we must deallocate the DMA frame slots we
previously allocated by request_slot().
This is done by storing the ring pointers before doing any ring
allocation and restoring the old pointers in case of an error.
Signed-off-by: Michael Buesch
stuff that must be done on init but
not on resume to the start function.
Also zero out filter_flags to make sure we don't have some flags
from a previous instance for a tiny timeframe until mac80211 reconfigures
them.
Signed-off-by: Michael Buesch [EMAIL PROTECTED]
---
This patch is upstream inside
.
It is safe to drop these packets, as the association they belong to
is not guaranteed anymore anyway.
This is a security fix in the sense that it prevents information leakage.
Signed-off-by: Michael Buesch [EMAIL PROTECTED]
---
This patch is upstream inside of the netdev tree.
Index: linux-2.6.24
On Saturday 02 February 2008 04:52:59 [EMAIL PROTECTED] wrote:
On the other hand, I'm going to go out on a limb and suggest that
PERHAPS if you have ANY brainpower left, you include a full dmesg as
well as an lsmod | grep b43 as well as an iwlist wlan0 scan ... or not.
Ok, well. Seems like
If you get a warning in the DMA parse_cookie() function, it's
because you are using too new firmware.
Downgrade your firmware please.
Please read this page _carefully_ an do _exactly_ what it says:
http://www.linuxwireless.org/en/users/Drivers/b43#devicefirmware
There is no human readable
On Saturday 02 February 2008 16:19:43 David Cohen wrote:
Hi,
On Feb 2, 2008 3:33 AM, Larry Finger [EMAIL PROTECTED] wrote:
David Cohen wrote:
Hi,
I think this could be more clear now:
$ sudo modprobe b43
$ no output
dmesg:
[ 3982.440406] b43-phy0: Broadcom 4318 WLAN
On Saturday 02 February 2008 16:47:40 David Cohen wrote:
Hi,
On Feb 2, 2008 11:31 AM, Michael Buesch [EMAIL PROTECTED] wrote:
On Saturday 02 February 2008 16:19:43 David Cohen wrote:
Hi,
On Feb 2, 2008 3:33 AM, Larry Finger [EMAIL PROTECTED] wrote:
David Cohen wrote:
Hi
On Monday 04 February 2008 18:21:42 Matti Viljanen wrote:
Michael Buesch kirjoitti:
On Sunday 03 February 2008 22:15:57 David Cohen wrote:
b43-phy0 ERROR: Fatal DMA error: 0x1000, 0x, 0x,
0x, 0x, 0x
This is a Descriptor Protocol Error
On Monday 04 February 2008, Michael Buesch wrote:
On Monday 04 February 2008 18:21:42 Matti Viljanen wrote:
Michael Buesch kirjoitti:
On Sunday 03 February 2008 22:15:57 David Cohen wrote:
b43-phy0 ERROR: Fatal DMA error: 0x1000, 0x, 0x,
0x, 0x
On Sunday 03 February 2008 22:15:57 David Cohen wrote:
b43-phy0 ERROR: Fatal DMA error: 0x1000, 0x, 0x,
0x, 0x, 0x
This is a Descriptor Protocol Error on the RX DMA engine.
On which architecture are you running the card and how much RAM
do you have?
On Tuesday 05 February 2008 08:14:33 Matti Viljanen wrote:
Try an x86_64 kernel. I bet it will work.
Can you also try the following patch on an i386 kernel?
I didn't think we would ever need to revisit this code; however, our use
of the PIO fall through that hid DMA problems was too
This checks if the DMA address is bigger than what the controller can manage.
It will reallocate the buffers in the GFP_DMA zone in that case.
Signed-off-by: Michael Buesch [EMAIL PROTECTED]
---
John, this is a fix for 2.6.25.
Stefano, this has to be ported to b43legacy.
Index: wireless-2.6
On Thursday 07 February 2008 00:14:31 Greg KH wrote:
On Fri, Jan 25, 2008 at 12:11:45PM +0100, Michael Buesch wrote:
This patch makes suspend/resume work with the b43 driver.
We must not overwrite the MAC addresses in the init function, as this
would also overwrite the MAC on resume
On Thursday 07 February 2008 01:34:10 Aurelien Jarno wrote:
Michael Buesch wrote:
ssb must init after PCI but before the ssb drivers.
Signed-off-by: Michael Buesch mb at bu3sch.de
Cc: Christian Casteyde casteyde.christan at free.fr
Fixes-bug: #9219
Unfortunately this has broken
On Thursday 07 February 2008 10:58:23 Aurelien Jarno wrote:
Michael Buesch a écrit :
On Thursday 07 February 2008 01:34:10 Aurelien Jarno wrote:
Michael Buesch wrote:
ssb must init after PCI but before the ssb drivers.
Signed-off-by: Michael Buesch mb at bu3sch.de
Cc: Christian
On Thursday 07 February 2008 11:41:05 Aurelien Jarno wrote:
On Thu, Feb 07, 2008 at 11:12:13AM +0100, Michael Buesch wrote:
On Thursday 07 February 2008 10:58:23 Aurelien Jarno wrote:
Michael Buesch a écrit :
On Thursday 07 February 2008 01:34:10 Aurelien Jarno wrote:
Michael Buesch
On Friday 08 February 2008 07:45:37 Brian Lavender wrote:
I downloaded the 2.6.24 kernel onto ubuntu gutsy, compiled it, installed the
firmware, but I can't seem to make a connection. The bmc43xx driver
seems to work, but disconnects for some reason. I noticed that while
trying to set the WEP
On Friday 08 February 2008 17:17:10 Guillaume wrote:
Stefano Brivio a écrit :
Sure. You must go to
http://linuxwireless.org/en/users/Drivers/b43#devicefirmware and download
the correct firmware (version 4). Does this ring a bell?
OK ; it's done and it work :-P
I have made a mistake
the .ko for the Firmware-ID:
xxx string.
While the driver might still support other versions of the firmware for backward
compatibility, this will always print out the officially supported version,
which
people _should_ use.
Signed-off-by: Michael Buesch [EMAIL PROTECTED]
---
John, as this has
On Saturday 09 February 2008 08:09:43 Hendrik Sattler wrote:
This has the disadvantage that you have to load the driver to see that it
fails, then unload it, boot a working kernel (if WLAN is the only connection
method), download the right firmware, reboot the wanted kernel.
This is no
This adds the firmware ID to modinfo.
Signed-off-by: Michael Buesch [EMAIL PROTECTED]
---
John, I'd also like to have this in 2.6.25, although it's not strictly
a bugfix. The chance to create regressions is less than zero and it will
help people to get the stuff working.
Stefano poor-patch
This fixes bandswitching for the new mac80211 band API.
Signed-off-by: Michael Buesch [EMAIL PROTECTED]
---
John, for 2.6.26
Index: wireless-2.6/drivers/net/wireless/b43/b43.h
===
--- wireless-2.6.orig/drivers/net/wireless/b43
On Saturday 09 February 2008 13:13:11 Bruno Ribeiro wrote:
Hello,
...
You are using the wrong firmware version.
Grep the list archives, please.
--
Greetings Michael.
___
Bcm43xx-dev mailing list
Bcm43xx-dev@lists.berlios.de
On Saturday 09 February 2008 17:08:00 Larry Finger wrote:
(3) Your udev renaming rules are F**CKED UP. The clue is that iwconfig shows
wlan0-rename. In
addition, as Michael said you have the wrong firmware. If Ubuntu would get
their heads out of their
backsides and enable debugging
On Saturday 09 February 2008 15:40:15 glenn greenfield wrote:
I have built and installed the compat-wireless-2.6 The installation
went fine, the card comes up and even obtains an i.p. but that's where
it ends. dmesg tells me that I have an old firmware version and to
get the latest which I
On Saturday 09 February 2008 17:12:02 Michael Buesch wrote:
On Saturday 09 February 2008 17:08:00 Larry Finger wrote:
(3) Your udev renaming rules are F**CKED UP. The clue is that iwconfig
shows wlan0-rename. In
addition, as Michael said you have the wrong firmware. If Ubuntu would get
On Saturday 09 February 2008 17:21:54 Michael Buesch wrote:
does not include the R, we can easily point him to a to-be-written FAQ
explaining that he needs to enable it in the kernel config.
I started a FAQ.
http://linuxwireless.org/en/users/Drivers/b43/faq
Everybody please add things
The firmware version information should always get printed. Not only
on a debug build.
Signed-off-by: Michael Buesch [EMAIL PROTECTED]
---
John, for 2.6.25
Index: wireless-2.6/drivers/net/wireless/b43/main.c
===
--- wireless-2.6
On Sunday 10 February 2008 01:28:32 Max Eaves wrote:
Dear team,
Wrong firmware version. Read the list archives, please.
--
Greetings Michael.
___
Bcm43xx-dev mailing list
Bcm43xx-dev@lists.berlios.de
On Sunday 10 February 2008 04:22:06 Pedro P wrote:
Hi,
My name is Javier and I'm a new in Linux. I have a problem with my wireless
card Broadcom
(WL-138G V2). The firmware is installed but I can't connect card. Also
NetworkManager
doesn't detect wireless card.
Can You help me?
On Sunday 10 February 2008 04:31:37 Brian Lavender wrote:
Booted kernel with latest firmware and then the older firmware.
Debugging enabled, but not working now!
See messages output.
You installed the wrong firmware.
(Man, I should write an answer script for this. ;) )
Second run
On Sunday 10 February 2008 21:43:48 Fernando Toledo wrote:
El Dom 10 Feb 2008, Michael Buesch escribió:
On Sunday 10 February 2008 09:02:27 Brian Lavender wrote:
On Sat, Feb 09, 2008 at 09:07:52PM -0800, Brian Lavender wrote:
At one point I had the version 3 firmware working, but now
On Monday 11 February 2008 13:22:14 Jörg Sommer wrote:
Hi,
I'm using the b43 driver to connect to a WPA2 encrypted WLAN. When I
enable the kernel option CONFIG_DEBUG_SLAB my connection breaks.
wpa_supplicant can establish the connection and I can make pings or DNS
queries, but downloading a
On Monday 11 February 2008 03:14:57 David Cohen wrote:
On Feb 10, 2008 9:40 PM, Pavel Roskin [EMAIL PROTECTED] wrote:
On Sun, 2008-02-10 at 17:28 -0400, David Cohen wrote:
Hi all,
I'm here again reporting another possible problem with my wireless
card and b43 driver. Please don't
On Tuesday 12 February 2008 20:01:59 Gene Heskett wrote:
On Tuesday 12 February 2008, Michael Buesch wrote:
On Tuesday 12 February 2008 18:48:30 Pavel Roskin wrote:
On Tue, 2008-02-12 at 14:38 -0200, Alan Carvalho de Assis wrote:
Hi,
I am testing kernel 2.6.25-rc1 to get my Broadcom
On Tuesday 12 February 2008 22:05:42 Michael Buesch wrote:
This patch adds QOS support for b43.
Please comment on this and test this.
This patch depends on Johannes' burst time - txop patch being _not_
applied.
One can trivially fix that, though.
Hm, it seems there are two other variables
On Tuesday 12 February 2008 22:05:42 Michael Buesch wrote:
This patch adds QOS support for b43.
Please comment on this and test this.
This patch depends on Johannes' burst time - txop patch being _not_
applied.
One can trivially fix that, though.
+ for (i = 0; i ARRAY_SIZE(wl
On Tuesday 12 February 2008 19:47:47 Alan Carvalho de Assis wrote:
Why this device don't work?
because support for draft-N devices is not yet implemented.
--
Greetings Michael.
___
Bcm43xx-dev mailing list
Bcm43xx-dev@lists.berlios.de
On Tuesday 12 February 2008 18:48:30 Pavel Roskin wrote:
On Tue, 2008-02-12 at 14:38 -0200, Alan Carvalho de Assis wrote:
Hi,
I am testing kernel 2.6.25-rc1 to get my Broadcom Corporation BCM4328
802.11a/b/g/n (rev 03) working.
The device won't work. No matter what you try.
--
Greetings
On Tuesday 12 February 2008 12:33:36 Jörg Sommer wrote:
So ehm. Disable DEBUG_SLAB?
Yes, but I thought this points to an error. Something like usage after
free. No? I thought those DEBUG options are to find bugs.
Well, you said it breaks down on huge throughput only, right?
I'm not so
On Wednesday 13 February 2008 13:07:53 Johannes Berg wrote:
+ if (queue = ARRAY_SIZE(wl-qos_params)) {
+ /* Queue not available or don't support setting
+* params on this queue. Return success to not
+* confuse mac80211. */
+ return 0;
+
This adds support for the high 16 bits of the hostflags.
No functional change.
Signed-off-by: Michael Buesch [EMAIL PROTECTED]
---
John, this is for 2.6.26.
Index: wireless-2.6/drivers/net/wireless/b43/b43.h
===
--- wireless-2.6
On Thursday 14 February 2008 16:45:31 bou.gui wrote:
Hi everyone.
I'm on Ubuntu hardy, with 2.6.24.7 kernel.
I have a trouble when using the make command, as said in this tuto :
http://linuxwireless.org/en/users/Drivers/b43
The make command return a lot of error messages.
Can someone
On Thursday 14 February 2008 17:11:26 bou.gui wrote:
Here are some of the error message :
I need all of the messages. Not just the last messages.
Do this:
make 2err.log
and send me the err.log file.
--
Greetings Michael.
___
Bcm43xx-dev mailing list
901 - 1000 of 1755 matches
Mail list logo
