Bug 982153 - [abrt] WARNING: at drivers/iommu/intel_irq_remapping.c:533 intel_irq_remapping_supported+0x35/0x78()
[abrt] WARNING: at drivers/iommu/intel_irq_remapping.c:533 intel_irq_remappin...
Status: CLOSED ERRATA
Product: Fedora
Classification: Fedora
Component: kernel (Show other bugs)
19
x86_64 Unspecified
unspecified Severity unspecified
: ---
: ---
Assigned To: Neil Horman
Fedora Extras Quality Assurance
abrt_hash:f19a7bc3f4add6d9200b9877353...
:
: 997950 998213 1014727 (view as bug list)
Depends On:
Blocks: 1012860
  Show dependency treegraph
 
Reported: 2013-07-08 05:26 EDT by maciekph
Modified: 2013-10-18 15:31 EDT (History)
20 users (show)

See Also:
Fixed In Version: kernel-3.11.4-101.fc18
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
: 1012860 (view as bug list)
Environment:
Last Closed: 2013-10-13 15:56:01 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
File: dmesg (61.74 KB, text/plain)
2013-07-08 05:26 EDT, maciekph
no flags Details
[PATCH] iommu: Remove stack trace from broken irq remapping warning (1.92 KB, patch)
2013-09-25 11:01 EDT, Neil Horman
no flags Details | Diff

  None (edit)
Description maciekph 2013-07-08 05:26:02 EDT
Description of problem:
Start the system, log into XFCE

Additional info:
reporter:       libreport-2.1.5
WARNING: at drivers/iommu/intel_irq_remapping.c:533 intel_irq_remapping_supported+0x35/0x78()
Hardware name: HP Z600 Workstation
This system BIOS has enabled interrupt remapping
on a chipset that contains an erratum making that
feature unstable.  To maintain system stability
interrupt remapping is being disabled.  Please
contact your BIOS vendor for an update
Modules linked in:
Pid: 1, comm: swapper/0 Not tainted 3.9.9-301.fc19.x86_64 #1
Call Trace:
 [<ffffffff81d469a4>] ? intel_irq_remapping_supported+0x35/0x78
 [<ffffffff8105cc56>] warn_slowpath_common+0x66/0x80
 [<ffffffff8105cd04>] warn_slowpath_fmt_taint+0x44/0x50
 [<ffffffff81038c40>] ? ioapic_read_entry+0x40/0x50
 [<ffffffff81d469a4>] intel_irq_remapping_supported+0x35/0x78
 [<ffffffff8151ba0b>] irq_remapping_supported+0x2b/0x30
 [<ffffffff81d15b4c>] enable_IR+0xa/0x60
 [<ffffffff81d15da1>] enable_IR_x2apic+0x8d/0x13f
 [<ffffffff81d17bb6>] default_setup_apic_routing+0x11/0x69
 [<ffffffff81d13ac0>] native_smp_prepare_cpus+0x2c0/0x3c2
 [<ffffffff81d04f8a>] kernel_init_freeable+0xba/0x1fa
 [<ffffffff8162b500>] ? rest_init+0x80/0x80
 [<ffffffff8162b50e>] kernel_init+0xe/0x190
 [<ffffffff8164f26c>] ret_from_fork+0x7c/0xb0
 [<ffffffff8162b500>] ? rest_init+0x80/0x80
Comment 1 maciekph 2013-07-08 05:26:08 EDT
Created attachment 770377 [details]
File: dmesg
Comment 2 HarveyUK 2013-08-15 13:05:38 EDT
I have the same issue, Fedora 19, upgraded with all the latest updates, on a Dell t5500 Xeon cpu, 48gb ram.

WARNING: at drivers/iommu/intel_irq_remapping.c:533 intel_irq_remapping_supported+0x35/0x78()

