[Nouveau] [Bug 92274] nouveau black screen and errors with two monitors attached

[bugzilla-daemon]

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

--- Comment #9 from joseph-thom...@gmx.de ---
Oh I misunderstood something about the kernel sources :D.
Thougt this included more afford ;).
I configured my current kernel by myself and it is bootable except for
the multi-monitor problem.
I'm going to try it now.

-- 
You are receiving this mail because:
You are the assignee for the bug.
___
Nouveau mailing list
Nouveau@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/nouveau

[Nouveau] [Bug 92287] Display errors in Qt applications after using Android Virtual Devices

[bugzilla-daemon]

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

--- Comment #3 from Guido Winkelmann  ---
Correction:

It just happened again, and this time, even application that have been running
the whole time are affected.

-- 
You are receiving this mail because:
You are the QA Contact for the bug.
You are the assignee for the bug.
___
Nouveau mailing list
Nouveau@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/nouveau

[Nouveau] [Bug 92287] Display errors in Qt applications after using Android Virtual Devices

[bugzilla-daemon]

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

--- Comment #4 from Ilia Mirkin  ---
Seems like something may have gotten overwritten (like the background texture
was made to be fully transparent). Odd.

You might try with mesa-git -- there are a handful of patches on there that
deal with resource lifetime issues, but I doubt it will do anything to resolve
your problem.

-- 
You are receiving this mail because:
You are the QA Contact for the bug.
You are the assignee for the bug.
___
Nouveau mailing list
Nouveau@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/nouveau

[Nouveau] [Bug 92274] nouveau black screen and errors with two monitors attached

[bugzilla-daemon]

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

--- Comment #7 from joseph-thom...@gmx.de ---
Oh these two video options were for testing and did not show any effect.
I accidently took this kernel log, but the other ones without these options
looked the same.
I'm not that into compiling everything on my own (except for some of the easy
or
self written parts; or when gentoo does it for me ;)), but I'm willing to learn
and been always looking for a good reason to get myself doing something like
this
and not thinking that others will do it or that it does not have enough
advantages.

So just that I got it right:
I get the source code from the nouveau git repository,
change the affected code parts, follow the instructions in the readme etc.
and compile nouveau as a module to load it.

Is it enough that I just download a snapshot and do a out-of-tree compilation?
Is it compatible with my kernel?
(because it says it contains the 3.x versions and my version is 4)
Which settings do I need to enable in my kernel that are not trivial?

Sorry for so many questions, but I'd really like to get this done.

-- 
You are receiving this mail because:
You are the assignee for the bug.
___
Nouveau mailing list
Nouveau@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/nouveau

[Nouveau] [Bug 92274] nouveau black screen and errors with two monitors attached

[bugzilla-daemon]

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

--- Comment #8 from Ilia Mirkin  ---
(In reply to joseph-thommes from comment #7)
> Oh these two video options were for testing and did not show any effect.
> I accidently took this kernel log, but the other ones without these options
> looked the same.
> I'm not that into compiling everything on my own (except for some of the
> easy or
> self written parts; or when gentoo does it for me ;)), but I'm willing to
> learn
> and been always looking for a good reason to get myself doing something like
> this
> and not thinking that others will do it or that it does not have enough
> advantages.
> 
> So just that I got it right:
> I get the source code from the nouveau git repository,
> change the affected code parts, follow the instructions in the readme etc.
> and compile nouveau as a module to load it.
> 
> Is it enough that I just download a snapshot and do a out-of-tree
> compilation?
> Is it compatible with my kernel?
> (because it says it contains the 3.x versions and my version is 4)
> Which settings do I need to enable in my kernel that are not trivial?
> 
> Sorry for so many questions, but I'd really like to get this done.

Doesn't matter what code you grab, it should basically be the same for the past
many kernel versions. Nouveau got a bit of a rewrite in 4.3, so the code might
look a bit different if you use an older kernel, but it's the same idea.

If this is your first time compiling a kernel, then it might get a bit tricky.
First grab a kernel, compile it, make sure you can boot it, and *then* make the
relevant changes.

-- 
You are receiving this mail because:
You are the assignee for the bug.
___
Nouveau mailing list
Nouveau@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/nouveau

[Nouveau] [PATCH] nouveau: make sure there's always room to emit a fence

[Ilia Mirkin]

I started seeing a lot of situations on nv30 where fence emission
wouldn't fit into the previous buffer (causing assertions). This ensures
that whenever checking for space, we always leave a bit of extra room
for the fence emission commands. Adjusts the nv30 and nvc0 fence
emission logic to bypass the space checking as well.

Signed-off-by: Ilia Mirkin 
Cc: mesa-sta...@lists.freedesktop.org
---
 src/gallium/drivers/nouveau/nouveau_winsys.h   | 2 ++
 src/gallium/drivers/nouveau/nv30/nv30_screen.c | 4 +++-
 src/gallium/drivers/nouveau/nv50/nv50_screen.c | 1 +
 src/gallium/drivers/nouveau/nvc0/nvc0_screen.c | 3 ++-
 4 files changed, 8 insertions(+), 2 deletions(-)

diff --git a/src/gallium/drivers/nouveau/nouveau_winsys.h 
b/src/gallium/drivers/nouveau/nouveau_winsys.h
index 389a229..a44fd3e 100644
--- a/src/gallium/drivers/nouveau/nouveau_winsys.h
+++ b/src/gallium/drivers/nouveau/nouveau_winsys.h
@@ -24,6 +24,8 @@ PUSH_AVAIL(struct nouveau_pushbuf *push)
 static inline bool
 PUSH_SPACE(struct nouveau_pushbuf *push, uint32_t size)
 {
+   /* Provide a buffer so that fences always have room to be emitted */
+   size += 8;
if (PUSH_AVAIL(push) < size)
   return nouveau_pushbuf_space(push, size, 0, 0) == 0;
return true;
diff --git a/src/gallium/drivers/nouveau/nv30/nv30_screen.c 
b/src/gallium/drivers/nouveau/nv30/nv30_screen.c
index 39267b3..335c163 100644
--- a/src/gallium/drivers/nouveau/nv30/nv30_screen.c
+++ b/src/gallium/drivers/nouveau/nv30/nv30_screen.c
@@ -347,7 +347,9 @@ nv30_screen_fence_emit(struct pipe_screen *pscreen, 
uint32_t *sequence)
 
*sequence = ++screen->base.fence.sequence;
 
-   BEGIN_NV04(push, NV30_3D(FENCE_OFFSET), 2);
+   assert(PUSH_AVAIL(push) >= 3);
+   PUSH_DATA (push, NV30_3D_FENCE_OFFSET |
+  (2 /* size */ << 18) | (7 /* subchan */ << 13));
PUSH_DATA (push, 0);
PUSH_DATA (push, *sequence);
 }
diff --git a/src/gallium/drivers/nouveau/nv50/nv50_screen.c 
b/src/gallium/drivers/nouveau/nv50/nv50_screen.c
index 6012ff6..812b246 100644
--- a/src/gallium/drivers/nouveau/nv50/nv50_screen.c
+++ b/src/gallium/drivers/nouveau/nv50/nv50_screen.c
@@ -388,6 +388,7 @@ nv50_screen_fence_emit(struct pipe_screen *pscreen, u32 
*sequence)
/* we need to do it after possible flush in MARK_RING */
*sequence = ++screen->base.fence.sequence;
 
+   assert(PUSH_AVAIL(push) >= 5);
PUSH_DATA (push, NV50_FIFO_PKHDR(NV50_3D(QUERY_ADDRESS_HIGH), 4));
PUSH_DATAh(push, screen->fence.bo->offset);
PUSH_DATA (push, screen->fence.bo->offset);
diff --git a/src/gallium/drivers/nouveau/nvc0/nvc0_screen.c 
b/src/gallium/drivers/nouveau/nvc0/nvc0_screen.c
index 32da76c..afd91e6 100644
--- a/src/gallium/drivers/nouveau/nvc0/nvc0_screen.c
+++ b/src/gallium/drivers/nouveau/nvc0/nvc0_screen.c
@@ -537,7 +537,8 @@ nvc0_screen_fence_emit(struct pipe_screen *pscreen, u32 
*sequence)
/* we need to do it after possible flush in MARK_RING */
*sequence = ++screen->base.fence.sequence;
 
