On Mon, Mar 18, 2013 at 08:19:03PM +0100, Daniel Vetter wrote:
On Mon, Mar 18, 2013 at 10:12:49AM +0100, Jiri Kosina wrote:
On Fri, 15 Mar 2013, Yinghai Lu wrote:
Just a datapoint -- I have put a trivial debugging patch in place, and it reveals that "nobody cared" for irq 16 happens long after last
I915_WRITE(GMBUS4 + reg_offset, 0);has been performed in gmbus_wait_hw_status(). On the other hand, if I comment out both GMBUS4 register offset writes in gmbus_wait_hw_status(), then it of course falls back to GPIO bit-banging, but the "nobody cared" for irq 16 is gone.
So it seems like something gets severely confused by the I915_WRITE to GMBUS4 + reg_offset. So far this seems to have been reported solely on Lenovos as far as I can see (although a completely different types), so it might be some platform-specific quirk?
Honestly, I still don't understand how all the GMBUS stuff relates to IRQ 16 at all.
that device is using i915 0000:00:02.0: irq 44 for MSI/MSI-X
so can you try to boot with pci=nomsi?
Yes, switching from MSI to IO-APIC-fasteoi makes the report about lost interrupts go away.
My understanding from the other mail is that DAniel Vetter already has an idea what might be going wrong with IRQ acking on GM45 chipsets; hopefully this datapoint regarding MSI will fit into it.
Yep, there's a big comment in the irq handler for that chipset that we have a gaping race with when using MSI interrupts. Although the comment bodly claims that the race is small enough to avoid the dreaded "nobody cared" message. Looks like gmbus is good at hitting that race - on newer chips it already brought up a similar race in handling pch interrupts.
Can you please give the below patch a whirl? It removes the probably race msi race avoidance code and replaces it with the same trick Paulo used to fix pch irq handling races.
Still nobody cares about irq16. -Chris