Bug 654599 - Wifi connection speed is very slow (intel PRO/Wireless 3945ABG), .34 -> .35 regression
Summary: Wifi connection speed is very slow (intel PRO/Wireless 3945ABG), .34 -> .35 r...
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Fedora
Classification: Fedora
Component: kernel
Version: 14
Hardware: i686
OS: Linux
low
medium
Target Milestone: ---
Assignee: Stanislaw Gruszka
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks: 671366 679002
TreeView+ depends on / blocked
 
Reported: 2010-11-18 11:12 UTC by SilvioTO
Modified: 2012-10-30 18:35 UTC (History)
11 users (show)

Fixed In Version: kernel-2.6.35.11-85.fc14
Doc Type: Bug Fix
Doc Text:
Clone Of:
: 671366 679002 (view as bug list)
Environment:
Last Closed: 2011-05-25 14:13:29 UTC


Attachments (Terms of Use)
dmesg after few minutes download (58.37 KB, text/plain)
2010-12-28 15:00 UTC, SilvioTO
no flags Details
0001-iwl3945-revert-disable_tx_power_cal.patch (1.03 KB, text/plain)
2010-12-30 12:39 UTC, Stanislaw Gruszka
no flags Details
0002-iwl3945-remove-check_plcp_health.patch (921 bytes, text/plain)
2010-12-30 12:40 UTC, Stanislaw Gruszka
no flags Details
full listing from "lspci -vvvnn" (2.07 KB, application/octet-stream)
2011-01-13 19:47 UTC, Radosław Piliszek
no flags Details
0001-iwl3945-do-not-use-agn-specific-IWL_RATE_MASK.patch (2.78 KB, text/plain)
2011-01-17 11:19 UTC, Stanislaw Gruszka
no flags Details
iwlwifi-mac80211-revert-QoS-changes.patch (13.70 KB, text/plain)
2011-01-17 11:21 UTC, Stanislaw Gruszka
no flags Details
iwl3945-plcp-delta-threshold-max.patch (982 bytes, text/plain)
2011-01-26 10:18 UTC, Stanislaw Gruszka
no flags Details

Description SilvioTO 2010-11-18 11:12:20 UTC
Description of problem:
the speed of connection with a near (1 meter) access point is about maximum 130-150 kb/s. On windows the speed is about 600-650 kb/s. I never had this problem with Fedora 11, 12 and 13.

How reproducible:
Connect to an access point and download a file.

Additional info:

wlan0     IEEE 802.11abg  ESSID:"MyHome"  
          Mode:Managed  Frequency:2.462 GHz  Access Point: 00:18:39:A7:45:8C   
          Bit Rate=12 Mb/s   Tx-Power=15 dBm   
          Retry  long limit:7   RTS thr:off   Fragment thr:off
          Power Management:off
          Link Quality=70/70  Signal level=-39 dBm  
          Rx invalid nwid:0  Rx invalid crypt:0  Rx invalid frag:0
          Tx excessive retries:0  Invalid misc:0   Missed beacon:0

