Re: [BUG] iwlwifi 3945 works only with disable_hw_scan=1

Re: [BUG] iwlwifi 3945 works only with disable_hw_scan=1

[Maxim Levitsky]

Maxim Levitsky wrote:
> I recently bought an acer aspire 5720G, and wireless didn't work with
> standard ubuntu 2.6.24 kernel.
> 
> I found that specifying the above option 'fixes' the driver
> but I also noticed that list of available access points shrinks
> to just one (the connected) point.
> 
> Moreover there is a trouble in changing a access point, it just hangs.
> the button that toggles wireless does work, but doesn't blink.
> 
> I then installed latest -git kernel (~ 2.6.26-rc4) and got this:
> 
> * I still have to use disable_hw_scan=1
> * Wireless led works thanks to acer-wmi
> * If I disable wireless with the button, I _can't_ re-enable it unless
>   I reload the module.
> 
> * List of access points doesn't shrink, and I can switch between those points.
> 
> 
> When I omit disable_hw_scan=1, I get errors about REPLY_SCAN_CMD
> I will send detailed debug info later.
> 
> Best regards,
> 	Maxim Levitsky


I found why I can't reenable wireless with wireless button.

It turns out that iwlwifi doesn't enable the wireless function after a 
R/F kill switch was enabled ether by the button or explicitly.

I bisected this to commit 5a66926aa9230810704fd5a127966215fd58881e
in linus tree.

Best regards,
	Maxim Levitsky

Re: [ipw3945-devel] [BUG] iwlwifi 3945 works only with disable_hw_scan=1

[Zhu Yi]

On Wed, 2008-06-11 at 18:47 +0300, Maxim Levitsky wrote:
> 
> I found why I can't reenable wireless with wireless button.
> 
> It turns out that iwlwifi doesn't enable the wireless function after a
> R/F kill switch was enabled ether by the button or explicitly.
> 
> I bisected this to commit 5a66926aa9230810704fd5a127966215fd58881e
> in linus tree.

The card will receive an interrupt when you disable the rf kill switch
anyway whatever the wireless function is enabled or not. So the driver
will enable the wireless function again. Please check if the interface
(wlan0) is up when you disable the rf kill switch later. If it is not,
you have to bring it up manually (i.e. ifconfig wlan0 up) to enable the
wireless function. Otherwise please provide the dmesg with
debug=0x20000.

Thanks,
-yi

Re: [ipw3945-devel] [BUG] iwlwifi 3945 works only with disable_hw_scan=1

[drago01]

On Thu, Jun 12, 2008 at 4:26 AM, Zhu Yi <yi.zhu@intel.com> wrote:
> On Wed, 2008-06-11 at 18:47 +0300, Maxim Levitsky wrote:
>>
>> I found why I can't reenable wireless with wireless button.
>>
>> It turns out that iwlwifi doesn't enable the wireless function after a
>> R/F kill switch was enabled ether by the button or explicitly.
>>
>> I bisected this to commit 5a66926aa9230810704fd5a127966215fd58881e
>> in linus tree.
>
> The card will receive an interrupt when you disable the rf kill switch
> anyway [...]
It does? I thought thats only true for 4965 ... 3945 uses an ucode
event for that thats why it does not detect the rfkill state when the
interface is down.

Re: [ipw3945-devel] [BUG] iwlwifi 3945 works only with disable_hw_scan=1

[Zhu Yi]

On Thu, 2008-06-12 at 08:42 +0200, drago01 wrote:
> > The card will receive an interrupt when you disable the rf kill
> switch
> > anyway [...]
> It does? I thought thats only true for 4965 ... 3945 uses an ucode
> event for that thats why it does not detect the rfkill state when the
> interface is down.

I was wrong. The card won't receive interrupt if the interface is down
since we have disable the device. So the driver does nothing when you
disable the rf_kill switch when the interface is down. But if you do so
and then issue an `ifconfig wlan0 up`, the iwl3945_up() will read the
hardware rf_kill register CSR_GP_CNTRL_REG_FLAG_HW_RF_KILL_SW before
load the ucode and initialize everything. This is both true for 3945 and
4965.

Thanks,
-yi

Re: [ipw3945-devel] [BUG] iwlwifi 3945 works only with disable_hw_scan=1

[Maxim Levitsky]

Zhu Yi wrote:
> On Wed, 2008-06-11 at 18:47 +0300, Maxim Levitsky wrote:
>> I found why I can't reenable wireless with wireless button.
>>
>> It turns out that iwlwifi doesn't enable the wireless function after a
>> R/F kill switch was enabled ether by the button or explicitly.
>>
>> I bisected this to commit 5a66926aa9230810704fd5a127966215fd58881e
>> in linus tree.
> 
> The card will receive an interrupt when you disable the rf kill switch
> anyway whatever the wireless function is enabled or not. So the driver
> will enable the wireless function again. Please check if the interface
> (wlan0) is up when you disable the rf kill switch later. If it is not,
> you have to bring it up manually (i.e. ifconfig wlan0 up) to enable the
> wireless function. Otherwise please provide the dmesg with
> debug=0x20000.
> 
> Thanks,
> -yi
> 

Why didn't I thought about this before...
This is exactly what happens, so this isn't a bug.

What happens is the Network manager brings wlan0 down is it detects that
there is no link, but this now removes the firmware.

I guess that the right solution is to listen to the wireless button (via 
input layer), and turn card on manually.

If I remember correctly there is something like that in kernel, I try to 
enable this.

Otherwise this can be implemented in userspace.

Best regards,
	Maxim Levitsky

Re: [ipw3945-devel] [BUG] iwlwifi 3945 works only with disable_hw_scan=1

[John W. Linville]

On Thu, Jun 12, 2008 at 11:28:35AM +0800, Zhu Yi wrote:

> I don't understand why "disable_hw_scan=1" works for you. Can you also
> attach the dmesg for it?

How does the hardware scan differ from what mac80211 does when
scanning?  I still see a lot of mysterious iwlwifi (especially iwl3945)
problems in Fedora that seem to disappear with disable_hw_scan=1.

Honestly I'm tempted to change it to "enable_hw_scan" instead...

John
-- 
John W. Linville
linville@tuxdriver.com

Re: [ipw3945-devel] [BUG] iwlwifi 3945 works only with disable_hw_scan=1

[Maxim Levitsky]

John W. Linville wrote:
> On Thu, Jun 12, 2008 at 11:28:35AM +0800, Zhu Yi wrote:
> 
>> I don't understand why "disable_hw_scan=1" works for you. Can you also
>> attach the dmesg for it?
> 
> How does the hardware scan differ from what mac80211 does when
> scanning?  I still see a lot of mysterious iwlwifi (especially iwl3945)
> problems in Fedora that seem to disappear with disable_hw_scan=1.
> 
> Honestly I'm tempted to change it to "enable_hw_scan" instead...
> 
> John

Exactly.

Although hardware scanning is better, until it is fixed it
is better to disable it, so at least users will get working wireless out
of box.

Best regards,
	Maxim levitsky

PS: intel devs, please look at that, it looks like your firmware has a 
bug, so please try to fix it.

Re: [ipw3945-devel] [BUG] iwlwifi 3945 works only with disable_hw_scan=1

[Maxim Levitsky]

Maxim Levitsky wrote:
> Zhu Yi wrote:
>> On Wed, 2008-06-11 at 18:47 +0300, Maxim Levitsky wrote:
>>> I found why I can't reenable wireless with wireless button.
>>>
>>> It turns out that iwlwifi doesn't enable the wireless function after a
>>> R/F kill switch was enabled ether by the button or explicitly.
>>>
>>> I bisected this to commit 5a66926aa9230810704fd5a127966215fd58881e
>>> in linus tree.
>>
>> The card will receive an interrupt when you disable the rf kill switch
>> anyway whatever the wireless function is enabled or not. So the driver
>> will enable the wireless function again. Please check if the interface
>> (wlan0) is up when you disable the rf kill switch later. If it is not,
>> you have to bring it up manually (i.e. ifconfig wlan0 up) to enable the
>> wireless function. Otherwise please provide the dmesg with
>> debug=0x20000.
>>
>> Thanks,
>> -yi
>>
> 
> Why didn't I thought about this before...
> This is exactly what happens, so this isn't a bug.
> 
> What happens is the Network manager brings wlan0 down is it detects that
> there is no link, but this now removes the firmware.
> 
> I guess that the right solution is to listen to the wireless button (via 
> input layer), and turn card on manually.
> 
> If I remember correctly there is something like that in kernel, I try to 
> enable this.
> 
> Otherwise this can be implemented in userspace.
> 
> Best regards,
>     Maxim Levitsky

Nope 3945 doesn't support rfkill via new rfkill subsystem.

Re: [ipw3945-devel] [BUG] iwlwifi 3945 works only with disable_hw_scan=1

[Norbert Preining]

On Do, 12 Jun 2008, Maxim Levitsky wrote:
> Nope 3945 doesn't support rfkill via new rfkill subsystem.

Any chance to get this working, too?

Best wishes

Norbert

-------------------------------------------------------------------------------
Dr. Norbert Preining <preining@logic.at>        Vienna University of Technology
Debian Developer <preining@debian.org>                         Debian TeX Group
gpg DSA: 0x09C5B094      fp: 14DF 2E6C 0307 BE6D AD76  A9C0 D2BF 4AA3 09C5 B094
-------------------------------------------------------------------------------
KENTUCKEY (adv.)
Fitting exactly and satisfyingly. The cardboard box that slides neatly
into an exact space in a garage, or the last book which exactly fills
a bookshelf, is said to fit 'real nice and kentuckey'.
			--- Douglas Adams, The Meaning of Liff

