On Wed, Dec 04, 2002 at 08:31:15PM -0800, Michael Graff wrote:
> 
> It started perhaps a few months ago.  I think the problem is related
> to something that mycroft pointed out once on icb -- the wi driver
> processes N interrupts, then exits the processing loop.
> 
> The value is 10 in the stock source.  I upped that to 100, and things
> for a lot better.  I'm considering removing the loop limit entirely to
> see what happens, or setting it really, really high.
> 

More precisely, the wi driver processes the event status register up to
10 times for every interrupt.  The old code used to process the event
status register just once per interrupt. But there are two changes which
are more likely to be problems:

1 Let's call the interrupt enable register IER and the event status
register ESR. I was assured once by an engineer at Agere that it
was the level of bits in (IER & ESR) which triggered interrupts, not
the transition of the bits. So I removed the code which disabled and
re-enabled all interrupts at the top and bottom of wi_intr, respectively,
because it looked to me like a superfluous protection against NetBSD
re-entering wi_intr.  Because the change did not do me any harm, I
left it, but maybe it is the wrong thing.  Try zeroing WI_INT_EN at the
top of wi_intr, and writing WI_INTRS before getting out. Tell me what
you observe.

2 It is possible that Lucent does not support the Join Request RID
(0xfce2) which Prism does.  Or maybe it supports it differently than
Prism. One data point: Allen Briggs tells me he that his Lucent card
fails while writing that RID. Lucent must have a function equivalent
to the Join Request RID for 802.11 compliance, but maybe it is not at
0xfce2? I have no docs on the Lucent firmware.

Dave


-- 
David Young             OJC Technologies
dyoung@ojctech.com      Engineering from the Right Brain
                        Urbana, IL * (217) 278-3933