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.
Best regards,
Maxim Levitsky
--
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