Re: [ipw3945-devel] [BUG] iwlwifi 3945 works only with disable_hw_scan=1

[Dan Williams]

On Thu, 2008-06-12 at 15:48 +0300, Maxim Levitsky wrote:
> Zhu Yi wrote:
> > On Wed, 2008-06-11 at 18:47 +0300, Maxim Levitsky wrote:
> >> I found why I can't reenable wireless with wireless button.
> >>
> >> It turns out that iwlwifi doesn't enable the wireless function after a
> >> R/F kill switch was enabled ether by the button or explicitly.
> >>
> >> I bisected this to commit 5a66926aa9230810704fd5a127966215fd58881e
> >> in linus tree.
> > 
> > The card will receive an interrupt when you disable the rf kill switch
> > anyway whatever the wireless function is enabled or not. So the driver
> > will enable the wireless function again. Please check if the interface
> > (wlan0) is up when you disable the rf kill switch later. If it is not,
> > you have to bring it up manually (i.e. ifconfig wlan0 up) to enable the
> > wireless function. Otherwise please provide the dmesg with
> > debug=0x20000.
> > 
> > Thanks,
> > -yi
> > 
> 
> Why didn't I thought about this before...
> This is exactly what happens, so this isn't a bug.
> 
> What happens is the Network manager brings wlan0 down is it detects that
> there is no link, but this now removes the firmware.
> 
> I guess that the right solution is to listen to the wireless button (via 
> input layer), and turn card on manually.
> 
> If I remember correctly there is something like that in kernel, I try to 
> enable this.
> 
> Otherwise this can be implemented in userspace.

The right solution is for NM to not take the device down (essentially
doing SIOCSIFFLAGS with !IFF_UP), but to set the TX power off.  However,
that's not possible right now, because HAL doesn't provide enough
information about the killswitches to distinguish between a software
rfkill (which means we can turn the power back on) and a hardware rfkill
(which means the user has to flip something).  On ipw2100, 2200, and
2915, setting the TX power off looks exactly like a hardware kill to
HAL, so if you chose unchecked "Enable Wireless" in the nm applet, you'd
never be able to turn wireless back on, because HAL and NM think there's
a hardware kill active.

The kernel rfkill layer needs to be supported in all drivers, and second
we need to figure out the HW vs. SW kill thing whether that happens in
rfkill or not.

Dan

Re: [ipw3945-devel] [BUG] iwlwifi 3945 works only with disable_hw_scan=1

[Stephen Clark]

John W. Linville wrote:
> On Thu, Jun 12, 2008 at 11:28:35AM +0800, Zhu Yi wrote:
> 
>> I don't understand why "disable_hw_scan=1" works for you. Can you also
>> attach the dmesg for it?
> 
> How does the hardware scan differ from what mac80211 does when
> scanning?  I still see a lot of mysterious iwlwifi (especially iwl3945)
> problems in Fedora that seem to disappear with disable_hw_scan=1.
> 
> Honestly I'm tempted to change it to "enable_hw_scan" instead...
> 
> John
It has been a while since I tested without "disable_hw_scan=1" - my 3945 works
every time with it - last time I tested without it was very hit or miss. 
Sometimes taking over 10 minutes to get associated, sometimes never and this
was with me right next to the WAP.

I think the latest in the fedora kernel I am using is 1.26kds as I recall.

Steve

-- 

"They that give up essential liberty to obtain temporary safety,
deserve neither liberty nor safety."  (Ben Franklin)

"The course of history shows that as a government grows, liberty
decreases."  (Thomas Jefferson)

Re: [ipw3945-devel] [BUG] iwlwifi 3945 works only with disable_hw_scan=1

[Zhu Yi]

On Thu, 2008-06-12 at 11:02 -0400, Dan Williams wrote:
> > I guess that the right solution is to listen to the wireless button
> (via 
> > input layer), and turn card on manually.
> > 
> > If I remember correctly there is something like that in kernel, I
> try to 
> > enable this.
> > 
> > Otherwise this can be implemented in userspace.
> 
> The right solution is for NM to not take the device down (essentially
> doing SIOCSIFFLAGS with !IFF_UP), but to set the TX power off.
> However,
> that's not possible right now, because HAL doesn't provide enough
> information about the killswitches to distinguish between a software
> rfkill (which means we can turn the power back on) and a hardware
> rfkill
> (which means the user has to flip something).  On ipw2100, 2200, and
> 2915, setting the TX power off looks exactly like a hardware kill to
> HAL, so if you chose unchecked "Enable Wireless" in the nm applet,
> you'd never be able to turn wireless back on, because HAL and NM think
> there's a hardware kill active.

I think who takes the interface down is responsible to bring it up. Even
if the driver receives a rf_kill switch disabled interrupt, it should
keep the current IFF_UP status. It should never bring it up or down
itself. (Think about the carrier on/off in ethernet).

I wonder why NM need to ifdown or "txpower off" when rf_kill switch
(both for SW and HW) is enabled. The driver already handles it. Could it
save more power?

Thanks,
-yi

Re: [ipw3945-devel] [BUG] iwlwifi 3945 works only with disable_hw_scan=1

[Zhu Yi]

On Thu, 2008-06-12 at 09:59 -0400, John W. Linville wrote:
> How does the hardware scan differ from what mac80211 does when
> scanning?

Software scan disables Tx during the scan process while hardware scan
doesn't. So you are expected to see continous ping responds instead of a
freeze during the scan period. Hardware scan is also more efficient
since it is handled by the firmware.

> I still see a lot of mysterious iwlwifi (especially iwl3945)
> problems in Fedora that seem to disappear with disable_hw_scan=1.

I don't see this problem from my side. I'll do more testing for 3945.

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

Thanks,
-yi

Re: [ipw3945-devel] [BUG] iwlwifi 3945 works only with disable_hw_scan=1

[Filippo Zangheri]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hello everybody.

Zhu Yi ha scritto:
> On Thu, 2008-06-12 at 09:59 -0400, John W. Linville wrote:
>> How does the hardware scan differ from what mac80211 does when
>> scanning?
> 
> Software scan disables Tx during the scan process while hardware scan
> doesn't. So you are expected to see continous ping responds instead of a
> freeze during the scan period. Hardware scan is also more efficient
> since it is handled by the firmware.
> 
>> I still see a lot of mysterious iwlwifi (especially iwl3945)
>> problems in Fedora that seem to disappear with disable_hw_scan=1.
> 
> I don't see this problem from my side. I'll do more testing for 3945.

Me neither. iwl3945's HW scan has always worked properly on my
system. It's a 32bit Core2Duo with latest stable vanilla kernel and
latest compat-wireless driver and mac80211 subsystem.

Never had a single problem with it.

Just a proper-work report.

Thank you for a driver that - at least on my system - is working
great (even from the speed point of view, but that's another topic).


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


- --
Filippo Zangheri

GPG key ID: 0x6C1F2F2F
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)

iD8DBQFIUjROjzxMG2wfLy8RApPjAJ4sUw0x9TcLYOh/YdIxV/hFWeUbCwCfWaLK
Wk97c4XkgpxvN8RNvzNefJA=
=Gn9F
-----END PGP SIGNATURE-----

Re: [ipw3945-devel] [BUG] iwlwifi 3945 works only with disable_hw_scan=1

[Tor Håkon Haugen]

Just to shred some (more confusing) light on this case.

I'm using the iwl3945-driver, and haven't had a problem at home using
HW-scan. At my parents, on the other hand, which uses the same ssid
and the same wep-key, it doesn't work. 1 out of 10 'iwlist scan'
failes to see anything at all.
I haven't tested with disable_hw_scan=1 yet though. But I can try it
the next time I'm visiting them, and post my results here.
Are there anything else information about these APs that anyone might
be interested in? Except for the key? ;-)

- Tor H. Haugen

