Bug 654599

Possibly similar to bug 653437.  I'm seeing slow connection speeds too, when I manage to connect.

What is AP here? I think I will buy a new one to reproduce that problem, because I'm not seeing it on my T60 laptop (I tried with 4 different AP WRT160NL, WRT610N V1, Sitecom WL-161 and some Enterprise Cisco AP that we have in the office).

I have Linksys Wireless-G model WAG200G AP.

Could you install packages form and see if they help:
http://people.redhat.com/sgruszka/compact_wireless.html

Nothing change installing the experimental compact_wireless package. So I have a new notice.

I trying to uninstall all other intel wireless firmware packages except the iwl3945-firmware.noarch and, at reboot, wireless connection was incredible fast, better than windows.
The bad notice is when I rebooted again the problem here again. I tryed to reboot more times but nothing.

I have WAG200G on my desk. Things do not work. However here wireless module on AP just hung after a while, AP is not able to respond probe request and NM disconnects. Performance at the beginning of connection is quite good, then it degradate and stay at that level some time before full disconnect.

SilvioTO please provide wireless settings and firmware version of AP, to make sure I get similar environment locally.

Hi Stanislaw, here's more detailed information about my AP:

Model: Wireless-G ADSL Home Gateway - WAG200G 
Firmware Version: 1.01.04

Basic Wireless Settings
Wireless Network Mode: Mixed
Wireless Network Name (SSID): MyHome
Wireless Channel: 11 - 2.462 GHz
Wireless SSID Broadcast: Enabled

Wireless Security
Security Mode: WPA-Personal
Passphrase: XXXXX
Group Key Renewal: 3600 seconds

Wireless Access
Allow All

Advanced Wireless Settings
Authentication Type: Auto
Control TX Rate: Auto
Beacon Interval: 100
DTIM Interval: 1
Fragmentation Threshold: 2346
RTS Threshold: 2347

------------------------

I notice you I tryed to connect with AP Atlantis Land Webshare 141W and have the same problem.
If you need more information ask me.

I configure the device according to your config. The only difference that I have WPA2-Personal encryption. Now I can not observe the AP crash. Performance of data copied between two local wireless devices iwl3945 and rt73usb is about 1Mbyte/s, not so good but also not so tragic like you have.

I wonder where the difference can be. I'm not using ADSL connection so perhaps this make a difference, could you check performance without ADSL line pluged in?
Also which version of fedora kernel do you use? Also I have 1.01.05 firmware whereas you have 1.01.04, could you update firmware (on the website there is 1.01.09 for Annex A and 1.01.06 for Annex B, I will update too).

Sorry but I do not have 2 wireless devices to try.
I use the kernel 2.6.35.9-64.fc14.i686.
Upgrading the firmware of AP to 1.01.09 I have the same problem.
http://www.speedtest.net/result/1072147825.png

Please attach dmesg command output.

... after reproduce the problem.

Please say me the exactly complete command row, thanks.

I'm not sure if I understand what you mean by "command row". If you asking about command it is:

$ dmesg > dmesg.txt

and attach dmesg.txt. If you asking about which rows in text, everything from iwl3945 driver load starting by line "iwl3945: Intel(R) PRO/Wireless 3945ABG/BG Network Connection driver for Linux" is interesting.

Created attachment 470977 [details]
dmesg after few minutes download

here's the output of command "dmesg > dmesg.txt"
I executed the command after (not while downloading) few minutes of file download from here: ftp://debian.fastbull.org/debian-cd/5.0.7/i386/iso-dvd/

https://bugs.launchpad.net/ubuntu/+source/linux/+bug/621265?comments=all

We are investigating similar problem there.

@SilvioTO: dmesg seems fine.

@Stanislaw: Decrease of speed is not immediate. It can happen after some time.

@ Radosław: nice to see that I'm not alone! ;)
Good luck guys, I cross fingers and hope this bug will solve soon.

Yep, problem was reported in a few places
http://marc.info/?l=linux-wireless&m=128882603709125&w=2 .
Intel is aware of it for some time now, but do not provide the fix yet.

> @Stanislaw: Decrease of speed is not immediate. It can happen after some time.

Ok, I will keep trying to reproduce. I will also prepare some patches to test since problem is much more reproducible for you guys.

