On Wednesday 31 March 2010 12:58:47 Bob Copeland wrote: > On Wed, Mar 31, 2010 at 11:02:32AM +0900, Bruno Randolf wrote: > > we have to stop TX while NF calibration. also we need to lock it against > > other uses of reset / calibration. i think this is what gives us the > > problems with 'warm reset'. afaik other calibration can run in parallel. > > nick gave me some clues and i'm looking into it today... > > Agreed, I've seen BadThings happen with two NF running in parallel, > sometimes NF would never complete, other times I'd get bus errors plus > an NMI. I tried a small patch to specifically test/set a bit around NF > and those problems went away.
good to hear! i've also seen bus errors. i have not verified if the come from NF or not, but they have something to do with ath5k_reset and register_timeout... as you say probably NF being interrupted by int RXORN which starts a reset... > (For my test I was running calibration tasklet once a second and doing > lots of scans at the same time, usually locks up within 15 minutes.) > > Once upon a time I had a patch that did a spinlock around all of reset, > but it's bad to lock other CPUs for such a long period of time. What I > think we should do instead is have a busy flag that gets set under a > spinlock which we can then test normally outside of locked regions. not sure right now... > > > There's still ath5k_tasklet_reset, which wakes the queues (should it?). > > > > yep i think so. after a reset we should be ready to transmit again. > > I meant, if nothing stops queues before reset, should > ath5k_tasklet_reset start them in any case? i think it's ok. ath5k_reset is also called from ath5k_init, or ath5k_config, so the queues might have been stopped before. also everything is supposed to be fresh & clean after a reset, so starting the queues won't hurt. bruno _______________________________________________ ath5k-devel mailing list ath5k-devel@lists.ath5k.org https://lists.ath5k.org/mailman/listinfo/ath5k-devel
