On Tue, Apr 23, 2013 at 04:10:22PM +0200, Thomas Gleixner wrote:
> On Mon, 22 Apr 2013, Borislav Petkov wrote:
> > [ 1449.134864] ACPI: Preparing to enter system sleep state S5
> > [ 1449.141054] [Firmware Bug]: ACPI: BIOS _OSI(Linux) query ignored
>
> and right after that the spurious interrupt h
On Tue, Apr 23, 2013 at 04:10:22PM +0200, Thomas Gleixner wrote:
> On Mon, 22 Apr 2013, Borislav Petkov wrote:
> > [ 1449.134864] ACPI: Preparing to enter system sleep state S5
> > [ 1449.141054] [Firmware Bug]: ACPI: BIOS _OSI(Linux) query ignored
>
> and right after that the spurious interrupt h
On Mon, 22 Apr 2013, Borislav Petkov wrote:
> [ 1449.134864] ACPI: Preparing to enter system sleep state S5
> [ 1449.141054] [Firmware Bug]: ACPI: BIOS _OSI(Linux) query ignored
and right after that the spurious interrupt happens. I asked Boris to
boot with acpi_osi=Linux on the command line and t
On Mon, Apr 22, 2013 at 11:33:03PM +0200, Borislav Petkov wrote:
> On Mon, Apr 22, 2013 at 07:44:02AM -0700, Paul E. McKenney wrote:
> > Would it make sense to try shutting off the hardware, waiting (say)
> > 100 milliseconds, then diabling the irq? (Hey, had to ask!)
>
> Ok, after a whole day of
On Mon, Apr 22, 2013 at 07:44:02AM -0700, Paul E. McKenney wrote:
> Would it make sense to try shutting off the hardware, waiting (say)
> 100 milliseconds, then diabling the irq? (Hey, had to ask!)
Ok, after a whole day of debugging, here's what tglx and I found out
(Thomas, please correct me if
On Mon, Apr 22, 2013 at 04:23:56PM +0200, Borislav Petkov wrote:
> On Mon, Apr 22, 2013 at 02:56:08PM +0200, Thomas Gleixner wrote:
> > Boris, can you please provide the irq16 line of /proc/interrupts
> > before you invoke suspend?
> >
> > If it's shared we know which driver is shutdown before hda_
On Mon, Apr 22, 2013 at 02:56:08PM +0200, Thomas Gleixner wrote:
> Boris, can you please provide the irq16 line of /proc/interrupts
> before you invoke suspend?
>
> If it's shared we know which driver is shutdown before hda_intel and
> perhaps leaves its device in a weird state.
>
> If it's not sha
On Mon, Apr 22, 2013 at 01:33:12PM +0200, Takashi Iwai wrote:
> At Mon, 22 Apr 2013 12:06:57 +0200,
> Borislav Petkov wrote:
> >
> > On Mon, Apr 22, 2013 at 11:19:07AM +0200, Takashi Iwai wrote:
> > > Is the PCI device a HD-audio controller for the built-in analog or
> > > a HDMI audio controller
On Mon, Apr 22, 2013 at 11:18:47AM +0200, Borislav Petkov wrote:
> On Mon, Apr 22, 2013 at 10:01:36AM +0200, Ingo Molnar wrote:
> > Hm, this really smells like a workaround: treating the symptom, not
> > the cause.
>
> Well, I just tested Takashi's add missing synchronize_irq() to the
> suspend pa
On Mon, 22 Apr 2013, Takashi Iwai wrote:
> At Mon, 22 Apr 2013 11:13:10 +0200,
> Borislav Petkov wrote:
> >
> > On Mon, Apr 22, 2013 at 10:32:17AM +0200, Takashi Iwai wrote:
> > > Hm, if it's really due to a stray irq, just adding the missing
> > > synchronize_irq() like below would help?
> > >
>
At Mon, 22 Apr 2013 12:06:57 +0200,
Borislav Petkov wrote:
>
> On Mon, Apr 22, 2013 at 11:19:07AM +0200, Takashi Iwai wrote:
> > Is the PCI device a HD-audio controller for the built-in analog or
> > a HDMI audio controller coupled with a graphics chip?
>
> Hmm:
>
> [7.204020] snd_hda_intel
On Mon, Apr 22, 2013 at 11:19:07AM +0200, Takashi Iwai wrote:
> Is the PCI device a HD-audio controller for the built-in analog or
> a HDMI audio controller coupled with a graphics chip?
Hmm:
[7.204020] snd_hda_intel :01:00.1: irq 90 for MSI/MSI-X
[7.551912] #0: HDA ATI SB at 0xfeb0
At Mon, 22 Apr 2013 11:13:10 +0200,
Borislav Petkov wrote:
>
> On Mon, Apr 22, 2013 at 10:32:17AM +0200, Takashi Iwai wrote:
> > Hm, if it's really due to a stray irq, just adding the missing
> > synchronize_irq() like below would help?
> >
> >
> > Takashi
> >
> > ---
> > diff --git a/sound/pci
On Mon, Apr 22, 2013 at 10:01:36AM +0200, Ingo Molnar wrote:
> Hm, this really smells like a workaround: treating the symptom, not
> the cause.
Well, I just tested Takashi's add missing synchronize_irq() to the
suspend path of snd_hda_intel and it doesn't help.
So it could be an issue with this d
On Mon, Apr 22, 2013 at 10:32:17AM +0200, Takashi Iwai wrote:
> Hm, if it's really due to a stray irq, just adding the missing
> synchronize_irq() like below would help?
>
>
> Takashi
>
> ---
> diff --git a/sound/pci/hda/hda_intel.c b/sound/pci/hda/hda_intel.c
> index 7b213d5..262dbf1 100644
> -
At Sun, 21 Apr 2013 09:30:02 -0700,
Paul E. McKenney wrote:
>
> On Sun, Apr 21, 2013 at 12:34:03PM +0200, Borislav Petkov wrote:
> > On Sat, Apr 20, 2013 at 04:52:07PM -0700, Paul E. McKenney wrote:
> > > Hmmm... Does this problem occur only with CONFIG_RCU_FAST_NO_HZ=y, or
> > > does it occur unc
* Borislav Petkov wrote:
> From 3c155e9a22036839c09d98a4acbc7e17a5a3783c Mon Sep 17 00:00:00 2001
> From: Borislav Petkov
> Date: Sun, 21 Apr 2013 23:56:15 +0200
> Subject: [PATCH] RCU: Expedite grace periods during suspend/resume
>
> Paul says CONFIG_RCU_FAST_NO_HZ can increase grace-period d
On Sun, Apr 21, 2013 at 03:00:15PM -0700, Paul E. McKenney wrote:
> Cool!!! Note that there is no need for expediting TINY_RCU because
> its grace periods are already maximally expedited. There is only one
> CPU, so if you are following the rules, when you call synchronize_rcu(),
> by definition
On Sun, Apr 21, 2013 at 11:42:41PM +0200, Borislav Petkov wrote:
> On Sun, Apr 21, 2013 at 10:51:39PM +0200, Borislav Petkov wrote:
> > A similar oneliner at the end of the resume path.
> >
> > Maybe have rcu suspend/resume callbacks where you can do this stuff
> > and maybe more in the future.
>
On Sun, Apr 21, 2013 at 10:51:39PM +0200, Borislav Petkov wrote:
> A similar oneliner at the end of the resume path.
>
> Maybe have rcu suspend/resume callbacks where you can do this stuff
> and maybe more in the future.
Ok, here's one - it is pretty straight-forward using that notifier
abominatio
On Sun, Apr 21, 2013 at 01:34:47PM -0700, Paul E. McKenney wrote:
> > No warning, no delay, 2 suspend/resume cycles back-to-back. So, a
> > probable fix could be to force-enable the expedited grace periods during
> > suspend...?
>
> Fix for the slowness, for sure!
>
> For the irq warning, it is m
On Sun, Apr 21, 2013 at 09:06:55PM +0200, Borislav Petkov wrote:
> On Sun, Apr 21, 2013 at 11:56:09AM -0700, Paul E. McKenney wrote:
> > CONFIG_RCU_FAST_NO_HZ will definitely change the timing, for example,
> > increasing grace-period durations by up to a factor of four.
> >
> > One way to figure o
On Sun, Apr 21, 2013 at 11:56:09AM -0700, Paul E. McKenney wrote:
> CONFIG_RCU_FAST_NO_HZ will definitely change the timing, for example,
> increasing grace-period durations by up to a factor of four.
>
> One way to figure out if this is the problem would be to either (1)
> apply the following patc
On Sun, Apr 21, 2013 at 08:10:35PM +0200, Borislav Petkov wrote:
> On Sun, Apr 21, 2013 at 06:56:54PM +0200, Borislav Petkov wrote:
> > Ok, let me try to disable the soundcard in the BIOS.
>
> Ok, there's no warning message anymore but maybe a dozen of seconds
> delay before the machine is actuall
On Sun, Apr 21, 2013 at 06:56:54PM +0200, Borislav Petkov wrote:
> On Sun, Apr 21, 2013 at 09:30:02AM -0700, Paul E. McKenney wrote:
> > Thank you for the info! Now to figure out what the heck is causing this.
> >
> > I am also guessing that your system does have hardware that could do an
> > irq
On Sun, Apr 21, 2013 at 06:56:54PM +0200, Borislav Petkov wrote:
> Ok, let me try to disable the soundcard in the BIOS.
Ok, there's no warning message anymore but maybe a dozen of seconds
delay before the machine is actually powered off.
"...
ACPI: Preparing to enter system sleep state S5
[Firmwa
On Sun, Apr 21, 2013 at 09:30:02AM -0700, Paul E. McKenney wrote:
> Thank you for the info! Now to figure out what the heck is causing this.
>
> I am also guessing that your system does have hardware that could do an
> irq 16. Of course, if removing or disabing this hardware is an option,
> it w
On Sun, Apr 21, 2013 at 12:34:03PM +0200, Borislav Petkov wrote:
> On Sat, Apr 20, 2013 at 04:52:07PM -0700, Paul E. McKenney wrote:
> > Hmmm... Does this problem occur only with CONFIG_RCU_FAST_NO_HZ=y, or
> > does it occur unconditionally? (My guess is the former, but figured I
> > should check.)
On Sat, Apr 20, 2013 at 04:52:07PM -0700, Paul E. McKenney wrote:
> Hmmm... Does this problem occur only with CONFIG_RCU_FAST_NO_HZ=y, or
> does it occur unconditionally? (My guess is the former, but figured I
> should check.)
Your guess is correct, sir.
>From quickly grepping in /boot/, I have C
On Sat, Apr 20, 2013 at 08:53:30PM +0200, Borislav Petkov wrote:
> Hi Paul,
>
> so I've been bisecting another issue and have been seeing the warning
> in the attached pic. Reverting c0f4dfd4f90f1667d234d21f15153ea09a2eaa66
> ("rcu: Make RCU_FAST_NO_HZ take advantage of numbered callbacks") seems
bus irq for waits") switched to
> using GMBUS irqs instead of GPIO bit-banging for chipset generations 4
> and above.
>
> It turns out though that on many systems this leads to spurious
> interrupts being generated, long after the register write to disable the
> IRQ
On Tue, 19 Mar 2013, Yinghai Lu wrote:
> > I guess I should have phrased it more precisely, but that's exactly
> > what I expect is happening on my machine: I don't have anything on
> > irq16 (i.e. in non-msi mode the gfx interrupt isn't shared) and hence
> > the irq is completely disabled. Which
On Wed, 20 Mar 2013, Jiri Kosina wrote:
> > I don't know of any way. In fact, I have been thinking of writing a
> > test driver module, with a module parameter telling it which IRQ number
> > to register for. It seems like the sort of thing that would be useful
> > to have, from time to time.
On Tue, 19 Mar 2013, Alan Stern wrote:
> > > That might be misleading. It's possible that the erroneous IRQs _are_
> > > being issued but you're simply not aware of them. If the kernel thinks
> > > that no device is using IRQ 16 then it will leave that IRQ disabled.
> >
> > I guess I should hav
On Tue, Mar 19, 2013 at 9:54 AM, Daniel Vetter wrote:
> I guess I should have phrased it more precisely, but that's exactly
> what I expect is happening on my machine: I don't have anything on
> irq16 (i.e. in non-msi mode the gfx interrupt isn't shared) and hence
> the irq is completely disabled
On Tue, 19 Mar 2013, Daniel Vetter wrote:
> > That might be misleading. It's possible that the erroneous IRQs _are_
> > being issued but you're simply not aware of them. If the kernel thinks
> > that no device is using IRQ 16 then it will leave that IRQ disabled.
>
> I guess I should have phras
ut though that on many systems this leads to spurious
>> interrupts
>> being generated, long after the register write to disable the IRQs has
>> been
>> issued.
>>
>> Typically this results in the spurious interrupt source getting
>> disabl
ster write to disable the IRQs has
> been
> issued.
>
> Typically this results in the spurious interrupt source getting
> disabled:
>
> [9.636345] irq 16: nobody cared (try booting with the "irqpoll"
> option)
> [9.637915] Pid:
upts
being generated, long after the register write to disable the IRQs has been
issued.
Typically this results in the spurious interrupt source getting
disabled:
[9.636345] irq 16: nobody cared (try booting with the "irqpoll" option)
[9.637915] Pid: 4157, com
On Tue, Mar 19, 2013 at 09:56:57AM +0100, Jiri Kosina wrote:
> On Mon, 18 Mar 2013, Chris Wilson wrote:
>
> > > +#define HAS_GMBUS_IRQ(dev) (INTEL_INFO(dev)->gen >= 5)
> > > void
> > > intel_i2c_reset(struct drm_device *dev)
> > > {
> > > struct drm_i915_private *dev_priv = dev->dev_private;
On Mon, 18 Mar 2013, Chris Wilson wrote:
> > +#define HAS_GMBUS_IRQ(dev) (INTEL_INFO(dev)->gen >= 5)
> > void
> > intel_i2c_reset(struct drm_device *dev)
> > {
> > struct drm_i915_private *dev_priv = dev->dev_private;
> > I915_WRITE(dev_priv->gpio_mmio_base + GMBUS0, 0);
> > - I915_WR
On Mon, Mar 18, 2013 at 3:05 PM, Jiri Kosina wrote:
> On Mon, 18 Mar 2013, Yinghai Lu wrote:
>
>> > Yes, switching from MSI to IO-APIC-fasteoi makes the report about lost
>> > interrupts go away.
>> >
>> > My understanding from the other mail is that DAniel Vetter already has an
>> > idea what mig
On Mon, 18 Mar 2013, Yinghai Lu wrote:
> > Yes, switching from MSI to IO-APIC-fasteoi makes the report about lost
> > interrupts go away.
> >
> > My understanding from the other mail is that DAniel Vetter already has an
> > idea what might be going wrong with IRQ acking on GM45 chipsets; hopefully
On Mon, 18 Mar 2013, Daniel Vetter wrote:
> Yep, there's a big comment in the irq handler for that chipset that we
> have a gaping race with when using MSI interrupts. Although the comment
> bodly claims that the race is small enough to avoid the dreaded "nobody
> cared" message. Looks like gmbus
On Mon, Mar 18, 2013 at 08:19:03PM +0100, Daniel Vetter wrote:
> On Mon, Mar 18, 2013 at 10:12:49AM +0100, Jiri Kosina wrote:
> > On Fri, 15 Mar 2013, Yinghai Lu wrote:
> >
> > > > Just a datapoint -- I have put a trivial debugging patch in place, and
> > > > it
> > > > reveals that "nobody cared
On Mon, Mar 18, 2013 at 04:56:02PM +0100, Jiri Kosina wrote:
> Okay, so I think that for 3.9 we want the patch below, and if eventually
> hardware root cause / workaround is found for GM45, we can have it merged
> later.
I'd prefer if we dig into this for a bit more. I've been traveling last
wee
On Mon, Mar 18, 2013 at 10:12:49AM +0100, Jiri Kosina wrote:
> On Fri, 15 Mar 2013, Yinghai Lu wrote:
>
> > > Just a datapoint -- I have put a trivial debugging patch in place, and it
> > > reveals that "nobody cared" for irq 16 happens long after last
> > >
> > > I915_WRITE(GMBUS4 + reg_o
On Mon, Mar 18, 2013 at 2:12 AM, Jiri Kosina wrote:
> On Fri, 15 Mar 2013, Yinghai Lu wrote:
>
>> > Just a datapoint -- I have put a trivial debugging patch in place, and it
>> > reveals that "nobody cared" for irq 16 happens long after last
>> >
>> > I915_WRITE(GMBUS4 + reg_offset, 0);
>>
On Mon, Mar 18, 2013 at 04:56:02PM +0100, Jiri Kosina wrote:
> Okay, so I think that for 3.9 we want the patch below, and if eventually
> hardware root cause / workaround is found for GM45, we can have it merged
> later.
>
>
>
> From: Jiri Kosina
> Subject: [PATCH] drm/i915: stop using GMBUS
Okay, so I think that for 3.9 we want the patch below, and if eventually
hardware root cause / workaround is found for GM45, we can have it merged
later.
From: Jiri Kosina
Subject: [PATCH] drm/i915: stop using GMBUS IRQs on Gen4 chips
Commit 28c70f162 ("drm/i915: use the gmbus irq for waits"
On Fri, 15 Mar 2013, Yinghai Lu wrote:
> > Just a datapoint -- I have put a trivial debugging patch in place, and it
> > reveals that "nobody cared" for irq 16 happens long after last
> >
> > I915_WRITE(GMBUS4 + reg_offset, 0);
> >
> > has been performed in gmbus_wait_hw_status(). On the o
gt; > > > > is
> > > > > involved.
> > > > >
> > > > > This laptop has "hybrid graphics" - one Intel GMA 4500MHD and one ATI
> > > > > Mobility Radeon HD 3650. When I boot with the Intel card, I get "irq
> > > > > 16:
t; This laptop has "hybrid graphics" - one Intel GMA 4500MHD and one ATI
>> > Mobility Radeon HD 3650. When I boot with the Intel card, I get "irq 16:
>> > nobody cared" during boot, not when I boot with the ATI card.
>>
>>
On Fri, Mar 15, 2013 at 8:14 AM, Jiri Kosina wrote:
> Just a datapoint -- I have put a trivial debugging patch in place, and it
> reveals that "nobody cared" for irq 16 happens long after last
>
> I915_WRITE(GMBUS4 + reg_offset, 0);
>
> has been performed in gmbus_wait_hw_status(). On the
Intel GMA 4500MHD and one ATI
> > > > > Mobility Radeon HD 3650. When I boot with the Intel card, I get "irq
> > > > > 16:
> > > > > nobody cared" during boot, not when I boot with the ATI card.
> > > >
> > > > Conf
"hybrid graphics" - one Intel GMA 4500MHD and one ATI
> > > > Mobility Radeon HD 3650. When I boot with the Intel card, I get "irq 16:
> > > > nobody cared" during boot, not when I boot with the ATI card.
> > >
> > > Confirming this. Af
On Fri, 15 Mar 2013, Greg KH wrote:
> > > I have the same problem on my Lenovo T500. I think the graphics card is
> > > involved.
> > >
> > > This laptop has "hybrid graphics" - one Intel GMA 4500MHD and one ATI
> > > Mobility Radeon
4500MHD and one ATI
> > Mobility Radeon HD 3650. When I boot with the Intel card, I get "irq 16:
> > nobody cared" during boot, not when I boot with the ATI card.
>
> Confirming this. After a lot of hassle, I have bisected this reliably to
>
> com
On Fri, 15 Mar 2013, Jiri Kosina wrote:
> > I have the same problem on my Lenovo T500. I think the graphics card is
> > involved.
> >
> > This laptop has "hybrid graphics" - one Intel GMA 4500MHD and one ATI
> > Mobility Radeon HD 3650. When I boot with t
On Fri, 15 Mar 2013, Harald Arnesen wrote:
> I have the same problem on my Lenovo T500. I think the graphics card is
> involved.
>
> This laptop has "hybrid graphics" - one Intel GMA 4500MHD and one ATI
> Mobility Radeon HD 3650. When I boot with the Intel card, I ge
I have the same problem on my Lenovo T500. I think the graphics card is
involved.
This laptop has "hybrid graphics" - one Intel GMA 4500MHD and one ATI
Mobility Radeon HD 3650. When I boot with the Intel card, I get "irq 16:
nobody cared" during boot, not when I boot with the
On Thu, 14 Mar 2013, Rafael J. Wysocki wrote:
> > > commit 181380b702eee1a9aca51354d7b87c7b08541fcf
> > > Author: Yinghai Lu
> > > Date: Sat Feb 16 11:58:34 2013 -0700
> > >
> > > PCI/ACPI: Don't cache _PRT, and don't associate them with bus numbers
> >
> > This patch __fixed__ this probl
On Wed, Mar 13, 2013 at 2:35 PM, Jiri Kosina wrote:
> OK, this is a "me too", on Thinkpad x200s.
>
> [ 4.116847] irq 16: nobody cared (try booting with the "irqpoll" option)
> [4.116849] Pid: 1, comm: systemd Not tainted 3.9.0-rc2-00188-g6c23cbb
On Thu, 2013-03-14 at 18:22 +0100, Rafael J. Wysocki wrote:
> On Thursday, March 14, 2013 01:06:04 PM Peter Hurley wrote:
> > On Thu, 2013-03-14 at 17:46 +0100, Rafael J. Wysocki wrote:
> > > On Thursday, March 14, 2013 05:09:59 PM Jiri Kosina wrote:
> > > > On Thu, 14 Mar 2013, Jiri Kosina wrote:
On Thursday, March 14, 2013 01:06:04 PM Peter Hurley wrote:
> On Thu, 2013-03-14 at 17:46 +0100, Rafael J. Wysocki wrote:
> > On Thursday, March 14, 2013 05:09:59 PM Jiri Kosina wrote:
> > > On Thu, 14 Mar 2013, Jiri Kosina wrote:
> > >
> > > > > > I don't think I have seen this message on rc1+ (8
On Thu, 2013-03-14 at 17:46 +0100, Rafael J. Wysocki wrote:
> On Thursday, March 14, 2013 05:09:59 PM Jiri Kosina wrote:
> > On Thu, 14 Mar 2013, Jiri Kosina wrote:
> >
> > > > > I don't think I have seen this message on rc1+ (8343bce, to be
> > > > > precise),
> > > > > but I have definitely se
On Thu, 2013-03-14 at 17:09 +0100, Jiri Kosina wrote:
> On Thu, 14 Mar 2013, Jiri Kosina wrote:
>
> > > > I don't think I have seen this message on rc1+ (8343bce, to be
> > > > precise),
> > > > but I have definitely seen sluggish system response on that kernel as
> > > > well.
> > > >
> > > >
On Thursday, March 14, 2013 05:09:59 PM Jiri Kosina wrote:
> On Thu, 14 Mar 2013, Jiri Kosina wrote:
>
> > > > I don't think I have seen this message on rc1+ (8343bce, to be
> > > > precise),
> > > > but I have definitely seen sluggish system response on that kernel as
> > > > well.
> > > >
>
On Thu, 14 Mar 2013, Jiri Kosina wrote:
> > There have been only three significant changes to uhci-hcd since last
> > summer, and two of them appear to be completely unrelated to this
> > issue. The three commits are
> >
> > 3171fcabb169 USB: uhci: beautify source code
> > 13996ca7afd
On Thu, 14 Mar 2013, Jiri Kosina wrote:
> I have reverted all three commits, and the "nobody cared" is still there.
>
> > If you revert all three and still see the problem then it must be
> > caused by changes outside of the USB stack. Differences in interrupt
> > routing could be a result of c
On Thu, 14 Mar 2013, Jiri Kosina wrote:
> > > I don't think I have seen this message on rc1+ (8343bce, to be precise),
> > > but I have definitely seen sluggish system response on that kernel as
> > > well.
> > >
> > > Attaching lspci, /proc/interrupts and dmesg.
> >
> > Can you try to do a g
On Thu, 14 Mar 2013, Jiri Kosina wrote:
> > Is occurrence of the "nobody cared" connected with any particular
> > device? Somebody reported a similar problem not long ago (although IIRC
> > it was for OHCI rather than UHCI) which appeared to be related to
> > activity on the built-in webcam.
>
On Thu, 14 Mar 2013, Alan Stern wrote:
> > > Can you try to do a git bisect for this? Is the sluggish system
> > > response clear enough that you can tell reliably when it is present and
> > > when it isn't?
> >
> > That was my first thought, but unfortunately I am afraid there will be
> > po
On Thu, 14 Mar 2013, Jiri Kosina wrote:
> On Thu, 14 Mar 2013, Alan Stern wrote:
>
> > > [ 4.116847] irq 16: nobody cared (try booting with the "irqpoll"
> > > option)
> > > [4.116849] Pid: 1, comm: systemd Not tainted 3.9.0-rc2-00188-g6c23cbb
On Thu, 14 Mar 2013, Alan Stern wrote:
> > [4.116847] irq 16: nobody cared (try booting with the "irqpoll" option)
> > [4.116849] Pid: 1, comm: systemd Not tainted 3.9.0-rc2-00188-g6c23cbb
> > #186
> > [4.116850] Call Trace:
> > [4.
On Wed, 13 Mar 2013, Jiri Kosina wrote:
> OK, this is a "me too", on Thinkpad x200s.
>
> [ 4.116847] irq 16: nobody cared (try booting with the "irqpoll" option)
> [4.116849] Pid: 1, comm: systemd Not tainted 3.9.0-rc2-00188-g6c23cbb #186
> [4.
[ +linux-pci, +linux-acpi, +Rafael Wysocki, +Bjorn Helgaas ]
On Sat, 2013-03-09 at 09:53 +0100, Thomas Meyer wrote:
> Am Freitag, den 08.03.2013, 21:19 -0500 schrieb Alan Stern:
> > On Fri, 8 Mar 2013, Peter Hurley wrote:
> >
> > > [ +linux-usb ]
> > >
> > > On Fri, 2013-03-08 at 14:12 -0500, Sh
Am Freitag, den 08.03.2013, 21:19 -0500 schrieb Alan Stern:
> On Fri, 8 Mar 2013, Peter Hurley wrote:
>
> > [ +linux-usb ]
> >
> > On Fri, 2013-03-08 at 14:12 -0500, Shawn Starr wrote:
> > > Hello folks,
> > >
> > > I am noticing since rc0 and now rc1, very poor interrupt handling.
> > > Keyboa
On Fri, 8 Mar 2013, Peter Hurley wrote:
> [ +linux-usb ]
>
> On Fri, 2013-03-08 at 14:12 -0500, Shawn Starr wrote:
> > Hello folks,
> >
> > I am noticing since rc0 and now rc1, very poor interrupt handling. Keyboard
> > response, mouse movements, display refreshing etc. General input/display
>
/input/input7
> [1.883668] hid-generic 0003:0D8C:0105.0001: input,hidraw0: USB HID v1.00
> Device [C-Media Electronics Inc. USB Multimedia Audio Device] on
> usb-:00:1d.7-1.2/input3
> [1.950222] usb 2-1.3: new high-speed USB device number 7 using ehci-pci
> [ 1.969193]
-:00:1d.7-1.2/input3
[1.950222] usb 2-1.3: new high-speed USB device number 7 using ehci-pci
[1.969193] irq 16: nobody cared (try booting with the "irqpoll" option)
[1.969254] Pid: 0, comm: swapper Not tainted 3.9.0-rc1+ #24
[1.969256] Call Trace:
[
09:02:36 ...
kernel:Disabling IRQ #16
Looking at IRQ16:
[root@xenhost xen]# cat /proc/interrupts | grep 16
16:190 xen-pirq-ioapic-level sata_mv
I also see this in the dmesg:
irq 16: nobody cared (try booting with the "irqpoll" option)
Pid: 0, comm: swapper/0 Not tainted 3.7.2-1.el6xen.x
82 matches
Mail list logo
