wireless takes long time to find networks

[zpletan]

On a Dell Studio 1737 (laptop) with Ubuntu Maverick, linux 2.6.35-25.44, it takes about 25 seconds from the wireless being turned on to being able to find wireless networks. This is really annoying when coming out of suspend, as I have to wait what seems an eternity before I can get online.

I can repeat this bug in two ways: either suspend/resume, which, as best I understand, shuts off the wireless on suspend, then brings it back on resume, or just use the wireless switch on the side of the computer to turn off wireless, then turn it back on. (I think it also does this on bootup, but because I have to spend some time in GDM and then waiting for login to complete, I know of no way to check the time.) Either way, the wireless takes only a second or two to come up, as evidenced by NetworkManager's 'Enable wireless' checkbox become active, but I have to wait 25-26 seconds before NetworkManager can see /any/ wireless networks (there are two in range of the computer).

I also tested this with the latest daily mainline kernel 2.6.38-999_2.6.38-999.201101261132, and the problem also exists in this version of the kernel.

=====

ProblemType: Bug
DistroRelease: Ubuntu 10.10
Package: linux-image-2.6.35-25-generic-pae 2.6.35-25.44
Regression: No
Reproducible: Yes
ProcVersionSignature: Ubuntu 2.6.35-25.44-generic-pae 2.6.35.10
Uname: Linux 2.6.35-25-generic-pae i686
NonfreeKernelModules: wl
AlsaVersion: Advanced Linux Sound Architecture Driver Version 1.0.23.
Architecture: i386
ArecordDevices:
 **** List of CAPTURE Hardware Devices ****
 card 0: Intel [HDA Intel], device 0: STAC92xx Analog [STAC92xx Analog]
   Subdevices: 1/1
   Subdevice #0: subdevice #0
AudioDevicesInUse:
 USER PID ACCESS COMMAND
 /dev/snd/controlC0: shopmaster 1563 F.... pulseaudio
CRDA: Error: [Errno 2] No such file or directory
Card0.Amixer.info:
 Card hw:0 'Intel'/'HDA Intel at 0xfc700000 irq 46'
   Mixer name : 'Intel Cantiga HDMI'
   Components : 'HDA:111d7675,102802a0,00100103 HDA:80862802,80860101,00100000'
   Controls : 20
   Simple ctrls : 11
Date: Thu Jan 27 11:16:03 2011
HibernationDevice: RESUME=UUID=1545e460-ee2e-4d3b-ae50-6a8eeeabe3a8
InstallationMedia: Ubuntu 10.10 "Maverick Meerkat" - Release i386 (20101007)
MachineType: Dell Inc. Studio 1737
ProcCmdLine: BOOT_IMAGE=/boot/vmlinuz-2.6.35-25-generic-pae root=UUID=076f8d28-c4ba-458d-be88-d1311ab34135 ro quiet splash
ProcEnviron:
 PATH=(custom, user)
 LANG=en_US.utf8
 SHELL=/bin/bash
RelatedPackageVersions: linux-firmware 1.38.3
RfKill:
 0: dell-wifi: Wireless LAN
  Soft blocked: no
  Hard blocked: no
SourcePackage: linux
dmi.bios.date: 11/25/2009
dmi.bios.vendor: Dell Inc.
dmi.bios.version: A08
dmi.board.name: 0P792H
dmi.board.vendor: Dell Inc.
dmi.board.version: A08
dmi.chassis.type: 8
dmi.chassis.vendor: Dell Inc.
dmi.chassis.version: A08
dmi.modalias: dmi:bvnDellInc.:bvrA08:bd11/25/2009:svnDellInc.:pnStudio1737:pvrA08:rvnDellInc.:rn0P792H:rvrA08:cvnDellInc.:ct8:cvrA08:
dmi.product.name: Studio 1737
dmi.product.version: A08
dmi.sys.vendor: Dell Inc.

[Jeremy Foshee (jeremyfoshee)]

Hi zpletan,

If you could also please test the latest upstream kernel available that would be great. It will allow additional upstream developers to examine the issue. Refer to https://wiki.ubuntu.com/KernelMainlineBuilds . Once you've tested the upstream kernel, please remove the 'needs-upstream-testing' tag. This can be done by clicking on the yellow pencil icon next to the tag located at the bottom of the bug description and deleting the 'needs-upstream-testing' text. Please let us know your results.

Thanks in advance.

    [This is an automated message. Apologies if it has reached you inappropriately; please just reply to this message indicating so.]

[eclipsenet (eclipse-net2k)]

I am having this same issue whenever I close my Dell Inspiron E1505 with 10.10 when it suspends. Upon waking up it takes a long time to find a network list. I do not see it taking this long when I do a cold start but I will double check.

[zpletan (zpletan)]

As noted above, I tested this with version 2.6.28-999.20110126132 before filing. In addition, I tested again today with version 2.6.38-999.201102040905. The bug persists in that version.

[Mathieu Trudel-Lapierre (cyphermox)]

I doubt there's very much to do about this at the kernel level, given that it's the wl driver (a closed source driver).

Note that there is a patch up for review upstream for wpasupplicant, which we're considering, in bug 638303. While this is a rather important issue for ConnMan, I suspect it may be visible here to a lesser degree for other users of wpasupplicant. I'll comment back here when the patch is in wpasupplicant in Natty to ask for testing.

Please note however that 25 seconds, while high-ish, doesn't seems like an unreasonable amount of time to wait for all the moving parts to get ready (poking the driver takes time, so does scanning...), especially after resume. Even patching wpasupplicant might not change much, especially considering the wl driver (which we can't control).

[zpletan (zpletan)]

Could this be related to bug #620318?

[zpletan (zpletan)]

@Mathieu - thanks for the explanation and link to bug.

[Mathieu Trudel-Lapierre (cyphermox)]

I´m unassigning this for myself since the patch for wpasupplicant to rescan isn't quite ready yet, so let's revisit when it is (I'll keep watching the mailing list)

[Kalle Valo (kvalo)]

I have been trying to get a workaround to wpasupplicant, but unfortunately none of my patches have been acceptable and I have now given up after four rounds.

Maybe it would be possible to fix this in kernel? For example implementing a wireless extension wrapper for the buggy wl driver or something similar? IIRC openwrt had done something similar.