[Bug 101577] New: [HSW] System freezes when fbc is enabled and deep package states are allowed

[bugzilla-daemon at freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=101577

            Bug ID: 101577
           Summary: [HSW] System freezes when fbc is enabled and deep
                    package states are allowed
           Product: DRI
           Version: unspecified
          Hardware: x86-64 (AMD64)
                OS: Linux (All)
            Status: NEW
          Keywords: bisected
          Severity: normal
          Priority: medium
         Component: DRM/Intel
          Assignee: intel-gfx-bugs at lists.freedesktop.org
          Reporter: eryngion at protonmail.com
        QA Contact: intel-gfx-bugs at lists.freedesktop.org
                CC: intel-gfx-bugs at lists.freedesktop.org
     i915 platform: HSW
     i915 features: display/FBC, power/runtime PM

Created attachment 132219
  --> https://bugs.freedesktop.org/attachment.cgi?id=132219&action=edit
dmesg 4.4.73

Hi.

I have a MacBookPro11,2 with an i7-4750HQ CPU and trying to keep it's power
consumption low. To achieve that, I'm switching off thunderbolt interface and
enabling fbc (otherwise you will get no pc6 at all or just 2-3% of it).
Starting with kernel 4.1 this configuration leads to a complete system freeze,
usually at a random point within an hour since boot. There are no oops or bug
messages in the log file and pstore, and netconsole is of no use either, as it
works only with an thunderbolt-attached netcard, but with thunderbolt enabled
there is no freeze. On kernels 4.1-4.8 it's reproducible on almost every boot,
and on 4.9-4.12 (up to 4.12.o-rc6) I'm still catching silent freezes that
"look" the same, but much less frequently.

I've bisected the frequent freezes back to commit
dbef0f15b5c83231dacb214dbf9a6dba063ca21c "drm/i915: add frontbuffer tracking to
FBC". Can we suppose that the reason of freezes in recent kernels is still the
same and try to fix it? Or could someone give me advice on how to debug this,
other than to bisect the drop in frequency?

I also can show a couple of dmesg logs with debug on, but they're not from the
freshest kernels (4.4.73 and 4.9.33) and the 4.9.33 log unfortunately lacks
atomic messages. I'm now trying to catch the freeze on 4.12.0-rc6 with the
proper drm debug flags, but it will take some time. If a log from any other
version between 4.1 and 4.8 will help, I can easily generate it.


Steps to reproduce

Since kernel 4.7 (e.g. commit e10cfdc33a0f23dc8449be7267f0a642e96a2a24) it's
enough to boot with options acpi_osi=!Darwin acpi_osi='Windows 2012' (to
disable thunderbolt) and i915.enable_fbc=1 (to enable FBC). And, probably,
start X. But there's a couple of gotchas: the first reboot from a non-affected
kernel does not seem to freeze (or probably takes considerably more than an
hour to trigger).

On kernels 4.1-4.7 it's a little mor tricky: to disable thunderbolt you need to
revert commit 7bc5a2bad0b8d9d1ac9f7b8b33150e4ddf197334 or somehow call an ACPI
method '\_SB.PCI0.RMC1' or \_SB.PCI0.P0P2.UPSB.DSB0.NHI0.TRPE'. An out-of-tree
module acpi_call could be helpful.

And if patches from https://github.com/l1k/linux/commits/thunderbolt_runpm_v6
land in mainline, the problem will probably be visible with just
i915.enable_fbc=1.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
You are the QA Contact for the bug.
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.freedesktop.org/archives/intel-gfx-bugs/attachments/20170624/d3fa1c6c/attachment.html>