From: Bill Moss Date: Tue, 6 May 2008 03:05:15 +0000 (+0800) Subject: iwl3945: do not delay hardware scan if it is a direct scan X-Git-Tag: v2.6.27-rc1~969^2~441^2~12 X-Git-Url: http://git.openpandora.org/cgi-bin/gitweb.cgi?a=commitdiff_plain;h=15dbf1b7b7b6ba6e5159dde60e111f617b2c54ea;p=pandora-kernel.git iwl3945: do not delay hardware scan if it is a direct scan iwl3945 <---> mac80211 <----> wpa_supplicant <---> NetworkManager When a hardware scan is completed and another scan is requested in less than two seconds, iwlwifi will not do the second scan and will pass the error code -EAGAIN back to mac80211 where it quickly dies. The error code is not passed along to the calling program wpa_supplicant. After a timeout, wpa_supplicant will just give up but it will not know why the scan failed. This is a weakness in the design. I ran into this issue when I was trying to figure out why it takes more an a minute for NetworkManager to connect after Networking has been disabled and then re-enabled. I found a good deal of unnecessary work being done because mac80211 requests authentication when the interface is not configured, the ANY mode. I created an experimental passive (NOTANY) mode for mac80211 to eliminate this case. Then NetworkManager became so fast that I ran into the iwlwifi 2 second delay next scan issue which we are discussing. The patch resolves the problem by bypassing the delay if the scan request is a direct scan. It should do less harm to the hardware. Signed-off-by: Bill Moss Signed-off-by: Zhu Yi Signed-off-by: John W. Linville --- Reading git-diff-tree failed