lspci
00:00.0 Host bridge: Intel Corporation Mobile 945GM/PM/GMS, 943/940GML and 945GT Express Memory Controller Hub (rev 03)
00:01.0 PCI bridge: Intel Corporation Mobile 945GM/PM/GMS, 943/940GML and 945GT Express PCI Express Root Port (rev 03)
00:1b.0 Audio device: Intel Corporation N10/ICH 7 Family High Definition Audio Controller (rev 02)
00:1c.0 PCI bridge: Intel Corporation N10/ICH 7 Family PCI Express Port 1 (rev 02)
00:1c.1 PCI bridge: Intel Corporation N10/ICH 7 Family PCI Express Port 2 (rev 02)
00:1c.2 PCI bridge: Intel Corporation N10/ICH 7 Family PCI Express Port 3 (rev 02)
00:1d.0 USB Controller: Intel Corporation N10/ICH 7 Family USB UHCI Controller #1 (rev 02)
00:1d.1 USB Controller: Intel Corporation N10/ICH 7 Family USB UHCI Controller #2 (rev 02)
00:1d.2 USB Controller: Intel Corporation N10/ICH 7 Family USB UHCI Controller #3 (rev 02)
00:1d.3 USB Controller: Intel Corporation N10/ICH 7 Family USB UHCI Controller #4 (rev 02)
00:1d.7 USB Controller: Intel Corporation N10/ICH 7 Family USB2 EHCI Controller (rev 02)
00:1e.0 PCI bridge: Intel Corporation 82801 Mobile PCI Bridge (rev e2)
00:1f.0 ISA bridge: Intel Corporation 82801GBM (ICH7-M) LPC Interface Bridge (rev 02)
00:1f.2 IDE interface: Intel Corporation 82801GBM/GHM (ICH7 Family) SATA IDE Controller (rev 02)
00:1f.3 SMBus: Intel Corporation N10/ICH 7 Family SMBus Controller (rev 02)
01:00.0 VGA compatible controller: nVidia Corporation G72M [Quadro NVS 110M/GeForce Go 7300] (rev a1)
05:00.0 Network controller: Intel Corporation PRO/Wireless 3945ABG [Golan] Network Connection (rev 02)
07:06.0 CardBus bridge: Texas Instruments PCIxx12 Cardbus Controller
07:06.1 FireWire (IEEE 1394): Texas Instruments PCIxx12 OHCI Compliant IEEE 1394 Host Controller
07:06.2 Mass storage controller: Texas Instruments 5-in-1 Multimedia Card Reader (SD/MMC/MS/MS PRO/xD)
07:06.3 SD Host controller: Texas Instruments PCIxx12 SDA Standard Compliant SD Host Controller
07:08.0 Ethernet controller: Intel Corporation PRO/100 VE Network Connection (rev 02)
[silvio@silvio-laptop ~]$ lspci -n
00:00.0 0600: 8086:27a0 (rev 03)
00:01.0 0604: 8086:27a1 (rev 03)
00:1b.0 0403: 8086:27d8 (rev 02)
00:1c.0 0604: 8086:27d0 (rev 02)
00:1c.1 0604: 8086:27d2 (rev 02)
00:1c.2 0604: 8086:27d4 (rev 02)
00:1d.0 0c03: 8086:27c8 (rev 02)
00:1d.1 0c03: 8086:27c9 (rev 02)
00:1d.2 0c03: 8086:27ca (rev 02)
00:1d.3 0c03: 8086:27cb (rev 02)
00:1d.7 0c03: 8086:27cc (rev 02)
00:1e.0 0604: 8086:2448 (rev e2)
00:1f.0 0601: 8086:27b9 (rev 02)
00:1f.2 0101: 8086:27c4 (rev 02)
00:1f.3 0c05: 8086:27da (rev 02)
01:00.0 0300: 10de:01d7 (rev a1)
05:00.0 0280: 8086:4222 (rev 02)
07:06.0 0607: 104c:8039
07:06.1 0c00: 104c:803a
07:06.2 0180: 104c:803b
07:06.3 0805: 104c:803c
07:08.0 0200: 8086:1092 (rev 02)

Comment 1 Orion Poplawski 2010-11-18 23:41:19 UTC
Possibly similar to bug 653437.  I'm seeing slow connection speeds too, when I manage to connect.

Comment 2 Stanislaw Gruszka 2010-12-01 09:51:33 UTC
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).

Comment 3 SilvioTO 2010-12-01 10:23:56 UTC
I have Linksys Wireless-G model WAG200G AP.

Comment 4 Stanislaw Gruszka 2010-12-10 13:56:09 UTC
Could you install packages form and see if they help:
http://people.redhat.com/sgruszka/compact_wireless.html

Comment 5 SilvioTO 2010-12-11 09:50:38 UTC
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.

Comment 6 Stanislaw Gruszka 2010-12-14 12:50:19 UTC
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.

Comment 7 SilvioTO 2010-12-14 18:06:29 UTC
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.

Comment 8 Stanislaw Gruszka 2010-12-15 14:41:56 UTC
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).

Comment 9 SilvioTO 2010-12-15 19:02:07 UTC
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

Comment 10 Stanislaw Gruszka 2010-12-23 22:54:49 UTC
Please attach dmesg command output.