WARNING: at drivers/iommu/intel_irq_remapping.c:533 intel_irq_remapping_supported+0x35/0x78()
This system BIOS has enabled interrupt remapping
on a chipset that contains an erratum making that
feature unstable.  To maintain system stability
interrupt remapping is being disabled.  Please
contact your BIOS vendor for an update
Modules linked in:
CPU: 0 PID: 1 Comm: swapper/0 Not tainted 3.10.5-201.fc19.x86_64 #1
Hardware name: Dell Inc. Precision WorkStation T5500  /0D883F, BIOS A16 05/28/2013
 000000000000000b ffff880be053dd88 ffffffff81638f56 ffff880be053ddc0
 ffffffff8105c211 0000000000000000 0000000000000246 00000000ffffffff
 0000000000000080 0000000000000000 ffff880be053de20 ffffffff8105c2c4
Call Trace:
 [<ffffffff81638f56>] dump_stack+0x19/0x1b
 [<ffffffff8105c211>] warn_slowpath_common+0x61/0x80
 [<ffffffff8105c2c4>] warn_slowpath_fmt_taint+0x44/0x50
 [<ffffffff81036ff0>] ? ioapic_read_entry+0x40/0x50
 [<ffffffff81d5a0b7>] intel_irq_remapping_supported+0x35/0x78
 [<ffffffff81512d8b>] irq_remapping_supported+0x2b/0x30
 [<ffffffff81d1d1fe>] enable_IR+0xa/0x60
 [<ffffffff81d1d453>] enable_IR_x2apic+0x8d/0x13f
 [<ffffffff81d1f268>] default_setup_apic_routing+0x11/0x69
 [<ffffffff81d1b172>] native_smp_prepare_cpus+0x2c0/0x3c2
 [<ffffffff81d0afa2>] kernel_init_freeable+0xba/0x1fa
 [<ffffffff81623110>] ? rest_init+0x80/0x80
 [<ffffffff8162311e>] kernel_init+0xe/0x190
 [<ffffffff816474ac>] ret_from_fork+0x7c/0xb0
 [<ffffffff81623110>] ? rest_init+0x80/0x80

3.10.5-201.fc19.x86_64
Comment 3 donjoe 2013-08-19 22:51:28 EDT
I can confirm this. Happens every time I boot the machine.


WARNING: at drivers/iommu/intel_irq_remapping.c:533 intel_irq_remapping_supported+0x37/0x7a()
This system BIOS has enabled interrupt remapping
on a chipset that contains an erratum making that
feature unstable.  To maintain system stability
interrupt remapping is being disabled.  Please
contact your BIOS vendor for an update
Modules linked in:
CPU: 0 PID: 1 Comm: swapper/0 Not tainted 3.10.7-100.fc18.x86_64 #1
Hardware name: System manufacturer System Product Name/P6T, BIOS 1408    09/21/2010
 000000000000000b ffff88032e4b1d48 ffffffff816561a6 ffff88032e4b1d88
 ffffffff8105d660 ffffffff815295ef 0000000000000000 0000000000000246
 00000000ffffffff 000000000000b020 000000000000000f ffff88032e4b1de8
Call Trace:
 [<ffffffff816561a6>] dump_stack+0x19/0x1b
 [<ffffffff8105d660>] warn_slowpath_common+0x70/0xa0
 [<ffffffff815295ef>] ? kzalloc+0xf/0x20
 [<ffffffff8105d6ef>] warn_slowpath_fmt_taint+0x3f/0x50
 [<ffffffff8103887b>] ? ioapic_read_entry+0x4b/0x60
 [<ffffffff81d599ea>] intel_irq_remapping_supported+0x37/0x7a
 [<ffffffff8152c88d>] irq_remapping_supported+0x2d/0x30
 [<ffffffff81d1c2d7>] enable_IR+0xb/0x62
 [<ffffffff81d1c613>] enable_IR_x2apic+0x8f/0x14b
 [<ffffffff81d1e31b>] default_setup_apic_routing+0x12/0x6b
 [<ffffffff81d1a2d8>] native_smp_prepare_cpus+0x2fc/0x336
 [<ffffffff81d09f9a>] kernel_init_freeable+0x9f/0x1df
 [<ffffffff81640460>] ? rest_init+0x80/0x80
 [<ffffffff8164046e>] kernel_init+0xe/0xf0
 [<ffffffff8166476c>] ret_from_fork+0x7c/0xb0
 [<ffffffff81640460>] ? rest_init+0x80/0x80
