Forgot to put this in the description, after the above the wifi interface stopped working, and to get it back I had to reboot.

Please attach full dmesg (which will include this warning). You can find it in .cache/abrt/spool/oops-{DATE}/ or in /var/spool/abrt/oops-{DATE}/

Can you reproduce this problem or it just happen once ?

Created attachment 659638 [details]
Full dmesg including kernel oops

It has happened more than once. I haven't seen a pattern, although from memory it has always happened a number of hours after I've switched the machine on. I haven't been constantly using the machine during that period, as it was sitting on my desk at work being charged after the train ride to work as well as for occasional use.

There are messages indicating firmware hang before the warning: 

[ 8625.598069] iwl4965 0000:03:00.0: Queue 4 stuck for 2004 ms.
[ 8625.598089] iwl4965 0000:03:00.0: On demand firmware reload
[ 8626.005131] iwl4965 0000:03:00.0: Error sending C_ADD_STA: time out after 500ms.
[ 8626.005165] wlan0: HW problem - can not stop rx aggregation for tid 0
[ 8626.505154] iwl4965 0000:03:00.0: Error sending C_ADD_STA: time out after 500ms.
[ 8626.505190] wlan0: HW problem - can not stop rx aggregation for tid 1
[ 8626.505349] ieee80211 phy0: Hardware restart was requested
[ 8626.510156] iwl4965 0000:03:00.0: idx 0 not used in uCode key table.
[ 8627.010154] iwl4965 0000:03:00.0: Error sending C_ADD_STA: time out after 500ms.

I'm not sure how to debug that since it happens after 2.5 hours. 

For now, instead of resting computer to get wlan device work, you can try similar workaround like described here:
http://bugzilla.intellinuxwireless.org/show_bug.cgi?id=2143#c44

You can also check if module option fw_restart=0 prevent the problem.

Thanks for that suggestions, I'll try to give them a go this week.

Is this still reproducible on 3.8 kernel or newer ?

I'll check over the weekend.

I didn't get a chance to try to the intellinuxwireless work around before the webpage has disappeared.

Hi,

Firstly I misread the earlier comment about setting fw_restart to 0, rather than the now default of one. I changed that to 0 before starting the test.

I was able to successfully transfer about 6.5 GB before the wifi died. There were no kernel log messages. I suspect that would have been the time when the firmware would have been reloaded if fw_restart is on.

One general thing I have noticed is that if I just reboot the machine (i.e., not power cycle it), so it seems to be a software/driver error of some sort, rather than hardware.

I'll do some more testing this weekend, to try to identify a better pattern of behaviour.

Description of problem:
Performing a test for Bug 872433.

Ran a bidirectional iperf traffic test for many hours, eventually kernel oops occurred, and wifi failed. Rebooting the machine via shutdown -r doesn't commonly resolve it, neither does shutting down the machine and then restarting it. However, if I shutdown the machine, and then disconnect the battery and the power pack, and then restart it, the wifi interface works again.

Version-Release number of selected component:
kernel

Additional info:
cmdline:        BOOT_IMAGE=/vmlinuz-3.8.8-100.fc17.i686.PAE root=UUID=3eedb729-4d70-4b01-ba26-f545f8b42931 ro rd.md=0 rd.lvm=0 rd.luks.uuid=luks-edd070f7-ad6e-45f2-a20b-4d1a61123e85 SYSFONT=True rd.dm=0 KEYTABLE=us rd.luks.uuid=luks-f82147f9-952f-4ba2-ba21-19e9e328c667 LANG=en_US.UTF-8 rhgb quiet elevator=noop
kernel:         3.8.8-100.fc17.i686.PAE
type:           Kerneloops
ureports_counter: 1

