On Mon, Jun 16, 2008 at 5:35 PM, Dan Williams <dcbw@xxxxxxxxxx> wrote: > On Mon, 2008-06-16 at 09:08 +0300, Maxim Levitsky wrote: >> Tomas Winkler wrote: >> > On Mon, Jun 16, 2008 at 8:50 AM, Maxim Levitsky <maximlevitsky@xxxxxxxxx> wrote: >> >> Tomas Winkler wrote: >> >>> On Sun, Jun 15, 2008 at 6:09 PM, Tomas Winkler <tomasw@xxxxxxxxx> wrote: >> >>>> On Sun, Jun 15, 2008 at 5:12 PM, Maxim Levitsky <maximlevitsky@xxxxxxxxx> >> >>>> wrote: >> >>>>> Tomas Winkler wrote: >> >>>>>> On Sun, Jun 15, 2008 at 4:42 PM, Maxim Levitsky >> >>>>>> <maximlevitsky@xxxxxxxxx> >> >>>>>> wrote: >> >>>>>>> Tomas Winkler wrote: >> >>>>>>>> On Fri, Jun 13, 2008 at 6:06 PM, Maxim Levitsky >> >>>>>>>> <maximlevitsky@xxxxxxxxx> >> >>>>>>>> wrote: >> >>>>>>>>> Tor Håkon Haugen wrote: >> >>>>>>>>>> John W. Linville wrote: >> >>>>>>>>>>> On Fri, Jun 13, 2008 at 03:35:23PM +0800, Zhu Yi wrote: >> >>>>>>>>>>>> On Thu, 2008-06-12 at 09:59 -0400, John W. Linville wrote: >> >>>>>>>>>>>>> Honestly I'm tempted to change it to "enable_hw_scan" instead... >> >>>>>>>>>>>> Give the advantages, I'd like to use it if we can fix the bug (I >> >>>>>>>>>>>> haven't >> >>>>>>>>>>>> seen what the bug is myself). But you are free to change the >> >>>>>>>>>>>> default >> >>>>>>>>>>>> value until it is fixed. There is no such problem for 4965, >> >>>>>>>>>>>> right? >> >>>>>>>>>>> AFAICT only the 3945 seems to need it. >> >>>>>>>>>>> >> >>>>>>>>>> I can confirm that this also applies to 4965 as a friend of mine >> >>>>>>>>>> has >> >>>>>>>>>> this card. According to him the card works a lot better with the >> >>>>>>>>>> parameters "swcrypto=1" and "disable_hw_scan=1". >> >>>>>>>>> Just to make it clear, >> >>>>>>>>> iwl3945 doesn't work at all without disable_hw_scan=1 here. >> >>>>>>>>> The driver just shuts down thee card since it detects microcode >> >>>>>>>>> error. >> >>>>>>>>> >> >>>>>>>> It looks like this is all caused by the big rate, band patch. Looks >> >>>>>>>> like A band scan channels are not configured correctly for the >> >>>>>>>> scanning. This crashes the firmware. >> >>>>>>>> >> >>>>>>>> Tomas >> >>>>>>> Probably, I see that eeprom according to dmesg contains no info about >> >>>>>>> A >> >>>>>>> channels, so maybe this crashes the firmware. >> >>>>>>> >> >>>>>> Can you please send your dmesg. >> >>>>> I did that >> >>>>> (You mean dmesg without disable_hw_scan=1?) >> >>>>> >> >>>>> If not what debug options I should include >> >>>>> (I tried same firmware debug options, but the log wrapped around.) >> >>>>> >> >>>>> dmesg without disable_hw_scan=1 attached. >> >>>>> >> >>>>> >> >>>>>>> I have few questions: >> >>>>>>> >> >>>>>>> * Is there a software workaround without the need to update the >> >>>>>>> firmware? >> >>>>>> Yes >> >>>>>> >> >>>>>>> * Is the firmware error so harmful, so driver can't continue? >> >>>>>> This is firmware misconfiguration. Driver should be friendly to >> >>>>>> firmware and use correctly API. >> >>>>>> >> >>>>>>> * Can I expect updated version of the firmware with fix? >> >>>>>> No need so far. >> >>>>>> >> >>>>>>> Sadly this confirms that firmware is worse that I thought, it is >> >>>>>>> closer >> >>>>>>> to >> >>>>>>> closed drivers. >> >>>>>> The firmware API is open, it just wasn't used correctly. >> >>>>> I mean if there is a bug in firmware, nobody expect intel can fix it. >> >>>> Intel is fixing bugs in the firmware. Still this doesn't look like a >> >>>> firmware error. >> >>>> >> >>>>> BTW you say that firmware api is open, >> >>>>> is there a programming manual for this wireless chip? >> >>>> it's well documented in -commands.h file >> >>> >> >>> >> >>> Please try this one >> >>> >> >>> --- a/drivers/net/wireless/iwlwifi/iwl3945-base.c >> >>> +++ b/drivers/net/wireless/iwlwifi/iwl3945-base.c >> >>> @@ -3348,7 +3348,10 @@ static void >> >>> iwl3945_rx_scan_complete_notif(struct iwl3945_priv *priv, >> >>> >> >>> /* Remove this scanned band from the list >> >>> * of pending bands to scan */ >> >>> - priv->scan_bands--; >> >>> + if (priv->cfg->sku & IWL_SKU_A) >> >>> + priv->scan_bands--; >> >>> + else >> >>> + priv->scan_bands = 0; >> >>> >> >>> >> >> >> >> I tested this patch, and it fixes this issue, Thanks a lot. >> >> >> > Thanks a lot for helping resolve this. I will post an official patch. >> > Tomas >> >> Thanks to you too. >> >> I just want to note that hardware scanning doesn't work well here >> (something unrelated) >> >> First of all I noticed large delays in communications occurring >> sometimes, I for example tried pinging Google, and every 20 replies >> I get about 10 lost packets. (this is exactly what hardware scanning >> should prevent, but it seems that the opposite happens) >> >> I tried that again now, and see no delays, but I reproduced this twice. >> >> Then power levels go crazy, the nm-applet shows that my access point >> have 23% quality, then 100%, then something low again, and looking list >> of networks withing same applet, it shows for example now that all 3 >> networks (mine, and two neighbors) have 100% quality, which is just wrong. > > Note that NM will periodically request scans (~ every 2 minutes or so) > which can cause latency in pings. But AFAIK it shouldn't really cause > _lost_ pings, since the driver and the AP need to work together to avoid > dropping packets when the card isn't on the same channel as the AP is. > I'm pretty sure mac80211 handles this in software (by doing the > powersave poll trick to get the AP to buffer frames for the STA while > not on the associated channel). Not sure how the hardware handles it, > but frames for the AP should _NOT_ be leaking out when the card isn't on > the same channel as the AP. > The same mechanism is used in HW scanning but with luxury of real time system. Tomas -- 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