-   BEGIN_NVC0(push, NVC0_3D(QUERY_ADDRESS_HIGH), 4);
+   assert(PUSH_AVAIL(push) >= 5);
+   PUSH_DATA (push, NVC0_FIFO_PKHDR_SQ(NVC0_3D(QUERY_ADDRESS_HIGH), 4));
PUSH_DATAh(push, screen->fence.bo->offset);
PUSH_DATA (push, screen->fence.bo->offset);
PUSH_DATA (push, *sequence);
-- 
2.4.9

___
Nouveau mailing list
Nouveau@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/nouveau

[Nouveau] [Bug 92287] Display errors in Qt applications after using Android Virtual Devices

[bugzilla-daemon]

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

--- Comment #5 from Guido Winkelmann  ---
> You might try with mesa-git -- there are a handful of patches on there that 
> deal with resource lifetime issues, but I doubt it will do anything to 
> resolve your problem.

I've installed mesa git, and so far, it looks like that solves the reported
problems, although sometimes they take a while to manifest. Will report back
tomorrow.

-- 
You are receiving this mail because:
You are the QA Contact for the bug.
You are the assignee for the bug.
___
Nouveau mailing list
Nouveau@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/nouveau

[Nouveau] [Bug 92274] nouveau black screen and errors with two monitors attached

[bugzilla-daemon]

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