Filippo Zangheri wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Hello everybody.
>
> Zhu Yi ha scritto:
>   
>> On Thu, 2008-06-12 at 09:59 -0400, John W. Linville wrote:
>>     
>>> How does the hardware scan differ from what mac80211 does when
>>> scanning?
>>>       
>> Software scan disables Tx during the scan process while hardware scan
>> doesn't. So you are expected to see continous ping responds instead of a
>> freeze during the scan period. Hardware scan is also more efficient
>> since it is handled by the firmware.
>>
>>     
>>> I still see a lot of mysterious iwlwifi (especially iwl3945)
>>> problems in Fedora that seem to disappear with disable_hw_scan=1.
>>>       
>> I don't see this problem from my side. I'll do more testing for 3945.
>>     
>
> Me neither. iwl3945's HW scan has always worked properly on my
> system. It's a 32bit Core2Duo with latest stable vanilla kernel and
> latest compat-wireless driver and mac80211 subsystem.
>
> Never had a single problem with it.
>
> Just a proper-work report.
>
> Thank you for a driver that - at least on my system - is working
> great (even from the speed point of view, but that's another topic).
>
>
>   
>>> 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?
>>     
>
>
> - --
> Filippo Zangheri
>
> GPG key ID: 0x6C1F2F2F
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.6 (GNU/Linux)
>
> iD8DBQFIUjROjzxMG2wfLy8RApPjAJ4sUw0x9TcLYOh/YdIxV/hFWeUbCwCfWaLK
> Wk97c4XkgpxvN8RNvzNefJA=
> =Gn9F
> -----END PGP SIGNATURE-----
>
>
> -------------------------------------------------------------------------
> Check out the new SourceForge.net Marketplace.
> It's the best place to buy or sell services for
> just about anything Open Source.
> http://sourceforge.net/services/buy/index.php
> _______________________________________________
> Ipw3945-devel mailing list
> Ipw3945-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/ipw3945-devel
>   

Re: [ipw3945-devel] [BUG] iwlwifi 3945 works only with disable_hw_scan=1

[John W. Linville]

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:
> > How does the hardware scan differ from what mac80211 does when
> > scanning?
> 
> Software scan disables Tx during the scan process while hardware scan
> doesn't. So you are expected to see continous ping responds instead of a
> freeze during the scan period. Hardware scan is also more efficient
> since it is handled by the firmware.
> 
> > I still see a lot of mysterious iwlwifi (especially iwl3945)
> > problems in Fedora that seem to disappear with disable_hw_scan=1.
> 
> I don't see this problem from my side. I'll do more testing for 3945.

FWIW, I don't have a reproducing environment that requires
disable_hw_scan either.  But I could probably dig-out several Fedora
bug reports that claim to need it.

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

John
-- 
John W. Linville
linville@tuxdriver.com

Re: [ipw3945-devel] [BUG] iwlwifi 3945 works only with disable_hw_scan=1

[Dan Williams]

On Fri, 2008-06-13 at 10:00 +0800, Zhu Yi wrote:
> On Thu, 2008-06-12 at 11:02 -0400, Dan Williams wrote:
> > > I guess that the right solution is to listen to the wireless button
> > (via 
> > > input layer), and turn card on manually.
> > > 
> > > If I remember correctly there is something like that in kernel, I
> > try to 
> > > enable this.
> > > 
> > > Otherwise this can be implemented in userspace.
> > 
> > The right solution is for NM to not take the device down (essentially
> > doing SIOCSIFFLAGS with !IFF_UP), but to set the TX power off.
> > However,
> > that's not possible right now, because HAL doesn't provide enough
> > information about the killswitches to distinguish between a software
> > rfkill (which means we can turn the power back on) and a hardware
> > rfkill
> > (which means the user has to flip something).  On ipw2100, 2200, and
> > 2915, setting the TX power off looks exactly like a hardware kill to
> > HAL, so if you chose unchecked "Enable Wireless" in the nm applet,
> > you'd never be able to turn wireless back on, because HAL and NM think
> > there's a hardware kill active.
> 
> I think who takes the interface down is responsible to bring it up. Even
> if the driver receives a rf_kill switch disabled interrupt, it should
> keep the current IFF_UP status. It should never bring it up or down
> itself. (Think about the carrier on/off in ethernet).
> 
> I wonder why NM need to ifdown or "txpower off" when rf_kill switch
> (both for SW and HW) is enabled. The driver already handles it. Could it
> save more power?

SW rfkill doesn't necessarily kill the device.  Input-only switches
(like Fn+F5 on thinkpads for exampel) aren't handled by the kernel
rfkill system and thus something in userspace needs to handle them
instead.  It's probably worth checking the radio state when the event
comes in and only if the radio isn't already disabled, then set tx power
off.

Dan

Re: [ipw3945-devel] [BUG] iwlwifi 3945 works only with disable_hw_scan=1

[Tor Håkon Haugen]

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


  Tor H. Haugen

Re: [ipw3945-devel] [BUG] iwlwifi 3945 works only with disable_hw_scan=1

[Maxim Levitsky]

Tor H=E5kon Haugen wrote:
>=20
> 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 ha=
ven't
>>> seen what the bug is myself). But you are free to change the defaul=
t
>>> value until it is fixed. There is no such problem for 4965, right?
>> AFAICT only the 3945 seems to need it.
>>
>=20
> I can confirm that this also applies to 4965 as a friend of mine has=20
> this card. According to him the card works a lot better with the=20
> parameters "swcrypto=3D1" and "disable_hw_scan=3D1".

Just to make it clear,
iwl3945 doesn't work at all without disable_hw_scan=3D1 here.
The driver just shuts down thee card since it detects microcode error.

Best regards,
	Maxim Levitsky
--
To unsubscribe from this list: send the line "unsubscribe linux-wireles=
s" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [ipw3945-devel] [BUG] iwlwifi 3945 works only with disable_hw_scan=1

[Tor Håkon Haugen]

Maxim Levitsky wrote:
> Tor H=E5kon 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=20
>>>> haven't
>>>> seen what the bug is myself). But you are free to change the defau=
lt
>>>> 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=
=20
>> this card. According to him the card works a lot better with the=20
>> parameters "swcrypto=3D1" and "disable_hw_scan=3D1".
>=20
> Just to make it clear,
> iwl3945 doesn't work at all without disable_hw_scan=3D1 here.
> The driver just shuts down thee card since it detects microcode error=
=2E
>=20
Ah, Sorry. Disregard my last post then.

  Tor H. Haugen

> Best regards,
>     Maxim Levitsky
--
To unsubscribe from this list: send the line "unsubscribe linux-wireles=
s" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [ipw3945-devel] [BUG] iwlwifi 3945 works only with disable_hw_scan=1

[Tomas Winkler]

On Fri, Jun 13, 2008 at 6:06 PM, Maxim Levitsky <maximlevitsky@gmail.co=
m> wrote:
> Tor H=E5kon 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 h=
aven't
>>>> seen what the bug is myself). But you are free to change the defau=
lt
>>>> 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=3D1" and "disable_hw_scan=3D1".
>
> Just to make it clear,
> iwl3945 doesn't work at all without disable_hw_scan=3D1 here.
> The driver just shuts down thee card since it detects microcode error=
=2E
>

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
--
To unsubscribe from this list: send the line "unsubscribe linux-wireles=
s" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [ipw3945-devel] [BUG] iwlwifi 3945 works only with disable_hw_scan=1

[Maxim Levitsky]

Tomas Winkler wrote:
> On Fri, Jun 13, 2008 at 6:06 PM, Maxim Levitsky <maximlevitsky@gmail.=
com> wrote:
>> Tor H=E5kon 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 defa=
ult
>>>>> 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 ha=
s
>>> this card. According to him the card works a lot better with the
>>> parameters "swcrypto=3D1" and "disable_hw_scan=3D1".
>> Just to make it clear,
>> iwl3945 doesn't work at all without disable_hw_scan=3D1 here.
>> The driver just shuts down thee card since it detects microcode erro=
r.
>>
>=20
> 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.
>=20
> Tomas
Any patches to fix this are welcome.

Best regards,
	Maxim Levitsky
--
To unsubscribe from this list: send the line "unsubscribe linux-wireles=
s" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [ipw3945-devel] [BUG] iwlwifi 3945 works only with disable_hw_scan=1

[Luis R. Rodriguez]

T24gRnJpLCBKdW4gMTMsIDIwMDggYXQgMTowNCBQTSwgVG9tYXMgV2lua2xlciA8dG9tYXN3QGdt
YWlsLmNvbT4gd3JvdGU6Cj4gT24gRnJpLCBKdW4gMTMsIDIwMDggYXQgNjowNiBQTSwgTWF4aW0g
TGV2aXRza3kgPG1heGltbGV2aXRza3lAZ21haWwuY29tPiB3cm90ZToKPj4gVG9yIEjDpWtvbiBI
YXVnZW4gd3JvdGU6Cj4+Pgo+Pj4gSm9obiBXLiBMaW52aWxsZSB3cm90ZToKPj4+PiBPbiBGcmks
IEp1biAxMywgMjAwOCBhdCAwMzozNToyM1BNICswODAwLCBaaHUgWWkgd3JvdGU6Cj4+Pj4+IE9u
IFRodSwgMjAwOC0wNi0xMiBhdCAwOTo1OSAtMDQwMCwgSm9obiBXLiBMaW52aWxsZSB3cm90ZToK
Pj4+Pj4+IEhvbmVzdGx5IEknbSB0ZW1wdGVkIHRvIGNoYW5nZSBpdCB0byAiZW5hYmxlX2h3X3Nj
YW4iIGluc3RlYWQuLi4KPj4+Pj4gR2l2ZSB0aGUgYWR2YW50YWdlcywgSSdkIGxpa2UgdG8gdXNl
IGl0IGlmIHdlIGNhbiBmaXggdGhlIGJ1ZyAoSSBoYXZlbid0Cj4+Pj4+IHNlZW4gd2hhdCB0aGUg
YnVnIGlzIG15c2VsZikuIEJ1dCB5b3UgYXJlIGZyZWUgdG8gY2hhbmdlIHRoZSBkZWZhdWx0Cj4+
Pj4+IHZhbHVlIHVudGlsIGl0IGlzIGZpeGVkLiBUaGVyZSBpcyBubyBzdWNoIHByb2JsZW0gZm9y
IDQ5NjUsIHJpZ2h0Pwo+Pj4+IEFGQUlDVCBvbmx5IHRoZSAzOTQ1IHNlZW1zIHRvIG5lZWQgaXQu
Cj4+Pj4KPj4+Cj4+PiBJIGNhbiBjb25maXJtIHRoYXQgdGhpcyBhbHNvIGFwcGxpZXMgdG8gNDk2
NSBhcyBhIGZyaWVuZCBvZiBtaW5lIGhhcwo+Pj4gdGhpcyBjYXJkLiBBY2NvcmRpbmcgdG8gaGlt
IHRoZSBjYXJkIHdvcmtzIGEgbG90IGJldHRlciB3aXRoIHRoZQo+Pj4gcGFyYW1ldGVycyAic3dj
cnlwdG89MSIgYW5kICJkaXNhYmxlX2h3X3NjYW49MSIuCj4+Cj4+IEp1c3QgdG8gbWFrZSBpdCBj
bGVhciwKPj4gaXdsMzk0NSBkb2Vzbid0IHdvcmsgYXQgYWxsIHdpdGhvdXQgZGlzYWJsZV9od19z
Y2FuPTEgaGVyZS4KPj4gVGhlIGRyaXZlciBqdXN0IHNodXRzIGRvd24gdGhlZSBjYXJkIHNpbmNl
IGl0IGRldGVjdHMgbWljcm9jb2RlIGVycm9yLgo+Pgo+Cj4gSXQgbG9va3MgbGlrZSB0aGlzIGlz
IGFsbCBjYXVzZWQgYnkgdGhlIGJpZyByYXRlLCBiYW5kIHBhdGNoLiBMb29rcwo+IGxpa2UgQSBi
YW5kIHNjYW4gY2hhbm5lbHMgYXJlIG5vdCBjb25maWd1cmVkIGNvcnJlY3RseSBmb3IgdGhlCj4g
c2Nhbm5pbmcuIFRoaXMgY3Jhc2hlcyB0aGUgZmlybXdhcmUuCgpXaHkgd291bGQgdGhpcyBjcmFz
aCBmaXJtd2FyZT8KCiAgTHVpcwo=

