Re: [Nouveau] [PATCH mesa 0/5] nouveau: codegen: Make use of double immediates

[Ilia Mirkin]

Hi Hans,

All pushed. I made a few additional fixes and improvement to fp64
immediate handling along the way, but all your commits were fine
as-is. (Except that they enabled fp64 immediates on nv50 implicitly
which is wrong -- there are no immediate-taking variants on nv50, so I
fixed that glitch. But only the G200 can do fp64 in the first place,
and nouveau doesn't actually expose it. Corner case of a corner case
:) )

Thanks for taking care of this... it was a small bit of fp64 which I
always felt bad about not having finished up. (But not bad enough to
actually finish it myself.)

Cheers,

  -ilia


On Thu, Nov 5, 2015 at 8:32 AM, Hans de Goede  wrote:
> Hi All,
>
> This series implements using double immediates in the nouveau codegen code.
>
> This turns the following (nvc0) code:
>   1: mov u32 $r2 0x (8)
>   2: mov u32 $r3 0x3fe0 (8)
>   3: add f64 $r0d $r0d $r2d (8)
>
> Into:
>   1: add f64 $r0d $r0d 0.50 (8)
>
> This has been tested with the 2 double shader tests which I just send to
> the piglet list. On a gk208 (gk110 / SM35) card, and by checking the output
> of nouveau_compiler with both nvdisasm and envydis on gf100 / gk104 / gm107.
>
> Regards,
>
> Hans
___
Nouveau mailing list
Nouveau@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/nouveau

[Nouveau] [Bug 90626] HP ZBook 15 nouveau driver hangup for kernel >= 4.1

[bugzilla-daemon]

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

--- Comment #37 from Ilia Mirkin  ---
(In reply to vdanj...@free.fr from comment #36)
> I suffer from the same bug on HP ZBook. However, with the last Debian kernel
> (ie plain 4.3), I still got an 'error -22' and no "pmu: hw bug workaround
> enabled" log:

You need to manually remove the "fast" acpi method. See my instructions in
comment 24.

-- 
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 90181] [NVF1] native cs:go crashes when its about to load up a map.

[bugzilla-daemon]

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

--- Comment #1 from Ilia Mirkin  ---
I've fixed a number of resource lifetime handling issues since you filed the
bug. Please try the latest 11.0.x mesa and see if things improve (or git).

-- 
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 90871] NV30: Xfwm4 use_compositing - garbled display

[bugzilla-daemon]

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

Ilia Mirkin  changed:

   What|Removed |Added

 Status|REOPENED|RESOLVED
 Resolution|--- |NOTOURBUG

--- Comment #56 from Ilia Mirkin  ---
(In reply to poma from comment #55)
> https://bugzilla.xfce.org/show_bug.cgi?id=11962#c27

Please open new bugs when you have new issues. This is an issue introduced in
4.3. See https://bugzilla.kernel.org/show_bug.cgi?id=106431 for the discussion
and patch links.

-- 
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 90626] HP ZBook 15 nouveau driver hangup for kernel >= 4.1

[bugzilla-daemon]

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

--- Comment #38 from vdanj...@free.fr  ---
Created attachment 119456
  --> https://bugs.freedesktop.org/attachment.cgi?id=119456=edit
acpidump (HP ZBook 15, NVidia GK208GLM [Quadro K610M], BIOS v21/07/2015)

-- 
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 90626] HP ZBook 15 nouveau driver hangup for kernel >= 4.1

[bugzilla-daemon]

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

--- Comment #36 from vdanj...@free.fr  ---
I suffer from the same bug on HP ZBook. However, with the last Debian kernel
(ie plain 4.3), I still got an 'error -22' and no "pmu: hw bug workaround
enabled" log:

$ dmesg | grep nouveau
[0.00] Command line: BOOT_IMAGE=/vmlinuz-4.3.0-trunk-amd64
root=/dev/mapper/eyak-root ro nouveau.config=War00C800_0=1 apparmor=1
security=apparmor quiet
[0.00] Kernel command line: BOOT_IMAGE=/vmlinuz-4.3.0-trunk-amd64
root=/dev/mapper/eyak-root ro nouveau.config=War00C800_0=1 apparmor=1
security=apparmor quiet
[4.459102] nouveau :01:00.0: enabling device ( -> 0003)
[4.459126] nouveau :01:00.0: NVIDIA GK208 (108390a1)
[4.462991] nouveau :01:00.0: bios: version 80.28.52.00.09
[4.462994] nouveau :01:00.0: mxm: BIOS version 3.0
[4.462995] nouveau :01:00.0: bios: unknown ddc map v00
[4.463695] nouveau :01:00.0: devinit: 0xce73[0]: unknown opcode 0x00
[4.463699] nouveau :01:00.0: preinit failed with -22
[4.463718] nouveau: DRM::0080: init failed with -22
[4.464046] nouveau: probe of :01:00.0 failed with error -22

I will put in attachment the result of acpidump on my machine.

  Regards,
Vincent

-- 
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] Documentation request for MP warp error 0x10

[Ilia Mirkin]

