On Thu, Jun 21, 2012 at 02:55:22PM +0200, Daniel Vetter 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. > > 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. > > 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> I've picked this one up for -fixes. -Daniel -- Daniel Vetter Mail: daniel at ffwll.ch Mobile: +41 (0)79 365 57 48
