"irqfixup" and "irqpoll" broken since 2.6.39

Bug #855199 reported by Edward Donovan on 2011-09-21
This bug affects 12 people
Affects Status Importance Assigned to Milestone
Fix Released
Edward Donovan
linux (Ubuntu)
Tim Gardner

Bug Description

In all kernels since 2.6.39, the "irqfixup" and "irqpoll" options are no longer taking effect.

The interrupts now generate the same errors seen without these kernel options, e.g.:

  irq 19: nobody cared (try booting with the "irqpoll" option)

even though irqpoll, or irqfixup, is used.

The Linux irq code was reworked during the 2.6.39 cycle. I have gone through the patches, isolated two regressions, and submitted patches for each.

The first bug effectively disabled the bad-irq handling routines, by a test condition be accidentally reversed. This is the commit where the regression arrives:

  commit d05c65fff0 , genirq: spurious: Run only one poller at a time


The maintainer has accepted my patch for that, and it's on its way into releases: it will be in Linux 3.2, and upcoming stable releases, likely 3.0.11 and 3.1.3. And it's marked as committed to Oneirc now. It's attached here, and is in Linus' tree at:


That bug disabled irqfixup & irqpoll for everybody. But with that fixed, I had some machines where those kernel options still failed. I bisected that problem to here:

  commit fa27271bc , genirq: Fixup poll handling


I've submitted another patch, for that regression, and Linus merged it. Yay. So 3.2 should be good, and 3.0/3.1 updates in a bit -- it took a month, last time.

Brad Figg (brad-figg) on 2011-09-21
Changed in linux (Ubuntu):
status: New → Confirmed

Thank you for taking the time to file a bug report on this issue.

However, given the number of bugs that the Kernel Team receives during any development cycle it is impossible for us to review them all. Therefore, we occasionally resort to using automated bots to request further testing. This is such a request.

We have noted that there is a newer version of the development kernel than the one you last tested when this issue was found. Please test again with the newer kernel and indicate in the bug if this issue still exists or not.

If the bug still exists, change the bug status from Incomplete to Confirmed. If the bug no longer exists, change the bug status from Incomplete to Fix Released.

Thank you for your help, we really do appreciate it.

Changed in linux (Ubuntu):
status: Confirmed → Incomplete
tags: added: kernel-request-3.0.0-12.19
Changed in linux (Ubuntu):
status: Incomplete → Confirmed

Thank you for taking the time to file a bug report on this issue.

However, given the number of bugs that the Kernel Team receives during any development cycle it is impossible for us to review them all. Therefore, we occasionally resort to using automated bots to request further testing. This is such a request.

We have noted that there is a newer version of the development kernel than the one you last tested when this issue was found. Please test again with the newer kernel and indicate in the bug if this issue still exists or not.

If the bug still exists, change the bug status from Incomplete to Confirmed. If the bug no longer exists, change the bug status from Incomplete to Fix Released.

Thank you for your help, we really do appreciate it.

Changed in linux (Ubuntu):
status: Confirmed → Incomplete
tags: added: kernel-request-3.0.0-12.20
Changed in linux (Ubuntu):
status: Incomplete → Confirmed
description: updated
tags: added: regression-release

Hi, I also have this problem on an old HP system with an old ATI RS480/SB400 chipset. Fortunately, I upgraded from 11.04 so I can boot with a 2.6.38 kernel and everything works again. If there is anything else I can do to help, please let me know.

Joseph Salisbury (jsalisbury) wrote :


Would it be possible for you to test the latest upstream kernel? It will allow additional upstream developers to examine the issue. Refer to https://wiki.ubuntu.com/KernelMainlineBuilds . Please test the release candidate kernel versus the daily build. Once you've tested the upstream kernel, please remove the 'needs-upstream-testing' tag. This can be done by clicking on the yellow pencil icon next to the tag located at the bottom of the bug description and deleting the 'needs-upstream-testing' text. Please let us know your results.

Thanks in advance.

tags: added: needs-upstream-testing
mfg (micahgalizia) wrote :


I installed linux-image-3.1.0-0301rc9-generic and the problem is still there. Is there anything else I can do?

tags: removed: needs-upstream-testing
description: updated
Edward Donovan (edward.donovan) wrote :

Hi Joseph and mfg. I have tested it with a daily kernel image, too, and it has the same problems.

