On 2014-11-03 16:25, Daniel Vetter wrote: > On Sat, Nov 01, 2014 at 06:08:00PM +0100, Christian Kastner wrote: >> >> [after upgrading dual-booted OSX to Yosemite, wich included firmware updates] >> >> Here's what I see [in Linux 3.16, 3.17]: >> >> $ GPE=/sys/firmware/acpi/interrupts/gpe66 >> $ while true; do cat $GPE; sleep 1; done >> 727268 enabled >> 757981 enabled >> 788576 enabled >> 807337 enabled >> 828426 enabled >> ... >> When I boot with modprobe.blacklist=i915, the issue disappears. >> >> Does anyone have an idea what could be going on? > > The only acpi interrupt we're handling is asle afaik, so sounds like > something we do in there doesn't please the new firmware and sends it into > a tailspin. So I'd sprinkle printks all over the place there until you > know what exactly goes on in i915, starting with the asle functions. In the meantime, I noticed that there a kernel bugzilla bug entry for this issue. https://bugzilla.kernel.org/show_bug.cgi?id=85881 It has been closed in the meantime, although AFAIUI it the solution merely forces disabling gpe66. I'd still like try resolving this by determining the cause. Before I embark on an unguided printk spree: does this analysis from the bugzilla bug perhaps somewhat narrow the issue down so that I can focus on a specific part? Comment #31 from Lv Zheng <lv.zheng@xxxxxxxxx> > The decompiled GPE 0x66 handler is as follows: > Method (_L66, 0, NotSerialized) // _Lxx: Level-Triggered GPE > { > If (LAnd (\_SB.PCI0.IGPU.GSSE, LNot (GSMI))) > { > \_SB.PCI0.IGPU.GSCI () > } > Else > { > Store (0x00, \_SB.PCI0.IGPU.GEFC) > Store (0x01, SCIS) /* \SCIS */ > Store (0x00, \_SB.PCI0.IGPU.GSSE) > Store (0x00, \_SB.PCI0.IGPU.SCIE) > } > } > It's completely GPU related. So I have no idea what has happened. > The GSMI seems to be some configuration option in the BIOS: > OperationRegion (GNVS, SystemMemory, 0x8CD3EA90, 0x026D) > Field (GNVS, AnyAcc, Lock, Preserve) > { > GSMI, 8, > } > It sounds like something was originally handled by SMI and now is reported > through GPE. So I guess there might be chances you could revert back to the > original behavior using some BIOS configuration. [note: TTBOMK no such low-level configuration is possible] Christian _______________________________________________ Intel-gfx mailing list Intel-gfx@xxxxxxxxxxxxxxxxxxxxx http://lists.freedesktop.org/mailman/listinfo/intel-gfx