Download Firefox: WindowsMac OS X
logo       
Google Custom Search
    AddThis Social Bookmark Button

Re: Applied: Intersil BAP timeout fix: msg#00062

Subject: Re: Applied: Intersil BAP timeout fix
On Fri, 23 Apr 2004, David Gibson wrote:

> > 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.

Done.  Thank you for your comment!

> > 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 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.

Of course there is still a possibility that we are doing something wrong.
I still have a hope for an eureka.  Just yesterday I found how to fix even
more weird problems with Agere firmware in monitor more.  The firmware is
not fool proof.  If we are doing something wrong, it may not tell us that.
It may timeout, reset itself, ignore some settings and do other crazy
things.  Yet there may be a simple and relatively straightforward fix.

On the other hand, two other projects with much more specific focus on
Intersil firmware could not find such solution, as far as I can see int
the code.

HostAP uses 50ms timeout and accesses BAP only in softirq and process
context.  When a BAP operation is needed in hard irq, it's rescheduled as
a tasklet.  linux-wlan-ng does the same, except that the timeout is 10ms.
HostAP also used only one BAP for all operations.

Using kernel threads would push the idea of rescheduling to the extreme.
I don't like the idea of punishing non-USB and non-Intersil cards for the
problems they don't have.  On the other hand, having several branches is
time consuming.

I guess I'll start conversion when I'm ready.  As it stands now, there are
several more important things that are orthogonal to the issue.

> Not that my opinion should matter that much, since there's no way I'm
> likely to have time to implement it.

We'll see.  It may be easier that it sounds.

-- 
Regards,
Pavel Roskin


-------------------------------------------------------
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


<Prev in Thread] Current Thread [Next in Thread>