Ok, please also read our comments on launchpad.

Radosław, since you can compile kernel from source, could you test two patches I'll attach?

Re: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/621265/comments/147
I agree this bug can be triggered only with particular companying software (wpa_supplicant, NetworkManager), but also kernel config is important. Could you try to compile and install vanilla 2.6.35.10 kernel with gentoo config on ubuntu, and see if problem is still reproducible there.

Created attachment 471178 [details]
0001-iwl3945-revert-disable_tx_power_cal.patch

Created attachment 471179 [details]
0002-iwl3945-remove-check_plcp_health.patch

Ok, I'll try these.

Sorry for not replying for so long.
I've been busy.

I'm compiling my Gentoo's config on Mint now.

Ok, I've tried Gentoo's config but Ubuntu/Mint seems to need some special config which I don't know so the system can't boot :/

Re comment 25:
> I've been busy.
Fully understand.

Also couple of additional questions:

Does by accident helps when disabling iptables ?

What show "lspci -nn | grep Wireless" ? (I think I may have different revision of device, and that's the reason I'm unable to reproduce)

One more thing, any info about patches from comment 22 and 23?

04:00.0 Network controller [0280]: Intel Corporation PRO/Wireless 3945ABG [Golan] Network Connection [8086:4222] (rev 02)

---

IPtables' chains are by default empty.

---

I didn't have time to test them. Recompilation takes a rather long time.

Ah, ok. Perhaps SilvioTO can test them, here patched kernel koji build:
http://koji.fedoraproject.org/koji/taskinfo?taskID=2718789
please test when it finish to compile.