Re: [ipw3945-devel] [BUG] iwlwifi 3945 works only with disable_hw_scan=1

[Maxim Levitsky]

Tomas Winkler wrote:
> On Fri, Jun 13, 2008 at 6:06 PM, Maxim Levitsky <maximlevitsky@gmail.=
com> wrote:
>> Tor H=E5kon 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 defa=
ult
>>>>> 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 ha=
s
>>> this card. According to him the card works a lot better with the
>>> parameters "swcrypto=3D1" and "disable_hw_scan=3D1".
>> Just to make it clear,
>> iwl3945 doesn't work at all without disable_hw_scan=3D1 here.
>> The driver just shuts down thee card since it detects microcode erro=
r.
>>
>=20
> 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.
>=20
> Tomas

Probably, I see that eeprom according to dmesg contains no info about A
channels, so maybe this crashes the firmware.

I have few questions:

* Is there a software workaround without the need to update the firmwar=
e?

* Is the firmware error so harmful, so driver can't continue?

* Can I expect updated version of the firmware with  fix?

Sadly this confirms that firmware is worse that I thought, it is closer=
=20
to closed drivers.

(Although intel isn't guilty in this case due to regulations.)

Best regards,
	Maxim Levitsky
--
To unsubscribe from this list: send the line "unsubscribe linux-wireles=
s" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [ipw3945-devel] [BUG] iwlwifi 3945 works only with disable_hw_scan=1

[Tomas Winkler]

On Sun, Jun 15, 2008 at 4:42 PM, Maxim Levitsky <maximlevitsky@gmail.co=
m> wrote:
> Tomas Winkler wrote:
>>
>> On Fri, Jun 13, 2008 at 6:06 PM, Maxim Levitsky <maximlevitsky@gmail=
=2Ecom>
>> wrote:
>>>
>>> Tor H=E5kon 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..=
=2E
>>>>>>
>>>>>> 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 def=
ault
>>>>>> value until it is fixed. There is no such problem for 4965, righ=
t?
>>>>>
>>>>> AFAICT only the 3945 seems to need it.
>>>>>
>>>> I can confirm that this also applies to 4965 as a friend of mine h=
as
>>>> this card. According to him the card works a lot better with the
>>>> parameters "swcrypto=3D1" and "disable_hw_scan=3D1".
>>>
>>> Just to make it clear,
>>> iwl3945 doesn't work at all without disable_hw_scan=3D1 here.
>>> The driver just shuts down thee card since it detects microcode err=
or.
>>>
>>
>> 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 have few questions:
>
> * Is there a software workaround without the need to update the firmw=
are?

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 clos=
er to
> closed drivers.

The firmware API is open, it just wasn't used correctly.

> (Although intel isn't guilty in this case due to regulations.)

Thanks
Tomas
--
To unsubscribe from this list: send the line "unsubscribe linux-wireles=
s" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [ipw3945-devel] [BUG] iwlwifi 3945 works only with disable_hw_scan=1

[Maxim Levitsky]

[-- Attachment #1: Type: text/plain, Size: 2508 bytes --]

Tomas Winkler wrote:
> On Sun, Jun 15, 2008 at 4:42 PM, Maxim Levitsky <maximlevitsky@gmail.com> wrote:
>> Tomas Winkler wrote:
>>> On Fri, Jun 13, 2008 at 6:06 PM, Maxim Levitsky <maximlevitsky@gmail.com>
>>> 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.
BTW you say that firmware api is open,
is there a programming manual for this wireless chip?

> 
>> (Although intel isn't guilty in this case due to regulations.)
> 
> Thanks
> Tomas


[-- Attachment #2: iwlwifi_firmware_log.gz --]
[-- Type: application/x-gzip, Size: 21078 bytes --]

Re: [ipw3945-devel] [BUG] iwlwifi 3945 works only with disable_hw_scan=1

[Tomas Winkler]

On Sun, Jun 15, 2008 at 5:12 PM, Maxim Levitsky <maximlevitsky@gmail.co=
m> wrote:
> Tomas Winkler wrote:
>>
>> On Sun, Jun 15, 2008 at 4:42 PM, Maxim Levitsky <maximlevitsky@gmail=
=2Ecom>
>> wrote:
>>>
>>> Tomas Winkler wrote:
>>>>
>>>> On Fri, Jun 13, 2008 at 6:06 PM, Maxim Levitsky
>>>> <maximlevitsky@gmail.com>
>>>> wrote:
>>>>>
>>>>> Tor H=E5kon 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=
=2E..
>>>>>>>>
>>>>>>>> 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 d=
efault
>>>>>>>> value until it is fixed. There is no such problem for 4965, ri=
ght?
>>>>>>>
>>>>>>> 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=3D1" and "disable_hw_scan=3D1".
>>>>>
>>>>> Just to make it clear,
>>>>> iwl3945 doesn't work at all without disable_hw_scan=3D1 here.
>>>>> The driver just shuts down thee card since it detects microcode e=
rror.
>>>>>
>>>> It looks like this is all caused by the big rate, band patch. Look=
s
>>>> 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 abo=
ut A
>>> channels, so maybe this crashes the firmware.
>>>
>>
>> Can you please send your dmesg.
>
> I did that
> (You mean dmesg without disable_hw_scan=3D1?)
>
> If not what debug options I should include
> (I tried same firmware debug options, but the log wrapped around.)
>
> dmesg without disable_hw_scan=3D1 attached.
>
>
>>
>>> I have few questions:
>>>
>>> * Is there a software workaround without the need to update the fir=
mware?
>>
>> 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 cl=
oser
>>> 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-wireles=
s" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [ipw3945-devel] [BUG] iwlwifi 3945 works only with disable_hw_scan=1

[Tomas Winkler]

On Sun, Jun 15, 2008 at 6:09 PM, Tomas Winkler <tomasw@gmail.com> wrote=
:
> On Sun, Jun 15, 2008 at 5:12 PM, Maxim Levitsky <maximlevitsky@gmail.=
com> wrote:
>> Tomas Winkler wrote:
>>>
>>> On Sun, Jun 15, 2008 at 4:42 PM, Maxim Levitsky <maximlevitsky@gmai=
l.com>
>>> wrote:
>>>>
>>>> Tomas Winkler wrote:
>>>>>
>>>>> On Fri, Jun 13, 2008 at 6:06 PM, Maxim Levitsky
>>>>> <maximlevitsky@gmail.com>
>>>>> wrote:
>>>>>>
>>>>>> Tor H=E5kon 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" instea=
d...
>>>>>>>>>
>>>>>>>>> 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, r=
ight?
>>>>>>>>
>>>>>>>> AFAICT only the 3945 seems to need it.
>>>>>>>>
>>>>>>> I can confirm that this also applies to 4965 as a friend of min=
e has
>>>>>>> this card. According to him the card works a lot better with th=
e
>>>>>>> parameters "swcrypto=3D1" and "disable_hw_scan=3D1".
>>>>>>
>>>>>> Just to make it clear,
>>>>>> iwl3945 doesn't work at all without disable_hw_scan=3D1 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. Loo=
ks
>>>>> 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 ab=
out A
>>>> channels, so maybe this crashes the firmware.
>>>>
>>>
>>> Can you please send your dmesg.
>>
>> I did that
>> (You mean dmesg without disable_hw_scan=3D1?)
>>
>> If not what debug options I should include
>> (I tried same firmware debug options, but the log wrapped around.)
>>
>> dmesg without disable_hw_scan=3D1 attached.
>>
>>
>>>
>>>> I have few questions:
>>>>
>>>> * Is there a software workaround without the need to update the fi=
rmware?
>>>
>>> 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 c=
loser
>>>> 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=
=2E
>
> 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 =3D 0;


>
--
To unsubscribe from this list: send the line "unsubscribe linux-wireles=
s" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [ipw3945-devel] [BUG] iwlwifi 3945 works only with disable_hw_scan=1

[Zhu Yi]

On Fri, 2008-06-13 at 10:45 -0400, Dan Williams wrote:
> SW rfkill doesn't necessarily kill the device.  Input-only switches
> (like Fn+F5 on thinkpads for exampel) aren't handled by the kernel
> rfkill system and thus something in userspace needs to handle them
> instead.  It's probably worth checking the radio state when the event
> comes in and only if the radio isn't already disabled, then set tx
> power off.

OK. That makes sense.

Thanks,
-yi

Re: [ipw3945-devel] [BUG] iwlwifi 3945 works only with disable_hw_scan=1

[Maxim Levitsky]

Tomas Winkler wrote:
> On Sun, Jun 15, 2008 at 6:09 PM, Tomas Winkler <tomasw@gmail.com> wro=
te:
>> On Sun, Jun 15, 2008 at 5:12 PM, Maxim Levitsky <maximlevitsky@gmail=
=2Ecom> wrote:
>>> Tomas Winkler wrote:
>>>> On Sun, Jun 15, 2008 at 4:42 PM, Maxim Levitsky <maximlevitsky@gma=
il.com>
>>>> wrote:
>>>>> Tomas Winkler wrote:
>>>>>> On Fri, Jun 13, 2008 at 6:06 PM, Maxim Levitsky
>>>>>> <maximlevitsky@gmail.com>
>>>>>> wrote:
>>>>>>> Tor H=E5kon 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" inste=
ad...
>>>>>>>>>> Give the advantages, I'd like to use it if we can fix the bu=
g (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 mi=
ne has
>>>>>>>> this card. According to him the card works a lot better with t=
he
>>>>>>>> parameters "swcrypto=3D1" and "disable_hw_scan=3D1".
>>>>>>> Just to make it clear,
>>>>>>> iwl3945 doesn't work at all without disable_hw_scan=3D1 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. Lo=
oks
>>>>>> 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 a=
bout A
>>>>> channels, so maybe this crashes the firmware.
>>>>>
>>>> Can you please send your dmesg.
>>> I did that
>>> (You mean dmesg without disable_hw_scan=3D1?)
>>>
>>> If not what debug options I should include
>>> (I tried same firmware debug options, but the log wrapped around.)
>>>
>>> dmesg without disable_hw_scan=3D1 attached.
>>>
>>>
>>>>> I have few questions:
>>>>>
>>>>> * Is there a software workaround without the need to update the f=
irmware?
>>>> 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 i=
t.
>> 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
>=20
>=20
>=20
> Please try this one
>=20
> --- 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,
>=20
>         /* 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 =3D 0;
>=20
>=20


I tested this patch, and it fixes this issue, Thanks a lot.


Best regards,
	Maxim Levitsky

--
To unsubscribe from this list: send the line "unsubscribe linux-wireles=
s" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [ipw3945-devel] [BUG] iwlwifi 3945 works only with disable_hw_scan=1

[Tomas Winkler]

On Mon, Jun 16, 2008 at 8:50 AM, Maxim Levitsky <maximlevitsky@gmail.co=
m> wrote:
> Tomas Winkler wrote:
>>
>> On Sun, Jun 15, 2008 at 6:09 PM, Tomas Winkler <tomasw@gmail.com> wr=
ote:
>>>
>>> On Sun, Jun 15, 2008 at 5:12 PM, Maxim Levitsky <maximlevitsky@gmai=
l.com>
>>> wrote:
>>>>
>>>> Tomas Winkler wrote:
>>>>>
>>>>> On Sun, Jun 15, 2008 at 4:42 PM, Maxim Levitsky
>>>>> <maximlevitsky@gmail.com>
>>>>> wrote:
>>>>>>
>>>>>> Tomas Winkler wrote:
>>>>>>>
>>>>>>> On Fri, Jun 13, 2008 at 6:06 PM, Maxim Levitsky
>>>>>>> <maximlevitsky@gmail.com>
>>>>>>> wrote:
>>>>>>>>
>>>>>>>> Tor H=E5kon 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" inst=
ead...
>>>>>>>>>>>
>>>>>>>>>>> Give the advantages, I'd like to use it if we can fix the b=
ug (I
>>>>>>>>>>> haven't
>>>>>>>>>>> seen what the bug is myself). But you are free to change th=
e
>>>>>>>>>>> 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 m=
ine
>>>>>>>>> has
>>>>>>>>> this card. According to him the card works a lot better with =
the
>>>>>>>>> parameters "swcrypto=3D1" and "disable_hw_scan=3D1".
>>>>>>>>
>>>>>>>> Just to make it clear,
>>>>>>>> iwl3945 doesn't work at all without disable_hw_scan=3D1 here.
>>>>>>>> The driver just shuts down thee card since it detects microcod=
e
>>>>>>>> error.
>>>>>>>>
>>>>>>> It looks like this is all caused by the big rate, band patch. L=
ooks
>>>>>>> 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=3D1?)
>>>>
>>>> If not what debug options I should include
>>>> (I tried same firmware debug options, but the log wrapped around.)
>>>>
>>>> dmesg without disable_hw_scan=3D1 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 =3D 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
--
To unsubscribe from this list: send the line "unsubscribe linux-wireles=
s" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [ipw3945-devel] [BUG] iwlwifi 3945 works only with disable_hw_scan=1

[Maxim Levitsky]

Tomas Winkler wrote:
> On Mon, Jun 16, 2008 at 8:50 AM, Maxim Levitsky <maximlevitsky@gmail.=
com> wrote:
>> Tomas Winkler wrote:
>>> On Sun, Jun 15, 2008 at 6:09 PM, Tomas Winkler <tomasw@gmail.com> w=
rote:
>>>> On Sun, Jun 15, 2008 at 5:12 PM, Maxim Levitsky <maximlevitsky@gma=
il.com>
>>>> wrote:
>>>>> Tomas Winkler wrote:
>>>>>> On Sun, Jun 15, 2008 at 4:42 PM, Maxim Levitsky
>>>>>> <maximlevitsky@gmail.com>
>>>>>> wrote:
>>>>>>> Tomas Winkler wrote:
>>>>>>>> On Fri, Jun 13, 2008 at 6:06 PM, Maxim Levitsky
>>>>>>>> <maximlevitsky@gmail.com>
>>>>>>>> wrote:
>>>>>>>>> Tor H=E5kon 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" ins=
tead...
>>>>>>>>>>>> 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 t=
he
>>>>>>>>>>>> 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=3D1" and "disable_hw_scan=3D1".
>>>>>>>>> Just to make it clear,
>>>>>>>>> iwl3945 doesn't work at all without disable_hw_scan=3D1 here.
>>>>>>>>> The driver just shuts down thee card since it detects microco=
de
>>>>>>>>> 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=3D1?)
>>>>>
>>>>> If not what debug options I should include
>>>>> (I tried same firmware debug options, but the log wrapped around.=
)
>>>>>
>>>>> dmesg without disable_hw_scan=3D1 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 i=
s
>>>>>>> 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 =3D 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=20
(something unrelated)

=46irst of all I noticed large delays in communications occurring=20
sometimes, I for example tried pinging Google, and every 20 replies
I get about 10 lost packets. (this is exactly what hardware scanning=20
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=20
have 23% quality, then 100%, then something low again, and looking list=
=20
of networks withing same applet, it shows for example now that all 3=20
networks (mine, and two neighbors) have 100% quality, which is just wro=
ng.


Best regards,
	Maxim Levitsky

--
To unsubscribe from this list: send the line "unsubscribe linux-wireles=
s" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [ipw3945-devel] [BUG] iwlwifi 3945 works only with disable_hw_scan=1

[Maxim Levitsky]

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

Rebooted, and here it is:

maxim@MOBILE:~$ ping www.google.com
PING www.google.com (209.85.135.147) 56(84) bytes of data.
64 bytes from www.google.com (209.85.135.147): icmp_seq=1 ttl=245 time=89.0 ms
64 bytes from www.google.com (209.85.135.147): icmp_seq=2 ttl=245 time=89.2 ms
64 bytes from www.google.com (209.85.135.147): icmp_seq=3 ttl=245 time=87.2 ms
64 bytes from www.google.com (209.85.135.147): icmp_seq=4 ttl=245 time=87.0 ms
64 bytes from www.google.com (209.85.135.147): icmp_seq=5 ttl=245 time=85.7 ms
64 bytes from www.google.com (209.85.135.147): icmp_seq=6 ttl=245 time=88.2 ms
64 bytes from www.google.com (209.85.135.147): icmp_seq=7 ttl=245 time=88.2 ms
64 bytes from www.google.com (209.85.135.147): icmp_seq=8 ttl=245 time=86.7 ms
64 bytes from www.google.com (209.85.135.147): icmp_seq=9 ttl=245 time=85.8 ms
64 bytes from www.google.com (209.85.135.147): icmp_seq=10 ttl=245 time=89.0 ms
64 bytes from www.google.com (209.85.135.147): icmp_seq=11 ttl=245 time=88.5 ms
64 bytes from www.google.com (209.85.135.147): icmp_seq=12 ttl=245 time=89.5 ms
64 bytes from www.google.com (209.85.135.147): icmp_seq=13 ttl=245 time=87.0 ms
64 bytes from www.google.com (209.85.135.147): icmp_seq=14 ttl=245 time=87.1 ms
64 bytes from www.google.com (209.85.135.147): icmp_seq=15 ttl=245 time=89.1 ms
64 bytes from www.google.com (209.85.135.147): icmp_seq=16 ttl=245 time=89.0 ms
64 bytes from www.google.com (209.85.135.147): icmp_seq=17 ttl=245 time=87.0 ms
64 bytes from www.google.com (209.85.135.147): icmp_seq=25 ttl=245 time=87.8 ms
64 bytes from www.google.com (209.85.135.147): icmp_seq=26 ttl=245 time=89.2 ms
64 bytes from www.google.com (209.85.135.147): icmp_seq=27 ttl=245 time=87.2 ms
64 bytes from www.google.com (209.85.135.147): icmp_seq=28 ttl=245 time=89.0 ms
64 bytes from www.google.com (209.85.135.147): icmp_seq=29 ttl=245 time=85.9 ms
64 bytes from www.google.com (209.85.135.147): icmp_seq=30 ttl=245 time=86.9 ms
64 bytes from www.google.com (209.85.135.147): icmp_seq=31 ttl=245 time=87.8 ms
64 bytes from www.google.com (209.85.135.147): icmp_seq=32 ttl=245 time=87.3 ms
64 bytes from www.google.com (209.85.135.147): icmp_seq=33 ttl=245 time=86.8 ms
64 bytes from www.google.com (209.85.135.147): icmp_seq=34 ttl=245 time=87.2 ms
64 bytes from www.google.com (209.85.135.147): icmp_seq=35 ttl=245 time=89.1 ms
64 bytes from www.google.com (209.85.135.147): icmp_seq=36 ttl=245 time=88.2 ms
64 bytes from www.google.com (209.85.135.147): icmp_seq=37 ttl=245 time=87.6 ms
64 bytes from www.google.com (209.85.135.147): icmp_seq=38 ttl=245 time=87.1 ms
64 bytes from www.google.com (209.85.135.147): icmp_seq=39 ttl=245 time=88.6 ms
64 bytes from www.google.com (209.85.135.147): icmp_seq=40 ttl=245 time=87.6 ms
64 bytes from www.google.com (209.85.135.147): icmp_seq=41 ttl=245 time=86.6 ms
64 bytes from www.google.com (209.85.135.147): icmp_seq=42 ttl=245 time=87.7 ms
64 bytes from www.google.com (209.85.135.147): icmp_seq=43 ttl=245 time=87.7 ms
64 bytes from www.google.com (209.85.135.147): icmp_seq=44 ttl=245 time=87.8 ms
64 bytes from www.google.com (209.85.135.147): icmp_seq=45 ttl=245 time=86.3 ms
64 bytes from www.google.com (209.85.135.147): icmp_seq=46 ttl=245 time=86.4 ms
64 bytes from www.google.com (209.85.135.147): icmp_seq=47 ttl=245 time=88.4 ms
64 bytes from www.google.com (209.85.135.147): icmp_seq=55 ttl=245 time=87.7 ms
64 bytes from www.google.com (209.85.135.147): icmp_seq=56 ttl=245 time=88.4 ms
64 bytes from www.google.com (209.85.135.147): icmp_seq=57 ttl=245 time=87.5 ms
64 bytes from www.google.com (209.85.135.147): icmp_seq=58 ttl=245 time=87.0 ms
64 bytes from www.google.com (209.85.135.147): icmp_seq=59 ttl=245 time=87.6 ms
64 bytes from www.google.com (209.85.135.147): icmp_seq=60 ttl=245 time=87.1 ms
64 bytes from www.google.com (209.85.135.147): icmp_seq=61 ttl=245 time=88.1 ms
64 bytes from www.google.com (209.85.135.147): icmp_seq=62 ttl=245 time=89.7 ms
64 bytes from www.google.com (209.85.135.147): icmp_seq=63 ttl=245 time=87.1 ms
^C
--- www.google.com ping statistics ---
63 packets transmitted, 49 received, 22% packet loss, time 62140ms
rtt min/avg/max/mdev = 85.770/87.752/89.720/1.068 ms
maxim@MOBILE:~$

and here:

ping www.google.com
PING www.l.google.com (209.85.129.99) 56(84) bytes of data.
64 bytes from www.google.com (209.85.129.99): icmp_seq=1 ttl=246 time=82.5 ms
64 bytes from www.google.com (209.85.129.99): icmp_seq=9 ttl=246 time=79.6 ms
64 bytes from www.google.com (209.85.129.99): icmp_seq=10 ttl=246 time=83.0 ms
64 bytes from www.google.com (209.85.129.99): icmp_seq=11 ttl=246 time=82.6 ms
64 bytes from www.google.com (209.85.129.99): icmp_seq=12 ttl=246 time=82.0 ms
64 bytes from www.google.com (209.85.129.99): icmp_seq=13 ttl=246 time=82.1 ms
64 bytes from www.google.com (209.85.129.99): icmp_seq=14 ttl=246 time=81.9 ms
64 bytes from www.google.com (209.85.129.99): icmp_seq=15 ttl=246 time=81.4 ms
64 bytes from www.google.com (209.85.129.99): icmp_seq=16 ttl=246 time=82.0 ms
64 bytes from www.google.com (209.85.129.99): icmp_seq=17 ttl=246 time=80.9 ms
64 bytes from www.google.com (209.85.129.99): icmp_seq=18 ttl=246 time=80.9 ms
64 bytes from www.google.com (209.85.129.99): icmp_seq=19 ttl=246 time=80.5 ms
64 bytes from www.google.com (209.85.129.99): icmp_seq=20 ttl=246 time=81.5 ms
64 bytes from www.google.com (209.85.129.99): icmp_seq=21 ttl=246 time=80.5 ms
64 bytes from www.google.com (209.85.129.99): icmp_seq=22 ttl=246 time=80.1 ms
64 bytes from www.google.com (209.85.129.99): icmp_seq=23 ttl=246 time=82.5 ms
64 bytes from www.google.com (209.85.129.99): icmp_seq=24 ttl=246 time=82.0 ms
64 bytes from www.google.com (209.85.129.99): icmp_seq=25 ttl=246 time=82.0 ms
64 bytes from www.google.com (209.85.129.99): icmp_seq=26 ttl=246 time=81.0 ms
64 bytes from www.google.com (209.85.129.99): icmp_seq=27 ttl=246 time=81.5 ms
64 bytes from www.google.com (209.85.129.99): icmp_seq=28 ttl=246 time=81.0 ms
64 bytes from www.google.com (209.85.129.99): icmp_seq=29 ttl=246 time=80.0 ms
64 bytes from www.google.com (209.85.129.99): icmp_seq=30 ttl=246 time=80.0 ms
64 bytes from www.google.com (209.85.129.99): icmp_seq=31 ttl=246 time=80.0 ms
64 bytes from www.google.com (209.85.129.99): icmp_seq=39 ttl=246 time=82.8 ms
64 bytes from www.google.com (209.85.129.99): icmp_seq=40 ttl=246 time=82.3 ms
64 bytes from www.google.com (209.85.129.99): icmp_seq=41 ttl=246 time=81.3 ms
64 bytes from www.google.com (209.85.129.99): icmp_seq=42 ttl=246 time=81.8 ms
^C
--- www.l.google.com ping statistics ---
42 packets transmitted, 28 received, 33% packet loss, time 41109ms
rtt min/avg/max/mdev = 79.627/81.461/83.079/0.961 ms
maxim@MOBILE:~$


> 
> 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.
> 
Don't see that now, but sudo iwlist wlan0 scan shows only my access point,
although there are two another strong access points.

Best regards,
	Maxim levitsky

> 
> Best regards,
>     Maxim Levitsky
> 

Re: [ipw3945-devel] [BUG] iwlwifi 3945 works only with disable_hw_scan=1

[Maxim Levitsky]

Maxim Levitsky wrote:
> .....
>>
>> 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.
> 
> Rebooted, and here it is:
> 
> maxim@MOBILE:~$ ping www.google.com
> PING www.google.com (209.85.135.147) 56(84) bytes of data.
> 64 bytes from www.google.com (209.85.135.147): icmp_seq=1 ttl=245 
> time=89.0 ms
> 64 bytes from www.google.com (209.85.135.147): icmp_seq=2 ttl=245 
> time=89.2 ms
> 64 bytes from www.google.com (209.85.135.147): icmp_seq=3 ttl=245 
> time=87.2 ms
> 64 bytes from www.google.com (209.85.135.147): icmp_seq=4 ttl=245 
> time=87.0 ms
> 64 bytes from www.google.com (209.85.135.147): icmp_seq=5 ttl=245 
> time=85.7 ms
> 64 bytes from www.google.com (209.85.135.147): icmp_seq=6 ttl=245 
> time=88.2 ms
> 64 bytes from www.google.com (209.85.135.147): icmp_seq=7 ttl=245 
> time=88.2 ms
> 64 bytes from www.google.com (209.85.135.147): icmp_seq=8 ttl=245 
> time=86.7 ms
> 64 bytes from www.google.com (209.85.135.147): icmp_seq=9 ttl=245 
> time=85.8 ms
> 64 bytes from www.google.com (209.85.135.147): icmp_seq=10 ttl=245 
> time=89.0 ms
> 64 bytes from www.google.com (209.85.135.147): icmp_seq=11 ttl=245 
> time=88.5 ms
> 64 bytes from www.google.com (209.85.135.147): icmp_seq=12 ttl=245 
> time=89.5 ms
> 64 bytes from www.google.com (209.85.135.147): icmp_seq=13 ttl=245 
> time=87.0 ms
> 64 bytes from www.google.com (209.85.135.147): icmp_seq=14 ttl=245 
> time=87.1 ms
> 64 bytes from www.google.com (209.85.135.147): icmp_seq=15 ttl=245 
> time=89.1 ms
> 64 bytes from www.google.com (209.85.135.147): icmp_seq=16 ttl=245 
> time=89.0 ms
> 64 bytes from www.google.com (209.85.135.147): icmp_seq=17 ttl=245 
> time=87.0 ms
> 64 bytes from www.google.com (209.85.135.147): icmp_seq=25 ttl=245 
> time=87.8 ms
> 64 bytes from www.google.com (209.85.135.147): icmp_seq=26 ttl=245 
> time=89.2 ms
> 64 bytes from www.google.com (209.85.135.147): icmp_seq=27 ttl=245 
> time=87.2 ms
> 64 bytes from www.google.com (209.85.135.147): icmp_seq=28 ttl=245 
> time=89.0 ms
> 64 bytes from www.google.com (209.85.135.147): icmp_seq=29 ttl=245 
> time=85.9 ms
> 64 bytes from www.google.com (209.85.135.147): icmp_seq=30 ttl=245 
> time=86.9 ms
> 64 bytes from www.google.com (209.85.135.147): icmp_seq=31 ttl=245 
> time=87.8 ms
> 64 bytes from www.google.com (209.85.135.147): icmp_seq=32 ttl=245 
> time=87.3 ms
> 64 bytes from www.google.com (209.85.135.147): icmp_seq=33 ttl=245 
> time=86.8 ms
> 64 bytes from www.google.com (209.85.135.147): icmp_seq=34 ttl=245 
> time=87.2 ms
> 64 bytes from www.google.com (209.85.135.147): icmp_seq=35 ttl=245 
> time=89.1 ms
> 64 bytes from www.google.com (209.85.135.147): icmp_seq=36 ttl=245 
> time=88.2 ms
> 64 bytes from www.google.com (209.85.135.147): icmp_seq=37 ttl=245 
> time=87.6 ms
> 64 bytes from www.google.com (209.85.135.147): icmp_seq=38 ttl=245 
> time=87.1 ms
> 64 bytes from www.google.com (209.85.135.147): icmp_seq=39 ttl=245 
> time=88.6 ms
> 64 bytes from www.google.com (209.85.135.147): icmp_seq=40 ttl=245 
> time=87.6 ms
> 64 bytes from www.google.com (209.85.135.147): icmp_seq=41 ttl=245 
> time=86.6 ms
> 64 bytes from www.google.com (209.85.135.147): icmp_seq=42 ttl=245 
> time=87.7 ms
> 64 bytes from www.google.com (209.85.135.147): icmp_seq=43 ttl=245 
> time=87.7 ms
> 64 bytes from www.google.com (209.85.135.147): icmp_seq=44 ttl=245 
> time=87.8 ms
> 64 bytes from www.google.com (209.85.135.147): icmp_seq=45 ttl=245 
> time=86.3 ms
> 64 bytes from www.google.com (209.85.135.147): icmp_seq=46 ttl=245 
> time=86.4 ms
> 64 bytes from www.google.com (209.85.135.147): icmp_seq=47 ttl=245 
> time=88.4 ms
> 64 bytes from www.google.com (209.85.135.147): icmp_seq=55 ttl=245 
> time=87.7 ms
> 64 bytes from www.google.com (209.85.135.147): icmp_seq=56 ttl=245 
> time=88.4 ms
> 64 bytes from www.google.com (209.85.135.147): icmp_seq=57 ttl=245 
> time=87.5 ms
> 64 bytes from www.google.com (209.85.135.147): icmp_seq=58 ttl=245 
> time=87.0 ms
> 64 bytes from www.google.com (209.85.135.147): icmp_seq=59 ttl=245 
> time=87.6 ms
> 64 bytes from www.google.com (209.85.135.147): icmp_seq=60 ttl=245 
> time=87.1 ms
> 64 bytes from www.google.com (209.85.135.147): icmp_seq=61 ttl=245 
> time=88.1 ms
> 64 bytes from www.google.com (209.85.135.147): icmp_seq=62 ttl=245 
> time=89.7 ms
> 64 bytes from www.google.com (209.85.135.147): icmp_seq=63 ttl=245 
> time=87.1 ms
> ^C
> --- www.google.com ping statistics ---
> 63 packets transmitted, 49 received, 22% packet loss, time 62140ms
> rtt min/avg/max/mdev = 85.770/87.752/89.720/1.068 ms
> maxim@MOBILE:~$
> 
> and here:
> 
> ping www.google.com
> PING www.l.google.com (209.85.129.99) 56(84) bytes of data.
> 64 bytes from www.google.com (209.85.129.99): icmp_seq=1 ttl=246 
> time=82.5 ms
> 64 bytes from www.google.com (209.85.129.99): icmp_seq=9 ttl=246 
> time=79.6 ms
> 64 bytes from www.google.com (209.85.129.99): icmp_seq=10 ttl=246 
> time=83.0 ms
> 64 bytes from www.google.com (209.85.129.99): icmp_seq=11 ttl=246 
> time=82.6 ms
> 64 bytes from www.google.com (209.85.129.99): icmp_seq=12 ttl=246 
> time=82.0 ms
> 64 bytes from www.google.com (209.85.129.99): icmp_seq=13 ttl=246 
> time=82.1 ms
> 64 bytes from www.google.com (209.85.129.99): icmp_seq=14 ttl=246 
> time=81.9 ms
> 64 bytes from www.google.com (209.85.129.99): icmp_seq=15 ttl=246 
> time=81.4 ms
> 64 bytes from www.google.com (209.85.129.99): icmp_seq=16 ttl=246 
> time=82.0 ms
> 64 bytes from www.google.com (209.85.129.99): icmp_seq=17 ttl=246 
> time=80.9 ms
> 64 bytes from www.google.com (209.85.129.99): icmp_seq=18 ttl=246 
> time=80.9 ms
> 64 bytes from www.google.com (209.85.129.99): icmp_seq=19 ttl=246 
> time=80.5 ms
> 64 bytes from www.google.com (209.85.129.99): icmp_seq=20 ttl=246 
> time=81.5 ms
> 64 bytes from www.google.com (209.85.129.99): icmp_seq=21 ttl=246 
> time=80.5 ms
> 64 bytes from www.google.com (209.85.129.99): icmp_seq=22 ttl=246 
> time=80.1 ms
> 64 bytes from www.google.com (209.85.129.99): icmp_seq=23 ttl=246 
> time=82.5 ms
> 64 bytes from www.google.com (209.85.129.99): icmp_seq=24 ttl=246 
> time=82.0 ms
> 64 bytes from www.google.com (209.85.129.99): icmp_seq=25 ttl=246 
> time=82.0 ms
> 64 bytes from www.google.com (209.85.129.99): icmp_seq=26 ttl=246 
> time=81.0 ms
> 64 bytes from www.google.com (209.85.129.99): icmp_seq=27 ttl=246 
> time=81.5 ms
> 64 bytes from www.google.com (209.85.129.99): icmp_seq=28 ttl=246 
> time=81.0 ms
> 64 bytes from www.google.com (209.85.129.99): icmp_seq=29 ttl=246 
> time=80.0 ms
> 64 bytes from www.google.com (209.85.129.99): icmp_seq=30 ttl=246 
> time=80.0 ms
> 64 bytes from www.google.com (209.85.129.99): icmp_seq=31 ttl=246 
> time=80.0 ms
> 64 bytes from www.google.com (209.85.129.99): icmp_seq=39 ttl=246 
> time=82.8 ms
> 64 bytes from www.google.com (209.85.129.99): icmp_seq=40 ttl=246 
> time=82.3 ms
> 64 bytes from www.google.com (209.85.129.99): icmp_seq=41 ttl=246 
> time=81.3 ms
> 64 bytes from www.google.com (209.85.129.99): icmp_seq=42 ttl=246 
> time=81.8 ms
> ^C
> --- www.l.google.com ping statistics ---
> 42 packets transmitted, 28 received, 33% packet loss, time 41109ms
> rtt min/avg/max/mdev = 79.627/81.461/83.079/0.961 ms
> maxim@MOBILE:~$
> 
> 
>>
>> 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.
Just reproduced this with following commands;
(I was playing with packet injection, I use recently posted patch for that)

ifconfig wlan0 down
iwconfig wlan0 mode monitor
ifconfig wlan0 up

aireplay-ng --test wlan0

ifconfig wlan0 down
iwconfig wlan0 mode managed

Then I disable/enable wireless in nm-applet, and get something funny:

wlan0     Scan completed :
           Cell 01 - Address: 00:1B:9E:D8:77:02
                     ESSID:"MAXIM-HOME"
                     Mode:Master
                     Channel:1
                     Frequency:2.412 GHz (Channel 1)
                     Quality=234/100  Signal level:-82 dBm  Noise level=-28 dBm
                     Encryption key:on
                     IE: IEEE 802.11i/WPA2 Version 1
                         Group Cipher : CCMP
                         Pairwise Ciphers (1) : CCMP
                         Authentication Suites (1) : PSK
                     Bit Rates:1 Mb/s; 2 Mb/s; 5.5 Mb/s; 11 Mb/s; 18 Mb/s
                               24 Mb/s; 36 Mb/s; 54 Mb/s; 6 Mb/s; 9 Mb/s
                               12 Mb/s; 48 Mb/s
                     Extra:tsf=0000000935df8c51
           Cell 02 - Address: 00:1A:70:7B:6A:52
                     ESSID:"basinm"
                     Mode:Master
                     Channel:6
                     Frequency:2.437 GHz (Channel 6)
                     Quality=144/100  Signal level:-82 dBm  Noise level=-28 dBm
                     Encryption key:on
                     IE: WPA Version 1
                         Group Cipher : CCMP
                         Pairwise Ciphers (1) : CCMP
                         Authentication Suites (1) : PSK
                     Bit Rates:1 Mb/s; 2 Mb/s; 5.5 Mb/s; 11 Mb/s; 18 Mb/s
                               24 Mb/s; 36 Mb/s; 54 Mb/s; 6 Mb/s; 9 Mb/s
                               12 Mb/s; 48 Mb/s
                     Extra:tsf=000000330e1bb608
           Cell 03 - Address: 00:0E:2E:F7:A0:3E
                     ESSID:"Home"
                     Mode:Master
                     Channel:11
                     Frequency:2.462 GHz (Channel 11)
                     Quality=188/100  Signal level:-82 dBm  Noise level=-28 dBm
                     Encryption key:off
                     Bit Rates:1 Mb/s; 2 Mb/s; 5.5 Mb/s; 11 Mb/s; 6 Mb/s
                               9 Mb/s; 12 Mb/s; 18 Mb/s; 24 Mb/s; 36 Mb/s
                               48 Mb/s; 54 Mb/s
                     Extra:tsf=000002df7cea679c

MAXIM-HOME is my access point.

Best regards,
	Maxim Levitsky

>>
> Don't see that now, but sudo iwlist wlan0 scan shows only my access point,
> although there are two another strong access points.
> 
> Best regards,
>     Maxim levitsky
> 
>>
>> Best regards,
>>     Maxim Levitsky
>>
> 

Re: [ipw3945-devel] [BUG] iwlwifi 3945 works only with disable_hw_scan=1

[Dan Williams]

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@gmai=
l.com> wrote:
> >> Tomas Winkler wrote:
> >>> On Sun, Jun 15, 2008 at 6:09 PM, Tomas Winkler <tomasw@gmail.com>=
 wrote:
> >>>> On Sun, Jun 15, 2008 at 5:12 PM, Maxim Levitsky <maximlevitsky@g=
mail.com>
> >>>> wrote:
> >>>>> Tomas Winkler wrote:
> >>>>>> On Sun, Jun 15, 2008 at 4:42 PM, Maxim Levitsky
> >>>>>> <maximlevitsky@gmail.com>
> >>>>>> wrote:
> >>>>>>> Tomas Winkler wrote:
> >>>>>>>> On Fri, Jun 13, 2008 at 6:06 PM, Maxim Levitsky
> >>>>>>>> <maximlevitsky@gmail.com>
> >>>>>>>> wrote:
> >>>>>>>>> Tor H=C3=A5kon 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 wrot=
e:
> >>>>>>>>>>>>> Honestly I'm tempted to change it to "enable_hw_scan" i=
nstead...
> >>>>>>>>>>>> Give the advantages, I'd like to use it if we can fix th=
e 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 49=
65,
> >>>>>>>>>>>> right?
> >>>>>>>>>>> AFAICT only the 3945 seems to need it.
> >>>>>>>>>>>
> >>>>>>>>>> I can confirm that this also applies to 4965 as a friend o=
f mine
> >>>>>>>>>> has
> >>>>>>>>>> this card. According to him the card works a lot better wi=
th the
> >>>>>>>>>> parameters "swcrypto=3D1" and "disable_hw_scan=3D1".
> >>>>>>>>> Just to make it clear,
> >>>>>>>>> iwl3945 doesn't work at all without disable_hw_scan=3D1 her=
e.
> >>>>>>>>> The driver just shuts down thee card since it detects micro=
code
> >>>>>>>>> error.
> >>>>>>>>>
> >>>>>>>> It looks like this is all caused by the big rate, band patch=
=2E Looks
> >>>>>>>> like A band scan channels are not configured correctly for t=
he
> >>>>>>>> scanning. This crashes the firmware.
> >>>>>>>>
> >>>>>>>> Tomas
> >>>>>>> Probably, I see that eeprom according to dmesg contains no in=
fo 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=3D1?)
> >>>>>
> >>>>> If not what debug options I should include
> >>>>> (I tried same firmware debug options, but the log wrapped aroun=
d.)
> >>>>>
> >>>>> dmesg without disable_hw_scan=3D1 attached.
> >>>>>
> >>>>>
> >>>>>>> I have few questions:
> >>>>>>>
> >>>>>>> * Is there a software workaround without the need to update t=
he
> >>>>>>> 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 f=
ix it.
> >>>> Intel is fixing bugs in the firmware. Still this doesn't look li=
ke 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 =3D 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 patc=
h.
> > Tomas
>=20
> Thanks to you too.
>=20
> I just want to note that hardware scanning doesn't work well here=20
> (something unrelated)
>=20
> First of all I noticed large delays in communications occurring=20
> sometimes, I for example tried pinging Google, and every 20 replies
> I get about 10 lost packets. (this is exactly what hardware scanning=20
> should prevent, but it seems that the opposite happens)
>=20
> I tried that again now, and see no delays, but I reproduced this twic=
e.
>=20
> Then power levels go crazy, the nm-applet shows that my access point=20
> have 23% quality, then 100%, then something low again, and looking li=
st=20
> of networks withing same applet, it shows for example now that all 3=20
> networks (mine, and two neighbors) have 100% quality, which is just w=
rong.

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 avoi=
d
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 o=
n
the same channel as the AP.

dan


--
To unsubscribe from this list: send the line "unsubscribe linux-wireles=
s" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [ipw3945-devel] [BUG] iwlwifi 3945 works only with disable_hw_scan=1

[Tomas Winkler]

On Mon, Jun 16, 2008 at 5:35 PM, Dan Williams <dcbw@redhat.com> 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@gma=
il.com> wrote:
>> >> Tomas Winkler wrote:
>> >>> On Sun, Jun 15, 2008 at 6:09 PM, Tomas Winkler <tomasw@gmail.com=
> wrote:
>> >>>> On Sun, Jun 15, 2008 at 5:12 PM, Maxim Levitsky <maximlevitsky@=
gmail.com>
>> >>>> wrote:
>> >>>>> Tomas Winkler wrote:
>> >>>>>> On Sun, Jun 15, 2008 at 4:42 PM, Maxim Levitsky
>> >>>>>> <maximlevitsky@gmail.com>
>> >>>>>> wrote:
>> >>>>>>> Tomas Winkler wrote:
>> >>>>>>>> On Fri, Jun 13, 2008 at 6:06 PM, Maxim Levitsky
>> >>>>>>>> <maximlevitsky@gmail.com>
>> >>>>>>>> wrote:
>> >>>>>>>>> Tor H=E5kon 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 wro=
te:
>> >>>>>>>>>>>>> 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 t=
he bug (I
>> >>>>>>>>>>>> haven't
>> >>>>>>>>>>>> seen what the bug is myself). But you are free to chang=
e the
>> >>>>>>>>>>>> default
>> >>>>>>>>>>>> value until it is fixed. There is no such problem for 4=
965,
>> >>>>>>>>>>>> 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 w=
ith the
>> >>>>>>>>>> parameters "swcrypto=3D1" and "disable_hw_scan=3D1".
>> >>>>>>>>> Just to make it clear,
>> >>>>>>>>> iwl3945 doesn't work at all without disable_hw_scan=3D1 he=
re.
>> >>>>>>>>> The driver just shuts down thee card since it detects micr=
ocode
>> >>>>>>>>> error.
>> >>>>>>>>>
>> >>>>>>>> It looks like this is all caused by the big rate, band patc=
h. 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 i=
nfo 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=3D1?)
>> >>>>>
>> >>>>> If not what debug options I should include
>> >>>>> (I tried same firmware debug options, but the log wrapped arou=
nd.)
>> >>>>>
>> >>>>> dmesg without disable_hw_scan=3D1 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, i=
t 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 l=
ike 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 =3D 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 pat=
ch.
>> > 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 twi=
ce.
>>
>> Then power levels go crazy, the nm-applet shows that my access point
>> have 23% quality, then 100%, then something low again, and looking l=
ist
>> 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 caus=
e
> _lost_ pings, since the driver and the AP need to work together to av=
oid
> dropping packets when the card isn't on the same channel as the AP is=
=2E
> 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-wireles=
s" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [ipw3945-devel] [BUG] iwlwifi 3945 works only with disable_hw_scan=1

[drago01]

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

seems like a fix thats worth having in .26

Re: [ipw3945-devel] [BUG] iwlwifi 3945 works only with disable_hw_scan=1

[John W. Linville]

On Wed, Jun 18, 2008 at 10:28:04AM +0200, drago01 wrote:
> >>> 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.
> 
> seems like a fix thats worth having in .26

Did I miss the official post of this patch?

John
-- 
John W. Linville
linville@tuxdriver.com

Re: [ipw3945-devel] [BUG] iwlwifi 3945 works only with disable_hw_scan=1

[Maxim Levitsky]

John W. Linville wrote:
> On Wed, Jun 18, 2008 at 10:28:04AM +0200, drago01 wrote:
>>>>> 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.
>> seems like a fix thats worth having in .26
> 
> Did I miss the official post of this patch?
> 
> John

I think patch wasn't posted, but it is committed to wireless tree
commit 085fa962fdeb09b17b8052f5f1da353949829e9d
iwlwifi: improve scanning band selection management


Best regards,
	Maxim Levitsky

PS: take a look at my bugreport about monitor mode, any ideas?

Re: [ipw3945-devel] [BUG] iwlwifi 3945 works only with disable_hw_scan=1

[Tomas Winkler]

On Tue, Jun 24, 2008 at 10:47 PM, John W. Linville
<linville@tuxdriver.com> wrote:
> On Wed, Jun 18, 2008 at 10:28:04AM +0200, drago01 wrote:
>> >>> 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.
>>
>> seems like a fix thats worth having in .26
>
> Did I miss the official post of this patch?
>
> John

It's queued in Yi's tree.
Tomas.