[PATCH] talkative reset

Pedro Estrela pedro.estrela at inesc.pt
Thu May 15 18:28:53 EDT 2003


Diff and patch quick howto:

Create the differences between ORIGINAL and MODIFIED files:
Diff -C3 --minimal ORIGINAL MODIFIED > bugfix.patch

To Apply the said differences: 
Patch --verbose [-p<num>] < bugfix.patch

For the common case where its just one file, and you apply the patch in
the current directory, there is no need to use option -p.

Pedro estrela


> -----Original Message-----
> From: hostap-admin at shmoo.com [mailto:hostap-admin at shmoo.com] On Behalf
Of
> Lukic
> Sent: quinta-feira, 15 de Maio de 2003 22:49
> To: hostap at shmoo.com
> Subject: Re: [PATCH] talkative reset
> 
> 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;
> > >  }
> > >
> >
> 
> 
> 
> _______________________________________________
> HostAP mailing list
> HostAP at shmoo.com
> http://lists.shmoo.com/mailman/listinfo/hostap




More information about the HostAP mailing list