[Nouveau] [Bug 76319] [NVE6] MMIO FAULT, black screen on QHD+ K2100M

2014-03-19 Thread bugzilla-daemon
https://bugs.freedesktop.org/show_bug.cgi?id=76319 --- Comment #2 from D. Moens d-bugzi...@moens.cc --- Ilia, thank you for your instantaneous reply. (In reply to comment #1) I think you may be the proud owner of multiple issues, as evidenced by the gpu lockup you get down the line. Thanks, I

[Nouveau] [Bug 76319] [NVE6] MMIO FAULT, black screen on QHD+ K2100M

2014-03-19 Thread bugzilla-daemon
https://bugs.freedesktop.org/show_bug.cgi?id=76319 D. Moens d-bugzi...@moens.cc changed: What|Removed |Added Attachment #95999|0 |1 is obsolete|

[Nouveau] [Bug 76319] [NVE6] MMIO FAULT, black screen on QHD+ K2100M

2014-03-19 Thread bugzilla-daemon
https://bugs.freedesktop.org/show_bug.cgi?id=76319 --- Comment #4 from D. Moens d-bugzi...@moens.cc --- Created attachment 96043 -- https://bugs.freedesktop.org/attachment.cgi?id=96043action=edit # journalctl -b -p err errors.out -- You are receiving this mail because: You are the assignee

[Nouveau] [Bug 76319] [NVE6] MMIO FAULT, black screen on QHD+ K2100M

2014-03-19 Thread bugzilla-daemon
https://bugs.freedesktop.org/show_bug.cgi?id=76319 --- Comment #5 from D. Moens d-bugzi...@moens.cc --- Created attachment 96044 -- https://bugs.freedesktop.org/attachment.cgi?id=96044action=edit # journalctl -b /usr/bin/X X.out -- You are receiving this mail because: You are the assignee

[Nouveau] [Bug 76319] [NVE6] MMIO FAULT, black screen on QHD+ K2100M

2014-03-19 Thread bugzilla-daemon
https://bugs.freedesktop.org/show_bug.cgi?id=76319 --- Comment #6 from D. Moens d-bugzi...@moens.cc --- Created attachment 96045 -- https://bugs.freedesktop.org/attachment.cgi?id=96045action=edit # lspci -vv (limited to graphics adapter) -- You are receiving this mail because: You are the

[Nouveau] [Bug 76319] [NVE6] MMIO FAULT, black screen on QHD+ K2100M

2014-03-19 Thread bugzilla-daemon
https://bugs.freedesktop.org/show_bug.cgi?id=76319 --- Comment #7 from Ilia Mirkin imir...@alum.mit.edu --- (In reply to comment #2) Patched : $ diff nouveau/nvkm/engine/disp/dport.c.orig nouveau/nvkm/engine/disp/dport.c 276c276 const u32 bw_list[] = { 27, 162000, 0 }; ---

[Nouveau] [PATCH] disp/nvd0-: allow 540MHz data rate for nvd0+ devices

2014-03-19 Thread Ilia Mirkin
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=76319 Signed-off-by: Ilia Mirkin imir...@alum.mit.edu --- It's unclear to me whether GF11x devices actually support this, but the disp split is at nvd0, so I went with that. The marketing docs are fairly unclear. However most of them don't

[Nouveau] [PATCH v2] disp/nvd0-: allow 540MHz data rate for nvd0+ devices

2014-03-19 Thread Ilia Mirkin
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=76319 Signed-off-by: Ilia Mirkin imir...@alum.mit.edu --- It's unclear to me whether GF11x devices actually support this, but the disp split is at nvd0, so I went with that. The marketing docs are fairly unclear. However most of them don't

[Nouveau] [PATCH] drm: compute runpm on load, don't register autosuspend for non-runpm

2014-03-19 Thread Ilia Mirkin
There was a proliferation of duplicated checks for runpm == -1 optimus. Instead of continuing that tradition, get rid of all of them, only doing the optimus computation once on load. This should hopefully fix secondary cards suspending and then being unable to come back in non-optimus setups.

Re: [Nouveau] [PATCH v2] disp/nvd0-: allow 540MHz data rate for nvd0+ devices

2014-03-19 Thread Ben Skeggs
On Thu, Mar 20, 2014 at 12:45 AM, Ilia Mirkin imir...@alum.mit.edu wrote: Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=76319 Signed-off-by: Ilia Mirkin imir...@alum.mit.edu --- It's unclear to me whether GF11x devices actually support this, but the disp split is at nvd0, so I went

Re: [Nouveau] [PATCH] drm: compute runpm on load, don't register autosuspend for non-runpm

2014-03-19 Thread Ben Skeggs
On Thu, Mar 20, 2014 at 1:28 AM, Ilia Mirkin imir...@alum.mit.edu wrote: There was a proliferation of duplicated checks for runpm == -1 optimus. Instead of continuing that tradition, get rid of all of them, only doing the optimus computation once on load. This should hopefully fix secondary

Re: [Nouveau] [PATCH] drm: compute runpm on load, don't register autosuspend for non-runpm

2014-03-19 Thread David Airlie
On Thu, Mar 20, 2014 at 1:28 AM, Ilia Mirkin imir...@alum.mit.edu wrote: There was a proliferation of duplicated checks for runpm == -1 optimus. Instead of continuing that tradition, get rid of all of them, only doing the optimus computation once on load. This should hopefully fix

Re: [Nouveau] [PATCH] drm: compute runpm on load, don't register autosuspend for non-runpm

2014-03-19 Thread Ilia Mirkin
On Wed, Mar 19, 2014 at 7:45 PM, David Airlie airl...@redhat.com wrote: On Thu, Mar 20, 2014 at 1:28 AM, Ilia Mirkin imir...@alum.mit.edu wrote: There was a proliferation of duplicated checks for runpm == -1 optimus. Instead of continuing that tradition, get rid of all of them, only doing

Re: [Nouveau] [PATCH] drm: compute runpm on load, don't register autosuspend for non-runpm

2014-03-19 Thread David Airlie
- Original Message - From: Ilia Mirkin imir...@alum.mit.edu To: David Airlie airl...@redhat.com Cc: Ben Skeggs skeg...@gmail.com, Ben Skeggs bske...@redhat.com, nouveau@lists.freedesktop.org Sent: Thursday, 20 March, 2014 9:49:47 AM Subject: Re: [Nouveau] [PATCH] drm: compute

Re: [Nouveau] [PATCH] drm: compute runpm on load, don't register autosuspend for non-runpm

2014-03-19 Thread Ilia Mirkin
On Wed, Mar 19, 2014 at 8:08 PM, David Airlie airl...@redhat.com wrote: - Original Message - From: Ilia Mirkin imir...@alum.mit.edu To: David Airlie airl...@redhat.com Cc: Ben Skeggs skeg...@gmail.com, Ben Skeggs bske...@redhat.com, nouveau@lists.freedesktop.org Sent: Thursday, 20

[Nouveau] [Bug 76376] New: mesa does not build after nouveau loader changes

2014-03-19 Thread bugzilla-daemon
https://bugs.freedesktop.org/show_bug.cgi?id=76376 Priority: medium Bug ID: 76376 Assignee: nouveau@lists.freedesktop.org Summary: mesa does not build after nouveau loader changes Severity: normal Classification: Unclassified