Created an attachment (id=2008) [details]
debug level 0x43fff's log

This issue appears in G-band.

severla followup questions here.
1. is there any recovery procedure from the stop transmission?
2. what percentage was it happening? 100% or 50%, etc?
3. have it been compared to other wireless cards?
4. has it been seen the stopped transmission resuming back?

Saw the similar issue against new product, and want to figure out in detail.
Look forward to more information.

(In reply to comment #2)
> severla followup questions here.
> 1. is there any recovery procedure from the stop transmission?
[Ximin] No recovery so far.
> 2. what percentage was it happening? 100% or 50%, etc?
[Ximin] most of time is 0%.
> 3. have it been compared to other wireless cards?
[Ximin] This issue only happended on 5000 serials cards (My testing only cover
5100/5300).
> 4. has it been seen the stopped transmission resuming back?
[Ximin] No back.
> Saw the similar issue against new product, and want to figure out in detail.
> Look forward to more information.

So far I am unable to reproduce this issue.

I tested using 5350 and firmware 8.24.2.12. I followed the steps in comment #1
and was able to scp a 185MB file successfully.

The log in comment #2 does not contain any errors.

Could you please elaborate what the symptoms are? 
How does it fail? 
Are there any error messages? 
What is result of "ping -s 1000 <IP_ADDR>" when fragmentation is enabled?
Do you get different behavior if you run the test without debugging enabled?

Reinette, Ximin is back to University today. 

I tried this issue and looks like this issue only happens on g band.

I used cisco1250 and disble all mcs rate so that the ap works on g mode. This
way I can reproduce this issue. ping -s 1000 <IP> has no response.

Created an attachment (id=2053) [details]
1250 configuration

(In reply to comment #5)

> I tried this issue and looks like this issue only happens on g band.

I tested the following setups:
Cisco 1200 (no 802.11n)
  Tested in G band with 5100 and 5350. Was able to use fragmentation.
Cisco 1250 (with 802.11n)
  Tested in G band with 5100 and 5350. Was able to use fragmentation.
  Repeated above test with all MCS rates disabled. Was able to use
fragmentation.

> I used cisco1250 and disble all mcs rate so that the ap works on g mode. This
> way I can reproduce this issue. ping -s 1000 <IP> has no response.

I attached the configuration of the Cisco 1250 - could you please compare it to
yours? In addition, here is the software information:

 Product/Model Number:        AIR-AP1252AG-A-K9
 Top Assembly Serial Number:     FTX121890KC
 System Software Filename:     c1250-k9w7-tar.124-10b.JA1
 System Software Version:     12.4(10b)JA1
 Bootloader Version:     12.4(10b)JA


It sounds as though this problem is easy for you to reproduce. Could you please
run the following modified test:

1. modprobe -r iwlagn
2. modprobe iwlagn
3. ifconfig wlan0 up
4. iwconfig wlan0 channel <> essid <> ---- associate with AP
5. iwconfig wlan0 frag 256
6. ifconfig wlan0 <IP_ADDR>
7. echo 0x41843fff > /sys/class/net/wlan0/device/debug_level
8. ping -s 1000 -c 2 DEST
9. echo 0 > /sys/class/net/wlan0/device/debug_level

Please send log file.

My AP is:
Product/Model Number:     AIR-LAP1252AG-C-K9
 Top Assembly Serial Number:    FCW1249Z05V
 System Software Filename:      c1250-k9w7-tar.124-10b.JA3
 System Software Version:       12.4(10b)JA3
 Bootloader Version:    12.4(10b)JA

Attached is the dmesg log. ping <IP> has response, but ping -s 1000 <IP> does
not have response.

Created an attachment (id=2054) [details]
dmesg log according to comment #6

(In reply to comment #7)
> My AP is:
> Product/Model Number:     AIR-LAP1252AG-C-K9
>  Top Assembly Serial Number:    FCW1249Z05V
>  System Software Filename:      c1250-k9w7-tar.124-10b.JA3
>  System Software Version:       12.4(10b)JA3
>  Bootloader Version:    12.4(10b)JA
> 
> Attached is the dmesg log. ping <IP> has response, but ping -s 1000 <IP> does
> not have response.
> 

This is interesting. Based on the product number at [1] this seems like a
"lightweight AP" which, according to [2] cannot act independently from a
"wireless LAN controller". The AP used in our lap is an "autonomous" AP. I do
not know if this makes a difference, but it is something to note.

Also, our software version is different - I'll look into upgrading ours.


[1]
http://www.cisco.com/en/US/prod/collateral/wireless/ps5678/ps6973/ps8382/product_data_sheet0900aecd806b7c6d.html
[2]
http://www.cisco.com/en/US/tech/tk722/tk809/technologies_tech_note09186a00806c9e51.shtml

(In reply to comment #8)
> Created an attachment (id=2054) [details] [details]
> dmesg log according to comment #6
> 

I'm sorry, but this did not work.

This debugging generates a lot of data and unfortunately your dmesg log rolled
over all the interesting data.

Would it be possible to configure your system to log to a file instead and send
me the whole log?

You can do it as follows:

- edit your /etc/syslog.conf and add a line like below:
kern.*                          -/var/log/kern.log
- reload your log deamon ... this could be something like:
/etc/init.d/sysklogd reload

please repeat your test after doing the above and send the contents of
/var/log/kern.log.

(In reply to comment #9)

> 
> Also, our software version is different - I'll look into upgrading ours.
> 

I upgraded the AP here to the latest firmware, but I am still not able to
reproduce.

Here is the current details:
 Product/Model Number:        AIR-AP1252AG-A-K9
 Top Assembly Serial Number:     FTX121890KC
 System Software Filename:     c1250-k9w7-tar.124-10b.JDA
 System Software Version:     12.4(10b)JDA
 Bootloader Version:     12.4(10b)JA 

Created an attachment (id=2055) [details]
More dmesg log.

Hope this helps.

Sometime ping -s 1000 partly response.

Created an attachment (id=2057) [details]
do not use scratch field and byte count table when aggregation not in use

Could you please test this patch?

After applying this patch to commit 323564a5d08cb504a84d4fefcc833ce96e011779.
At the first run (reload the new module), ping -s 1000 received the 1st, lost
next 6 packets, and received all other packets.

I then tried to reload the new module for 6 times, ping -s 1000 works great. 

So I think this bug is fixed by the patch. There are must something wrong with
the first run.

This patch is now in our repo.

Created an attachment (id=2067) [details]
do not update byte count table

(In reply to comment #15)
> This patch is now in our repo.
> 

The patch did not pass internal review and was reverted. I have attached a new
patch. Could you please test it? Please note that the original patch was merged
into our iwlwifi-2.6 repo for some time but has now been reverted. When you
test this patch, please use new code from our repo.

(In reply to comment #16)
> Created an attachment (id=2067) [details] [details]
> do not update byte count table
> (In reply to comment #15)
> > This patch is now in our repo.
> > 
> The patch did not pass internal review and was reverted. I have attached a new
> patch. Could you please test it? Please note that the original patch was merged
> into our iwlwifi-2.6 repo for some time but has now been reverted. When you
> test this patch, please use new code from our repo.

Hi Reinette,
I have pulled the new code from our repo and applied the new patch. scp file
with fragmentation and ping -s 1000 -c 20 <IP> work well. I believe the new
patch fixed the bug.

Testing Environment is below, patch is applied on commit
fed5b11dd117f1661a3e8d76cd8592024c62cd6e.

==============================================
Platform        :       Intel SDV M3M41 
Wireless Card   :       Intel(R) WiFi Link 5100
OS              :       Redhat Fedora release 10 (Cambridge) 32bit
AP              :       Cisco 1250
uCode           :       iwlwifi-5000-2.ucode 8.24.2.12
Source          :       commit fed5b11dd117f1661a3e8d76cd8592024c62cd6e

mark as fixed based on last comments

Didn't found it on 2.6.31-rc2-wl and marked it as verified.