Comment 11 Stanislaw Gruszka 2010-12-23 23:06:36 UTC
... after reproduce the problem.

Comment 12 SilvioTO 2010-12-24 09:08:21 UTC
Please say me the exactly complete command row, thanks.

Comment 13 Stanislaw Gruszka 2010-12-28 11:05:36 UTC
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.

Comment 14 SilvioTO 2010-12-28 15:00:55 UTC
Created attachment 470977 [details]
dmesg after few minutes download

Comment 15 SilvioTO 2010-12-28 15:01:28 UTC
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/

Comment 17 Radosław Piliszek 2010-12-29 08:33:30 UTC
We are investigating similar problem there.

@SilvioTO: dmesg seems fine.

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

Comment 18 SilvioTO 2010-12-29 09:50:44 UTC
@ Radosław: nice to see that I'm not alone! ;)
Good luck guys, I cross fingers and hope this bug will solve soon.

Comment 19 Stanislaw Gruszka 2010-12-29 14:28:07 UTC
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.

Comment 20 Radosław Piliszek 2010-12-29 15:11:38 UTC
Ok, please also read our comments on launchpad.

Comment 21 Stanislaw Gruszka 2010-12-30 12:38:10 UTC
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.

Comment 22 Stanislaw Gruszka 2010-12-30 12:39:13 UTC
Created attachment 471178 [details]
0001-iwl3945-revert-disable_tx_power_cal.patch

Comment 23 Stanislaw Gruszka 2010-12-30 12:40:03 UTC
Created attachment 471179 [details]
0002-iwl3945-remove-check_plcp_health.patch

Comment 24 Radosław Piliszek 2010-12-30 20:42:12 UTC
Ok, I'll try these.

Comment 25 Radosław Piliszek 2011-01-11 19:34:58 UTC
Sorry for not replying for so long.
I've been busy.

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

Comment 26 Radosław Piliszek 2011-01-11 20:50:47 UTC
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 :/

Comment 27 Stanislaw Gruszka 2011-01-12 09:10:59 UTC
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)

Comment 28 Stanislaw Gruszka 2011-01-12 09:18:09 UTC
One more thing, any info about patches from comment 22 and 23?

Comment 29 Radosław Piliszek 2011-01-12 20:30:34 UTC
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.

Comment 30 Stanislaw Gruszka 2011-01-13 12:31:26 UTC
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.

Comment 31 Stanislaw Gruszka 2011-01-13 12:38:24 UTC
(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:).

Comment 32 Radosław Piliszek 2011-01-13 19:47:00 UTC
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!

Comment 33 SilvioTO 2011-01-14 09:09:44 UTC
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.

Comment 34 Stanislaw Gruszka 2011-01-14 09:44:53 UTC
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.

Comment 35 SilvioTO 2011-01-14 10:15:40 UTC
All clear, I'll try as soon as possibile :-)

Comment 36 Radosław Piliszek 2011-01-14 12:32:56 UTC
I have applied the 1st patch on Ubuntu sources with no luck - problem persists.
I will try the 2nd patch later today.

