[PATCH] talkative reset
Pedro Estrela
pedro.estrela
Thu May 15 15:28:53 PDT 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