[Bug 111601] New: regression: deadlock-freeze due to kernel commit aa56a292ce623734ddd30f52d73f527d1f3529b5

bugzilla-daemon at freedesktop.org bugzilla-daemon at freedesktop.org
Mon Sep 9 09:49:13 UTC 2019


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

            Bug ID: 111601
           Summary: regression: deadlock-freeze due to kernel commit
                    aa56a292ce623734ddd30f52d73f527d1f3529b5
           Product: DRI
           Version: unspecified
          Hardware: x86-64 (AMD64)
                OS: Linux (All)
            Status: NEW
          Severity: major
          Priority: not set
         Component: DRM/Intel
          Assignee: intel-gfx-bugs at lists.freedesktop.org
          Reporter: howaboutsynergy at pm.me
        QA Contact: intel-gfx-bugs at lists.freedesktop.org
                CC: intel-gfx-bugs at lists.freedesktop.org

In kernel 5.3.0-rc8 with commit aa56a292ce623734ddd30f52d73f527d1f3529b5
present(bisected), only on Intel/i915 computer (not on AMD/Radeon laptop) I can
easily reproduce a deadlock-like freeze of the entire system which apparently
lasts indefinitely. Sysrq still works but the CPU/fans go low speed and there's
no disk activity.

Apparently this freeze happens during low memory / memory pressure situations.
I've encountered the freeze during chromium compilation (possibly due to jumbo
build being in use which means it uses much RAM, I've 32G RAM total)

I tried to post about this on the issue that that commit references here:
https://bugzilla.kernel.org/show_bug.cgi?id=203317#c4

Not sure what more info to give at this point, please let me know.

Ah, the way I can easily reproduce this is by running the memfreeze (variant 1)
script from here:
https://gist.github.com/howaboutsynergy/d9818dcf462c071251a236787d8fbea6#file-memfreeze
But in order to avoid the usual disk-reading freeze/crawl, I'm also using the
le9i.patch from here:
https://gist.github.com/howaboutsynergy/cbfa3cc5e8093c26c29f5d411c16e6b1/941ebb19cb493fb1d090475fafc57d4f4c2638ef
(but le9h.patch is enough though, it just keeps `Active(file)` above 300MiB
during memory pressure; whilst le9i.patch also keeps `Inactive(file)` above
64MiB - but this is not necessary) 

le9h.patch is here:
https://gist.github.com/howaboutsynergy/04fd9be927835b055ac15b8b64658e85/166cb58f454f2bdae26cbe219b919084cddfc657

Note that even without those patches, I can still cause this deadlock freeze
and I know that it's not the disk-reading freeze that le9*.patch is solving
because it lacks any disk activity and fans are slow speed, also mouse is
frozen forever and it doesn't snap back to normal after the specified
timeout(for 'stress' command).

The only reason I think it's about i915 is because of:
1. "i915" in the stacktrace in Comment 1 here
https://bugzilla.kernel.org/show_bug.cgi?id=203317#c1
2. it only happens on my Intel(i915) computer, not on Amd/Radeon laptop(I
simply cannot reproduce the freeze on the AMD one)

-- 
You are receiving this mail because:
You are the QA Contact for the bug.
You are on the CC list 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/20190909/4080f419/attachment.html>


More information about the intel-gfx-bugs mailing list