[ath5k-devel] [RFC/RFT 0/4] ath5k: locking updates

Previous message: [thread] [date] [author]
Next message: [thread] [date] [author]
From: Bob Copeland
Date: Sunday, December 28, 2008 - 10:32 am

Hi all,

Please comment on and test these changes, especially #2 and #3 which
put a spinlock around reset() to prevent HW lockups of pcie devices
when scans race with the calibration timer and other paths.  reset()
is a rather chunky function to lock in this way, but at the moment
there's no finer grained option without pushing the lock down into the
hardware layer.

Big fat disclaimer: when I set the code up to reset every second, 
I could reliably hard lock my laptop after a few hours.  However, reset() 
itself can take up to 1/3 of a second just looping (in gain and noise 
calibration) not even counting the register writes, so I think this was 
just a problem of having too small a period.  In normal operation we 
don't reset anywhere near that often and I've been running for a 
couple of days without issues.  But maybe I missed something obvious.

_______________________________________________
ath5k-devel mailing list
ath5k-devel@lists.ath5k.org
https://lists.ath5k.org/mailman/listinfo/ath5k-devel
Previous message: [thread] [date] [author]
Next message: [thread] [date] [author]

Messages in current thread:
[ath5k-devel] [RFC/RFT 0/4] ath5k: locking updates, Bob Copeland, (Sun Dec 28, 10:32 am)
Re: [ath5k-devel] [RFC/RFT 0/4] ath5k: locking updates, Soeren Sonnenburg, (Fri Jan 2, 11:40 am)
Re: [ath5k-devel] [RFC/RFT 0/4] ath5k: locking updates, Bob Copeland, (Tue Jan 6, 8:39 am)
Re: [ath5k-devel] [RFC/RFT 0/4] ath5k: locking updates, Soeren Sonnenburg, (Tue Jan 6, 8:48 am)