iwl4965 unusable: packet loss, slow network

Bug #183796 reported by Kim Nguyễn on 2008-01-17
8
Affects Status Importance Assigned to Milestone
Linux
Invalid
Unknown
PLD Linux
Undecided
Unassigned
Nominated for Th by Patryk Zawadzki
Nominated for Titanium by Patryk Zawadzki
linux (Ubuntu)
Medium
Unassigned
Nominated for Lucid by geek

Bug Description

Binary package hint: linux-image-2.6.24-4-generic

On my sony vaio TZ, the intel wireless adapter is correctly detected but performances are horrible when using a 802.11b access point.
This *does'nt seem* to affect 802.11g access points but I only tested with one. (While I tested 2 b access points, both perfectly working
with other laptops (Linux/Windows Vista, intel cards,...)).
I am testing with hardy amd64:

# uname -a
Linux carciofo 2.6.24-4-generic #1 SMP Mon Jan 14 18:19:11 UTC 2008 x86_64 GNU/Linux

Behaviour is the following:
modprobe iwl4965 works properly.
network-manager associate with the acess point (WEP authentication),
route/dns is setup correctly.

ping 192.168.0.1 (the acess point) show over 10% packet loss and half the packet duplicated (DUP!),
with the laptop only a few meters from the AP.
Downloading a file with wget shows poor performances (around 10kb/s max) while connecting the laptop to the AP with ethernet gives around
1Mb/s in download speed.

This is with linux-image-2.6.24-4 from Hardy but the following kernel/driver combinations give the same behaviour:

- linux-image-2.6.22 from gutsy
- stock 2.6.23.13 kernel with latest mac80211 (10.0.0.4), latest iwlwifi (1.2.23) and latest firmware.
- stock 2.6.24-rc7 and -rc8 with in-tree mac80211 and iwlwifi (1.2.23 fails to compile due to a change of wext_handle_ioctl and such).

- also tried associating manually with iwconfig instead of network-manager, same result.
- also tried without wep.
- also tried with various module parameters (antenna=1,2, disable_hw_scan=1, ...)

I will attach output of iwconfig, lspci -v, dmesg, and ping.
Let me know if I can do some more testing.

Kim Nguyễn (kim.nguyen) wrote :

Output of iwconfig once associated:

wlan0 IEEE 802.11g ESSID:"fast306"
          Mode:Managed Frequency:2.437 GHz Access Point: 00:0C:41:A5:A8:9A
          Bit Rate=11 Mb/s Tx-Power=27 dBm
          Retry min limit:7 RTS thr:off Fragment thr=2346 B
          Link Quality=100/100 Signal level=-36 dBm Noise level=-95 dBm
          Rx invalid nwid:0 Rx invalid crypt:0 Rx invalid frag:0
          Tx excessive retries:0 Invalid misc:0 Missed beacon:0

Kim Nguyễn (kim.nguyen) wrote :
Kim Nguyễn (kim.nguyen) wrote :
Kim Nguyễn (kim.nguyen) wrote :
Kim Nguyễn (kim.nguyen) wrote :

Arg... looks like a duplicate of #149214. However using latest firmware doesn't fix the problem for me (or any firmware for that matter).

Hi Kim,

You mentioned "stock 2.6.24-rc7 and -rc8 with in-tree mac80211 and iwlwifi (1.2.23 fails to compile due to a change of wext_handle_ioctl and such)". I'd actually encourage you to also open a bug report at the upstream bugzilla.kernel.org bug tracker. I've noticed many times that once a bug gets the attention of the upstream kernel community, there will be a quick resolution to the issue. Since the Ubuntu kernel rebases with the upstream vanilla kernel, once the fix is committed upstream for others to benefit from as well, the Ubuntu kernel would also pull in the fix. For help with making an upstream bug report, please refer to the "Reporting Bugs Upstream" section of the following link: https://wiki.ubuntu.com/KernelTeamBugPolicies. Please let us know if you open the report upstream. Thanks!

Changed in linux:
status: New → Incomplete
Kim Nguyễn (kim.nguyen) wrote :

Sorry for the delay. This is still an issue with 2.6.24-8-generic.
I have reported the issue upstream.
http://bughost.org/bugzilla/show_bug.cgi?id=1598

Cheers.

Changed in linux:
status: Unknown → Confirmed
Changed in linux:
assignee: nobody → ubuntu-kernel-team
importance: Undecided → Medium
status: Incomplete → Triaged
Changed in linux:
status: Confirmed → In Progress
Patryk Zawadzki (patrys) wrote :

Confirming with 2.6.25.3 in PLD Linux.

Patryk Zawadzki (patrys) wrote :

Partially fixed, no more packet loss, transfer rates are still low. New tracking bug: http://www.intellinuxwireless.org/bugzilla/show_bug.cgi?id=1669

