All of lore.kernel.org
 help / color / mirror / Atom feed
From: bugzilla-daemon@freedesktop.org
To: dri-devel@lists.freedesktop.org
Subject: [Bug 93718] nouveau + moveablecore => endless havoc (possibly a general drm problem)
Date: Thu, 14 Jan 2016 20:54:28 +0000	[thread overview]
Message-ID: <bug-93718-502@http.bugs.freedesktop.org/> (raw)


[-- Attachment #1.1: Type: text/plain, Size: 2255 bytes --]

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

            Bug ID: 93718
           Summary: nouveau + moveablecore => endless havoc (possibly a
                    general drm problem)
           Product: DRI
           Version: XOrg git
          Hardware: Other
                OS: All
            Status: NEW
          Severity: normal
          Priority: medium
         Component: General
          Assignee: dri-devel@lists.freedesktop.org
          Reporter: rwhite@pobox.com

NOTE: I'm actually using the gentoo x11 overlay which seems to be an xorg
git...

So reserving movable core on the linux command line seems to cause random
failure in my nouveau dual monitor desktop system. (I suspect it's happening to
a lessor extent on my radeon laptop as well).

So anyway, I've been using "moveablecore=2G" on my kernel command line for some
time in order to accommodate hugepages (etc) for transient virtual machines.
When I started playing with SDDM and kde Plasma I started getting display
hangs.

The exact moment and error of the hang/error is hard to catch, but just
starting sddm is enough to cause my dmesg to fill with faults. They all looked
memory/state related so I started playing around.

With no kernelcore= or moveablecore= options on the kernel command line the
system seems rock steady.

Using either (they both reserve a movable memory NUMA region that anonymous
mappings via mmap() "like" and the kernel is free to relocate by juggling page
tables and copying physical images) seems to steal data will-he/nil-he out from
under nouveau.

ASIDE: I say it may be happening on my radeon laptop because Chromium gets
render-hung there for odd reasons but the diagnostics are more vague.

So the work-around is to not use these options, but I suspect there's some
missing page locking or whatever creating phantom failures... particularly in
nouveau... particularly under high render pressure.

With "moveablecore=2G kernelcore=3G" I can't even get all the way through the
sddm password entry without a messy crash.

This seems to line up with a lot of can-not-duplicate type of error reports I
found with google, so I figure'd I drop my datapoint here.

-- 
You are receiving this mail because:
You are the assignee for the bug.

[-- Attachment #1.2: Type: text/html, Size: 3523 bytes --]

[-- Attachment #2: Type: text/plain, Size: 159 bytes --]

_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

             reply	other threads:[~2016-01-14 20:54 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-01-14 20:54 bugzilla-daemon [this message]
2019-10-14 13:20 ` [Bug 93718] nouveau + moveablecore => endless havoc (possibly a general drm problem) bugzilla-daemon

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=bug-93718-502@http.bugs.freedesktop.org/ \
    --to=bugzilla-daemon@freedesktop.org \
    --cc=dri-devel@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.