On Tuesday 30 March 2010 21:42:30 Bob Copeland wrote: > > > In both cases the first reset works at cross purposes to the > > > goal of pausing transmissions, so nix them. > > > > i don't understand this sentence... > > Instead of "reset" I meant "the first wake_queues". Maybe this is clearer: > > In both cases the first wake is superfluous, so remove it.
much clearer :) > (Just in case it's not obvious, the problems are as I see it: > > - why should we allow calls back to ->tx while attempting to free all > the descriptors? It just doesn't make sense to me. yep. > - can we do tx while in phy calibrate? My guess is no -- but phy > calibration is sometimes a long process so this may show up as periodic > pauses to users.) 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... > > couldn't we then also get rid of ath5k_reset_wake() completely? i think > > we need to re-think the whole queue handling and reset code, but this > > seems like a good start. > > 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. > Of the series, this patch might be the most speculative and worrisome: > it's possible that there's some path where we leave them disabled but > subsequent resets save us. That said, relying on that is a bit sloppy, > and I've been running the patch for a few days without noticable issues. usually, under normal/light traffic we dont get into the situations that tx queues have to be stopped/waked. it's important to test it in extreme situations. bruno _______________________________________________ ath5k-devel mailing list ath5k-devel@lists.ath5k.org https://lists.ath5k.org/mailman/listinfo/ath5k-devel
