[PATCH] talkative reset

[Lukic]

well, i did some more printk :-) in hostap_pci.c, so sreset seems like this
(don't blame me, i don't know how to use diff or so :-)):

----------------cut starts here-----------------
static void prism2_pci_cor_sreset(local_info_t *local)
{
        struct net_device *dev = local->dev;

        /* linux-wlan-ng uses extremely long hold and settle times for
         * COR sreset. A comment in the driver code mentions that the long
         * delays appear to be necessary. However, at least IBM 22P6901
         * seems to work fine with shorter delays.
         *
         * Longer delays can be configured by uncommenting following line:
*/
#define PRISM2_PCI_USE_LONG_DELAYS

#ifdef PRISM2_PCI_USE_LONG_DELAYS
        int timeout;
        printk(KERN_WARNING "here we are.. going to send 0x0080 \n");
               //  this is the last message i get..

        HFA384X_OUTW(0x0080, HFA384X_PCICOR_OFF);
                   // probably point of hang
        timeout = jiffies + HZ / 4;
        while (time_before(jiffies, timeout))
                // we can't run in loop, cause, with short
                udelay(5);
            // with short delays system hangs too.. :-((

        HFA384X_OUTW(0x0, HFA384X_PCICOR_OFF);
        timeout = jiffies + HZ / 2;
        while (time_before(jiffies, timeout))
                udelay(5);
        printk(KERN_WARNING "sent 0x0 waiting..\n");

        /* Wait for f/w to complete initialization (CMD:BUSY == 0) */
        timeout = jiffies + 2 * HZ;
        while ((HFA384X_INW(HFA384X_CMD_OFF) & HFA384X_CMD_BUSY) &&
               time_before(jiffies, timeout))
                udelay(10);
        printk(KERN_WARNING "waited... end of reset soon..\n");

#else /* PRISM2_PCI_USE_LONG_DELAYS */

        printk(KERN_WARNING "here we are.. going to send 0x0080 \n");
        HFA384X_OUTW(0x0080, HFA384X_PCICOR_OFF);
        printk(KERN_WARNING "sent 0x0080 sending 0x0\n");
        mdelay(1);
        HFA384X_OUTW(0x0, HFA384X_PCICOR_OFF);
        mdelay(1);
        printk(KERN_WARNING "sent 0x0 ...\n");

#endif /* PRISM2_PCI_USE_LONG_DELAYS */


        if (HFA384X_INW(HFA384X_CMD_OFF) & HFA384X_CMD_BUSY) {
                printk(KERN_DEBUG "%s: COR sreset timeout\n", dev->name);
        }
        printk(KERN_WARNING "end of reset...\n");
}
-------------------end of cut--------------


Lukic

N49? 02,40' E19? 43,07'
----- Original Message -----
From: Lukas Zvonar <lukic at mag-net.sk>
To: <hostap at shmoo.com>
Cc: <vda at port.imtp.ilyichevsk.odessa.ua>
Sent: Thursday, May 15, 2003 11:16 PM
Subject: Re: [PATCH] talkative reset


> It hangs in cor_sreset (after cor_sreset is printed out)...
>
> Lukic
>
> N49? 02,40' E19? 43,07'
> ----- Original Message -----
> From: Denis Vlasenko <vda at port.imtp.ilyichevsk.odessa.ua>
> To: <hostap at shmoo.com>
> Cc: Dave Hinkle <hinkle at DerbyWorks.com>; Lukas Zvonar <lukic at mag-net.sk>
> Sent: Thursday, May 15, 2003 8:23 AM
> Subject: [PATCH] talkative reset
>
>
> > On 14 May 2003 21:59, Dave Hinkle wrote:
> > > Are the long delays really unnecessary for all cards?  On what
> > > assumptions has this conclusion been made? Has anyone experimented
> > > with this? Any problems solved with PRISM2_PCI_USE_LONG_DELAYS
> > > uncommented?
> >
> > Long delays may help if card fails to reset with short delays.
> > But I doubt this can eliminate solid hangs. We have to determine
> > exactly where do we hang first. I planned to try it yesterday
> > at home but -(ETOOSLEEPY | EPILLOWENCOUNTERED)  ;)
> >
> > Anyway, for any brave soul out there: this patch should
> > make reset code more talkative. I am not sure whether yield()
> > is a right way to release CPU timeslice, I hope it will
> > allow you to see those messages in the logs / on the screen
> > before machine freeze. Feel free to raise log level or add
> > several yield()s in a row to increase delays.
> >
> > On 14 May 2003 07:12, Lukic wrote:
> > > I have done tests, that points, that it's irelevant what reset occurs
> > > (manual or at signal lost), there is still high chance of system
> > > lockup when some data is received... :-((
> >
> > The best way to use: run patched driver, start heavy traffic,
> > redirect logging to a console before your eyes and provoke
> > card resets (play with antenna or maybe 'iwpriv wlan0 reset 1'
> > in a loop ?)
> > --
> > vda
> >
> > --- hostap_hw.c.orig Wed Apr 30 06:40:27 2003
> > +++ hostap_hw.c Thu May 15 09:08:40 2003
> > @@ -1270,11 +1270,17 @@
> >
> >   printk(KERN_WARNING "%s: %s: resetting card\n", dev_info, dev->name);
> >   local->hw_resetting = 1;
> > +printk(KERN_DEBUG "disable_interrupts...\n"); yield();
> >   hfa384x_disable_interrupts(dev);
> > - if (local->func->cor_sreset)
> > + if (local->func->cor_sreset) {
> > +printk(KERN_DEBUG "cor_sreset...\n"); yield();
> >   local->func->cor_sreset(local);
> > + }
> > +printk(KERN_DEBUG "hw_shutdown...\n"); yield();
> >   prism2_hw_shutdown(dev, 1);
> > +printk(KERN_DEBUG "hw_config...\n"); yield();
> >   prism2_hw_config(dev, 0);
> > +printk(KERN_DEBUG "done!\n"); yield();
> >   local->hw_resetting = 0;
> >  }
> >
>