(I didn't know about the mainline builds; I was going to try building an upstream kernel. So that was quicker, thank you.)

And I hoped to look at the kernel bugzilla, but it's still offline.

Joseph Salisbury (jsalisbury) wrote :

This issue appears to be an upstream bug, since you tested the latest upstream kernel. Would it be possible for you to open an upstream bug report at bugzilla.kernel.org(Once it is online again)? That will allow the upstream Developers to examine the issue, and may provide a quicker resolution to the bug.

If you are comfortable with opening a bug upstream, It would be great if you can report back the upstream bug number in this bug report. That will allow us to link this bug to the upstream report.

Edward Donovan (edward.donovan) wrote :

Yes, I'll try to keep an eye on the kernel bugzilla, and report there when I can. Thanks.

Ok, I've been going back through the mainline builds, and this regression shows up, for my machines, in 2.6.39-rc1.

The last 2.6.38 was fine, and anything from that first .39 release candidate, inclusive, has shown the bug.

I'll try to get time to look through changelogs and patches for that version. (Though that's a big pile. And I'm no C programmer, nor do I have a git-bisect setup, or any experience with such things, alas... :-)

For reference's sake, one patch that does not seem to be the culprit:

From the list of 2.6.39 changes at kernelnewbies.org, the one IRQ-related change I could pick out was this:

  genirq: Provide forced interrupt threading


I built a 2.6.39 with that patch reverted. It made no difference; the regression was present.

Changed in linux (Ubuntu):
status: Confirmed → Triaged

Ok, now I'm going through the git logs, between March 14, when 2.6.38 was released, and March 29, the date of .39-rc1. As I can get time., I'll pull, build, and test versions that seem to have interrupt-related changes.

The earliest change that looked important was this, on March 16:

  Merge branch 'irq-core-for-linus'


The breakage has not shown up yet; this kernel tested out fine.

There are changes in the interrupt code committed by Thomas Gleixner; a couple on the 17th, and several on the 23rd and after. I hope to get to these soon.

Thru March 23, and this commit, still no problems:

  genirq: Provide locked setter for chip, handler, name


That snapshot includes a couple other "genirq: ..." changes from the 23rd. On to the 24th. I'm either getting somewhere, or nowhere. :)

Still don't see the bug, through this committ on the 29th.

genirq: Remove compat code

author Thomas Gleixner <email address hidden>
 Mon, 28 Mar 2011 11:32:20 +0000 (13:32 +0200)

committer Thomas Gleixner <email address hidden>
 Tue, 29 Mar 2011 12:48:19 +0000 (14:48 +0200)

commit 0c6f8a8b917ad361319c8ace3e9f28e69bfdb4c1

tree b4b0cb4b619368bc93ff883f4b667e05a185549b


mfg (micahgalizia) wrote :


I don't really have time to dig into this at the moment (maybe this evening), but have you checked the revision history on kernel/irq/spurious.c? That seems to be where the irqpoll stuff is handled.


Thanks, Micah! I'll try to get to that, too!

Things are a bit more complicated than I thought, and you should disregard what I said in comments 12, 13, and 14. Apologies.

The regression appears dependent on the kernel configuration. As I was building test images, I was shutting off many drivers and options that I hoped were irrelevant , to cut down the long build times. Some of those options *are* relevant; I have not narrowed it down yet.

So! The regression does first appear on March 16, in this commit:

  Merge branch 'irq-core-for-linus'


I have built that kernel with a fuller config that shows the bug, and a stripped down one that does not. When I next get time, I'll work to pin down the significant options.

I built the previous snapshot, with the same config as the buggy build, but it had not problems. So, for my machines at least, the "5f6fb45" commit appears to contain the regression.

mfg, I have before-and-after images, that you can test if you'd like. I"m not sure if 80M of debs are proper to attach to the bug report?

Ok, did a bunch more building and testing. They cant' be exhaustive, but these tests indicate that:

The config option that makes a difference is the sound driver for the PCI-E video card; the SND_HDA_INTEL option. So the conditions for IRQ trouble showing up are not only that a card is present in the PCI-E video slot, but also that the kernel engages the audio hardware on that card.

Under those conditions, a standard boot of every Linux version I've tried throws the "IRQ 19 - nobody cared" error during startup. (And on some cards, another error message for IRQ 18.) The USB hardware is trying to use IRQ 19 (in conflict with that sound hardware?), and USB performance suffers.

The 'irqpoll' boot option used to fix this problem, until that March 16 commit, "Merge branch 'irq-core-for-linus'". I've tested kernels from that snapshot through 3.1-pre, and if they contain that audio driver (which I'd like to continue to use), they give the IRQ errors even when irqpoll is active.

