Please note: This project is no longer active. The website is kept online for historic purposes only.
If you´re looking for a Linux driver for your Atheros WLAN device, you should continue here .

Ticket #671 (closed defect: fixed)

Opened 13 years ago

Last modified 13 years ago

STA mode: resume doesn't restart ath0 device

Reported by: espy@pepper.com Assigned to:
Priority: major Milestone:
Component: madwifi: 802.11 stack Version:
Keywords: Cc:
Patch is attached: 1 Pending:

Description

If a 2.6.x system running the latest madwifi driver (snapshot: 1630) with a PCI wifi card is put to sleep (S3) and then resumed (S0), the IFF_RUNNING flag is not reset in the net_device.flags of ath0.

If the IFF_RUNNING flag is not set for ath0, then scanning doesn't work due to the fact that the device is not considered UP ( see ieee80211_ioctl_siwscan() ). If the system in question is also running wpa_supplicant, it won't re-associate due to the fact that scanning doesn't work.

The interesting thing is that if you're manually controlling association via iwconfig, the act of setting the essid kicks the devices and causes IFF_RUNNING to be set ( see ieee80211_ioctl_siwessid() ) and everything works just fine.

I added some debug statements to the code and clearly watch IFF_RUNNING cleared for wifi0 by ath_stop_locked() and for ath0 by ieee80211_stop(). On resume ath_init() restores IFF_RUNNING for wifi0. ath_init() in turn calls ieee80211_start_running() which is supposed to start all VAPs. Unfortunately, it only calls ieee80211_open(dev) if the IFF_RUNNING flag is already set for the device, which in this case it clearly is not.

I also checked and ieee80211_start_running() is only called from ath_init().

Also I did search for other suspend resume bugs. Ticket #201 originally describes what sounds like a hardware problem with resetting the card on resume, although one of the comments does mention using ifconfig up/down to resolve problems. Ticket #494 also mentions that suspend/resume doesn't work if there are VAPs however due to the lack of detail supplied I decided that creating a new ticket was the best thing to do.

Here are the specifics of my system:

* AMD Geode processor running on a Pepper prototype system
* Distribution: Pepper / FC4-based
* Kernel: 2.6.12 w/AMD Geode specific patches 
* Wireless Extensions v17
* WiFi Hw: mini-PCI b/g card using an AR2413 chip ( PCI Device ID: 0x001a )
* wpa_supplicant v0.4.7 w/Pepper-specific patches

Attachments

madwifi-resume.patch (458 bytes) - added by espy@pepper.com on 06/08/06 00:42:26.
madwifi-resume-2.patch (483 bytes) - added by espy@pepper.com on 08/02/06 01:01:01.

Change History

06/08/06 00:42:26 changed by espy@pepper.com

  • attachment madwifi-resume.patch added.

06/25/06 00:48:03 changed by espy@pepper.com

The attached patch causes the station VAP to be restarted when the PCI resume function in the driver, ath_pci_resume(), is called.

Signed-off-by: Tony Espy <espy@pepper.com>, Pepper Computer, Inc.

06/27/06 14:26:07 changed by kelmo

Hi espy,

I've been playing around with your patch and some of the HAL specific calls used in svens early patches on #201, will report back soon.

07/31/06 11:15:53 changed by kelmo

This seems wrong to me. With the change, madwifi driven devices that go into suspend idle and not even used are resumed in an up operstate; scanning and so on. Are you sure this properly addresses the problem you want fixed?

07/31/06 22:33:25 changed by espy@pepper.com

The patch makes things works when MADWiFi is configured with a single station VAP, which is how the Pepper Pad is configured. That said, I never expected this patch to cover all bases, but merely to illustrate that suspend/resume is busted when running as a station with wpa_supplicant in control.

After re-examing the patch, a possible modification would be to modify the if stmt to check that the IFF_UP flag is set before calling ieee80211_open(). I'll give that a try and see if it works in our case.

Also, FYI, we're currently running MADWiFi 0.9.1 with 6 patches ( including this one ). When I get back from vacation, I plan on trying to test with 0.9.2 and will post my results as well as a summary of the current patches we're using for Pepper Pad 3.

08/01/06 09:27:38 changed by kelmo

Thanks for your interest in correcting the poor behaviour. Hope to here from you soon.

08/02/06 01:01:01 changed by espy@pepper.com

  • attachment madwifi-resume-2.patch added.

08/02/06 01:08:11 changed by espy@pepper.com

I revised my patch to check that the device's IFF_UP flag is set in addition to IFF_RUNNING being clear, before ieee80211_open(dev) is called.

As I mentioned above, I've only tested this patch with the driver configured with a single station VAP.

Signed-off-by: Tony Espy <espy@pepper.com>, Pepper Computer, Inc.

08/07/06 16:31:14 changed by mentor

  • patch_attached set to 1.

08/07/06 16:31:53 changed by mentor

Patch needs reviewing and integrating.

08/08/06 17:41:17 changed by mentor

committed in r1699

08/09/06 17:11:54 changed by mentor

  • status changed from new to closed.
  • resolution set to fixed.

Closing as fixed. Reopen if necessary.