"irqfixup" and "irqpoll" broken since 2.6.39

[Edward Donovan]

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

  http://git.kernel.org/?p=linux/kernel/git/torvalds/linux.git;a=commit;h=d05c65fff0ef672be75429266751f0e015b54d94

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:

  http://git.kernel.org/?p=linux/kernel/git/torvalds/linux.git;a=commit;h=c75d720fca8a91ce99196d33adea383621027bf2

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

  http://git.kernel.org/?p=linux/kernel/git/torvalds/linux.git;a=commitdiff;h=fa27271bc8d230355c1f24ddea103824fdc12de6

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)]

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.

[Brad Figg (brad-figg)]

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.

[mfg (micahgalizia)]

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)]

@Edward

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.

[mfg (micahgalizia)]

Hi,

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

[Edward Donovan (edward.donovan)]

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)]

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)]

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

[Edward Donovan (edward.donovan)]

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... :-)

[Edward Donovan (edward.donovan)]

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

  http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=8d32a307e4faa8b123dc8a9cd56d1a7525f69ad3

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

[Edward Donovan (edward.donovan)]

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'

  http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=5f6fb45466b2273ffb91c9cf209f164f666c33b1

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.

[Edward Donovan (edward.donovan)]

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

  genirq: Provide locked setter for chip, handler, name

  http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=a2e8461a2ce5e8140b7374eb68af0d09e36e07ff

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

[Edward Donovan (edward.donovan)]

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

http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=0c6f8a8b917ad361319c8ace3e9f28e69bfdb4c1

[mfg (micahgalizia)]

Edward,

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.

Cheers!

[Edward Donovan (edward.donovan)]

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

[Edward Donovan (edward.donovan)]

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'

  http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=5f6fb45466b2273ffb91c9cf209f164f666c33b1

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?

[Edward Donovan (edward.donovan)]

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

[Edward Donovan (edward.donovan)]

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.

Thanks.

[Edward Donovan (edward.donovan)]

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)]

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.

[Edward Donovan (edward.donovan)]

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

  http://lkml.org/lkml/2011/10/19/405

[Joseph Salisbury (jsalisbury)]

Thanks, Edward!

[Edward Donovan (edward.donovan)]

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:

  http://www.linuxquestions.org/questions/linux-hardware-18/irqpoll-being-ignored-899574/

[Edward Donovan (edward.donovan)]

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.

[Edward Donovan (edward.donovan)]

Here is another message-board user seeming to have the problem:

  http://forums.overclockers.com.au/showpost.php?s=b002eb76507593bd6c9567f2bf9a4c93&p=13734474&postcount=153

[Edward Donovan (edward.donovan)]

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:

  http://git.kernel.org/?p=linux/kernel/git/torvalds/linux.git;a=commitdiff;h=d05c65fff0ef672be75429266751f0e015b54d94

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. :-)

[Edward Donovan (edward.donovan)]

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

[Edward Donovan (edward.donovan)]

Mythbuntu users are finding the regression, here:

  http://ubuntuforums.org/showthread.php?p=11396394

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.

[Edward Donovan (edward.donovan)]

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.

[Edward Donovan (edward.donovan)]

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:

  https://lkml.org/lkml/2011/11/1/267

Please test if you can. Thanks.

[Edward Donovan (edward.donovan)]

Here are examples of more distros encountering the problem:

  http://fedoraforum.org/forum/showthread.php?p=1527448

  https://bbs.archlinux.org/viewtopic.php?pid=1014552

[Edward Donovan (edward.donovan)]

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

[Alex Wauck (awauck)]

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.

[Edward Donovan (edward.donovan)]

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

[Alex Wauck (awauck)]

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

[Edward Donovan (edward.donovan)]

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:

  https://lkml.org/lkml/2011/7/24/54

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

  https://lkml.org/lkml/2011/11/19/189

And I'll report back.

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

  http://git.kernel.org/?p=linux/kernel/git/torvalds/linux.git;a=commit;h=c75d720fca8a91ce99196d33adea383621027bf2

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.

[Edward Donovan (edward.donovan)]

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.

[Herton R. Krzesinski (herton)]

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.

[Edward Donovan (edward.donovan)]

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

  http://git.kernel.org/?p=linux/kernel/git/torvalds/linux.git;a=commit;h=52553ddffad76ccf192d4dd9ce88d5818f57f62a

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

[jhoechtl (johann-hoechtl)]

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

[Launchpad Janitor (janitor)]

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
    calculation.
    - 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
    DCE4.1
    - 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
  * ...

[Aaron Peromsik (aperomsik)]

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)

[Edward Donovan (edward.donovan)]

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,

  http://kernel.ubuntu.com/~kernel-ppa/mainline/v3.0.13-oneiric/

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

[Obrouni (nick-fisk)]

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.

[Edward Donovan (edward.donovan)]

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.

[Aaron Peromsik (aperomsik)]

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.

[Edward Donovan (edward.donovan)]

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,

  http://kernel.ubuntu.com/git?p=ubuntu/ubuntu-oneiric.git;a=summary

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)]

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.

[Edward Donovan (edward.donovan)]

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)]

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]

[Edward Donovan (edward.donovan)]

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

[Florian R, (xyz)]

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
QD