On Thu, 21 Jun 2012 14:55:22 +0200, Daniel Vetter <daniel.vetter at ffwll.ch> wrote: > After banging my head against this for the past few months, I still > don't see how this could possible race under the premise that once an > irq bit is masked in PM_IMR and reset in PM_IIR it won't show up again > until we unmask it in PM_IMR. > > Still, we have reports of this being seen in the wild. Now Bspec has > this little bit of lovely language in the PMIIR register: > > Public SNB Docs, Vol3Part2, 2.5.14 "PMIIR": > > "For each bit, the IIR can store a second pending interrupt if two or > more of the same interrupt conditions occur before the first condition > is cleared. Upon clearing the interrupt, the IIR bit will momentarily > go low, then return high to indicate there is another interrupt > pending." > > Now if we presume that PMIMR only prevent new interrupts from being > queued, we could easily end up masking an interrupt and clearing it, > but the 2nd pending interrupt setting the bit in PMIIR right away > again. Which leads, the next time the irq handler runs, to hitting the > WARN. Ok, if we suppose that the PMIMR is only applied when the interrupt is asserted in the double-buffered register rather than on transfer of that backing register into PMIIR, I can see how that would lead to hitting the WARN as you outlined. > Also, no bad side effects of this have ever been reported. And we've > tracked down our issues with the gpu turbo getting stuck to bogus > interrupt generation limits in th RPLIMIT register. True, our current usage is simply to poke the rps up/down, and so if we miss an interrupt we simply get another one a few milliseconds later (presumably) in the same direction. > So let's just rip out this WARN as bogus and call it a day. The only > shallow thing here is that this 2-deep irq queue in the hw makes you > wonder how racy the windows irq handler is ... > > Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=42907 > Cc: stable at vger.kernel.org > Signed-Off-by: Daniel Vetter <daniel.vetter at ffwll.ch> Acked-by: Chris Wilson <chris at chris-wilson.co.uk> If we cared we could request a BUN to clarify when the mask is applied. -Chris -- Chris Wilson, Intel Open Source Technology Centre
