On Thu, Apr 22, 2004 at 04:21:54PM -0400, Pavel Roskin wrote:
> Hello!
>
> I have applied a patch that fixes BAP timeouts with Intersil firmware.
> The patch is not a complete solution, but it works in most cases and
> should increase reliability of the driver.
>
> Cards with Intersil firmware experience conditions when the BAP offset
> requires a long time to be set. Most often it happens after port 0 is
> enabled (either the interface goes up or the new settings are committed).
> It can also happen (very rarely) during data transmission. The delay is
> usually between 4 and 5 ms, occasionally 6 ms.
Aha, good insights.
> When the port 0 is enabled, either the first of the second BAP offset
> setting can experience the delay.
Ok. That kind of makes sense w.r.t. my theory of what causes these
errors with WEP enabled. I'm guessing the firmware is insufficiently
multi-threaded in parts, so sometimes it can be off doing some
processing and won't respond to the BAP request. WEP encryption may
be one sort of problematic processing, but it seems plausible that
enabling the port kicks of some other thing that takes a bit of work.
> The approach taken by the patch is two-pronged. The BAP timeout is
> increased to 10 ms when running in softirq or user context. When port 0
> is enabled, the first two BAP seeks are made in process context with the
> lock held. This means that they shouldn't timeout and there will be no
> interrupts trying to access the BAP.
Hrm... having a 10ms timeout with a lock held and irqs disabled is
not really any better than doing it in interrupt context. It would be
simpler and not really less dangerous to just unconditionally increase
the timeout.
> The only case when the timeouts can still happen is when they are
> spontaneous and the BAP is accessed from the hard irq context. There is
> very little we can do about it, except rescheduling the operation to
> softirq or process context. This might happen eventually during Orinoco
> USB integration.
The fact that we have (even if occasionally) these sorts of delays
really suggest to me that the right way to approach this is to do as
much of the work as possible in process context, using a
single-threaded (but sleepable) flow of control, rather than a big
lock (so either a thread or a bunch of workqueues). The fact that
that will help for USB too is a bonus.
Not that my opinion should matter that much, since there's no way I'm
likely to have time to implement it.
> The attached patch includes the non-trivial changes only. I'll try do
> factorize this code. Maybe priv->firmware_type should become
> hw->firmware_type so that we can put this code to hermes_enable_port().
--
David Gibson | For every complex problem there is a
david AT gibson.dropbear.id.au | solution which is simple, neat and
| wrong.
http://www.ozlabs.org/people/dgibson
-------------------------------------------------------
This SF.net email is sponsored by: The Robotic Monkeys at ThinkGeek
For a limited time only, get FREE Ground shipping on all orders of $35
or more. Hurry up and shop folks, this offer expires April 30th!
http://www.thinkgeek.com/freeshipping/?cpg=12297
|