On Fri, Nov 6, 2015 at 4:19 PM, Robert Morell  wrote:
> On Fri, Nov 06, 2015 at 04:15:29PM -0500, Ilia Mirkin wrote:
>> In order for ATOM.*/RED.* to work, the addresses in question must
>> *NOT* be inside of the 16MB local/shared windows. So if I'm getting
>> that error, the address must be inside.
>
> Yes, that's my understanding.
>
>> If so, this may be a reasonable explanation for what I'm seeing --
>
> Cool, I'm happy it helps.

Looks like we were setting LOCAL_BASE (0x077c) to 0, which was
effectively shadowing the low 16M of g[] space, which is where our
buffers were ending up too. Setting it to some high-up far-off land
makes everything work!

Obviously I'll need some cleverer way to deal with this, but looks
like it's all exactly as you described. Documentation does wonders :)
Looks like I should be able to make progress on my atomics/ssbo work
now.

Thanks again,

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

[Nouveau] [Bug 90871] NV30: Xfwm4 use_compositing - garbled display

[bugzilla-daemon]

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

poma  changed:

   What|Removed |Added

 Status|RESOLVED|REOPENED
 Resolution|NOTOURBUG   |---

--- Comment #55 from poma  ---

https://bugzilla.xfce.org/show_bug.cgi?id=11962#c27

-- 
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 90626] HP ZBook 15 nouveau driver hangup for kernel >= 4.1

[bugzilla-daemon]

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

--- Comment #40 from Ilia Mirkin  ---
(In reply to vdanj...@free.fr from comment #39)
> I was thinking that the "nouveau.config=War00C800_0=1" workaround was enough
> with a plain 4.3 kernel.

No, that will do nothing for you -- that's only for GK104/GK106/GK107 boards.
Yours is a GK208.

-- 
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 92852] NV34: WARNING: ... at drivers/gpu/drm/drm_irq.c:924 drm_vblank_count_and_time+0x71/0x80 [drm]()

[bugzilla-daemon]

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

--- Comment #3 from poma  ---

SW:
kernel-core-4.3.0-1.fc24.i686
libdrm-2.4.61-3.fc22.i686
xorg-x11-server-Xorg-1.17.4-1.fc22.i686
xorg-x11-drv-nouveau-1.0.12-0.3.fc22.i686
mesa-dri-drivers-10.6.9-1.20151008.fc22.i686

&

Xfwm4 from git commit:
"compositor: Fix GL without ARB_texture_rectangle"
http://git.xfce.org/xfce/xfwm4/commit/?id=2cfac64

Both, DRI3/XPresent and GLX, use_compositing true,

- DRI3/XPresent - configure --disable-epoxy --enable-xpresent
   Build Configuration for xfwm4:
 Xpresent support: yes
 Epoxy support:no

- GLX - configure --disable-xpresent --enable-epoxy
   Build Configuration for xfwm4:
 Xpresent support: no
 Epoxy support:yes

-- 
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 92852] NV34: WARNING: ... at drivers/gpu/drm/drm_irq.c:924 drm_vblank_count_and_time+0x71/0x80 [drm]()

[bugzilla-daemon]

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

poma  changed:

   What|Removed |Added

   See Also||https://bugs.freedesktop.or
   ||g/show_bug.cgi?id=92851

-- 
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 92852] NV34: WARNING: ... at drivers/gpu/drm/drm_irq.c:924 drm_vblank_count_and_time+0x71/0x80 [drm]()

[bugzilla-daemon]

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

Ilia Mirkin  changed:

   What|Removed |Added

   Severity|major   |normal

--- Comment #1 from Ilia Mirkin  ---
Identical to https://bugzilla.kernel.org/show_bug.cgi?id=106431

-- 
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 92851] NV34: err: MEM_FAULT

[bugzilla-daemon]

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

poma  changed:

   What|Removed |Added

   See Also||https://bugs.freedesktop.or
   ||g/show_bug.cgi?id=92852

-- 
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 92852] New: NV34: WARNING: ... at drivers/gpu/drm/drm_irq.c:924 drm_vblank_count_and_time+0x71/0x80 [drm]()

[bugzilla-daemon]

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

Bug ID: 92852
   Summary: NV34: WARNING: ... at drivers/gpu/drm/drm_irq.c:924
drm_vblank_count_and_time+0x71/0x80 [drm]()
   Product: xorg
   Version: unspecified
  Hardware: x86 (IA32)
OS: Linux (All)
Status: NEW
  Severity: major
  Priority: medium
 Component: Driver/nouveau
  Assignee: nouveau@lists.freedesktop.org
  Reporter: pomidorabelis...@gmail.com
QA Contact: xorg-t...@lists.x.org

Created attachment 119457
  --> https://bugs.freedesktop.org/attachment.cgi?id=119457=edit
dmesg 4.3.0-1.fc24.i686 NV34

NV34 / 4.3.0-1.fc24.i686
Both, DRI3/XPresent and GLX, use_compositing true:

