Suspending 802.11 drivers
Hi, I am currently thinking about the best way to correctly implement PM suspending for wireless drivers. Currently, the 802.11 stack is not suspend aware (if I talk about stack here, I mostly mean devicescape). For example, if we suspend the bcm43xx driver, we don't notify the stack before doing so. That's a bug. I would say, we should have two functions, which are called from the driver suspend and resume callbacks. Let's call them ieee80211_suspend() and ieee80211_resume() for now. The suspend would save all status information, for example to which AP we are associated and so on. After that it would cleanly disassociate from the AP and do other cleanups which are needed. The resume function would try to re-esablish the connection. Of course, that will not always be possible (the notebook owner traveled around half the world between suspend and resume ;) ). But that does not matter. We simply return silently without a new association (Do a new scan, or whatever). Are such functions generally desireable? -- Greetings Michael. ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de http://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: Suspending 802.11 drivers
On Thursday 15 June 2006 22:12, Florian Fainelli wrote: Hello Michael, I think these are really interesting functions. Currently I scripted a bit to do module unloading/loading on suspend/resume requests plus supplicant context saving and restart. Of course, if the driver is able to manage this by itself, it's far better. Well, if the _suspend() and _resume() semantics are actually implemented in kernel or userspace is another question. I would say, it should be possible to defer it to userspace, after the userspace MLME stuff is done. But that does not really matter here to get my point. My point is: ieee80211 subsystem should provide functions which save/restore the whole state of the stack (Well, the state of running connections and associations ,actually). How these functions are implemented internally is another matter. But I would also say that it sounds sane to put these semantics into userspace, in the long term. Any news on the power management specifications ? No. I think I will start another attempt to measure the power consumption of the card, soon. Maybe this time I will be able to figure out the meaning of the PS bits :) I think I forgot to set important bits last time I checked. -- Greetings Michael. ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de http://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: Suspending 802.11 drivers
On Thu, 2006-06-15 at 22:42 +0200, Michael Buesch wrote: My point is: ieee80211 subsystem should provide functions which save/restore the whole state of the stack (Well, the state of running connections and associations ,actually). How these functions are implemented internally is another matter. I don't really know how that works, but currently (using 2.6.17-rc6 kernel with softmac stack), pure open connections keep their state during sleep/wakeup. I don't have anything to do when resuming. -- Yves-Alexis Perez ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de http://lists.berlios.de/mailman/listinfo/bcm43xx-dev
HELP! :) Problems w/driver -- REDUX (4306 card in laptop)
Okay...this still isn't working...nothing I do is helping. I'm going to repost this message in it's entirety, including the responses I got, and let's try this again... I've been having problems getting the driver working, and was told to post this question here, after trying on the bcm43xx forum. I've got a Compaq Presario R3240US laptop. It's got a Broadcom 4306 built in. This combination is working with ndiswrapper. My AP is running WPA-PSK with AES encryption, so I'm currently running the wireless-dev kernel (which I updated today to check before mailing this). First thing I noticed is that if I don't modprobe aes, I get a kernel panic upon running wpa_supplicant. But I was able to figure that out and once I modprobe that and bcm43xx_d80211 I'm able to get a connection after running wpa_supplicant. Now, here's my problem: After a short time, the connection is lost. I've been trying to send a 30M file through scp. I notice that the data throughput starts at a decent rate and immediately starts falling and continues to fall until the connection is lost. I am currently running wpa_supplicant in -D so I can see what's going on. Once the connection is lost, it goes into a loop where it cannot get the handshake. Killing wpa_supplicant, removing and reinstalling the module sometimes works again, but the same thing occurs. Sometimes when I attempt to remove the module, I get a kernel panic. If need be I can attach a copy of the output from wpa_supplicant. P.S. I thought the Enable local IRQs while executing patch sounded like it might be the trick, but I applied it and it did not help. Any help would be appreciated, or if I should be directing this question elsewhere, a pointer to where I should direct this would also be appreciated. Thanks. - Matt Andruff replied: Depending on what OS your running results may vary, what is the current data rate that you are using? I've seen issues on Ubuntu with having to manually reduce the rate (iwconfig eth1 rate 22M) to have things run consistantly. Infact, I used to have to run at 11Mb/s all the time but recent developments have let me go a litttle faster, 36Mb/s but it's not stable, and I get some dropped packets, meaning variable speed. I replied back: I'm running Slackware Linux. It seems like the rate change ability is gone at the moment... When I look at the iwconfig wlan0 it doesn't print rate information and when I try to change the rate, it gives me an error saying it cannot be changed. I had always found bcm43xx to be defaulting to 11M in earlier versions, and figured it was again. When I start it up and start the scp it's only giving me around 181K/s to start and goes down from there. Matt Andruff replied: k when your ability returns to change returns then lets change to 11M and see what happens, if you stay without aid for a while we could try, using the ubuntu package with alien to import it properly to you system, but hopefully the ability to change the rate returns, what rate is listed when you run 'iwconfig [interface] This doesn't help me...here is the output from iwconfig: wmaster0 IEEE 802.11g ESSID: Mode:Master Frequency:2.462 GHz RTS thr:off Fragment thr=2346 B Encryption key:off wlan0 IEEE 802.11g ESSID:XX Mode:Managed Frequency:2.462 GHz Access Point: Not-Associated RTS thr:off Fragment thr=2346 B Encryption key:off As you can see, there is ***NO*** rate information. There *USED TO BE*...I can't remember what revision I was running when it was there...but it is not there now. I have no way of changing it. As I said in my last message...when I attempt to change it I get a message saying it cannot be changed: Error for wireless request Set Bit Rate (8B20) : SET failed on device wlan0 ; Operation not supported. And, seeing the other thread on the 4306 here, here's my dmesg info: bcm43xx_d80211 driver ACPI: PCI Interrupt Link [LNK3] enabled at IRQ 11 ACPI: PCI Interrupt :02:02.0[A] - Link [LNK3] - GSI 11 (level, low) - IRQ 11 bcm43xx_d80211: Chip ID 0x4306, rev 0x3 bcm43xx_d80211: Number of cores: 5 bcm43xx_d80211: Core 0: ID 0x800, rev 0x4, vendor 0x4243, enabled bcm43xx_d80211: Core 1: ID 0x812, rev 0x5, vendor 0x4243, disabled bcm43xx_d80211: Core 2: ID 0x80d, rev 0x2, vendor 0x4243, enabled bcm43xx_d80211: Core 3: ID 0x807, rev 0x2, vendor 0x4243, disabled bcm43xx_d80211: Core 4: ID 0x804, rev 0x9, vendor 0x4243, enabled bcm43xx_d80211: PHY connected bcm43xx_d80211: Detected PHY: Version: 2, Type 2, Revision 2 bcm43xx_d80211: Detected Radio: ID: 2205017f (Manuf: 17f Ver: 2050 Rev: 2) bcm43xx_d80211: Radio turned off bcm43xx_d80211: Radio turned off bcm43xx_d80211: Virtual interface added (type: 0x0002, ID: 5, MAC: 00:90:4b:5d:ae:6a) bcm43xx_d80211: PHY connected bcm43xx_d80211: Radio turned
Re: [PATCH] bcm43xx: use softmac-suggested TX rate
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Michael Buesch wrote: Hi John, Sorry, took a little bit longer than expected, but here it is. :) Please queue for 2.6.18. -- From: Daniel Drake [EMAIL PROTECTED] Use Softmac-suggested TX ratecode: ieee80211softmac_suggest_txrate() Signed-off-by: Daniel Drake [EMAIL PROTECTED] Signed-off-by: Michael Buesch [EMAIL PROTECTED] Index: wireless-2.6/drivers/net/wireless/bcm43xx/bcm43xx_xmit.c === --- wireless-2.6.orig/drivers/net/wireless/bcm43xx/bcm43xx_xmit.c 2006-06-14 16:53:50.0 +0200 +++ wireless-2.6/drivers/net/wireless/bcm43xx/bcm43xx_xmit.c 2006-06-14 17:44:23.0 +0200 @@ -296,11 +296,14 @@ u16 control = 0; u16 wsec_rate = 0; u16 encrypt_frame; + const u16 ftype = WLAN_FC_GET_TYPE(le16_to_cpu(wireless_header-frame_ctl)); + const int is_mgt = (ftype == IEEE80211_FTYPE_MGMT); /* Now construct the TX header. */ memset(txhdr, 0, sizeof(*txhdr)); - bitrate = bcm-softmac-txrates.default_rate; + bitrate = ieee80211softmac_suggest_txrate(bcm-softmac, + is_multicast_ether_addr(wireless_header-addr1), is_mgt); ofdm_modulation = !(ieee80211_is_cck_rate(bitrate)); fallback_bitrate = bcm43xx_calc_fallback_rate(bitrate); fallback_ofdm_modulation = !(ieee80211_is_cck_rate(fallback_bitrate)); Well I decided to take the plunge and test this for you all. Only problem is it fails to compile CC net/ieee80211/softmac/ieee80211softmac_io.o net/ieee80211/softmac/ieee80211softmac_io.c: In function 'ieee80211softmac_send_mgt_frame': net/ieee80211/softmac/ieee80211softmac_io.c:463: error: too many arguments to function 'ieee80211_tx_frame' make[3]: *** [net/ieee80211/softmac/ieee80211softmac_io.o] Error 1 make[2]: *** [net/ieee80211/softmac] Error 2 make[1]: *** [net/ieee80211] Error 2 make: *** [net] Error 2 I will look into it tomorrow night unless once of you get around to it before then. Jory -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.3 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFEki3iGDfjNg8unQIRAhMzAJ4rvfbtJS2FiXyOMkf9lVI41QYDwQCgrmus K9z8D/x5HFCi1dGBMaF+fb0= =u26i -END PGP SIGNATURE- ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de http://lists.berlios.de/mailman/listinfo/bcm43xx-dev
