From: Christian Kastner <debian@kvr.at>
Cc: intel-gfx@lists.freedesktop.org
Subject: Re: Macbook Air 6, 2: i915-related interrupt storm after Yosemite update
Date: Tue, 18 Nov 2014 22:07:43 +0100 [thread overview]
Message-ID: <546BB51F.2060400@kvr.at> (raw)
In-Reply-To: <20141103152523.GV26941@phenom.ffwll.local>
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@intel.com>
> 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@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
next prev parent reply other threads:[~2014-11-18 21:07 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-11-01 17:08 Macbook Air 6, 2: i915-related interrupt storm after Yosemite update Christian Kastner
2014-11-03 15:25 ` Daniel Vetter
2014-11-18 21:07 ` Christian Kastner [this message]
2015-02-11 9:00 ` Macbook Air 6, 2: i915-related interrupt storm after Yosemite update -- resolved Christian Kastner
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=546BB51F.2060400@kvr.at \
--to=debian@kvr.at \
--cc=intel-gfx@lists.freedesktop.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.