Re: RFC: A workaround for BCM43XX devices with no on-board SPROM
On Thu, 2010-03-18 at 12:46 -0500, Larry Finger wrote: > Michael, > > I'm switching this discussion from the kernel Bugzilla to the lists. > > As you know, but I'm restating for anyone that has not read our previous > discussions, the b43 driver needs to be changed to handle some of the newer > devices do not have an on-board SPROM. It would be trivial to incorporate the > data except for the need to have a unique, reproducible MAC. Where does the data usually come from in these devices? johannes ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: RFC: A workaround for BCM43XX devices with no on-board SPROM
On Thu, 2010-03-18 at 16:10 -0500, Larry Finger wrote: > On 03/18/2010 03:53 PM, Johannes Berg wrote: > > On Thu, 2010-03-18 at 12:46 -0500, Larry Finger wrote: > >> Michael, > >> > >> I'm switching this discussion from the kernel Bugzilla to the lists. > >> > >> As you know, but I'm restating for anyone that has not read our previous > >> discussions, the b43 driver needs to be changed to handle some of the newer > >> devices do not have an on-board SPROM. It would be trivial to incorporate > >> the > >> data except for the need to have a unique, reproducible MAC. > > > > Where does the data usually come from in these devices? > > It comes from the SPROM, which is missing in the devices in question. > Broadcrap > wanted to save a few pennies. Right, but they have to support getting the data somehow on for example windows even if there's no sprom. Do we know where it comes from then? johannes ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: RFC: A workaround for BCM43XX devices with no on-board SPROM
On Thu, 2010-03-18 at 16:20 -0400, John W. Linville wrote: > On Thu, Mar 18, 2010 at 08:31:24PM +0100, Michael Buesch wrote: > > On Thursday 18 March 2010 18:46:35 Larry Finger wrote: > > > > It it reasonable to keep the vendor portion of the MAC and only replace > > > the > > > "serial number", or would it be better to randomize all 6 octants? > > > > I think it doesn't really matter. > > It might be a good idea to set the LAA bit...? And clear the mcast bit :) johannes ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: [PATCH V2] ssb: Add PCI ID 0x4322 to PMU handling
On Sun, 2010-02-21 at 11:53 +0100, Gábor Stefanik wrote: > 2010/2/21 Rafał Miłecki : > > 2010/2/20 Larry Finger : > >> Some of the N PHYs need a revision in the handling of the PMU. > >> > >> Signed-off-by: Larry Finger > >> --- > >> > >> John, > >> > >> This will be needed for some of the N PHY devices - 2.6.34 > amterial. > >> > >> Larry > >> --- > >> > >> V2 - Fix typo in subject line of commit message. > > > > amterial you say? ;) > > Taht's not prat of the cimmot megasse, it is olny a ntoe to Jhon. > Deons't mtater eevn if it is cmolpelety jmulbed up. Geez. The patch is already in the tree anyway, with the original typo. johannes signature.asc Description: This is a digitally signed message part ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: [RFC] How to store HT (40MHz) support
On Wed, 2010-01-20 at 01:06 +0100, Rafał Miłecki wrote: > + if (phy->supports_40mhz) That is useless, if it doesn't support it then you should not advertise it and mac80211 will not use it. > + phy->use_40mhz = conf_is_ht(conf); This is wrong, conf_is_ht might also be 20mhz, look at the other helpers. johannes signature.asc Description: This is a digitally signed message part ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: [PATCH 3/6] b43: N-PHY: add RSSI calculation for PHY rev < 3
On Mon, 2010-01-11 at 23:13 +0100, Michael Buesch wrote:
> No I don't think so.
> It's C standard that uninitialized elements on automatic variables are
> initialized
> to zero, _if_ at least one element is initialized to something.
> So if you init one element to 0, all others will be 0, too.
AFAIK, you don't even have to init anything, since otherwise not
mentioned fields will be set to 0. Hence, just = {} is sufficient for
arrays and will hopefully compile to the same code as an explicit
memset().
johannes
signature.asc
Description: This is a digitally signed message part
___
Bcm43xx-dev mailing list
Bcm43xx-dev@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: [PATCH] b43: add config option to force QoS off
On Mon, 2009-12-14 at 22:43 +0100, Rafał Miłecki wrote: > I believe we ieee80211_register_hw in b43 once but it may happen we > reload firmware while having device still registered. Should we really > ieee80211_unregister_hw and ieee80211_register_hw on every time we > reload firmware (as we may load one with other capabilities)? Afaict the driver never reloads the firmware from userspace, it just reprograms it onto the device, so your question is moot. However, it does register _before_ loading it, the new async work allows it to do it the other way around. johannes signature.asc Description: This is a digitally signed message part ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: [PATCH] b43: add config option to force QoS off
On Sun, 2009-12-13 at 19:17 +0100, Albert Herranz wrote: > > Well, something in mac80211 was changed that breaks this. > > mac80211 currently seems to assume that the number of queues does not change > > after ieee80211_register, which was not the case previously. This breaks > > the QoS disable, because b43 modifies the nr of queues variable in the > > ieee80211_hw structure. > > > >> This patch adds a config option to allow disabling QoS from the beginning. > >> This is the only way to workaround the described problem when building the > >> b43 driver in-kernel, as in that case modparam_qos can't be changed. > >> > >> Signed-off-by: Albert Herranz > > > > Why are we currently adding all kind of workaround patches instead of > > fixing the bugs? > > This bug's been there for months, so I don't see a reason to push out a > > workaround now. > > > > I'm fine not pushing this workaround upstream. I can carry the workaround > locally. > > Is someone (apart from you) aware of this bug and looking at mac80211 to fix > it? I don't even consider it a bug in mac80211. Once you register your capabilities, they're fair game. If you need to register them based on firmware capabilities, load the firmware before you register, like I did with my [RFC] patch to ar9170 (which I'll be sending soon since the required patch is going into mainline). johannes signature.asc Description: This is a digitally signed message part ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: Fatal DMA error problem with netbook and BCM4312
On Sun, 2009-11-22 at 19:52 -0600, Larry Finger wrote: > We know that the wl driver does something to the interface that persists > across > a warm boot - we just do not know what. It does not appear to be done in any > of > the MMIO traffic - at least I have not seen it in the mmio-trace output. If > anyone has a KVM setup using PCI passthrough, it is possible to trace PCI > configuration traffic? I'm pretty sure even the binary driver has to go through drivers/pci/access.c, maybe you can just insert logging into that code? johannes signature.asc Description: This is a digitally signed message part ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: [mmotm 2009-10-09-01-07] b43/wireless possible circular locking
On Sun, 2009-10-11 at 17:41 +0800, Dave Young wrote:
> Hi,
>
> I got lockdep warnings about possible circular lock with
> b43 interface startup. It looks like a real problem.
>
> [ 71.974542] wlan0: deauthenticating from 00:19:e0:db:24:de by local choice
> (reason=3)
> [ 72.004352] b43-phy0 debug: Removing Interface type 2
> [ 72.005431]
> [ 72.005435] ===
> [ 72.006168] [ INFO: possible circular locking dependency detected ]
> [ 72.006759] 2.6.32-rc3-mm1 #4
> [ 72.007047] ---
> [ 72.007617] ifconfig/2175 is trying to acquire lock:
> [ 72.007617] (&(&rfkill->poll_work)->work){+.+...}, at: []
> __cancel_work_timer+0x8c/0x18e
> [ 72.007617]
> [ 72.007617] but task is already holding lock:
> [ 72.007617] (&wl->mutex){+.+.+.}, at: [] b43_op_stop+0x28/0x6a
> [b43]
I believe this is already taken care of by Larry.
johannes
signature.asc
Description: This is a digitally signed message part
___
Bcm43xx-dev mailing list
Bcm43xx-dev@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: [ANN] b43 LP-PHY support (BCM4310/4312/4315) working (partially)!
On Wed, 2009-08-19 at 14:43 +0200, Mark Huijgen wrote: > After running the included python script, patching the cutter and > extracting firmware, I now get ucode version 478.104 in dmesg. Next test > is also without the 2 patches. Following log is from modprobe+ifconfig > wlan0 up: Not really surprising, the firmware is for the MAC _only_, it doesn't really ever touch the PHY, so it's very unlikely to matter. johannes signature.asc Description: This is a digitally signed message part ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: [PATCH] remove wrong probe_resp_plcp write
On Tue, 2009-08-04 at 22:27 +0200, Michael Buesch wrote:
> On Tuesday 04 August 2009 18:05:58 John W. Linville wrote:
> > On Fri, Jul 31, 2009 at 10:38:14PM +0200, Michael Buesch wrote:
> > > On Friday 31 July 2009 22:35:49 gregor kowski wrote:
> > > > The tkip hw support uncovered a bug in b43_write_probe_resp_template :
> > > > it is
> > > > writing at the wrong shm offset, it is in the B43_SHM_SH_TKIPTSCTTAK
> > > > zone. This
> > > > patch comments these writes.
> > > >
> > > > Signed-off-by: Gregor Kowski
> > >
> > > Signed-off-by: Michael Buesch
> >
> > CC [M] drivers/net/wireless/b43/main.o
> > drivers/net/wireless/b43/main.c:1432: warning: ‘b43_write_probe_resp_plcp’
> > defined but not used
> >
> > Comment it out too? Or are you going to fix the block that has been
> > commented-out here?
>
> No, please add
> #if 0
> void b43_write_probe_resp_plcp(...)
> {
> ...
> }
> #endif /* 0 */
>
> to comment out the function, too.
> The probe response offload is currently not supported by mac80211.
Just remove it -- if we need it back we can find it in the git archives,
and it's rather unlikely that we're going to add that functionality to
mac80211 and hostapd unless you'll push it.
johannes
signature.asc
Description: This is a digitally signed message part
___
Bcm43xx-dev mailing list
Bcm43xx-dev@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: mac80211: changing number of queues in ops->start
On Tue, 2009-04-07 at 21:40 +0200, Michael Buesch wrote: > Ok I see. So you say it's OK to lower hw->queues after ieee80211_register. Let's say it's acceptable ;) > Should I reset hw->queues back to the value ieee80211_register was called > with, before > I call unregister/free? Are there resources allocated by the number of queues? There are resources allocated, notably the qdiscs etc. in alloc_ether_mq() or whatever it's called in register_hw(). But the networking core should keep track of those so it shouldn't matter what the value is. OTOH if it can switch back and forth the pending packets are done per queue... for example ieee80211_clear_tx_pending will be called at unregister times, so if it's possible to be up with 4 queues, and later be up with 1, you will want to unregister with 4. johannes signature.asc Description: This is a digitally signed message part ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: mac80211: changing number of queues in ops->start
On Tue, 2009-04-07 at 21:33 +0200, Michael Buesch wrote: > > Well, I suppose you could register with the max and later reduce and > > stop the remaining queues you're not using... Or not stop them and drop > > packets on them. That's somewhat fragile, gives people who look at tc a > > wrong idea, and I can't imagine supporting it, but it should work. > > mkay, I'll try this. thanks :) > > I wonder, however, will mac80211 try to queue packets on queues that are > stopped? > And I think just dropping them is not an option, because this will cause > breakage. > > What about just queueing everything on a single queue, no matter what queue > mac80211 > puts the frame into? Would this cause ordering issues? > Or the other way around, is there anything that _depends_ on the higher > priority queues > to get sent before the higher priority queues? mac80211 won't try to select a queue higher than hw->queues at select_queue time, so it shouldn't try to put packets onto that queue, look in wme.c. johannes signature.asc Description: This is a digitally signed message part ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: mac80211: changing number of queues in ops->start
On Tue, 2009-04-07 at 20:24 +0200, Michael Buesch wrote: > I'm wondering how to implement QoS capability runtime detection > in a mac80211 driver. > > In b43 we don't know at ieee80211_register time whether the firmware does > support QoS or not, because it's not loaded yet. (Reasons for not loading > it that early are issues with builtin-b43, etc...). > So we don't know whether we are going to load opensource fw (no QoS) or > proprietary fw (QoS capable). > But it seems that mac80211 requires to set hw->queues before > ieee80211_register. > > So what I'd need is a way to change the number of possible queues from within > the ops->start handler. Well, I suppose you could register with the max and later reduce and stop the remaining queues you're not using... Or not stop them and drop packets on them. That's somewhat fragile, gives people who look at tc a wrong idea, and I can't imagine supporting it, but it should work. johannes signature.asc Description: This is a digitally signed message part ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: [RFC] b43: rework rfkill code
Marcel, > > We're going to have to integrate rfkill with mac80211, but nobody cares. > > if you figured out on how to do it the best way, then let me know, > because I have to do the same thing for Bluetooth. I've now rewritten rfkill [beep] to [beep] -- the plan for mac80211 now is to have _it_ register the rfkill struct, and let the driver only provide the hard-block state (or a function to poll it where necessary), and handle everything else via the regular config call in mac80211 with radio_enabled. Then mac80211 can also react on unblock by reassociating or whatever. johannes signature.asc Description: This is a digitally signed message part ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: Cardbus wireless cards
On Tue, 2009-02-03 at 19:17 +0100, Gábor Stefanik wrote: > If Hungary does not fall outside the "anyone I can afford shipping > to", then I am interested in the acx111 card. Acx-based cards are > pretty hard to find in Hungary. Heh, should be fine, send me your address in private. johannes signature.asc Description: This is a digitally signed message part ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Cardbus wireless cards
Hi,
Some of you know that I got a new laptop, and it doesn't have a cardbus
slot any more. I still have my powerbook, and it's still working fine,
but I'm not using it any more, it hasn't even booted in a month. I could
test on my powerbook, but given my regular time budget it seems unlikely
that I ever will.
Hence, I'm offering my collection of cardbus/pcmcia wireless test cards
to anyone I can afford shipping to.
* Broadcom PCMCIA (not cardbus, in cardbus slot adapter)
requires external single antenna (u.fl, have one if I can find it)
* Airgo-based Belkin F5D8010 ("true MIMO")
* rt61pci (Conceptronic)
* Broadcom 11n (4321)
* acx111 based card (D-Link AirPlus XTreme G+)
I also have a Broadcom 11g (4306 I think, might be 4318) PCI card
somewhere that I will most likely never again have a use for.
johannes
signature.asc
Description: This is a digitally signed message part
___
Bcm43xx-dev mailing list
Bcm43xx-dev@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: [RFC 7/7] B43N: Add the tx gain table of different version.
On Thu, 2009-01-15 at 09:48 +0800, YanBo wrote:
> > I think you should give these different names, rather than sub-indexing
> > in that array.
> >
>
> Yes, they has been assigned difference names. like below
> +enum b43_nphy_txgain_type {
> + REV_LE2 = 0,/* rev <= 2 */
> + REV_GE3_2G, /* rev >= 3 (2.4 GHz) */
> + REV_E3_5G, /* rev 3 (5 GHz) */
> + REV_GE4_5G, /* rev >= 4 (5 GHz) */
> +};
> But above code was split into patch 4/7 by my mistake.
Yes, but I think you should give them names, not just named array
indexes.
johannes
signature.asc
Description: This is a digitally signed message part
___
Bcm43xx-dev mailing list
Bcm43xx-dev@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: [RFC 4/7] B43N: Add TX power control and gain get function
On Thu, 2009-01-15 at 09:56 +0800, YanBo wrote: > >> + if (sprom->revision < 4) > >> + txpid[0] = txpid[1] = txpid[2] = txpid[3] = 0x48; > > > > 2, 3? This is a little odd. As I say on the wiki, "The txpid values are > > two values, one for each radio core." > > > but why in the specs, it also mentioned txpid5ga, txpid5gl, txpid5gah > and txpid2g, is the three 5g value is just one value in fact? a bit > confuse? No, each of those txpid5ga ... consists of _two_ values, one for each core, that you are supposed to use in that case. johannes signature.asc Description: This is a digitally signed message part ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: [b43] opensource firmware
On Wed, 2009-01-14 at 16:09 -0500, John W. Linville wrote: > On Wed, Jan 14, 2009 at 09:45:22PM +0100, Johannes Berg wrote: > > > > > Initvals and new firmware version can be found at > > > http://www.ing.unibs.it/openfwwf > > > > I suggest that before this is packaged, we change it so b43 can > > recognise it and automatically disable qos and hwcrypto. > > That's a good idea. Is that simply a driver patch? Should be fairly simple, yeah. johannes signature.asc Description: This is a digitally signed message part ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: [b43] opensource firmware
> Initvals and new firmware version can be found at > http://www.ing.unibs.it/openfwwf I suggest that before this is packaged, we change it so b43 can recognise it and automatically disable qos and hwcrypto. johannes signature.asc Description: This is a digitally signed message part ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: [RFC 4/7] B43N: Add TX power control and gain get function
On Wed, 2009-01-14 at 15:58 +0800, YanBo wrote:
> Three functions about tx power control
> b43_nphy_tx_power_fix() b43_nphy_tx_power_coeff_set()
> b43_nphy_tx_power_type_set()
> but remain lots of TODO cause not very clearly understand the SPECS
>
> Signed-off-by: Li YanBo
> ---
> drivers/net/wireless/b43/phy_n.c | 195
> +-
> 1 files changed, 194 insertions(+), 1 deletions(-)
>
> diff --git a/drivers/net/wireless/b43/phy_n.c
> b/drivers/net/wireless/b43/phy_n.c
> index 586e774..1330309 100644
> --- a/drivers/net/wireless/b43/phy_n.c
> +++ b/drivers/net/wireless/b43/phy_n.c
> @@ -82,9 +82,183 @@ static void b43_chantab_phy_upload(struct b43_wldev *dev,
> b43_phy_write(dev, B43_NPHY_BW6, e->phy_bw6);
> }
>
> +enum b43_nphy_txpid {
> + B43_N_5G_MEDIUM_FREQ = 0,
> + B43_N_5G_LOW_FREQ,
> + B43_N_5G_HIGH_FREQ,
> + B43_N_2G_FREQ,
> + /* Attent: currently we just using 2 txpid */
> + B43_N_TXPID_MAX = 2,
> +};
> + u32 txpid[B43_N_TXPID_MAX];
> + int i;
> +
> + if (nphy->havoid)
> + b43_nphy_stay_carrier_search_enable(dev);
> +
> + if (sprom->revision < 4)
> + txpid[0] = txpid[1] = txpid[2] = txpid[3] = 0x48;
2, 3? This is a little odd. As I say on the wiki, "The txpid values are
two values, one for each radio core."
So you should do that B43_N_MAX_CORES == 2.
> + else {
> + /* TODO */
> +/* if (medium freq range, 5100..5499 mhz) */
> +/* txpid[B43_N_5G_MEDIUM_FREQ] = ; */
> +/* Use the txpid5ga values from the SPROM in the loop
> below; */
> +/* if (low freq range, 4900..5099 mhz) */
> +/* txpid[B43_N_5G_LOW_FREQ] = ; */
> +/* Use the txpid5gal values from the SPROM in the loop
> below; */
> +/* if (high freq range, 5500.. mhz) */
> +/* txpid[B43_N_5G_HIGH_FREQ] = ; */
> +/* Use the txpid5gah values from the SPROM in the loop
> below; */
> +/* if (2.4 GHz) */
> +/* txpid[B43_N_2G_FREQ] = ; */
> +/* Use the txpid2g values from the SPROM in the loop
> below; */
> + }
> + if (phy->rev >= 3)
> + txpid[0] = txpid[1] = txpid[2] = txpid[3] = 0x28;
> +
> + for (i = 0; i < B43_N_TXPID_MAX; i++) {
So, this loop just sets up the tx power for each radio core.
johannes
signature.asc
Description: This is a digitally signed message part
___
Bcm43xx-dev mailing list
Bcm43xx-dev@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: [RFC 7/7] B43N: Add the tx gain table of different version.
On Wed, 2009-01-14 at 15:59 +0800, YanBo wrote:
> Add the tx gain table
>
> Signed-off-by: Li YanBo
> ---
> drivers/net/wireless/b43/tables_nphy.c | 110
>
> drivers/net/wireless/b43/tables_nphy.h |3 +-
> 2 files changed, 112 insertions(+), 1 deletions(-)
>
> diff --git a/drivers/net/wireless/b43/tables_nphy.c
> b/drivers/net/wireless/b43/tables_nphy.c
> index 4e23363..a6e3d2b 100644
> --- a/drivers/net/wireless/b43/tables_nphy.c
> +++ b/drivers/net/wireless/b43/tables_nphy.c
> @@ -27,6 +27,116 @@
> #include "phy_common.h"
> #include "phy_n.h"
>
> +const u32 b43_ntab_txgain[][B43_NPHY_TXGAIN] = {
> + }, /* rev <= 2 */
> + {
I think you should give these different names, rather than sub-indexing
in that array.
johannes
signature.asc
Description: This is a digitally signed message part
___
Bcm43xx-dev mailing list
Bcm43xx-dev@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: [PATCH] ssb-sprom: Put SPROM data in a master table and add Rev. 8
On Mon, 2008-12-29 at 10:23 -0600, Larry Finger wrote: > Michael Buesch wrote: > > Thanks, I applied this. > > Is it possible, however, to have ssb_sprom --help not ask for the version? > > Simply print out _all_ options that apply to all versions. > > It's kind of confusing to see a question about a file version, if we don't > > have a file at all when just requesting commandline help. > > Sure. I'll just loop it through all the versions. Of course, that will > generate > what is probably too much output for the console, thus I will direct it to a > file and list the name of the file, unless I hear that you want it all on the > console. All on console please, people can add > /tmp/file or | less johannes signature.asc Description: This is a digitally signed message part ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Broadcom 11n implementation
Hey, I hope those of you who got their presents today enjoyed that. Here's one from me for the poor souls like myself who have a Broadcom 11n chip: I've been publishing specifications for things we have reverse engineered, is anyone interested in implementing this? If so, go wild, but synchronise on the list if there are multiple people. John, I think you had somebody who was interested, but I can't find the email right now. Michael has said that he might be able to help a bit (review maybe), but won't implement the bulk of it. And I actually need this code ASAP since I failed to replace the wireless card in my new MacBook (I couldn't even find it). johannes signature.asc Description: This is a digitally signed message part ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: [PATCH] b43/ssb: Add SPROM8 extraction and LP-PHY detection
On Thu, 2008-12-25 at 00:39 +0100, Michael Buesch wrote: > This adds detection code for the LP-PHY and SPROM > extraction code for version 8, which is needed by the LP-PHY and > newer N-PHY. I still get mac address ff:ff:ff:ff:ff:ff with this, but it might just be that we need to use a different address or something, will double check. We can fix that, so don't take this as a nack, the patch lays the foundation, and the devices aren't supported anyway. johannes signature.asc Description: This is a digitally signed message part ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: [RFC] b43: rework rfkill code
On Wed, 2008-12-10 at 13:29 -0500, Dan Williams wrote: > > Does the wireless driver get the notification about this from the > > hardware, like it would if this was a real physical switch? Then it's > > probably pretty simple: provide a rfkill struct from the driver that > > updates hard-kill and provide a second rfkill struct for the platform > > device that doesn't get hard-killed, but also provide a soft-kill input > > form the platform device. That way, you can toggle that button, but you > > can also software-enable the platform rfkill device and that in turn > > re-enables the wifi-rfkill "hw" switch device. > > This sort of sucks for userspace, because we see the actual wifi card as > hardblocked, but some other random button as softblocked. There's no > indication that changing the softblock one will affect the hardblocked > one. What are userspace processes supposed to do here, assume that if a > non-radio-associated softblocked switch exists, that it can re-enable a > hardblocked radio of some random wifi card? The other question is whether we actually care? So what if the hardware can only be enabled with the button, why does that matter? johannes signature.asc Description: This is a digitally signed message part ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: [RFC] b43: rework rfkill code
On Wed, 2008-12-10 at 17:51 +, Matthew Garrett wrote: > They may not be physical buttons, but we can often control this anyway. > For instance, my HP has a button that will perform a hardware disable of > the wifi card. However, I can control that button's state through > software with the hp-wmi driver. That's indeed a complication I wasn't aware of. > The way we currently handle that (and, > I think, the only way we *can* handle that) is to provide two separate > rfkill interfaces - one tied to the wireless device, one tied to the > platform device. Yes, but how do we currently do this? Does the wireless driver get the notification about this from the hardware, like it would if this was a real physical switch? Then it's probably pretty simple: provide a rfkill struct from the driver that updates hard-kill and provide a second rfkill struct for the platform device that doesn't get hard-killed, but also provide a soft-kill input form the platform device. That way, you can toggle that button, but you can also software-enable the platform rfkill device and that in turn re-enables the wifi-rfkill "hw" switch device. If we need to tie them together in software it gets more complicated though. johannes signature.asc Description: This is a digitally signed message part ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: [RFC] b43: rework rfkill code
On Wed, 2008-12-10 at 18:31 +0100, Michael Buesch wrote: > I introduced it when I ported b43 to rfkill. > Well, a lot of semantical changes were made _after_ that. > When I added it there only were two rfkill states and b43 handled these wrt > the > actual hardware state (and I still think that's the right thing to do. The > sw-state intermix > is confusing). Right. > So when I added the flag it meant: > user_claim_unsupported = True means user cannot change the hardware kill > state. Yeah, but the assumption that software can change the "hardware kill state" is rather stupid to start with, I think. > So basically it means the device has two states. One software state and one > hardware > state. > However, I don't know what the semantics for the flag are today. Lots of code > changed. Ok. I think the fundamental flaw here is assuming that there's just a single state. There isn't. The device can be turned off in hardware (in which case sw won't be able do anything about it, but we want to know) or in software (which we want to handle). Pretending that there's just a single state that's either hw-off, sw-off or on is plain wrong. The device can be hw-off and sw-off at the same time, and then if you turn off the hw-off button it won't turn on (however, unless your system integrator totally screwed up, you won't have a hw and a sw button on your system) johannes signature.asc Description: This is a digitally signed message part ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: [RFC] b43: rework rfkill code
On Wed, 2008-12-10 at 18:23 +0100, Johannes Berg wrote: > Then there's user_claim_unsupported which is set by all drivers but > rt2x00, probably because they have hardware kill switches and thus they > have to set it even if it's not strictly true, because of the lacking > separation between these things (that I pointed out) IOW, correct me if I'm wrong, it seems to me that user_claim_unsupported really is a wrong name for "has hw kill", which could be avoided if sw and hw kill were a different thing and the rfkill structure was only used, as I'm proposing, for hw kill and sw kill _notifications_, but not the sw kill operation itself. johannes signature.asc Description: This is a digitally signed message part ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: [RFC] b43: rework rfkill code
On Wed, 2008-12-10 at 18:18 +0100, Johannes Berg wrote: > We really need to disentangle the state tracking rfkill does. People > have said this a million times before, but nobody cares: drivers need to > register hard-blocked and get soft-block states independently, not in a > single enum; API for drivers needs to be, above all, EASY to use. Also, the rfkill struct itself is a mess. What's get_state() for? Why is this not layered? How can get_state() work correctly, it doesn't poll the device so it doesn't look like software will ever get a state update. Then there's user_claim_unsupported which is set by all drivers but rt2x00, probably because they have hardware kill switches and thus they have to set it even if it's not strictly true, because of the lacking separation between these things (that I pointed out) johannes signature.asc Description: This is a digitally signed message part ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: [RFC] b43: rework rfkill code
[warning: this is going to be a long mail and will tell you why and how I think rfkill needs to be rewritten] On Wed, 2008-12-10 at 17:51 +0100, Marcel Holtmann wrote: > if you figured out on how to do it the best way, then let me know, > because I have to do the same thing for Bluetooth. I'd suggest to start by rewriting rfkill to be not such a mess to use. We really need to disentangle the state tracking rfkill does. People have said this a million times before, but nobody cares: drivers need to register hard-blocked and get soft-block states independently, not in a single enum; API for drivers needs to be, above all, EASY to use. For mac80211, we really need to register an rfkill structure for each physical device that mac80211 knows about. Drivers would not be allowed to get access to this structure, because the toggle_radio() callback is assigned to a mac80211 function that calls the driver's ->config() callback and, at some point, also disallows configuring interfaces that belong to a device that is rfkilled. To properly implement this, however, we need to disentangle rfkill states and provide just a single API function to change the state: rfkill_hw_kill(struct rfkill *rfkill, bool killed); this would be shadowed by mac80211 with ieee80211_hw_rfkill(struct ieee80211_hw *hw, bool killed) so mac80211 knows about hard-kills too, since they don't call ->toggle_radio() obviously. I know what you're thinking at this point, but hear me out. This is another thing where I think rfkill's design is fundamentally wrong. If you're not thinking anything, hear me out anyway :) Let's take a step back here and analyse what we really have and need: * we have devices with a plethora of rfkill setups: 1) devices disappear from the bus (not handled here, not possible either) 2) devices have hard kill button that just disables the radio (need to know about this so users aren't left in the dark) 3) devices have soft kill buttons that just notify the driver 4) soft kill switches that work through other input methods (ACPI comes to mind, but anything is possible) * we have various ways to kill the radio: 1) like above 2) through platform methods (toshiba ACPI I think?) 3) through the driver only The last two cases only differ in the radios that the button is supposed to apply to, but this is more of a policy decision. The point where I think rfkill's design is totally wrong is that it intimately ties this software kill from case three to the rfkill structure as well. Instead, we should come to accept that this is just a button as well. A button, however, that is *by default* tied to a particular radio. Therefore, drivers for devices that provide such buttons, should, in my opinion, register an rfkill button driver that a) by default is tied to their hardware by a pointer to the rfkill struct for the hardware, but this could be possible to override in sysfs like LEDs are, if you want the button to really kill all radios b) serves as input to the rfkill subsystem which will then look up the right rfkill struct(s) and ask them to kill the radio This would add new API for a button, but again only a single function, something like rfkill_button_update(struct rfkill_button *btn, bool killed) Finally, rfkill-input will boil down to just registering a software button that happens to control all radios by default, by setting the controlled rfkill struct to NULL. johannes signature.asc Description: This is a digitally signed message part ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: [RFC] b43: rework rfkill code
On Wed, 2008-12-10 at 15:09 +, Matthew Garrett wrote: > The final change is that I removed the code for changing the wireless > state in response to the txpower configuration in mac80211. Right now, I > can't see any way for this to work correctly - if the user disables the > radio via rfkill, mac80211 doesn't flag the radio as disabled. As a > result, the next time the configuration callback is called, b43 > reenables the radio again, even though the user has explicitly disabled > it. I don't think any of the other drivers handle this case, so I'm not > really sure what the best way to handle this in future is. The current > situation certainly seems broken. We're going to have to integrate rfkill with mac80211, but nobody cares. johannes signature.asc Description: This is a digitally signed message part ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: b43: Everybody with PHY TX error, please try
On Thu, 2008-11-06 at 12:46 +, Przemek Kulczycki wrote: > On Fri, Oct 24, 2008 at 6:32 PM, Michael Buesch <[EMAIL PROTECTED]> wrote: > > Everybody with PHY TX error, please try updated firmware from > > ftp://ftp.linksys.com/opensourcecode/wrt610n/1.00.00.018/wrt610n_v1.00.00.018_us.tgz > > (Yeah, big tarball. It's 87MB) > If this tarball is so large then maybe downloading latest ubuntu > restricted modules will be faster. > http://packages.ubuntu.com/intrepid/linux-restricted-modules-2.6.27-7-generic > AFAIK this package contains the proprietary Broadcom WL driver so the > latest firmware might be in it too. No, not at all. johannes signature.asc Description: This is a digitally signed message part ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: b43: Everybody with PHY TX error, please try
On Fri, 2008-10-24 at 20:32 +0200, Michael Buesch wrote: > Try to reproduce the PHY TX error with the new firmware. This helped neither with the PHY TX errors nor with the RX errors where I'm getting invalid frames passed up from the firmware and run into a WARN_ON: drivers/net/wireless/b43/xmit.c:49 (b43_plcp_get_bitrate_idx_cck) johannes signature.asc Description: This is a digitally signed message part ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: [PATCH] b43: Fix Bluetooth coexistence SPROM coding error for Motorola 7010 variant of BCM4306
On Sat, 2008-09-20 at 16:08 -0500, Larry Finger wrote: > I don't know, but I really wouldn't want to blindly kill bluetooth > coexistence. After all, most cards have their SPROMs programmed > correctly. Only the PCI-versions of the BCM4306 and the ASUS BCM4318 > seem to have the problem. Yeah, true, it's mostly fine. Maybe we're missing something in the specs that makes the original driver work? Otherwise, I suspect they'd be getting these cards back in bunches... > I have been working the openSUSE and Ubuntu support forums, which is > where I have been getting these new devices to add to the work-around. Yeah, I still wonder where you get the patience to deal with support forums, but I think everybody very much appreciates that :) johannes signature.asc Description: This is a digitally signed message part ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: [PATCH] b43: Fix Bluetooth coexistence SPROM coding error for Motorola 7010 variant of BCM4306
On Sat, 2008-09-20 at 14:05 -0700, Luis R. Rodriguez wrote: > >> > Does anyone actually make laptops that use these bluetooth coexistence > >> > pins? All CSR bluetooth chips do it automatically I'm told, maybe we > >> > should just kill them completely. > >> > >> Regardless of the wireless card? Or just for bcm? > > > > Well just for b43(legacy), but out of curiosity, does any BT chip use > > these pins anyway? Well I guess _somebody_ has to buy BCMs BT chips, > > but ... > > BCM BT chips? I thought you said CSR? Well the thing is, BCM wifi chips have these IO pins that tell the BT chip what the wifi chip is doing. But CSR chips for instance don't care, they just check what the wifi chip is doing on the antenna. So those don't use those IO pins. Hence, I'm wondering if there's any use in the IO pins at all. But they must have added them for a reason, presumably because their own BT chips can use those inputs... Anyway, mostly just idly wondering, since most of the time it works fine and the EEPROM is actually done right I guess we should keep them on. johannes signature.asc Description: This is a digitally signed message part ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: [PATCH] b43: Fix Bluetooth coexistence SPROM coding error for Motorola 7010 variant of BCM4306
On Sat, 2008-09-20 at 13:59 -0700, Luis R. Rodriguez wrote: > On Sat, Sep 20, 2008 at 1:51 PM, Johannes Berg > <[EMAIL PROTECTED]> wrote: > > On Sat, 2008-09-20 at 17:44 +0200, Michael Buesch wrote: > >> On Friday 19 September 2008 21:47:38 Larry Finger wrote: > >> > An additional BCM4306 has been found with the Bluetooth coexistence > >> > SPROM coding error. > > > > Does anyone actually make laptops that use these bluetooth coexistence > > pins? All CSR bluetooth chips do it automatically I'm told, maybe we > > should just kill them completely. > > Regardless of the wireless card? Or just for bcm? Well just for b43(legacy), but out of curiosity, does any BT chip use these pins anyway? Well I guess _somebody_ has to buy BCMs BT chips, but ... johannes signature.asc Description: This is a digitally signed message part ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: [PATCH] b43: Fix Bluetooth coexistence SPROM coding error for Motorola 7010 variant of BCM4306
On Sat, 2008-09-20 at 17:44 +0200, Michael Buesch wrote: > On Friday 19 September 2008 21:47:38 Larry Finger wrote: > > An additional BCM4306 has been found with the Bluetooth coexistence > > SPROM coding error. Does anyone actually make laptops that use these bluetooth coexistence pins? All CSR bluetooth chips do it automatically I'm told, maybe we should just kill them completely. johannes signature.asc Description: This is a digitally signed message part ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: [RFC] b43: A patch for control of the radio LED using rfkill
On Thu, 2008-09-18 at 15:47 -0300, Henrique de Moraes Holschuh wrote: > Passing rfkill state around using the input layer is broken, and caused real > issues. That is what cannot be done, that is what was fixed in the new API. > But that does not preclude, e.g., b43, from also exporting input events... > *as long as* it is done correctly. [...] I don't get it. We only have a few things to control: * radio state for each device and a few mechanisms: 1) mac80211-internal (TPC, ..., iwconfig txpower off) 2) per-hardware input button (soft) 3) per-hardware rfkill button (hard) 4) platform input buttons (soft) 5) platform rfkill buttons (hard) b43, for example, 1, 2 and 3 (where connected, this is unknown to the driver) and may live on a platform that also has 4, 5 is very unlikely. The way I see it, we should have about this architecture: input layeruserspace mac80211 driver rfkill 2 ->| (a)--->| 4 ->| | (b)<--| | +>(c) (e)<---(d) | +--->| | (f)<| (a) synthesize rfkill state for each driver out of the various input events you can get, depending on whether the platform button is bluetooth, wlan, all, ... (b) take rfkill state and transform it into conf.radio_enabled along with the internal conf.radio_enabled state that mac80211 may decide on based on iwconfig txpower off. assume that users know what they're doing if they iwconfig txpower off, I think it's pretty pointless to have in light of rfkill and for all I care we can remove it (c) take conf.radio_enabled and enable/disable radio (d) notify mac80211 about _HARD_ rfkill state (e) take that into account for internal state machine and report to rfkill subsystem (f) display to user Driver only has to follow conf.radio_enabled and inform mac80211 of the hard state. Where's the flaw? johannes signature.asc Description: This is a digitally signed message part ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: [RFC] b43: A patch for control of the radio LED using rfkill
On Thu, 2008-09-18 at 20:34 +0200, Michael Buesch wrote: > So you say that rfkill should only be notified about changes in the first > read-only > hardware intication bit? If that's the case, it would be possible to turn the > radio off > through mac80211 calls (using the read-write register), but still have rfkill > think it's > unblocked. This is why I'm saying it needs to be integrated with mac80211. Anything else is stupid because it would force drivers to keep track of all three states. johannes signature.asc Description: This is a digitally signed message part ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: [RFC] b43: A patch for control of the radio LED using rfkill
On Thu, 2008-09-18 at 20:06 +0200, Ivo van Doorn wrote: > On Thursday 18 September 2008, Johannes Berg wrote: > > On Thu, 2008-09-18 at 19:52 +0200, Ivo van Doorn wrote: > > > > > From rfkill.h: > > > RFKILL_STATE_SOFT_BLOCKED = 0, /* Radio output blocked */ > > > RFKILL_STATE_UNBLOCKED= 1, /* Radio output allowed */ > > > RFKILL_STATE_HARD_BLOCKED = 2, /* Output blocked, non-overrideable */ > > > > > > Since b43 has a rfkill mechanism that does switch of the radio when > > > RFKILL is set to BLOCK > > > after a key press, it should send RFKILL_STATE_HARD_BLOCKED because > > > rfkill cannot override > > > it. > > > > > > rt2x00 hardware does not change the radio state when RFKILL is set to > > > BLOCK after a key press, > > > the state is therefor overridable and it can send > > > RFKILL_STATE_SOFT_BLOCKED to rfkill. > > > > If rt2x00 has no meaning of "hardware blocked", why is the button not a > > simple input device? > > Because I had that discussion with Henrique and that ended with a "it isn't a > input device"... Why isn't it? If it doesn't affect the hardware itself it might as well be connected to the ps/2 port for all I care. johannes signature.asc Description: This is a digitally signed message part ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: [RFC] b43: A patch for control of the radio LED using rfkill
On Thu, 2008-09-18 at 19:52 +0200, Ivo van Doorn wrote: > From rfkill.h: > RFKILL_STATE_SOFT_BLOCKED = 0, /* Radio output blocked */ > RFKILL_STATE_UNBLOCKED= 1, /* Radio output allowed */ > RFKILL_STATE_HARD_BLOCKED = 2, /* Output blocked, non-overrideable */ > > Since b43 has a rfkill mechanism that does switch of the radio when RFKILL is > set to BLOCK > after a key press, it should send RFKILL_STATE_HARD_BLOCKED because rfkill > cannot override > it. > > rt2x00 hardware does not change the radio state when RFKILL is set to BLOCK > after a key press, > the state is therefor overridable and it can send RFKILL_STATE_SOFT_BLOCKED > to rfkill. If rt2x00 has no meaning of "hardware blocked", why is the button not a simple input device? johannes signature.asc Description: This is a digitally signed message part ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: [RFC] b43: A patch for control of the radio LED using rfkill
On Thu, 2008-09-18 at 19:42 +0200, Ivo van Doorn wrote: > Well from my perspective: > Note that 'sw' is the RADIO state as requested by mac80211 and > 'hw' is the RFKILL state as indicated by the hardware > > radio: block, rfkill: block => BLOCK > radio: block, rfkill: unblock => UNBLOCK > radio: unblock, rfkill: block => BLOCK > radio: unblock, rfkill: unblock => UNBLOCK Can't that crap just live in rfkill? rfkill_announce_softstate(OPEN/BLOCKED) rfkill_announce_hardstate(OPEN/BLOCKED) and all the other junk happens there. And make sure this can be called from interrupts. johannes signature.asc Description: This is a digitally signed message part ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: [BUG] latest changes in mac80211 & b43
On Sat, 2008-09-13 at 19:44 +0200, Johannes Berg wrote: > The actual problem seems to be that we're sending those EAPOL frames > encrypted, I'll take a look tomorrow or Monday. It's a problem in hostapd, patch posted. johannes signature.asc Description: This is a digitally signed message part ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: [BUG] latest changes in mac80211 & b43
Hi, Please use linux-wireless, CC added. > b43 doesn't work in AP-mode, hostapd print such errors: > > wlan0: STA 00:1b:fc:f2:49:b2 WPA: EAPOL-Key timeout > WPA: 00:1b:fc:f2:49:b2 WPA_PTK entering state PTKSTART > wlan0: STA 00:1b:fc:f2:49:b2 WPA: sending 1/4 msg of 4-Way Handshake > WPA: Send EAPOL(version=2 secure=0 mic=0 ack=1 install=0 pairwise=8 > kde_len=0 keyidx=0 encr=0) > WPA: 00:1b:fc:f2:49:b2 WPA_PTK entering state DISCONNECT > hostapd_wpa_auth_disconnect: WPA authenticator requests disconnect: > STA 00:1b:fc:f2:49:b2 reason 2 > WPA: 00:1b:fc:f2:49:b2 WPA_PTK entering state DISCONNECTED > WPA: 00:1b:fc:f2:49:b2 WPA_PTK entering state INITIALIZE > wlan0: STA 00:1b:fc:f2:49:b2 IEEE 802.1X: unauthorizing port > Could not set station 00:1b:fc:f2:49:b2 flags for kernel driver (errno=124). > wlan0: STA 00:1b:fc:f2:49:b2 IEEE 802.11: deauthenticated due to local > deauth request That makes no sense at all, but that's because you snipped the log so much that the actual problem is gone. The actual problem seems to be that we're sending those EAPOL frames encrypted, I'll take a look tomorrow or Monday. johannes signature.asc Description: This is a digitally signed message part ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: [PATCH] b43legacy: Fix failure in rate-adjustment mechanism
On Sat, 2008-09-06 at 14:59 -0500, Larry Finger wrote: > In the V3 specs, I found > > "Transmit Status > > When this interrupt is set, the retrieve the TransmitStatus. Note that > on cores with revision < 5, the last DMA controller or PIO queue can > also also get the DMA recieve done interrupt, which also triggers the > TransmitStatus retrieval process. The driver should be prepared to > deal with both interrupts at any time, on any revision. In AP mode, > this interrupt also initiates the sending of powersave responses." Yeah, this isn't entirely correct, when the core revision is < 5 then the register-based TX status doesn't actually exist and the firmware always uses the FIFO-based mechanism. > The implication is that the interrupt will only be generated if we use > the last (i.e. #5) DMA controller. As we are only using #3, no > interrupts and handle_irq_status() is dead code. Right, only core revisions 2 and 4 are supported here. johannes signature.asc Description: This is a digitally signed message part ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: [PATCH] b43legacy: Fix failure in rate-adjustment mechanism
On Sat, 2008-09-06 at 14:36 -0500, Larry Finger wrote:
> What I see are lots of
>
> b43legacy: In b43legacy_handle_hwtxstatus, hw->flags = 0x1
>
> and this is the only one that ever triggered. ATM, I'm not sure why
> handle_irq_transmit_status() is not called.
The mechanism depends on the card revision, but according to
drivers/net/wireless/b43legacy/dma.c it's always via the dma/pio
mechanism for legacy cards:
if (dev->dev->id.revision < 5) {
ring = b43legacy_setup_dmaring(dev, 3, 0, type);
if (!ring)
goto err_destroy_rx0;
dma->rx_ring3 = ring;
}
johannes
signature.asc
Description: This is a digitally signed message part
___
Bcm43xx-dev mailing list
Bcm43xx-dev@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: [PATCH] b43legacy: Fix failure in rate-adjustment mechanism
On Sat, 2008-09-06 at 20:55 +0200, Michael Buesch wrote: > On Saturday 06 September 2008 20:52:53 Larry Finger wrote: > > Michael Buesch wrote: > > > On Saturday 06 September 2008 20:34:02 Larry Finger wrote: > > >> A coding error present since b43legacy was incorporated into the > > >> kernel has prevented the driver from using the rate-setting mechanism > > >> of mac80211. The driver has been forced to remain at a 1 Mb/s rate. > > > > > > Does version3 firmware have a different bitlayout for the status? > > > > It seems so. I found this because I was not getting any acks back to > > net/mac80211/rc80211_pid_algo.c. I then reviewed the V3 specs, found > > that bit 0, not bit 1, contained the ack. Test prints confirmed that > > result. With this patch, both my BCM4306/2 and BCM4303 reach the > > maximum rate. With the current code, 54 Mb/s is not as fast as 36 > > Mb/s, but at least the algorithm is working. > > Yeah ok. I just asked, because it seems the _whole_ flags bitfield > is rightshifted by one (so the other flags are wrong, too. See the > intermediate flag) It is, this isn't really a difference between the two but a result of you shifting it up/down due to the tx status via dma queue vs. tx status via registers thing. johannes signature.asc Description: This is a digitally signed message part ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: [PATCH stable] b43: Do not return TX_BUSY from op_tx
On Thu, 2008-07-03 at 10:31 +0200, Michael Buesch wrote: > On Thursday 03 July 2008 08:35:23 Kalle Valo wrote: > > Michael Buesch <[EMAIL PROTECTED]> writes: > > > > > +drop_packet: > > > + /* We can not transmit this packet. Drop it. */ > > > + dev_kfree_skb_any(skb); > > > return NETDEV_TX_OK; > > > > So no need to call ieee80211_tx_status() in this case? I'm just > > curious about this, nothing else. > > I don't think we must call tx_status for dropped or lost packets. That's a bit of a corner case really. If you call tx-status then the rate control algorithm will adjust to something that hasn't happened, and if you don't then the packet won't be on the monitor interface. In practice, it doesn't really matter because so far this only happens during resume and that'll hopefully get fixed. johannes signature.asc Description: This is a digitally signed message part ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: b43 locks the machine when resuming after suspend to disk
On Wed, 2008-07-02 at 18:27 -0500, Larry Finger wrote: > Johannes Berg wrote: > > On Thu, 2008-07-03 at 01:08 +0200, Rafael J. Wysocki wrote: > >> On Thursday, 3 of July 2008, Johannes Berg wrote: > >>> Rafael, you misled me :) This is a completely different thing. > >> Ah, sorry then. I was too quick with my response. > > > > No trouble, it reminded me that I wanted to ask stable to pick up that > > patch anyway although I don't think we ever ran into the issue there. > > > > This seems very odd though, Giacomo, are you sure it also happens if you > > unload the module? > > I'm confused. Should the "mac80211: detect driver tx bugs" patch be sent to > stable? Yeah I think it still should even if that's not the bug here. johannes signature.asc Description: This is a digitally signed message part ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: b43 locks the machine when resuming after suspend to disk
On Thu, 2008-07-03 at 01:08 +0200, Rafael J. Wysocki wrote: > On Thursday, 3 of July 2008, Johannes Berg wrote: > > On Wed, 2008-07-02 at 23:40 +0200, Rafael J. Wysocki wrote: > > > On Wednesday, 2 of July 2008, Giacomo Mulas wrote: > > > > I tried searching on the list for this, before posting, but searching > > > > the > > > > mailing list archives with keywords such as b43, suspend, resume... > > > > brings > > > > up such a ludicrous amount of threads that it's not realistic to check > > > > them > > > > all, so just tell me what to look for if it's been asked already. > > > > > > > > Whenever I do a suspend to disk after using b43, the computer freezes > > > > hard > > > > as soon as it attempts again to access b43 after resume. > > > > > > > > Minimal how to reproduce the freeze: > > > > 1) modprobe b43 > > > > 2) hibernate (using any suspend to disk, which one is irrelevant) > > > > 3) resume > > > > 4) ifconfig wlan0 up > > > > > I think you need the appended patch, but it only applies to linux-next. > > > > Rafael, you misled me :) This is a completely different thing. > > Ah, sorry then. I was too quick with my response. No trouble, it reminded me that I wanted to ask stable to pick up that patch anyway although I don't think we ever ran into the issue there. This seems very odd though, Giacomo, are you sure it also happens if you unload the module? johannes signature.asc Description: This is a digitally signed message part ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: b43 locks the machine when resuming after suspend to disk
On Wed, 2008-07-02 at 23:40 +0200, Rafael J. Wysocki wrote: > On Wednesday, 2 of July 2008, Giacomo Mulas wrote: > > I tried searching on the list for this, before posting, but searching the > > mailing list archives with keywords such as b43, suspend, resume... brings > > up such a ludicrous amount of threads that it's not realistic to check them > > all, so just tell me what to look for if it's been asked already. > > > > Whenever I do a suspend to disk after using b43, the computer freezes hard > > as soon as it attempts again to access b43 after resume. > > > > Minimal how to reproduce the freeze: > > 1) modprobe b43 > > 2) hibernate (using any suspend to disk, which one is irrelevant) > > 3) resume > > 4) ifconfig wlan0 up > I think you need the appended patch, but it only applies to linux-next. Rafael, you misled me :) This is a completely different thing. johannes signature.asc Description: This is a digitally signed message part ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: b43 locks the machine when resuming after suspend to disk
On Wed, 2008-07-02 at 17:32 -0500, Larry Finger wrote:
> Johannes Berg wrote:
> >>> I think you need the appended patch, but it only applies to linux-next.
> >> A different version has been merged into what will become 2.6.26. I'll
> >> see what we can do about stable.
> >
> > http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=ef3a62d272f033989e83eb1f26505f93f93e3e69;hp=6d1a3fb567a728d31474636e167c324702a0c38b
> >
> > Anybody have a stable tree around to see if that applies? I think it
> > should.
>
> It didn't, but this version will. It has been compile tested only.
Ah, the TXRX result thing, thanks a bunch. Adding stable to CC, can you
pick this up?
Subject: mac80211: detect driver tx bugs
When a driver rejects a frame in it's ->tx() callback, it must also
stop queues, otherwise mac80211 can go into a loop here. Detect this
situation and abort the loop after five retries, warning about the
driver bug.
Thanks to Larry Finger <[EMAIL PROTECTED]> for doing the -stable
port.
--- linux-2.6.orig/net/mac80211/tx.c
+++ linux-2.6/net/mac80211/tx.c
@@ -1090,7 +1090,7 @@ static int ieee80211_tx(struct net_devic
ieee80211_tx_handler *handler;
struct ieee80211_txrx_data tx;
ieee80211_txrx_result res = TXRX_DROP, res_prepare;
- int ret, i;
+ int ret, i, retries = 0;
WARN_ON(__ieee80211_queue_pending(local, control->queue));
@@ -1181,6 +1181,13 @@ retry:
if (!__ieee80211_queue_stopped(local, control->queue)) {
clear_bit(IEEE80211_LINK_STATE_PENDING,
&local->state[control->queue]);
+ retries++;
+ /*
+* Driver bug, it's rejecting packets but
+* not stopping queues.
+*/
+ if (WARN_ON_ONCE(retries > 5))
+ goto drop;
goto retry;
}
memcpy(&store->control, control,
___
Bcm43xx-dev mailing list
Bcm43xx-dev@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: b43 locks the machine when resuming after suspend to disk
> > I think you need the appended patch, but it only applies to linux-next. > > A different version has been merged into what will become 2.6.26. I'll > see what we can do about stable. http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=ef3a62d272f033989e83eb1f26505f93f93e3e69;hp=6d1a3fb567a728d31474636e167c324702a0c38b Anybody have a stable tree around to see if that applies? I think it should. johannes signature.asc Description: This is a digitally signed message part ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: b43 locks the machine when resuming after suspend to disk
On Wed, 2008-07-02 at 23:40 +0200, Rafael J. Wysocki wrote: > On Wednesday, 2 of July 2008, Giacomo Mulas wrote: > > I tried searching on the list for this, before posting, but searching the > > mailing list archives with keywords such as b43, suspend, resume... brings > > up such a ludicrous amount of threads that it's not realistic to check them > > all, so just tell me what to look for if it's been asked already. > > > > Whenever I do a suspend to disk after using b43, the computer freezes hard > > as soon as it attempts again to access b43 after resume. > > > > Minimal how to reproduce the freeze: > > 1) modprobe b43 > > 2) hibernate (using any suspend to disk, which one is irrelevant) > > 3) resume > > 4) ifconfig wlan0 up > > > > This has been happening (at least) since b43 was included in the mainline > > kernel, on my Asus A6K laptop running an x86_64 kernel (now the latest > > 2.6.25 stable release or compiled from the latest released debian sid > > sources). The nvidia module is not responsible: I explicitely booted my > > laptop in single user mode without any unnecessary modules, same result. It > > does not happen using the windows driver with ndiswrapper (which I would > > prefer to avoid for other reasons), so it definitely depends on b43 or > > something it depends on. Unloading and reloading the b43 module and all the > > other modules it depends on does not change anything. Just loading the > > module once, hibernating and resuming means freeze-up as soon as the module > > is actually initialised next time, regardless of it having been unloaded and > > reloaded any number of times before or after the suspend-resume cycle. No > > oopses, nothing on system logs, just instant freeze-up. Is there some > > testing a user can do to help nailing this? I am not a kernel developer, > > even if I am a decent C programmer. > > > > Please CC me on replies, I am not on the list. > > I think you need the appended patch, but it only applies to linux-next. A different version has been merged into what will become 2.6.26. I'll see what we can do about stable. johannes signature.asc Description: This is a digitally signed message part ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: Monitor-while-operating bug in b43: WEP-encrypted packets are received in decrypted form on the monitor interface
On Fri, 2008-06-27 at 21:38 +0200, Stefanik Gábor wrote: > I don't think that we should require turning off hardware cryptography > for doing this - one might want to use a managed interface with > hardware cryptography enabled (less code overhead), while getting a > truely-raw dump on a monitor interface simultaneously. This is useful > for wireless IDS, for example. Sure, would be great. Go implement it. Might need hardware changes. And think about it first maybe. johannes signature.asc Description: This is a digitally signed message part ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: Monitor-while-operating bug in b43: WEP-encrypted packets are received in decrypted form on the monitor interface
On Fri, 2008-06-27 at 19:19 +0200, Stefanik Gábor wrote: > On Tue, May 20, 2008 at 6:24 PM, Stefanik Gábor <[EMAIL PROTECTED]> wrote: > > Hi all, > > > > One day I was testing monitor-while-operating, with "wlan0" as the > > managed interface and "rtap0" as the monitor one, and found an > > interesting bug: when I am associated with an AP on wlan0, and try to > > receive the same AP's packets through the monitor interface, the > > packets arrive in decrypted form, but with the WEP bit still set. This > > appears to be a HW-crypto-related bug, though I haven't tested with HW > > crypto off. What can cause such a bug? > Could someone investigate this? I first posted this a month ago, and > noone really did anything about it. It's not a bug, it's a feature. Turn off hardware encryption if it bothers you. johannes signature.asc Description: This is a digitally signed message part ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: BUG(?): dev->wl->if_type is 0 for monitor interfaces (should be 5); b43_is_mode(dev->wl; IEEE80211_IF_TYPE_MNTR) is always false
On Wed, 2008-06-25 at 22:23 +0200, Stefanik Gábor wrote: > On Wed, Jun 25, 2008 at 10:22 PM, Stefanik Gábor > <[EMAIL PROTECTED]> wrote: > > In both b43 and b43legacy, dev->wl->if_type is 0 > > (IEEE80211_IF_TYPE_INVALID) when injecting/transmitting packets on a > > monitor interface (not sure about receiving), while the logical result > > would be 5 (IEEE80211_IF_TYPE_MNTR). I should answer on the list too then: No, 5 wouldn't be the logical result. Try to understand how monitor mode and virtual interfaces in mac80211 work. b43 only sees what mode it is operating in, but pure monitor mode isn't "operating" at all. johannes signature.asc Description: This is a digitally signed message part ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: BUG(?): dev->wl->if_type is 0 for monitor interfaces (should be 5); b43_is_mode(dev->wl; IEEE80211_IF_TYPE_MNTR) is always false
On Wed, 2008-06-25 at 22:22 +0200, Stefanik Gábor wrote: > In both b43 and b43legacy, dev->wl->if_type is 0 > (IEEE80211_IF_TYPE_INVALID) when injecting/transmitting packets on a > monitor interface (not sure about receiving), while the logical result > would be 5 (IEEE80211_IF_TYPE_MNTR). No, 5 wouldn't be the logical result. Try to understand how monitor mode and virtual interfaces in mac80211 work. johannes signature.asc Description: This is a digitally signed message part ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: mac80211 local_bh_enable called with IRQs disabled (was: b43legacy kernel warning)
On Tue, 2008-06-17 at 23:20 +0200, Michael Buesch wrote:
> On Tuesday 17 June 2008 22:59:52 David Ellingsworth wrote:
> > I ran into this error today from a kernel I built last night based on
> > the latest wireless-testing branch. Correct me if I'm wrong, but it
> > looks to be b43legacy related. I'm a bit new to kernel debugging but
> > can try to provide additional information if instructions on how to do
> > so are provided.
>
> No, this is a mac80211 bug
Can you try the patch below?
johannes
--- everything.orig/net/mac80211/sta_info.h 2008-06-18 10:07:24.0
+0200
+++ everything/net/mac80211/sta_info.h 2008-06-18 11:58:32.0 +0200
@@ -164,6 +164,7 @@ struct sta_ampdu_mlme {
* @aid: STA's unique AID (1..2007, 0 = not assigned yet),
* only used in AP (and IBSS?) mode
* @flags: STA flags, see &enum ieee80211_sta_info_flags
+ * @flaglock: spinlock for flags accesses
* @ps_tx_buf: buffer of frames to transmit to this station
* when it leaves power saving state
* @tx_filtered: buffer of frames we already tried to transmit
@@ -186,6 +187,7 @@ struct sta_info {
struct rate_control_ref *rate_ctrl;
void *rate_ctrl_priv;
spinlock_t lock;
+ spinlock_t flaglock;
struct ieee80211_ht_info ht_info;
u64 supp_rates[IEEE80211_NUM_BANDS];
u8 addr[ETH_ALEN];
@@ -198,7 +200,10 @@ struct sta_info {
*/
u8 pin_status;
- /* frequently updated information, locked with lock spinlock */
+ /*
+* frequently updated, locked with own spinlock (flaglock),
+* use the accessors defined below
+*/
u32 flags;
/*
@@ -293,34 +298,41 @@ static inline enum plink_state sta_plink
static inline void set_sta_flags(struct sta_info *sta, const u32 flags)
{
- spin_lock_bh(&sta->lock);
+ unsigned long irqfl;
+
+ spin_lock_irqsave(&sta->flaglock, irqfl);
sta->flags |= flags;
- spin_unlock_bh(&sta->lock);
+ spin_unlock_irqrestore(&sta->flaglock, irqfl);
}
static inline void clear_sta_flags(struct sta_info *sta, const u32 flags)
{
- spin_lock_bh(&sta->lock);
+ unsigned long irqfl;
+
+ spin_lock_irqsave(&sta->flaglock, irqfl);
sta->flags &= ~flags;
- spin_unlock_bh(&sta->lock);
+ spin_unlock_irqrestore(&sta->flaglock, irqfl);
}
static inline void set_and_clear_sta_flags(struct sta_info *sta,
const u32 set, const u32 clear)
{
- spin_lock_bh(&sta->lock);
+ unsigned long irqfl;
+
+ spin_lock_irqsave(&sta->flaglock, irqfl);
sta->flags |= set;
sta->flags &= ~clear;
- spin_unlock_bh(&sta->lock);
+ spin_unlock_irqrestore(&sta->flaglock, irqfl);
}
static inline u32 test_sta_flags(struct sta_info *sta, const u32 flags)
{
u32 ret;
+ unsigned long irqfl;
- spin_lock_bh(&sta->lock);
+ spin_lock_irqsave(&sta->flaglock, irqfl);
ret = sta->flags & flags;
- spin_unlock_bh(&sta->lock);
+ spin_unlock_irqrestore(&sta->flaglock, irqfl);
return ret;
}
@@ -329,11 +341,12 @@ static inline u32 test_and_clear_sta_fla
const u32 flags)
{
u32 ret;
+ unsigned long irqfl;
- spin_lock_bh(&sta->lock);
+ spin_lock_irqsave(&sta->flaglock, irqfl);
ret = sta->flags & flags;
sta->flags &= ~flags;
- spin_unlock_bh(&sta->lock);
+ spin_unlock_irqrestore(&sta->flaglock, irqfl);
return ret;
}
@@ -341,10 +354,11 @@ static inline u32 test_and_clear_sta_fla
static inline u32 get_sta_flags(struct sta_info *sta)
{
u32 ret;
+ unsigned long irqfl;
- spin_lock_bh(&sta->lock);
+ spin_lock_irqsave(&sta->flaglock, irqfl);
ret = sta->flags;
- spin_unlock_bh(&sta->lock);
+ spin_unlock_irqrestore(&sta->flaglock, irqfl);
return ret;
}
--- everything.orig/net/mac80211/sta_info.c 2008-06-18 11:56:44.0
+0200
+++ everything/net/mac80211/sta_info.c 2008-06-18 11:56:58.0 +0200
@@ -235,6 +235,7 @@ struct sta_info *sta_info_alloc(struct i
return NULL;
spin_lock_init(&sta->lock);
+ spin_lock_init(&sta->flaglock);
memcpy(sta->addr, addr, ETH_ALEN);
sta->local = local;
___
Bcm43xx-dev mailing list
Bcm43xx-dev@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: [PATCH] mac80211: fix panic when using hardware WEP
On Mon, 2008-06-02 at 07:54 -0400, Pavel Roskin wrote:
> 57ccbb1cbe3f8e10a500ff8b9fb26dc1a542fe99 misplaced code for setting
> hardware WEP keys. Move it back. This fixes kernel panic in b43 if WEP
> is used and hardware encryption is enabled.
Oh wow, yes, sorry about that, and thanks for tracking it down!
> Signed-off-by: Pavel Roskin <[EMAIL PROTECTED]>
Acked-by: Johannes Berg <[EMAIL PROTECTED]>
> ---
>
> net/mac80211/wep.c |2 +-
> 1 files changed, 1 insertions(+), 1 deletions(-)
>
> diff --git a/net/mac80211/wep.c b/net/mac80211/wep.c
> index c9fd129..e7b6344 100644
> --- a/net/mac80211/wep.c
> +++ b/net/mac80211/wep.c
> @@ -335,10 +335,10 @@ static int wep_encrypt_skb(struct ieee80211_tx_data
> *tx, struct sk_buff *skb)
> info->control.icv_len = WEP_ICV_LEN;
>
> if (!(tx->key->flags & KEY_FLAG_UPLOADED_TO_HARDWARE)) {
> - info->control.hw_key = &tx->key->conf;
> if (ieee80211_wep_encrypt(tx->local, skb, tx->key))
> return -1;
> } else {
> + info->control.hw_key = &tx->key->conf;
> if (tx->key->conf.flags & IEEE80211_KEY_FLAG_GENERATE_IV) {
> if (!ieee80211_wep_add_iv(tx->local, skb, tx->key))
> return -1;
>
signature.asc
Description: This is a digitally signed message part
___
Bcm43xx-dev mailing list
Bcm43xx-dev@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: Wireless-testing's b43 panics in b43_generate_txhdr on packet transmit
On Sat, 2008-05-31 at 19:54 +0200, Michael Buesch wrote: > On Saturday 31 May 2008 18:50:36 Pavel Roskin wrote: > > On Sat, 2008-05-31 at 18:41 +0200, Michael Buesch wrote: > > > On Saturday 31 May 2008 18:34:29 Stefanik Gábor wrote: > > > > "BUG: unable to handle kernel NULL pointer dereference at 0004 > > > > IP: [] :b43:b43_generate_txhdr+0x6a9/0x790 > > > > > > So can you put a few printks into the function to see where it > > > dereferences > > > a NULL pointer? (or use gdb to lookup the offset). > > > > u8 key_idx = info->control.hw_key->hw_key_idx; > > > > info->control.hw_key is NULL. > > Is a NULL pointer supposed to tell "do not encrypt", or is this a mac80211 > bug? It looks like a mac80211 bug, but I can't see how we get there. If you look at mac80211's tx.c, you'll see, in ieee80211_tx_h_select_key: if (!tx->key || !(tx->key->flags & KEY_FLAG_UPLOADED_TO_HARDWARE)) info->flags |= IEEE80211_TX_CTL_DO_NOT_ENCRYPT; Hence, I haven't got a clue how you can possibly get into the situation we have here, even with packet injection. Unless it's a different version of mac80211 or something. johannes signature.asc Description: This is a digitally signed message part ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: Wireless-testing's b43 panics in b43_generate_txhdr on packet transmit
On Sat, 2008-05-31 at 19:54 +0200, Michael Buesch wrote: > On Saturday 31 May 2008 18:50:36 Pavel Roskin wrote: > > On Sat, 2008-05-31 at 18:41 +0200, Michael Buesch wrote: > > > On Saturday 31 May 2008 18:34:29 Stefanik Gábor wrote: > > > > "BUG: unable to handle kernel NULL pointer dereference at 0004 > > > > IP: [] :b43:b43_generate_txhdr+0x6a9/0x790 > > > > > > So can you put a few printks into the function to see where it > > > dereferences > > > a NULL pointer? (or use gdb to lookup the offset). > > > > u8 key_idx = info->control.hw_key->hw_key_idx; > > > > info->control.hw_key is NULL. > > Is a NULL pointer supposed to tell "do not encrypt", or is this a mac80211 > bug? It's probably a bug. johannes signature.asc Description: This is a digitally signed message part ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: suspend vs. b43
On Sat, 2008-05-31 at 00:49 +0200, Rafael J. Wysocki wrote: > On Saturday, 31 of May 2008, Johannes Berg wrote: > > > > > It hangs for me either at read_unlock_irqrestore() in b43_op_tx() or > > > somewhere > > > in ieee80211_tx() (at various places). > > > > Huh. Why is it even getting into the tx path? And even then, why does it > > hang at an unlock? > > Well, I saw that during hibernation, so it probably happened after creating > the > image, when devices were being resumed for image saving. Yeah, like I said earlier to somebody. Still doesn't make much sense here. I'll play with it next week, or you could try to put into suspend() a call to ieee80211_stop_queues() and in resume ieee80211_wake_queues(), maybe that fixes it? I probably won't have time over the weekend to look more into it, sorry. johannes signature.asc Description: This is a digitally signed message part ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: suspend vs. b43
> It hangs for me either at read_unlock_irqrestore() in b43_op_tx() or somewhere > in ieee80211_tx() (at various places). Huh. Why is it even getting into the tx path? And even then, why does it hang at an unlock? johannes signature.asc Description: This is a digitally signed message part ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: suspend vs. b43
On Fri, 2008-05-30 at 17:20 +0200, Rafael J. Wysocki wrote: > On Friday, 30 of May 2008, Johannes Berg wrote: > > On Fri, 2008-05-30 at 16:42 +0200, Michael Buesch wrote: > > > On Friday 30 May 2008 16:37:18 Johannes Berg wrote: > > > > Odd. Resume itself works just fine here, except when b43 is up. But then > > > > again, you might not notice that this is the problem because by default, > > > > nothing gets printed on the resume console and then it will indeed hang > > > > with a black screen. > > > > > > How can I change the printing? > > > > Hmm. It seems I might have been wrong here. Rafael, do we still have > > console suspend stuff? > > Yes, we do. Use "no_console_suspend" in the kernel command line to change > that, but note that it's not generally safe (eg. if you are using netconsole > at > the same time). I see. System reset hard and clock set to 1904, PMU didn't like me :) Thing is, I do have no_console_suspend (hardcoded in my boot loader config so I forgot), but even with PM-debug I didn't see it hang at b43 and no useful messages. Not sure what to do, hence asking if anybody has the rtc-trace stuff. johannes signature.asc Description: This is a digitally signed message part ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: suspend vs. b43
On Fri, 2008-05-30 at 16:49 +0200, Holger Schurig wrote: > > Odd. Resume itself works just fine here, except when b43 is > > up. But then again, you might not notice that this is the > > problem because by default, nothing gets printed on the resume > > console and then it will indeed hang with a black screen. > > pepper it with printk's and add netconsole ... Well, yeah, netconsole _might_ work as sungem gets resumed before b43, but I tried doing that on the regular console and didn't see anything useful. johannes signature.asc Description: This is a digitally signed message part ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: suspend vs. b43
On Fri, 2008-05-30 at 16:42 +0200, Michael Buesch wrote: > On Friday 30 May 2008 16:37:18 Johannes Berg wrote: > > Odd. Resume itself works just fine here, except when b43 is up. But then > > again, you might not notice that this is the problem because by default, > > nothing gets printed on the resume console and then it will indeed hang > > with a black screen. > > How can I change the printing? Hmm. It seems I might have been wrong here. Rafael, do we still have console suspend stuff? johannes signature.asc Description: This is a digitally signed message part ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: suspend vs. b43
On Fri, 2008-05-30 at 16:06 +0200, Michael Buesch wrote: > On Friday 30 May 2008 14:31:53 Johannes Berg wrote: > > Since a while ago I've had trouble resuming when b43 was connected to an > > AP while suspended. > > > > I did a test today where this was the only difference, but I failed to > > see whether ssb or b43 were causing the problem. > > > > Does anyone have a machine with b43 in it that can suspend and supports > > the RTC-trace feature so we can narrow it down? Even reproducing might > > help to make sure it's not just something weird with my powerbook. > > Resume is pretty broken since some time for me. > It sometimes works fine and sometimes just hangs with a black screen. > I have no idea what's going on. Odd. Resume itself works just fine here, except when b43 is up. But then again, you might not notice that this is the problem because by default, nothing gets printed on the resume console and then it will indeed hang with a black screen. johannes signature.asc Description: This is a digitally signed message part ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
suspend vs. b43
Hi, Since a while ago I've had trouble resuming when b43 was connected to an AP while suspended. I did a test today where this was the only difference, but I failed to see whether ssb or b43 were causing the problem. Does anyone have a machine with b43 in it that can suspend and supports the RTC-trace feature so we can narrow it down? Even reproducing might help to make sure it's not just something weird with my powerbook. johannes signature.asc Description: This is a digitally signed message part ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: 4311 v2 Bail - 2.6.26-rc2
> > We really need a raw monitor frame capture. > > Not sure how I go about that one? > > I have an external RTL8187 device I can stick into monitor mode? But > then it wouldn't be associated/encryption keys... > > Tips anyone? In this case, adding a monitor interface to your local b43 machine (with iw: http://wireless.kernel.org/en/users/Documentation/iw) might be preferable. johannes signature.asc Description: This is a digitally signed message part ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: 4311 v2 Bail - 2.6.26-rc2
On Wed, 2008-05-14 at 01:48 +0200, Johannes Berg wrote: > > > b43-phy1 debug: Found PHY: Analog 4, Type 2, Revision 9 > > > b43-phy1 debug: Found Radio: Manuf 0x17F, Version 0x2050, Revision 2 > > > b43-phy1 debug: DebugFS (CONFIG_DEBUG_FS) not enabled in kernel config > > > phy1: Selected rate control algorithm 'pid' > > > Broadcom 43xx driver loaded [ Features: P, Firmware-ID: FW13 ] > > > firmware: requesting b43/ucode13.fw > > > firmware: requesting b43/lp0initvals13.fw > > Huh? lp0initvals?! Hmm. specs bug? But probably unrelated anyway since, well, it works for other people. We really need a raw monitor frame capture. johannes signature.asc Description: This is a digitally signed message part ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: 4311 v2 Bail - 2.6.26-rc2
> > b43-phy1 debug: Found PHY: Analog 4, Type 2, Revision 9 > > b43-phy1 debug: Found Radio: Manuf 0x17F, Version 0x2050, Revision 2 > > b43-phy1 debug: DebugFS (CONFIG_DEBUG_FS) not enabled in kernel config > > phy1: Selected rate control algorithm 'pid' > > Broadcom 43xx driver loaded [ Features: P, Firmware-ID: FW13 ] > > firmware: requesting b43/ucode13.fw > > firmware: requesting b43/lp0initvals13.fw Huh? lp0initvals?! johannes signature.asc Description: This is a digitally signed message part ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: 4311 v2 Bail - 2.6.26-rc2
On Wed, 2008-05-14 at 01:33 +0200, Johannes Berg wrote: > > Where does this "wrong buffer size" message come from, and what does it > > mean? > > > > > b43-phy1 debug: Using hardware based encryption for keyidx: 1, mac: > > > ff:ff:ff:ff:ff:ff > > > wlan0: wrong buffer size<7>wlan0: wrong buffer size<7>wlan0: wrong > > > buffer size<7>wlan0: wrong buffer size > > It comes from mac80211 when the AP is sending invalid A-MSDU frames. Wait. If this is with b43, why the hell is it sending A-MSDU frames in the first place? Or maybe it's receiving totally corrupt data. A monitor mode trace would help. johannes signature.asc Description: This is a digitally signed message part ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: 4311 v2 Bail - 2.6.26-rc2
> Where does this "wrong buffer size" message come from, and what does it mean? > > > b43-phy1 debug: Using hardware based encryption for keyidx: 1, mac: > > ff:ff:ff:ff:ff:ff > > wlan0: wrong buffer size<7>wlan0: wrong buffer size<7>wlan0: wrong > > buffer size<7>wlan0: wrong buffer size It comes from mac80211 when the AP is sending invalid A-MSDU frames. johannes signature.asc Description: This is a digitally signed message part ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: BCM4308 rev 3 owner, willing to help (want to make an access point)
On Thu, 2008-05-01 at 03:01 +0200, Francis Galiegue wrote: > > > > > > > > No, "you only need *-allow-ap-vlan-modes.patch for current hostapd git", > > as > > > SERIES says. I think that would be > > > > > http://johannes.sipsolutions.net/patches/kernel/all/LATEST/026-allow-ap-vlan-modes.patch. > > > > > > > OK, it's starting to get a little more clear now. > > > > I've git-pulled the whole wireless-testing, applied this patch and am > > right now in the process of compiling the kernel. > > > > After this, time for hostapd... > > > > With the following patch applied, plus libnl 1.1, and git hostapd... > > unencrypted AP --> success; > WAP --> segfault http://johannes.sipsolutions.net/patches/kernel/all/2008-05-01-00:32/023-mac80211-fix-debugfs-key.patch johannes signature.asc Description: This is a digitally signed message part ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: b43 generates an excesive amount of log
> > Apr 29 01:13:17 lambda kernel: b 9c 13 c7 42 a5 ca 5c 3f e5 f0 e8 98 > > 81 10 d0 ed 6b > That is certainly not coming from b43. > Try to turn off mac80211 debugging. Yeah that looks like verbose TX debugging. Uhum. Do you read Kconfig entries of things you enable? johannes signature.asc Description: This is a digitally signed message part ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: BCM4308 rev 3 owner, willing to help (want to make an access point)
On Mon, 2008-04-28 at 20:06 +0200, Francis Galiegue wrote: > [...] > > > > > > There are some patches to enable AP functionality at > > > http://johannes.sipsolutions.net/patches/ > > > > > > I haven't tried it myself and I don't know any details. > > > > > > > Hmm, lots of stuff in there... I'll dig into this and let you know the > > outcome. > > > > Now, I have a problem :( > > From file http://johannes.sipsolutions.net/patches/kernel/all/LATEST/series: > Does that mean that these patches are merged somewhere? Could could bother to read the series file. johannes signature.asc Description: This is a digitally signed message part ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
RE: Feedback on ASUS WL-138G V2
> > And the ping is from "this box" to the workstation, so the wr-602 isn't > > involved? > > You know, I did ask myself 'I wonder if he wants a little ascii topo-map?' > Obviously I got my own answer wrong. Again... Heh. > You nearly got it right thoughI'll just move what you've drawn around > a little bit...;. > > > (== cable, -- wireless) > > 32bit with asus >| >| > workstation = AP = ADSL > / \ >/ \ > / \ >/ \ > winXP wr-602 this box > That one looks a tad wrong, those wireless links should go to the AP. But so you are pinging across the wr-602. Can you do the same test from any other box? I think most likely the wr-602 isn't doing de-dup correctly. johannes signature.asc Description: This is a digitally signed message part ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
RE: Feedback on ASUS WL-138G V2
> Answering your question -- the remote end consists of the netgear wgr-614 > AP unit ; it's WAN port connected to ADSL modem, and one workstation > connected to it's inbuilt 4-port hub. This is about 10metres down the hall > from my location. > > This end consists of the netgear wr-602 unit in 'client hub' mode, associated > with said AP. This box is connected to the wr-602 by ethernet wire. The 32bit > machine fitted withthe ASUS card is also my end of things, associated to > said AP unit. There is also a winXP box this end of the house, associated to > the same AP (but using a netgear wg311 card, and displaying no errors) > The 32bit machine fitted with the ASUS card is about 2metres from the > wr-602 this end. So let me get this straight, you have (topologically) (== cable, -- wireless) 32bit with asus | | workstation = AP = ADSL |\ | \ this box wr-602 \ \ winXP And the ping is from "this box" to the workstation, so the wr-602 isn't involved? johannes signature.asc Description: This is a digitally signed message part ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: Feedback on ASUS WL-138G V2
> Notice the lack of led devices registering here (as I mentioned before). > Indeed, > the behaviour of the leds is totally different -- now, they come ON and stay > ON when the card is 'active'...ie; ifconfig wlan0 up. Converse is true ; doing > 'ifconfig wlan0 down' turns the leds off again. > > If I dump the sprom image Stefanik provided back into the card, the led device > registration lines reappear in debug, and the leds blink in that sympathetic > way > rx/tx leds do. Is there yet another funky value in sprom responsible for this? Yes, the sprom determines how the card vendor wants the LEDs to behave. You can change this behaviour easily in sysfs. > [from the 'host' box with the asus card] > > 1212 packets transmitted, 1200 packets received, 0% packet loss > round-trip min/avg/max/stddev = 0.821/1.192/5.801/0.366 ms > > ...???.I would've expected almost 1% packet loss (having lost 12 packets) Heh. May be a rounding error somewhere > If I ping the host box from my machine here, the packets have to go out > my eth0 interface into a netgear wr602 in client mode which is associated > with the wgr614 AP down the hall (which is the AP the host is associated > with also). In this case, I get ; > 350 packets transmitted, 344 packets received, +140 duplicates, 1% packet loss > round-trip min/avg/max/stddev = 1.222/1.893/4.296/0.443 ms > > Has anyone any idea what's going on here? Eh, what exactly is your network setup? You normally can't bridge STA mode. This looks like something is not doing ieee 802.11 de-duplication. johannes signature.asc Description: This is a digitally signed message part ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
b43 speed problem over 2.6.24 (was: One more log file from when the network was unusable)
Hi, Miles described a b43 speed problem in the thread 2.6.25-rc9 -- bcm4306 performance is in the toilet (over 2.6.24) and not being able to see anything from his logs/packet captures/... I asked him to bisect. This resulted in commit 61bca6eb85c863603d6054530e2f65c3b9aba85b Author: Stefano Brivio <[EMAIL PROTECTED]> Date: Tue Nov 6 22:49:05 2007 +0100 b43: rewrite A PHY initialization which is a huge commit and hence a bit of a problem. Does anyone have suggestions how to proceed? I have very similar hardware, maybe this card is affected by the boardflags problems we found recently? Miles, can you give us * lspci -vn -s 01:06.0 * the kernel init messages when ssb is built with debugging johannes signature.asc Description: This is a digitally signed message part ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: ASUS WL-138G v2 working with different sprom values
On Fri, 2008-04-18 at 18:24 +0200, Michael Buesch wrote: > On Friday 18 April 2008 18:17:23 Stefanik Gábor wrote: > > According to the README of the Vista driver, the card supports Afterburner, > > To be honest, I don't care for afterburner. It's a horrible > proprietary extension and it's (IMO) not really what people should > be using. > So I'm OK with leaving that bit off. (it's unused in any case). Yeah, the afterburner bit doesn't matter. I think it's marketing thing anyway because afterburner is actually just 802.11e/n frame aggregation in a broadcom-proprietary way, so it isn't really a question whether hw supports it or not, but more whether the vendor wants it on the box or not... I think. johannes signature.asc Description: This is a digitally signed message part ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: ASUS WL-138G v2 working with different sprom values
> It is the BFL_BTCMOD this bit selects which GPIO pin the microcode > uses for disabling the bluetooth chip. > I think the GPIO pin is actually connected to the power amplifier > on this device. So you see what this results in. :) > So the SPROM is buggy and we are missing some workaround for it > in the driver. I think the correct workaround for this card would be > to disable the BFL_BTCOEXIST bit, as there is no bluetooth chip on > the card anyway. So I think that bit is the one that is wrong. > (of course it's also wrong on lots of other cards without a bluetooth > chip. But the bug doesn't trigger there, as they don't use that GPIO > pin for something else) > > I'm not sure how to implement this workaround. How should we decide > when to nuke the bit? Make it depend on the pci ID? johannes signature.asc Description: This is a digitally signed message part ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: ASUS WL-138G v2 working with different sprom values
On Fri, 2008-04-18 at 15:57 +0200, Michael Buesch wrote: > > Following up on this idea of substituting sprom images; > > > > > Oops, sorry, here is the attached SPROM file.> > > Using that sprom dump which Stefanik provided, the card in question here > > appears to be now working (although I've not yet tested it at any length) > > wlan0: associated > > phy0: Added STA 00:1e:2a:61:7d:2c > > ADDRCONF(NETDEV_CHANGE): wlan0: link becomes ready > > That's interesting. I didn't expect this. Maybe one could "bisect" through the sprom to see which values break/make it? Certainly the MAC address won't matter :) johannes signature.asc Description: This is a digitally signed message part ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: New Device
On Thu, 2008-04-17 at 21:35 +0200, Michael Buesch wrote: > On Thursday 17 April 2008 21:26:17 Larry Finger wrote: > > Michael Buesch wrote: > > > On Thursday 17 April 2008 19:47:57 Larry Finger wrote: > > >> b43-phy0 ERROR: FOUND UNSUPPORTED PHY (Analog 6, Type 5, Revision 1) > > > > > > Heh, with an LP-PHY. That is not going to be supported anytime, soon, > > > unless > > > somebody else shows up and writes some specifications and code. > > > > > > > I didn't figure it would. I'll have to put on my RE hat again, check > > out the LP-PHY handler, and generate some specs. After I do that, I > > hope that someone else will actually write code. > > > > Fortunately, I have a BCM4311/2 on the shelf that I can use in the > > meantime. Once we have trial code, I can test it with my new device. > > note that this device also has one of the newer wireless cores, so > there will also be some modifications needed for some non-PHY code. > And of course the changed backplane bits. Not much of a difference, IIRC, except it has different ucode (which might support MBSS operation) johannes signature.asc Description: This is a digitally signed message part ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: [PATCH v2] b43: Add fastpath to b43_mac_suspend()
On Tue, 2008-04-15 at 21:13 +0200, Michael Buesch wrote: > This adds a fastpath for the common workloads to the > MAC suspend flushing. > @@ -2340,12 +2340,20 @@ static void b43_mac_suspend(struct b43_w > b43_power_saving_ctl_bits(dev, B43_PS_AWAKE); > b43_write32(dev, B43_MMIO_MACCTL, > b43_read32(dev, B43_MMIO_MACCTL) > & ~B43_MACCTL_ENABLED); > /* force pci to flush the write */ > b43_read32(dev, B43_MMIO_MACCTL); > + /* Finally wait for the microcode to flush the fifos. */ That comment is wrong, the ucode won't flush the FIFOs, it'll just go to sleep. If you want it to flush FIFOs you have to set a flush request bit somewhere (mac command I think), but you don't actually, you just don't want to have it processing stuff. johannes signature.asc Description: This is a digitally signed message part ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: mac80211 sysfs interface
On Wed, 2008-04-16 at 17:58 +0200, Holger Schurig wrote: > Hmm, I found "ip" and it's built in help confusing ... at least > two years ago, things might have changed. > > Since then I'm using "ifconfig" / "route" again ... What? No way. I can remember the 'ip' commands much much better than the mangled ifconfig syntax. johannes signature.asc Description: This is a digitally signed message part ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: mac80211 sysfs interface
> > Yeah, me too. But the current iw syntax is just really confusing. :) > > I guess there's room for improving it. > > But the tool name "iw" is just fine, IMO. Less to type = better. > > Could we make it reference the wiphy instead of the wmaster? I still > hold-out some hope of making wmaster go away eventually... Yes, that's the plan, there are even some stubs for that in the code. johannes signature.asc Description: This is a digitally signed message part ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: mac80211 sysfs interface
On Wed, 2008-04-16 at 14:06 +0200, Stefanik Gábor wrote: > My recommendations: nl80211 or nlconfig, since it controls NL80211. > Also, the syntax "nl80211 --add --master=wmaster0 --mode=monitor > mon0" (or, using short parameters, "nlconfig -a -m=monitor -p=wmaster0 > mon0" - "-a" for an alias of "--add", "-m" for "--mode" and "-p" for > "--master") would be much better than the current one. (This is pretty > similar to kexec's or aircrack-ng's syntax, and is used by many other > commands.) I accept patches but I'd *much* rather have a syntax like the "ip" tool. johannes signature.asc Description: This is a digitally signed message part ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: B43 problem with wireless-testing 2.6.25-rc8 from APR 8 commit -- ARPs no longer go through
> FYI I didn't manually do anything for the sample I submitted. In that > one I simply used NetworkManager and it "just Connected" and never did > anything else. > > In previous tests I'd eliminated NetworkManager by manually setting the > ESSID and WEP key*. Since that made no difference I went back to NM. Hmm. I do wonder why your key was re-set in the middle then, that shouldn't happen normally, but it must of course still be supported. In any case, the ordering of the hw accel calls was wrong, which was the problem. > Again, thanks for the quick response, and the quick fix :) Well, thank you for providing all the info needed to fix the bug. If every bug report was this useful... :) johannes signature.asc Description: This is a digitally signed message part ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: B43 problem with wireless-testing 2.6.25-rc8 from APR 8 commit -- ARPs no longer go through
> > As you can see in the log, the WEP key is getting disabled. printk > > timestamps would help to identify what really happens. > > > > > Missed that! No worries. I was just a bit confused because I couldn't tell whether the enable/disable messages were directly after one another or not. > I was going to but then you released the followup [PATCH] mac80211: fix > key todo list order so I tried that. > > That fixed the problem :) Good to know, thanks for testing. We really want both patches, and the previous one would have "fixed" the problem too because you were using WEP, with WPA the problem might still have happened. johannes signature.asc Description: This is a digitally signed message part ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: B43 problem with wireless-testing 2.6.25-rc8 from APR 8 commit -- ARPs no longer go through
> When the problem occurs, wireshark on the wlan (laptop) side shows ARP > requests that are not responded to. > When the problem occurs, wireshark on the LAN (wired) side does not show > those ARP requests. As you can see in the log, the WEP key is getting disabled. printk timestamps would help to identify what really happens. > b43-phy0 debug: Using hardware based encryption for keyidx: 0, mac: > ff:ff:ff:ff:ff:ff Here you set the key first > wlan0: associated > wlan0: switched to short barker preamble (BSSID=00:16:01:b9:f9:3f) and associated > wlan0: authenticate with AP 00:16:01:b9:f9:3f > b43-phy0 debug: Using hardware based encryption for keyidx: 0, mac: > ff:ff:ff:ff:ff:ff > b43-phy0 debug: Disabling hardware based encryption for keyidx: 0, > mac: ff:ff:ff:ff:ff:ff Somehow you're deauthenticated, maybe manually? The strange thing is the order here, why is it adding the key again, and then deleting it? Can you please try the patch [PATCH v2] mac80211: fix key hwaccel race johannes johannes signature.asc Description: This is a digitally signed message part ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: BCM4318 (ASUS WL-500gP) & hostapd problem
On Sun, 2008-04-06 at 18:33 +0400, Artem Antonov wrote: > I've solved my problem with this patch: > > diff -urN hostap/hostapd/driver_nl80211.c > hostap/hostapd/driver_nl80211.c > --- hostap/hostapd/driver_nl80211.c 2008-04-05 09:00:34.0 > +0400 > +++ hostap/hostapd/driver_nl80211.c 2008-04-06 17:16:35.0 > +0400 > @@ -1689,7 +1692,8 @@ > return; > } > - if (have_ifidx(drv, lladdr.sll_ifindex)) > + if ((have_ifidx(drv, lladdr.sll_ifindex)) > + || (lladdr.sll_ifindex == if_nametoindex(hapd->conf->bridge))) > ieee802_1x_receive(hapd, lladdr.sll_addr, buf, len); Please post that as a usable patch to the hostapd mailing list and CC me. johannes signature.asc Description: This is a digitally signed message part ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: [PATCH] b43: Fix PHY TX control words in SHM
On Fri, 2008-04-04 at 21:43 +0200, Michael Buesch wrote: > This fixes the initialization of the PHY TX control words in > shared memory. These control words are used for management frames > like beacons. This actually breaks beacons, if I don't use this it sends them, otherwise it only gets PHY TX errors for beacons. johannes signature.asc Description: This is a digitally signed message part ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: [PATCH RFT] b43: We need lots of regression testing
> Another unrelated bug (sorry, testing often finds unrelated bugs) is > that scanning with specific ESSID was returning non-matching APs. I > mean "iwlist wlan0 scan my_essid", which would still report many > different ESSIDs. It's inconvenient when the driver can sense 22 APs at > once :) Heh. I'm not sure what the desired behaviour is, if you do that scan we'll give you everything we found but will scan actively for that particular SSID. The man page (sigh) only says: This command take optional arguments, however most drivers will ignore those. The option essid is used to specify a scan on a specific ESSID. The option last do not trigger a scan and read left-over scan results. Which isn't quite clear, but seems to match what we do. Maybe iwlist should filter it? johannes signature.asc Description: This is a digitally signed message part ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: [PATCH] b43: Add PIO support for PCMCIA devices
> PIO is needed for 16bit PCMCIA devices, as we really don't want to poke with > the braindead DMA mechanisms on PCMCIA sockets. Additionally, not all > PCMCIA sockets do actually support DMA in 16bit mode (mine doesn't). Oddly, my CF card still doesn't work. Is there anything else I need in a current wireless-testing tree? johannes signature.asc Description: This is a digitally signed message part ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: Urgent help needed: Broadcom 4318 SPROM corruption
On Tue, 2008-04-01 at 20:40 +0200, Stefanik Gábor wrote: > Looks like my SPROM (the actual hardware) died. Am I right? Actually, I would suspect more than that died since the SPROM doesn't contain any PCI stuff besides the IDs, the IO ports/MMIO windows/expansion rom stuff all looks wrong. > Also, b43 doesn't even get loaded, and trying to load it makes > modprobe freeze. Looks more and more like hardware. > On a related note: What is "prog-if be"? wasn't there before the card failed. No idea, sorry. johannes signature.asc Description: This is a digitally signed message part ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
