On Tuesday 28 September 2010 01:01:37 Ignacy Gawedzki wrote: > On Mon, Sep 27, 2010 at 07:36:21PM +0200, thus spake Christian Lamparter: > > Sure, but why when you have a monotonic 40 MHz timer? > > Glad to know there is such a thing, then. =) or was it 80Mhz? Nevermind, the docs are not very specific. > > > OK, I'll stick with the latest wireless-testing then. BTW, I noticed that the > > > FW API is 1.8.8.2, while driver API in wireless-testing is still 1.8.8.1. > > Actually, the firmware is already at 1.8.8.3-pre. But it shouldn't matter if > > what API "version" you are using, as long as the firmware descriptors and > > command interface structs are the same. > > Okay, I thought these API versions were there to be checked by the driver > somehow for conformance. They are... But only at the "highest" level ;) Anyway, there's a bitfield which describe what commands, operation modes and features are support by the firmware image. > > > Having some stability issues with this combination, I reverted the last few > > > commits in the FW's git back to API 1.8.8.1. Are these different numbers > > > nevertheless compatible with each other? > > "Stability issues"? Again, a "vague" and stretchy term. Do you have "Oops" - > > reports or something like that? > > Yeah, sorry for the vagueness, I promise I'll grab as much info as possible > upon next encounter of such a thing. As I remember it, it's mainly a matter > of the module getting suck somehow (and attempts to unload it getting stuck as > well) and the card not being detected upon subsequent insertions anymore. I posted a few patches two hours ago. you should check out "[PATCH] carl9170: fix hung workqueue", because it may be fixes the bug. > I just tried the whole setup with the latest wireless-testing sources and your > patch on the firmware. So far, so good, the problems I had previously are not > showing up. I'm now just adapting your proposition to support rollover and > conversion of the measurement to nanoseconds. Rollover checks? Can you please tell me where you exactly see a potential rollover problem in the proposal? > One last question about your patch. If a frame transmission fails altogether, > i.e. the maximum attempts have been made and no ACK has been received > whatsoever, will the driver get a tx_status with the overall timer spent > serving that frame anyway (read: that's what I actually want)? Currently not, but this can be achieved by moving the tsfl = get_clock_counter(); from __wlan_tx to _wlan_tx() and kill the one in wlan_tx_status. Regards, Christian -- 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
