On Mon, Mar 18, 2013 at 2:12 AM, Jiri Kosina <jkosina@xxxxxxx> 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. What is /proc/interrupts difference between with and without pci=nomsi ? drm is forced to share irq 16? Thanks Yinghai -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