The Ubuntu Kernel Team is planning to move to the 2.6.27 kernel for the upcoming Intrepid Ibex 8.10 release. As a result, the kernel team would appreciate it if you could please test this newer 2.6.27 Ubuntu kernel. There are one of two ways you should be able to test:

1) If you are comfortable installing packages on your own, the linux-image-2.6.27-* package is currently available for you to install and test.

--or--

2) The upcoming Alpha5 for Intrepid Ibex 8.10 will contain this newer 2.6.27 Ubuntu kernel. Alpha5 is set to be released Thursday Sept 4. Please watch http://www.ubuntu.com/testing for Alpha5 to be announced. You should then be able to test via a LiveCD.

Please let us know immediately if this newer 2.6.27 kernel resolves the bug reported here or if the issue remains. More importantly, please open a new bug report for each new bug/regression introduced by the 2.6.27 kernel and tag the bug report with 'linux-2.6.27'. Also, please specifically note if the issue does or does not appear in the 2.6.26 kernel. Thanks again, we really appreicate your help and feedback.

Kim Nguyễn (kim.nguyen) wrote :

I have been testing Intrepid for quite some time now. I have recently switched to 2.6.27-1-generic to test this particular issue, but the slow network performances are still there. However, as mentioned in the upstream bug report, using the module option qos_enable=0 solves the problem without seemingly affecting network performances in other configurations. Of cours this would have to be tested more thoroughly but I think it would be sound to add
options iwlagn qos_enable=0
to /etc/modprobe.d/options with a comment in this file as a workaround.

Please note that the orignial bug (ping issue) has been closed but that another one monitoring the data transfer rate issue
was opened some times ago
(http://www.intellinuxwireless.org/bugzilla/show_bug.cgi?id=1669)

There hasn't been many activity for this bug report recently however, besides the last comments on qos_enable=0.

Changed in linux:
status: In Progress → Unknown
Changed in linux:
status: Unknown → Confirmed
h3 (h3) wrote :

Jezus Christ, me and my co-worker have been searching for hours to find out why some of our Linux machines and VM where slow and some not. I've quickly spotted the correlation with the Linux kernel versions but it took us over 2 hours of intensive search to finally find this thread.

Thanks it works !

Kevin Krafthefer (krafthefer) wrote :

This bug manifests on my system when I use 802.11b (linksys befw11s5).

These suggested workarounds did not work for me:
disabling wireless power management
qos_enable=0
I'm at 2.6.24-19-generic and latest nic & wireless router firmware revs.

I suspect the problem exists between old, 802.11b only routers and new Intel Corporation PRO/Wireless 4965 AG or AGN [Kedron] Network Connection (rev 61) nics.

I'm retaining the old linksys wireless route in the event I can provide any useful debug information to help get to the bottom of this; what information can I provide?

Per a decision made by the Ubuntu Kernel Team, bugs will longer be assigned to the ubuntu-kernel-team in Launchpad as part of the bug triage process. The ubuntu-kernel-team is being unassigned from this bug report. Refer to https://wiki.ubuntu.com/KernelTeamBugPolicies for more information. Thanks.

Changed in linux:
status: Confirmed → Invalid

Kim Nguyễn, this bug was reported a while ago and there hasn't been any activity in it recently. We were wondering if this is still an issue? If so, could you please test for this with the latest development release of Ubuntu? ISO images are available from http://cdimage.ubuntu.com/daily-live/current/ .

If it remains an issue, could you please run the following command in the development release from a Terminal (Applications->Accessories->Terminal), as it will automatically gather and attach updated debug information to this report:

apport-collect -p linux <replace-with-bug-number>

Also, could you please test the latest upstream kernel available following https://wiki.ubuntu.com/KernelMainlineBuilds ? It will allow additional upstream developers to examine the issue. Please do not test the daily folder, but the one all the way at the bottom. Once you've tested the upstream kernel, please comment on which kernel version specifically you tested. If this bug is fixed in the mainline kernel, please add the following tags:
kernel-fixed-upstream
kernel-fixed-upstream-VERSION-NUMBER

where VERSION-NUMBER is the version number of the kernel you tested. For example:
kernel-fixed-upstream-v3.11-rc5

This can be done by clicking on the yellow circle with a black pencil icon next to the word Tags located at the bottom of the bug description. As well, please remove the tag:
needs-upstream-testing

If the mainline kernel does not fix this bug, please add the following tags:
kernel-bug-exists-upstream
kernel-bug-exists-upstream-VERSION-NUMBER

As well, please remove the tag:
needs-upstream-testing

If you are unable to test the mainline kernel, please comment as to why specifically you were unable to test it and add the following tags:
kernel-unable-to-test-upstream
kernel-unable-to-test-upstream-VERSION-NUMBER

Once testing of the upstream kernel is complete, please mark this bug's Status as Confirmed. Please let us know your results. Thank you for your understanding.

tags: added: needs-kernel-logs needs-upstream-testing
Changed in linux (Ubuntu):
status: Triaged → Incomplete
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.