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
30 matches
Mail list logo