I'm not sure if I'm near the limits of my skills for troubleshooting this, but I'll try to 0

Dang! I fumbled the keyboard there and posted prematurely.

I may be near the limit of my skills on this one, but I'll try to learn more. This hardware is (otherwise) serving well for me, so I'd be happy to keep using it, if I can. I'm not in a position to say, right now, whether there's a general, if minor, correctness issue for the kernel, here.

I'm also not sure whether I ought to rewrite the initial post to add what more I've learned. Any tips on launchpad procedures are welcome.


Oh yes -- with the kernel bugzilla remaining down, any advice on whether it's time to post to linux-kernel, is welcome, too.

Joseph Salisbury (jsalisbury) wrote :

Yes, it may be best to post the bug to LKML, since bugzilla.kernel.org is still down. I don't believe they have an estimate when bugzilla.kernel.org will be back up.

I have emailed LKML, and the IRQ subsystem maintainer, Thomas Gleixner. Here's my post in one list archive:


Joseph Salisbury (jsalisbury) wrote :

Thanks, Edward!

I have tried looking for reports like this, in the BTS's of other major distros. I don't see any -- it may be too early, as not many have shipped a release with 2.6.39+, yet.

I have seen one user mention this problem, outside a BTS. Interestingly, their machine needs "irqpoll" for a quite different piece of hardware, a RAID card. A possible indication this regression may be more general than just the particular IRQ problem my boxes have.

For future ref, here is that user's report:


I've tested "irqfixup" in the same situations. The behavior is just the same as irqpoll: it fixes my machines, through 2.6.38. From .39 on, it doesn't catch the bad irq.

summary: - 2.6.39 and later have lost "irqpoll" functionality
+ 2.6.39 and later have lost "irqfixup" and "irqpoll" functionality

Ok, I've probably isolated the commit.

I found the new location of the "tip" tree, then read up on git, and set to work. "git bisect" helped me find the commit where things stop working:

 "genirq: spurious: Run only one poller at a time

  author Thomas Gleixner <email address hidden>
   Mon, 7 Feb 2011 13:31:37 +0000 (14:31 +0100)
  committer Thomas Gleixner <email address hidden>
   Sat, 19 Feb 2011 11:58:09 +0000 (12:58 +0100)

  commit d05c65fff0ef672be75429266751f0e015b54d94

  No point in running concurrent pollers which confuse each other by
  setting PENDING."

The small diff is at:


I haven't mailed Mr. Gleixner and LKML again, yet. I may try to take time, to consider how best to get their attention, and whether to propose reverting, or modifying, the patch.

I do see that while bugzilla is down, Maciej Rutecki, <email address hidden> , is keeping a list of regressions, and asks to be CC'd on regression reports. I'll include him, too.

And if any other user beats me to trying them, again, be my guest. :-)

tags: added: irqfixup irqpoll

Oh, and this commit only touched irq/spurious.c , as mfg expected, above. :)

Mythbuntu users are finding the regression, here:


so I added that project to the report.

It seems heavy-handed, but might be accurate, to add all the Ubuntu 11.10 derivatives as affected, in this report. I won't get into that for the moment.

Also, I've tested Linux 3.1, and some newer branches. They don't fix the regression.

For simply reverting the small , "guilty" commit ,'git revert d05c65fff' succeeds on the command line, but does not seem to revert cleanly. Those kernels have failed to build. I haven't had time to look that over, or to really think about the patch.

So I don't have a simple workaround, for using the later kernels, yet. Maybe someone will see it more quickly than I.

Changed in linux:
status: New → Confirmed
Changed in mythbuntu:
status: New → Confirmed
description: updated
description: updated
summary: - 2.6.39 and later have lost "irqfixup" and "irqpoll" functionality
+ "irqfixup" and "irqpoll" broken since 2.6.39
description: updated
description: updated

I think I've got it fixed. I submitted a patch, so we'll see.

