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?
diff --git a/drivers/net/wireless/ipw2x00/ipw2200.c b/drivers/net/wireless/ipw2x00/ipw2200.c
index c73173a..a776da3 100644
--- a/drivers/net/wireless/ipw2x00/ipw2200.c
+++ b/drivers/net/wireless/ipw2x00/ipw2200.c
@@ -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)
{
Holger Schurig <[email protected]> writes:
> 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.
--
Kalle Valo
On Tue, 2008-11-25 at 18:09 +0100, Helmut Schaa wrote:
> 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?
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
> diff --git a/drivers/net/wireless/ipw2x00/ipw2200.c b/drivers/net/wireless/ipw2x00/ipw2200.c
> index c73173a..a776da3 100644
> --- a/drivers/net/wireless/ipw2x00/ipw2200.c
> +++ b/drivers/net/wireless/ipw2x00/ipw2200.c
> @@ -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 Mittwoch, 26. November 2008 schrieb Holger Schurig:
> > 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.
> 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.
> 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
On Wed, 2008-11-26 at 16:04 +0800, Zhu Yi wrote:
> On Wed, 2008-11-26 at 15:24 +0800, Kalle Valo wrote:
> > 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.
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 Dienstag, 25. November 2008 schrieb reinette chatre:
> On Tue, 2008-11-25 at 09:09 -0800, Helmut Schaa wrote:
> > 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?
> >
> > diff --git a/drivers/net/wireless/ipw2x00/ipw2200.c b/drivers/net/wireless/ipw2x00/ipw2200.c
> > index c73173a..a776da3 100644
> > --- a/drivers/net/wireless/ipw2x00/ipw2200.c
> > +++ b/drivers/net/wireless/ipw2x00/ipw2200.c
> > @@ -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.
>
> 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
Am Dienstag, 25. November 2008 schrieb Dan Williams:
> On Tue, 2008-11-25 at 18:09 +0100, Helmut Schaa wrote:
> > 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
> -----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 timeout
>
> On Tue, 2008-11-25 at 09:09 -0800, Helmut Schaa wrote:
> > 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?
> >
> > diff --git a/drivers/net/wireless/ipw2x00/ipw2200.c
> > b/drivers/net/wireless/ipw2x00/ipw2200.c
> > index c73173a..a776da3 100644
> > --- a/drivers/net/wireless/ipw2x00/ipw2200.c
> > +++ b/drivers/net/wireless/ipw2x00/ipw2200.c
> > @@ -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.
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 --
>
> 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
>
On Tue, 25 Nov 2008 18:09:54 +0100
Helmut Schaa <[email protected]> wrote:
> 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.
> 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
On Tue, 2008-11-25 at 09:09 -0800, Helmut Schaa wrote:
> 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?
>
> diff --git a/drivers/net/wireless/ipw2x00/ipw2200.c b/drivers/net/wireless/ipw2x00/ipw2200.c
> index c73173a..a776da3 100644
> --- a/drivers/net/wireless/ipw2x00/ipw2200.c
> +++ b/drivers/net/wireless/ipw2x00/ipw2200.c
> @@ -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.
Acked-by: Reinette Chatre <[email protected]>
Thank you
Reinette
> 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?
Am Dienstag, 25. November 2008 schrieb Harald Braumann:
> On Tue, 25 Nov 2008 18:09:54 +0100
> Helmut Schaa <[email protected]> wrote:
>
> > 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
On Wed, 2008-11-26 at 15:24 +0800, Kalle Valo wrote:
> 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
Am Dienstag, 25. November 2008 schrieb reinette chatre:
> On Tue, 2008-11-25 at 09:09 -0800, Helmut Schaa wrote:
> > 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