While looking into http://bugzilla.kernel.org/show_bug.cgi?id=12080 I noticed that we call reset() from a lot of places without locking:
- at probe time - whenever we change channels - whenever we miss 3 beacons - whenever a 'bad' interrupt occurs - whenever the calibration timer runs and we are poorly calibrated - from user space when a user configures an interface, or requests a scan Some paths use the tasklet, some call reset directly. PCI-E cards tend to lock up eventually, it seems ath5k_config() is often implicated. Could we do some of this (e.g. set up channels) without doing a full reset? Anyone currently working on reworking the reset a bit? This is a lot better with Felix's patch to not bail out of reset the first time noise calibration fails, but by and large reset's error paths are still twisty. With his patch, I can still make the card lockup by reducing ath5k_calinterval. I can play with this some, but I didn't know if anyone already had pending changes in the area. -- Bob Copeland %% www.bobcopeland.com _______________________________________________ ath5k-devel mailing list ath5k-devel@lists.ath5k.org https://lists.ath5k.org/mailman/listinfo/ath5k-devel
