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 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: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 zaj...@gmail.com: 2010/2/20 Larry Finger larry.fin...@lwfinger.net: Some of the N PHYs need a revision in the handling of the PMU. Signed-off-by: Larry Finger larry.fin...@lwfinger.net --- 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 albert_herr...@yahoo.es 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: [c0239375]
__cancel_work_timer+0x8c/0x18e
[ 72.007617]
[ 72.007617] but task is already holding lock:
[ 72.007617] (wl-mutex){+.+.+.}, at: [f8fa5359] 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: 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: 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 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: [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: [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 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 dreamfly...@gmail.com
---
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: [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 dreamfly...@gmail.com
---
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: [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: [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: [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
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
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: [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: [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 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: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 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: 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: 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: [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: [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 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: [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: [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 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 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 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: [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: [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: [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] 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 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 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 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: 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 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
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 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: 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: 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: 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: 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: 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: [f8dd3a99] :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: [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
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: 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
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: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 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
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 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: 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
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 size7wlan0: wrong buffer size7wlan0: wrong buffer size7wlan0: 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: 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: 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: 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
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 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: 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 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: 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 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: [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: 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: 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
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: 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 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: 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] 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
Re: Urgent help needed: Broadcom 4318 SPROM corruption
On Mon, 2008-03-31 at 22:22 +0200, Stefanik Gábor wrote: Thanks, now I got the ssb_sprom file in place, but it's completely corrupt (0120... until the end, ssb-sprom says CRC error, if I run it with --force -P, I get for all values). Could someone upload an SPROM dump for his card (preferably a 4318 or possibly a 4311)? Because I didn't have an SPROM backup. I hope you at least still remember your MAC address :) I cannot give you a 4318 dump as the only 4318 I own is the pcmcia one. 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: Problems with a bcm4306 (03) and b43/b43legacy
wpa_supplicant seems to find a suitable AP and it is requesting kernel (mac80211 in this case) to associate. However, that is timing out. wpa_supplicant does not has visibility to what mac80211 does here, so the next step would be to debug what is happening there (first step might be to just take a look at 'dmesg' output). It looks like either the AP is rejecting the STA for some reason or the STA does not even try to associate. Just to expand on that, you need to enable mac80211 debugging to get decent output for this case, and it is well possible that it's still a driver problem if mac80211 is transmitting packets to the driver but they never make it to the air. Please enable mac80211 debugging and post the kernel's log. 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: Problems with a bcm4306 (03) and b43/b43legacy
http://pastebin.org/25229 for b43, and that doesn't seem to exist any more. 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: More on ASUS WL-138G V2
...I'd be fairly sure that I shouldn't see this either ; wlan0: authenticate with AP 00:1e:2a:61:7d:2c phy3: TX to low-level driver (len=30) FC=0x00b0 DUR=0x013a A1=00:1e:2a:61:7d:2c A2=00:1b:fc:61:15:e1 A3=00:1e:2a:61:7d:2c wlan0: authenticate with AP 00:1e:2a:61:7d:2c phy3: TX to low-level driver (len=30) FC=0x00b0 DUR=0x013a A1=00:1e:2a:61:7d:2c A2=00:1b:fc:61:15:e1 A3=00:1e:2a:61:7d:2c wlan0: authentication with AP 00:1e:2a:61:7d:2c timed out For one you should turn off low-level debugging ;) But the timeouts are another matter. on the other hand, if RX packets = 0 on the interface and that's true, then I probably would expect to see something like that... Not entirely sure those stats are kept properly, but I think they are. Strangely, turning encryption off altogether in the AP itself and the linux setup here, made absolutely no difference apart from the fact that you then don't get debug messages about authentication attempts and failures.and this make me think it's not authenticaion/encryption, seeing as the use (or not) of such security measures makes absolutly no difference to the tcpip layer - it seems dead. AFAICT, the radio (wireless) layer is doing all the right things, and the tcpip networking routingshould work, but and alas nothing happens...in fact, I doubt I've see ANY count on RX packets on wlan0 ever No, it's more likely a transmission bug. Can you enable b43 debugfs, mount debugfs, and check the output of cat /debug/b43/phy*/txstat One other curious thing -- if this machine is at 172.16.1.234 and the wireless AP is at 172.16.1.1 and I try to ping that end address across wlan0, the ping command itself performs very slowly, and I'll have to send it several rapidfire ^C breaks to get it to return. It might take it up to 10second to release and give me my prompt back, but in doing so it reports that it only got around to sending 3 packets in 10-15seconds worth of realtime - this is fairly bizarre behaviour, and no..there's no firewall in anyone's way. That's pretty normal if it cannot reverse-resolve the name. 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 (BCM4318 non-E rev02) scans but doesn't associate using b43 driver, works with bcm43xx
On Mon, 2008-03-17 at 11:09 +0100, Stefanik Gábor wrote: Not sure if it's related, but I have read somewhere that 4318/02 requires wl_apsta.o when using fw4.80.53, it doesn't work with wl_apsta_mimo.o from the same package. There are lots of rumors, but they are all false. 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 (BCM4318 non-E rev02) scans but doesn't associate using b43 driver, works with bcm43xx
On Mon, 2008-03-17 at 12:36 +0100, Stefanik Gábor wrote: If you also meant this to be an answer for the regdom lockout, then all I can say is that I haven't read that on the web, it's what I am seeing. With the bcm43xx driver (that works to some extent), I can switch to channels 1-13, but not 14, even if the regulatory domain is set to Japan. It gives Operation not permitted. Possibly this is Asus-specific (and not present on other 4318/02-based cards), and maybe it is only present in EU versions (so US and JP versions are identical). Ahrg. I don't get why people think that this is related to the firmware. It's cfg80211's fault because it defaults to the US domain. 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 (BCM4318 non-E rev02) scans but doesn't associate using b43 driver, works with bcm43xx
On Sat, 2008-03-15 at 14:19 +0100, Stefanik Gábor wrote: Wait, are you Hungarian too? Looks like b43 specifically hates 4318/02s designed for the EU (13 channel versions). Nah. The hardware is identical, regulatory enforcement is done in software. Someone from the USA should confirm, this looks more and more like a mac80211 bug. (Note: my AP is on channel 1, so it's not in the EU-only range.) Also, are there any records of an EU 4318/02 user getting b43 to work? Japan might also be of interest. Someone should also try loading mac80211 (or cfg80211 on the wireless-testing tree) with ieee80211_regdom=64 to see if that helps. (I can't, as my OpenSUSE box died.) You currently can't use channels 12/13 with mac80211, but that shouldn't matter if your AP is on channel 1. 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: powerbook 4306 disassociate/reassociate 'bouncing' with b43/2.6.24.x
On Fri, 2008-03-07 at 14:03 +0100, Rafał Miłecki wrote: Mar 7 13:23:05 acer kernel: wlan0: associate with AP 00:18:39:dd:ee:78 Mar 7 13:23:05 acer kernel: wlan0: authentication frame received from 00:18:39:dd:ee:78, but not in authenticate state - ignored Mar 7 13:23:05 acer kernel: wlan0: RX deauthentication from 00:18:39:dd:ee:78 (reason=6) Maybe somebody's trying to hack your network? reason 6 means WLAN_REASON_CLASS2_FRAME_FROM_NONAUTH_STA which means: don't send association frames when you're not authenticated. 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: powerbook 4306 disassociate/reassociate 'bouncing' with b43/2.6.24.x
Mar 7 13:23:05 acer kernel: wlan0: associate with AP 00:18:39:dd:ee:78 Mar 7 13:23:05 acer kernel: wlan0: authentication frame received from 00:18:39:dd:ee:78, but not in authenticate state - ignored Mar 7 13:23:05 acer kernel: wlan0: RX deauthentication from 00:18:39:dd:ee:78 (reason=6) Maybe somebody's trying to hack your network? reason 6 means WLAN_REASON_CLASS2_FRAME_FROM_NONAUTH_STA which means: don't send association frames when you're not authenticated. Well, I can't be 100% sure that there isn't anyone trying to break my network's security but: 1) I live outside town, there are only a few houses in my neightbour 2) I already had this disassociate problem two weeks ago so I think noone would try to hack my network for 2 weeks :) Heh ok. So I guess it's more likely that you're sending those rogue packets yourself. Do you have a second card and can provide a monitor dump? 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: AP mode with b43 driver shipped in 2.6.24
1) I need another firmware for the AP mode 2) I must not use iwconfig but this new configuration tool for cfg80211 3) I need a newer driver than the one included in 2.6.24 4) I have to use this hostap deamon? 5) I must specify an option when loading the b43 module (although modinfo b43 does not show my any matching options) 6) no more ideas ... 7) you have to get a clue and hostapd. and no, I won't support you. you need kernel and hostapd patches too which you can find on the linux wireless list. 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: powerbook 4306 disassociate/reassociate 'bouncing' with b43/2.6.24.x
On Wed, 2008-02-27 at 12:48 -0700, David Wilk wrote: awesome! thank you *very* much. I wish I was a bit more source-savvy. Any idea what 17 means and what would cause this? 15: 4-way handshake timeout 3: deauth leaving (sent by the client, not AP) 17: IE different (probably RSN/WPA) :) Not really, no, sorry. Something wrong with the WPA implementation on either side of the connection? 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 broadcom 14e4:4315 device
b43-phy6 ERROR: PHY transmission error Which is not that strange since its not supported. Actually, that is a bit strange, wrong PHY programming usually only causes the packets to never be sent out and none to be received. I guess in this case the PHY isn't even turned on so the Microcode notices that something is wrong with it. If it was just calibrated wrongly it wouldn't know. 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: firmware version for 2.6.25-rcX
My concern was related with the what firmware to have in an eventual kernel update... say when updating to Fedora 9 my laptop. That's why I was asking to use different filenames for the new firmware, so that the answer could be both. Maybe it's not too late? 2.6.25 wasn't released yet. The newer driver still supports the old firmware version and will until 2.6.26 or whatever. That should be enough. 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: powerbook 4306 disassociate/reassociate 'bouncing' with b43/2.6.24.x
also, I was wondering what the reason codes were (17 above). I've gotten reason=3 and reason=17. google didn't help me find anything useful here, and I looked through the source a bit as well. I also saw 15. include/linux/ieee80211.h, look for enum ieee80211_reasoncode 15: 4-way handshake timeout 3: deauth leaving (sent by the client, not AP) 17: IE different (probably RSN/WPA) 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 broadcom 14e4:4315 device
I hacked the bcm43xx driver in a linux 2.6.23 kernel to also include the pci id of this card. Fails as expected, but maybe this dmesg info is usefull: bcm43xx: Chip ID 0x4312, rev 0x1 bcm43xx: Number of cores: 4 bcm43xx: Core 0: ID 0x800, rev 0x16, vendor 0x4243 bcm43xx: Core 1: ID 0x812, rev 0xf, vendor 0x4243 bcm43xx: Unsupported 80211 core revision 15 bcm43xx: Core 2: ID 0x80d, rev 0xa, vendor 0x4243 bcm43xx: Core 3: ID 0x820, rev 0x9, vendor 0x4243 bcm43xx: WARNING: Invalid SPROM checksum (0xB6, expected: 0xFF) bcm43xx: Detected PHY: Analog: 6, Type 5, Revision 1 bcm43xx: Error: Unknown PHY Type 5 Probably this chip with preliminary N support: http://www.broadcom.com/products/Wireless-LAN/802.11-Wireless-LAN-Solutions/BCM94321MC Will this chip be supported by future version of this driver? If you want to help make it happen join the RE team ;) We're, very slowly, working on 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 RFT] b43: Fix beaconing
On Thu, 2008-02-21 at 17:57 +0100, Michael Buesch wrote: Can you please test if this fixes beaconing? Hmm, unfortunately not. This results in continuous beacon update interrupts because when both templates are valid we keep them valid all the time. Hence, it's not usable. I really wonder wtf. is going on. Why do we even have two beacon templates if we can't mark them both as valid at the same time? My earlier debugging change marked only the first one ever valid and that seems to work because the machine is fast enough... Basically, I think the machine has to always be fast enough to upload a beacon template within a beacon interval. That's pretty much guaranteed though so no big deal. I guess the only reason why there are two beacon templates is the processing latency. When the beacon template ready (for modification by host) interrupt comes in, we might only get to process it even later than that, and the ucode might need another beacon rather quickly. It needs to be guaranteed that the ucode has another beacon before it needs to send one, so the latency must not be higher than the beacon interval, but that should be fine. If we have to then change/upload the beacon though, maybe the thinking is that the latency combined with the template RAM write might be long enough to not allow uploading the complete beacon again before the next one is needed. Hence, the ability to upload both and with a just one MMIO read and write switch to the second one before uploading the first. I think what we should do is this: * we upload both beacon templates whenever we control them and it's necessary * however, we only mark one of them as hardware valid Then, when the beacon template ready (for modification by host) interrupt comes in, we check for which one the interrupt came in and mark the other template as valid immediately. This allows us to mark it *really* quickly, ie. with just a single MMIO read/write and could be done even in the interrupt handler itself. Then, we can lazily see later if we need to change the beacon template data and upload that without having too much timing pressure. Then, on the next interrupt, we switch to this one etc. 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