--- Comment #10 from joseph-thom...@gmx.de ---
Ok I'm sorry to ask again, but I've got no idea what the methods nvkm_mask,
read, and wr32 are expecting, returning or doing, so I cannot
think by myself what to do...
(By the way in my sources they are just named nv_*.)
So where can I find documentation about it or where are they defined?
I'm familiar with (userspace) C, but not in these dimensions
and I don't know how to locate the definition of a function except for
looking in all included headers recursively...
Did I understand you correctly, that I should make the changes like this:
(again I've got no idea what these functions do, so it might be nonsense)

/* AVI InfoFrame */

u32 foo = nvkm_rd32(device, 0x69 + hdmi);
nvkm_wr32(device, 0x69 + hdmi, foo & ~1);
nvkm_wr32(device, 0x69000c + hdmi, 0x006f);
nvkm_wr32(device, 0x690010 + hdmi, 0x);
nvkm_wr32(device, 0x690014 + hdmi, 0x);
nvkm_wr32(device, 0x690018 + hdmi, 0x);
nvkm_wr32(device, 0x69 + hdmi, foo | 1);

/* ??? InfoFrame? */
u32 foo = nvkm_rd32(device, 0x6900c0 + hdmi);
nvkm_wr32(device, 0x6900c0 + hdmi, foo & ~1);
nvkm_wr32(device, 0x6900cc + hdmi, 0x0010);
nvkm_wr32(device, 0x6900c0 + hdmi, foo | 1);

-- 
You are receiving this mail because:
You are the assignee for the bug.
___
Nouveau mailing list
Nouveau@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/nouveau

[Nouveau] [Bug 92297] dithering detected incorrectly

[bugzilla-daemon]

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

--- Comment #1 from Ilia Mirkin  ---
Please grab a copy of envytools (github.com/envytools/envytools) and also
provide the output of

nvapeek 101000

-- 
You are receiving this mail because:
You are the assignee for the bug.
___
Nouveau mailing list
Nouveau@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/nouveau

[Nouveau] [Bug 92297] New: dithering detected incorrectly

[bugzilla-daemon]

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

Bug ID: 92297
   Summary: dithering detected incorrectly
   Product: xorg
   Version: unspecified
  Hardware: x86-64 (AMD64)
OS: Linux (All)
Status: NEW
  Severity: minor
  Priority: medium
 Component: Driver/nouveau
  Assignee: nouveau@lists.freedesktop.org
  Reporter: avi.kiv...@gmail.com
QA Contact: xorg-t...@lists.x.org

Created attachment 118681
  --> https://bugs.freedesktop.org/attachment.cgi?id=118681=edit
vbios.rom

4.1.8-200.fc22.x86_64
01:00.0 VGA compatible controller: NVIDIA Corporation GF108GLM [NVS 5200M] (rev
a1)

This is a laptop; the laptop screen displays some colors as flickering
vertically striped patterns, which IRC/imirkin diagnosed as unneeded dithering.
 Disabling dithering with xrandr fixes the issue.

-- 
You are receiving this mail because:
You are the assignee for the bug.
___
Nouveau mailing list
Nouveau@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/nouveau

[Nouveau] [Bug 92274] nouveau black screen and errors with two monitors attached

[bugzilla-daemon]

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

--- Comment #14 from joseph-thom...@gmx.de ---
Created attachment 118683
  --> https://bugs.freedesktop.org/attachment.cgi?id=118683=edit
/var/log/dmesg after changes in ./drm/.../hdmigk104.c

-- 
You are receiving this mail because:
You are the assignee for the bug.
___
Nouveau mailing list
Nouveau@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/nouveau

[Nouveau] [Bug 92274] nouveau black screen and errors with two monitors attached

[bugzilla-daemon]

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

--- Comment #12 from Ilia Mirkin  ---
(In reply to joseph-thommes from comment #10)
> Ok I'm sorry to ask again, but I've got no idea what the methods nvkm_mask,
> read, and wr32 are expecting, returning or doing, so I cannot
> think by myself what to do...
> (By the way in my sources they are just named nv_*.)
> So where can I find documentation about it or where are they defined?
> I'm familiar with (userspace) C, but not in these dimensions
> and I don't know how to locate the definition of a function except for
> looking in all included headers recursively...
> Did I understand you correctly, that I should make the changes like this:
> (again I've got no idea what these functions do, so it might be nonsense)
> 
> /* AVI InfoFrame */
> 
> u32 foo = nvkm_rd32(device, 0x69 + hdmi);
> nvkm_wr32(device, 0x69 + hdmi, foo & ~1);
> nvkm_wr32(device, 0x69000c + hdmi, 0x006f);
> nvkm_wr32(device, 0x690010 + hdmi, 0x);
> nvkm_wr32(device, 0x690014 + hdmi, 0x);
> nvkm_wr32(device, 0x690018 + hdmi, 0x);
> nvkm_wr32(device, 0x69 + hdmi, foo | 1);
> 
> /* ??? InfoFrame? */
> u32 foo = nvkm_rd32(device, 0x6900c0 + hdmi);
> nvkm_wr32(device, 0x6900c0 + hdmi, foo & ~1);
> nvkm_wr32(device, 0x6900cc + hdmi, 0x0010);
> nvkm_wr32(device, 0x6900c0 + hdmi, foo | 1);

Seems right to me, except of course it won't compile since you have two
variables named "foo" being declared in the same scope. Remove the second 'u32'
and you should be good to go.

-- 
You are receiving this mail because:
You are the assignee for the bug.
___
Nouveau mailing list
Nouveau@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/nouveau

[Nouveau] [Bug 92274] nouveau black screen and errors with two monitors attached

[bugzilla-daemon]

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

--- Comment #13 from joseph-thom...@gmx.de ---
Ok I changed the file, it compiled fine (with a little C90 standard warning).
On bootup I still get the message at the HDMI Monitor: No input. The DVI
Monitor just stays black, not sure if this is specific to this monitor, but I
think it usually shows such a message, too. So the symtpoms are the same.
In the last post I accidentally removed one line too much, which I did not in
the source code I used to compile it.
The kernel log has changed a bit.

-- 
You are receiving this mail because:
You are the assignee for the bug.
___
Nouveau mailing list
Nouveau@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/nouveau

[Nouveau] [Bug 92299] New: PGRAPH error when using plasmashell (KDE v5)

[bugzilla-daemon]

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

Bug ID: 92299
   Summary: PGRAPH error when using plasmashell (KDE v5)
   Product: Mesa
   Version: 11.0
  Hardware: x86-64 (AMD64)
OS: Linux (All)
Status: NEW
  Severity: normal
  Priority: medium
 Component: Drivers/DRI/nouveau
  Assignee: nouveau@lists.freedesktop.org
  Reporter: quelque_...@yahoo.fr
QA Contact: nouveau@lists.freedesktop.org

Created attachment 118684
  --> https://bugs.freedesktop.org/attachment.cgi?id=118684=edit
dmesg + stacktrace

Hi everyone,


Just in case, I wonder if there is not some kind of connection to this post:
https://bugs.freedesktop.org/show_bug.cgi?id=92213
Also, I am not sure of the version of nouveau, so I give the information I know
for sure there:
I am running Archlinux (Linux 4.2.2), KDE (5.4.4), Qt (5.5.0) on a x86_64
system. mesa is version 11.0.2 and xf86-video-nouveau is version 1.0.11-3.

Also, there is my lspci -vv:
01:00.0 VGA compatible controller: NVIDIA Corporation GT216M [GeForce GT 320M]
(rev a2) (prog-if 00 [VGA controller])
Subsystem: Acer Incorporated [ALI] Device 036d
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr-
Stepping- SERR- FastB2B- DisINTx+
Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- SERR- 
Capabilities: [100 v1] Virtual Channel
Caps:   LPEVC=0 RefClk=100ns PATEntryBits=1
Arb:Fixed- WRR32- WRR64- WRR128-
Ctrl:   ArbSelect=Fixed
Status: InProgress-
VC0:Caps:   PATOffset=00 MaxTimeSlots=1 RejSnoopTrans-
Arb:Fixed- WRR32- WRR64- WRR128- TWRR128- WRR256-
Ctrl:   Enable+ ID=0 ArbSelect=Fixed TC/VC=01
Status: NegoPending- InProgress-
Capabilities: [128 v1] Power Budgeting 
Capabilities: [600 v1] Vendor Specific Information: ID=0001 Rev=1
Len=024 
Kernel driver in use: nouveau
Kernel modules: nouveau

And I have errors when running the system for too long.
There, you can access the stacktrace (on an Archlinux system). You also have
the dmesg messages. There is a sample of what is displayed:
[251170.682470] nouveau E[  PGRAPH][:01:00.0] magic set 1:
[251170.682485] nouveau E[  PGRAPH][:01:00.0] 0x00408e04: 0x2008bf05
[251170.682494] nouveau E[  PGRAPH][:01:00.0] 0x00408e08: 0x00205640
[251170.682501] nouveau E[  PGRAPH][:01:00.0] 0x00408e0c: 0x4432
[251170.682509] nouveau E[  PGRAPH][:01:00.0] 0x00408e10: 0x5640
[251170.682515] nouveau E[  PGRAPH][:01:00.0] TRAP_TEXTURE - TP1:  FAULT
[251170.682531] nouveau E[  PGRAPH][:01:00.0] ch 9 [0x003f518000
plasmashell[503]] subc 3 class 0x8597 mthd 0x1b0c data 0x1000f010
[251170.682555] nouveau E[ PFB][:01:00.0] trapped read at 0x0020564000
on channel 0x0003f518 [plasmashell[503]] PGRAPH/TEXTURE/00 reason:
PAGE_NOT_PRESENT
[251170.683469] nouveau E[  PGRAPH][:01:00.0] magic set 1:
[251170.683476] nouveau E[  PGRAPH][:01:00.0] 0x00408e04: 0x2009bc05
[251170.683481] nouveau E[  PGRAPH][:01:00.0] 0x00408e08: 0x00205641
[251170.683485] nouveau E[  PGRAPH][:01:00.0] 0x00408e0c: 0x4432
[251170.683490] nouveau E[  PGRAPH][:01:00.0] 0x00408e10: 0x5640
[251170.683493] nouveau E[  PGRAPH][:01:00.0] TRAP_TEXTURE - TP1:  FAULT
[251170.683502] nouveau E[  PGRAPH][:01:00.0] ch 9 [0x003f518000
plasmashell[503]] subc 3 class 0x8597 mthd 0x1b0c data 0x1000f010
[251170.683513] nouveau E[ PFB][:01:00.0] trapped read at 0x0020564100
on channel 0x0003f518 [plasmashell[503]] PGRAPH/TEXTURE/00 reason:
PAGE_NOT_PRESENT
[251170.683543] nouveau E[  PGRAPH][:01:00.0] magic set 1:
[251170.683555] nouveau E[  PGRAPH][:01:00.0] 0x00408e04: 0x2009610f
[251170.683560] nouveau E[  PGRAPH][:01:00.0] 0x00408e08: 0x00205734
[251170.683565] nouveau E[  PGRAPH][:01:00.0] 0x00408e0c: 0x4432
[251170.683570] nouveau E[  PGRAPH][:01:00.0] 0x00408e10: 0x5720
[251170.683574] nouveau E[  PGRAPH][:01:00.0] TRAP_TEXTURE - TP1:  FAULT
[251170.683586] nouveau E[  PGRAPH][:01:00.0] ch 9 [0x003f518000
plasmashell[503]] subc 3 class 0x8597 mthd 0x15f0 data 0x02000201
[251170.683599] nouveau E[ PFB][:01:00.0] trapped read at 0x0020573400
on channel 0x0003f518 [plasmashell[503]] PGRAPH/TEXTURE/00 reason:
PAGE_NOT_PRESENT
[251170.683632] nouveau E[  PGRAPH][:01:00.0] magic set 1:
[251170.683644] nouveau E[  PGRAPH][:01:00.0] 0x00408e04: 0x20086805
[251170.683650] nouveau E[  PGRAPH][:01:00.0] 0x00408e08: 0x00205890
[251170.683656] nouveau E[  PGRAPH][:01:00.0] 0x00408e0c: 0x4432
[251170.683662] nouveau E[  PGRAPH][:01:00.0] 0x00408e10: 0x5890
[251170.683667] nouveau E[  PGRAPH][:01:00.0] TRAP_TEXTURE - 

Re: [Nouveau] [PATCH] nouveau: make sure there's always room to emit a fence

[Samuel Pitoiset]

Reviewed-by: Samuel Pitoiset 

On 10/05/2015 09:21 PM, Ilia Mirkin wrote:

I started seeing a lot of situations on nv30 where fence emission
wouldn't fit into the previous buffer (causing assertions). This ensures
that whenever checking for space, we always leave a bit of extra room
for the fence emission commands. Adjusts the nv30 and nvc0 fence
emission logic to bypass the space checking as well.

Signed-off-by: Ilia Mirkin 
Cc: mesa-sta...@lists.freedesktop.org
---
  src/gallium/drivers/nouveau/nouveau_winsys.h   | 2 ++
  src/gallium/drivers/nouveau/nv30/nv30_screen.c | 4 +++-
  src/gallium/drivers/nouveau/nv50/nv50_screen.c | 1 +
  src/gallium/drivers/nouveau/nvc0/nvc0_screen.c | 3 ++-
  4 files changed, 8 insertions(+), 2 deletions(-)

diff --git a/src/gallium/drivers/nouveau/nouveau_winsys.h 
b/src/gallium/drivers/nouveau/nouveau_winsys.h
index 389a229..a44fd3e 100644
--- a/src/gallium/drivers/nouveau/nouveau_winsys.h
+++ b/src/gallium/drivers/nouveau/nouveau_winsys.h
@@ -24,6 +24,8 @@ PUSH_AVAIL(struct nouveau_pushbuf *push)
  static inline bool
  PUSH_SPACE(struct nouveau_pushbuf *push, uint32_t size)
  {
+   /* Provide a buffer so that fences always have room to be emitted */
+   size += 8;
 if (PUSH_AVAIL(push) < size)
return nouveau_pushbuf_space(push, size, 0, 0) == 0;
 return true;
diff --git a/src/gallium/drivers/nouveau/nv30/nv30_screen.c 
b/src/gallium/drivers/nouveau/nv30/nv30_screen.c
index 39267b3..335c163 100644
--- a/src/gallium/drivers/nouveau/nv30/nv30_screen.c
+++ b/src/gallium/drivers/nouveau/nv30/nv30_screen.c
@@ -347,7 +347,9 @@ nv30_screen_fence_emit(struct pipe_screen *pscreen, 
uint32_t *sequence)
  
 *sequence = ++screen->base.fence.sequence;
  
-   BEGIN_NV04(push, NV30_3D(FENCE_OFFSET), 2);

+   assert(PUSH_AVAIL(push) >= 3);
+   PUSH_DATA (push, NV30_3D_FENCE_OFFSET |
+  (2 /* size */ << 18) | (7 /* subchan */ << 13));


Is there some other places where we do something like this?
If so, maybe we should introduce NV30_FIFO_PKHDR_SQ.


 PUSH_DATA (push, 0);
 PUSH_DATA (push, *sequence);
  }
diff --git a/src/gallium/drivers/nouveau/nv50/nv50_screen.c 
b/src/gallium/drivers/nouveau/nv50/nv50_screen.c
index 6012ff6..812b246 100644
--- a/src/gallium/drivers/nouveau/nv50/nv50_screen.c
+++ b/src/gallium/drivers/nouveau/nv50/nv50_screen.c
@@ -388,6 +388,7 @@ nv50_screen_fence_emit(struct pipe_screen *pscreen, u32 
*sequence)
 /* we need to do it after possible flush in MARK_RING */
 *sequence = ++screen->base.fence.sequence;
  
+   assert(PUSH_AVAIL(push) >= 5);

 PUSH_DATA (push, NV50_FIFO_PKHDR(NV50_3D(QUERY_ADDRESS_HIGH), 4));
 PUSH_DATAh(push, screen->fence.bo->offset);
 PUSH_DATA (push, screen->fence.bo->offset);
diff --git a/src/gallium/drivers/nouveau/nvc0/nvc0_screen.c 
b/src/gallium/drivers/nouveau/nvc0/nvc0_screen.c
index 32da76c..afd91e6 100644
--- a/src/gallium/drivers/nouveau/nvc0/nvc0_screen.c
+++ b/src/gallium/drivers/nouveau/nvc0/nvc0_screen.c
@@ -537,7 +537,8 @@ nvc0_screen_fence_emit(struct pipe_screen *pscreen, u32 
*sequence)
 /* we need to do it after possible flush in MARK_RING */
 *sequence = ++screen->base.fence.sequence;
  
-   BEGIN_NVC0(push, NVC0_3D(QUERY_ADDRESS_HIGH), 4);

+   assert(PUSH_AVAIL(push) >= 5);
+   PUSH_DATA (push, NVC0_FIFO_PKHDR_SQ(NVC0_3D(QUERY_ADDRESS_HIGH), 4));
 PUSH_DATAh(push, screen->fence.bo->offset);
 PUSH_DATA (push, screen->fence.bo->offset);
 PUSH_DATA (push, *sequence);


___
Nouveau mailing list
Nouveau@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/nouveau

[Nouveau] [Bug 92077] nouveau graphics freeze when using KDE Plasma 5; PGR engine fault

[bugzilla-daemon]

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

--- Comment #9 from dmidge  ---
Hi zoominee,
Ooops, sorry. I thought it was the same one, because we have the same
application that crashes. Alright, I will file a new bug! Thanks! And sorry for
the inconvenience. Is there a way I can delete my previous post, to avoid
people to read it anymore, since it seems to be unrelated?

-- 
You are receiving this mail because:
You are the QA Contact for the bug.
You are the assignee for the bug.
___
Nouveau mailing list
Nouveau@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/nouveau

[Nouveau] [Bug 92297] dithering detected incorrectly

[bugzilla-daemon]

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

--- Comment #2 from Avi Kivity  ---
00101000: 9f5cb098

-- 
You are receiving this mail because:
You are the assignee for the bug.
___
Nouveau mailing list
Nouveau@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/nouveau

[Nouveau] Struggle with GPU lockups and console deadlock using kernel-space modifications

[Innocenti Maresin]

Hello.

I have a poorly functioning GeForce 8600 GTS (rev a1) video card,
that causes many problems for the box where it’s installed,
primarily GPU lockups (sometimes unprovoked),
several instances in a day.
Without intervention, a GPU lockup is a condition
where the system console is no longer usable
(even the keyboard, because
switching from Xorg to TUI becomes obstructed; see below).

Upgrading Linux from 3.16 to 4.3 and improved cooling
reduced some minor problems (such as snow),
but didn’t prevent lockups.
Therefore I present some experiences and reflections
on abating GPU lockups.


First, I hoped to use the bus hardware reset control, found at
/sys/devices/pci:00/:00:01.0/:01:00.0/reset
in my system.
The #nouveau @ freenode channel suggested some insights afterwards.
But maneuvers with unloading/loading the nouveau module
after a lockup were not succeed for several reasons.
I envisaged the following sequence that could recover a computer
from a GPU lockup, with the system console usable again
and applications not disturbed too much.

1. Suspend all applications using the video card.
2. If necessary, perform hardware reset on the bus.
3. If necessary, run initialization functions for the video card.
4. Restore a usable video mode (can be achieved
  by switching virtual consoles Xorg ⇔ TUI, for example).
5. Resume the work.

Implementation became a challenge.
First, loading nouveau with config=NvForcePost=1
doesn’t result in a usable console, either during Linux startup or else.
It doesn’t produce a signal at all with my hardware.
I tested it with at least three different versions of nouveau
at both Linux 3.16 and Linux 4.3.

There are major problems with making the step 4 from the kernel mode.
Linux kernel has the «set_console(nr)» function (from vt.c),
but doesn’t export it.
Moreover, in modern kernels (apparently since Linux 3)
even this internal kernel function performs checks
for «vt_dont_switch», hence a deadlock can ensue.
Neither are exported other functions, even such high-level ones
as «suspend_console()» and «resume_console()».
I even was unable to reconnaissance their true addresses
in the memory using /proc/kallsyms — there are only zeros
(that wasn’t the case for Linux 2.6).


Some partial experiences, made using remote shell access,
are described below.

With any module and no lockup:
stop Xorg;
echo 0 >/sys/class/vtconsole/vtcon1/bind;
rmmod nouveau;
modprobe nouveau; — success.

With standard nouveau module on Linux 4.3:
 • stop Xorg; reset device; modprobe nouveau; —
   the module won’t initialize.
 • stop Xorg; reset device; reload module (as above) —
   won’t work, symptoms differ from case to case.

With modified nouveau modules, after a lockup:
 • «nvkm_device_init(⧦);» (at ⧦->devinit->post = false) —
   no effect.
 • reset device while Xorg runs —
   system crash or deadlock, nothing in logs.
 • «⧦->devinit->post = true; nvkm_device_init(⧦);» without reset —
   to be tested.
(«⧦» points to the card’s «struct nvkm_device» object.)

My modified nouveau module was derived
from git://people.freedesktop.org/~darktama/nouveau


Proposals and suggestions?
Please, think generally and not focus too much on my particular case.
My video card (and, possibly, some related stuff on the motherboard)
almost certainly functions improperly.

Regards, Incnis Mrsi
___
Nouveau mailing list
Nouveau@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/nouveau

[Nouveau] [Bug 92297] dithering detected incorrectly

[bugzilla-daemon]

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

--- Comment #3 from Ilia Mirkin  ---
Well, unless I'm misreading the bios (entirely possible), the FP data pointed
to by the offset in BIT table 'L' suggests that it's not a 8bpc screen.

bios->fp.strapless_is_24bit = bios->data[bios->fp.lvdsmanufacturerpointer + 4];

lvdsmanufacturerpointer = 56df

and 0x56e3 == 0. So nouveau is correctly turning on dithering based on the
information available to it. However perhaps that information isn't trustworthy
for fermi+. Or perhaps there's another bit somewhere.

-- 
You are receiving this mail because:
You are the assignee for the bug.
___
Nouveau mailing list
Nouveau@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/nouveau

[Nouveau] [Bug 92306] New: GL Excess demo renders incorrectly on nv43

[bugzilla-daemon]

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

Bug ID: 92306
   Summary: GL Excess demo renders incorrectly on nv43
   Product: Mesa
   Version: git
  Hardware: x86 (IA32)
OS: Linux (All)
Status: NEW
  Severity: normal
  Priority: medium
 Component: Drivers/DRI/nouveau
  Assignee: nouveau@lists.freedesktop.org
  Reporter: rand...@mail.ru
QA Contact: nouveau@lists.freedesktop.org

Created attachment 118688
  --> https://bugs.freedesktop.org/attachment.cgi?id=118688=edit
X log

I was trying to see if GL Excess demo still works - it does, but only some
scenes rendered correctly.

Demo: http://www.glexcess.com/files.htm

Hardware: 01:00.0 VGA compatible controller: NVIDIA Corporation NV43 [GeForce
6600 GT] (rev a2)

Mesa: OpenGL version string: 2.1 Mesa 11.1.0-devel (git-93161be)
drm: commit 8c4a1cbd98bd8d185d489395f33302a17db643a9 ("xf86drm: Fix error
handling for drmGetDevices()")
xf86-video-nouveau: commit 1ff13a922535924681b91452235b017e43a4c6f6 ("fix build
after glamor removal")
kernel from nouveau/4.3 branch: 4.2.0-rc8-40978-g778613e5
X server - standard 1.14.3 from Slackware 14.1
wine (yes, I know, old - but then same demo works with LIBGL_ALWAYS_SOFTWARE=1,
so not only wine's fault. I can upgrade after some time):
wine-1.5.25-1-gc2505fd

-- 
You are receiving this mail because:
You are the QA Contact for the bug.
You are the assignee for the bug.
___
Nouveau mailing list
Nouveau@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/nouveau

[Nouveau] [Bug 92306] GL Excess demo renders incorrectly on nv43

[bugzilla-daemon]

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

--- Comment #1 from Andrew Randrianasulu  ---
Created attachment 118689
  --> https://bugs.freedesktop.org/attachment.cgi?id=118689=edit
correct software rendering

It shows some landscape, even if at 1 fps.

-- 
You are receiving this mail because:
You are the QA Contact for the bug.
You are the assignee for the bug.
___
Nouveau mailing list
Nouveau@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/nouveau

[Nouveau] [Bug 92306] GL Excess demo renders incorrectly on nv43

[bugzilla-daemon]

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

--- Comment #2 from Andrew Randrianasulu  ---
Created attachment 118690
  --> https://bugs.freedesktop.org/attachment.cgi?id=118690=edit
incorrect hw rendering

with nouveau it only shows text and FPS bar - not landscape

-- 
You are receiving this mail because:
You are the QA Contact for the bug.
You are the assignee for the bug.
___
Nouveau mailing list
Nouveau@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/nouveau

[Nouveau] [Bug 92306] GL Excess demo renders incorrectly on nv43

[bugzilla-daemon]

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

--- Comment #3 from Andrew Randrianasulu  ---
Created attachment 118691
  --> https://bugs.freedesktop.org/attachment.cgi?id=118691=edit
dmesg

I think you can ignore locking-related warnings. But I can retry with 4.3-rc4
mainline, if you prefer (again, will need some time to compile it)

-- 
You are receiving this mail because:
You are the QA Contact for the bug.
You are the assignee for the bug.
___
Nouveau mailing list
Nouveau@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/nouveau

[Nouveau] [Bug 92306] GL Excess demo renders incorrectly on nv43

[bugzilla-daemon]

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

--- Comment #4 from Andrew Randrianasulu  ---
Created attachment 118692
  --> https://bugs.freedesktop.org/attachment.cgi?id=118692=edit
Another type of image corruption

Probably need its own bugreport. It always happen at same place in scene - so,
not random. Nearly looks like some garbage instead of (guess) alpha channel of
texture?

-- 
You are receiving this mail because:
You are the QA Contact for the bug.
You are the assignee for the bug.
___
Nouveau mailing list
Nouveau@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/nouveau

[Nouveau] Chipset & Family

[poma]

4.1.8-200.fc22.x86_64 dmesg:
[   11.809467] nouveau  [  DEVICE][:02:00.0] BOOT0  : 0x098200a2
[   11.809493] nouveau  [  DEVICE][:02:00.0] Chipset: G98 (NV98)
[   11.809508] nouveau  [  DEVICE][:02:00.0] Family : NV50


4.3.0-0.rc4.git0.1.fc24.x86_64 dmesg:
[2.483843] nouveau :02:00.0: NVIDIA G98 (098200a2)


Where vanished these Chipset & Family super cool lines?

___
Nouveau mailing list
Nouveau@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/nouveau

[Nouveau] [Bug 92307] New: NV50: WARNING: ... at include/drm/drm_crtc.h:1577 drm_helper_choose_encoder_dpms+0x8a/0x90 [drm_kms_helper]()

[bugzilla-daemon]

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

Bug ID: 92307
   Summary: NV50: WARNING: ... at include/drm/drm_crtc.h:1577
drm_helper_choose_encoder_dpms+0x8a/0x90
[drm_kms_helper]()
   Product: xorg
   Version: git
  Hardware: x86-64 (AMD64)
OS: Linux (All)
Status: NEW
  Severity: normal
  Priority: medium
 Component: Driver/nouveau
  Assignee: nouveau@lists.freedesktop.org
  Reporter: pomidorabelis...@gmail.com
QA Contact: xorg-t...@lists.x.org

S3 RESUME:

WARNING: ... at include/drm/drm_crtc.h:1577
drm_helper_choose_encoder_dpms+0x8a/0x90 [drm_kms_helper]()
Call Trace:
 [] dump_stack+0x4b/0x72
 [] warn_slowpath_common+0x82/0xc0
 [] warn_slowpath_null+0x1a/0x20
 [] drm_helper_choose_encoder_dpms+0x8a/0x90 [drm_kms_helper]
 [] drm_helper_connector_dpms+0x4b/0x100 [drm_kms_helper]
 [] nouveau_connector_hotplug+0x5b/0xb0 [nouveau]
 [] nvif_notify_work+0x27/0xa0 [nouveau]
 [] process_one_work+0x230/0x6a0
 [] ? process_one_work+0x199/0x6a0
 [] worker_thread+0x4e/0x450
 [] ? process_one_work+0x6a0/0x6a0
 [] ? process_one_work+0x6a0/0x6a0
 [] kthread+0x101/0x120
 [] ? trace_hardirqs_on_caller+0x129/0x1b0
 [] ? kthread_create_on_node+0x250/0x250
 [] ret_from_fork+0x3f/0x70
 [] ? kthread_create_on_node+0x250/0x250
---[ end trace cf287771813cb2d1 ]---

WARNING: ... at include/drm/drm_crtc.h:1577
drm_helper_choose_crtc_dpms+0x93/0xa0 [drm_kms_helper]()
Call Trace:
 [] dump_stack+0x4b/0x72
 [] warn_slowpath_common+0x82/0xc0
 [] warn_slowpath_null+0x1a/0x20
 [] drm_helper_choose_crtc_dpms+0x93/0xa0 [drm_kms_helper]
 [] ? nv50_display_crtc_get+0x20/0x20 [nouveau]
 [] drm_helper_connector_dpms+0xb9/0x100 [drm_kms_helper]
 [] nouveau_connector_hotplug+0x5b/0xb0 [nouveau]
 [] nvif_notify_work+0x27/0xa0 [nouveau]
 [] process_one_work+0x230/0x6a0
 [] ? process_one_work+0x199/0x6a0
 [] worker_thread+0x4e/0x450
 [] ? process_one_work+0x6a0/0x6a0
 [] ? process_one_work+0x6a0/0x6a0
 [] kthread+0x101/0x120
 [] ? trace_hardirqs_on_caller+0x129/0x1b0
 [] ? kthread_create_on_node+0x250/0x250
 [] ret_from_fork+0x3f/0x70
 [] ? kthread_create_on_node+0x250/0x250
---[ end trace cf287771813cb2d2 ]---

-- 
You are receiving this mail because:
You are the assignee for the bug.
___
Nouveau mailing list
Nouveau@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/nouveau

[Nouveau] [Bug 92307] NV50: WARNING: ... at include/drm/drm_crtc.h:1577 drm_helper_choose_encoder_dpms+0x8a/0x90 [drm_kms_helper]()

[bugzilla-daemon]

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

--- Comment #1 from poma  ---
Created attachment 118693
  --> https://bugs.freedesktop.org/attachment.cgi?id=118693=edit
dmesg 4.3.0-0.rc4.git0.1.fc24.x86_64+debug NV50

-- 
You are receiving this mail because:
You are the assignee for the bug.
___
Nouveau mailing list
Nouveau@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/nouveau

[Nouveau] [Bug 92297] dithering detected incorrectly

[bugzilla-daemon]

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

Ilia Mirkin  changed:

   What|Removed |Added

 Attachment #118681|text/plain  |application/octet-stream
  mime type||

-- 
You are receiving this mail because:
You are the assignee for the bug.
___
Nouveau mailing list
Nouveau@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/nouveau

[Nouveau] [Bug 92274] nouveau black screen and errors with two monitors attached

[bugzilla-daemon]

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

--- Comment #11 from joseph-thom...@gmx.de ---
And of course I meant effort not afford

-- 
You are receiving this mail because:
You are the assignee for the bug.
___
Nouveau mailing list
Nouveau@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/nouveau

[Nouveau] [PATCH v3 5/6] drm/nouveau: Switch DDC when reading the EDID

[Lukas Wunner]

The pre-retina MacBook Pro uses an LVDS panel and a gmux controller
to switch the panel between its two GPUs. The panel mode in VBIOS
is notoriously bogus on these machines.

Use drm_get_edid_switcheroo() in lieu of drm_get_edid() on LVDS.
This allows us to retrieve the EDID if the outputs are currently
muxed to the other GPU by temporarily switching the panel's DDC
lines. Likewise, ask vga_switcheroo to switch DDC before probing
LVDS connectors.

This only enables EDID probing on the pre-retina MBP (2008 - 2013).
The retina MBP (2012 - present) uses eDP and gmux is apparently not
capable of switching AUX separately from the main link on these models.
This will be addressed in later patches.

List of pre-retina MBPs with dual GPUs, either or both Nvidia:
[MBP  5,1 2008  nvidia MCP79 + G96pre-retina  15"]
[MBP  5,2 2009  nvidia MCP79 + G96pre-retina  17"]
[MBP  5,3 2009  nvidia MCP79 + G96pre-retina  15"]
[MBP  6,2 2010  intel ILK + nvidia GT216  pre-retina  15"]
[MBP  6,1 2010  intel ILK + nvidia GT216  pre-retina  17"]
[MBP  9,1 2012  intel IVB + nvidia GK107  pre-retina  15"]

Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=88861
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=61115
Tested-by: Pierre Moreau 
[MBP  5,3 2009  nvidia MCP79 + G96pre-retina  15"]
Tested-by: Lukas Wunner 
[MBP  9,1 2012  intel IVB + nvidia GK107  pre-retina  15"]

Signed-off-by: Lukas Wunner 
---
 drivers/gpu/drm/nouveau/nouveau_connector.c | 13 +++--
 1 file changed, 11 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/nouveau/nouveau_connector.c 
b/drivers/gpu/drm/nouveau/nouveau_connector.c
index 2e7cbe9..b3b0ca5 100644
--- a/drivers/gpu/drm/nouveau/nouveau_connector.c
+++ b/drivers/gpu/drm/nouveau/nouveau_connector.c
@@ -27,6 +27,7 @@
 #include 
 
 #include 
+#include 
 
 #include 
 #include 
@@ -148,7 +149,13 @@ nouveau_connector_ddc_detect(struct drm_connector 
*connector)
break;
} else
if (nv_encoder->i2c) {
-   if (nvkm_probe_i2c(nv_encoder->i2c, 0x50))
+   int ret;
+   if (nv_encoder->dcb->type == DCB_OUTPUT_LVDS)
+   vga_switcheroo_lock_ddc(dev->pdev);
+   ret = nvkm_probe_i2c(nv_encoder->i2c, 0x50);
+   if (nv_encoder->dcb->type == DCB_OUTPUT_LVDS)
+   vga_switcheroo_unlock_ddc(dev->pdev);
+   if (ret)
break;
}
}
@@ -259,7 +266,9 @@ nouveau_connector_detect(struct drm_connector *connector, 
bool force)
 
nv_encoder = nouveau_connector_ddc_detect(connector);
if (nv_encoder && (i2c = nv_encoder->i2c) != NULL) {
-   nv_connector->edid = drm_get_edid(connector, i2c);
+   nv_connector->edid = nv_encoder->dcb->type == DCB_OUTPUT_LVDS ?
+drm_get_edid_switcheroo(connector, i2c) :
+drm_get_edid(connector, i2c);
drm_mode_connector_update_edid_property(connector,
nv_connector->edid);
if (!nv_connector->edid) {
-- 
1.8.5.2 (Apple Git-48)

___
Nouveau mailing list
Nouveau@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/nouveau

[Nouveau] [Bug 81072] [NVC1] GPU lockup after "read fault at 0x0000039000 [PAGE_NOT_PRESENT] from PCOPY0"

[bugzilla-daemon]

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

--- Comment #4 from Patryk Zawadzki  ---
I am getting a slightly different error and am not sure whether it's the same
issue:

nouveau E[   PFIFO][:01:00.0] read fault at 0x001198 [PAGE_NOT_PRESENT]
from PGRAPH/GPC0/PROP on channel 0x00bf739000 [Xorg[2305]]
nouveau E[   PFIFO][:01:00.0] PGRAPH engine fault on channel 10,
recovering...

After that the screen freezes and I need to do a hard reset. Applications
continue running and I can SSH in but restarting Xorg and trying to soft reboot
do not help.

-- 
You are receiving this mail because:
You are the assignee for the bug.
___
Nouveau mailing list
Nouveau@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/nouveau

[Nouveau] [Bug 81072] [NVC1] GPU lockup after "read fault at 0x0000039000 [PAGE_NOT_PRESENT] from PCOPY0"

[bugzilla-daemon]

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

--- Comment #5 from Patryk Zawadzki  ---
Just got some more:

nouveau E[Xorg[2265]] failed to idle channel 0x [Xorg[2265]]
nouveau E[Xorg[2265]] failed to idle channel 0x [Xorg[2265]]

-- 
You are receiving this mail because:
You are the assignee for the bug.
___
Nouveau mailing list
Nouveau@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/nouveau

[Nouveau] [PATCH v3 0/6] Enable gpu switching on the MacBook Pro

[Lukas Wunner]

The pre-retina MacBook Pro uses an LVDS panel and a gmux controller
to switch the panel between its two GPUs. The panel mode in VBIOS
is notoriously bogus on these machines and some models have no
VBIOS at all, so the inactive GPU cannot set up its LVDS output.

Extend vga_switcheroo to support switching only the DDC lines.
Introduce a drm_get_edid_switcheroo() helper which uses this feature.
Amend i915, nouveau and radeon to call it for LVDS connectors.

This only enables EDID probing on the pre-retina MBP (2008 - 2013),
and only under the condition that apple-gmux loads before the DRM
drivers. Later patches will address reprobing of the DRM drivers
if apple-gmux loads late.

The retina MBP (2012 - present) uses eDP and is apparently not
capable of switching AUX separately from the main link.
This will also be addressed in later patches.


Previous installments:
v1: http://lists.freedesktop.org/archives/dri-devel/2015-April/081515.html
v2: http://lists.freedesktop.org/archives/dri-devel/2015-August/088156.html


Changes since v2:
  * Previously the DDC locking happened in drm_get_edid() and thus
was done for all DRM drivers, regardless if they are ever used
on muxed machines. Now this is moved to a separate helper which
is only called by relevant drivers and only for LVDS connectors.
(Suggested by Thierry Reding and seconded by Alex Deucher and
Daniel Vetter.)
  * Squashed commits, overhauled locking, added kernel-doc for new
public functions and locks.
(Suggested by Daniel Vetter.)


Thanks a lot to the reviewers and testers for your valuable feedback.


Lukas Wunner (6):
  vga_switcheroo: Add support for switching only the DDC
  apple-gmux: Add switch_ddc support
  drm/edid: Switch DDC when reading the EDID
  drm/i915: Switch DDC when reading the EDID
  drm/nouveau: Switch DDC when reading the EDID
  drm/radeon: Switch DDC when reading the EDID

 drivers/gpu/drm/drm_edid.c  | 26 
 drivers/gpu/drm/i915/intel_lvds.c   |  3 +-
 drivers/gpu/drm/nouveau/nouveau_connector.c | 13 +++-
 drivers/gpu/drm/radeon/radeon_connectors.c  |  4 ++
 drivers/gpu/vga/vga_switcheroo.c| 98 -
 drivers/platform/x86/apple-gmux.c   | 23 +++
 include/drm/drm_crtc.h  |  2 +
 include/linux/vga_switcheroo.h  |  9 +++
 8 files changed, 173 insertions(+), 5 deletions(-)

-- 
1.8.5.2 (Apple Git-48)

___
Nouveau mailing list
Nouveau@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/nouveau

Re: [Nouveau] [PATCH v3 0/6] Enable gpu switching on the MacBook Pro

[Lukas Wunner]

Hi,

I've also pushed this series to GitHub now to ease reviewing:
https://github.com/l1k/linux/commits/mbp_switcheroo_v3

Thanks,

Lukas
___
Nouveau mailing list
Nouveau@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/nouveau

[Nouveau] [Bug 92077] nouveau graphics freeze when using KDE Plasma 5; PGR engine fault

[bugzilla-daemon]

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

--- Comment #8 from zoominee  ---
Dear dmidge!  I think the error messages that you get (something about PGRAPH
and textures) are quite different from mine (something about PFIFO and the PGR
engine, whatever that may be...) - it probably makes more sense to file it as a
different bug instead of putting it into the same thread. Thanks!

-- 
You are receiving this mail because:
You are the QA Contact for the bug.
You are the assignee for the bug.
___
Nouveau mailing list
Nouveau@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/nouveau

[Nouveau] [Bug 92287] New: Display errors in Qt applications after using Android Virtual Devices

[bugzilla-daemon]

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

Bug ID: 92287
   Summary: Display errors in Qt applications after using Android
Virtual Devices
   Product: Mesa
   Version: 11.0
  Hardware: x86-64 (AMD64)
OS: Linux (All)
Status: NEW
  Severity: major
  Priority: medium
 Component: Drivers/DRI/nouveau
  Assignee: nouveau@lists.freedesktop.org
  Reporter: gu...@ambient-entertainment.de
QA Contact: nouveau@lists.freedesktop.org

Created attachment 118670
  --> https://bugs.freedesktop.org/attachment.cgi?id=118670=edit
Screenshot showing the problems

After using an Android Virtual Machine (from Android Studio,
https://developer.android.com/sdk/index.html) and stopping it, Qt/KDE
application will show weird display errors. Pixmaps get drawn poorly aligned or
with parts of them corrupted or just not at all, some windows are translucent
when they should not be, drop down menus are not drawn fully (some items do not
get drawn, although the space for them is still reserved) and have horizontal
bars, either black or of various weird colors, through them. Most applications
affected by this become unusable. I will attach a screenshot that shows the
problem.

Only Qt/KDE applications seem to be affected by this, as far as I can tell.
Only applications that are newly started after this will be affected, not
applications that have been running before but have opened new windows. When
these problems start to happen, only restarting the computer seems to fix them,
simply restarting the X server is not enough.

On two occasions so far, the problems were even worse: The X display froze
completely, except for mouse movements, and I could no longer switch the
keyboards NumLuck LED on or off by pressing Numlock. I had to reset the machine
with a SysRq sequence.

This problem is not always reproducible, but seems to happen more often when
running two AVDs simultaneously and then quitting them. The AVDs need to be
configured to "Use Host GPU". I have not found any other way to reproduce this.

My system:

Gentoo Linux on x86_64
X server: xorg-server 1.17.2-r1
Display driver: 1.0.11
Mesa: 11.0.2
Kernel version: 4.2.2

This also happened with earlier versions of the X server and Mesa. I upgraded
those after this problem first started,

-- 
You are receiving this mail because:
You are the QA Contact for the bug.
You are the assignee for the bug.
___
Nouveau mailing list
Nouveau@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/nouveau

[Nouveau] [Bug 92287] Display errors in Qt applications after using Android Virtual Devices

[bugzilla-daemon]

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

Guido Winkelmann  changed:

   What|Removed |Added

 Attachment #118670|text/plain  |image/png
  mime type||

-- 
You are receiving this mail because:
You are the QA Contact for the bug.
You are the assignee for the bug.
___
Nouveau mailing list
Nouveau@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/nouveau

Re: [Nouveau] [PATCH v3 0/6] Enable gpu switching on the MacBook Pro

[Evan Foss]

On Mon, Oct 5, 2015 at 9:23 AM, Lukas Wunner  wrote:
> Hi,
>
> I've also pushed this series to GitHub now to ease reviewing:
> https://github.com/l1k/linux/commits/mbp_switcheroo_v3

So to test this all someone has to do is pull this and try it? No
patching required?

> Thanks,
>
> Lukas
> ___
> Nouveau mailing list
> Nouveau@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/nouveau



-- 
Home
http://evanfoss.googlepages.com/
Work
http://forge.abcd.harvard.edu/gf/project/epl_engineering/wiki/
___
Nouveau mailing list
Nouveau@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/nouveau

Re: [Nouveau] [PATCH v3 0/6] Enable gpu switching on the MacBook Pro

[Evan Foss]

On Mon, Oct 5, 2015 at 11:17 AM, Lukas Wunner  wrote:
> Hi Evan,
>
> On Mon, Oct 05, 2015 at 10:15:53AM -0400, Evan Foss wrote:
>> On Mon, Oct 5, 2015 at 9:23 AM, Lukas Wunner  wrote:
>> > I've also pushed this series to GitHub now to ease reviewing:
>> > https://github.com/l1k/linux/commits/mbp_switcheroo_v3
>>
>> So to test this all someone has to do is pull this and try it? No
>> patching required?
>
> Yes. But if you don't already have a kernel git repo, this will be
> a > 1 GByte download.

2012
Macbook Pro 9,2

$ dmesg|grep Apple
[0.00] efi: EFI v1.10 by Apple
[0.00] DMI: Apple Inc. MacBookPro9,1/Mac-
4B7AC7E43945597E,
BIOS MBP91.88Z.00D3.B08.1208081132 08/08/2012

> Which MacBook Pro model do you want to test this on? As noted in the
> cover letter, this will only work on pre-retinas and only if the
> apple-gmux module loads before the DRM drivers. You can try to ensure
> the latter by editing modules.dep, or grab this tarball which contains
> reprobing patches on top:
> http://wunner.de/mbp_switcheroo_v3_reprobe_4.3-rc4pre.tar.gz

Ok thanks

> Best regards,
>
> Lukas

Evan

-- 
Home
http://evanfoss.googlepages.com/
Work
http://forge.abcd.harvard.edu/gf/project/epl_engineering/wiki/
___
Nouveau mailing list
Nouveau@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/nouveau

Re: [Nouveau] [PATCH v3 0/6] Enable gpu switching on the MacBook Pro

[Lukas Wunner]

Hi Evan,

On Mon, Oct 05, 2015 at 10:15:53AM -0400, Evan Foss wrote:
> On Mon, Oct 5, 2015 at 9:23 AM, Lukas Wunner  wrote:
> > I've also pushed this series to GitHub now to ease reviewing:
> > https://github.com/l1k/linux/commits/mbp_switcheroo_v3
> 
> So to test this all someone has to do is pull this and try it? No
> patching required?

Yes. But if you don't already have a kernel git repo, this will be
a > 1 GByte download.

Which MacBook Pro model do you want to test this on? As noted in the
cover letter, this will only work on pre-retinas and only if the
apple-gmux module loads before the DRM drivers. You can try to ensure
the latter by editing modules.dep, or grab this tarball which contains
reprobing patches on top:
http://wunner.de/mbp_switcheroo_v3_reprobe_4.3-rc4pre.tar.gz

Best regards,

Lukas
___
Nouveau mailing list
Nouveau@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/nouveau

[Nouveau] [Bug 92287] Display errors in Qt applications after using Android Virtual Devices

[bugzilla-daemon]

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

--- Comment #1 from Guido Winkelmann  ---
Created attachment 118671
  --> https://bugs.freedesktop.org/attachment.cgi?id=118671=edit
dmesg output when the problem occured

-- 
You are receiving this mail because:
You are the QA Contact for the bug.
You are the assignee for the bug.
___
Nouveau mailing list
Nouveau@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/nouveau

[Nouveau] [Bug 92287] Display errors in Qt applications after using Android Virtual Devices

[bugzilla-daemon]

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

--- Comment #2 from Guido Winkelmann  ---
Created attachment 118672
  --> https://bugs.freedesktop.org/attachment.cgi?id=118672=edit
Xorg logfile from when the problem occured

-- 
You are receiving this mail because:
You are the QA Contact for the bug.
You are the assignee for the bug.
___
Nouveau mailing list
Nouveau@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/nouveau

Re: [Nouveau] [PATCH v3 0/6] Enable gpu switching on the MacBook Pro

[Pierre Moreau]

The repo is a fork of Linus' tree, with the patches on top of it. So you just 
need to build that modified version of the kernel and boot it. :-)

Pierre

> On 05 Oct 2015, at 16:15, Evan Foss  wrote:
> 
>> On Mon, Oct 5, 2015 at 9:23 AM, Lukas Wunner  wrote:
>> Hi,
>> 
>> I've also pushed this series to GitHub now to ease reviewing:
>> https://github.com/l1k/linux/commits/mbp_switcheroo_v3
> 
> So to test this all someone has to do is pull this and try it? No
> patching required?
> 
>> Thanks,
>> 
>> Lukas
>> ___
>> Nouveau mailing list
>> Nouveau@lists.freedesktop.org
>> http://lists.freedesktop.org/mailman/listinfo/nouveau
> 
> 
> 
> -- 
> Home
> http://evanfoss.googlepages.com/
> Work
> http://forge.abcd.harvard.edu/gf/project/epl_engineering/wiki/
> ___
> Nouveau mailing list
> Nouveau@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/nouveau
___
Nouveau mailing list
Nouveau@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/nouveau

[Nouveau] [Bug 92274] nouveau black screen and errors with two monitors attached

[bugzilla-daemon]

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

--- Comment #4 from joseph-thom...@gmx.de ---
Created attachment 118677
  --> https://bugs.freedesktop.org/attachment.cgi?id=118677=edit
/var/log/dmesg with kernel command line added drm.debug=14 log_buf_len=16M

-- 
You are receiving this mail because:
You are the assignee for the bug.
___
Nouveau mailing list
Nouveau@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/nouveau

[Nouveau] [Bug 92274] nouveau black screen and errors with two monitors attached

[bugzilla-daemon]

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

--- Comment #6 from Ilia Mirkin  ---
In your first dmesg, you have:

video=HDMI-0:e video=DVI-I-1:e

Are these required for something? Force-enabling this stuff just leads to
trouble down the line.

Interesting

[8.872612] nouveau E[PBUS][:01:00.0] MMIO read of 0x FAULT
at 0x690400 [ IBUS ]
[8.872781] nouveau E[PBUS][:01:00.0] MMIO write of 0xbadf1001 FAULT
at 0x690400 [ IBUS ]
[8.872869] nouveau E[PBUS][:01:00.0] MMIO read of 0x FAULT
at 0x6904c0 [ IBUS ]
[8.873043] nouveau E[PBUS][:01:00.0] MMIO write of 0xbadf1001 FAULT
at 0x6904c0 [ IBUS ]

in drm/nouveau/nvkm/engine/disp/hdmigk104.c:

/* AVI InfoFrame */
nvkm_mask(device, 0x69 + hdmi, 0x0001, 0x);
nvkm_wr32(device, 0x690008 + hdmi, 0x000d0282);
nvkm_wr32(device, 0x69000c + hdmi, 0x006f);
nvkm_wr32(device, 0x690010 + hdmi, 0x);
nvkm_wr32(device, 0x690014 + hdmi, 0x);
nvkm_wr32(device, 0x690018 + hdmi, 0x);
nvkm_mask(device, 0x69 + hdmi, 0x0001, 0x0001);

/* ??? InfoFrame? */
nvkm_mask(device, 0x6900c0 + hdmi, 0x0001, 0x);
nvkm_wr32(device, 0x6900cc + hdmi, 0x0010);
nvkm_mask(device, 0x6900c0 + hdmi, 0x0001, 0x0001);

69 + hdmi / 6900c0 + hdmi each get 2 reads/writes, but you only see one
error, both times on the enable. I wonder if this code doesn't need to be more
like

u32 foo = nvkm_rd32(device, 0x69 + hdmi);
nvkm_wr32(device, 0x69 + hdmi, foo & ~1);
...
nvkm_wr32(device, 0x69 + hdmi, foo | 1);

and same sort of thing for the second section. Are comfortable enough with code
to try this on your own, or do you need patches?

-- 
You are receiving this mail because:
You are the assignee for the bug.
___
Nouveau mailing list
Nouveau@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/nouveau

[Nouveau] [Bug 92274] nouveau black screen and errors with two monitors attached

[bugzilla-daemon]

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

--- Comment #5 from joseph-thom...@gmx.de ---
Having in mind that this could also be a Gennto-specific Bug or could be a
badly configured kernel, do you have any suggestions for my kernel config?
I think I followed all instructions to get nouveau to work also due to it
working with only one monitor connected, but there's also the possibility
that I forgot something, so feel free to ask or suggest something that helps
solving this.

-- 
You are receiving this mail because:
You are the assignee for the bug.
___
Nouveau mailing list
Nouveau@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/nouveau

Re: [Nouveau] [PATCH v3 0/6] Enable gpu switching on the MacBook Pro

[Lukas Wunner]

Hi Evan,

On Mon, Oct 05, 2015 at 11:23:21AM -0400, Evan Foss wrote:
> $ dmesg|grep Apple
> [0.00] efi: EFI v1.10 by Apple
> [0.00] DMI: Apple Inc. MacBookPro9,1/Mac-
> 4B7AC7E43945597E,
> BIOS MBP91.88Z.00D3.B08.1208081132 08/08/2012

That was the last of the pre-retinas. I have exactly the same machine,
so yes, it should work just fine on that one.

Best regards,

Lukas
___
Nouveau mailing list
Nouveau@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/nouveau