Created attachment 564223 [details]
File: smolt_data

That is this line in ieee80211_duration:

       if (WARN_ON_ONCE(info->control.rates[0].idx < 0))
                return 0;

(In reply to comment #0)
> libreport version: 2.0.8
> abrt_version:   2.0.7
> cmdline:        BOOT_IMAGE=/vmlinuz-3.2.5-3.fc16.x86_64
> root=UUID=0f893208-e2e5-4f0a-b9a6-25e241a1c871 ro rd.md=0 rd.lvm=0 rd.dm=0
> KEYTABLE=us quiet rhgb LANG=zh_CN.UTF-8 rd.luks=0
> kernel:         3.2.5-3.fc16.x86_64
> reason:         WARNING: at
> /builddir/build/BUILD/kernel-3.2.fc16/compat-wireless-3.3-rc1-2/net/mac80211/tx.c:55
> invoke_tx_handlers+0xc84/0x13e0 [mac80211]()
> time:           2012年02月17日 星期五 07时41分32秒
> 
> smolt_data:     Binary file, 3752 bytes
> 
> backtrace:
> :WARNING: at
> /builddir/build/BUILD/kernel-3.2.fc16/compat-wireless-3.3-rc1-2/net/mac80211/tx.c:55
> invoke_tx_handlers+0xc84/0x13e0 [mac80211]()
> :Hardware name: VPCEB2S2C
> :Modules linked in: ppdev parport_pc lp parport fuse lockd rfcomm bnep
> ip6t_REJECT nf_conntrack_ipv6 nf_defrag_ipv6 nf_conntrack_ipv4 nf_defrag_ipv4
> ip6table_filter xt_state nf_conntrack ip6_tables snd_hda_codec_hdmi
> snd_hda_codec_realtek snd_hda_intel snd_hda_codec snd_hwdep snd_seq
> snd_seq_device snd_pcm uinput uvcvideo videodev media v4l2_compat_ioctl32
> sunrpc arc4 microcode joydev ath9k btusb intel_ips bluetooth mac80211 iTCO_wdt
> iTCO_vendor_support i2c_i801 sky2 ath9k_common ath9k_hw ath cfg80211
> sony_laptop rfkill snd_timer snd soundcore snd_page_alloc sdhci_pci sdhci
> mmc_core video radeon ttm drm_kms_helper drm i2c_algo_bit i2c_core [last
> unloaded: scsi_wait_scan]
> :Pid: 76, comm: kworker/u:6 Tainted: G        W    3.2.5-3.fc16.x86_64 #1
> :Call Trace:
> : [<ffffffff8106dd4f>] warn_slowpath_common+0x7f/0xc0
> : [<ffffffff8106ddaa>] warn_slowpath_null+0x1a/0x20
> : [<ffffffffa0275b24>] invoke_tx_handlers+0xc84/0x13e0 [mac80211]
> : [<ffffffff812bcccc>] ? rb_erase+0x1bc/0x310
> : [<ffffffffa0254dac>] ? sta_info_get+0x6c/0x80 [mac80211]
> : [<ffffffffa02763d0>] ieee80211_tx+0x60/0xc0 [mac80211]
> : [<ffffffffa02764b1>] ieee80211_xmit+0x81/0xd0 [mac80211]
> : [<ffffffffa02774bf>] ieee80211_tx_skb_tid+0x5f/0x70 [mac80211]
> : [<ffffffffa0260beb>] ieee80211_send_nullfunc+0x5b/0x70 [mac80211]
> : [<ffffffffa025ae49>] ieee80211_offchannel_return+0x1d9/0x1e0 [mac80211]
> : [<ffffffffa0253557>] ? ieee80211_hw_config+0x127/0x230 [mac80211]
> : [<ffffffffa0265033>] ieee80211_work_work+0x573/0x16d0 [mac80211]
> : [<ffffffff810136ba>] ? __switch_to+0xca/0x310
> : [<ffffffffa0264ac0>] ? free_work+0x20/0x20 [mac80211]
> : [<ffffffff81089ddd>] process_one_work+0x11d/0x470
> : [<ffffffff8108b1df>] worker_thread+0x15f/0x350
> : [<ffffffff8108b080>] ? manage_workers+0x230/0x230
> : [<ffffffff8108fb9c>] kthread+0x8c/0xa0
> : [<ffffffff815eb8f4>] kernel_thread_helper+0x4/0x10
> : [<ffffffff8108fb10>] ? kthread_worker_fn+0x190/0x190
> : [<ffffffff815eb8f0>] ? gs_change+0x13/0x13

are you consistently hitting this warning. please share any information that might be helpful to trigger this WARNING. let me check out in the code if we had missed something.

Yes, I have this warning consistently showing on the bug reports. I am sorry that I am a beginner on linux, I don't know how to trigger this warning. This is what the problem was: the wireless would be able to work, even the warning is generated continually. Sometime my system was crashed due to this type of warning.

hi,

can we narrow down that it is an ath9k rate control specific issue,
please comment it out by # in your config.mk of compat wireless package
CONFIG_ATH9K_RATE_CONTROL.
an easy way is to apply the following patch to ath9k to disable ath9k rate control(courtesy: Raj)

Created attachment 564837 [details]
disabling ath9k rate control

Test kernels with a patch inspired by comment 5 are available here:

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

When they finish, please give them a try and post the results here...thanks!

(In reply to comment #7)
> Test kernels with a patch inspired by comment 5 are available here:
> 
> http://koji.fedoraproject.org/koji/taskinfo?taskID=3810905
> 
> When they finish, please give them a try and post the results here...thanks!


thanks John!

[mass update]
kernel-3.3.0-4.fc16 has been pushed to the Fedora 16 stable repository.
Please retest with this update.

[mass update]
kernel-3.3.0-4.fc16 has been pushed to the Fedora 16 stable repository.
Please retest with this update.

[mass update]
kernel-3.3.0-4.fc16 has been pushed to the Fedora 16 stable repository.
Please retest with this update.

This bug seems to be stuck in some kind of limbo state.  Mohammed, I don't see the patch in comment #6 upstream anywhere.  Did this get fixed in some other way?

(In reply to comment #12)
> This bug seems to be stuck in some kind of limbo state.  Mohammed, I don't
> see the patch in comment #6 upstream anywhere.  Did this get fixed in some
> other way?

Josh, sorry i wasn't tracking this bug for sometime, I have not found a
fix too. If i am correct(an my sanity!) it can be one of the off-channel bugs that Johannes was saying in one of the thread. 
The proposal of disabling ath9k rate control is to just narrow down if the
bug is in ath9k rate control itself(obviously it was not a fix at all).
I suppose the latest kernel can be tested(considering the changes in mac80211), to see if this still present.

Ok, assume this is fixed in mac80211.