Let me just be really clear. Fast channel change is notoriously unreliable and really only fully debugged on some very later chips. The correct thing to do is something like this: * if you meet the fast cc requirements (same channel width, same frequency band, etc) then change channel; * if you fail the initial cal, or you hit some traffic stop condition, or you start failing NF cals - do a cold reset. Now, unless you're doing some kind of very latency sensitive applications (eg doing channel scans whilst in hostap mode) and you debug this very very thoroughly, fast-cc is not guaranteed to work. So I'd just ignore fast channel change in its entirety. Now, warm versus cold reset. Cold reset resets everything. Warm reset apparently doesn't fully reset everything in the MAC/PHY. Although I -thought- the initval arrays would initialise things, apparently there are some things that don't get fully cleared. Hence why I suggest doing a cold reset if things are going a bit awry. Felix's catch was good - if the queues weren't fully stopped, just do a cold reset. But I'd just give up on fast-cc for now. Adrian -- 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
