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 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