dmesg:
WARNING: CPU: 0 PID: 1654 at drivers/gpu/drm/drm_irq.c:924
drm_vblank_count_and_time+0x71/0x80 [drm]()
...
Call Trace:
 [] dump_stack+0x41/0x61
 [] warn_slowpath_common+0x87/0xc0
 [] ? drm_vblank_count_and_time+0x71/0x80 [drm]
 [] ? drm_vblank_count_and_time+0x71/0x80 [drm]
 [] warn_slowpath_null+0x22/0x30
 [] drm_vblank_count_and_time+0x71/0x80 [drm]
 [] drm_send_vblank_event+0x6c/0x80 [drm]
 [] nouveau_finish_page_flip+0x66/0x120 [nouveau]
 [] nouveau_flip_complete+0x26/0x220 [nouveau]
 [] ? nouveau_display_vblstamp+0x70/0x80 [nouveau]
 [] nvif_notify+0x90/0x160 [nouveau]
 [] ? __wake_up+0x3f/0x50
 [] ? _raw_spin_unlock_irqrestore+0xd/0x10
 [] ? drm_handle_vblank+0x210/0x360 [drm]
 [] nvkm_client_ntfy+0x78/0x80 [nouveau]
 [] nvkm_client_notify+0x28/0x30 [nouveau]
 [] nvkm_notify_send+0x75/0x120 [nouveau]
 [] nvkm_event_send+0xb5/0xe0 [nouveau]
 [] nvkm_sw_chan_mthd+0x5e/0x80 [nouveau]
 [] nvkm_sw_mthd+0x91/0xb0 [nouveau]
 [] nv04_fifo_intr+0x5ff/0x770 [nouveau]
 [] ? _raw_spin_unlock_irqrestore+0xd/0x10
 [] ? nvkm_event_send+0x9b/0xe0 [nouveau]
 [] nvkm_fifo_intr+0x11/0x20 [nouveau]
 [] nvkm_engine_intr+0x19/0x20 [nouveau]
 [] nvkm_subdev_intr+0x13/0x20 [nouveau]
 [] nvkm_mc_intr+0x61/0xf0 [nouveau]
 [] ? add_interrupt_randomness+0x14e/0x1b0
 [] nvkm_pci_intr+0x42/0x80 [nouveau]
 [] handle_irq_event_percpu+0x76/0x190
 [] ? handle_simple_irq+0x70/0x70
 [] handle_irq_event+0x2a/0x50
 [] handle_fasteoi_irq+0x72/0x120
 [] handle_irq+0xa3/0xd0
   [] do_IRQ+0x3c/0xc0
 [] ? __copy_to_user_ll+0xd/0x10
 [] common_interrupt+0x33/0x38
 [] ? __fget_light+0x35/0x50
 [] __fdget+0x12/0x20
 [] do_sys_poll+0x2bd/0x570
 [] ? _copy_from_user+0x3c/0x50
 [] ? rw_copy_check_uvector+0x58/0x110
 [] ? unix_stream_recvmsg+0x46/0x60
 [] ? unix_set_peek_off+0x50/0x50
 [] ? sock_recvmsg+0x3d/0x50
 [] ? ___sys_recvmsg+0x116/0x150
 [] ? check_preempt_wakeup+0xe8/0x220
 [] ? poll_select_copy_remaining+0x130/0x130
 [] ? __alloc_skb+0x78/0x1e0
 [] ? __fdget+0x12/0x20
 [] ? __sys_recvmsg+0x44/0x80
 [] ? SYSC_socketcall+0x7ae/0x9c0
 [] ? unix_stream_sendmsg+0x358/0x380
 [] ? sock_sendmsg+0x2d/0x40
 [] ? do_readv_writev+0x140/0x350
 [] ? ktime_get+0x4a/0x120
 [] ? sock_sendmsg+0x40/0x40
 [] ? __audit_syscall_entry+0xaf/0x110
 [] ? do_audit_syscall_entry.isra.9+0x44/0x50
 [] ? syscall_trace_enter_phase1+0x107/0x130
 [] SyS_poll+0xc3/0x100
 [] syscall_call+0x7/0x7