The problem commit added a test to the bad-irq routines, checking whether they were already running. One of these tests had an equal-to operator, "==", where it seems to need "!=", not equal. Making that one change in kernel/irq/spurious.c fixes the regression for me. I've tested it successfully it on various kernels, including the current Oneiric source.

The submitted patch is attached. And here it is on LKML, in (hopeful) case anything happens there:


Please test if you can. Thanks.

description: updated
tags: added: kernel-bug patch-forwarded-upstream
description: updated
description: updated

(forgot to say - no bug tracker entries from those distros, or any others, yet.)

Alex Wauck (awauck) wrote :

I gave the patch a try. Previously, I had problems on every single boot. Now, I have booted once and found all USB devices in working order. I will do a few more boots and report back if I encounter any problems.

Hey, that's great, Alex. Thank you!

Alex Wauck (awauck) wrote :

Still looking good. The patch appears to solve my problem without breaking anything.

I've isolated the second regression, and submitted another patch, attached here. So far, no one else seeing this bug report has hit that second regression, so there may be no one here to really test it.

I have found a previous post to LKML, from a user who bisected his problem to the same commit, fa2727, so I may try to contact him:


At any rate, my submission to Thomas can be watched here:


And I'll report back.

In the meantime, my first patch was merged into Linus' tree, and will be in Linux 3.2.


It has not shown up in the stable releases, yet. I'm not sure when it's time to start asking Greg KH about that; I'll give it a bit more time. At this point, I'd suggest Ubuntu apply it, unless your MO is to wait for patches to hit the stable tree.

description: updated
tags: added: patch-accepted-upstream
removed: amd64
Tim Gardner (timg-tpi) on 2011-11-21
Changed in linux (Ubuntu Precise):
status: Triaged → Fix Released
Changed in linux (Ubuntu Oneiric):
status: New → In Progress
assignee: nobody → Tim Gardner (timg-tpi)
Tim Gardner (timg-tpi) on 2011-11-21
Changed in linux (Ubuntu Oneiric):
status: In Progress → Fix Committed

Ok, tonight I got the notices from Greg KH that the first patch is going into the stable trees. Looks on track to be in 3.0.11 and 3.1.3, I'd think, in a couple weeks.

Thank you, Tim, for pulling it into Oneiric already.

description: updated
Herton R. Krzesinski (herton) wrote :

The commit c75d720fca8a91ce99196d33adea383621027bf2, cherry-picked into oneiric, is an early application of a change that will be coming in via upstream stable. As such it is not subject to the standard bug verification process.

tags: added: verification-done-oneiric

Okay, Linus has merged my second patch, and CC'd it to the stable tree.


So hopefully we will be all wrapped up here, soon.

Changed in linux:
status: Confirmed → Fix Committed
Changed in mythbuntu:
status: Confirmed → Fix Committed
description: updated
tags: removed: patch-forwarded-upstream
jhoechtl (johann-hoechtl) wrote :

Thank you for the effort, let's keep our fingers crosed to see it for X-Mas in our apt!

Launchpad Janitor (janitor) wrote :
Download full text (24.8 KiB)

This bug was fixed in the package linux - 3.0.0-14.23

