hw reset during high traffic load (was: talkative reset)

[Denis Vlasenko]

On 19 May 2003 05:50, Jouni Malinen wrote:
> On Sat, May 17, 2003 at 11:51:22PM -0700, Jouni Malinen wrote:
> > On Thu, May 15, 2003 at 11:53:51PM +0200, Lukic wrote:
> > > So, my question is: What is doing HFA384X_OUTW(0x0080,
> > > HFA384X_PCICOR_OFF);??
> > >
> > > Did we do all we have to do before sending this to card? Or is it
> > > a hardware error?
> >
> > The most important part is to disable interrupts or mask them out
> > before resetting the card. It was done, however, not always in
> > proper order.
>
> Actually, I did not test this at all with shared IRQs. I continued
> today with similar tests, but added flood of shared IRQs from other
> devices during the sreset. I shared the interrupt with Prism2.5 PCI
> card and wired Ethernet card and then flooded both interfaces during
> sreset.

Wow. Thank you Jouni for working on this, I have shared IRQ setup
but unfortunately cannot arrange for wlan floodpinging tests :(

> I don't know why, but the host system does indeed crash quite often
> after setting sreset bit in COR. Since I did not find any better way
> of fixing this, I changed Host AP driver to disable all shared
> interrupts (on the interrupt it is using) during COR sreset. This
> seemed to remove most of the crashes.

Blocking IRQs from other device can be quite painful...

Hmmm.... if(we_are_resetting) return IRQ_NONE; at the top of
IRQ handler wasn't enough?

(BTW I'm curious why IRQ handler code seem to be written to
try to handle some events even if card is being reset? That's
strange... is prism hw convoluted enough to really need it?)

> I'm still able to crash the
> system every now and then (over 100 'iwpriv wlan0 reset 1' during
> ping flood for both eth0 and wlan0), but it certainly takes more
> trying than before..

        hfa384x_disable_interrupts(dev);
        <-------- maybe add a slight delay here?
        if (local->func->cor_sreset) {
                local->func->cor_sreset(local);
        }
--
vda