---[ end trace aac837c2925b2e70 ]---
nouveau :01:00.0: Xorg[494]: failed to idle channel 0x [Xorg[494]]
nouveau :01:00.0: Xorg[494]: failed to idle channel 0x [Xorg[494]]
nouveau :01:00.0: DRM: 0xDBBA: Parsing digital output script table
nouveau :01:00.0: DRM: 0xDB7C: Parsing digital output script table
nouveau :01:00.0: DRM: GPU lockup - switching to software fbcon
nouveau :01:00.0: DRM: 0xDBBA: Parsing digital output script table
nouveau :01:00.0: Xorg[1847]: failed to idle channel 0x
[Xorg[1847]]
nouveau :01:00.0: Xorg[1847]: failed to idle channel 0x
[Xorg[1847]]
nouveau :01:00.0: DRM: 0xDBBA: Parsing digital output script table
nouveau :01:00.0: gr: intr 0010 [ERROR] nsource 0100
[DMA_W_PROTECTION] nstatus 0400 [PROTECTION_FAULT] ch 1 [Xorg[2211]] subc 0
class 0039 mthd 0100 data 
nouveau :01:00.0: Xorg[2211]: failed to idle channel 0x0001
[Xorg[2211]]
nouveau :01:00.0: Xorg[2211]: failed to idle channel 0x0001
[Xorg[2211]]
nouveau :01:00.0: Xorg[2211]: failed to idle channel 0x
[Xorg[2211]]
nouveau :01:00.0: timeout at
drivers/gpu/drm/nouveau/nvkm/engine/gr/nv20.c:46/nv20_gr_chan_fini()!
nouveau :01:00.0: Xorg[2211]: failed to idle channel 0x
[Xorg[2211]]
nouveau :01:00.0: fifo: DMA_PUSHER - ch 0 [DRM] get ff2c4784 put ff2c4784
state df2c4785 (err: MEM_FAULT) push 0100
nouveau :01:00.0: Xorg[2211]: failed to idle channel 0x
[Xorg[2211]]
nouveau :01:00.0: Xorg[2211]: failed to idle channel 0x
[Xorg[2211]]
nouveau :01:00.0: DRM: 0xDB7C: Parsing digital output script table
nouveau :01:00.0: timeout at
drivers/gpu/drm/nouveau/nvkm/engine/gr/nv04.c:1223/nv04_gr_idle()!
nouveau :01:00.0: gr: idle timed out with status 00022001

[Nouveau] [Bug 92851] NV34: err: MEM_FAULT

[bugzilla-daemon]

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

Ilia Mirkin  changed:

   What|Removed |Added

   Severity|major   |normal

--- Comment #1 from Ilia Mirkin  ---
Are you using DRI3? If so, please switch back to DRI2.

What mesa version are you using (this is relevant if you're using DRI3).

-- 
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 92851] NV34: err: MEM_FAULT

[bugzilla-daemon]

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

--- Comment #2 from poma  ---

How to reproduce:

Build, install and use Xfwm4 from git commit:
"compositor: Fix GL without ARB_texture_rectangle"
http://git.xfce.org/xfce/xfwm4/commit/?id=2cfac64

The problem applies to both, DRI3/XPresent and GLX, use_compositing true,
therefore build, install and use Xfwm4 configured:

- DRI3/XPresent - configure --disable-epoxy --enable-xpresent
   Build Configuration for xfwm4:
 Xpresent support: yes
 Epoxy support:no

- GLX - configure --disable-xpresent --enable-epoxy
   Build Configuration for xfwm4:
 Xpresent support: no
 Epoxy support:yes


1. Log in to xfce4-session

2. Make sure display compositing is enabled:
   $ xfconf-query --channel xfwm4 --property /general/use_compositing
   true

3. Suspend to disk:
   $ systemctl hibernate
   Of course, STD(S4) must be functional and correctly configured

4. RESUME(thaw) from S4

5. Disable display compositing:
   $ xfconf-query --channel xfwm4 --property /general/use_compositing --set
false
   $ xfconf-query --channel xfwm4 --property /general/use_compositing
   false

After this machine need reboot, shuffling multi-user.target & graphical.target
ain't helping.

-- 
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 92852] NV34: WARNING: ... at drivers/gpu/drm/drm_irq.c:924 drm_vblank_count_and_time+0x71/0x80 [drm]()

[bugzilla-daemon]

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

poma  changed:

   What|Removed |Added

   See Also||https://bugzilla.kernel.org
   ||/show_bug.cgi?id=106431
   Severity|normal  |major

-- 
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 92852] NV34: WARNING: ... at drivers/gpu/drm/drm_irq.c:924 drm_vblank_count_and_time+0x71/0x80 [drm]()

[bugzilla-daemon]

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

Ilia Mirkin  changed:

   What|Removed |Added

   Severity|major   |normal

--- Comment #2 from Ilia Mirkin  ---
Please don't fiddle with the importance. All it does is affect the color on
lists I look at, and the red annoys me.

-- 
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 92851] New: NV34: err: MEM_FAULT

[bugzilla-daemon]

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

Bug ID: 92851
   Summary: NV34: err: MEM_FAULT
   Product: xorg
   Version: unspecified
  Hardware: x86 (IA32)
OS: Linux (All)
Status: NEW
  Severity: major
  Priority: medium
 Component: Driver/nouveau
  Assignee: nouveau@lists.freedesktop.org
  Reporter: pomidorabelis...@gmail.com
QA Contact: xorg-t...@lists.x.org

NV34 / 4.2.5-201.fc22.i686

