I wonder if anybody knows something more about this issue by now, as it appears to occur to a few people. I reread the thread (rather quickly) but I do not see many specifications of driver/mac80211/kernel. The few cases that do contain specs all appear to be using fedora (don't want to jump to conclusions). But just wondering if anybody experienced this on any other kernel? The log that I saw from a person with these symptoms, showed a perfectly normal booting driver, doing all the initialization identical to my functional card, except that apparently iwl_mac_open() (which is currently known as iwl3945_mac_start iirc) is never called. this callback is conditionally called from mac80211, in on it's turn a callback from even higher up the kernel stack. Hence my best (uneducated) guess would be that for some reason mac80211 doesn't call the ops->start(), but the scan (completion) somehow manages to rectify this I believe this bug is similar though with older versions of the code http://bughost.org/bugzilla/show_bug.cgi?id=1452 although back then the scan didn't magically fix it. Seeing as the driver appears to be functioning normally (it's receiving! and dropping packages because not open). and my knowledge of mac80211 is very limited i'm hoping someone here knows: What could sensibly be causing ops->start() not to be called? Tomas Winkler wrote: > On 10/18/07, Johannes Berg <johannes@xxxxxxxxxxxxxxxx> wrote: >> On Thu, 2007-10-18 at 08:23 -0400, Stephen Clark wrote: >> >>>>> iwlist eth1 scan would report no scan results, I then switched to loading >>>>> the kernel module with >>>>> the option that tells iwl3945 to do software scanning and it works >>>>> everytime now. >>> In my modprobe.conf file: >>> options iwl3945 disable_hw_scan=1 >> Hah. Told you it wasn't mac80211's problem. Can somebody remind me again >> exactly why we have hardware scan offload when we parse each received >> packet anyway and the hardware doesn't even batch them so the CPU could >> wake up less? >> > 1. Tuning to each channel is done internally by fw so you don't spend > cycles and it's is faster to switch channels so overall scanning take > less time. Sending probe responses is also offloaded. Returning to > operational channel is more precisely matched to DTIM period as it is > handled by RT code. > 2. There are also more advanced modes of scanning such as during voice > traffic etc. > 3. Yes beacon batching will be nice, but there is a memory tradeoff. > Tomas > >> johannes >> >> > - 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
