All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jiang Liu <jiang.liu@linux.intel.com>
To: Thomas Gleixner <tglx@linutronix.de>,
	"Rafael J. Wysocki" <rjw@rjwysocki.net>
Cc: Borislav Petkov <bp@alien8.de>, x86-ml <x86@kernel.org>,
	lkml <linux-kernel@vger.kernel.org>,
	Peter Zijlstra <peterz@infradead.org>
Subject: Re: rc7 + tip/master suspend fun
Date: Tue, 29 Jul 2014 10:17:16 +0800	[thread overview]
Message-ID: <53D7042C.1040404@linux.intel.com> (raw)
In-Reply-To: <alpine.DEB.2.10.1407282255120.23352@nanos>

Hi Borislav, Thomas and Rafael,
	Thanks for testing and reporting this issue.
	I guess the issue is that, we shouldn't release IOAPIC
pin reference count when suspend/hibernate system. I'm reading
PM code and working on a solution for this issue. The basic
idea is to register an PM notifier to stop releasing IOAPIC
pin count during system suspend/hibernate/resume.
	Hi Rafael, is that the right direction to go?

Regards!
Gerry

On 2014/7/29 5:02, Thomas Gleixner wrote:
> On Mon, 28 Jul 2014, Rafael J. Wysocki wrote:
>> On Monday, July 28, 2014 07:53:26 PM Borislav Petkov wrote:
>>>
>>> --Nq2Wo0NMKNjxTN9z
>>> Content-Type: text/plain; charset=utf-8
>>> Content-Disposition: inline
>>>
>>> Hi guys,
>>>
>>> so during my rc7 + tip/master testing today, I've hit the second WARN
>>> in remove_proc_entry, see attached pic. This happens right before I
>>> suspend to disk and I can't successfully suspend because sda gets choked
>>> afterwards and floods dmesg with something-has-timeout messages which I
>>> can't read - whizzing by too fast.
>>>
>>> And this seems consistent with the warning because sda1 is behind AHCI
>>> for which the warning is for.
>>>
>>> Oh, and I'm saying it is tip/master-related because plain rc7 is fine.
>>>
>>> Other strange things I was able to observe in dmesg between plain rc7
>>> and rc7+tip/master are that something in the interrupts allocation is
>>> different now (plenty of movement in that area recently) leading to the
>>> following diffs between dmesg:
>>>
>>> --- 16-rc7	2014-07-28 19:43:13.000000000 +0200
>>> +++ 16-rc7+	2014-07-28 11:11:24.000000000 +0200
>>>
>>> @@ -137,11 +138,9 @@ IOAPIC[1]: apic_id 10, version 33, addre
>>>  ACPI: INT_SRC_OVR (bus 0 bus_irq 0 global_irq 2 dfl dfl)
>>>  ACPI: INT_SRC_OVR (bus 0 bus_irq 9 global_irq 9 low level)
>>>  ACPI: IRQ0 used by override.
>>> -ACPI: IRQ2 used by override.
>>>  ACPI: IRQ9 used by override.
>>>  Using ACPI (MADT) for SMP configuration information
>>>  smpboot: Allowing 8 CPUs, 0 hotplug CPUs
>>> -nr_irqs_gsi: 72
>>>  PM: Registered nosave memory: [mem 0x0009e000-0x0009efff]
>>>  PM: Registered nosave memory: [mem 0x0009f000-0x0009ffff]
>>>  PM: Registered nosave memory: [mem 0x000a0000-0x000dffff]
>>>
>>> that gsi thing went away, apparently.
>>>
>>> -NR_IRQS:4352 nr_irqs:1288 16
>>> +NR_IRQS:4352 nr_irqs:1032 0
>>>
>>> fun.
> 
> Right, that's from Jiangs ioapic rework.
>  
>>> And then something lead to different interrupts being assigned:
>>>
>>> -pci 0000:00:00.2: irq 72 for MSI/MSI-X
>>> +pci 0000:00:00.2: irq 27 for MSI/MSI-X
>>>
>>> -ahci 0000:04:00.0: irq 73 for MSI/MSI-X
>>> +ahci 0000:04:00.0: irq 29 for MSI/MSI-X
> 
> Borislav, can you please upload a full bootlog with "apic=verbose" on
> the commandline?
> 
> Jiang, can you please have a look?
>  
>>> and lookie lookie, it is ahci which changes IRQ lines.
>>>
>>> Suggestions and ideas how to narrow down are appreciated.
>>
>> Please try to revert this patch from Peter:
>>
>> http://marc.info/?l=linux-kernel&m=140620918218199
> 
> How is that related to a leaked interrupt handler? That patch gives a
> splat at request_irq() time. Completely unrelated to this problem.
> 
> Thanks,
> 
> 	tglx
> 

  parent reply	other threads:[~2014-07-29  2:17 UTC|newest]

Thread overview: 24+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <20140728175326.GA7100@pd.tnic>
2014-07-28 20:59 ` rc7 + tip/master suspend fun Rafael J. Wysocki
2014-07-28 21:02   ` Thomas Gleixner
2014-07-28 22:02     ` Rafael J. Wysocki
2014-07-29  2:17     ` Jiang Liu [this message]
2014-07-30  9:37     ` [PATCH] x86, irq: Keep IRQ assignment for PCI devices during suspend/hibernation Jiang Liu
2014-07-30 17:58       ` Borislav Petkov
2014-07-31  0:33         ` Jiang Liu
2014-07-31 10:39           ` Borislav Petkov
2014-07-31 14:41             ` Jiang Liu
2014-07-31 14:41               ` Jiang Liu
2014-07-31 15:21               ` Borislav Petkov
2014-07-31 15:21                 ` Borislav Petkov
2014-07-31 16:36             ` Jiang Liu
2014-07-31 16:56               ` Borislav Petkov
2014-08-01 10:56                 ` [PATCH] x86, irq: Keep IRQ assignment for PCI devices during suspend/hibernation, bisected Borislav Petkov
2014-08-01 12:27                   ` Jiang Liu
2014-08-01 14:39                     ` Borislav Petkov
2014-08-01 16:11                       ` Borislav Petkov
2014-08-01 22:14                         ` Jörg Rödel
2014-08-01 22:50                           ` Borislav Petkov
2014-08-02  2:25                             ` [PATCH] iommu/amd: Implement syscore_ops.shutdown() Jiang Liu
2014-08-02  2:25                               ` Jiang Liu
2014-08-04 10:12                               ` Borislav Petkov
2014-08-04 10:12                                 ` Borislav Petkov

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=53D7042C.1040404@linux.intel.com \
    --to=jiang.liu@linux.intel.com \
    --cc=bp@alien8.de \
    --cc=linux-kernel@vger.kernel.org \
    --cc=peterz@infradead.org \
    --cc=rjw@rjwysocki.net \
    --cc=tglx@linutronix.de \
    --cc=x86@kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.