2008/12/22 Bob Copeland <m...@bobcopeland.com>: > 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. >
I'm working on PHY stuff right now, I'll add the synth-only channel switching code after i'm done with txpower. Also i have a better idea about periodic phy calibration using software generated interrupts and packet count instead of a timer. Give me some time and i'll come up with patches soon (i'm almost done with EEPROM code, only 5210 stuff remains). Can someone work on these locking issues inside base.c to be safe on the driver side ? -- GPG ID: 0xD21DB2DB As you read this post global entropy rises. Have Fun ;-) Nick _______________________________________________ ath5k-devel mailing list ath5k-devel@lists.ath5k.org https://lists.ath5k.org/mailman/listinfo/ath5k-devel
