Bug 571753 - iwlagn stops transferring after few MB data transfer at 5GHz 11n mode
Summary: iwlagn stops transferring after few MB data transfer at 5GHz 11n mode
Keywords:
Status: CLOSED CURRENTRELEASE
Alias: None
Product: Fedora
Classification: Fedora
Component: kernel
Version: 12
Hardware: i686
OS: Linux
low
medium
Target Milestone: ---
Assignee: Stanislaw Gruszka
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
: 574885 (view as bug list)
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2010-03-09 12:18 UTC by ANEZAKI, Akira
Modified: 2010-10-01 16:28 UTC (History)
11 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2010-04-27 20:16:10 UTC
Type: ---
Embargoed:


Attachments (Terms of Use)
A message file compressed by bzip2. (25.09 KB, application/x-bzip2)
2010-03-17 12:34 UTC, ANEZAKI, Akira
no flags Details
A message file compressed by bzip2. (38.11 KB, application/x-bzip2)
2010-03-18 09:29 UTC, ANEZAKI, Akira
no flags Details
A message file compressed by bzip2. (3rd) (706.22 KB, application/x-bzip2)
2010-03-18 10:16 UTC, ANEZAKI, Akira
no flags Details

Description ANEZAKI, Akira 2010-03-09 12:18:01 UTC
Description of problem:
iwlagn stops transferring all data after few MB data transfer at 5GHz 11n mode. For example, while viewing some web pages, all data transferring are stopped.

Version-Release number of selected component (if applicable):
kernel-2.6.32.9-67.fc12

How reproducible:

Steps to Reproduce:
1. connect AP with 5GHz 11n mode.
2. transfer some MBytes data. (ex. viewing some web pages)
3. all data transfer are stopped. ping fails sending data with message "ping: sendmsg: No buffer space available"

Actual results:
All data transferring are stopped.

Expected results:
All data transferring are continued.

Additional info:
I cannot find any logs about this in message file.
I haven't seen this trouble in other mode.
kernel-2.6.31.12-174.2.22.fc12 works fine except 2.4GHz 11n mode.

Comment 1 ANEZAKI, Akira 2010-03-09 12:22:38 UTC
Sorry, this is about wireless lan driver problem. I forgot to mention about it.
I use 5300AGN on board chip.

Comment 2 ANEZAKI, Akira 2010-03-11 02:31:24 UTC
kernel-2.6.32.9-70.fc12 has same problem in 5GHz 11n mode.
But, there are two case.
1. Data transfer was stopped soon.
2. Data transfer is continued for a while.

Comment 3 Joshua Baker-LePain 2010-03-17 04:52:57 UTC
I'm seeing something similar even in 2.4GHz 11n mode with the 2.6.32 kernels.  It happens after a variable amount of time, and there doesn't seem to be much of interest in the logs.  In my case, ping just reports the network as unreachable.  I've also got a 5300 on-board chip (ThinkPad T400s).

In the meantime, I'm using kernel 2.6.31.12-174.2.22.fc12.x86_64, which works just fine in 2.4GHz 11n mode but not in 5GHz (bug 536988).

Comment 4 Stanislaw Gruszka 2010-03-17 07:35:07 UTC
Hi.