dmesg:
[   24.812240] nouveau  [  DEVICE][:01:00.0] Chipset: NV34 (NV34)
[   24.812249] nouveau  [  DEVICE][:01:00.0] Family : NV30
...
[  178.486096] ACPI: Waking up from system sleep state S4
...
[  355.012379] nouveau E[   PFIFO][:01:00.0] DMA_PUSHER - ch 1 [Xorg[517]]
get 0x0003c528 put 0x00025618 state 0xc000fa40 (err: MEM_FAULT) push 0x
[  355.012391] nouveau W[   PFIFO][:01:00.0] unknown intr 0x0001
[  608.759016] nouveau E[Xorg[517]] failed to idle channel 0x0001
[Xorg[517]]
[  638.934015] nouveau E[Xorg[517]] failed to idle channel 0x0001
[Xorg[517]]
[  669.024015] nouveau E[Xorg[517]] failed to idle channel 0x
[Xorg[517]]
[  699.220016] nouveau E[Xorg[517]] failed to idle channel 0x
[Xorg[517]]
[  715.214259] nouveau  [ DRM] 0xDBBA: Parsing digital output script table
[  719.981109] nouveau E[  PGRAPH][:01:00.0]  (unknown bits 0x0080)
nsource: nstatus:
[  719.981129] nouveau E[  PGRAPH][:01:00.0] ch 1 [Xorg[1579]] subc 0 class
0x0039 mthd 0x0100 data 0x
[  830.456017] nouveau E[Xorg[1579]] failed to idle channel 0x0001
[Xorg[1579]]
[  860.514016] nouveau E[Xorg[1579]] failed to idle channel 0x0001
[Xorg[1579]]
[  891.004014] nouveau E[Xorg[1579]] failed to idle channel 0x
[Xorg[1579]]
[  902.422408] nouveau  [ DRM] 0xDB7C: Parsing digital output script table
[  902.518808] nouveau E[ DRM] GPU lockup - switching to software fbcon
[  921.324016] nouveau E[Xorg[1579]] failed to idle channel 0x
[Xorg[1579]]
[  952.652018] nouveau E[Xorg[1579]] failed to idle channel 0x
[Xorg[1579]]
[  982.702016] nouveau E[Xorg[1579]] failed to idle channel 0x
[Xorg[1579]]

-- 
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 92851] NV34: err: MEM_FAULT

[bugzilla-daemon]

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

--- Comment #3 from Ilia Mirkin  ---
Does this only happen with a suspend in between? Does it still happen if you
stick to DRI2 instead of using DRI3?

-- 
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 92852] NV34: WARNING: ... at drivers/gpu/drm/drm_irq.c:924 drm_vblank_count_and_time+0x71/0x80 [drm]()

[bugzilla-daemon]

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

--- Comment #4 from poma  ---

How to reproduce:

Run xfce4-session with display compositing enabled:
$ xfconf-query --channel xfwm4 --property /general/use_compositing
true

-- 
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] Fw: new message

[Nouveau]

Hello!

 

New message, please read 

 

Nouveau

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

[Nouveau] Fw: new message

[Nouveau]

Hello!

 

New message, please read 

 

Nouveau

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

[Nouveau] [Bug 92192] nouveau does not detect monitor native resolution (Geforce GT240 / GT215)

[bugzilla-daemon]

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

--- Comment #5 from Germano Massullo  ---
(In reply to Ilia Mirkin from comment #4)
> It appears all we get are those modelines from EDID. You can add your own
> custom ones if you like.

Okay but it's an "hack around"

-- 
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] NOUVEAU(0): DRI3 on EXA enabled

[poma]

On 05.11.2015 23:47, poma wrote:
> On 04.11.2015 12:27, poma wrote:
>> On 04.11.2015 11:57, Martin Peres wrote:
>>> On 02/11/15 08:28, poma wrote:
 An interesting results.

 DRI2:

 $ vblank_mode=0 glxgears
 ATTENTION: default value of option vblank_mode overridden by environment.
 6321 frames in 5.0 seconds = 1264.103 FPS
 6380 frames in 5.0 seconds = 1275.943 FPS
 6369 frames in 5.0 seconds = 1273.629 FPS
 6377 frames in 5.0 seconds = 1275.322 FPS
 6387 frames in 5.0 seconds = 1277.330 FPS
 6407 frames in 5.0 seconds = 1281.337 FPS
 6381 frames in 5.0 seconds = 1276.053 FPS
 6410 frames in 5.0 seconds = 1281.855 FPS
 6405 frames in 5.0 seconds = 1280.905 FPS
 6378 frames in 5.0 seconds = 1275.599 FPS
 ^C

 ~

 DRI3:

 $ cat /etc/X11/xorg.conf.d/nouveau-dri3.conf
 Section "Device"
Identifier  "Videocard0"
Driver  "nouveau"
Option  "DRI" "3"
 EndSection

 $ grep DRI3 /var/log/Xorg.0.log
 [ 4367.417] (II) NOUVEAU(0): DRI3 on EXA enabled