Comment 37 Radosław Piliszek 2011-01-14 18:48:17 UTC
After applying the 2nd patch things seem to got even worse :(
Speed decreases immediately.

Comment 38 Radosław Piliszek 2011-01-15 16:30:03 UTC
@Stanislaw: Have you found anything interesting in lspci's output? Do you have any idea what I should do now?

Comment 39 Stanislaw Gruszka 2011-01-17 11:12:41 UTC
(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.

Comment 40 Stanislaw Gruszka 2011-01-17 11:19:17 UTC
Created attachment 473809 [details]
0001-iwl3945-do-not-use-agn-specific-IWL_RATE_MASK.patch

Comment 41 Stanislaw Gruszka 2011-01-17 11:21:42 UTC
Created attachment 473812 [details]
iwlwifi-mac80211-revert-QoS-changes.patch

Comment 42 Stanislaw Gruszka 2011-01-17 11:25:07 UTC
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.

Comment 43 Radosław Piliszek 2011-01-17 14:31:12 UTC
(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.

Comment 44 Stanislaw Gruszka 2011-01-17 16:22:13 UTC
(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.

Comment 45 Radosław Piliszek 2011-01-17 16:38:06 UTC
(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.

Comment 46 SilvioTO 2011-01-18 12:57:19 UTC
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]

Comment 47 Stanislaw Gruszka 2011-01-18 15:17:06 UTC
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.

Comment 48 Radosław Piliszek 2011-01-18 15:28:09 UTC
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.

Comment 50 Stanislaw Gruszka 2011-01-18 16:28:57 UTC
@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.

Comment 51 Radosław Piliszek 2011-01-18 17:05:24 UTC
(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).

Comment 52 Stanislaw Gruszka 2011-01-18 17:11:40 UTC
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

Comment 53 Radosław Piliszek 2011-01-18 19:57:27 UTC
I have just installed Fedora. Speed is mega poor so I can work on resolving this issue on this distro as well.

Comment 54 Stanislaw Gruszka 2011-01-19 07:52:32 UTC
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.

Comment 55 Radosław Piliszek 2011-01-19 19:45:26 UTC
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).

Comment 56 Radosław Piliszek 2011-01-19 19:51:47 UTC
^ 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.

Comment 57 Radosław Piliszek 2011-01-19 19:52:50 UTC
I will try the -rc2 now.

Comment 58 SilvioTO 2011-01-20 17:03:36 UTC
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.

Comment 59 Radosław Piliszek 2011-01-20 18:55:09 UTC
When trying to "make install" -rc2 it complains about missing lirc modules.
Any workaround?

Comment 60 Radosław Piliszek 2011-01-20 19:18:30 UTC
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.

Comment 61 Radosław Piliszek 2011-01-20 21:01:01 UTC
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.

Comment 62 Stanislaw Gruszka 2011-01-21 07:11:23 UTC
(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 ...

Comment 63 Radosław Piliszek 2011-01-21 11:51:21 UTC
Guess what?
2.6.34 is buggy as well.
I even checked "uname -r" to be sure I booted the right kernel.

Comment 64 Stanislaw Gruszka 2011-01-21 12:23:53 UTC
:-( 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.

Comment 65 Stanislaw Gruszka 2011-01-21 12:31:39 UTC
Radosław, please comment on bug 671366 since now, I opened it to track your issue.

Comment 66 Radosław Piliszek 2011-01-23 14:23:39 UTC
Take a look at Launchpad's bugtracker.

Comment 67 Stanislaw Gruszka 2011-01-25 09:01:16 UTC
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.

Comment 68 Stanislaw Gruszka 2011-01-26 10:18:59 UTC
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.

Comment 69 SilvioTO 2011-01-27 13:09:21 UTC
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]

Comment 70 Radosław Piliszek 2011-01-27 14:28:54 UTC
@Stanislaw: Create debs for Launchpad users?

Comment 71 Stanislaw Gruszka 2011-01-27 14:50:48 UTC
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.

Comment 72 Radosław Piliszek 2011-01-27 15:22:05 UTC
Ok, they will be ready today or tomorrow.

Comment 73 Radosław Piliszek 2011-01-28 19:49:22 UTC
Done.

Comment 74 Radosław Piliszek 2011-02-11 08:52:27 UTC
Take a look at Launchpad's bugtracker.

Comment 75 Stanislaw Gruszka 2011-02-11 10:41:09 UTC
In kernel #236 is iwl3945-plcp-delta-threshold-max.patch and in #237 are remaining 4 patches ?

Comment 76 Radosław Piliszek 2011-02-11 11:43:28 UTC
Yes.

Comment 77 Stanislaw Gruszka 2011-02-11 14:15:29 UTC
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.

Comment 79 Eric Appleman 2011-02-11 17:59:34 UTC
ndiswrapper: 23 Mbps
compat-wireless iwlwifi: 4 Mbps with rare spikes up to 14 Mbps
2.6.38 iwlwifi: 4 Mbps

Comment 80 Chuck Ebbert 2011-02-24 18:06:16 UTC
iwl3945-remove-plcp-check.patch applied to F14 and will be in the next official build.


Note You need to log in before you can comment on or make changes to this bug.