Can You try a new kernel 2.6.32.10 from koji ( search here http://koji.fedoraproject.org/koji/packageinfo?packageID=8 ),
which contains a N-only network fix, perhaps this fix helps also with that issue.

If bug is not fixed, please provide logs when module is loaded with
debug=0x47833fff parameter. This will generate a lots of debugging messages.

When logging, please assure you have "kern.*" log to messages in
/etc/rsyslog.conf like in example bellow:

*.info;kern.*;mail.none;authpriv.none;cron.none               
/var/log/messages

If you will modify /etc/rsyslog.conf please do not forgot to restart syslog
daemon.

Test of rawhide 2.6.34 kernel, will be also very much appreciated, as we would
know if the bug is fixed upstream or not.

Comment 5 ANEZAKI, Akira 2010-03-17 12:34:13 UTC
Created attachment 400732 [details]
A message file compressed by bzip2.

Comment 6 ANEZAKI, Akira 2010-03-17 12:49:09 UTC
Hi! This is a report of some tests.

2.6.32.10-78.fc12.i686.PAE:
Both of 2.4GHz and 5GHz 11n modes work fine!
But, message file has many logs like this:
Mar 17 17:29:39 localhost kernel: iwlagn 0000:06:00.0: free more than tfds_in_queue (0:1)
Hole message file are attached above.

2.6.34-0.10.rc1.git0.fc14.i686.PAE:
Both of 2.4GHz and 5GHz 11n modes work fine!

Thank you very much!

Comment 7 Stanislaw Gruszka 2010-03-18 08:06:35 UTC
Hello Akira, I'm glad that driver works for you.  

We need to get rid of that "tdfs_in_queue" messages, however. This is some firmware/driver problem. Could you please provide logs with debug=0x47833fff module option. This will generate lots of debugging messages. Logs from iwlagn module load to first few occurrences of "tfds_in_queue" are fine. Thanks.

Comment 8 ANEZAKI, Akira 2010-03-18 09:23:15 UTC
Hi!

I re-generated message file. The message file attached before uses modprobe file. But this time I typed "rmmod iwlagn" and "modprobe iwlagn debug=0x47833fff".  No error/warning messages were displayed. I cannot find so many differences between this and that attached before. So I attach new message file "as is".

I used kernel-PAE-2.6.32.10-78.fc12.i686.rpm, but if other kernel is required, please inform me which one is correct.

Best Regards,
Anezaki

Comment 9 ANEZAKI, Akira 2010-03-18 09:29:23 UTC
Created attachment 400971 [details]
A message file compressed by bzip2.

Old message file is generated with /etc/modprobe.d/iwlagn.conf file including a line:
debug=0x47833fff

This message file is generated by typing these lines:
> /sbin/rmmod iwlagn
> /sbin/modprobe iwlagn debug=0x47833fff
> /etc/rc.d/init.d/NetworkManager start
And connect 5GHz 11n AP by GUI operation.

Comment 10 Stanislaw Gruszka 2010-03-18 09:32:20 UTC
I'm sorry, option should be debug50=0x47833fff.

Comment 11 ANEZAKI, Akira 2010-03-18 10:13:35 UTC
Hi!

I just finished it.
I did like this:

Boot and logged in.
> rmmod iwlagn
> modprobe iwlagn debug50=0x47833fff
Connect 5GHz 11n AP by GUI operation.
Viewing many Amazon pages.
Switch 2.4GHz 11n AP by GUI operation.
Viewing many Amazon pages.
Shutdown.

This message file contains many logs.
It will be attached next.
I hope these information help you.

Best Regards,
Anezaki

Comment 12 ANEZAKI, Akira 2010-03-18 10:16:36 UTC
Created attachment 400978 [details]
A message file compressed by bzip2. (3rd)

A message file generated with modprobe iwlagn debug50=0x4783fff
1st block is 5GHz. 2nd block is 2.4GHz.

Comment 13 Stanislaw Gruszka 2010-03-18 15:31:28 UTC
Akira,

Could you please test below kernel (when it finish to built, it is compiling right now). Thanks.

http://koji.fedoraproject.org/koji/taskinfo?taskID=2061297

Comment 14 ANEZAKI, Akira 2010-03-18 23:27:38 UTC
Hi!

I tested the kernel.
It works fine and "tfds_in_queue" disappears! 

I'm sorry that I have i686 environment only and I can't test other kernels.

Thank you very much!

Best Regards,
Akira Anezaki

Comment 15 Stanislaw Gruszka 2010-03-19 14:29:10 UTC
*** Bug 574885 has been marked as a duplicate of this bug. ***

Comment 16 ANEZAKI, Akira 2010-03-25 14:48:12 UTC
Hi!

I have continued test more some days.
It works fine and no "tdfs_in_queue" message.

By the way, kernel-PAE-2.6.32.10-83.sg_test.fc12.i686 fails resuming from sleep/hibernate. Do you think that this problem has no relation to iwlagn driver/firmware, don't you?

Regards,
Anezaki

Comment 17 Derek Atkins 2010-03-25 17:40:56 UTC
For what it's worth I'm running 2.6.32.10-83.sg_test.fc12.x86_64 and I have not see it fail to resume from sleep (I don't use hibernate).  I did, however, see it fail to come back from S3 (screen blank), but only once.

Comment 18 ANEZAKI, Akira 2010-03-31 09:47:36 UTC
Hi!

I'm testing new kernel-PAE-2.6.32.10-90.fc12.i686.

It looks quite good!

11n mode works in both 2.4GHz and 5GHz.
No "tdfs_in_queue" appears.
Resume is succeeded from both of sleep and hibernate.

Stanislaw, thank you !

Comment 19 Stanislaw Gruszka 2010-04-27 20:16:10 UTC
If still everything looks fine, time to close this bug :)

Comment 20 Derek Atkins 2010-09-23 18:39:56 UTC
For what it's worth, I recently updated to 2.6.32.19-163.fc12.x86_64 and I'm seeing this issue again!  I turned off my 'n' network configuration in order to get work done.

Comment 21 Stanislaw Gruszka 2010-10-01 16:28:24 UTC
Hi Derek,

This is other bug, please open new report for it and assign it to me. Provide dmesg output, and info about version last known working kernel.


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