Comment 4 Josh Boyer 2013-08-20 08:35:20 EDT
Sigh.  The WARN_ON tells you what the issue is and what to do.  There's nothing that can really be done from the kernel side other than remove the stacktrace.  I'll look at doing that today.

The actual issue needs to be fixed in the BIOS, as noted.
Comment 5 Josh Boyer 2013-08-20 08:56:03 EDT
*** Bug 997950 has been marked as a duplicate of this bug. ***
Comment 6 Yann Droneaud 2013-08-20 09:19:40 EDT
(In reply to Josh Boyer from comment #4)
> Sigh.  The WARN_ON tells you what the issue is and what to do.  There's
> nothing that can really be done from the kernel side other than remove the
> stacktrace.  I'll look at doing that today.
> 
> The actual issue needs to be fixed in the BIOS, as noted.

It's also noted the kernel has disabled interrupt remapping, so one would assume the kernel having a "safe" workaround:
so why update the BIOS ? what kind of improvement would give a BIOS fix over the kernel workaround ?

https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=03bbcb2e7e292838bb0244f5a7816d194c911d62

Regards.
Comment 7 Josh Boyer 2013-08-20 09:45:12 EDT
(In reply to Yann Droneaud from comment #6)
> (In reply to Josh Boyer from comment #4)
> > Sigh.  The WARN_ON tells you what the issue is and what to do.  There's
> > nothing that can really be done from the kernel side other than remove the
> > stacktrace.  I'll look at doing that today.
> > 
> > The actual issue needs to be fixed in the BIOS, as noted.
> 
> It's also noted the kernel has disabled interrupt remapping, so one would
> assume the kernel having a "safe" workaround:
> so why update the BIOS ? what kind of improvement would give a BIOS fix over
> the kernel workaround ?
> 
> https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/
> ?id=03bbcb2e7e292838bb0244f5a7816d194c911d62
> 
> Regards.

Nothing, really.

Neil, can we change this WARN_TAINT to pr_warn or something?  Otherwise ABRT is going to just keep collecting these reports and filing bugs.
Comment 8 Steven Haigh 2013-08-31 12:51:35 EDT
Yeah, I got here via ABRT popping up on every boot...

[    0.044348] ------------[ cut here ]------------
[    0.044354] WARNING: at drivers/iommu/intel_irq_remapping.c:533 intel_irq_remapping_supported+0x35/0x78()
[    0.044355] This system BIOS has enabled interrupt remapping
on a chipset that contains an erratum making that
feature unstable.  To maintain system stability
interrupt remapping is being disabled.  Please
contact your BIOS vendor for an update
[    0.044357] Modules linked in:
[    0.044360] CPU: 0 PID: 1 Comm: swapper/0 Not tainted 3.10.9-200.fc19.x86_64 #1
[    0.044361] Hardware name: System manufacturer System Product Name/P6X58D-E, BIOS 0803    08/06/2012
[    0.044362]  000000000000000b ffff8801b68bbd88 ffffffff8163910b ffff8801b68bbdc0
[    0.044365]  ffffffff8105c221 0000000000000000 0000000000000246 00000000ffffffff
[    0.044367]  0000000000000080 0000000000000000 ffff8801b68bbe20 ffffffff8105c2d4
[    0.044369] Call Trace:
[    0.044374]  [<ffffffff8163910b>] dump_stack+0x19/0x1b
[    0.044378]  [<ffffffff8105c221>] warn_slowpath_common+0x61/0x80
[    0.044380]  [<ffffffff8105c2d4>] warn_slowpath_fmt_taint+0x44/0x50
[    0.044384]  [<ffffffff81036f90>] ? ioapic_read_entry+0x40/0x50
[    0.044386]  [<ffffffff81d5a0f5>] intel_irq_remapping_supported+0x35/0x78
[    0.044389]  [<ffffffff81512f9b>] irq_remapping_supported+0x2b/0x30
[    0.044393]  [<ffffffff81d1d23c>] enable_IR+0xa/0x60
[    0.044395]  [<ffffffff81d1d491>] enable_IR_x2apic+0x8d/0x13f
[    0.044398]  [<ffffffff81d1f2a6>] default_setup_apic_routing+0x11/0x69
[    0.044400]  [<ffffffff81d1b1b0>] native_smp_prepare_cpus+0x2c0/0x3c2
[    0.044403]  [<ffffffff81d0afa2>] kernel_init_freeable+0xba/0x1fa
[    0.044407]  [<ffffffff816232b0>] ? rest_init+0x80/0x80
[    0.044409]  [<ffffffff816232be>] kernel_init+0xe/0x190
[    0.044411]  [<ffffffff8164766c>] ret_from_fork+0x7c/0xb0
[    0.044413]  [<ffffffff816232b0>] ? rest_init+0x80/0x80
[    0.044418] ---[ end trace abc0f582666d6cb4 ]---

Mine is a generic system built with a Gigabyte P6X58D-E mainboard, BIOS 0803 dated 08/06/2012.

As ABRT will keep referencing this, is it possible to at least get a description as to what this affects (if anything) and what the possible symptoms are / could be?
Comment 9 Steven Haigh 2013-08-31 12:54:26 EDT
Whoops - just correcting myself. The P6X58D-E is an Asus mainboard - not Gigabyte as per my previous comment.
Comment 10 Neil Horman 2013-09-17 09:34:20 EDT
yeah, I can look into that Josh.  I'll do it once I'm back from linuxcon

In response to comment 6, the bios update will disable irq remapping, same as the kernel fix, but doing so in the bios prevents us from inadvertently enabling remapping early in the kernel (as it will cause the chip to not report irq remapping capabilities).  It also will remove the warning that you all are getting
Comment 11 Josh Boyer 2013-09-18 16:40:05 EDT
*********** 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.
Comment 12 Josh Boyer 2013-09-18 17:32:53 EDT
*** Bug 998213 has been marked as a duplicate of this bug. ***
Comment 13 Sergio Pascual 2013-09-18 18:18:36 EDT
I still see the warning 

 Linux version 3.11.1-200.fc19.x86_64 (mockbuild@bkernel02) (gcc version 4.8.1 20130603 (Red Hat 4.8.1-1) #1 SMP Sat Sep 14 15:04:51 UTC 2013

...


dmar: Host address width 40
dmar: DRHD base: 0x0000009fffe000 flags: 0x0
dmar: IOMMU 0: reg_base_addr 9fffe000 ver 1:0 cap c90780106f0462 ecap f020fe
dmar: DRHD base: 0x000000fedc0000 flags: 0x1
dmar: IOMMU 1: reg_base_addr fedc0000 ver 1:0 cap c90780106f0462 ecap f020f6
dmar: RMRR base: 0x0000009be58000 end: 0x0000009be6ffff
dmar: ATSR flags: 0x0
dmar: ATSR flags: 0x0
------------[ cut here ]------------
WARNING: CPU: 0 PID: 1 at drivers/iommu/intel_irq_remapping.c:533 intel_irq_remapping_supported+0x35/0x78() 
[232B blob data]
Modules linked in:
CPU: 0 PID: 1 Comm: swapper/0 Not tainted 3.11.1-200.fc19.x86_64 #1
Hardware name: Dell Inc. Precision WorkStation T5500  /0D883F, BIOS A04 03/03/2010
 000000000000000b ffff88035a913d88 ffffffff816476af ffff88035a913dd0
 ffff88035a913dc0 ffffffff810670dd 0000000000000000 0000000000000246
 00000000ffffffff 0000000000000080 0000000000000000 ffff88035a913e20
Call Trace:
 [<ffffffff816476af>] dump_stack+0x45/0x56 
 [<ffffffff810670dd>] warn_slowpath_common+0x7d/0xa0
 [<ffffffff81067194>] warn_slowpath_fmt_taint+0x44/0x50
 [<ffffffff81042a10>] ? ioapic_read_entry+0x40/0x50
 [<ffffffff81d5f689>] intel_irq_remapping_supported+0x35/0x78
 [<ffffffff8152b21b>] irq_remapping_supported+0x2b/0x30
 [<ffffffff81d21660>] enable_IR+0xa/0x60
 [<ffffffff81d218b6>] enable_IR_x2apic+0x8d/0x13f
 [<ffffffff81d236cb>] default_setup_apic_routing+0x11/0x69
 [<ffffffff81d1f5c8>] native_smp_prepare_cpus+0x2c0/0x3c2
 [<ffffffff81d0efbb>] kernel_init_freeable+0xba/0x1fa
 [<ffffffff8163d970>] ? rest_init+0x80/0x80
 [<ffffffff8163d97e>] kernel_init+0xe/0x190
 [<ffffffff816567ac>] ret_from_fork+0x7c/0xb0
 [<ffffffff8163d970>] ? rest_init+0x80/0x80
---[ end trace 1cead87308f0ac81 ]---
Comment 14 Steve Ardern 2013-09-19 09:40:31 EDT
I'm no longer seeing ABRT pop-up having upgraded to the latest 3.11 kernel.

$ uname -a
Linux xxx.xxx.xxx 3.11.1-200.fc19.x86_64 #1 SMP Sat Sep 14 15:04:51 UTC 2013 x86_64 x86_64 x86_64 GNU/Linux
Comment 15 Sergio Pascual 2013-09-19 14:52:23 EDT
I have updated the BIOS firmware from A04 to A016 and still see the warning.

------------[ cut here ]------------
WARNING: CPU: 0 PID: 1 at drivers/iommu/intel_irq_remapping.c:533 intel_irq_remapping_supported+0x35/0x78
[232B blob data]
Modules linked in:
CPU: 0 PID: 1 Comm: swapper/0 Not tainted 3.11.1-200.fc19.x86_64 #1
Hardware name: Dell Inc. Precision WorkStation T5500  /0D883F, BIOS A16 05/28/2013
 000000000000000b ffff88035a915d88 ffffffff816476af ffff88035a915dd0
 ffff88035a915dc0 ffffffff810670dd 0000000000000000 0000000000000246
 00000000ffffffff 0000000000000080 0000000000000000 ffff88035a915e20
Call Trace:
 [<ffffffff816476af>] dump_stack+0x45/0x56 
 [<ffffffff810670dd>] warn_slowpath_common+0x7d/0xa0
 [<ffffffff81067194>] warn_slowpath_fmt_taint+0x44/0x50
 [<ffffffff81042a10>] ? ioapic_read_entry+0x40/0x50
 [<ffffffff81d5f689>] intel_irq_remapping_supported+0x35/0x78
 [<ffffffff8152b21b>] irq_remapping_supported+0x2b/0x30
 [<ffffffff81d21660>] enable_IR+0xa/0x60
 [<ffffffff81d218b6>] enable_IR_x2apic+0x8d/0x13f
 [<ffffffff81d236cb>] default_setup_apic_routing+0x11/0x69
 [<ffffffff81d1f5c8>] native_smp_prepare_cpus+0x2c0/0x3c2
 [<ffffffff81d0efbb>] kernel_init_freeable+0xba/0x1fa
 [<ffffffff8163d970>] ? rest_init+0x80/0x80
 [<ffffffff8163d97e>] kernel_init+0xe/0x190
 [<ffffffff816567ac>] ret_from_fork+0x7c/0xb0
 [<ffffffff8163d970>] ? rest_init+0x80/0x80
---[ end trace b49d338f23c03fd5 ]---
Comment 16 Neil Horman 2013-09-19 18:38:05 EDT
Then you have a system that hasn't had a bios update to correct this issue.  I suggest you call your bios vendor to have a fix issued.  until then, you can boot with intremap=off until I modify the printk to not dump the stack.
Comment 17 Raphos 2013-09-20 15:58:48 EDT
Same conclusion as Steve (In reply to Steve Ardern from comment #14)
> I'm no longer seeing ABRT pop-up having upgraded to the latest 3.11 kernel.
> 
> $ uname -a
> Linux xxx.xxx.xxx 3.11.1-200.fc19.x86_64 #1 SMP Sat Sep 14 15:04:51 UTC 2013
> x86_64 x86_64 x86_64 GNU/Linux
Comment 18 Neil Horman 2013-09-25 11:01:21 EDT
Created attachment 802903 [details]
[PATCH] iommu: Remove stack trace from broken irq remapping warning


The warning for the irq remapping broken check in intel_irq_remapping.c is
pretty pointless.  We need the warning, but we know where its comming from, the
stack trace will always be the same, and it needlessly triggers things like
Abrt.  This changes the warning to just print a text warning about BIOS being
broken, without the stack trace, then sets the appropriate taint bit.  Since we
automatically disable irq remapping, theres no need to contiue making Abrt jump
at this problem

Signed-off-by: Neil Horman <nhorman@tuxdriver.com>
---
 drivers/iommu/intel_irq_remapping.c | 13 +++++++------
 1 file changed, 7 insertions(+), 6 deletions(-)
Comment 19 Neil Horman 2013-09-25 11:03:22 EDT
there you go, please try the attached patch above and confirm that it works better than the full WARN_ON that we previously had.
Comment 20 Josh Boyer 2013-09-27 09:35:33 EDT
Here's a scratch build with that included.

http://koji.fedoraproject.org/koji/taskinfo?taskID=5990794
Comment 21 Neil Horman 2013-09-27 10:20:31 EDT
Josh, did you already pull this in?  Because I've not posted it upstream yet.
Comment 22 Josh Boyer 2013-09-27 10:26:27 EDT
(In reply to Neil Horman from comment #21)
> Josh, did you already pull this in?  Because I've not posted it upstream yet.

No.  I tend to mark a Fedora bug as POST if there's a patch posted in the bug or a link to a patch upstream.  It seems pretty obvious your patch will resolve the issue it's intended to fix.
Comment 23 Neil Horman 2013-09-27 10:29:23 EDT
Understood, Is it ok if we wait until I get the patch upstream please?  That way we don't wind up with a patch that we're carrying that isn't upstream.
Comment 24 Josh Boyer 2013-09-27 10:49:03 EDT
(In reply to Neil Horman from comment #23)
> Understood, Is it ok if we wait until I get the patch upstream please?  That
> way we don't wind up with a patch that we're carrying that isn't upstream.

Sure, no problem.

Though to be clear, if upstream rejects this for some reason, I'm likely going to want to carry it anyway if for no reason other than to prevent ABRT from continuing to file reports :\.  I doubt upstream will object though, so all should be fine.
Comment 25 Neil Horman 2013-09-27 12:49:27 EDT
Thanks, and I'm fine with carrying it in fedora, I just use the bz as a reminder that I still need to get this in upstream.
Comment 26 Neil Horman 2013-09-27 12:56:41 EDT
http://marc.info/?l=linux-kernel&m=138030097109017&w=2

posted
Comment 27 Josh Boyer 2013-10-02 11:52:09 EDT
*** Bug 1014727 has been marked as a duplicate of this bug. ***
Comment 28 Neil Horman 2013-10-07 10:53:19 EDT
Ok, this is upstream now:
https://git.kernel.org/cgit/linux/kernel/git/joro/iommu.git/commit/?h=x86/vt-d

I'll move this back to post, since we're all back in sync.
Comment 29 Josh Boyer 2013-10-08 08:47:56 EDT
Added to all Fedora branches.  Thanks Neil.
Comment 30 Fedora Update System 2013-10-10 13:41:24 EDT
kernel-3.11.4-201.fc19 has been submitted as an update for Fedora 19.
https://admin.fedoraproject.org/updates/kernel-3.11.4-201.fc19
Comment 31 Fedora Update System 2013-10-10 13:41:40 EDT
kernel-3.11.4-101.fc18 has been submitted as an update for Fedora 18.
https://admin.fedoraproject.org/updates/kernel-3.11.4-101.fc18
Comment 32 Fedora Update System 2013-10-10 18:34:01 EDT
kernel-3.11.4-301.fc20 has been submitted as an update for Fedora 20.
https://admin.fedoraproject.org/updates/kernel-3.11.4-301.fc20
Comment 33 Fedora Update System 2013-10-10 22:33:00 EDT
Package kernel-3.11.4-201.fc19:
* should fix your issue,
* was pushed to the Fedora 19 testing repository,
* should be available at your local mirror within two days.
Update it with:
# su -c 'yum update --enablerepo=updates-testing kernel-3.11.4-201.fc19'
as soon as you are able to, then reboot.
Please go to the following url:
https://admin.fedoraproject.org/updates/FEDORA-2013-18820/kernel-3.11.4-201.fc19
then log in and leave karma (feedback).
Comment 34 Fedora Update System 2013-10-13 15:56:01 EDT
kernel-3.11.4-301.fc20 has been pushed to the Fedora 20 stable repository.  If problems still persist, please make note of it in this bug report.
Comment 35 Fedora Update System 2013-10-14 03:11:12 EDT
kernel-3.11.4-201.fc19 has been pushed to the Fedora 19 stable repository.  If problems still persist, please make note of it in this bug report.
Comment 36 Fedora Update System 2013-10-14 13:18:05 EDT
kernel-3.11.4-201.fc19 has been pushed to the Fedora 19 stable repository.  If problems still persist, please make note of it in this bug report.
Comment 37 HarveyUK 2013-10-16 07:26:09 EDT
I'm finding this still ongoing, anyone else tested? 
Oct 16 11:17:31 t5500 kernel: [ 1540.866256] ieee80211 phy0: rt2x00queue_flush_queue: Warning - Queue 2 failed to flush
Oct 16 11:17:31 t5500 kernel: [ 1540.866275] ieee80211 phy0: rt2x00queue_write_tx_frame: Error - Dropping frame due to full tx queue 2
Oct 16 11:17:31 t5500 kernel: [ 1540.983293] ieee80211 phy0: rt2x00queue_flush_queue: Warning - Queue 2 failed to flush
Oct 16 11:17:31 t5500 kernel: [ 1540.983330] ieee80211 phy0: rt2x00queue_write_tx_frame: Error - Dropping frame due to full tx queue 2
Oct 16 11:17:31 t5500 kernel: [ 1541.182492] ieee80211 phy0: rt2x00queue_flush_queue: Warning - Queue 2 failed to flush
Oct 16 11:17:35 t5500 kernel: [ 1545.496696] ieee80211 phy0: rt2x00queue_write_tx_frame: Error - Arrived at non-free entry in the non-full queue 2
Oct 16 11:19:10 t5500 kernel: [ 1640.243144] ieee80211 phy0: rt2x00queue_write_tx_frame: Error - Arrived at non-free entry in the non-full queue 2
Oct 16 11:19:20 t5500 kernel: [ 1650.384000] ieee80211 phy0: rt2x00queue_write_tx_frame: Error - Arrived at non-free entry in the non-full queue 2
Oct 16 11:24:40 t5500 kernel: [ 1970.712061] ieee80211 phy0: rt2x00queue_write_tx_frame: Error - Arrived at non-free entry in the non-full queue 2
Oct 16 11:29:53 t5500 kernel: [ 2284.021939] ieee80211 phy0: rt2x00queue_write_tx_frame: Error - Arrived at non-free entry in the non-full queue 2
[root@t5500 ~]# uname -r
3.11.4-201.fc19.x86_64
Comment 38 Fedora Update System 2013-10-18 15:31:52 EDT
kernel-3.11.4-101.fc18 has been pushed to the Fedora 18 stable repository.  If problems still persist, please make note of it in this bug report.

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