linux (3.0.0-14.23) oneiric-proposed; urgency=low

  [Herton R. Krzesinski]

  * Release Tracking Bug
    - LP: #893213

  [ Andy Whitcroft ]

  * debian: add locking to protect debian/files from parallel update

  [ Konrad Rzeszutek Wilk ]

  * SAUCE: x86/paravirt: Partially revert "remove lazy mode in interrupts"
    - LP: #854050

  [ Leann Ogasawara ]

  * Revert "ubuntu: fsam7400 disable driver"
    - LP: #876030

  [ Seth Forshee ]

  * [Config] Enable EVENT_POWER_TRACING_DEPRECATED=y for powertop

  [ Tim Gardner ]

  * Add postinit and postrm scripts to the extras package
    - LP: #882120
  * [Config] CONFIG_R6040=m
    - LP: #650899
  * [Config] CONFIG_MEMSTICK_R592=m
    - LP: #238208
  * [Config] CONFIG_HID_ACRUX_FF=y
    - LP: #890952

  [ Upstream Kernel Changes ]

  * Revert "NFS: Ensure that writeback_single_inode() calls write_inode()
    when syncing"
    - LP: #890952
  * sparc64: Force the execute bit in OpenFirmware's translation entries.
    - LP: #881420
  * sched/rt: Migrate equal priority tasks to available CPUs
    - LP: #881420
  * sched: Fix up wchan borkage
    - LP: #881420
  * ide-disk: Fix request requeuing
    - LP: #881420
  * posix-cpu-timers: Cure SMP wobbles
    - LP: #881420
  * lis3: fix regression of HP DriveGuard with 8bit chip
    - LP: #881420
  * ASoC: use a valid device for dev_err() in Zylonite
    - LP: #881420
  * ASoC: Fix setting update bits for WM8753_LADC and WM8753_RADC
    - LP: #881420
  * drm/radeon: Update AVIVO cursor coordinate origin before x/yorigin
    - LP: #881420
  * drm/radeon/kms: fix regression in DP aux defer handling
    - LP: #881420
  * drm/radeon/kms: add retry limits for native DP aux defer
    - LP: #881420
  * drm/radeon/kms: fix channel_remap setup (v2)
    - LP: #881420
  * ptp: fix L2 event message recognition
    - LP: #881420
  * x86/PCI: use host bridge _CRS info on ASUS M2V-MX SE
    - LP: #881420
  * qla2xxx: Fix crash in qla2x00_abort_all_cmds() on unload
    - LP: #881420
  * libsas: fix panic when single phy is disabled on a wide port
    - LP: #881420
  * md: Avoid waking up a thread after it has been freed.
    - LP: #881420
  * dm table: avoid crash if integrity profile changes
    - LP: #881420
  * mmc: mxs-mmc: fix clock rate setting
    - LP: #881420
  * exec: do not call request_module() twice from search_binary_handler()
    - LP: #881420
  * ARM: mach-ux500: enable fix for ARM errata 754322
    - LP: #881420
  * drm/radeon/kms: retry aux transactions if there are status flags
    - LP: #881420
  * drm/radeon/kms: use hardcoded dig encoder to transmitter mapping for
    - LP: #881420
  * ipv6: fix NULL dereference in udp6_ufo_fragment()
    - LP: #881420
  * ahci: Enable SB600 64bit DMA on Asus M3A
    - LP: #881420
  * MIPS: PM: Use struct syscore_ops instead of sysdevs for PM (v2)
    - LP: #881420
  * ftrace: Fix regression of :mod:module function enabling
    - LP: #881420
  * ftrace: Fix regression where ftrace breaks when modules are loaded
    - LP: #881420
  * ftrace: Fix warning when CONFIG_FUNCTION_TRACER is not defined
    - LP: #881420
  * ...

Changed in linux (Ubuntu Oneiric):
status: Fix Committed → Fix Released
Aaron Peromsik (aperomsik) wrote :

Installed 3.0.0-14.23 from proposed but it doesn't seem to have helped. Mouse and keyboard are still choppy.

ii linux-image-3.0.0-14-generic-pae 3.0.0-14.23

$ cat /proc/cmdline
BOOT_IMAGE=/boot/vmlinuz-3.0.0-14-generic-pae root=UUID=a1d758b2-1b9b-43a1-96e8-6ec585d96742 ro quiet splash noapictimer irqpoll vt.handoff=7

Machine is an eMachines T6524. (ATI RS780 chipset.) My other machines seem to like Oneiric just fine.

[ 56.870142] irq 19: nobody cared (try booting with the "irqpoll" option)

Hi Aaron -

The Oneiric updates still don't contain my second patch, despite Launchpad marking it 'fix released'. Maybe that machine needs it, like some of mine do? It's the second attachment here, in 3.2-rc4 and later, and yesterday's stable updates, 3.0.13 and 3.1.5. Because of the latter, I think it should be in Oneiric with their next stable update.

If you can try it, maybe with the mainline builds, here,


I'd certainly be interested to hear. Thanks. :)

Obrouni (nick-fisk) wrote :

I have a Nova-TD freeview card which normally dies after 5-60 minutes with the message

irq 17: nobody cared (try booting with the "irqpoll" option)

I updated to 3.0.0-14.23 but still got the same problem. I then tried the mainline kernel 3.0.13 and this fixed the problem (its been working for about 12 hours now).

So it looks like in my case I needed the second patch.