Truncated backtrace:
WARNING: at drivers/net/wireless/iwlegacy/common.c:117 _il_grab_nic_access+0x96/0xa0 [iwlegacy]()
Hardware name: Inspiron 910
Timeout waiting for ucode processor access (CSR_GP_CNTRL 0xffffffff)
Modules linked in: fuse lockd sunrpc rfcomm bnep ip6t_REJECT nf_conntrack_ipv6 nf_defrag_ipv6 ip6table_filter ip6_tables nf_conntrack_ipv4 nf_defrag_ipv4 xt_state nf_conntrack iTCO_wdt iTCO_vendor_support arc4 iwl4965 iwlegacy mac80211 uvcvideo videobuf2_vmalloc videobuf2_memops videobuf2_core coretemp videodev media dell_laptop compal_laptop dcdbas cfg80211 microcode btusb bluetooth i2c_i801 snd_hda_codec_realtek lpc_ich rfkill mfd_core snd_hda_intel snd_hda_codec jmb38x_ms snd_hwdep r8169 snd_seq memstick snd_seq_device mii snd_pcm snd_page_alloc snd_timer snd soundcore uinput mmc_block dm_crypt sdhci_pci sdhci mmc_core i915 video i2c_algo_bit drm_kms_helper drm i2c_core
Pid: 6544, comm: kworker/0:0 Not tainted 3.8.8-100.fc17.i686.PAE #1
Call Trace:
 [<c044d839>] warn_slowpath_common+0x69/0x90
 [<f8224726>] ? _il_grab_nic_access+0x96/0xa0 [iwlegacy]
 [<f8224726>] ? _il_grab_nic_access+0x96/0xa0 [iwlegacy]
 [<c044d903>] warn_slowpath_fmt+0x33/0x40
 [<f8224726>] _il_grab_nic_access+0x96/0xa0 [iwlegacy]
 [<f8225112>] il_wr_prph+0x32/0x90 [iwlegacy]
 [<f8225431>] il_apm_init+0x1b1/0x320 [iwlegacy]
 [<f81e4f3f>] il4965_hw_nic_init+0x2f/0x170 [iwl4965]
 [<f81d8607>] ? il4965_set_hw_ready+0x37/0xc0 [iwl4965]
 [<f81e511f>] __il4965_up+0x9f/0x300 [iwl4965]
 [<c0996a3f>] ? wait_for_common+0xdf/0x110
 [<f81e54bb>] il4965_mac_start+0x7b/0x230 [iwl4965]
 [<c047e900>] ? try_to_wake_up+0x230/0x230
 [<c0995758>] ? mutex_lock+0x18/0x40
 [<c046786d>] ? flush_workqueue+0x13d/0x360
 [<f83a47de>] ieee80211_reconfig+0x18e/0x1390 [mac80211]
 [<c0995758>] ? mutex_lock+0x18/0x40
 [<f8389392>] ? ieee80211_scan_cancel+0x82/0x160 [mac80211]
 [<c0995758>] ? mutex_lock+0x18/0x40
 [<f8381766>] ieee80211_restart_work+0x86/0xa0 [mac80211]
 [<c0866c1a>] ? od_dbs_timer+0x6a/0xd0
 [<c0466e4e>] process_one_work+0x12e/0x3d0
 [<c099f173>] ? common_interrupt+0x33/0x38
 [<c0468ef9>] worker_thread+0x119/0x3b0
 [<c0468de0>] ? flush_delayed_work+0x50/0x50
 [<c046d864>] kthread+0x94/0xa0
 [<c099ebb7>] ret_from_kernel_thread+0x1b/0x28
 [<c046d7d0>] ? kthread_create_on_node+0xc0/0xc0

Further to the reboot comments, it seems intermittent. Sometimes a software reboot resolves it, and wifi starts working again. Other times I have to shutdown the machine and disconnect all power sources. It seems that even when the machine is powered off but still connected to a mains power source, there is a trickle of power to the card, leaving it in the broken state (perhaps to support Wake-On-Lan?).

This message is a reminder that Fedora 17 is nearing its end of life.
Approximately 4 (four) weeks from now Fedora will stop maintaining
and issuing updates for Fedora 17. It is Fedora's policy to close all
bug reports from releases that are no longer maintained. At that time
this bug will be closed as WONTFIX if it remains open with a Fedora 
'version' of '17'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version' 
to a later Fedora version prior to Fedora 17's end of life.

Bug Reporter:  Thank you for reporting this issue and we are sorry that 
we may not be able to fix it before Fedora 17 is end of life. If you 
would still like  to see this bug fixed and are able to reproduce it 
against a later version  of Fedora, you are encouraged  change the 
'version' to a later Fedora version prior to Fedora 17's end of life.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events. Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.

*********** MASS BUG UPDATE **************

We apologize for the inconvenience.  There is a large number of bugs to go through and several of them have gone stale.  Due to this, we are doing a mass bug update across all of the Fedora 19 kernel bugs.

Fedora 19 has now been rebased to 3.11.1-200.fc19.  Please test this kernel update and let us know if you issue has been resolved or if it is still present with the newer kernel.

If you experience different issues, please open a new bug report for those.

This bug is being closed with INSUFFICIENT_DATA as there has not been a response in 2 weeks. If you are still experiencing this issue, please reopen and attach the relevant data from the latest kernel you are running and any data that might have been requested previously.