Hi there, on my system, I observe some odd symptoms which I have troubled Thomas with before. After some more investigation, I have come to the conclusion that ath5k is at the bottom of this, but since I don't really understand the connection, I thought that Thomas may perhaps throw some light on the matter, after all, even though I still think that ath5k will have to be fixed. The Behaviour I'm seeing is this: sometimes, timers fire prematurely, i.e. a timer x started with mod_timer(&x, HZ/50); fires after less than 10 or even 1 msec rather than 20 msec. Trying to get to the bottom of this, it struck me that these glitches only occur when ath5k is loaded and an interface is brought up (ifconfig wlan0 up is quite sufficient). Some more digging revealed that the occurrences of such ``fast forward events'' coincided with the expiry of the recalibration timer started for the interface. The same behaviour can be observed on kernels 2.6.25.16, 2.6.26.5, 2.6.27-rc8-git8 and next-20080919. Looking through the code, I tried to find an obvious suspect, but nothing struck me as out of the ordinary, except for one thing: There doesn't seem to be anything in place that ensures serialisation of calls to the functions involved in calibration or, indeed, accesses to the card's registers. There definitely are parts of the calibration sequence that don't just get called from the calibration timer callback, so I think something has to be done about that. My first question is, can simultaneous unserialised accesses to registers possibly disturb softirqs in the way I see it happen, or do I have to look for something else? What about the locking issue? In fact, I wonder whether this really is the only place in the driver where we face the problem of potential concurrent access to the same registers including bit manipulations that require a read-write-in-a-row operation. Regards, Elias -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
