From mboxrd@z Thu Jan 1 00:00:00 1970
From: bugzilla-daemon@freedesktop.org
Subject: [Bug 93718] nouveau + moveablecore => endless havoc (possibly a
general drm problem)
Date: Thu, 14 Jan 2016 20:54:28 +0000
Message-ID:
Mime-Version: 1.0
Content-Type: multipart/mixed; boundary="===============0177161069=="
Return-path:
Received: from culpepper.freedesktop.org (unknown [131.252.210.165])
by gabe.freedesktop.org (Postfix) with ESMTP id A30A87212E
for ; Thu, 14 Jan 2016 12:54:28 -0800 (PST)
List-Unsubscribe: ,
List-Archive:
List-Post:
List-Help:
List-Subscribe: ,
Errors-To: dri-devel-bounces@lists.freedesktop.org
Sender: "dri-devel"
To: dri-devel@lists.freedesktop.org
List-Id: dri-devel@lists.freedesktop.org
--===============0177161069==
Content-Type: multipart/alternative; boundary="1452804868.f30d50.15269"; charset="UTF-8"
--1452804868.f30d50.15269
Date: Thu, 14 Jan 2016 20:54:28 +0000
MIME-Version: 1.0
Content-Type: text/plain; charset="UTF-8"
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.
--1452804868.f30d50.15269
Date: Thu, 14 Jan 2016 20:54:28 +0000
MIME-Version: 1.0
Content-Type: text/html; charset="UTF-8"
| 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.
--1452804868.f30d50.15269--
--===============0177161069==
Content-Type: text/plain; charset="utf-8"
MIME-Version: 1.0
Content-Transfer-Encoding: base64
Content-Disposition: inline
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KZHJpLWRldmVs
IG1haWxpbmcgbGlzdApkcmktZGV2ZWxAbGlzdHMuZnJlZWRlc2t0b3Aub3JnCmh0dHA6Ly9saXN0
cy5mcmVlZGVza3RvcC5vcmcvbWFpbG1hbi9saXN0aW5mby9kcmktZGV2ZWwK
--===============0177161069==--
From mboxrd@z Thu Jan 1 00:00:00 1970
From: bugzilla-daemon@freedesktop.org
Subject: [Bug 93718] nouveau + moveablecore => endless havoc (possibly a
general drm problem)
Date: Mon, 14 Oct 2019 13:20:26 +0000
Message-ID:
References:
Mime-Version: 1.0
Content-Type: multipart/mixed; boundary="===============0874226819=="
Return-path:
Received: from culpepper.freedesktop.org (culpepper.freedesktop.org
[IPv6:2610:10:20:722:a800:ff:fe98:4b55])
by gabe.freedesktop.org (Postfix) with ESMTP id D8997896C7
for ; Mon, 14 Oct 2019 13:20:27 +0000 (UTC)
In-Reply-To:
List-Unsubscribe: ,
List-Archive:
List-Post:
List-Help:
List-Subscribe: ,
Errors-To: dri-devel-bounces@lists.freedesktop.org
Sender: "dri-devel"
To: dri-devel@lists.freedesktop.org
List-Id: dri-devel@lists.freedesktop.org
--===============0874226819==
Content-Type: multipart/alternative; boundary="15710592266.20Ee05.29307"
Content-Transfer-Encoding: 7bit
--15710592266.20Ee05.29307
Date: Mon, 14 Oct 2019 13:20:26 +0000
MIME-Version: 1.0
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
X-Bugzilla-URL: http://bugs.freedesktop.org/
Auto-Submitted: auto-generated
https://bugs.freedesktop.org/show_bug.cgi?id=3D93718
Martin Peres changed:
What |Removed |Added
----------------------------------------------------------------------------
Resolution|--- |INVALID
Status|NEW |RESOLVED
--- Comment #1 from Martin Peres ---
Hi,
Freedesktop's Bugzilla instance is EOLed and open bugs are about to be migr=
ated
to http://gitlab.freedesktop.org.
To avoid migrating out of date bugs, I am now closing all the bugs that did=
not
see any activity in the past year. If the issue is still happening, please
create a new bug in the relevant project at https://gitlab.freedesktop.org/=
drm
(use misc by default).
Sorry about the noise!
--=20
You are receiving this mail because:
You are the assignee for the bug.=
--15710592266.20Ee05.29307
Date: Mon, 14 Oct 2019 13:20:26 +0000
MIME-Version: 1.0
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
X-Bugzilla-URL: http://bugs.freedesktop.org/
Auto-Submitted: auto-generated
<=
span class=3D"fn">Martin Peres
changed
bug 93718<=
/a>
| What |
Removed |
Added |
| Resolution |
---
|
INVALID
|
| Status |
NEW
|
RESOLVED
|
You are receiving this mail because:
- You are the assignee for the bug.
=
--15710592266.20Ee05.29307--
--===============0874226819==
Content-Type: text/plain; charset="utf-8"
MIME-Version: 1.0
Content-Transfer-Encoding: base64
Content-Disposition: inline
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KZHJpLWRldmVs
IG1haWxpbmcgbGlzdApkcmktZGV2ZWxAbGlzdHMuZnJlZWRlc2t0b3Aub3JnCmh0dHBzOi8vbGlz
dHMuZnJlZWRlc2t0b3Aub3JnL21haWxtYW4vbGlzdGluZm8vZHJpLWRldmVs
--===============0874226819==--