Changed in linux (Ubuntu Oneiric):
status: Fix Released → Fix Committed

Ok, thanks for reporting. I've changed the status for Oneiric back to Fix Committed. Hopefully we'll have a stable update, soon, that includes 3.0.13, and then we can mark it Released. (Presuming the second patch fixes things for Aaron, that is.)

While I've seen other users who need the second patch, I hadn't seen anyone else here on Launchpad. So when it was marked 'Fix Committed', I was like, "well that's one of the two, but the second should be along any time now. I don't see anyone here yet who needs the second patch, so things are probably moving along OK."

Then LP marked it Fix Released, and two more of us reported the first patch wasn't enough. So now I'm trying to highlight that. If Ubuntu has a different way of handling a situation like this, someone do so, or let me know.

Also, now I can change upstream Linux from Committed to Released.

Changed in linux:
status: Fix Committed → Fix Released
Aaron Peromsik (aperomsik) wrote :

I installed the mainline kernel. Unfortunately I couldn't boot into X so I can't verify the fix. I have an nvidia card in that machine and dkms failed to build the nvidia-current driver for the mainline 3.0.13 kernel, complaining it could not identify the kernel version.

Ah, too bad.

Well, I could try to build a patched one for you, but I've had dkms be touchy about my images, too, so it might not help.

I see Ubuntu's git repository,


shows a new version, 3.0.0-15.24, that includes 3.0.13. So it continues to look on its way :) , but I don't know how long 'til that reaches the update archives. (Or if there are debs built from it already, somewhere.)

Aaron Peromsik (aperomsik) wrote :

Thanks for clarifying. I saw 3.0.0-15.24 in -pre-proposed but I didn't realize it included 3.0.13. I installed it and it works.

Oh, great! And here it is now in proposed. Now I can let distro kernels run again; nice.

This is interesting, a bigger proportion of people needing the second patch, than I'd known.

Alex Wauck (awauck) wrote :

For what it's worth, 3.0.0-14.23 and 3.0.13-030013.201112091235 (from the mainline "PPA") both fix the problem on my machine.

lspci -nn excerpt:
00:00.0 Host bridge [0600]: Advanced Micro Devices [AMD] RS780 Host Bridge [1022:9600]
00:02.0 PCI bridge [0604]: Advanced Micro Devices [AMD] RS780 PCI to PCI bridge (ext gfx port 0) [1022:9603]
00:06.0 PCI bridge [0604]: Advanced Micro Devices [AMD] RS780 PCI to PCI bridge (PCIE port 2) [1022:9606]
00:14.0 SMBus [0c05]: ATI Technologies Inc SBx00 SMBus Controller [1002:4385] (rev 3a)
00:14.2 Audio device [0403]: ATI Technologies Inc SBx00 Azalia (Intel HDA) [1002:4383]
00:14.3 ISA bridge [0601]: ATI Technologies Inc SB7x0/SB8x0/SB9x0 LPC host controller [1002:439d]
00:14.4 PCI bridge [0604]: ATI Technologies Inc SBx00 PCI to PCI Bridge [1002:4384]
01:00.0 VGA compatible controller [0300]: ATI Technologies Inc RV790 [Radeon HD 4890] [1002:9460]
01:00.1 Audio device [0403]: ATI Technologies Inc HD48x0 audio [1002:aa30]

no point in having tglx's address on here, anymore, anyway.

Changed in linux (Ubuntu Oneiric):
status: Fix Committed → Fix Released
Changed in mythbuntu:
status: Fix Committed → Fix Released
Changed in linux:
status: Fix Released → New
assignee: nobody → Edward Donovan (edward.donovan)
status: New → Fix Released
no longer affects: mythbuntu
Florian R, (xyz) wrote :

Quiet old butg, but it seems to be there again?
My kernel is 3.13.0-45-generic #74-Ubuntu and I have to use IRQPOLL to keep harddisks from crashing and today, I got a crash again related to IRQPOLL. (Feb 19 04:51:02 mythtv kernel: [45426.291760] irq 18: nobody cared (try booting with the "irqpoll" option)
Feb 19 04:51:02 mythtv kernel: [45426.358066] irq 19: nobody cared (try booting with the "irqpoll" option))

Seems, that this bug raises up again on actual kernel releases?

Best regards

To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers