On Fri, 2008-11-28 at 17:31 +0800, Helmut Schaa wrote: > Hmm, I was able to reproduce the firmware looping endlessly reasonably > reliable (turned off the beacon-miss-cancels-scan-behaviour and increased the > scan watchdog timeout) and the ABORT_SCAN command was processed in that case > and canceled the scan which resulted in a > HOST_NOTIFICATION_STATUS_SCAN_COMPLETED notification with status 2 (not sure > if it really was 2). '2' is SCAN_COMPLETED_STATUS_ABORTED. > So, at least the failure I noticed here could be corrected > by aborting the scan instead of restarting the adapter. > > What about the following: > After the first scan timeout we try to cancel the scan and if that does not > succeed in a few seconds we can still restart the fw. A watchdog is used to prevent unpredictable firmware hangs. In your report, the firmware hang has a predictable pattern. We should focus on resolving the real problem than workaround this issue. > I see the timeout because the firmware will never stop scanning until either > the beacon miss notification cancels the scan or the IPW_SCAN_CHECK_WATCHDOG > timeout restarts the adapter. I already tried a scan timeout of 25 seconds but > the firmware insists on scanning the first passive channel (in my setup 52) > over and over again. >From what you are saying, it looks like we have a real bug here. Why the firmware keep sticking in the passive channel if dwell > beacon_interval? I didn't see this in our testing environment. Normally my scan for 24 channels takes about 1 second. [...] > Yes, it is. If the passive channel dwell time is larger than the beacon > interval the firmware will be stuck at the first passive channel. Thus the > scan will never succeed. > > > We assume most APs use 100ms beacon interval. But in case you are > > associated with an AP which uses 20ms beacon interval, do you want to > > set the passive_dwell time to 10ms here? > > Yes, either that or just leaving all channels out that need to be scanned > for a longer period than the beacon interval. In case of a 20ms beacon interval > I'm pretty sure the active scan on all other channels will results in a > endless scan loop in the fw too. > > > 120ms makes sure we can at > > least receive a beacon for normal APs. > > Yes, but I'd favour a successful scan that does not find every AP on passive > channels over a canceled scan. See above. I ack your idea 2. But 1 and 3 are workaround for a firmware stuck problem on scan. Let's try to solve the real problem before considering these workarounds. Looks like you are the only one reported this problem. Would you like to test some debug patches? > > BTW, another thing might help to resolve the scan-while-associate > > problem. Currently we scan 5GHz band channels first, then 2.4GHz band > > (see ipw_add_scan_channels). Normally most channels in 5GHz band are > > passive ones. Thus they use longer dwell time. If we change to scan > > 2.4GHz band channels first, we can get more scan result before a scan > > abort. Can you please try it? > > That's true but in case the scan is canceled the results are not forwarded > to user space as they may be incomplete. We only send an empty scan event when the scan is completed successfully (vs. aborted). But user is still able to read the partial scan result even if the scan is aborted. The ieee->network_list is updated anyway. Thanks, -yi -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
