[PATCH] talkative reset

[Denis Vlasenko]

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;
 }