(In reply to comment #27)
> What show "lspci -nn | grep Wireless" ? (I think I may have different revision
> of device, and that's the reason I'm unable to reproduce)

Opps sorry, "lspci -nn" does not show SUBDEVICE value which may be important here. I rather would like to know "lspci -vnn | grep -A 1 Wireless" output (from both of you:).

Created attachment 473406 [details]
full listing from "lspci -vvvnn"

I have attached this full listing from "lspci -vvvnn". It contains everything except the MAC Address part. Enjoy!

I would like to test the patched kernel but I'm not expert like you, please tell me where I can download the i686 version and instruction to install (as well as normal rpm package?).
Thanks a lot.

From koji task page (link in comment 30) you have to click on i686 descendent task link:

    * buildArch (kernel-2.6.35.10-77.bz654599.fc14.src.rpm, i686)

then on the bottom of the page there are different versions of kernel packages. You can pick up the same one that "uname -r" command shows, or different one, for example kernel-debug .

Anyway here is direct link to download for standard i686 kernel:
> http://koji.fedoraproject.org/koji/getfile?taskID=2718792&name=kernel-2.6.35.10-77.bz654599.fc14.i686.rpm

Then install by command (as root):
$ rpm -ivh kernel-2.6.35.10-77.bz654599.fc14.i686.rpm

Then you have to restart system and chose that kernel in grub menu at boot (If menu does not show up, modify "timeout=" in /boot/grub/grub.conf)

And BTW, please also show me "lspci -vnn | grep -A 1 Wireless" command output.

All clear, I'll try as soon as possibile :-)

I have applied the 1st patch on Ubuntu sources with no luck - problem persists.
I will try the 2nd patch later today.

After applying the 2nd patch things seem to got even worse :(
Speed decreases immediately.

@Stanislaw: Have you found anything interesting in lspci's output? Do you have any idea what I should do now?

(In reply to comment #38)
> @Stanislaw: Have you found anything interesting in lspci's output?'

I wanted to now lspci to find exact the same device here in RH, I think bug is only reproducible on some types of 3945 devices. On my 3945 laptop I can not reproduce, similarly like user from https://bugs.launchpad.net/ubuntu/+source/linux/+bug/621265/comments/171

> Do you have any idea what I should do now?

The best thing you could do is bisect. However bisection can be hard and tricky, I described how to do this here https://bugzilla.redhat.com/show_bug.cgi?id=640612#c37

But first I will give you some more patches to test. Note: you don't have recompile whole kernel, if you have kernel complied. After apply a patch make will only compile new changes.

Created attachment 473809 [details]
0001-iwl3945-do-not-use-agn-specific-IWL_RATE_MASK.patch

Created attachment 473812 [details]
iwlwifi-mac80211-revert-QoS-changes.patch

Above patches are pretty much shots in the dark, but maybe ...

Note: .34 to .35 iwlwifi update is huge [ 48 files changed, 9091 insertions(+), 7358 deletions(-) ], so it's pretty hard to find where the problem is. Moreover, problem can be caused not by driver but by wireless stack or generic network stack. So bisection is the best way for solving bug, because that way we check driver and stack, I would do this by myself if I could reproduce.

(In reply to comment #39)
> But first I will give you some more patches to test. Note: you don't have
> recompile whole kernel, if you have kernel complied. After apply a patch make
> will only compile new changes.

I wish it was a simple make...

I will try these patches later today. I will try bisection if they don't help.

(In reply to comment #42)
> Moreover, problem can be caused not by driver but by wireless stack or generic
> network stack. So bisection is the best way for solving bug, because that way
> we check driver and stack, I would do this by myself if I could reproduce.

https://bugs.launchpad.net/ubuntu/maverick/+source/linux/+bug/621265/comments/126
https://bugs.launchpad.net/ubuntu/maverick/+source/linux/+bug/621265/comments/141
https://bugs.launchpad.net/ubuntu/maverick/+source/linux/+bug/621265/comments/142

^ After these I thought about the same what you say but as I am not that much experienced in playing with kernel I did not try more.

(In reply to comment #43)
> I wish it was a simple make...
? Once kernel is configured "make" it's enough to compile,  "make modules_install && make install" should be enough to install compiled kernel. If you would bisect, you should optimise kernel compilation work, as you will need repeat it many times.

> I will try these patches later today. I will try bisection if they don't help.
Thanks!
 
> (In reply to comment #42)
> https://bugs.launchpad.net/ubuntu/maverick/+source/linux/+bug/621265/comments/126
> ^ After these I thought about the same what you say but as I am not that much
> experienced in playing with kernel I did not try

If problem really happens between rc2 and rc3, these are suspicious commit:
> [linux-2.6]$ git log --pretty=oneline --no-merges v2.6.35-rc2..v2.6.35-rc3 -- drivers/net/wireless/iwlwifi/ net/
> 07a0f0f07a68014c92c752a5598102372bddf46e pktgen: Fix accuracy of inter-packet delay.
> ae638c47dc040b8def16d05dc6acdd527628f231 pkt_sched: gen_estimator: add a new lock
> 597a264b1a9c7e36d1728f677c66c5c1f7e3b837 net: deliver skbs on inactive slaves to exact matches
> 00d9d6a185de89edc0649ca4ead58f0283dfcbac ipv6: fix ICMP6_MIB_OUTERRORS
> aea34e7ae7a40bc72f9f11b5658160dfb4b90c48 caif: fix a couple range checks
> 08c801f8d45387a1b46066aad1789a9bb9c4b645 net: Print num_rx_queues imbalance warning only when there are allocated queues
> b054b747a694927879c94dd11af54d04346aed7d mac80211: fix deauth before assoc
> 6db6340c42d027b6364d49fa99d69019aca24de4 iwlwifi: add missing rcu_read_lock
> 35dd0509b21e4b5bab36b9eb80c8dab0322f5007 mac80211: fix function pointer check
> 035320d54758e21227987e3aae0d46e7a04f4ddc ipmr: dont corrupt lists
> 8ffb335e8d696affc04f963bf73ce2196f80edb9 ip6mr: fix a typo in ip6mr_for_each_table()
> 7d47618a2ade0cb6d8a0b2597029c383c1662fa0 iwlwifi: move sysfs_create_group to post request firmware
> 1402364162afbaac1b8a74ee21aeb013e817ac7d iwl3945: fix internal scan
> a6866ac93e6cb68091326e80b4fa4619a5957644 iwl3945: enable stuck queue detection on 3945
> 72e09ad107e78d69ff4d3b97a69f0aad2b77280f ipv6: avoid high order allocations
> 8b9a4e6e442756f670ef507f09bbc6c11dc0fca6 mac80211: process station blockack action frames from work

IMHO, no one from above commits looks like could cause that bug, however most suspicious looks these two: 

> b054b747a694927879c94dd11af54d04346aed7d mac80211: fix deauth before assoc
> 8b9a4e6e442756f670ef507f09bbc6c11dc0fca6 mac80211: process station blockack action frames from work

Before use git-bisect to do actual bisection, you could find rcX-rcY regression window, to confirm or deny Eric results? I expect breakage rather between
2.6.34 and 2.6.35-rc1 as rc1 is most experimental, further rcX are mostly fixes. You can easily checkout -rcX releases using "git checkout -b b2.6.35-rc2 v2.6.35-rc2" once you have cloned git repository.

(In reply to comment #44)
> (In reply to comment #43)
> > I wish it was a simple make...
> ? Once kernel is configured "make" it's enough to compile,  "make
> modules_install && make install" should be enough to install compiled kernel.
> If you would bisect, you should optimise kernel compilation work, as you will
> need repeat it many times.
On Ubuntu almost everything is in modules so it needs to create an initrd image it could load. It uses a special script which annoyingly compiles everything again (I will try to figure out if I can bypass it or trick it in some other way).

(In reply to comment #44)
> > 1402364162afbaac1b8a74ee21aeb013e817ac7d iwl3945: fix internal scan
> > a6866ac93e6cb68091326e80b4fa4619a5957644 iwl3945: enable stuck queue detection on 3945

^ I have already tried reverting these two.

(In reply to comment #44)
> Before use git-bisect to do actual bisection, you could find rcX-rcY regression
> window, to confirm or deny Eric results? I expect breakage rather between
> 2.6.34 and 2.6.35-rc1 as rc1 is most experimental, further rcX are mostly
> fixes. You can easily checkout -rcX releases using "git checkout -b b2.6.35-rc2
> v2.6.35-rc2" once you have cloned git repository.

Ok.

Good news. Finally I had some time and I tested carefully the kernel-2.6.35.10-77.bz654599.fc14.i686.rpm. Using this kernel the problem is solved on my laptop. I rebooted more times and switched from kernel to other and the evidence is that with the new kernel the wireless connection speed is stable and run at top speed. Here's the output of command "lspci -vnn | grep -A 1 Wireless".

05:00.0 Network controller [0280]: Intel Corporation PRO/Wireless 3945ABG [Golan] Network Connection [8086:4222] (rev 02)
	Subsystem: Intel Corporation Device [8086:1041]

That's interesting as Radosław reports in comment 36 and 37 that patches do not fix the problem.

Radosław, are you sure you applied patches correctly? Also could you apply both of them and test, perhaps only together patches make a difference.

I applied both of them. I copied them into the root of the source and did: 
patch -p1 < first_file
patch -p1 < second_file
It said it applied patches successfully.

The checksum of compiled iwl3945 was different after applying each patch so it must be fine.

Also note this:
https://bugs.launchpad.net/ubuntu/maverick/+source/linux/+bug/621265/comments/176
https://bugs.launchpad.net/ubuntu/maverick/+source/linux/+bug/621265/comments/177
https://bugs.launchpad.net/ubuntu/maverick/+source/linux/+bug/621265/comments/178
I think I will have to keep repeating this.
This bug is nasty.

@Radosław, moreover you could not reproduce with 2.6.35 gentoo kernel but you could with 2.6.35 ubuntu kernel, yeh, bug is very nasty.

Below commands should install kernel on ubuntu (from kernel source dir):

sudo make modules_install
sudo cp arch/x86/boot/bzImage /boot/test-vmlinuz
sudo mkinitramfs -o /boot/test-initrd.img `cat include/config/kernel.release`

You have to add test-kernel and test-initrd.img to grub.conf or lilo.conf, once added you can reinstall kernel how many times you want with above commands. If you have test-kernel running, and recompile only iwl3945 driver after apply a patch, below commands are enough to reload driver and test the patch (not need to reboot):

sudo make modules_install
sudo rmmod iwl3945 iwlcore mac80211 cfg80211
sudo modprobe iwl3945

@SilvioTO, I will prepare 2 test kernels with individual patches to see which one helps in your environment.

(In reply to comment #50)
> @Radosław, moreover you could not reproduce with 2.6.35 gentoo kernel but you
> could with 2.6.35 ubuntu kernel, yeh, bug is very nasty.

Well, the main big difference between Gentoo and Ubuntu/Mint is that Gentoo has no X11 environment installed (it is a simple console-based set of my favorite apps to diagnose networks, use SSH and so on).

SilvioTO, please test both of these kernels when they finish to compile:
http://koji.fedoraproject.org/koji/taskinfo?taskID=2729164
http://koji.fedoraproject.org/koji/taskinfo?taskID=2729188

I have just installed Fedora. Speed is mega poor so I can work on resolving this issue on this distro as well.

That's great. Could you give your feedback about kernels from comment 30 and comment 52?

Anyway still is better to compile kernel from source to play with (see this link https://bugzilla.redhat.com/show_bug.cgi?id=640612#c37 for description how to compile vanilla kernel on fedora). I'm waiting for results about patches from comment 40 and 41 and reverting mac80211 patches from .35 -rc2 -> -rc3. If you do not want to compile or have problems with that, I'll prepare koji builds.

That from comment 30 works as that in Ubuntu after me patching it. Speed is even poorer than w/o patches and decrease is always immediate (as in matter of seconds, never minutes).

^ I've found why it is so or at least WHEN it is so.
When restarting (as in no shutdown and turning back on) the speed decrease from previous session continues.

In other words: these two patches from build in comment 30 do not influence the buggy behavior.

I will try the -rc2 now.

Date: january 20, 2011
Start Test time: 4.20 PM

Download debian cd1 from http://caesar.acc.umu.se/debian-cd/5.0.7/i386/iso-cd/debian-507-i386-CD-1.iso
===========================
Kernel 2.6.35.10-77.bz654599.fc14.i686:
* Start 2200 kb/s -> in a few seconds 753 Kb/s (in line with max speed of my provider) stable till the end of download (about 14 minutes).
* Shutdown.
$ lspci -vnn | grep -A 1 Wireless
05:00.0 Network controller [0280]: Intel Corporation PRO/Wireless 3945ABG [Golan] Network Connection [8086:4222] (rev 02)
	Subsystem: Intel Corporation Device [8086:1041]
-----------------
Kernel 2.6.35.10-77.txpow.fc14.i686:
* Start 50 kb/s -> after 15 minutes speed still around min 25 - max 60 kb/s.
* Download stopped.
* Shutdown.
$ lspci -vnn | grep -A 1 Wireless
05:00.0 Network controller [0280]: Intel Corporation PRO/Wireless 3945ABG [Golan] Network Connection [8086:4222] (rev 02)
	Subsystem: Intel Corporation Device [8086:1041]
-----------------
Kernel 2.6.35.10-77.plcp.fc14.i686:
* Start 750 Kb/s -> stable till the end of download (about 14 minutes).
* Shutdown.
$ lspci -vnn | grep -A 1 Wireless
05:00.0 Network controller [0280]: Intel Corporation PRO/Wireless 3945ABG [Golan] Network Connection [8086:4222] (rev 02)
	Subsystem: Intel Corporation Device [8086:1041]
===========================

Additional notes:
I tryed to surf some pages too, make a speedtest.net test, reboot kernel randomly more times; each kernel give me ever the same results each time.

When trying to "make install" -rc2 it complains about missing lirc modules.
Any workaround?

It seems to have installed the kernel anyway.
(It would be cool if you could tell me why it popped these errors but it is not really necessary.)

The connection with -rc2 is bad so either Eric is wrong or all the bugs we experience are actually different. SilvioTO seems to have his bug fixed by plcp patch.

I have tried -rc1 and our nasty bug is there as well.

To be perfectly sure the bug was introduced in 2.6.35 I will try the 2.6.34 now.

(In reply to comment #60)
> It seems to have installed the kernel anyway.
> (It would be cool if you could tell me why it popped these errors but it is not
> really )
These are warnings IIRC, when building intitramfs image that some modules are missing, that was previously available. If modules are not related with booting, warnings can be ignored. 

> The connection with -rc2 is bad so either Eric is wrong or all the bugs we
> experience are actually different.
I asked Eric on linux-wireless mailing list about that, and not get any answer, so I think he was not sure if -rc2 has the problem or not.

> SilvioTO seems to have his bug fixed by plcp patch.

You and SilvioTO have different problems, but some kind related since plcp patch make things worse for you ...

Since 2.6.35, new code was added to reset radio (phy) chip based on physical layer (plcp) statistics. We did not have that resets on previous 2.6.34 kernel, at least not in that from like in 2.6.35. For sure we do not have radio chip resets on older kernels (< 2.6.32). On SilvioTO case, seems device stop working after one or more resets. In your case device not working from initialization, but resets helps somehow (not fully and at some point performance degradate). We need to find a fix make your device work without phy resets.

I'm quite sure regression happens between 2.6.34 and 2.6.34-rc1. But before bisecting, could you apply all these 3 patches on broken kernel:

0002-iwl3945-remove-check_plcp_health.patch
0001-iwl3945-do-not-use-agn-specific-IWL_RATE_MASK.patch
iwlwifi-mac80211-revert-QoS-changes.patch   

and test, I have some hope relating with that patches ...

Guess what?
2.6.34 is buggy as well.
I even checked "uname -r" to be sure I booted the right kernel.

:-( ok then, try to find latest working version. Also assure you have updated your AP firmware. Since your problem is not the same as SilvioTO, I'm going to open a separate bug report for it.

Also could you show https://bugzilla.redhat.com/show_bug.cgi?id=654599#c23 on launchpad.net to get some more testing from ubuntu folks. If feedback will be at least partially positive, I'm going to post patch.

Radosław, please comment on bug 671366 since now, I opened it to track your issue.

Take a look at Launchpad's bugtracker.

Sees patch helps some users, and does not help some others. I'm going to post it as RFC, let's see what Intel will tell.

Created attachment 475359 [details]
iwl3945-plcp-delta-threshold-max.patch

SilvioTO,

Please test this patch (koji build is here: http://koji.fedoraproject.org/koji/taskinfo?taskID=2742952, compiling right now). Instead of removing plcp check at all, it increase error delta threshold, after which radio chip is reset. So we could possibly avoid radio resets when not necessary.  It it fix the problem, it would be preferred over previous patch.

I tryed kernel-2.6.35.10-81.delta_max.fc14.i686.rpm and work well; I made the same tests as my previous post.

$ lspci -vnn | grep -A 1 Wireless
05:00.0 Network controller [0280]: Intel Corporation PRO/Wireless 3945ABG [Golan] Network Connection [8086:4222] (rev 02)
	Subsystem: Intel Corporation Device [8086:1041]

@Stanislaw: Create debs for Launchpad users?

That would be very nice!

Could you crate two test kernels. One with iwl3945-plcp-delta-threshold-max.patch
and second with 4 remaining patches:
- 0001-iwl3945-revert-disable_tx_power_cal.patch
- 0002-iwl3945-remove-check_plcp_health.patch
- 0001-iwl3945-do-not-use-agn-specific-IWL_RATE_MASK.patch
- iwlwifi-mac80211-revert-QoS-changes.patch

Thanks.

Ok, they will be ready today or tomorrow.

Done.

Take a look at Launchpad's bugtracker.

In kernel #236 is iwl3945-plcp-delta-threshold-max.patch and in #237 are remaining 4 patches ?

Yes.

Intel told us that fully disabling plcp check is better after all. Sorry for bothering you with testing plcp-delta-threshold-max.patch :-/

However I have some more test request :-P  I want to know if it is better to disable hw scan by default and would like to have test results from as many users as possible (also from these that have 3945 wifi working well currently). Is important that test need to be done on current upstream driver.

Fedora users can use that packages: 
http://koji.fedoraproject.org/koji/taskinfo?taskID=2832390
as described here:
http://people.redhat.com/sgruszka/compact_wireless.html

Ubuntu folks (which I hope will be informed by Radosław :-) can test this tarball (installation is described in README):
http://people.redhat.com/sgruszka/compat-wireless-2011-02-10-iwlwifi.tar.bz2

Anyone else can install wireless-testing tree and use disable_hw_scan=1 iwl3945 module parameter.

Done: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/621265/comments/250

ndiswrapper: 23 Mbps
compat-wireless iwlwifi: 4 Mbps with rare spikes up to 14 Mbps
2.6.38 iwlwifi: 4 Mbps

iwl3945-remove-plcp-check.patch applied to F14 and will be in the next official build.

http://koji.fedoraproject.org/koji/buildinfo?buildID=231525