On Tue, 2017-01-31 at 09:54 +0100, Ingo Molnar wrote:
> > Fast ain't gonna happen, 5bf728f02218 bricked.
>
> :-/
>
> Next point would be f9a42e0d58cf I suspect, to establish that Linus's latest
> kernel is fine. That means it's in one of the ~200 -tip commits - should be
> bisectable in 8-10 steps from that point on.
It bisected cleanly to the below, confirmed via quilt push/pop revert.
According to the symptoms my box exhibits, patchlet needs to be
twiddled to ensure that interrupts are enabled at _least_ once ;-)
08d85f3ea99f1eeafc4e8507936190e86a16ee8c is the first bad commit
commit 08d85f3ea99f1eeafc4e8507936190e86a16ee8c
Author: Marc Zyngier <marc.zyng...@arm.com>
Date: Tue Jan 17 16:00:48 2017 +0000
irqdomain: Avoid activating interrupts more than once
Since commit f3b0946d629c ("genirq/msi: Make sure PCI MSIs are
activated early"), we can end-up activating a PCI/MSI twice (once
at allocation time, and once at startup time).
This is normally of no consequences, except that there is some
HW out there that may misbehave if activate is used more than once
(the GICv3 ITS, for example, uses the activate callback
to issue the MAPVI command, and the architecture spec says that
"If there is an existing mapping for the EventID-DeviceID
combination, behavior is UNPREDICTABLE").
While this could be worked around in each individual driver, it may
make more sense to tackle the issue at the core level. In order to
avoid getting in that situation, let's have a per-interrupt flag
to remember if we have already activated that interrupt or not.
Fixes: f3b0946d629c ("genirq/msi: Make sure PCI MSIs are activated early")
Reported-and-tested-by: Andre Przywara <andre.przyw...@arm.com>
Signed-off-by: Marc Zyngier <marc.zyng...@arm.com>
Cc: sta...@vger.kernel.org
Link:
http://lkml.kernel.org/r/1484668848-24361-1-git-send-email-marc.zyng...@arm.com
Signed-off-by: Thomas Gleixner <t...@linutronix.de>
:040000 040000 eed859b1f22b822f4400e7c050929d8b4c4a146d
39097c0315a12c0a3809bb82687fa56b1c9e5633 M include
:040000 040000 7dfe2ca8e1de55e890d0e6a761bab9c07c6f5f8a
e28a3a54a68866273b474e2053b16155987e06f2 M kernel
