network_reconnect_resume_test cannot work for most wifi chips

When writing this test I didn't have any non intel wifi cards available at my disposal. I asked Brendan to post the dmesg output of his non-intel wifi controller here in the bug so we can take a look and find some sort of string to parse.

It looks like it's not restricted to non-Intel. This system does have an Intel wireless chip but there is no sign of the required string in dmesg: http://paste.ubuntu.com/1271397/

Today if I have time I'll see if we can maybe use the following output to denote if the wifi card is enabled.

[151756.284050] iwlwifi 0000:06:00.0: >L1 Disabled; Enabling L0S
[151756.291093] iwlwifi 0000:06:00.0: >Radio type=0x1-0x3-0x1

The output from comment #3 is from my system,

The output pasted below from Brendan shows

[85517.817496] iwlwifi 0000:02:00.0: L1 Enabled; Disabling L0S
[85517.824637] iwlwifi 0000:02:00.0: Radio type=0x1-0x2-0x0

Note: there is no "<" preceding the L1 Enabled.

Heres my initial thought, we can leave the script as it is and look for wlan, this should cover most intel / realtek drivers. Then, add a simple check so that if wlan is not found then look for iwlwifi as a secondary for broadcom drivers.

The following regex should be able to look for L1 Enabled; Disabling L0S

re.compile("\[(.*)\] iwlwifi.* *L1 Disabled; Enabling L0S")

I made some modifications to the script was able to get my hands on a Dell Vostro, on this particular system the ASPM states were reporting differently,

[ 13.984149] iwlwifi 0000:01:00.0: L1 Enabled; Disabling L0S
[ 13.990844] iwlwifi 0000:01:00.0: Radio type=0x1-0x2-0x0

I believe this has to do with laptop vendor , bios & pci-e. So I don't think we can use this as a reliable marker to signify when wifi is initializing. Alternatively there was a 6.59 second difference from the time the radio was initialized to wifi actually connect to an access point.

So far I found that Intel , Atheros , Realtek all report WLAN appropriately, I was able to get my hands on a older broadcom chipset which used the TG3 driver, that was really no help as dmesg didn't report much.

I may have to look into tailing the syslog to identify when the network starts up if using a broadcom chipset but thats going to require more time to look into. If anyone else has some ideas let me know.

Sean, I've assigned the bug to you again since you seem to be actively looking at this. Let us know how things are going.

I'm going to take this bug over and what we'll do is make it so that the test doesn't fail if it can't calculate the time to resume, only if it exceeds the expected threshold (i.e. resume is provably slow)