>>>
>>> For the record, the only acceptable way of checking for DRI3 is to run 
>>> the program with LIBGL_DEBUG=verbose. Any other solution is wrong.
>>>
>>
>>
>> - DRI2:
>>
>> [  3210.736] (II) Loading sub module "dri2"
>> [  3210.736] (II) LoadModule: "dri2"
>> [  3210.736] (II) Module "dri2" already built-in
>> [  3210.736] (==) NOUVEAU(0): Allowed maximum DRI level 2.
>> [  3210.877] (II) NOUVEAU(0): [DRI2] Setup complete
>> [  3210.894] (II) GLX: Initialized DRI2 GL provider for screen 0
>>
>>
>> $ LIBGL_DEBUG=verbose vblank_mode=0 glxgears
>> libGL: OpenDriver: trying /usr/lib64/dri/tls/nouveau_dri.so
>> libGL: OpenDriver: trying /usr/lib64/dri/nouveau_dri.so
>> ATTENTION: default value of option vblank_mode overridden by environment.
>> libGL: Using DRI2 for screen 0
>> 6231 frames in 5.0 seconds = 1246.081 FPS
>> 6387 frames in 5.0 seconds = 1277.312 FPS
>> 6421 frames in 5.0 seconds = 1284.023 FPS
>> 6375 frames in 5.0 seconds = 1274.905 FPS
>> 6399 frames in 5.0 seconds = 1279.609 FPS
>> 6440 frames in 5.0 seconds = 1287.837 FPS
>> 6371 frames in 5.0 seconds = 1274.142 FPS
>> 6397 frames in 5.0 seconds = 1279.245 FPS
>> 6429 frames in 5.0 seconds = 1285.668 FPS
>> 6371 frames in 5.0 seconds = 1274.177 FPS
>> ^C
>>
>> ~
>>
>> - DRI3:
>>
>> [  3750.992] (II) Loading sub module "dri2"
>> [  3750.992] (II) LoadModule: "dri2"
>> [  3750.992] (II) Module "dri2" already built-in
>> [  3750.992] (**) NOUVEAU(0): Option "DRI" "3"
>> [  3750.992] (**) NOUVEAU(0): Allowed maximum DRI level 3.
>> [  3751.128] (II) NOUVEAU(0): [DRI2] Setup complete
>> [  3751.128] (II) NOUVEAU(0): DRI3 on EXA enabled
>> [  3751.145] (II) GLX: Initialized DRI2 GL provider for screen 0
>>
>>
>> $ LIBGL_DEBUG=verbose vblank_mode=0 glxgears
>> libGL: pci id for fd 4: 10de:06e4, driver nouveau
>> libGL: OpenDriver: trying /usr/lib64/dri/tls/nouveau_dri.so
>> libGL: OpenDriver: trying /usr/lib64/dri/nouveau_dri.so
>> ATTENTION: default value of option vblank_mode overridden by environment.
>> libGL: Using DRI3 for screen 0
>> 7261 frames in 5.0 seconds = 1452.136 FPS
>> 7353 frames in 5.0 seconds = 1470.404 FPS
>> 7354 frames in 5.0 seconds = 1470.652 FPS
>> 7385 frames in 5.0 seconds = 1476.916 FPS
>> 7337 frames in 5.0 seconds = 1467.380 FPS
>> 7344 frames in 5.0 seconds = 1468.661 FPS
>> 7360 frames in 5.0 seconds = 1471.951 FPS
>> 7327 frames in 5.0 seconds = 1465.211 FPS
>> 7345 frames in 5.0 seconds = 1468.992 FPS
>> 7371 frames in 5.0 seconds = 1474.112 FPS
>> ^C
>>
>> ~
>>
>> $ xfwm4 --version
>> This is xfwm4 version 4.12.3git.20150825 (revision 20150825) for Xfce 4.12
>> Released under the terms of the GNU General Public License.
>> Compiled against GTK+-2.24.28, using GTK+-2.24.28.
>>
>> Build configuration and supported features:
>> - Startup notification support: Yes
>> - XSync support:Yes
>> - Render support:   Yes
>> - Xrandr support:   Yes
>> - Xpresent support: Yes
>> - Embedded compositor:  Yes
>> - Epoxy support:No
>>
>>
>> $ xfconf-query --channel xfwm4 --property /general/use_compositing
>> true
>>
>>
>> SW:
>> xorg-x11-drv-nouveau-1.0.12-0.3.fc22.x86_64
>> xorg-x11-server-Xorg-1.17.3-1.fc22.x86_64
>> mesa-dri-drivers-10.6.9-1.20151008.fc22.x86_64
>> libdrm-2.4.61-3.fc22.x86_64
>> libXpresent-1.0.0-1.fc22.x86_64
>> xfwm4-4.12.3-15.1.xpresent.nv34.git20150825.fc22.x86_64
>>
>>
> 
> NV34 / i686
> 
> - DRI2:
> 
> /var/log/Xorg.0.log
> [   438.397] (II) Loading sub module "dri2"
> [   438.397] (II) LoadModule: "dri2"
> [   438.397] (II) Module "dri2" already built-in
> [   438.397] (==) NOUVEAU(0): Allowed maximum DRI level 2.
> [   

Re: [Nouveau] [PATCH] drm/nouveau: Fix pre-nv50 pageflip events

[Thierry Reding]

Cc += Mario Kleiner, Mario, can you take a look whether this proposed
solution makes sense and fixes the issues you were seeing back when you
posted the patch in commit:

commit af4870e406126b7ac0ae7c7ce5751f25ebe60f28
Author: Mario Kleiner 
Date:   Tue May 13 00:42:08 2014 +0200

drm/nouveau/kms/nv04-nv40: fix pageflip events via special case.

Cards with nv04 display engine can't reliably use vblank
counts and timestamps computed via drm_handle_vblank(), as
the function gets invoked after sending the pageflip events.

Fix this by defaulting to the old crtcid = -1 fallback path
on <= NV-50 cards, and only using the precise path on NV-50
and later.

Signed-off-by: Mario Kleiner 
Signed-off-by: Ben Skeggs 
Cc:  # 3.13+

Do you happen to still have the setup around where you saw this?

Thierry

On Fri, Oct 30, 2015 at 10:55:40PM +0100, Daniel Vetter wrote:
> Apparently pre-nv50 pageflip events happen before the actual vblank
> period. Therefore that functionality got semi-disabled in
> 
> commit af4870e406126b7ac0ae7c7ce5751f25ebe60f28
> Author: Mario Kleiner 
> Date:   Tue May 13 00:42:08 2014 +0200
> 
> drm/nouveau/kms/nv04-nv40: fix pageflip events via special case.
> 
> Unfortunately that hack got uprooted in
> 
> commit cc1ef118fc099295ae6aabbacc8af94d8d8885eb
> Author: Thierry Reding 
> Date:   Wed Aug 12 17:00:31 2015 +0200
> 
> drm/irq: Make pipe unsigned and name consistent
> 
> Trigering a warning when trying to sample the vblank timestamp for a
> non-existing pipe. There's a few ways to fix this:
> 
> - Open-code the old behaviour, which just enshrines this slight
>   breakage of the userspace ABI.
> 
> - Revert Mario's commit and again inflict broken timestamps, again not
>   pretty.
> 
> - Fix this for real by delaying the pageflip TS until the next vblank
>   interrupt, thereby making it accurate.
> 
> This patch implements the third option. Since having a page flip
> interrupt that happens when the pageflip gets armed and not when it
> completes in the next vblank seems to be fairly common (older i915 hw
> works very similarly) create a new helper to arm vblank events for
> such drivers.
> 
> Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=106431
> Cc: Thierry Reding 
> Cc: Mario Kleiner 
> Cc: Ben Skeggs 
> Cc: Ilia Mirkin 
> Signed-off-by: Daniel Vetter 
> ---
> 
> Note that due to lack of hw this is completely untested. But I think
> it's the right way to fix this.
> -Daniel
> ---
>  drivers/gpu/drm/drm_irq.c | 56 
> ++-
>  drivers/gpu/drm/nouveau/nouveau_display.c | 16 -
>  include/drm/drmP.h|  4 +++
>  3 files changed, 66 insertions(+), 10 deletions(-)
> 
> diff --git a/drivers/gpu/drm/drm_irq.c b/drivers/gpu/drm/drm_irq.c
> index 46dbc34b81ba..b3e1f58666a6 100644
> --- a/drivers/gpu/drm/drm_irq.c
> +++ b/drivers/gpu/drm/drm_irq.c
> @@ -972,7 +972,8 @@ static void send_vblank_event(struct drm_device *dev,
>   struct drm_pending_vblank_event *e,
>   unsigned long seq, struct timeval *now)
>  {
> - WARN_ON_SMP(!spin_is_locked(>event_lock));
> + assert_spin_locked(>event_lock);
> +
>   e->event.sequence = seq;
>   e->event.tv_sec = now->tv_sec;
>   e->event.tv_usec = now->tv_usec;
> @@ -985,6 +986,59 @@ static void send_vblank_event(struct drm_device *dev,
>  }
>  
>  /**
> + * drm_arm_vblank_event - arm vblanke event after pageflip
> + * @dev: DRM device
> + * @pipe: CRTC index
> + * @e: the event to prepare to send
> + *
> + * A lot of drivers need to generate vblank events for the very next vblank
> + * interrupt. For example when the page flip interrupt happens when the page
> + * flip gets armed, but not when it actually executes within the next vblank
> + * period. This helper function implements exactly the required vblank arming
> + * behaviour.
> + *
> + * Caller must hold event lock. Caller must also hold a vblank reference for 
> the
> + * event @e, which will be dropped when the next vblank arrives.
> + *
> + * This is the legacy version of drm_crtc_arm_vblank_event().
> + */
> +void drm_arm_vblank_event(struct drm_device *dev, unsigned int pipe,
> +   struct drm_pending_vblank_event *e)
> +{
> + struct timeval now;
> + unsigned int seq;
> +
> + assert_spin_locked(>event_lock);
> +
> + e->pipe = pipe;
> + list_add_tail(>base.link, >vblank_event_list);
> +}
> +EXPORT_SYMBOL(drm_arm_vblank_event);
> +
> +/**
> + * drm_arm_vblank_event - arm vblanke event after pageflip
> + * @crtc: the source CRTC of the vblank event
> + * @e: the event to send
> + *
> + * A lot of drivers need to generate vblank events for the 

[Nouveau] [Bug 92833] [NV117] nouveau E[ PFIFO][0000:01:00.0] read fault at 0x0000011000 [UNSUPPORTED_KIND] from PBDMA0/HOST on channel 0x007ed78000 [unknown]

[bugzilla-daemon]

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

--- Comment #2 from ba...@barrys-emacs.org ---
(In reply to Ilia Mirkin from comment #1)
> Are those the first messages? 

There where some info ones. (sorry I've lost the setup for the moment to repro
this).

> What kernel are you using? Or to rephrase,
> does this still happen with kernel 4.3.0?

F23 is on 4.2.5. I will see if I can get a 4.3.0 to play with.

Is there any version of nouveau that I need to use with 4.3.0?

> nv50cal_space *basically* means the GPU has hung -- it's when we run out of
> IB space for pushbuf submission.

o.k.

-- 
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] Documentation request for MP warp error 0x10

[Robert Morell]

On Fri, Oct 02, 2015 at 06:05:21PM -0400, Ilia Mirkin wrote:
> Could you advise what the proper way of indicating
> that the memory is "global" to the op? I'm sure I'm just missing
> something simple. If you show me what to look for in SM35 I can
> probably find it on my own for SM20/SM30/SM50.

Sorry again for the delay.  Here's what I've been able to find out about
the generic thread address space (used by the SMs) and what types of
memory it contains.  Hopefully this clears things up.


Local memory is a per-thread space.
Shared memory is a per-CTA space (compute shaders only).

LDL and STL instructions access local memory with a zero offset.
LDS, LSDLK, STS, and STSCUL instructions access shared memory with a zero
offset.

LD, ST, RED, ATOM, and CCTL.D instructions access the generic thread address
space, which is layered on top of the channel's virtual address space.

In the generic thread address space, there are 16MB windows into local and
shared memory; everything not in a Local or Shared address window accesses
global virtual memory.

The local window offset within the generic thread address space is determined
by the SetShaderLocalMemoryWindow class method (offset 0x77c in classes *97 and
*c0).

The shared window offset within the generic thread address space is determined
by the SetShaderSharedMemoryWindow class method (offset 0x214 in classes *c0).

For both methods, the offset is in bytes, but the window must be aligned to a
16MB boundary (so the lower 24 bits of the data must be zero). The upper 32
bits of the windows are hard-coded to 0 (so they must be placed within the
lower 4GB of address space).

Generally, it is expected that software will reserve ranges in the global
virtual address space where these windows will be placed. (Otherwise anything
mapped there will be inaccessible to shaders.)

For graphics shaders, the shared address space logic does not exist, so there
is no need to reserve virtual memory for it.


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

Re: [Nouveau] Documentation request for MP warp error 0x10

[Ilia Mirkin]

On Fri, Nov 6, 2015 at 3:59 PM, Robert Morell  wrote:
> On Fri, Oct 02, 2015 at 06:05:21PM -0400, Ilia Mirkin wrote:
>> Could you advise what the proper way of indicating
>> that the memory is "global" to the op? I'm sure I'm just missing
>> something simple. If you show me what to look for in SM35 I can
>> probably find it on my own for SM20/SM30/SM50.
>
> Sorry again for the delay.  Here's what I've been able to find out about
> the generic thread address space (used by the SMs) and what types of
> memory it contains.  Hopefully this clears things up.
>
>
> Local memory is a per-thread space.
> Shared memory is a per-CTA space (compute shaders only).
>
> LDL and STL instructions access local memory with a zero offset.
> LDS, LSDLK, STS, and STSCUL instructions access shared memory with a zero
> offset.
>
> LD, ST, RED, ATOM, and CCTL.D instructions access the generic thread address
> space, which is layered on top of the channel's virtual address space.
>
> In the generic thread address space, there are 16MB windows into local and
> shared memory; everything not in a Local or Shared address window accesses
> global virtual memory.
>
> The local window offset within the generic thread address space is determined
> by the SetShaderLocalMemoryWindow class method (offset 0x77c in classes *97 
> and
> *c0).
>
> The shared window offset within the generic thread address space is determined
> by the SetShaderSharedMemoryWindow class method (offset 0x214 in classes *c0).
>
> For both methods, the offset is in bytes, but the window must be aligned to a
> 16MB boundary (so the lower 24 bits of the data must be zero). The upper 32
> bits of the windows are hard-coded to 0 (so they must be placed within the
> lower 4GB of address space).
>
> Generally, it is expected that software will reserve ranges in the global
> virtual address space where these windows will be placed. (Otherwise anything
> mapped there will be inaccessible to shaders.)
>
> For graphics shaders, the shared address space logic does not exist, so there
> is no need to reserve virtual memory for it.

Hi Robert, thanks so much for getting back to me. I believe I've
understood what you've said, but please confirm:

In order for ATOM.*/RED.* to work, the addresses in question must
*NOT* be inside of the 16MB local/shared windows. So if I'm getting
that error, the address must be inside.

If so, this may be a reasonable explanation for what I'm seeing --
while I knew about the local/shared windows, I didn't realize that the
windows were 16MB-sized.

Thanks again,

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

Re: [Nouveau] Documentation request for MP warp error 0x10

[Robert Morell]

On Fri, Nov 06, 2015 at 04:15:29PM -0500, Ilia Mirkin wrote:
> In order for ATOM.*/RED.* to work, the addresses in question must
> *NOT* be inside of the 16MB local/shared windows. So if I'm getting
> that error, the address must be inside.

Yes, that's my understanding.

> If so, this may be a reasonable explanation for what I'm seeing --

Cool, I'm happy it helps.


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