ipw2200: increase scan timeout
PATCH 1/1 ipw2200: increase scan timeout
The current scan timeout is set to 5 seconds. If the timeout is hit because the firmware did not respond yet, the adapter gets restarted, which results in a disassociation.
However, in an environment with lots of access points the scan sometimes takes longer than 5 seconds. This patch simply increases the timeout to 10 seconds.
---
I was able to reproduce the issue fairly reliable with a 2915 adapter by periodically triggering scans while associated.
I have no idea in which situations the scan takes longer than 5 seconds to complete but maybe it might even take longer than 10 seconds. Has anybody from Intel insight into the firmware scan code?
drivers/net/wireless/ipw2x00/ipw2200.c +1 -1
@@ -2304,7 +2304,7 @@ static void ipw_bg_adapter_restart(struct work_struct *work)mutex_unlock (&priv->mutex); } -#define IPW_SCAN_CHECK_WATCHDOG (5 * HZ) +#define IPW_SCAN_CHECK_WATCHDOG (10 * HZ)static void ipw_scan_check (void *data) {
Quoted 22 lines · Helmut Schaa
The current scan timeout is set to 5 seconds. If the timeout is hit because the firmware did not respond yet, the adapter gets restarted, which results in a disassociation.
However, in an environment with lots of access points the scan sometimes takes longer than 5 seconds. This patch simply increases the timeout to 10 seconds.
Signed-off-by [email protected]---
I was able to reproduce the issue fairly reliable with a 2915 adapter by periodically triggering scans while associated.
I have no idea in which situations the scan takes longer than 5 seconds to complete but maybe it might even take longer than 10 seconds. Has anybody from Intel insight into the firmware scan code?
drivers/net/wireless/ipw2x00/ipw2200.c +0
-0
drivers/net/wireless/ipw2x00/ipw2200.c static void ipw_bg_adapter_restart(struct work_struct *work) · line 2310
Quoted 8 lines
drivers/net/wireless/ipw2x00/ipw2200.c +1
-1@@ -2304,7 +2304,7 @@ static void ipw_bg_adapter_restart(struct work_struct *work)mutex_unlock (&priv->mutex); } -#define IPW_SCAN_CHECK_WATCHDOG (5 * HZ) +#define IPW_SCAN_CHECK_WATCHDOG (10 * HZ)static void ipw_scan_check (void *data) {
I do not have insight into the scan code ... but I can try to find out if there is something specific you need to know.
This change seems harmless and if it helps you it may help somebody else too.
Thank you
Reinette
Quoted 44 lines
-----Original Message-----
From: reinette chatre [mailto:[email protected]]
Sent: Tuesday, November 25, 2008 1:33 PM
To: Helmut Schaa
Cc: [email protected]; Zhu, Yi; [email protected]; [email protected]
Subject: Re: [Ipw2100-devel] [PATCH] ipw2200: increase scan timeoutQuoted 2 lines · Helmut Schaa
The current scan timeout is set to 5 seconds. If the timeout is hit because the firmware did not respond yet, the adapter gets
restarted,
Quoted 4 lines
which results in a disassociation.
However, in an environment with lots of access points the scan sometimes takes longer than 5 seconds. This patch simply
increases the timeout to 10 seconds.
Quoted 5 lines
Signed-off-by [email protected]---
I was able to reproduce the issue fairly reliable with a
2915 adapter
drivers/net/wireless/ipw2x00/ipw2200.c static void
Quoted 12 lines
by periodically triggering scans while associated.
I have no idea in which situations the scan takes longer than 5 seconds to complete but maybe it might even take longer than 10 seconds. Has anybody from Intel insight into the firmware scan code?
drivers/net/wireless/ipw2x00/ipw2200.c +0
-0@@ -2304,7 +2304,7 @@ static void
ipw_bg_adapter_restart(struct work_struct *work)Quoted 6 lines
drivers/net/wireless/ipw2x00/ipw2200.c +1
-1mutex_unlock (&priv->mutex); } -#define IPW_SCAN_CHECK_WATCHDOG (5 * HZ) +#define IPW_SCAN_CHECK_WATCHDOG (10 * HZ)
Quoted 7 lines
drivers/net/wireless/ipw2x00/ipw2200.c static void · line 2309
Quoted 1 line
drivers/net/wireless/ipw2x00/ipw2200.c +0
-0static void ipw_scan_check (void *data) {I do not have insight into the scan code ... but I can try to find out if there is something specific you need to know.
This change seems harmless and if it helps you it may help somebody else too.
It seems harmless to me also, and if anyone is getting burned by it timing out before a scan is complete, then it seems like a good idea. It's just a "safety net", and should not affect the *actual* time spent scanning.
-- Ben --
Quoted 20 lines
Acked-by Reinette Chatre <[email protected]>Thank you
Reinette
--------------------------------------------------------------
-----------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/
_______________________________________________
ipw2100-devel mailing list [email protected]
https://lists.sourceforge.net/lists/listinfo/ipw2100-devel
Am Dienstag, 25. November 2008 schrieb reinette chatre:
Quoted 7 lines · Helmut Schaa
Quoted 3 lines
I have no idea in which situations the scan takes longer than 5 seconds to complete but maybe it might even take longer than 10 seconds. Has anybody from Intel insight into the firmware scan code?
I do not have insight into the scan code ... but I can try to find out if there is something specific you need to know.
A worst case runtime estimation of the scan code would be interesting ;)
Helmut
Am Dienstag, 25. November 2008 schrieb reinette chatre:
Quoted 35 lines · Helmut Schaa
Quoted 22 lines
The current scan timeout is set to 5 seconds. If the timeout is hit because the firmware did not respond yet, the adapter gets restarted, which results in a disassociation.
However, in an environment with lots of access points the scan sometimes takes longer than 5 seconds. This patch simply increases the timeout to 10 seconds.
Signed-off-by [email protected]---
I was able to reproduce the issue fairly reliable with a 2915 adapter by periodically triggering scans while associated.
I have no idea in which situations the scan takes longer than 5 seconds to complete but maybe it might even take longer than 10 seconds. Has anybody from Intel insight into the firmware scan code?
drivers/net/wireless/ipw2x00/ipw2200.c +0
-0drivers/net/wireless/ipw2x00/ipw2200.c static void ipw_bg_adapter_restart(struct work_struct *work) · line 2310
Quoted 8 lines
drivers/net/wireless/ipw2x00/ipw2200.c +1
-1@@ -2304,7 +2304,7 @@ static void ipw_bg_adapter_restart(struct work_struct *work)mutex_unlock (&priv->mutex); } -#define IPW_SCAN_CHECK_WATCHDOG (5 * HZ) +#define IPW_SCAN_CHECK_WATCHDOG (10 * HZ)static void ipw_scan_check (void *data) {I do not have insight into the scan code ... but I can try to find out if there is something specific you need to know.
Quoted 4 lines
This change seems harmless and if it helps you it may help somebody else too.
Acked-by Reinette Chatre <[email protected]>
John, please do _not_ merge this patch. It only hides the real problem. I'll send another patch (including explanations) in a few minutes.
Helmut
Quoted 8 lines · Helmut Schaa
The current scan timeout is set to 5 seconds. If the timeout is hit because the firmware did not respond yet, the adapter gets restarted, which results in a disassociation.
However, in an environment with lots of access points the scan sometimes takes longer than 5 seconds. This patch simply increases the timeout to 10 seconds.
Signed-off-by [email protected]
Quoted 8 lines
---
I was able to reproduce the issue fairly reliable with a 2915 adapter by periodically triggering scans while associated.
I have no idea in which situations the scan takes longer than 5 seconds to complete but maybe it might even take longer than 10 seconds. Has anybody from Intel insight into the firmware scan code?
Probably because with 802.11a, you have so many more channels to scan. Depending on whether they are active or passive, you may be able to do probe-scans on them, or you may have to sit on each channel for 120ms to listen for beacons. It's not unusual for cards that support A channels to take two or three times as long for a scan as cards that support only b/g, depending on the channel list.
dan
Quoted 17 lines
drivers/net/wireless/ipw2x00/ipw2200.c +1
-2@@ -2304,7 +2304,7 @@ static void ipw_bg_adapter_restart(struct work_struct *work)mutex_unlock (&priv->mutex); } -#define IPW_SCAN_CHECK_WATCHDOG (5 * HZ) +#define IPW_SCAN_CHECK_WATCHDOG (10 * HZ)static void ipw_scan_check (void *data) { --To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Am Dienstag, 25. November 2008 schrieb Dan Williams:
Quoted 11 lines · Helmut Schaa
Quoted 3 lines
I have no idea in which situations the scan takes longer than 5 seconds to complete but maybe it might even take longer than 10 seconds. Has anybody from Intel insight into the firmware scan code?
Probably because with 802.11a, you have so many more channels to scan. Depending on whether they are active or passive, you may be able to do probe-scans on them, or you may have to sit on each channel for 120ms to listen for beacons. It's not unusual for cards that support A channels to take two or three times as long for a scan as cards that support only b/g, depending on the channel list.
Sure, but the strange thing is that not every scan took longer than 5 seconds. I did not run much measurements but some scans even finished in less than 3 seconds.
Helmut
Quoted 3 lines · On Tue, 25 Nov 2008 18:09:54 +0100 Helmut Schaa <[email protected]>…
The current scan timeout is set to 5 seconds. If the timeout is hit because the firmware did not respond yet, the adapter gets restarted, which results in a disassociation.
Could this be a workaround for my bug as well (disconnects caused by scan while associated)? I get the following log entries:
I isr_status_change Scan detected while associated, with no scan request. Restarting firmware.
I schedule_reset wifi0: Scheduling firmware restart (0s). I isr_status_change Status change: IPW_STATE_SCANNING I isr_indicate_scanning Scanning...
U ipw2100_reset_adapter : wifi0: Restarting adapter.
U ipw2100_power_cycle_adapter Power cycling the hardware.
Quoted 3 lines
However, in an environment with lots of access points the scan sometimes takes longer than 5 seconds. This patch simply increases the timeout to 10 seconds.
I only have 1 AP, though.
Cheer,
harry
Am Dienstag, 25. November 2008 schrieb Harald Braumann:
Quoted 9 lines
Quoted 3 lines · On Tue, 25 Nov 2008 18:09:54 +0100 Helmut Schaa <[email protected]>…
The current scan timeout is set to 5 seconds. If the timeout is hit because the firmware did not respond yet, the adapter gets restarted, which results in a disassociation.
Could this be a workaround for my bug as well (disconnects caused by scan while associated)?
No, seems to be something different :(
Helmut
Quoted 3 lines
The current scan timeout is set to 5 seconds. If the timeout is hit because the firmware did not respond yet, the adapter gets restarted, which results in a disassociation.
I have nothing against raising the timeout, but two general questions.
First thing: why does the adapter get's resetted? Even if a whole scan takes 11 seconds, the scan of one channel takes less. So if results trickle in during these 11 seconds, nothing should get resettet.
Second thing: why should the association get's cleared if the adapter get's reset? Isn't one a (assoc) at protocol level and the other (adapter) a hardware thing?
Quoted 3 lines · Holger Schurig
Second thing: why should the association get's cleared if the adapter get's reset? Isn't one a (assoc) at protocol level and the other (adapter) a hardware thing?
Good point. I once had a bad bug in stlc45xx tx queue handling and firmware was crashing all the time. While the firmware was reset association state wasn't changed and I could, for example, run iperf tests while firmware was resetting without userspace noticing anything (expect a slight decreare of throughput of course). This might depend on firmware implementation, but at least with softmac devices it shouldn't be a problem.
Signature · 1 line
Kalle Valo
Quoted 6 lines · Kalle Valo
While the firmware was reset
association state wasn't changed and I could, for example, run iperf tests while firmware was resetting without userspace noticing anything (expect a slight decreare of throughput of course). This might depend on firmware implementation, but at least with softmac devices it shouldn't be a problem.
This is fairly easy to be handled by hardmac as well. We didn't do it
because: 1) this is an unexpected behaviour so we simply put everything to the initial state when this happens and didn't put a lot of effort on the recovery 2) 'associate=1' used to be the default value, so the driver associated automatically after the firmware restart cycle.
Patches are welcome.
Thanks,
-yi
Quoted 8 lines · Zhu Yi
Quoted 6 lines · Kalle Valo
While the firmware was reset
association state wasn't changed and I could, for example, run iperf tests while firmware was resetting without userspace noticing anything (expect a slight decreare of throughput of course). This might depend on firmware implementation, but at least with softmac devices it shouldn't be a problem.
Quoted 7 lines
This is fairly easy to be handled by hardmac as well. We didn't do it
because: 1) this is an unexpected behaviour so we simply put everything to the initial state when this happens and didn't put a lot of effort on the recovery 2) 'associate=1' used to be the default value, so the driver associated automatically after the firmware restart cycle.Patches are welcome.
Yeah, even with associate=0 we'll want to preserve the association across restarts of the firmware, so we need to make the driver bring the association back up if the firmware crashed. But only on crash.
Dan
Am Mittwoch, 26. November 2008 schrieb Holger Schurig:
Quoted 8 lines
Quoted 3 lines
The current scan timeout is set to 5 seconds. If the timeout is hit because the firmware did not respond yet, the adapter gets restarted, which results in a disassociation.
I have nothing against raising the timeout, but two general questions.
First thing: why does the adapter get's resetted?
I guess the intention was that if the firmware does not get back within the timeout it might have been crashed (or something similar) and thus the driver simply restarts the card.
Quoted 4 lines
Even if a
whole scan takes 11 seconds, the scan of one channel takes less. So if results trickle in during these 11 seconds, nothing should get resettet.
Right. Could do that too.
Quoted 3 lines
Second thing: why should the association get's cleared if the adapter get's reset? Isn't one a (assoc) at protocol level and the other (adapter) a hardware thing?
No idea!
Helmut