[Nouveau] xfree86: use modesetting driver by default on GeForce 8 and newer - Fedora

[poma]

Hello

Default to xf86-video-modesetting on GeForce 8 and newer.
https://src.fedoraproject.org/cgit/rpms/xorg-x11-server.git/commit/?id=de1c849ff18b41f53d003bb70bf8b1744b749af8

This is thrown onto users downstream, without any further explanation, why 
modesetting is preferred for GeForce 8.
Is the nouveau Xorg DDX i.e. xf86-video-nouveau broken with NV50 family (Tesla)?

I mean xf86-video-nouveau works here with a couple of NV50, so what is the 
story there?

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

[Nouveau] NVAC - WARN_ON(nvbo->pin_refcnt > 0);

[poma]

[ cut here ]
WARNING: CPU: 3 PID: 692 at drivers/gpu/drm/nouveau/nouveau_bo.c:137 
nouveau_bo_del_ttm+0x7f/0x90 [nouveau]
Modules linked in: ... nouveau mxm_wmi video i2c_algo_bit ttm drm_kms_helper 
drm wmi ...
CPU: 3 PID: 692 Comm: Xorg Not tainted 4.10.8-1002.fc24.x86_64 #1
...
Call Trace:
 dump_stack+0x63/0x86
 __warn+0xcb/0xf0
 warn_slowpath_null+0x1d/0x20
 nouveau_bo_del_ttm+0x7f/0x90 [nouveau]
 ttm_bo_release_list+0xcb/0x210 [ttm]
 ttm_bo_release+0x198/0x240 [ttm]
 ttm_bo_unref+0x24/0x30 [ttm]
 nouveau_gem_object_del+0x94/0xf0 [nouveau]
 drm_gem_object_free+0x29/0x70 [drm]
 drm_gem_object_unreference_unlocked+0x3a/0xa0 [drm]
 drm_gem_object_handle_unreference_unlocked+0x65/0xb0 [drm]
 drm_gem_object_release_handle+0x53/0x90 [drm]
 idr_for_each+0xb0/0x110
 ? drm_gem_object_handle_unreference_unlocked+0xb0/0xb0 [drm]
 ? nouveau_abi16_fini+0x50/0x70 [nouveau]
 drm_gem_release+0x20/0x30 [drm]
 drm_release+0x34c/0x3a0 [drm]
 __fput+0xdf/0x1e0
 fput+0xe/0x10
 task_work_run+0x80/0xa0
 do_exit+0x2c8/0xb80
 ? __do_page_fault+0x266/0x4e0
 do_group_exit+0x47/0xb0
 SyS_exit_group+0x14/0x20
 entry_SYSCALL_64_fastpath+0x1a/0xa9
...
---[ end trace 02bd4b75c91c94a7 ]---

4.10.8-1002.fc24.x86_64 = 4.10.8-100.fc24.x86_64 + 
https://github.com/skeggsb/nouveau/commit/23da66b.patch
i.e.
stable 4.10.8 + "kms/nv50: fix double dma_fence_put() when destroying plane 
state"


Ref.
https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git/tree/drivers/gpu/drm/nouveau/nouveau_bo.c?id=refs/tags/v4.10.8#n137

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

[Nouveau] NVAC - BUG: unable to handle kernel NULL pointer dereference

[poma]

With lightweight desktoping,
the atomic modesetting seems far from robust.

BUG: unable to handle kernel NULL pointer dereference at 0021
IP: dma_fence_wait_timeout+0x36/0xf0
...
Oops:  [#1] SMP
Modules linked in: ... nouveau ...
CPU: 0 PID: 6895 Comm: Xorg Not tainted 4.10.5-1001.fc24.x86_64 #1
...
Call Trace:
 drm_atomic_helper_wait_for_fences+0x48/0x120 [drm_kms_helper]
 nv50_disp_atomic_commit+0x19c/0x2a0 [nouveau]
 drm_atomic_commit+0x4b/0x50 [drm]
 drm_atomic_helper_update_plane+0xec/0x150 [drm_kms_helper]
 __setplane_internal+0x1b4/0x280 [drm]
 drm_mode_cursor_universal+0x126/0x210 [drm]
 drm_mode_cursor_common+0x86/0x180 [drm]
 drm_mode_cursor_ioctl+0x50/0x70 [drm]
 drm_ioctl+0x21b/0x4c0 [drm]
 ? drm_mode_setplane+0x1a0/0x1a0 [drm]
 nouveau_drm_ioctl+0x74/0xc0 [nouveau]
 do_vfs_ioctl+0xa3/0x5f0
 SyS_ioctl+0x79/0x90
 entry_SYSCALL_64_fastpath+0x1a/0xa9
...
RIP: dma_fence_wait_timeout+0x36/0xf0 RSP: c1f700723a38
...
---[ end trace a6bef2d32ed5fbbc ]---


BUG: unable to handle kernel NULL pointer dereference at 0021
IP: dma_fence_wait_timeout+0x36/0xf0
...
Oops:  [#1] SMP
Modules linked in: ... nouveau ...
CPU: 3 PID: 30654 Comm: Xorg Tainted: GE   
4.11.0-0.rc3.git0.1.fc26.x86_64 #1
...
Call Trace:
 drm_atomic_helper_wait_for_fences+0x73/0x110 [drm_kms_helper]
 nv50_disp_atomic_commit+0x28a/0x2c0 [nouveau]
 ? refcount_dec_and_test+0x11/0x20
 drm_atomic_commit+0x4b/0x50 [drm]
 drm_atomic_helper_update_plane+0xf1/0x150 [drm_kms_helper]
 __setplane_internal+0x1fa/0x260 [drm]
 drm_mode_cursor_universal+0x12a/0x220 [drm]
 drm_mode_cursor_common+0x88/0x180 [drm]
 drm_mode_cursor_ioctl+0x4a/0x60 [drm]
 drm_ioctl+0x203/0x4d0 [drm]
 ? drm_mode_setplane+0x1a0/0x1a0 [drm]
 nouveau_drm_ioctl+0x72/0xc0 [nouveau]
 do_vfs_ioctl+0xa5/0x600
 ? security_inode_getsecid+0x1b/0x40
 SyS_ioctl+0x79/0x90
 entry_SYSCALL_64_fastpath+0x1a/0xa9
...
RIP: dma_fence_wait_timeout+0x36/0xf0 RSP: bda700723a40
...
---[ end trace 95b0fca6a8295839 ]---


Subsequently, hardware reset is needed.

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

Re: [Nouveau] NVAC: WARN_ON(nvbo->pin_refcnt > 0);

[poma]

[...]
> WARNING: CPU: 1 PID: 701 at drivers/gpu/drm/nouveau/nouveau_bo.c:137 
> nouveau_bo_del_ttm+0x7f/0x90 [nouveau]
[...]

Which does not appear within mainline 4.10,
tested with 4.10.0-1.fc26.x86_64+debug.

OK

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

Re: [Nouveau] nouveau preventing shutdown after suspend-resume

[poma]

On 17.02.2017 18:06, Ilia Mirkin wrote:
> On Fri, Feb 17, 2017 at 11:22 AM, João Paulo Rechi Vita
>  wrote:
>> Hello Ilia,
>>
>> On 17 February 2017 at 11:14, Ilia Mirkin  wrote:
>>> On Fri, Feb 17, 2017 at 10:54 AM, João Paulo Rechi Vita
>>>  wrote:
 I'm happy to file
 a bugzilla entry and provide any other needed information or help with
 testing. Are nouveau bugs tracked on bugs.kernel.org or the fdo
 bugzilla?
>>>
>>> Nouveau bugs are tracked on the fdo bugzilla. It would appear that
>>> you're using a 4.8 kernel. Do issues persist with a 4.10 kernel? I'm
>>> thinking of upstream commit cae9ff036ee, but it's likely that there
>>> have also been others I'm not thinking of.
>>>
>>
>> Yes, although the logs I have pasted were indeed collected using a 4.8
>> kernel, the problem persists with a recent Linus' tree (v4.10-rc8 + a
>> couple of commits) which contains cae9ff036ee.
> 
> You should file a bug with all the relevant info. BTW, odd that the
> device is reported as 179c. 1780-17bf isn't allocated to anything.
> There *is* a 139c device, "GM107M [GeForce 940M]", but that would
> imply there's an extra 0x0400 bit set.
> 

$ curl -s ftp://download.nvidia.com/XFree86/Linux-x86/375.39/README/README.txt 
| grep -i 179c 
GeForce 940MX 179C   E


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

[Nouveau] NVAC: WARN_ON(nvbo->pin_refcnt > 0);

[poma]

Hello fellows!

Signal finally goes through ION's HDMI,
however
# chvt from 5 "graphical" to 3 "textual",
and then at the very end of reboot,
WARN emerges:
...
nouveau :01:00.0: DRM: EVO timeout
[ cut here ]
WARNING: CPU: 1 PID: 701 at drivers/gpu/drm/nouveau/nouveau_bo.c:137 
nouveau_bo_del_ttm+0x7f/0x90 [nouveau]
Modules linked in: ... nouveau mxm_wmi video i2c_algo_bit ttm drm_kms_helper 
drm wmi ...
CPU: 1 PID: 701 Comm: Xorg Not tainted 4.10.0-0.rc8.git0.1.fc26.x86_64 #1
...
Call Trace:
 dump_stack+0x63/0x84
 __warn+0xcb/0xf0
 warn_slowpath_null+0x1d/0x20
 nouveau_bo_del_ttm+0x7f/0x90 [nouveau]
 ttm_bo_release_list+0xd7/0x1e0 [ttm]
 ttm_bo_release+0x19c/0x250 [ttm]
 ttm_bo_unref+0x23/0x30 [ttm]
 nouveau_gem_object_del+0x8f/0xe0 [nouveau]
 drm_gem_object_free+0x29/0x70 [drm]
 drm_gem_object_unreference_unlocked+0x34/0x80 [drm]
 drm_gem_object_handle_unreference_unlocked+0x69/0xc0 [drm]
 drm_gem_object_release_handle+0x53/0x90 [drm]
 ? drm_gem_object_handle_unreference_unlocked+0xc0/0xc0 [drm]
 idr_for_each+0xa4/0x100
 ? nouveau_abi16_fini+0x50/0x70 [nouveau]
 drm_gem_release+0x20/0x30 [drm]
 drm_release+0x33d/0x390 [drm]
 __fput+0xdf/0x1e0
 fput+0xe/0x10
 task_work_run+0x76/0x90
 do_exit+0x2d0/0xb70
 ? __do_page_fault+0x267/0x4c0
 do_group_exit+0x47/0xb0
 SyS_exit_group+0x14/0x20
 entry_SYSCALL_64_fastpath+0x1a/0xa9
RIP: 0033:0x7fa5510acdd8
RSP: 002b:7fff4a0cb608 EFLAGS: 0246 ORIG_RAX: 00e7
RAX: ffda RBX: 7fa5536839a0 RCX: 7fa5510acdd8
RDX:  RSI: 003c RDI: 
RBP: 7fff4a0cb600 R08: 00e7 R09: fc88
R10: 7fa552bf5d80 R11: 0246 R12: 7fa552bf5d68
R13: 004a R14:  R15: 7fff4a0cb2f0
---[ end trace 53f6d91de8e38281 ]---

Ref.
https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/drivers/gpu/drm/nouveau/nouveau_bo.c?id=refs/tags/v4.10-rc8#n137
___
Nouveau mailing list
Nouveau@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/nouveau

Re: [Nouveau] NVAC "No Signal"

[poma]

On 09.01.2017 19:20, Roy Spliet wrote:
> Op 09-01-17 om 00:24 schreef Ben Skeggs:
>> On 12/24/2016 07:48 PM, Roy Spliet wrote:
>>> I've observed this regression on my NVAC board; a 1920x1080 TV on HDMI
>>> (single monitor set-up) gets no signal with Fedora kernels from 4.8.
>>> Trace sent to the mmio dumps mailbox. A brief scan already revealed that
>>> register 0xe840 is never touched, so it appears that NVIDIA does
>>> something different.
>>> VBIOS for this board is in the usual place. Commenting out 0xac from the
>>> workaround seems to solve the problem, as tested on a Fedora 4.9 kernel.
>>> I hope that helps you get a little further with this issue. Cheers, and
>>> happy holidays!
>> Thanks Roy,
>>
>> NVIDIA told me that it applied to these boards, but, I can't see NVIDIA
>> attempting the workaround in your trace, so until there's evidence to
>> the contrary, I've disabled it for MCP7x for now.
>>
>> Ben.
> Thanks. Since your patch is the exact modification I made to verify the 
> workaround was bugging me, consider it:
> 
> Tested-by: Roy Spliet <nouv...@spliet.org>
> 
> Given "no display on HDMI since 4.8" is quite a serious regression 
> (albeit for a small userbase), please consider submitting this to 4.10 
> as well as a "back-port" to the upstream 4.8 and 4.9 trees.
> Thanks again! Cheers,
> 
> Roy
> 


Thanks Roy

Hello Dave, Greg

If it is not already, please push for:
- stable 4.9.6
- mainline 4.10-rc5

Also:
Reported-by: poma <p...@gmail.com>
Tested-by: poma <p...@gmail.com>

Ref.
https://lists.freedesktop.org/archives/nouveau/2016-October/026242.html
https://github.com/skeggsb/nouveau/commit/2e5fba2.patch

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

Re: [Nouveau] NVAC "No Signal"

[poma]

On 20.10.2016 00:46, Ben Skeggs wrote:
[...]
> I'd like to see a mmiotrace of the NVIDIA binary driver on a system
> where this WAR breaks things.  I applied it to all the GPUs that NVIDIA
> told me required it.
> 
> Ben.
> 

Still broken, more than four months,
tested with mainline 4.9-rc6.

According to Ben Skeggs,
since this is "told" by NVIDIA i.e. by you, or perhaps some other of your 
colleagues,
what's more that I don't see progress in this regard,
would you guys from NVIDIA R mind help him to finally solve this?

Thanks.


Ref.
https://lists.freedesktop.org/archives/nouveau/2016-October/026242.html
http://goo.gl/Gm4ffO
mmiotrace-nouveau/
___
Nouveau mailing list
Nouveau@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/nouveau

Re: [Nouveau] NVAC "No Signal"

[poma]

On 21.10.2016 10:56, Pierre Moreau wrote:
> On 01:15 am - Oct 21 2016, Lukas Wunner wrote:
>> On Thu, Oct 20, 2016 at 10:08:28AM +0200, Lukas Wunner wrote:
>>> On Wed, Oct 19, 2016 at 07:58:06PM +0200, Pierre Moreau wrote:
 For example, my laptop (which also has an NVAC) has been triggering the
 no-signal message on external monitors way before Ben???s patch landed,
 but only for some adapters. I haven???t tried Ben???s patch yet, nor
 yours, but I will certainly do it, and see what effect each of them has.
>>>
>>> The external DP port on your MBP5,3 is switchable between GPUs and
>>> the apple-gmux driver switches it in unison with the panel.  Thus
>>> the NVAC cannot drive external displays when gmux is switched to
>>> the MCP79.  (You probably were aware of this, just wanted to mention
>>   ^
>> I meant G96, sorry I mixed it up.
>>
>> Lukas
> 
> Yes, that bit had stayed in my memory, that switching between the two GPUs
> would not only switch them for the laptop screen, but for the external ones as
> well. IIRC, I am getting the no signal in both cases, but I need to retest.
> 
> Pierre

Any news related on your side?



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

Re: [Nouveau] NVAC "No Signal"

[poma]

On 06.11.2016 18:02, poma wrote:
> 
> http://goo.gl/Gm4ffO
> mmiotrace-nouveau/
> 

$ uname -r
4.9.0-0.rc4.git0.1.fc26.x86_64+debug

$ dmesg -t | grep -P '(?=.*nouveau)(?=.*MMIO)'
nouveau :01:00.0: bus: MMIO write of 8015 FAULT at 61a804
nouveau :01:00.0: bus: MMIO read of 0010 FAULT at 64
nouveau :01:00.0: bus: MMIO read of 0007 FAULT at 61a804
nouveau :01:00.0: bus: MMIO write of 8015 FAULT at 61a804
nouveau :01:00.0: bus: MMIO read of 07ff FAULT at 61a804
nouveau :01:00.0: bus: MMIO write of 00100180 FAULT at 61a80c
nouveau :01:00.0: bus: MMIO read of 8055 FAULT at 61a804
nouveau :01:00.0: bus: MMIO read of 0007 FAULT at 61a804
nouveau :01:00.0: bus: MMIO write of 8015 FAULT at 61a804
nouveau :01:00.0: bus: MMIO read of 0001 FAULT at 61a804
nouveau :01:00.0: bus: MMIO write of 00100180 FAULT at 61a80c
nouveau :01:00.0: bus: MMIO read of  FAULT at 61a804
nouveau :01:00.0: bus: MMIO write of fb08d1ff FAULT at 61a804
nouveau :01:00.0: bus: MMIO read of 0001 FAULT at 641000
nouveau :01:00.0: bus: MMIO write of 0020 FAULT at 641000
nouveau :01:00.0: bus: MMIO read of 0001 FAULT at 64
nouveau :01:00.0: bus: MMIO read of 0030 FAULT at 64
nouveau :01:00.0: bus: MMIO write of 0014 FAULT at 64
nouveau :01:00.0: bus: MMIO write of 006c FAULT at 641000
nouveau :01:00.0: bus: MMIO read of 0007 FAULT at 64
nouveau :01:00.0: bus: MMIO write of 0010 FAULT at 64
nouveau :01:00.0: bus: MMIO write of  FAULT at 647080
nouveau :01:00.0: bus: MMIO write of 0008 FAULT at 64
nouveau :01:00.0: bus: MMIO read of  FAULT at 64
nouveau :01:00.0: bus: MMIO read of 0014 FAULT at 64
nouveau :01:00.0: bus: MMIO write of  FAULT at 647080
nouveau :01:00.0: bus: MMIO read of  FAULT at 64
nouveau :01:00.0: bus: MMIO write of  FAULT at 647080
nouveau :01:00.0: bus: MMIO read of  FAULT at 64
nouveau :01:00.0: bus: MMIO read of 0007 FAULT at 64
nouveau :01:00.0: bus: MMIO write of  FAULT at 647080
nouveau :01:00.0: bus: MMIO read of  FAULT at 64
nouveau :01:00.0: bus: MMIO write of  FAULT at 647080
nouveau :01:00.0: bus: MMIO read of  FAULT at 64
nouveau :01:00.0: bus: MMIO read of 0014 FAULT at 64
nouveau :01:00.0: bus: MMIO write of  FAULT at 647080


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

Re: [Nouveau] NVAC "No Signal"

[poma]

http://goo.gl/Gm4ffO
mmiotrace-nouveau/


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

Re: [Nouveau] Atomic modesetting + DisplayPort MST

[poma]

On 04.11.2016 10:41, Ben Skeggs wrote:
> Hey all,
> 
> I've just pushed out the initial Nouveau support for $subject \o/
> 
> As the atomic modesetting transition is basically a rewrite of the KMS
> portion of the driver, I would be very grateful for any additional
> testing that people could provide (even as simple as just booting and
> making sure you get a display is valuable).
[...]
> There's another branch (devel-kms) in the same repository, which is the
> same code on top of what's currently Linux 4.9.  If you have problems
> with the 4.10 code, I'd definitely be interested in seeing if they exist
> on the 4.9 branch too.
> 

Hey Joe,

$ grep nouveau /etc/dracut.conf.d/custom.conf 
omit_drivers+=" nouveau "
# lsinitrd --kver 4.9.0-0.rc3.git2.1.fc26.x86_64 | grep nouveau ; echo $?
1

$ git clone https://github.com/skeggsb/nouveau.git -b devel-kms
$ cd nouveau/drm/
$ git log -1 | head -1
commit 5a4d1791e82dd1eaa1e4ad5a220e82cbcc2f6535
$ sed -i /0xac/s/^/\\/\\// nouveau/nvkm/engine/disp/nv50.c# "No Signal" ION 
VGA
$ make
$ su
# cp nouveau/nouveau.ko /usr/lib/modules/4.9.0-0.rc3.git2.1.fc26.x86_64/updates/
# depmod
# reboot

$ modinfo -n nouveau
/lib/modules/4.9.0-0.rc3.git2.1.fc26.x86_64/updates/nouveau.ko

= G98
$ dmesg | grep nouveau
[   22.111216] nouveau: loading out-of-tree module taints kernel.
[   22.115029] nouveau: module verification failed: signature and/or required 
key missing - tainting kernel
[   22.167576] nouveau :02:00.0: NVIDIA G98 ...
[   22.283146] nouveau :02:00.0: bios: version ...
[   22.314705] nouveau :02:00.0: bios: M0203T not found
[   22.314835] nouveau :02:00.0: bios: M0203E not matched!
[   22.314961] nouveau :02:00.0: fb: 512 MiB DDR2
[   24.767092] nouveau :02:00.0: DRM: VRAM: 512 MiB
[   24.767267] nouveau :02:00.0: DRM: GART: 1048576 MiB
[   24.767423] nouveau :02:00.0: DRM: TMDS table version 2.0
[   24.767570] nouveau :02:00.0: DRM: DCB version 4.0
[   24.767719] nouveau :02:00.0: DRM: DCB outp 00: 02000300 0028
[   24.767869] nouveau :02:00.0: DRM: DCB outp 01: 01000302 00020030
[   24.768019] nouveau :02:00.0: DRM: DCB outp 02: 04011310 0028
[   24.768167] nouveau :02:00.0: DRM: DCB outp 03: 010223f1 00c0c080
[   24.768339] nouveau :02:00.0: DRM: DCB conn 00: 1030
[   24.768487] nouveau :02:00.0: DRM: DCB conn 01: 0100
[   24.768638] nouveau :02:00.0: DRM: DCB conn 02: 0210
[   24.768784] nouveau :02:00.0: DRM: DCB conn 03: 0211
[   24.768932] nouveau :02:00.0: DRM: DCB conn 04: 0213
[   24.776629] nouveau :02:00.0: DRM: failed to create encoder 0/1/0: -19
[   24.776760] nouveau :02:00.0: DRM: TV-1 has no encoders, removing
[   24.791752] nouveau :02:00.0: DRM: MM: using M2MF for buffer copies
[   24.858594] nouveau :02:00.0: DRM: allocated 1920x1080 fb: 0x5, bo 
9013e3162000
[   24.859949] fbcon: nouveaufb (fb0) is primary device
[   24.908898] nouveau :02:00.0: fb0: nouveaufb frame buffer device
[   24.921432] [drm] Initialized nouveau 1.3.1 20120801 for :02:00.0 on 
minor 0
[   61.198374] nouveau :02:00.0: Direct firmware load for 
nouveau/nv98_fuc084 failed with error -2
[   61.198563] nouveau :02:00.0: Direct firmware load for 
nouveau/nv98_fuc084d failed with error -2
[   61.198580] nouveau :02:00.0: msvld: unable to load firmware data
[   61.198588] nouveau :02:00.0: msvld: init failed, -19
[   76.197433] nouveau :02:00.0: Direct firmware load for 
nouveau/nv98_fuc084 failed with error -2
[   76.197468] nouveau :02:00.0: Direct firmware load for 
nouveau/nv98_fuc084d failed with error -2
[   76.197473] nouveau :02:00.0: msvld: unable to load firmware data
[   76.197475] nouveau :02:00.0: msvld: init failed, -19
   S3 / S4 / RESUME
[  194.532401] nouveau :02:00.0: DRM: suspending console...
[  194.532638] nouveau :02:00.0: DRM: suspending display...
[  194.559166] nouveau :02:00.0: DRM: evicting buffers...
[  195.716205] nouveau :02:00.0: DRM: waiting for kernel channels to go 
idle...
[  195.716328] nouveau :02:00.0: DRM: suspending client object trees...
[  195.717089] nouveau :02:00.0: DRM: suspending kernel object tree...
[  197.464225] nouveau :02:00.0: DRM: resuming kernel object tree...
[  197.579099] nouveau :02:00.0: DRM: resuming client object trees...
[  197.579429] nouveau :02:00.0: DRM: resuming display...
[  197.605069] nouveau :02:00.0: DRM: resuming console...


= ION VGA
$ dmesg | grep nouveau
[   39.239672] nouveau: loading out-of-tree module taints kernel.
[   39.249832] nouveau: module verification failed: signature and/or required 
key missing - tainting kernel
[   39.392859] nouveau :01:00.0: NVIDIA MCP79/MCP7A ...
[   39.417499] nouveau :01:00.0: bios: version ...
[   39.448535] nouveau :01:00.0: fb: 256 MiB stolen system memory
[   39.509648] nouveau :01:00.0: DRM: VRAM: 256 MiB
[   39.514208] nouveau 

Re: [Nouveau] MediaWriter & Nouveau

[poma]

[...]

= "basic" render

$ QSG_INFO=1 mediawriter 
Debug: QSG: basic render loop ((null):0, (null))
Debug: texture atlas dimensions: 1024x512 ((null):0, (null))
Debug: R/G/B/A Buffers:8 8 8 0 ((null):0, (null))
Debug: Depth Buffer:   24 ((null):0, (null))
Debug: Stencil Buffer: 8 ((null):0, (null))
Debug: Samples:-1 ((null):0, (null))
Debug: GL_VENDOR:  nouveau ((null):0, (null))
Debug: GL_RENDERER:Gallium 0.4 on NV98 ((null):0, (null))
Debug: GL_VERSION: 3.0 Mesa 13.0.0-rc2 ((null):0, (null))
Debug: GL_EXTENSIONS:  ...
Debug: Max Texture Size:  8192 ((null):0, (null))
Debug: Debug context: false ((null):0, (null))
...

$ ps -C mediawriter -o cmd,%cpu
CMD %CPU
mediawriter 30.1



= "windows" render

$ QSG_INFO=1 QSG_RENDER_LOOP=windows mediawriter
Debug: windows render loop ((null):0, (null))
Debug: Using sg animation driver ((null):0, (null))
Debug: Animation Driver: using vsync: 16.67 ms ((null):0, (null))
Debug: texture atlas dimensions: 1024x512 ((null):0, (null))
Debug: R/G/B/A Buffers:8 8 8 0 ((null):0, (null))
Debug: Depth Buffer:   24 ((null):0, (null))
Debug: Stencil Buffer: 8 ((null):0, (null))
Debug: Samples:-1 ((null):0, (null))
Debug: GL_VENDOR:  nouveau ((null):0, (null))
Debug: GL_RENDERER:Gallium 0.4 on NV98 ((null):0, (null))
Debug: GL_VERSION: 3.0 Mesa 13.0.0-rc2 ((null):0, (null))
Debug: GL_EXTENSIONS:  ...
Debug: Max Texture Size:  8192 ((null):0, (null))
Debug: Debug context: false ((null):0, (null))
...

$ ps -C mediawriter -o cmd,%cpu
CMD %CPU
mediawriter 41.2



= "threaded" render

$ QSG_INFO=1 QSG_RENDER_LOOP=threaded mediawriter
Debug: threaded render loop ((null):0, (null))
Debug: Using sg animation driver ((null):0, (null))
Debug: Animation Driver: using vsync: 16.67 ms ((null):0, (null))
Debug: Animation Driver: using vsync: 16.67 ms ((null):0, (null))
Debug: texture atlas dimensions: 1024x512 ((null):0, (null))
Debug: R/G/B/A Buffers:8 8 8 0 ((null):0, (null))
Debug: Depth Buffer:   24 ((null):0, (null))
Debug: Stencil Buffer: 8 ((null):0, (null))
Debug: Samples:-1 ((null):0, (null))
Debug: GL_VENDOR:  nouveau ((null):0, (null))
Debug: GL_RENDERER:Gallium 0.4 on NV98 ((null):0, (null))
Debug: GL_VERSION: 3.0 Mesa 13.0.0-rc2 ((null):0, (null))
Debug: GL_EXTENSIONS:  ...
Debug: Max Texture Size:  8192 ((null):0, (null))
Debug: Debug context: false ((null):0, (null))
...

$ ps -C mediawriter -o cmd,%cpu
CMD %CPU
mediawriter 18.3

...
Debug: animation driver switched to timer mode ((null):0, (null))
Debug: animation driver switched to vsync mode ((null):0, (null))
Debug: Animation Driver: using vsync: 16.67 ms ((null):0, (null))
Debug: texture atlas dimensions: 1024x512 ((null):0, (null))
Segmentation fault (core dumped)

QSGRenderThread[8636]: segfault at 8 ip 7f9138a4320f sp 7f911cd908f0 
error 4 in libdrm_nouveau.so.2.0.0[7f9138a3f000+7000]



= About

$ rpm -q mediawriter 
mediawriter-4.0.3-2.fc26.x86_64

built without "threaded" render:
$ grep sed mediawriter.spec -A2
sed -i /threaded/s/^/\\/\\// app/main.cpp

%build

$ rpm -q qt5-qtbase-devel qt5-qtdeclarative-devel
qt5-qtbase-devel-5.7.0-9.fc26.x86_64
qt5-qtdeclarative-devel-5.7.0-2.fc25.x86_64



= Conclusion
From the nouveau perspective, "threaded" render is "out of scope".


Ref.
Force threaded run loop for QML - Fixes high CPU load
https://github.com/MartinBriza/MediaWriter/commit/63492f4

Qt Quick Scene Graph - Scene Graph and Rendering
https://doc.qt.io/qt-5/qtquick-visualcanvas-scenegraph.html#scene-graph-and-rendering


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

[Nouveau] MediaWriter & Nouveau

[poma]

Pan Bříza,
to se stane, když
Custom image - Pick a file from your drives(s)
...
nouveau :02:00.0: fifo: DMA_PUSHER - ch 5 [mediawriter[20975]] get 
0020171c34 put 00201746ec ib_get 0017 ib_put 0018 state 8000a32c (err: 
INVALID_CMD) push 00406040
nouveau :02:00.0: gr: DATA_ERROR 0004 [INVALID_VALUE]
nouveau :02:00.0: gr: 0010 [] ch 5 [001f7bd000 mediawriter[20975]] subc 
5 class 5039 mthd 0320 data 00046da8
nouveau :02:00.0: gr: DATA_ERROR 0005 [INVALID_ENUM]
nouveau :02:00.0: gr: 0010 [] ch 5 [001f7bd000 mediawriter[20975]] subc 
5 class 5039 mthd 0324 data 
nouveau :02:00.0: gr: DATA_ERROR 0005 [INVALID_ENUM]
nouveau :02:00.0: gr: 0010 [] ch 5 [001f7bd000 mediawriter[20975]] subc 
5 class 5039 mthd 0328 data 00046da4
nouveau :02:00.0: fifo: DMA_PUSHER - ch 5 [mediawriter[20975]] get 
0020175a18 put 002018ae6c ib_get 001a ib_put 001b state 80008208 (err: 
INVALID_CMD) push 00406040
nouveau :02:00.0: gr: DATA_ERROR 000c [INVALID_BITFIELD]
nouveau :02:00.0: gr: 0010 [] ch 5 [001f7bd000 mediawriter[20975]] subc 
4 class 502d mthd 0200 data 00086e04
nouveau :02:00.0: gr: DATA_ERROR 000c [INVALID_BITFIELD]
nouveau :02:00.0: gr: 0010 [] ch 5 [001f7bd000 mediawriter[20975]] subc 
4 class 502d mthd 0204 data 02cb02c6
nouveau :02:00.0: fifo: DMA_PUSHER - ch 5 [mediawriter[20975]] get 
002019d8b8 put 00201acb08 ib_get 0023 ib_put 0026 state 4004 (err: 
INVALID_MTHD) push 00406040
nouveau :02:00.0: fifo: CACHE_ERROR - ch 5 [mediawriter[20975]] subc 0 mthd 
 data 0390
nouveau :02:00.0: gr: DATA_ERROR 000d [BEGIN_END_ACTIVE]
nouveau :02:00.0: gr: 0010 [] ch 5 [001f7bd000 mediawriter[20975]] subc 
3 class 8297 mthd 131c data 3f5ededf
nouveau :02:00.0: gr: DATA_ERROR 000d [BEGIN_END_ACTIVE]
nouveau :02:00.0: gr: 0010 [] ch 5 [001f7bd000 mediawriter[20975]] subc 
3 class 8297 mthd 1320 data 3f5ededf
nouveau :02:00.0: gr: DATA_ERROR 000d [BEGIN_END_ACTIVE]
nouveau :02:00.0: gr: 0010 [] ch 5 [001f7bd000 mediawriter[20975]] subc 
3 class 8297 mthd 1324 data 3f5ededf
nouveau :02:00.0: gr: DATA_ERROR 000d [BEGIN_END_ACTIVE]
nouveau :02:00.0: gr: 0010 [] ch 5 [001f7bd000 mediawriter[20975]] subc 
3 class 8297 mthd 1328 data 3f80
nouveau :02:00.0: fifo: DMA_PUSHER - ch 5 [mediawriter[20975]] get 
00203c4e34 put 00203d04b0 ib_get 003b ib_put 003c state 8024 (err: 
INVALID_CMD) push 00406040
nouveau :02:00.0: mediawriter[20975]: push 0 buffer not in list
show_signal_msg: 21 callbacks suppressed
QSGRenderThread[21104]: segfault at 774b0 ip 7f10f99d5494 sp 
7f10f1989ee0 error 4 in libdrm_nouveau.so.2.0.0[7f10f99d2000+7000]

$ rpm -q mediawriter
mediawriter-4.0.0-2.fc24.x86_64


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

Re: [Nouveau] NVAC "No Signal"

[poma]

On 19.10.2016 17:03, Karol Herbst wrote:

> You don't get why I try to say. We have to actually find out when to
> apply this workaround, not to create some silly whitelist/blacklist.
> It's the last option, we never want to actually use.
> 

Well if you do not say, who can understand!? :)
Besides, you can mock with "silly" whitelist/blacklist", however there is 
nothing wrong with the method as such, it is used practically everywhere.

> And even if we would have to create such lists, who tells us, that if
> affects every GPU with your device id? Usually quirks are applied
> depending on the sub-vendor-id and sub-device-id if actually required.
> 
> In the end we need something like this: If byte X in table Y is set in
> the vbios or if bits A-B in reg Z in the MMIO space are set to
> whatever, we have to apply that workaround.
> 
> In the end we should also wait until Ben replies, because he might
> know the exact reasons why this workaround was actually needed.
> 

If you eager to leave it broken even more than three months that have already 
been passed since the original commit ...

> We might have a GPU with the same chipset like yours and we might be
> able to verify the issue
> 

Ah, I see.
You do not have confidence in my test results, good to know.

Oh! Carol


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

Re: [Nouveau] NVAC "No Signal"

[poma]

On 18.10.2016 16:02, Karol Herbst wrote:
> well, I just don't want that this fix breaks the same thing for other
> users, that's why I am asking.
> 

Affected device ID:
https://github.com/skeggsb/nouveau/blob/master/drm/nouveau/nvkm/engine/device/pci.c#L1229
can it be excluded from device->chipset case 0xac ?

Care to create a patch?
I'll test it.


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

Re: [Nouveau] NVAC "No Signal"

[poma]

On 18.10.2016 09:35, Karol Herbst wrote:
> how sure are you, that this is needed for _every_ nvac?
> 

Thank you for asking.

If you consider, as relevant,
referring to the original commit:
"drm/nouveau/disp/g94: implement workaround for dvi issue on fx380"
https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=2a4bd8a

Fixes the second DVI output on Quadro FX380.
Thanks to NVIDIA for providing the details on the full workaround. 

[...]
+   switch (device->chipset) {
+   case 0x94:
+   case 0x96:
+   case 0x98:
+   case 0xaa:
+   case 0xac:
+   return true;
[...]


and to Quadro FX380 as defined:

1. https://nouveau.freedesktop.org/wiki/CodeNames/#NV50
   NV96 (G96) ...

2. https://en.wikipedia.org/wiki/Nvidia_Quadro
   G96 ... GeForce 9400 based

3. 
https://en.wikipedia.org/wiki/List_of_Nvidia_graphics_processing_units#Quadro_FX_.28x800.29_series
   G96 ...


The right question would be,
for you Karol, Ben and perhaps the ones from the NVIDIA - those to which Ben 
refers,

whether device->chipset:
+   case 0x94:
+   case 0x98:
+   case 0xaa:
+   case 0xac:
are redundant, in the first place?

Moreover, even if case 0x96 applies only,
how sure are -you-, that this is needed for _every_ nv96?

And given that I am here only the user, who is only caring for my hardware,
I can only appreciate your sense of humor. ;)



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

[Nouveau] NVAC "No Signal"

[poma]

Fixes "No Signal" via HDMI from NVIDIA Corporation ION VGA (rev b1)

Ref.
"drm/nouveau/disp/g94: implement workaround for dvi issue on fx380"
https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=2a4bd8a

The last working Fedora kernel 4.8.0-0.rc0.git3.1.fc25

Patched and tested with:
$ modinfo -n nouveau
/lib/modules/4.8.2-300.fc25.x86_64/updates/nouveau.ko

Tested-by: poma <p...@gmail.com>
---
 drivers/gpu/drm/nouveau/nvkm/engine/disp/nv50.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/nouveau/nvkm/engine/disp/nv50.c 
b/drivers/gpu/drm/nouveau/nvkm/engine/disp/nv50.c
index fbb8c7d..c9e40e7 100644
--- a/drivers/gpu/drm/nouveau/nvkm/engine/disp/nv50.c
+++ b/drivers/gpu/drm/nouveau/nvkm/engine/disp/nv50.c
@@ -434,7 +434,8 @@ nv50_disp_dptmds_war(struct nvkm_device *device)
case 0x96:
case 0x98:
case 0xaa:
-   case 0xac:
+/* NVIDIA MCP79/MCP7A "No Signal" */
+/* case 0xac:*/
return true;
default:
break;
-- 
2.7.4
___
Nouveau mailing list
Nouveau@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/nouveau

Re: [Nouveau] [Mesa-dev] nouveau_drv_video.so ?

[poma]

On 30.06.2016 13:11, Emil Velikov wrote:
> Hi poma,
> 
> Seems like you're missed your question. "nouveau_drv_video.so ?" does
> not mean much I'm afraid :-(
> 
> On 30 June 2016 at 11:03, poma <pomidorabelis...@gmail.com> wrote:
>> On 30.06.2016 08:27, Xiang, Haihao wrote:
>>>
>>>
>>> Are you using VA-API on X11? libva gets the driver name from Xserver,
>>> it is nouveau for you. so libva tries to load nouveau_drv_video.so.
>>> You can create a symlink for nouveau pointing to a available driver or
>>> just ignore the message because you have gallium_drv_video.so now.
>>>
> Indeed. The tricky part is that libva honours the gallium_drv_video.so
> name only in some corner cases :-(
> 
>>> Thanks
>>> Haihao
>>>
>>
>>
>> In practice, regarding video acceleration, nouveau has proven to be fragile,
>> no matter what and how to config
>>
>> $ file /usr/lib64/dri/nouveau_drv_video.so
>> /usr/lib64/dri/nouveau_drv_video.so: cannot open 
>> `/usr/lib64/dri/nouveau_drv_video.so' (No such file or directory)
>>
>> $ ll /usr/lib64/dri/nouveau_drv_video.so
>> ls: cannot access '/usr/lib64/dri/nouveau_drv_video.so': No such file or 
>> directory
>>
> This should no longer be the case with mesa 12.0, where appropriately
> named files/links are created.
> 
> 
>> # ln -s vdpau_drv_video.so nouveau_drv_video.so
>>
>> $ ll /usr/lib64/dri/nouveau_drv_video.so
>> ... /usr/lib64/dri/nouveau_drv_video.so -> vdpau_drv_video.so
>>
>> $ file /usr/lib64/dri/nouveau_drv_video.so
>> /usr/lib64/dri/nouveau_drv_video.so: symbolic link to vdpau_drv_video.so
>>
> If you do this you're up-to the mercy of the vdpau_drv_video (wrapper)
> driver, which seems abandoned for the past 4 years.
> 
> 
>> # ln -fs gallium_drv_video.so nouveau_drv_video.so
>>
>> $ ll /usr/lib64/dri/nouveau_drv_video.so
>> ... /usr/lib64/dri/nouveau_drv_video.so -> gallium_drv_video.so
>>
>> $ file /usr/lib64/dri/nouveau_drv_video.so
>> /usr/lib64/dri/nouveau_drv_video.so: symbolic link to gallium_drv_video.so
>>
> As said above, this should no longer be needed.
> 
> 
>>
>> $ icecat
>> ...
>> libva info: VA-API version 0.39.2
>> libva info: va_getDriverName() returns 0
>> libva info: Trying to open /usr/lib64/dri/nouveau_drv_video.so
>> libva info: Found init function __vaDriverInit_0_39
>> libva info: va_openDriver() returns 0
>> icecat: pushbuf.c:727: nouveau_pushbuf_data: Assertion `kref' failed.
>> Aborted (core dumped)
>>
>> https://bugzilla.redhat.com/attachment.cgi?id=1174453
>>
> From a quick guess - MT and/or GL VAAPI interop related ? If so, these
> two [1] patches could help.
> 
> -Emil
> 
> [1]
> https://github.com/imirkin/mesa/commit/be089dd63c6102df48de06bb7184ca1202f1e0f5
> https://github.com/imirkin/mesa/commit/5e8e523514e73afa48916e094583f4ca83f05175
> 


Thanks for the explanation


$ rpm -qf /usr/lib64/dri/nouveau_drv_video.so
mesa-dri-drivers-12.0.0-0.5.rc4.fc24.x86_64
incl.:
0001-WIP-nouveau-add-locking.patch
0002-nouveau-more-locking-make-sure-that-fence-work-is-al.patch


$ rpm -qf /usr/lib64/dri/vdpau_drv_video.so 
libva-vdpau-driver-0.7.4-14.fc24.x86_64

# rpm -evh libva-vdpau-driver
Preparing...  # [100%]
Cleaning up / removing...
   1:libva-vdpau-driver-0.7.4-14.fc24 # [100%]


icecat-38.8.0 with
https://github.com/lejenome/html5-video-everywhere
produce kernel oops - it is enough to attempt to change video settings of add-on

icecat-38.8.0 without html5-video-everywhere
still can crush - running native yt player, but system stays OK
although with
nouveau :02:00.0: fifo: CACHE_ERROR - ch 6 [source:src[2854]] subc 0 mthd 
0060 data beef0201

for comparison,
firefox-47.0 with html5-video-everywhere
with the exception of delays a few seconds of the first video frame in full 
screen mode,
and same delay at exit the full screen mode,
works OK - not breaking anything.

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

[Nouveau] nouveau_drv_video.so ?

[poma]

nouveau_drv_video.so - what should it be?


https://koji.fedoraproject.org/koji/buildinfo?buildID=722316
... 0.7.4-13 - Revert symlinks - should be handled by mesa rhbz#1271842
https://bugzilla.redhat.com/show_bug.cgi?id=1271842
... 0.7.4-12 - Add symlinks for radeonsi,r600,nouveau - rhbz#1264499
 https://bugzilla.redhat.com/show_bug.cgi?id=1264499


$ rpm -q libva libva-vdpau-driver mesa-dri-drivers
libva-1.7.1-1.fc24.x86_64
libva-vdpau-driver-0.7.4-14.fc24.x86_64
mesa-dri-drivers-11.2.2-2.20160614.fc24.x86_64

$ rpm -ql libva-vdpau-driver 
/usr/lib64/dri/nvidia_drv_video.so
/usr/lib64/dri/s3g_drv_video.so
/usr/lib64/dri/vdpau_drv_video.so
/usr/share/doc/...
...

$ rpm -ql mesa-dri-drivers
/etc/drirc
/usr/lib64/dri/gallium_drv_video.so
/usr/lib64/dri/i915_dri.so
/usr/lib64/dri/i965_dri.so
/usr/lib64/dri/ilo_dri.so
/usr/lib64/dri/kms_swrast_dri.so
/usr/lib64/dri/nouveau_dri.so
/usr/lib64/dri/nouveau_vieux_dri.so
/usr/lib64/dri/r200_dri.so
/usr/lib64/dri/r300_dri.so
/usr/lib64/dri/r600_dri.so
/usr/lib64/dri/radeon_dri.so
/usr/lib64/dri/radeonsi_dri.so
/usr/lib64/dri/swrast_dri.so
/usr/lib64/dri/virtio_gpu_dri.so
/usr/lib64/dri/vmwgfx_dri.so
/usr/lib64/gallium-pipe
/usr/lib64/gallium-pipe/pipe_i965.so
/usr/lib64/gallium-pipe/pipe_nouveau.so
/usr/lib64/gallium-pipe/pipe_r300.so
/usr/lib64/gallium-pipe/pipe_r600.so
/usr/lib64/gallium-pipe/pipe_radeonsi.so
/usr/lib64/gallium-pipe/pipe_swrast.so
/usr/lib64/gallium-pipe/pipe_vmwgfx.so

$ ll /usr/lib64/dri/
... dummy_drv_video.so
... gallium_drv_video.so
... i915_dri.so
... i965_dri.so
... ilo_dri.so
... kms_swrast_dri.so
... nouveau_dri.so
... nouveau_vieux_dri.so
... nvidia_drv_video.so -> vdpau_drv_video.so
... r200_dri.so
... r300_dri.so
... r600_dri.so
... radeon_dri.so
... radeonsi_dri.so
... s3g_drv_video.so -> vdpau_drv_video.so
... swrast_dri.so
... vdpau_drv_video.so
... virtio_gpu_dri.so
... vmwgfx_dri.so


$ icecat 
...
libva info: VA-API version 0.39.2
libva info: va_getDriverName() returns 0
libva info: Trying to open /usr/lib64/dri/nouveau_drv_video.so
libva info: va_openDriver() returns -1
libva info: VA-API version 0.39.2
libva info: va_getDriverName() returns 0
libva info: Trying to open /usr/lib64/dri/nouveau_drv_video.so
libva info: va_openDriver() returns -1
libva info: VA-API version 0.39.2
libva info: va_getDriverName() returns 0
libva info: Trying to open /usr/lib64/dri/gallium_drv_video.so
libva info: Found init function __vaDriverInit_0_39
libva info: va_openDriver() returns 0


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

Re: [Nouveau] GV98 adapter, experience with nouveau

[poma]

On 01.06.2016 20:44, poma wrote:
> On 01.06.2016 20:20, Yury Tarasievich wrote:
>> Thank you!
>>
>> Now, I'd appreciate some hints on how to make 
>> console work, at least.
>> How are the video modes controlled, e.g., can I 
>> have some analogue of /etc/fb.modes for nouveau?
>>
>> -Yury
>>
> 
> 
> After hand-over:
> "fb: switching to nouveaufb from VESA VGA"
> 
> video device "automatically" switches to the native resolution of the 
> connected display.
> 
> If it does not work:
> https://nouveau.freedesktop.org/wiki/Bugs/
> 
> 

"If you are using packages from your distribution and are unable/unwilling to 
test the latest versions of all the pieces of nouveau, send the bug reports to 
your distribution and not directly to us. If you're using an out-of-date 
software version, our first question will probably be "does it still happen on 
latest"."
Ref.
https://nouveau.freedesktop.org/wiki/Bugs/

This is why I referred to the "try to test with newer software",
e.g. Rawhide LiveCD/DVDs
https://dl.fedoraproject.org/pub/fedora/linux/development/rawhide/Spins/x86_64/iso/

I have tested it with NVIDIA G98 here, and it works as expected.

With this approach - test with the "latest and greatest" - you can create a 
reference point for further comparison - with lower versions of software 
components.


Godspeed

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

Re: [Nouveau] GV98 adapter, experience with nouveau

[poma]

On 01.06.2016 20:20, Yury Tarasievich wrote:
> Thank you!
> 
> Now, I'd appreciate some hints on how to make 
> console work, at least.
> How are the video modes controlled, e.g., can I 
> have some analogue of /etc/fb.modes for nouveau?
> 
> -Yury
> 


After hand-over:
"fb: switching to nouveaufb from VESA VGA"

video device "automatically" switches to the native resolution of the connected 
display.

If it does not work:
https://nouveau.freedesktop.org/wiki/Bugs/


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

Re: [Nouveau] GV98 adapter, experience with nouveau

[poma]

On 01.06.2016 13:48, Yury Tarasievich wrote:
> I'm trying to put to work the nouveau driver on 
> slackware 64 bits current, kernel 4.4.*.
> 
> I've thought the hardware to be some obscure OEM 
> variant of GT610. However, kind soul on IRC 
> pointed out that it's a G98 really, 'GeForce 
> 9300 GS or 8400 GS'.
> 
> Proprietary NVIDIA drivers:
> * 340.96 installs okay, console works, but X 
> doesn't start, with unspecified error occuring 
> when trying to initialise hardware (-19);
> * 304.131 works, with no undue surprises.
> 
> I've experienced a lot of problems with nouveau 
> driver (as packaged for Slackware on Dec 16, 
> 2015; build date in logs: '19 November 2015 
> 12:46:02AM'):
> 
> 1) Console does not initialise the output 
> correctly if video mode is not restricted to 
> 640x480 by kernel command line with '... 
> video=640x480'. Any other (bigger) resolution 
> there, or no restriction, and the screen blanks; 
> also, for either 800x600 or 1024x768 upper 
> limits the monitor outputs the warning about 
> unusable mode, 26.8KHz/43Hz for 800x600, and 
> 21.6KHz/27Hz for 1024x768.
> 
> The input works. I can log in and start X, which 
> starts (!) and works, but produces no output either.
> 
> No such problem with NVIDIA drivers.
> 
> 2) The working mode restriction 640x480 gives 
> the console set to 68Hz vertical refresh (as 
> monitor reports).
> 
> 3) The X started from console (having 640x480 
> restriction) allows only 640x480 mode in config. 
> Any other mode produces working X with blank 
> screen, excepting console started restrictred to 
> 800x600 or 1024x768, which retains the monitor's 
> floating message about 'unusable mode'. Either 
> way, input in X works.
> 
> 4) The X in 640x480 has actual vertical refresh 
> of 68Hz, which xrandr reports as 75Hz. Attempt 
> to change vert. refresh rate to 60Hz produces 
> screen 'stroboscoping'. Any other resolution set 
> via xrandr produces blank screen.
> 
> Any advice? NVIDIA driver files removed, full 
> dmesg and xorg available. Cut of dmesg with 
> nouveau lines is in postscriptum.
> 
> -Yury
> 
> PS [7.137052] nouveau :02:00.0: NVIDIA 
> G98 (298500a2)
> [7.256163] nouveau :02:00.0: bios: 
> version 70.18.36.00.00
> [7.258447] nouveau :02:00.0: disp: conn 
> 02:0261: func 08 lookup failed, -2
> [7.279208] nouveau :02:00.0: bios: 
> M0203T not found
> [7.279327] nouveau :02:00.0: bios: 
> M0203E not matched!
> [7.279442] nouveau :02:00.0: fb: 1024 
> MiB DDR2
> [7.328218] nouveau :02:00.0: DRM: VRAM: 
> 1024 MiB
> [7.328332] nouveau :02:00.0: DRM: GART: 
> 1048576 MiB
> [7.328448] nouveau :02:00.0: DRM: TMDS 
> table version 2.0
> [7.328563] nouveau :02:00.0: DRM: DCB 
> version 4.0
> [7.328677] nouveau :02:00.0: DRM: DCB 
> outp 00: 02000300 0028
> [7.328793] nouveau :02:00.0: DRM: DCB 
> outp 01: 01000302 00020030
> [7.328908] nouveau :02:00.0: DRM: DCB 
> outp 02: 04011310 0028
> [7.329035] nouveau :02:00.0: DRM: DCB 
> outp 03: 02022322 00c20090
> [7.329150] nouveau :02:00.0: DRM: DCB 
> conn 00: 1030
> [7.329264] nouveau :02:00.0: DRM: DCB 
> conn 01: 0100
> [7.329378] nouveau :02:00.0: DRM: DCB 
> conn 02: 2261
> [7.339193] nouveau :02:00.0: DRM: MM: 
> using M2MF for buffer copies
> [7.408036] nouveau :02:00.0: DRM: 
> allocated 640x480 fb: 0x5, bo 8800bf77c000
> [7.408442] fbcon: nouveaufb (fb0) is primary 
> device
> [7.410533] nouveau :02:00.0: devinit: 
> unable to compute acceptable pll values
> [7.410535] nouveau :02:00.0: devinit: 
> failed pll calculation
> [7.470351] nouveau :02:00.0: fb0: 
> nouveaufb frame buffer device
> [7.477047] [drm] Initialized nouveau 1.3.1 
> 20120801 for :02:00.0 on minor 0
> 


You can display basic video device info via:
$ lspci -knn -d ::0300

Compare output with the
https://nouveau.freedesktop.org/wiki/CodeNames/

Also you can try to test with newer software,
e.g.
https://dl.fedoraproject.org/pub/fedora/linux/development/rawhide/Spins/x86_64/iso/
Fedora-KDE-Live-x86_64-Rawhide-20160601.n.0.iso

If the machine reaches Desktop in the first place,
put SELinux in permissive mode:
$ su -c "setenforce 0"

otherwise config changes will not apply

re-log ...

Test various Compositor Settings:
$ kcmshell5 kwincompositing

Observe config file:
$ cat ~/.config/kwinrc

Check OpenGL info:
$ kcmshell5 opengl

Check X-Server info
$ kcmshell5 xserver

Start Terminal emulator to exec commands:
ALT+F2: konsole


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

Re: [Nouveau] [PATCH v5 00/13] PRIME Synchronization

[poma]

On 29.04.2016 07:41, Dave Airlie wrote:
> On 13 April 2016 at 14:17, Alex Goins  wrote:
>> Hello all,
>>
>> These patches change the xserver to support setting up PRIME with double
>> buffering, and implement double buffered PRIME sink and source support in
>> the modesetting driver. In addition to these changes, I've upstreamed a
>> couple of patches to the i915 DRM driver that mesh with these, and have
>> implemented double buffered PRIME source support in the NVIDIA proprietary
>> driver (pending release.)
>>
>> Previous cover letters:
>> v4: https://lists.x.org/archives/xorg-devel/2016-March/048944.html
>> v3: http://lists.x.org/archives/xorg-devel/2016-February/048677.html
>> v2: http://lists.x.org/archives/xorg-devel/2016-January/048434.html
>> v1: http://lists.x.org/archives/xorg-devel/2015-November/048039.html
>>
>> I wasn't able to get any of my questions answered in the last thread, so I
>> addressed the issues how I saw fit. Aside from some small tweaks, the biggest
>> changes in this patch set involve resolving the ambiguity with
>> rrSetScanoutPixmap(). Instead of using multiple calls to 
>> rrSetScanoutPixmap() to
>> setup scanout pixmaps for flipping, the scanout pixmap setting is done
>> implicitly in rrEnableSharedPixmapFlipping().
>>
>> There are two new patches that fix outstanding bugs with
>> drmmode_set_scanout_pixmap(), with details in their respective commit 
>> messages:
>> modesetting: Internal storage of scanout pixmaps
>> modesetting: Always tear down scanout pixmap
>>
>> Getting RRReplaceScanoutPixmap() working with synchronization would require 
>> an
>> ABI change to pass in two pixmaps instead of one, so I just made it fail
>> gracefully in the synchronized case. None of the drivers that I implemented
>> PRIME synchronization for seem to use RRReplaceScanoutPixmap(). In fact, I
>> believe it is currently broken with the modesetting driver without the above 
>> 2
>> patches.
> 
> Okay I've finally gotten around to playing with these today. I'm using
> a i915 + nouveau
> system with nouveau running as the master. Both using modesetting DDX.
> 
> The basics seem to work okay, but I am seeing some issues I'm not 100% sure
> are the fault of these patches.
> 
> Scenario 1:
> start X, start mutter against X (using DRI3), start gnome-terminal,
> drag g-t around
> seems smooth.
> set provider output, xrandr in a new display, drag g-t around, I get
> choppy rendering
> on the main display, the offloaded display is smooth!
> 
> I don't think this happens with DRI2 mutter, so I'm not 100% sure what
> is going on there,
> I assume it's something to do with page flipping not being allowed for
> present anymore.
> 
> Scenario 2:
> start X, set provider output, xrandr in a new display, start mutter in
> DRI3 mode, things
> go horribly wrong. Again it seems fine in DRI2 mode. so I expect this
> is some interaction
> with the present extension fighting this.
> 
> I'm going to try and look at the interfaces a bit more now that I have
> it running on a machine.
> 
> Dave.
> 


Generally speaking nouveau/DRI3 -is- half-broken,
talk to Skeggs and try to solve it once and for all.


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

Re: [Nouveau] VDPAU DEINTERLACE

[poma]

On 09.05.2016 20:45, Ilia Mirkin wrote:
> You can try playing with pstate in /sys/kernel/debug/dri/0/pstate
> 

# cat /sys/kernel/debug/dri/0/pstate
0f: core 567 MHz shader 1400 MHz memory 400 MHz
AC: core 566 MHz shader 1400 MHz memory 399 MHz

±1 MHz :)

> On Mon, May 9, 2016 at 2:42 PM, poma <pomidorabelis...@gmail.com> wrote:
>> On 09.05.2016 19:37, Ilia Mirkin wrote:
>>> Mesa only supports the non-spatial temporal deinterlace (deint=3). I'm
>>> guessing that due to some unfortunate issues, you're no longer getting
>>> hw accelerated video decoding. Check in vdpauinfo to make sure that
>>> it's indeed showing the relevant codec as supported. If not, you can
>>> turn that back on by updating to mesa 11.2.2, or downgrading your
>>> kernel to 4.2 or earlier. (The issue only affects G98 and MCP77/MCP79
>>> IGPs.)
>>>
>>
>> With the -Mplayer- vdpau decoding works, at least with the -progressive- 
>> scan type,
>> -interlaced- scan type (DVBT-576i/1080i) is questionable,
>> especially when runs within vlc or xine, even without vdpau deinterlacer,
>> Xorg crash dump, satisfaction guarantee.
>>
>>
>> $ vdpauinfo
>> display: :0.0   screen: 0
>> API version: 1
>> Information string: G3DVL VDPAU Driver Shared Library version 1.0
>> ...
>>
>> Decoder capabilities:
>>
>> namelevel macbs width height
>> 
>> MPEG1   0 16384  2048  2048
>> MPEG2_SIMPLE3 16384  2048  2048
>> MPEG2_MAIN  3 16384  2048  2048
>> H264_BASELINE  41 16384  2048  2048
>> H264_MAIN  41 16384  2048  2048
>> H264_HIGH  41 16384  2048  2048
>> VC1_SIMPLE  1 16384  2048  2048
>> VC1_MAIN2 16384  2048  2048
>> VC1_ADVANCED4 16384  2048  2048
>> MPEG4_PART2_SP --- not supported ---
>> ...
>>
>> Video mixer:
>>
>> feature namesup
>> 
>> DEINTERLACE_TEMPORAL y
>> DEINTERLACE_TEMPORAL_SPATIAL -
>> INVERSE_TELECINE -
>> NOISE_REDUCTION  y
>> SHARPNESSy
>> LUMA_KEY -
>> ...
>>
>>> If you are, in fact, getting hw video decoding acceleration, then it
>>> could be that your GPU is clocked too low. You could attempt
>>> reclocking to a higher pstate and seeing what happens.
>>>
>>
>> # nvclock --speeds
>> ...
>> Memory clock: 399.600 MHz
>> GPU clock: 612.000 MHz
>>
>> # nvclock --info
>> ...
>> Performance level 0: gpu 567MHz/shader 1400MHz/memory 400MHz/100%
>>
>> $ dmesg -t | grep pstate
>> ...
>> Kernel command line: ... nouveau.pstate=1 ...
>> nouveau: unknown parameter 'pstate' ignored
>> -4.5.2-
>>
>> Is there a room for reinforcement, or
>> NVIDIA G98 DEINTERLACER: ability without capability, i.e. underpowered GPU?
>>
>>>
>>> On Thu, May 5, 2016 at 1:12 AM, poma <pomidorabelis...@gmail.com> wrote:
>>>>
>>>> NVIDIA G98
>>>> mesa-dri-drivers-11.2.1-2.20160501.fc22.x86_64
>>>> (incl. mesa commit 38fcf7c)
>>>>
>>>>
>>>> vdpauinfo | grep -i deint
>>>> DEINTERLACE_TEMPORAL y
>>>> DEINTERLACE_TEMPORAL_SPATIAL -
>>>>
>>>>
>>>> https://cgit.freedesktop.org/vdpau/libvdpau/tree/include/vdpau/vdpau.h#n3420
>>>> #define VDP_VIDEO_MIXER_FEATURE_DEINTERLACE_TEMPORAL 
>>>> ((VdpVideoMixerFeature)0)
>>>> /**
>>>>  * \hideinitializer
>>>>  * \brief A VdpVideoMixerFeature.
>>>>  *
>>>>  * When requested and enabled, this enables a more advanced
>>>>  * version of temporal de-interlacing, that additionally uses
>>>>  * edge-guided spatial interpolation.
>>>>  *
>>>>  * When multiple de-interlacing options are requested and
>>>>  * enabled, the back-end implementation chooses the best
>>>>  * algorithm to apply.
>>>>  */
>>>> #define VDP_VIDEO_MIXER_FEATURE_DEINTERLACE_TEMPORAL_SPATIAL 
>>>> ((VdpVideoMixerFeature)1)
>>>> /**
>>>>  * \hideinitializer
>>>>  * \brief A VdpVideoMixerFeature.
>>>>  *
>>>>  * When requested a

Re: [Nouveau] VDPAU DEINTERLACE

[poma]

On 09.05.2016 19:37, Ilia Mirkin wrote:
> Mesa only supports the non-spatial temporal deinterlace (deint=3). I'm
> guessing that due to some unfortunate issues, you're no longer getting
> hw accelerated video decoding. Check in vdpauinfo to make sure that
> it's indeed showing the relevant codec as supported. If not, you can
> turn that back on by updating to mesa 11.2.2, or downgrading your
> kernel to 4.2 or earlier. (The issue only affects G98 and MCP77/MCP79
> IGPs.)
> 

With the -Mplayer- vdpau decoding works, at least with the -progressive- scan 
type,
-interlaced- scan type (DVBT-576i/1080i) is questionable,
especially when runs within vlc or xine, even without vdpau deinterlacer,
Xorg crash dump, satisfaction guarantee.


$ vdpauinfo 
display: :0.0   screen: 0
API version: 1
Information string: G3DVL VDPAU Driver Shared Library version 1.0
...

Decoder capabilities:

namelevel macbs width height

MPEG1   0 16384  2048  2048
MPEG2_SIMPLE3 16384  2048  2048
MPEG2_MAIN  3 16384  2048  2048
H264_BASELINE  41 16384  2048  2048
H264_MAIN  41 16384  2048  2048
H264_HIGH  41 16384  2048  2048
VC1_SIMPLE  1 16384  2048  2048
VC1_MAIN2 16384  2048  2048
VC1_ADVANCED4 16384  2048  2048
MPEG4_PART2_SP --- not supported ---
...

Video mixer:

feature namesup

DEINTERLACE_TEMPORAL y
DEINTERLACE_TEMPORAL_SPATIAL -
INVERSE_TELECINE -
NOISE_REDUCTION  y
SHARPNESSy
LUMA_KEY -
...

> If you are, in fact, getting hw video decoding acceleration, then it
> could be that your GPU is clocked too low. You could attempt
> reclocking to a higher pstate and seeing what happens.
> 

# nvclock --speeds
...
Memory clock: 399.600 MHz
GPU clock: 612.000 MHz

# nvclock --info
...
Performance level 0: gpu 567MHz/shader 1400MHz/memory 400MHz/100%

$ dmesg -t | grep pstate
...
Kernel command line: ... nouveau.pstate=1 ...
nouveau: unknown parameter 'pstate' ignored
-4.5.2-

Is there a room for reinforcement, or
NVIDIA G98 DEINTERLACER: ability without capability, i.e. underpowered GPU?

> 
> On Thu, May 5, 2016 at 1:12 AM, poma <pomidorabelis...@gmail.com> wrote:
>>
>> NVIDIA G98
>> mesa-dri-drivers-11.2.1-2.20160501.fc22.x86_64
>> (incl. mesa commit 38fcf7c)
>>
>>
>> vdpauinfo | grep -i deint
>> DEINTERLACE_TEMPORAL y
>> DEINTERLACE_TEMPORAL_SPATIAL -
>>
>>
>> https://cgit.freedesktop.org/vdpau/libvdpau/tree/include/vdpau/vdpau.h#n3420
>> #define VDP_VIDEO_MIXER_FEATURE_DEINTERLACE_TEMPORAL 
>> ((VdpVideoMixerFeature)0)
>> /**
>>  * \hideinitializer
>>  * \brief A VdpVideoMixerFeature.
>>  *
>>  * When requested and enabled, this enables a more advanced
>>  * version of temporal de-interlacing, that additionally uses
>>  * edge-guided spatial interpolation.
>>  *
>>  * When multiple de-interlacing options are requested and
>>  * enabled, the back-end implementation chooses the best
>>  * algorithm to apply.
>>  */
>> #define VDP_VIDEO_MIXER_FEATURE_DEINTERLACE_TEMPORAL_SPATIAL 
>> ((VdpVideoMixerFeature)1)
>> /**
>>  * \hideinitializer
>>  * \brief A VdpVideoMixerFeature.
>>  *
>>  * When requested and enabled, cadence detection will be enabled
>>  * on interlaced content and the video mixer will try to extract
>>  * progressive frames from pull-down material.
>>  */
>>
>>
>> https://cgit.freedesktop.org/vdpau/libvdpau/tree/include/vdpau/vdpau.h#n606
>>  * \subsection deint_adv Advanced De-interlacing
>>  *
>>  * Operation of both temporal and temporal-spatial de-interlacing is
>>  * identical; the only difference is the internal processing the algorithm
>>  * performs in generating the output frame.
>>  *
>>
>>
>> man 1 mplayer
>> ...
>> vdpau (X11 only)
>> ...
>> deint=<-4-4>
>> ...
>>Select deinterlacing mode (default: -3). Positive  values
>>choose mode and enable deinterlacing. Corresponding nega‐
>>tive values select the same deinterlacing  mode,  but  do
>>not enable deinterlacing on startup (useful in configura‐
>>tion files to specify what mode will be  enabled  by  the
>>"D" key). All modes respect --field-dominance.
>>
>>0  same as -3
>>
>>1  Show only first field, similar

[Nouveau] VDPAU DEINTERLACE

[poma]

NVIDIA G98
mesa-dri-drivers-11.2.1-2.20160501.fc22.x86_64
(incl. mesa commit 38fcf7c)


vdpauinfo | grep -i deint
DEINTERLACE_TEMPORAL y
DEINTERLACE_TEMPORAL_SPATIAL -


https://cgit.freedesktop.org/vdpau/libvdpau/tree/include/vdpau/vdpau.h#n3420
#define VDP_VIDEO_MIXER_FEATURE_DEINTERLACE_TEMPORAL 
((VdpVideoMixerFeature)0)
/**
 * \hideinitializer
 * \brief A VdpVideoMixerFeature.
 *
 * When requested and enabled, this enables a more advanced
 * version of temporal de-interlacing, that additionally uses
 * edge-guided spatial interpolation.
 *
 * When multiple de-interlacing options are requested and
 * enabled, the back-end implementation chooses the best
 * algorithm to apply.
 */
#define VDP_VIDEO_MIXER_FEATURE_DEINTERLACE_TEMPORAL_SPATIAL 
((VdpVideoMixerFeature)1)
/**
 * \hideinitializer
 * \brief A VdpVideoMixerFeature.
 *
 * When requested and enabled, cadence detection will be enabled
 * on interlaced content and the video mixer will try to extract
 * progressive frames from pull-down material.
 */


https://cgit.freedesktop.org/vdpau/libvdpau/tree/include/vdpau/vdpau.h#n606
 * \subsection deint_adv Advanced De-interlacing
 *
 * Operation of both temporal and temporal-spatial de-interlacing is
 * identical; the only difference is the internal processing the algorithm
 * performs in generating the output frame.
 *


man 1 mplayer
...
vdpau (X11 only)
...
deint=<-4-4>
...
   Select deinterlacing mode (default: -3). Positive  values
   choose mode and enable deinterlacing. Corresponding nega‐
   tive values select the same deinterlacing  mode,  but  do
   not enable deinterlacing on startup (useful in configura‐
   tion files to specify what mode will be  enabled  by  the
   "D" key). All modes respect --field-dominance.

   0  same as -3

   1  Show only first field, similar to --vf=field.

   2  Bob deinterlacing, similar to --vf=tfields=1.

   3  motion  adaptive  temporal deinterlacing. May lead
  to A/V desync with slow video hardware and/or high
  resolution.

   4  motion   adaptive   temporal   deinterlacing  with
  edge-guided  spatial  interpolation.  Needs   fast
  video hardware.


Reading all this, am I correctly concluded,
what is supported within NVIDIA G98 HW is DEINTERLACE_TEMPORAL,
which should be engaged with Mplayer's 'vdpau:deint=4' option?

Then again, what DEINTERLACE_TEMPORAL_SPATIAL represents?
As reading the 'vdpauinfo' output it should not be supported.
Is it associated with Mplayer's 'vdpau:deint=3' option,
which in turn works, so to speak?

mplayer -vo vdpau:deint=[34] -vc ffmpeg12vdpau dvb://2@DVBT

Although they achieve solid deinterlacing result,
vdpau:deint=3 and vdpau:deint=4 tend to produce:


 Your system is too SLOW to play this!  


Rest of the deinterlacing modes - 1 and 2, are not so great.


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

[Nouveau] [PATCH] nouveau: Switch perms from macros to octal notations, module params readable to everyone

[poma]

From: poma <pomidorabelis...@gmail.com>

Switch from "silly" S_* macros to "definitely more readable" octal "way" 
permissions,
moreover to not "so restrictive" module parameters permissions.

Suggested-by: Ilia Mirkin <imir...@alum.mit.edu>
Fixes: poma <pomidorabelis...@gmail.com>
Tested-by: poma <pomidorabelis...@gmail.com>
---
 drivers/gpu/drm/nouveau/dispnv04/tvnv17.c   |  2 +-
 drivers/gpu/drm/nouveau/nouveau_chan.c  |  2 +-
 drivers/gpu/drm/nouveau/nouveau_connector.c |  8 +++---
 drivers/gpu/drm/nouveau/nouveau_debugfs.c   |  2 +-
 drivers/gpu/drm/nouveau/nouveau_drm.c   | 10 
 drivers/gpu/drm/nouveau/nouveau_fbcon.c |  2 +-
 drivers/gpu/drm/nouveau/nouveau_hwmon.c | 40 ++---
 7 files changed, 33 insertions(+), 33 deletions(-)

diff --git a/drivers/gpu/drm/nouveau/dispnv04/tvnv17.c 
b/drivers/gpu/drm/nouveau/dispnv04/tvnv17.c
index 163317d..2fa0d09 100644
--- a/drivers/gpu/drm/nouveau/dispnv04/tvnv17.c
+++ b/drivers/gpu/drm/nouveau/dispnv04/tvnv17.c
@@ -40,7 +40,7 @@ MODULE_PARM_DESC(tv_norm, "Default TV norm.\n"
 "\t\tDefault: PAL\n"
 "\t\t*NOTE* Ignored for cards with external TV encoders.");
 static char *nouveau_tv_norm;
-module_param_named(tv_norm, nouveau_tv_norm, charp, 0400);
+module_param_named(tv_norm, nouveau_tv_norm, charp, 0444);
 
 static uint32_t nv42_tv_sample_load(struct drm_encoder *encoder)
 {
diff --git a/drivers/gpu/drm/nouveau/nouveau_chan.c 
b/drivers/gpu/drm/nouveau/nouveau_chan.c
index 879655c..6d2b9d9 100644
--- a/drivers/gpu/drm/nouveau/nouveau_chan.c
+++ b/drivers/gpu/drm/nouveau/nouveau_chan.c
@@ -43,7 +43,7 @@
 
 MODULE_PARM_DESC(vram_pushbuf, "Create DMA push buffers in VRAM");
 int nouveau_vram_pushbuf;
-module_param_named(vram_pushbuf, nouveau_vram_pushbuf, int, 0400);
+module_param_named(vram_pushbuf, nouveau_vram_pushbuf, int, 0444);
 
 int
 nouveau_channel_idle(struct nouveau_channel *chan)
diff --git a/drivers/gpu/drm/nouveau/nouveau_connector.c 
b/drivers/gpu/drm/nouveau/nouveau_connector.c
index ae96ebc..1684d22 100644
--- a/drivers/gpu/drm/nouveau/nouveau_connector.c
+++ b/drivers/gpu/drm/nouveau/nouveau_connector.c
@@ -49,19 +49,19 @@
 
 MODULE_PARM_DESC(tv_disable, "Disable TV-out detection");
 int nouveau_tv_disable = 0;
-module_param_named(tv_disable, nouveau_tv_disable, int, 0400);
+module_param_named(tv_disable, nouveau_tv_disable, int, 0444);
 
 MODULE_PARM_DESC(ignorelid, "Ignore ACPI lid status");
 int nouveau_ignorelid = 0;
-module_param_named(ignorelid, nouveau_ignorelid, int, 0400);
+module_param_named(ignorelid, nouveau_ignorelid, int, 0444);
 
 MODULE_PARM_DESC(duallink, "Allow dual-link TMDS (default: enabled)");
 int nouveau_duallink = 1;
-module_param_named(duallink, nouveau_duallink, int, 0400);
+module_param_named(duallink, nouveau_duallink, int, 0444);
 
 MODULE_PARM_DESC(hdmimhz, "Force a maximum HDMI pixel clock (in MHz)");
 int nouveau_hdmimhz = 0;
-module_param_named(hdmimhz, nouveau_hdmimhz, int, 0400);
+module_param_named(hdmimhz, nouveau_hdmimhz, int, 0444);
 
 struct nouveau_encoder *
 find_encoder(struct drm_connector *connector, int type)
diff --git a/drivers/gpu/drm/nouveau/nouveau_debugfs.c 
b/drivers/gpu/drm/nouveau/nouveau_debugfs.c
index 3d0dc19..135e6c8 100644
--- a/drivers/gpu/drm/nouveau/nouveau_debugfs.c
+++ b/drivers/gpu/drm/nouveau/nouveau_debugfs.c
@@ -204,7 +204,7 @@ nouveau_debugfs_create_file(struct drm_minor *minor,
 
node->minor = minor;
node->info_ent = (const void *)ndf->fops;
-   node->dent = debugfs_create_file(ndf->name, S_IRUGO | S_IWUSR,
+   node->dent = debugfs_create_file(ndf->name, 0644,
 minor->debugfs_root, node, ndf->fops);
if (!node->dent) {
kfree(node);
diff --git a/drivers/gpu/drm/nouveau/nouveau_drm.c 
b/drivers/gpu/drm/nouveau/nouveau_drm.c
index d06877d..2166bdc 100644
--- a/drivers/gpu/drm/nouveau/nouveau_drm.c
+++ b/drivers/gpu/drm/nouveau/nouveau_drm.c
@@ -63,24 +63,24 @@
 
 MODULE_PARM_DESC(config, "option string to pass to driver core");
 static char *nouveau_config;
-module_param_named(config, nouveau_config, charp, 0400);
+module_param_named(config, nouveau_config, charp, 0444);
 
 MODULE_PARM_DESC(debug, "debug string to pass to driver core");
 static char *nouveau_debug;
-module_param_named(debug, nouveau_debug, charp, 0400);
+module_param_named(debug, nouveau_debug, charp, 0444);
 
 MODULE_PARM_DESC(noaccel, "disable kernel/abi16 acceleration");
 static int nouveau_noaccel = 0;
-module_param_named(noaccel, nouveau_noaccel, int, 0400);
+module_param_named(noaccel, nouveau_noaccel, int, 0444);
 
 MODULE_PARM_DESC(modeset, "enable driver (default: auto, "
  "0 = disabled, 1 = enable

[Nouveau] [PATCH] module parameters: permissions as defines, readable to everyone

[poma]

For the purposes of the module parameters,
specifies the permissions of the corresponding files in sysfs in predefined 
S_I* form rather than in octal notation.
Withal it makes the source code more consistent.
Moreover, because all parameters are readable to everyone, it is more 
user-friendly.

$ grep S_IRUGO include/linux/stat.h
#define S_IRUGO (S_IRUSR|S_IRGRP|S_IROTH)

$ grep 'S_IRUSR\|S_IRGRP\|S_IROTH' include/uapi/linux/stat.h
#define S_IRUSR 00400
#define S_IRGRP 00040
#define S_IROTH 4

$ ls -l /sys/module/nouveau/parameters/
total 0
-r--r--r--. 1 root root 4096 Apr 10 17:43 config
-r--r--r--. 1 root root 4096 Apr 10 17:43 debug
-r--r--r--. 1 root root 4096 Apr 10 17:43 duallink
-r--r--r--. 1 root root 4096 Apr 10 17:43 hdmimhz
-r--r--r--. 1 root root 4096 Apr 10 17:43 ignorelid
-r--r--r--. 1 root root 4096 Apr 10 17:43 modeset
-r--r--r--. 1 root root 4096 Apr 10 17:43 noaccel
-r--r--r--. 1 root root 4096 Apr 10 17:43 nofbaccel
-r--r--r--. 1 root root 4096 Apr 10 17:43 runpm
-r--r--r--. 1 root root 4096 Apr 10 17:43 tv_disable
-r--r--r--. 1 root root 4096 Apr 10 17:43 tv_norm
-r--r--r--. 1 root root 4096 Apr 10 17:43 vram_pushbuf

$ systool -vm nouveau | grep Parameters -A 12
  Parameters:
config  =  28 6e 75 6c 6c 29 0a
debug   = "(null)"
duallink= "1"
hdmimhz = "0"
ignorelid   = "0"
modeset = "-1"
noaccel = "0"
nofbaccel   = "0"
runpm   = "-1"
tv_disable  = "0"
tv_norm = "(null)"
vram_pushbuf= "0"

Signed-off-by: poma <pomidorabelis...@gmail.com>
---
 drivers/gpu/drm/nouveau/dispnv04/tvnv17.c   |  2 +-
 drivers/gpu/drm/nouveau/nouveau_chan.c  |  2 +-
 drivers/gpu/drm/nouveau/nouveau_connector.c |  8 
 drivers/gpu/drm/nouveau/nouveau_drm.c   | 10 +-
 drivers/gpu/drm/nouveau/nouveau_fbcon.c |  2 +-
 5 files changed, 12 insertions(+), 12 deletions(-)

diff --git a/drivers/gpu/drm/nouveau/dispnv04/tvnv17.c 
b/drivers/gpu/drm/nouveau/dispnv04/tvnv17.c
index 163317d..af520d0 100644
--- a/drivers/gpu/drm/nouveau/dispnv04/tvnv17.c
+++ b/drivers/gpu/drm/nouveau/dispnv04/tvnv17.c
@@ -40,7 +40,7 @@ MODULE_PARM_DESC(tv_norm, "Default TV norm.\n"
 "\t\tDefault: PAL\n"
 "\t\t*NOTE* Ignored for cards with external TV encoders.");
 static char *nouveau_tv_norm;
-module_param_named(tv_norm, nouveau_tv_norm, charp, 0400);
+module_param_named(tv_norm, nouveau_tv_norm, charp, S_IRUGO);
 
 static uint32_t nv42_tv_sample_load(struct drm_encoder *encoder)
 {
diff --git a/drivers/gpu/drm/nouveau/nouveau_chan.c 
b/drivers/gpu/drm/nouveau/nouveau_chan.c
index 879655c..0bb1b9c 100644
--- a/drivers/gpu/drm/nouveau/nouveau_chan.c
+++ b/drivers/gpu/drm/nouveau/nouveau_chan.c
@@ -43,7 +43,7 @@
 
 MODULE_PARM_DESC(vram_pushbuf, "Create DMA push buffers in VRAM");
 int nouveau_vram_pushbuf;
-module_param_named(vram_pushbuf, nouveau_vram_pushbuf, int, 0400);
+module_param_named(vram_pushbuf, nouveau_vram_pushbuf, int, S_IRUGO);
 
 int
 nouveau_channel_idle(struct nouveau_channel *chan)
diff --git a/drivers/gpu/drm/nouveau/nouveau_connector.c 
b/drivers/gpu/drm/nouveau/nouveau_connector.c
index ae96ebc..30785fb 100644
--- a/drivers/gpu/drm/nouveau/nouveau_connector.c
+++ b/drivers/gpu/drm/nouveau/nouveau_connector.c
@@ -49,19 +49,19 @@
 
 MODULE_PARM_DESC(tv_disable, "Disable TV-out detection");
 int nouveau_tv_disable = 0;
-module_param_named(tv_disable, nouveau_tv_disable, int, 0400);
+module_param_named(tv_disable, nouveau_tv_disable, int, S_IRUGO);
 
 MODULE_PARM_DESC(ignorelid, "Ignore ACPI lid status");
 int nouveau_ignorelid = 0;
-module_param_named(ignorelid, nouveau_ignorelid, int, 0400);
+module_param_named(ignorelid, nouveau_ignorelid, int, S_IRUGO);
 
 MODULE_PARM_DESC(duallink, "Allow dual-link TMDS (default: enabled)");
 int nouveau_duallink = 1;
-module_param_named(duallink, nouveau_duallink, int, 0400);
+module_param_named(duallink, nouveau_duallink, int, S_IRUGO);
 
 MODULE_PARM_DESC(hdmimhz, "Force a maximum HDMI pixel clock (in MHz)");
 int nouveau_hdmimhz = 0;
-module_param_named(hdmimhz, nouveau_hdmimhz, int, 0400);
+module_param_named(hdmimhz, nouveau_hdmimhz, int, S_IRUGO);
 
 struct nouveau_encoder *
 find_encoder(struct drm_connector *connector, int type)
diff --git a/drivers/gpu/drm/nouveau/nouveau_drm.c 
b/drivers/gpu/drm/nouveau/nouveau_drm.c
index d06877d..98ead83 100644
--- a/drivers/gpu/drm/nouveau/nouveau_drm.c
+++ b/drivers/gpu/drm/nouveau/nouveau_drm.c
@@ -63,24 +63,24 @@
 
 MODULE_PARM_DESC(config, "option string to pass to driver core");
 static char *nouveau_config;
-module_param_named(config, nouveau_config, charp, 0400);
+mod

Re: [Nouveau] glmark2: high CPU usage - DRI3 & modeset

[poma]

On 07.04.2016 14:51, Karol Herbst wrote:
> did the test result changed in any way? Maybe the DRI2 run was vsynced and the
> DRI3 not?
> Nouveau has a pretty high cpu usage in general, because it usually busy waits 
> on
> fences (I think? not sure where it was exactly that nouveau is busy waiting)
> 
>> poma <pomidorabelis...@gmail.com> hat am 7. April 2016 um 13:56 geschrieben:
>>
>>
>>
>> $ glmark2
>> ===
>> glmark2 2014.03
>> ===
>> OpenGL Information
>> GL_VENDOR: nouveau
>> GL_RENDERER:   Gallium 0.4 on NV98
>> GL_VERSION:3.0 Mesa 11.2.0
>> ===
>>
>>
>> /etc/X11/xorg.conf.d/nouveau.conf 
>> Section "Device"
>>   Identifier  "gpu0"
>>   Driver  "nouveau"
>> EndSection
>>
>> $ ps -C glmark2 -o cmd,pcpu
>> CMD %CPU
>> glmark2 16.2
>>
>> ~
>>
>> /etc/X11/xorg.conf.d/nouveau.conf 
>> Section "Device"
>>   Identifier  "gpu0"
>>   Driver  "nouveau"
>>   Option  "DRI" "3"
>> EndSection
>>
>> $ ps -C glmark2 -o cmd,pcpu
>> CMD %CPU
>> glmark2 86.4
>>
>> ~
>>
>> /etc/X11/xorg.conf.d/modeset.conf 
>> Section "Device"
>>   Identifier  "gpu0"
>>   Driver  "modesetting"
>> EndSection
>>
>> $ ps -C glmark2 -o cmd,pcpu
>> CMD %CPU
>> glmark2 94.5
>>


'vblank_mode=0 glmark2' makes no difference.

A -fence- as a sync object?
https://www.opengl.org/wiki/Sync_Object#Fence


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

[Nouveau] glmark2: high CPU usage - DRI3 & modeset

[poma]

$ glmark2
===
glmark2 2014.03
===
OpenGL Information
GL_VENDOR: nouveau
GL_RENDERER:   Gallium 0.4 on NV98
GL_VERSION:3.0 Mesa 11.2.0
===


/etc/X11/xorg.conf.d/nouveau.conf 
Section "Device"
  Identifier  "gpu0"
  Driver  "nouveau"
EndSection

$ ps -C glmark2 -o cmd,pcpu
CMD %CPU
glmark2 16.2

~

/etc/X11/xorg.conf.d/nouveau.conf 
Section "Device"
  Identifier  "gpu0"
  Driver  "nouveau"
  Option  "DRI" "3"
EndSection

$ ps -C glmark2 -o cmd,pcpu
CMD %CPU
glmark2 86.4

~

/etc/X11/xorg.conf.d/modeset.conf 
Section "Device"
  Identifier  "gpu0"
  Driver  "modesetting"
EndSection

$ ps -C glmark2 -o cmd,pcpu
CMD %CPU
glmark2 94.5

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

[Nouveau] stable? kms: take mode_config mutex in connector hotplug path

[poma]

https://github.com/skeggsb/nouveau/commit/9862b21
https://git.kernel.org/cgit/linux/kernel/git/next/linux-next.git/commit/drivers/gpu/drm/nouveau/nouveau_connector.c?id=0a882cad

this was sent to @stable,
but test result is:

nouveau: Unknown symbol mutex_lock (err 0)
nouveau: Unknown symbol mutex_lock_interruptible (err 0)

4.4.3-201.fc22.x86_64+debug

Backport faux?

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

[Nouveau] freshclam: page allocation failure: order:0, mode:0x2204010

[poma]

Hi Fi, 

as you can see it looks very peculiar mix, nouveau and usbnet.
Are they hidden viruses!?

...
freshclam: page allocation failure: order:0, mode:0x2204010
CPU: 0 PID: 12885 Comm: freshclam Not tainted 4.4.0-1.fc22.x86_64 #1
...
Call Trace:
   [] dump_stack+0x4b/0x72
 [] warn_alloc_failed+0xfa/0x160
 [] __alloc_pages_nodemask+0x4b1/0xd70
 [] ? nvkm_client_ioctl+0x12/0x20 [nouveau]
 [] alloc_pages_current+0x9b/0x1c0
 [] new_slab+0x2a8/0x530
 [] ___slab_alloc+0x1f0/0x580
 [] ? sched_clock_local+0x17/0x80
 [] ? radix_tree_node_alloc+0x28/0xa0
 [] ? intr_complete+0x3d/0xd0 [usbnet]
 [] ? radix_tree_node_alloc+0x28/0xa0
 [] __slab_alloc+0x51/0x90
 [] kmem_cache_alloc+0x250/0x300
 [] ? radix_tree_node_alloc+0x28/0xa0
 [] radix_tree_node_alloc+0x28/0xa0
 [] __radix_tree_create+0x7c/0x200
 [] radix_tree_insert+0x41/0xe0
 [] add_dma_entry+0xa2/0x170
 [] debug_dma_map_page+0x113/0x150
 [] usb_hcd_map_urb_for_dma+0x5f8/0x780
 [] ? trace_hardirqs_on+0xd/0x10
 [] usb_hcd_submit_urb+0x1cd/0xac0
 [] ? sched_clock_cpu+0x8a/0xb0
 [] ? led_trigger_blink_oneshot+0x77/0x90
 [] ? local_clock+0x15/0x20
 [] ? debug_lockdep_rcu_enabled+0x1d/0x20
 [] usb_submit_urb+0x3fc/0x5a0
 [] ? _raw_read_unlock+0x27/0x40
 [] intr_complete+0x3d/0xd0 [usbnet]
 [] __usb_hcd_giveback_urb+0x8e/0x160
 [] usb_giveback_urb_bh+0x9a/0xf0
 [] tasklet_hi_action+0x184/0x1d0
 [] __do_softirq+0xde/0x490
 [] ? handle_fasteoi_irq+0x11d/0x150
 [] irq_exit+0x112/0x120
 [] do_IRQ+0x6a/0x120
 [] common_interrupt+0x91/0x91
   [] ? _raw_spin_unlock_irq+0x33/0x40
 [] ? _raw_spin_unlock_irq+0x2c/0x40
 [] shrink_active_list+0x178/0x3a0
 [] shrink_lruvec+0x5e5/0x750
 [] shrink_zone+0xef/0x2e0
 [] do_try_to_free_pages+0x17c/0x400
 [] try_to_free_pages+0xfe/0x2c0
 [] __alloc_pages_nodemask+0x894/0xd70
 [] ? __lock_acquire+0x4ba/0x1b70
 [] ? sched_clock+0x9/0x10
 [] alloc_pages_current+0x9b/0x1c0
 [] __page_cache_alloc+0x150/0x1a0
 [] ? find_get_entry+0x120/0x240
 [] ? find_get_entry+0x5/0x240
 [] pagecache_get_page+0x84/0x200
 [] grab_cache_page_write_begin+0x29/0x40
 [] ext4_da_write_begin+0xd0/0x3d0
 [] generic_perform_write+0xd1/0x1e0
 [] ? file_update_time+0x5f/0x110
 [] __generic_file_write_iter+0x1a2/0x1e0
 [] ext4_file_write_iter+0x102/0x480
 [] ? sched_clock+0x9/0x10
 [] __vfs_write+0xcc/0x110
 [] vfs_write+0xac/0x1a0
 [] ? __fget_light+0x66/0x90
 [] SyS_write+0x58/0xd0
 [] entry_SYSCALL_64_fastpath+0x12/0x76
SLUB: Unable to allocate memory on node -1 (gfp=0x200)
  cache: radix_tree_node, object size: 576, buffer size: 584, default order: 2, 
min order: 0
  node 0: slabs: 766, objs: 21448, free: 0
DMA-API: cacheline tracking ENOMEM, dma-debug disabled
...

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

Re: [Nouveau] Activate DVI-I behind KVM on FX 5200

[poma]

On 05.01.2016 04:08, Thomas Richter wrote:
> Hi folks,
> 
> I don't seem to be able to enable the DVI-I output of an old FX 5200
> behind a KVM switch. Autodetection works fine if the FX 5200 DVI output
> is switched to the monitor, but when it is not, I have not found a way
> to force-enable it.
> 
> Here is what I tried:
> 
> *) used the video=DVI-I-1:1280x1024-24@60e kernel parameter
> (framebuffer still sits at 1024x768)
> 
...

Tested here,

in "video=DVI-I-1:1280x1024-24@60e" directive
problematic are:

color depth (bpp) 24
-and-
'e' as "forced display enablement"

causing display -switching off- at the exact moment:
fb: switching to nouveaufb from VESA VGA


Contrairement à ce que,
these 3 examples have been successfully tested:

1.  video=DVI-I-1:1280x1024
2.  video=DVI-I-1:1280x1024@60
3.  video=DVI-I-1:1280x1024-16@60

~~

# cat /proc/cmdline
... video=DVI-I-1:1280x1024 ...


# fbset -i

mode "1280x1024"
geometry 1280 1024 1280 1024 32
timings 0 0 0 0 0 0 0
accel true
rgba 8/16,8/8,8/0,0/0
endmode

Frame buffer device information:
Name: nouveaufb
Address : 0xd0006000
Size: 5242880
Type: PACKED PIXELS
Visual  : TRUECOLOR
XPanStep: 1
YPanStep: 1
YWrapStep   : 0
LineLength  : 5120
Accelerator : No


# dmesg -t | egrep fb:\ 0x
nouveau :02:00.0: DRM: allocated 1280x1024 fb: 0x5, bo 88007f5d2800

~~

# cat /proc/cmdline
... video=DVI-I-1:1280x1024@60 ...


# fbset -i

mode "1280x1024"
geometry 1280 1024 1280 1024 32
timings 0 0 0 0 0 0 0
accel true
rgba 8/16,8/8,8/0,0/0
endmode

Frame buffer device information:
Name: nouveaufb
Address : 0xd0006000
Size: 5242880
Type: PACKED PIXELS
Visual  : TRUECOLOR
XPanStep: 1
YPanStep: 1
YWrapStep   : 0
LineLength  : 5120
Accelerator : No

~

# cat /proc/cmdline
... video=DVI-I-1:1280x1024-16@60 ...


# fbset -i

mode "1280x1024"
geometry 1280 1024 1280 1024 16
timings 0 0 0 0 0 0 0
accel true
rgba 5/11,6/5,5/0,0/0
endmode

Frame buffer device information:
Name: nouveaufb
Address : 0xd0006000
Size: 2621440
Type: PACKED PIXELS
Visual  : TRUECOLOR
XPanStep: 1
YPanStep: 1
YWrapStep   : 0
LineLength  : 2560
Accelerator : No



Ref.
https://www.kernel.org/doc/Documentation/fb/modedb.txt

p.s.
Can you paste here the output of these two oneliners:
$ cd /sys/class/drm ; ls -1d card0-* | sed s/card0-// | sort
$ xrandr | grep connected | awk '{print $1}' | sort


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

[Nouveau] League of Legends Refueled

[poma]

http://cgit.freedesktop.org/~darktama/nouveau
https://github.com/skeggsb/nouveau

Is the one at freedesktop.org - ride on diesel, became a part of museum's 
collection?

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

Re: [Nouveau] Activate DVI-I behind KVM on FX 5200

[poma]

On 05.01.2016 14:47, Thomas Richter wrote:
> Am 05.01.2016 um 11:41 schrieb poma:
> 
>>
>> append to kernel cmdline:
>> drm_kms_helper.edid_firmware=DVI-I-1:edid/edid.bin
>>
>> $ cat /proc/cmdline
>> ... drm_kms_helper.edid_firmware=DVI-I-1:edid/edid.bin ...
>>
> 
> Well, no banana. Yes, the kernel loads the edid, but the screen keeps
> blank if I switch the monitor to the system after bootstrap. )-:
> 
> [   20.319271] [drm] Got external EDID base block and 0 extensions from
> "edid/edid.bin" for connector "DVI-I-1"
> [   20.347274] [drm] Got external EDID base block and 0 extensions from
> "edid/edid.bin" for connector "DVI-I-1"
> 
> I also replaced that with the "dummy" edid/1280x1024.bin parameter, same
> thing.
> 
> If I boot with the monitor connected, everything is fine. If I boot with
> it disconnected, no chance.
> 
> I also tried to force the DVI connector on:
> 
> video=DVI-I-1:e
> 
> The result is that the kernel still loads the edid, but the screen
> remains now blank all the time, even if I boot with the monitor connected.
> 
> Yes, it is really connected to DVI-I-1, at least according to xrandr
> without the "video" parameter, and with the monitor connected.
> 
> Greetings,
>   Thomas
> 

Try your luck here
http://lists.freedesktop.org/mailman/listinfo/dri-devel

BTW what is actual KVM switch device, vendor/product?


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

Re: [Nouveau] Activate DVI-I behind KVM on FX 5200

[poma]

On 05.01.2016 20:31, Thomas Richter wrote:
> Hi,
> 
>>
>> Try your luck here
>> http://lists.freedesktop.org/mailman/listinfo/dri-devel
> 
> The major problem is that there is no way to tell the nouveau kernel 
> module to enforce a specific output. There is a video=XXX kernel 
> parameter, but this only applies to the VGA framebuffer but not to the 
> nouveau framebuffer.
> 

Tested,
in contrast to enablement, video=DVI-I-1:d becomes effective at the exact 
moment:
fb: switching to nouveaufb from VESA VGA

However this is a direct connection, without KVM switch.

>> BTW what is actual KVM switch device, vendor/product?
> 
> This is an ATEN CS22D. It is "supposed to remember the EDID data", but 
> frankly, it does not.
> 

http://eservice.aten.com/eServiceCx/Common/FAQ/view.do?id=4746
"No, The CS22D/CS22U do not support Video Dynasync feature, it bypass's EDID."


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

Re: [Nouveau] Activate DVI-I behind KVM on FX 5200

[poma]

On 05.01.2016 04:08, Thomas Richter wrote:
> Hi folks,
> 
> I don't seem to be able to enable the DVI-I output of an old FX 5200
> behind a KVM switch. Autodetection works fine if the FX 5200 DVI output
> is switched to the monitor, but when it is not, I have not found a way
> to force-enable it.
> 
> Here is what I tried:
> 
> *) used the video=DVI-I-1:1280x1024-24@60e kernel parameter
> (framebuffer still sits at 1024x768)
> 
> *) used "options drm_kms_helper edid-firmware=edid/edid.bin"
> in /etc/modprobe.d/nouveau.conf. "no initrd here, drm-kms-helper.ko is
> loaded during bootstrap)
> 
> *) downloaded the edid from the monitor and validated its correctness.
> I placed the edid data into /lib/firmware/edid/edid.bin, and added the
> module option "options drm_kms_helper edid-firmware=edid/edid.bin"
> 

append to kernel cmdline:
drm_kms_helper.edid_firmware=DVI-I-1:edid/edid.bin

$ cat /proc/cmdline
... drm_kms_helper.edid_firmware=DVI-I-1:edid/edid.bin ...


> as one can see from
> "/sys/module/drm_kms_helper/parameters/edid_firmware", the parameter is
> accepted, but does not resolve the problem. Framebuffer stays at
> 1024x768, and "xinit" does not give any display.
> 
> Any hints appreciated. It would be very helpful to have a working display.
> 
> Greetings,
>   Thomas
> ___
> 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

Re: [Nouveau] nouveau sync DMA memory not allocated

[poma]

On 12.11.2015 14:48, Thierry Reding wrote:
> On Wed, Nov 11, 2015 at 09:12:33PM +0100, poma wrote:
>> On 10.11.2015 17:25, Mario Kleiner wrote:
>>> On 11/10/2015 05:00 PM, Thierry Reding wrote:
>>>> On Tue, Nov 10, 2015 at 03:54:52PM +0100, Mario Kleiner wrote:
>>>>> From: Daniel Vetter <daniel.vet...@ffwll.ch>
>>>>>
>>>>> Apparently pre-nv50 pageflip events happen before the actual vblank
>>>>> period. Therefore that functionality got semi-disabled in
>>>>>
>>>>> commit af4870e406126b7ac0ae7c7ce5751f25ebe60f28
>>>>> Author: Mario Kleiner <mario.kleiner...@gmail.com>
>>>>> 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 <tred...@nvidia.com>
>>>>> 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 <tred...@nvidia.com>
>>>>> Cc: Mario Kleiner <mario.kleiner...@gmail.com>
>>>>> Cc: Ben Skeggs <bske...@redhat.com>
>>>>> Cc: Ilia Mirkin <imir...@alum.mit.edu>
>>>>>
>>>>> v2 (mario): Integrate my own review comments into Daniels patch.
>>>>> - Fix function prototypes in drmP.h
>>>>> - Add missing vblank_put() for pageflip completion without
>>>>>   pageflip event.
>>>>> - Initialize sequence number for queued pageflip event to avoidng
>>>>>   trouble in drm_handle_vblank_events().
>>>>> - Remove dead code and spelling fix.
>>>>>
>>>>> v3 (mario): Add a signed-off-by and cc stable tag per Ilja's advice.
>>>>>
>>>>> Signed-off-by: Daniel Vetter <daniel.vet...@intel.com>
>>>>> (v1) Reviewed-by: Mario Kleiner <mario.kleiner...@gmail.com>
>>>>> (v2/v3) Signed-off-by: Mario Kleiner <mario.kleiner...@gmail.com>
>>>>>
>>>>> Cc: sta...@vger.kernel.org # v4.3
>>>>> ---
>>>>>   drivers/gpu/drm/drm_irq.c | 54 
>>>>> ++-
>>>>>   drivers/gpu/drm/nouveau/nouveau_display.c | 19 ++-
>>>>>   include/drm/drmP.h|  4 +++
>>>>>   3 files changed, 68 insertions(+), 9 deletions(-)
>>>>
>>>> This looks good to me. Let me clean this up a little and submit it to
>>>> Dave.
>>>>
>>>> Thierry
>>>>
>>>
>>> Btw., if somebody has a functional old card for testing this, it should 
>>> be easy to verify if it works on pre-nv50. If it would not work it would 
>>> deliver the pageflip event 1 frame delayed, so at least on standard 
>>> nouveau + default DRI2 + default double-buffering the rate for a tight 
>>> loop of page-flipped swaps should go down to 30 fps on a 60 Hz display, 
>>> quite noticeable. Afaik we also have Piglit tests for OML_sync_control 
>>> which would likely fail if this would be broken.
>>>
>>> Oh and if someone has tips on how to resurrect an old nv-40 PC (booted 
>>> with BIOS o

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

[poma]

On 10.11.2015 17:41, Thierry Reding wrote:
> On Tue, Nov 10, 2015 at 05:37:31PM +0100, Thierry Reding wrote:
>> From: Daniel Vetter 
>>
>> 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
>>
>> Triggering 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.
>>
>> v2 (Mario Kleiner):
>> - Fix function prototypes in drmP.h
>> - Add missing vblank_put() for pageflip completion without
>>   pageflip event.
>> - Initialize sequence number for queued pageflip event to avoid
>>   trouble in drm_handle_vblank_events().
>> - Remove dead code and spelling fix.
>>
>> v3 (Mario Kleiner):
>> - Add a signed-off-by and cc stable tag per Ilja's advice.
>>
>> v4 (Thierry Reding):
>> - Fix kerneldoc typo, discovered by Michel Dänzer
>> - Rearrange tags and changelog
>>
>> 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 
>> Reviewed-by: Mario Kleiner 
>> Cc: sta...@vger.kernel.org # v4.3
>> Signed-off-by: Mario Kleiner 
>> Signed-off-by: Thierry Reding 
>> ---
>>  drivers/gpu/drm/drm_irq.c | 54 
>> ++-
>>  drivers/gpu/drm/nouveau/nouveau_display.c | 19 ++-
>>  include/drm/drmP.h|  4 +++
>>  3 files changed, 68 insertions(+), 9 deletions(-)
> 
> Hi Dave,
> 
> It'd be great if you could queue this up for fixes, since it gets rid of
> a WARN_ON() that is triggered on a number of cards in v4.3. I realize
> that this is a tad big for stable, but it's the right way to fix this.
> If you'd prefer something smaller, I think we can fix the regression
> using a one-line band-aid and then apply this one on top for v4.4.
> 
> Thierry
> 


Apparently not reached @stable (stable: 4.3.3 2015-12-15),
so here's one more time.


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

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

[poma]

On 15.12.2015 12:21, Emil Velikov wrote:
> On 15 December 2015 at 11:11, poma <pomidorabelis...@gmail.com> wrote:
> 
>>
>> Apparently not reached @stable (stable: 4.3.3 2015-12-15),
>> so here's one more time.
>>
> It has reached 4.4-rcX and will get picked by the stable maintainer
> (Greg?) in due time. Meanwhile you can ask your distro maintainers to
> apply it locally until we get an official release that includes it.
> 
> -Emil
> 

It is all but unknown ;)
https://bugzilla.redhat.com/show_bug.cgi?id=1281368

Emil, the point is - if it has -not- reached sta...@vger.kernel.org, how can it 
be applied, in the first place.

Aye

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

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

[poma]

On 02.12.2015 09:55, Daniel Vetter wrote:
> On Wed, Dec 02, 2015 at 06:40:32AM +0100, poma wrote:
>> On Tue, Dec 1, 2015 at 6:30 PM, Mario Kleiner
>> <mario.kleiner...@gmail.com> wrote:
>>> When we are at it, the one with the title "[PATCH] drm/nouveau: Use
>>> drm_vblank_on/off consistently" from Daniel, which has a reviewed and tested
>>> by me also never made it into nouveau.
>>>
>>> Maybe pick that up as well?
>>>
>>> -mario
>>>
>>
>> If you refer to
>> "[1/3] drm/nouveau: Use drm_vblank_on/off consistently"
>> https://patchwork.freedesktop.org/patch/50771
>>
>> this is the result:
>> patched 4.4.0-0.rc3.git0.1.fc24.x86_64 with it,
>> i.e. 1-3-drm-nouveau-Use-drm_vblank_on-off-consistently.patch
>>
>> # cat /var/log/Xorg.0.log
>> [   126.360]
>> X.Org X Server 1.18.0
>> ...
>> [   126.909] (EE) [drm] Failed to open DRM device for pci::02:00.0: -19
>> [   126.909] (EE) No devices detected.
>> [   126.909] (EE)
>> Fatal server error:
>> [   126.909] (EE) no screens found(EE)
>> [   126.909] (EE)
>> Please consult 
> 
> Kernel log needed if the drm device isn't there. And this is pretty much
> impossible, worst case modesetting is functionally busted.
> -Daniel
> 


Pardon me,
I missed 0 in EXTRAVERSION, therefore version magic not so pretty.

$ sed -i 's/-rc3/\-0.rc3/' Makefile

[ 1771.699138] checking generic (f700 e0) vs hw (d000 1000)
[ 1771.699143] checking generic (f700 e0) vs hw (f600 200)
[ 1771.699144] fb: switching to nouveaufb from VESA VGA
[ 1771.699271] Console: switching to colour dummy device 80x25
[ 1771.699450] nouveau :02:00.0: NVIDIA G98 (098200a2)
[ 1771.813968] nouveau :02:00.0: bios: version 62.98.2c.00.00
[ 1771.834802] nouveau :02:00.0: bios: M0203T not found
[ 1771.834819] nouveau :02:00.0: bios: M0203E not matched!
[ 1771.834830] nouveau :02:00.0: fb: 512 MiB DDR2
[ 1774.593921] [TTM] Zone  kernel: Available graphics memory: 1891762 kiB
[ 1774.593926] [TTM] Initializing pool allocator
[ 1774.593932] [TTM] Initializing DMA pool allocator
[ 1774.593948] nouveau :02:00.0: DRM: VRAM: 512 MiB
[ 1774.593950] nouveau :02:00.0: DRM: GART: 1048576 MiB
[ 1774.593954] nouveau :02:00.0: DRM: TMDS table version 2.0
[ 1774.593956] nouveau :02:00.0: DRM: DCB version 4.0
[ 1774.593959] nouveau :02:00.0: DRM: DCB outp 00: 02000300 0028
[ 1774.593962] nouveau :02:00.0: DRM: DCB outp 01: 01000302 00020030
[ 1774.593964] nouveau :02:00.0: DRM: DCB outp 02: 04011310 0028
[ 1774.593966] nouveau :02:00.0: DRM: DCB outp 03: 010223f1 00c0c080
[ 1774.593969] nouveau :02:00.0: DRM: DCB conn 00: 1030
[ 1774.593971] nouveau :02:00.0: DRM: DCB conn 01: 0100
[ 1774.593973] nouveau :02:00.0: DRM: DCB conn 02: 0210
[ 1774.593975] nouveau :02:00.0: DRM: DCB conn 03: 0211
[ 1774.593977] nouveau :02:00.0: DRM: DCB conn 04: 0213
[ 1774.595827] nouveau :02:00.0: DRM: failed to create encoder 0/1/0: -19
[ 1774.595832] nouveau :02:00.0: DRM: TV-1 has no encoders, removing
[ 1774.595867] [drm] Supports vblank timestamp caching Rev 2 (21.10.2013).
[ 1774.595870] [drm] Driver supports precise vblank timestamp query.
[ 1774.600023] CE: hpet increased min_delta_ns to 11521 nsec
[ 1774.605699] nouveau :02:00.0: DRM: MM: using M2MF for buffer copies
[ 1774.690808] nouveau :02:00.0: DRM: allocated 1024x768 fb: 0x5, bo 
8800c9a46000
[ 1774.690960] fbcon: nouveaufb (fb0) is primary device
[ 1774.746581] Console: switching to colour frame buffer device 128x48
[ 1774.747411] nouveau :02:00.0: fb0: nouveaufb frame buffer device
[ 1774.750093] [drm] Initialized nouveau 1.3.1 20120801 for :02:00.0 on 
minor 0


Tested-by: poma <pomidorabelis...@gmail.com>


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

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

[poma]

On Tue, Dec 1, 2015 at 6:30 PM, Mario Kleiner
 wrote:
> When we are at it, the one with the title "[PATCH] drm/nouveau: Use
> drm_vblank_on/off consistently" from Daniel, which has a reviewed and tested
> by me also never made it into nouveau.
>
> Maybe pick that up as well?
>
> -mario
>

If you refer to
"[1/3] drm/nouveau: Use drm_vblank_on/off consistently"
https://patchwork.freedesktop.org/patch/50771

this is the result:
patched 4.4.0-0.rc3.git0.1.fc24.x86_64 with it,
i.e. 1-3-drm-nouveau-Use-drm_vblank_on-off-consistently.patch

# cat /var/log/Xorg.0.log
[   126.360]
X.Org X Server 1.18.0
...
[   126.909] (EE) [drm] Failed to open DRM device for pci::02:00.0: -19
[   126.909] (EE) No devices detected.
[   126.909] (EE)
Fatal server error:
[   126.909] (EE) no screens found(EE)
[   126.909] (EE)
Please consult 
...
___
Nouveau mailing list
Nouveau@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/nouveau

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

[poma]

On Mon, Nov 16, 2015 at 4:11 PM, Daniel Vetter  wrote:
> On Mon, Nov 02, 2015 at 04:45:00PM +0900, Michel Dänzer wrote:
>> On 31.10.2015 06:55, 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.
>>
>> What happens when the page flip interrupt arrives during a vertical
>> blank period?  Presumably the userspace event will be deferred until the
>> next vertical blank period, but the flip might already take effect in
>> the current one.
>
> Hm yeah there's a tiny race if your update handler for the pageflip can
> race with your vblank handler. That's impossible here since it's all done
> from the same hw irq hanlder, and since that is single-threaded there
> shouldn't be a problem, as long as vblank handling are pageflip are
> ordered correctly.
>
> Might be worth a note in the kerneldoc though that this function isn't
> perfectly foolproof.
> -Daniel


Is there any updates in this respect?

drm-nouveau-Fix-pre-nv50-pageflip-events-v4.patch
https://patchwork.kernel.org/patch/7591531

https://bugzilla.kernel.org/show_bug.cgi?id=106431
Reported: 2015-10-21
___
Nouveau mailing list
Nouveau@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/nouveau

Re: [Nouveau] [PATCH] drm/nouveau: Fix pre-nv50 pageflip events (v3) -> v4

[poma]

On 12.11.2015 14:48, Thierry Reding wrote:
> On Wed, Nov 11, 2015 at 09:12:33PM +0100, poma wrote:
>> On 10.11.2015 17:25, Mario Kleiner wrote:
>>> On 11/10/2015 05:00 PM, Thierry Reding wrote:
>>>> On Tue, Nov 10, 2015 at 03:54:52PM +0100, Mario Kleiner wrote:
>>>>> From: Daniel Vetter <daniel.vet...@ffwll.ch>
>>>>>
>>>>> Apparently pre-nv50 pageflip events happen before the actual vblank
>>>>> period. Therefore that functionality got semi-disabled in
>>>>>
>>>>> commit af4870e406126b7ac0ae7c7ce5751f25ebe60f28
>>>>> Author: Mario Kleiner <mario.kleiner...@gmail.com>
>>>>> 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 <tred...@nvidia.com>
>>>>> 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 <tred...@nvidia.com>
>>>>> Cc: Mario Kleiner <mario.kleiner...@gmail.com>
>>>>> Cc: Ben Skeggs <bske...@redhat.com>
>>>>> Cc: Ilia Mirkin <imir...@alum.mit.edu>
>>>>>
>>>>> v2 (mario): Integrate my own review comments into Daniels patch.
>>>>> - Fix function prototypes in drmP.h
>>>>> - Add missing vblank_put() for pageflip completion without
>>>>>   pageflip event.
>>>>> - Initialize sequence number for queued pageflip event to avoidng
>>>>>   trouble in drm_handle_vblank_events().
>>>>> - Remove dead code and spelling fix.
>>>>>
>>>>> v3 (mario): Add a signed-off-by and cc stable tag per Ilja's advice.
>>>>>
>>>>> Signed-off-by: Daniel Vetter <daniel.vet...@intel.com>
>>>>> (v1) Reviewed-by: Mario Kleiner <mario.kleiner...@gmail.com>
>>>>> (v2/v3) Signed-off-by: Mario Kleiner <mario.kleiner...@gmail.com>
>>>>>
>>>>> Cc: sta...@vger.kernel.org # v4.3
>>>>> ---
>>>>>   drivers/gpu/drm/drm_irq.c | 54 
>>>>> ++-
>>>>>   drivers/gpu/drm/nouveau/nouveau_display.c | 19 ++-
>>>>>   include/drm/drmP.h|  4 +++
>>>>>   3 files changed, 68 insertions(+), 9 deletions(-)
>>>>
>>>> This looks good to me. Let me clean this up a little and submit it to
>>>> Dave.
>>>>
>>>> Thierry
>>>>
>>>
>>> Btw., if somebody has a functional old card for testing this, it should 
>>> be easy to verify if it works on pre-nv50. If it would not work it would 
>>> deliver the pageflip event 1 frame delayed, so at least on standard 
>>> nouveau + default DRI2 + default double-buffering the rate for a tight 
>>> loop of page-flipped swaps should go down to 30 fps on a 60 Hz display, 
>>> quite noticeable. Afaik we also have Piglit tests for OML_sync_control 
>>> which would likely fail if this would be broken.
>>>
>>> Oh and if someone has tips on how to resurrect an old nv-40 PC (booted 
>>> with BIOS o

Re: [Nouveau] [PATCH] drm/nouveau: Fix pre-nv50 pageflip events (v3) -> v4

[poma]

On 10.11.2015 17:25, Mario Kleiner wrote:
> On 11/10/2015 05:00 PM, Thierry Reding wrote:
>> On Tue, Nov 10, 2015 at 03:54:52PM +0100, Mario Kleiner wrote:
>>> From: Daniel Vetter 
>>>
>>> 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 
>>>
>>> v2 (mario): Integrate my own review comments into Daniels patch.
>>> - Fix function prototypes in drmP.h
>>> - Add missing vblank_put() for pageflip completion without
>>>   pageflip event.
>>> - Initialize sequence number for queued pageflip event to avoidng
>>>   trouble in drm_handle_vblank_events().
>>> - Remove dead code and spelling fix.
>>>
>>> v3 (mario): Add a signed-off-by and cc stable tag per Ilja's advice.
>>>
>>> Signed-off-by: Daniel Vetter 
>>> (v1) Reviewed-by: Mario Kleiner 
>>> (v2/v3) Signed-off-by: Mario Kleiner 
>>>
>>> Cc: sta...@vger.kernel.org # v4.3
>>> ---
>>>   drivers/gpu/drm/drm_irq.c | 54 
>>> ++-
>>>   drivers/gpu/drm/nouveau/nouveau_display.c | 19 ++-
>>>   include/drm/drmP.h|  4 +++
>>>   3 files changed, 68 insertions(+), 9 deletions(-)
>>
>> This looks good to me. Let me clean this up a little and submit it to
>> Dave.
>>
>> Thierry
>>
> 
> Btw., if somebody has a functional old card for testing this, it should 
> be easy to verify if it works on pre-nv50. If it would not work it would 
> deliver the pageflip event 1 frame delayed, so at least on standard 
> nouveau + default DRI2 + default double-buffering the rate for a tight 
> loop of page-flipped swaps should go down to 30 fps on a 60 Hz display, 
> quite noticeable. Afaik we also have Piglit tests for OML_sync_control 
> which would likely fail if this would be broken.
> 
> Oh and if someone has tips on how to resurrect an old nv-40 PC (booted 
> with BIOS only) graphics card in a MacPro (EFI boot), i wouldn't mind 
> hearing them. It would be nice to still be able to use that card for 
> testing.
> 
> thanks,
> -mario


[ cut here ]
WARNING: CPU: 0 PID: 313 at lib/dma-debug.c:1205 check_sync+0x169/0x6e0()
nouveau :01:00.0: DMA-API: device driver tries to sync DMA memory it has 
not allocated [device address=0xc0bf6468] [size=4096 bytes]
Modules linked in: nouveau(+) ...
CPU: 0 PID: 313 Comm: systemd-udevd Not tainted 4.3.0-3.fc22.i686+debug #1
...
Call Trace:
 [] dump_stack+0x48/0x69
 [] warn_slowpath_common+0x87/0xc0
 [] ? check_sync+0x169/0x6e0
 [] ? check_sync+0x169/0x6e0
 [] warn_slowpath_fmt+0x3e/0x60
 [] check_sync+0x169/0x6e0
 [] debug_dma_sync_single_for_device+0x7d/0x90
 [] ? ttm_bo_del_sub_from_lru+0x18/0x50 [ttm]
 [] ? text_poke_bp+0xd0/0xd0
 [] nouveau_bo_sync_for_device+0x8b/0xa0 [nouveau]
 [] nouveau_bo_validate+0x34/0x40 [nouveau]
 [] nouveau_bo_pin+0x188/0x290 [nouveau]
 [] ? nv10_bo_put_tile_region+0x80/0x80 [nouveau]
 [] nouveau_channel_prep+0xfd/0x2c0 [nouveau]
 [] nouveau_channel_new+0x57/0x7a0 [nouveau]
 [] ? kfree+0xdc/0x280
 [] ? nvif_object_sclass_put+0x12/0x20 [nouveau]
 [] nouveau_drm_load+0x596/0x8d0 [nouveau]
 [] ? trace_hardirqs_on_caller+0x12c/0x1d0
 [] ? drm_minor_register+0x89/0x120 [drm]
 [] drm_dev_register+0x96/0xa0 [drm]
 [] drm_get_pci_dev+0x79/0x1c0 [drm]
 [] ? pcibios_set_master+0x4e/0xa0
 [] nouveau_drm_probe+0x1ee/0x220 [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 su

Re: [Nouveau] NOUVEAU(0): DRI3 on EXA enabled

[poma]

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 --pr

Re: [Nouveau] NOUVEAU(0): DRI3 on EXA enabled

[poma]

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
&g

Re: [Nouveau] NOUVEAU(0): DRI3 on EXA enabled

[poma]

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


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

[Nouveau] NOUVEAU(0): DRI3 on EXA enabled

[poma]

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

$ vblank_mode=0 glxgears
ATTENTION: default value of option vblank_mode overridden by environment.
7276 frames in 5.0 seconds = 1455.099 FPS
7353 frames in 5.0 seconds = 1470.475 FPS
7373 frames in 5.0 seconds = 1474.566 FPS
7377 frames in 5.0 seconds = 1475.310 FPS
7355 frames in 5.0 seconds = 1470.943 FPS
7350 frames in 5.0 seconds = 1469.864 FPS
7370 frames in 5.0 seconds = 1473.970 FPS
7360 frames in 5.0 seconds = 1471.911 FPS
7360 frames in 5.0 seconds = 1471.944 FPS
7365 frames in 5.0 seconds = 1472.809 FPS
^C


SW:
xorg-x11-drv-nouveau-1.0.12-0.3.fc22.x86_64
xorg-x11-server-Xorg-1.17.2-2.fc22.2.x86_64
mesa-dri-drivers-10.6.9-1.20151008.fc22.x86_64
libdrm-2.4.61-3.fc22.x86_64

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

Re: [Nouveau] Chipset & Family

[poma]

dmesg -t | grep -i nvidia
nouveau :02:00.0: NVIDIA G98 (098200a2)
input: HDA NVidia Rear Mic as 
/devices/pci:00/:00:07.0/sound/card0/input6
input: HDA NVidia Front Mic as 
/devices/pci:00/:00:07.0/sound/card0/input7
input: HDA NVidia Line as /devices/pci:00/:00:07.0/sound/card0/input8
input: HDA NVidia Line Out Front as 
/devices/pci:00/:00:07.0/sound/card0/input9
input: HDA NVidia Line Out Surround as 
/devices/pci:00/:00:07.0/sound/card0/input10
input: HDA NVidia Line Out CLFE as 
/devices/pci:00/:00:07.0/sound/card0/input11
input: HDA NVidia Line Out Side as 
/devices/pci:00/:00:07.0/sound/card0/input12
input: HDA NVidia Front Headphone as 
/devices/pci:00/:00:07.0/sound/card0/input13

- patched:
$ dmesg -t | grep -i chipset
nouveau :02:00.0: GPU NVIDIA Chipset: G98 (098200a2)

Signed-off-by: poma <pomidorabelis...@gmail.com>

Nvidia is not just about video, but also audio,
so be more descriptive on device type and chipset as well.

---
 drm/nouveau/nvkm/engine/device/base.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drm/nouveau/nvkm/engine/device/base.c 
b/drm/nouveau/nvkm/engine/device/base.c
index bbc9824..932a29a 100644
--- a/drm/nouveau/nvkm/engine/device/base.c
+++ b/drm/nouveau/nvkm/engine/device/base.c
@@ -2467,7 +2467,7 @@ nvkm_device_ctor(const struct nvkm_device_func *func,
goto done;
}
 
-   nvdev_info(device, "NVIDIA %s (%08x)\n",
+   nvdev_info(device, "GPU NVIDIA Chipset: %s (%08x)\n",
   device->chip->name, boot0);
 
/* determine frequency of timing crystal */
-- 
2.6.0

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

Re: [Nouveau] Chipset & Family

[poma]

On 07.10.2015 03:55, Ben Skeggs wrote:

> NACK.
> 
> All the relevant information is shown, "nouveau" (video driver)
> detected an "NVIDIA G98" (complete with full chip identification
> register value for specifics).  I'm not bikeshedding this topic any
> further than that.
> 
> Thanks,
> Ben.
> 

Gaudeamus igitur.

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

Re: [Nouveau] Chipset & Family

[poma]

On 06.10.2015 21:07, Pierre Moreau wrote:
> Hello poma,
> 
> The chipset didn't disappear and is still displayed: it is the G98 you get on 
> the "[2.483843] nouveau :02:00.0: NVIDIA G98 (098200a2)" line. The 
> "NV98" was the "Nouveau" chipset, but the switch was made to use the same 
> naming as NVIDIA. So rather than displaying both the Nouveau version of the 
> chipset and the NVIDIA one, it make sense to only use one, and to prefer the 
> NVIDIA naming. (FYI, files name has been modified to follow the NVIDIA naming 
> as well, along with envytools.)
> 

If you decided to follow NVIDIA naming scheme, OK it is your concern as 
developers.
But it's not just the actual version and revision of the chipset, but also 
descriptive string itself - "Chipset".

> As for the family, it can be easily deduced from the chipset in most cases: 
> GMxxx are Maxwell cards, GKxxx are Kepler cards, GFxxx are Fermi cards, GTxxx 
> are Tesla cards, and most reasonably, GPxxx will be Pascal cards. NV50, G8x, 
> G9x, MCPxx are also Tesla cards. They do not follow the same pattern as newer 
> cards and so it might not be as easy to identify their family. But there is 
> the wiki page to help for that. 
> 
> Regards,
> Pierre
> 

(ALL!) all of the people around us they say
Can they be that close
Just let me state for the record
We're giving love in a family dose

We are family
I got all my sisters with me
We are family
Get up ev'rybody and sing


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

Re: [Nouveau] Chipset & Family

[poma]

On 06.10.2015 02:21, poma wrote:
> 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?
> 

http://cgit.freedesktop.org/~darktama/nouveau/commit/drm/nouveau/nvkm/engine/device/base.c?id=6cc9e47

commit 6cc9e47f7f574cb3df6b14caebf15b35408b106d
Author: Ben Skeggs <bske...@redhat.com>
Date:   Thu Aug 20 14:54:13 2015 +1000

device: switch to dev_printk macros

Signed-off-by: Ben Skeggs <bske...@redhat.com>

 drm/nouveau/nvkm/engine/device/base.c  | 11 +++
 ...


-   nv_info(device, "BOOT0  : 0x%08x\n", boot0);
-   nv_info(device, "Chipset: %s (NV%02X)\n",
-   device->cname, device->chipset);
-   nv_info(device, "Family : NV%02X\n", device->card_type);
+   nvdev_info(device, "NVIDIA %s (%08x)\n", device->cname, boot0);



These lines were useful as basic device information,
and as reference to wiki "CodeNames"
http://nouveau.freedesktop.org/wiki/CodeNames

"This page contains a list of some NVIDIA chip code names and their 
corresponding official GeForce number. If you're running a recent version 
nouveau, you can find your chipset by doing dmesg | grep -i chipset. This will 
always be correct, whereas the lists below are approximate."

Notice "dmesg | grep -i chipset"

BTW "NVIDIA" is already visible via 'lspci' - lspci | grep VGA

So only gain is unnecessary information reduction and redundancy.

Please bring Chipset & Family back.


___
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

Re: [Nouveau] nvs280 / nv34 card only does 1680x1050, not 1920x1080 ?

[poma]

On 04.09.2015 19:40, poma wrote:
> On 04.09.2015 16:56, Ilia Mirkin wrote:
>> Tmds is limited to 135mhz on nv3x. If you use analog, you can get full
>> resolution.
>> On Sep 4, 2015 9:00 AM, "Hans de Goede" <hdego...@redhat.com> wrote:
>>
>>> Hi All,
>>>
>>> I've recently acquired a nvs280 card, which is a nv34
>>> gpu based card with a pci-e bridge on the card, this
>>> way I can test nv3x problems without needing an agp
>>> motherboard.
>>>
>>> One thing which stands out with this card is that
>>> it drivers my dvi lcd monitor at 1680x1050 instead of its
>>> native 1920x1080.
>>>
>>> Is this due to a known limitation on the display pipeline
>>> of these cards / nv34 gpu-s. Or is this more likely a bug
>>> somewhere ?
>>>
>>> Regards,
>>>
>>> Hans
>>>
> 
> man 1 cvt
> "Create a mode with reduced blanking. ..."
> 
> Enough to fit,
> GeForce FX 5200 −DVI− LCD FullHD
> 
> xrandr --newmode "1920x1080R" 138.50 1920 1968 2000 2080 1080 1083 1088  
> +hsync -vsync
> xrandr --addmode  1920x1080R
> xrandr --output  --mode 1920x1080R
> 
> 
> 

Via xorg conf:

/etc/X11/xorg.conf.d/00-FullHD.conf
Section "Monitor"
Identifier  "LCD FullHD"
Modeline"1920x1080R" 138.50 1920 1968 2000 2080 1080 1083 1088  
+HSync -VSync
#   Modeline...
Option  "PreferredMode" "1920x1080R"
EndSection

Section "Device"
Identifier  "Chipset NV34"
Option  "Monitor-" "LCD FullHD"
EndSection


man 5 xorg.conf


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

Re: [Nouveau] nvs280 / nv34 card only does 1680x1050, not 1920x1080 ?

[poma]

On 04.09.2015 16:56, Ilia Mirkin wrote:
> Tmds is limited to 135mhz on nv3x. If you use analog, you can get full
> resolution.
> On Sep 4, 2015 9:00 AM, "Hans de Goede"  wrote:
> 
>> Hi All,
>>
>> I've recently acquired a nvs280 card, which is a nv34
>> gpu based card with a pci-e bridge on the card, this
>> way I can test nv3x problems without needing an agp
>> motherboard.
>>
>> One thing which stands out with this card is that
>> it drivers my dvi lcd monitor at 1680x1050 instead of its
>> native 1920x1080.
>>
>> Is this due to a known limitation on the display pipeline
>> of these cards / nv34 gpu-s. Or is this more likely a bug
>> somewhere ?
>>
>> Regards,
>>
>> Hans
>>

man 1 cvt
"Create a mode with reduced blanking. ..."

Enough to fit,
GeForce FX 5200 −DVI− LCD FullHD

xrandr --newmode "1920x1080R" 138.50 1920 1968 2000 2080 1080 1083 1088  
+hsync -vsync
xrandr --addmode  1920x1080R
xrandr --output  --mode 1920x1080R



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

Re: [Nouveau] Odd text behavior on Websites and others

[poma]

On 12.08.2015 00:11, Ilia Mirkin wrote:
 Add a file to /etc/X11/xorg.conf.d, named anything-you-want.conf, which 
 contains
 
 Section Device
   Driver modesetting
 EndSection
 
 Hopefully that should do it.
 


/var/log/Xorg.0.log 
...
[  4223.892] (==) Using config directory: /etc/X11/xorg.conf.d
[  4223.892] (==) Using system config directory /usr/share/X11/xorg.conf.d
[  4223.892] Parse error on line 4 of section Device in file 
/etc/X11/xorg.conf.d/00-modesetting.conf
This section must have an Identifier line.
[  4223.892] (EE) Problem parsing the config file
[  4223.892] (EE) Error parsing the config file
[  4223.892] (EE) 
Fatal server error:
[  4223.892] (EE) no screens found(EE) 
[  4223.892] (EE) 
...
[  4223.892] (EE) 
[  4223.892] (EE) Server terminated with error (1). Closing log file.


man 5 xorg.conf
...
DEVICE SECTION
...
Device sections have the following format:

Section Device
Identifier name
Driver driver
entries
...
EndSection

The *Identifier* *and* *Driver* entries are *required* in all Device sections.
All other entries are optional.

e.g.

/etc/X11/xorg.conf.d/00-modesetting.conf
Section Device
Identifier video0
Driver modesetting
EndSection


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

Re: [Nouveau] [PATCH mesa] nv30: Fix creation of scanout buffers

[poma]

On 12.08.2015 14:24, Hans de Goede wrote:
 Scanout buffers on nv30 must always be non-swizzled and have special
 width alignment constraints.
 
 These constrains have been taken from the xf86-video-nouveau
 src/nv_accel_common.c: nouveau_allocate_surface() function.
 
 nouveau_allocate_surface() applies these width constraints only when a
 tiled attribute is set, which it sets for all surfaces allocated via
 dri, and this tiling is not the same as swizzling, scanout surfaces
 must be linear / have a uniform_pitch or only complete garbage is shown.
 
 This commit fixes dri3 on nv30 showing a garbled display, with dri3 the
 scanout buffers are allocated by mesa, rather then by the ddx, and the
 wrong stride of these buffers was causing the garbled display.
 
 Signed-off-by: Hans de Goede hdego...@redhat.com
 ---
  src/gallium/drivers/nouveau/nv30/nv30_miptree.c | 10 ++
  1 file changed, 10 insertions(+)
 
 diff --git a/src/gallium/drivers/nouveau/nv30/nv30_miptree.c 
 b/src/gallium/drivers/nouveau/nv30/nv30_miptree.c
 index c75b4b9..2276347 100644
 --- a/src/gallium/drivers/nouveau/nv30/nv30_miptree.c
 +++ b/src/gallium/drivers/nouveau/nv30/nv30_miptree.c
 @@ -28,6 +28,7 @@
  #include util/u_surface.h
  
  #include nv_m2mf.xml.h
 +#include nv_object.xml.h
  #include nv30/nv30_screen.h
  #include nv30/nv30_context.h
  #include nv30/nv30_resource.h
 @@ -362,6 +363,7 @@ nv30_miptree_create(struct pipe_screen *pscreen,
 blocksz = util_format_get_blocksize(pt-format);
  
 if ((pt-target == PIPE_TEXTURE_RECT) ||
 +   (pt-bind  PIPE_BIND_SCANOUT) ||
 !util_is_power_of_two(pt-width0) ||
 !util_is_power_of_two(pt-height0) ||
 !util_is_power_of_two(pt-depth0) ||
 @@ -369,6 +371,14 @@ nv30_miptree_create(struct pipe_screen *pscreen,
 util_format_is_float(pt-format) || mt-ms_mode) {
mt-uniform_pitch = util_format_get_nblocksx(pt-format, w) * blocksz;
mt-uniform_pitch = align(mt-uniform_pitch, 64);
 +  if (pt-bind  PIPE_BIND_SCANOUT) {
 + struct nv30_screen *screen = nv30_screen(pscreen);
 + int pitch_align = MAX2(
 +   screen-eng3d-oclass = NV40_3D_CLASS ? 1024 : 256,
 +   /* round_down_pow2(mt-uniform_pitch / 4) */
 +   1  (util_last_bit(mt-uniform_pitch / 4) - 1));
 + mt-uniform_pitch = align(mt-uniform_pitch, pitch_align);
 +  }
 }
  
 if (!mt-uniform_pitch)
 


I patched mesa 10.6.4 with it, did not help to solve
https://bugs.freedesktop.org/show_bug.cgi?id=90871


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

Re: [Nouveau] enable dri3 support without glamor causes gnome-shell regression on nv4x

[poma]

On 03.08.2015 15:02, Hans de Goede wrote:
 Hi,
 
 On 30-07-15 16:09, Ilia Mirkin wrote:
 FWIW this is a fail on nv50+ as well. See for example
 https://bugs.freedesktop.org/show_bug.cgi?id=91445

 My suspicion is that this is due to the lack of PUSH_KICK in the *Done
 exa handlers -- works fine with DRI2, but DRI3 has no synchronization
 and so the commands never get flushed out. Easily verified by sticking
 PUSH_KICK's everywhere.
 
 I do not believe that that is the problem, in my case it clearly
 seems to be a pitch / swizzle problem rather then a synchronizarion
 problem, here is what my desktop with gnome shell looks like when
 using DRI2:
 
 https://fedorapeople.org/~jwrdegoede/nv46-gnome-shell-good.jpg
 
 And this is what it looks like when using DRI3:
 
 https://fedorapeople.org/~jwrdegoede/nv46-gnome-shell-bad.jpg
 

You can tell, just by looking at garbled pattern, what is the actually problem!?


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

Re: [Nouveau] RFC: drop glamor from nouveau ddx

[poma]

On 07.07.2015 23:05, Ben Skeggs wrote:
 On 8 July 2015 at 06:06, Ilia Mirkin imir...@alum.mit.edu wrote:
 Ben,

 Looks like the reality is that glamor is just not hooked up properly
 in the nouveau DDX. Mainly it's missing DRI2, which in turn means no
 core GL contexts, and probably lots of other issues. While this could
 probably be fixed somehow, I doubt there's any advantage to using the
 nouveau DDX over something like modesetting nowadays.

 How would you feel about dropping glamor support from the nouveau ddx
 and failing to load for GPUs that don't have EXA support (unless
 AccelMode = none is forced for them). That way it'll fall back to
 loading modesetting which should be properly set up for DRI2 and so
 on.
 I have no objections to this.  In fact, in Fedora at least (I floated
 the idea in #nouveau a while back too), in the near future I plan on
 having the DDX fail to load on all GPUs where modesetting+glamor can
 be used (unless overridden by a config option).
 

Shouldn't the priority always be what is proven to work.
NV50 works OK with the EXA.
Besides, can it be set color vibrance, vibrant hue and other props via 
modeset?

When people get hit by sunstroke, a real summer has begun.

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

Re: [Nouveau] Handling GeForce GTX 850M GPU on Arch Linux

[poma]

On 18.05.2015 01:46, Ilia Mirkin wrote:
 Your errors are most likely due to:
 
 [2.421428] nouveau  [ PFB][:01:00.0] RAM size: 1975398418 MiB
 
 I'm guessing you don't *actually* have 1.9PB of VRAM. At least one
 other person with a GM108 was seeing a similar issue. You're getting a
 bunch of other failed reads, looks like we're somehow not bringing the
 card up properly. The most immediate fix is to just disable nouveau
 entirely -- boot with nouveau.modeset=0.
 
 Cheers,
 
   -ilia
 


As the IGPs tend to steal system memory:

[   21.733864] nouveau  [ PFB][:01:00.0] RAM type: stolen system memory
[   21.733883] nouveau  [ PFB][:01:00.0] RAM size: 256 MiB
[   21.787222] nouveau  [ DRM] VRAM: 256 MiB

can we reverse the process in this case, and steal a few GB of VRAM for a 
system memory?
I mean there are more than enough.


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

[Nouveau] Nouveau Images - 3D

[poma]

https://nouveau.pmoreau.org

How to test Mesa i.e. hardware-accelerated OpenGL?

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

Re: [Nouveau] Testers needed for NVAA/NVAC kernel patch

[poma]

On 02.12.2014 23:29, Pierre Moreau wrote:
 Hello everyone,
 
 I would need testers to check that this patch doesn't break working
 NVAA/NVAC configurations. It fixes an issue where some NVAC would hang on 
 boot;
 if similar issues exist on NVAA, it may fix them too.
 You will find the patch below in two different versions: one will apply on Ben
 Skeggs' repository, the other one will apply on a regular Linux tree.
 
 Thanks in advance,
 
 Pierre Moreau
 


git://people.freedesktop.org/~darktama/nouveau
commented the following dumb lines  patched with If you are using Ben 
Skeggs' repository

/NV/nouveau/drm/nouveau_gem.c: In function ‘validate_list’:
/NV/nouveau/drm/nouveau_gem.c:447:22: error: ‘struct drm_gem_object’ has no 
member named ‘dumb’
   WARN_ONCE(nvbo-gem.dumb,
  ^
include/asm-generic/bug.h:121:27: note: in definition of macro ‘WARN_ONCE’
  int __ret_warn_once = !!(condition);   \
   ^
/NV/nouveau/drm/nouveau_display.c: In function ‘nouveau_display_dumb_create’:
/NV/nouveau/drm/nouveau_display.c:879:9: error: ‘struct drm_gem_object’ has no 
member named ‘dumb’
  bo-gem.dumb = true;
 ^
/NV/nouveau/drm/nouveau_display.c: In function 
‘nouveau_display_dumb_map_offset’:
/NV/nouveau/drm/nouveau_display.c:900:18: error: ‘struct drm_gem_object’ has no 
member named ‘dumb’
   WARN_ONCE(!(gem-dumb || gem-import_attach),
  ^
include/asm-generic/bug.h:121:27: note: in definition of macro ‘WARN_ONCE’
  int __ret_warn_once = !!(condition);   \
   ^
/NV/nouveau/drm/nouveau_display.c: In function ‘nouveau_display_dumb_create’:
/NV/nouveau/drm/nouveau_display.c:879:9: error: ‘struct drm_gem_object’ has no 
member named ‘dumb’
  bo-gem.dumb = true;
 ^

# dmesg | grep nouveau
[   25.348109] nouveau: module verification failed: signature and/or  required 
key missing - tainting kernel
[   25.392337] fb: switching to nouveaufb from VESA VGA
[   25.410386] nouveau  [  DEVICE][:01:00.0] BOOT0  : 0x0ace80b1
[   25.410408] nouveau  [  DEVICE][:01:00.0] Chipset: MCP79/MCP7A (NVAC)
[   25.410419] nouveau  [  DEVICE][:01:00.0] Family : NV50
[   25.426804] nouveau  [   VBIOS][:01:00.0] using image from PRAMIN
[   25.427343] nouveau  [   VBIOS][:01:00.0] BIT signature found
[   25.427361] nouveau  [   VBIOS][:01:00.0] version 62.79.78.00.00
[   25.450604] nouveau :01:00.0: irq 26 for MSI/MSI-X
[   25.450635] nouveau  [ PMC][:01:00.0] MSI interrupts enabled
[   25.450698] nouveau  [ PFB][:01:00.0] RAM type: stolen system memory
[   25.450710] nouveau  [ PFB][:01:00.0] RAM size: 256 MiB
[   25.450719] nouveau  [ PFB][:01:00.0]ZCOMP: 0 tags
[   25.482512] nouveau  [  PTHERM][:01:00.0] FAN control: none / external
[   25.482581] nouveau  [  PTHERM][:01:00.0] fan management: automatic
[   25.482602] nouveau  [  PTHERM][:01:00.0] internal sensor: yes
[   25.502658] nouveau  [ CLK][:01:00.0] 03: core 200 MHz shader 400 
MHz vdec 200 MHz
[   25.502684] nouveau  [ CLK][:01:00.0] 05: core 300 MHz shader 600 
MHz vdec 300 MHz
[   25.502701] nouveau  [ CLK][:01:00.0] 07: core 350 MHz shader 800 
MHz vdec 350 MHz
[   25.502717] nouveau  [ CLK][:01:00.0] 0f: core 450 MHz shader 1100 
MHz vdec 450 MHz
[   25.502753] nouveau  [ CLK][:01:00.0] --: core 450 MHz shader 1100 
MHz vdec 450 MHz
[   25.503536] nouveau  [ DRM] VRAM: 256 MiB
[   25.503550] nouveau  [ DRM] GART: 1048576 MiB
[   25.503570] nouveau  [ DRM] TMDS table version 2.0
[   25.503584] nouveau  [ DRM] DCB version 4.0
[   25.503599] nouveau  [ DRM] DCB outp 00: 02000300 001e
[   25.503616] nouveau  [ DRM] DCB outp 01: 01011322 0030
[   25.503631] nouveau  [ DRM] DCB outp 02: 02022332 00020010
[   25.503645] nouveau  [ DRM] DCB conn 00: 
[   25.503659] nouveau  [ DRM] DCB conn 01: 1131
[   25.503672] nouveau  [ DRM] DCB conn 02: 2261
[   25.548615] nouveau  [ DRM] MM: using M2MF for buffer copies
[   25.637542] nouveau  [ DRM] allocated 800x600 fb: 0x5, bo 
8800bc6d3c00
[   25.637949] fbcon: nouveaufb (fb0) is primary device
[   25.705760] nouveau :01:00.0: fb0: nouveaufb frame buffer device
[   25.705791] [drm] Initialized nouveau 1.2.1 20120801 for :01:00.0 on 
minor 1

# grep -w connected /var/log/Xorg.0.log
[34.783] (II) NOUVEAU(0): Output HDMI-1 connected

# modinfo nouveau -n
/lib/modules/3.18.0-0.rc7.git0.1.fc22.x86_64/updates/nouveau.ko


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

Re: [Nouveau] demmio

[poma]

On 02.12.2014 14:40, Ilia Mirkin wrote:
 On Tue, Dec 2, 2014 at 8:38 AM, poma pomidorabelis...@gmail.com wrote:
 Is this expected result for Chipset: G98 (NV98)?
 
 Yep, 100% expected. [Perhaps you might glance at the wiki page you got
 that from for clues as to why.]
 

  You basically never need to do the mmiotrace, unless you're a nouveau 
developer.?

I did everything by the book[1].
Though I don't need this, I still wanted to see how it works with 
'nouveau.config=NvGrUseFW=1'.
Bummer.


[1] https://wiki.ubuntu.com/X/MMIOTracing



 $ modinfo nvidia -F version
 304.123

 $ stat -c %s mmiotrace.log
 134659197

 $ file mmiotrace.log
 mmiotrace.log: ASCII text

 $ grep -i lost mmiotrace.log ; echo $?
 1

 $ ./envytools/rnn/demmio -f mmiotrace.log | perl -e 'open($fh409c, 
 fuc409c); open($fh409d, fuc409d); open($fh41ac, fuc41ac); 
 open($fh41ad, fuc41ad);%m = (0x409184 = $fh409c, 0x4091c4 = 
 $fh409d, 0x41a184 = $fh41ac, 0x41a1c4 = $fh41ad);while () { exit if 
 (/0x409840/); next if (!/W (0x4(?:09|1a)1[c8]4) .* = (?:.*0x)?(.*)/); print 
 { $m{$1} } pack I, hex($2);}'
 I don't know which chipset variant to use!
 I don't know which chipset variant to use!
 I don't know which chipset variant to use!
 I don't know which chipset variant to use!
 I don't know which chipset variant to use!
 I don't know which chipset variant to use!
 I don't know which chipset variant to use!
 I don't know which chipset variant to use!
 I don't know which chipset variant to use!
 I don't know which chipset variant to use!
 I don't know which chipset variant to use!
 I don't know which chipset variant to use!
 I don't know which chipset variant to use!
 I don't know which chipset variant to use!
 I don't know which chipset variant to use!

 $ file fuc4*
 fuc409c: empty
 fuc409d: empty
 fuc41ac: empty
 fuc41ad: empty


 Ref.
 http://nouveau.freedesktop.org/wiki/NVC0_Firmware
 ___
 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

Re: [Nouveau] demmio

[poma]

On 02.12.2014 14:52, Ilia Mirkin wrote:
 On Tue, Dec 2, 2014 at 8:50 AM, poma pomidorabelis...@gmail.com wrote:
 On 02.12.2014 14:40, Ilia Mirkin wrote:
 On Tue, Dec 2, 2014 at 8:38 AM, poma pomidorabelis...@gmail.com wrote:
 Is this expected result for Chipset: G98 (NV98)?

 Yep, 100% expected. [Perhaps you might glance at the wiki page you got
 that from for clues as to why.]


   You basically never need to do the mmiotrace, unless you're a nouveau 
 developer.?

 I did everything by the book[1].
 Though I don't need this, I still wanted to see how it works with 
 'nouveau.config=NvGrUseFW=1'.
 Bummer.
 
 You don't just not need it -- you can't possibly use it. Context
 switching firmware of this sort only exists on nvc0+ (fermi and
 newer). As the page you got the instructions from suggests
 (NVC0_Firmware).
 
   -ilia
 

AHA! Maxwell and Maxwell only.
Bummer.



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

Re: [Nouveau] demmio

[poma]

On 02.12.2014 14:59, poma wrote:
 On 02.12.2014 14:52, Ilia Mirkin wrote:
 On Tue, Dec 2, 2014 at 8:50 AM, poma pomidorabelis...@gmail.com wrote:
 On 02.12.2014 14:40, Ilia Mirkin wrote:
 On Tue, Dec 2, 2014 at 8:38 AM, poma pomidorabelis...@gmail.com wrote:
 Is this expected result for Chipset: G98 (NV98)?

 Yep, 100% expected. [Perhaps you might glance at the wiki page you got
 that from for clues as to why.]


   You basically never need to do the mmiotrace, unless you're a nouveau 
 developer.?

 I did everything by the book[1].
 Though I don't need this, I still wanted to see how it works with 
 'nouveau.config=NvGrUseFW=1'.
 Bummer.

 You don't just not need it -- you can't possibly use it. Context
 switching firmware of this sort only exists on nvc0+ (fermi and
 newer). As the page you got the instructions from suggests
 (NVC0_Firmware).

   -ilia

 
 AHA! Maxwell and Maxwell only.
 Bummer.
 

Pardon me,
Fermi, Kepler and Maxwell only.
Bummer^3.


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

[Nouveau] kworker/u16:57: page allocation failure: order:0, mode:0x284000

[poma]

No problemos with x86_64,
however on i686

kworker/u16:57: page allocation failure: order:0, mode:0x284000
CPU: 0 PID: 1425 Comm: kworker/u16:57 Not tainted 
3.18.0-0.rc5.git0.1.fc22.i686+debug #1
Workqueue: events_unbound async_run_entry_fn
Call Trace:
 [c0b2b55a] dump_stack+0x48/0x60
 [c056f3d4] warn_alloc_failed+0xd4/0x110
 [c0571ade] __alloc_pages_nodemask+0x81e/0xc30
 [c04e4b65] ? clockevents_program_event+0x45/0x150
 [c05b81c8] new_slab+0x258/0x3a0
 [c05b9490] __slab_alloc.constprop.55+0x5f0/0x790
 [c0b34636] ? restore_all+0xf/0xf
 [c0755622] ? radix_tree_node_alloc+0x22/0x90
 [c04a9728] ? __lock_is_held+0x48/0x70
 [c05bac55] kmem_cache_alloc+0x295/0x3c0
 [c0755622] ? radix_tree_node_alloc+0x22/0x90
 [c0755622] radix_tree_node_alloc+0x22/0x90
 [c0755e7c] __radix_tree_create+0x6c/0x1c0
 [c0756009] radix_tree_insert+0x39/0xe0
 [c077ae59] add_dma_entry+0x89/0x150
 [c04121b0] ? save_stack_trace+0x30/0x50
 [c077b21d] debug_dma_map_page+0xfd/0x130
 [f83e3578] nouveau_ttm_tt_populate+0x118/0x230 [nouveau]
 [f817de4e] ttm_tt_bind+0x2e/0x60 [ttm]
 [f818016a] ttm_bo_handle_move_mem+0x4ca/0x560 [ttm]
 [f81807fd] ? ttm_bo_mem_space+0x14d/0x310 [ttm]
 [f817eed3] ? ttm_bo_wait+0x113/0x250 [ttm]
 [f81804a3] ttm_mem_evict_first+0x2a3/0x4b0 [ttm]
 [c040c498] ? sched_clock+0x8/0x10
 [f83eb41d] ? nv84_fence_sync+0x3d/0x60 [nouveau]
 [f8180a23] ttm_bo_force_list_clean+0x63/0xb0 [ttm]
 [f8180c1a] ttm_bo_evict_mm+0x2a/0x60 [ttm]
 [f83dd028] nouveau_do_suspend+0x78/0x2d0 [nouveau]
 [f83dd305] nouveau_pmops_freeze+0x15/0x20 [nouveau]
 [c0798bad] pci_pm_freeze+0x4d/0xd0
 [c087566f] dpm_run_callback+0x6f/0x420
 [c0798b60] ? pci_pm_poweroff+0xe0/0xe0
 [c08764d4] __device_suspend+0xf4/0x2d0
 [c08766cf] async_suspend+0x1f/0x90
 [c047d25e] async_run_entry_fn+0x4e/0x170
 [c04a9728] ? __lock_is_held+0x48/0x70
 [c0474076] process_one_work+0x1e6/0x7b0
 [c0473fd1] ? process_one_work+0x141/0x7b0
 [c0474679] worker_thread+0x39/0x440
 [c0474640] ? process_one_work+0x7b0/0x7b0
 [c047999c] kthread+0xbc/0xd0
 [c0b34401] ret_from_kernel_thread+0x21/0x30
 [c04798e0] ? kthread_create_on_node+0x180/0x180
...

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

Re: [Nouveau] Logo Nouveau

[poma]

On 16.11.2014 21:03, valeria aguilera wrote:
 
 
 
 
 
 
 
 
 
 
 Dear community members,
 
 
 Im a graphic designer and for the last couple of months I have been working 
 on a new logo for the Nouveau project. After sending preliminary designs to 
 both Martin Peres and Ilia Mirkin, we have decided to share the logo in order 
 to gather your feedback. 
 
 
 I would like to highlight that the logo incorporates a penguin corresponding 
 to the linux kernel components used to create this open source driver. The 3D 
 cube/shape represents the 2D and 3D acceleration capability. The “n” simply 
 stands for the first letter in Nouveau and the green colour was chosen 
 because the driver is for NVIDIA video cards.
 
 
 Please provide Martin and Ilia with your comments and preferences, since they 
 both have been the ones giving me the design requirements. 
 Valeria Aguilera.   
 

Never ask engineers for design, it will always bring out the cube. :)
We all know Claudia would rather drive a german, but Valeria do you have 
something more fluid designed, something like a una macchina italiana.


poma


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

Re: [Nouveau] [PATCH] nv50/disp: Fix modeset on G94

[poma]

On 31.10.2014 11:28, Roy Spliet wrote:
 
 --- Ursprüngliche Nachricht ---
 Von: Ben Skeggs skeg...@gmail.com
 Datum: 00:52:05 31-10-2014
 An: Ilia Mirkin imir...@alum.mit.edu
 Betreff: Re: [Nouveau] [PATCH] nv50/disp: Fix modeset on G94
 
 On Fri, Oct 31, 2014 at 8:00 AM, Ilia Mirkin imir...@alum.mit.edu
 wrote:
 On Thu, Oct 30, 2014 at 5:57 PM, Roy Spliet rspl...@eclipso.eu
 wrote:
 Commit 1dce6264045cd23e9c07574ed0bb31c7dce9354f introduced a regression
 spotted
 on several G94 (FDObz #85160). This device seems to expect the vblank
 period to

 I believe that's often done as a

 Bugzilla: https://bugs.freedesktop.org/bla

 annotation

 be set after setting scale instead of before.

 V2: shove this in a separate function

 This is a candidate bug-fix for 3.18

 Signed-off-by: Roy Spliet rspl...@eclipso.eu
 Tested-by: Zlatko Calusic zcalu...@bitsync.net
 Tested-by: Michael Riesch mich...@riesch.at
 Tested-by: poma pomidorabelis...@gmail.com
 Tested-by: Adam Williamson ad...@happyassassin.net
 ---
  drivers/gpu/drm/nouveau/nv50_display.c | 26 --

  1 file changed, 24 insertions(+), 2 deletions(-)

 diff --git a/drivers/gpu/drm/nouveau/nv50_display.c 
 b/drivers/gpu/drm/nouveau/nv50_display.c

 index ae873d1..2f24a08 100644
 --- a/drivers/gpu/drm/nouveau/nv50_display.c
 +++ b/drivers/gpu/drm/nouveau/nv50_display.c
 @@ -791,6 +791,23 @@ nv50_crtc_set_scale(struct nouveau_crtc *nv_crtc,
 bool update)
  }

  static int
 +nv50_crtc_set_raster_vblank_dmi(struct nouveau_crtc *nv_crtc, u32
 usec)

 What's dmi?
 SetRasterVertBlankDmi is the name of method 0x828.  I presume it's
 Display Memory Interface or something to that effect.


 +{
 +   struct nv50_mast *mast = nv50_mast(nv_crtc-base.dev);

 +   u32 *push;
 +
 +   push = evo_wait(mast, 8);

 Just needs to be 2, no?
 Yes, doesn't matter too much though.
 If it is, we might need to fix nv50_crtc_mode_set() too; it seems to assume 
 the second parameter in evo_wait() is bytes, not words.
 


 +   if (!push)
 +   return -ENOMEM;
 +
 +   evo_mthd(push, 0x0828 + (nv_crtc-index * 0x400), 1);

 +   evo_data(push, usec);
 +   evo_kick(push, mast);
 +
 +   return 0;
 +}
 +
 +static int
  nv50_crtc_set_color_vibrance(struct nouveau_crtc *nv_crtc, bool
 update)
  {
 struct nv50_mast *mast = nv50_mast(nv_crtc-base.dev);

 @@ -1104,14 +1121,14 @@ nv50_crtc_mode_set(struct drm_crtc *crtc,
 struct drm_display_mode *umode,
 evo_mthd(push, 0x0804 + (nv_crtc-index
 * 0x400), 2);
 evo_data(push, 0x0080 | mode-clock);

 evo_data(push, (ilace == 2) ? 2 : 0);
 -   evo_mthd(push, 0x0810 + (nv_crtc-index
 * 0x400), 8);
 +   evo_mthd(push, 0x0810 + (nv_crtc-index
 * 0x400), 6);
 evo_data(push, 0x);
 evo_data(push, (vactive  16) | hactive);

 evo_data(push, ( vsynce  16) | hsynce);

 evo_data(push, (vblanke  16) | hblanke);

 evo_data(push, (vblanks  16) | hblanks);

 evo_data(push, (vblan2e  16) | vblan2s);

 -   evo_data(push, vblankus);
 +   evo_mthd(push, 0x082c + (nv_crtc-index
 * 0x400), 1);
 evo_data(push, 0x);
 evo_mthd(push, 0x0900 + (nv_crtc-index
 * 0x400), 2);
 evo_data(push, 0x0311);
 @@ -1141,6 +1158,11 @@ nv50_crtc_mode_set(struct drm_crtc *crtc,
 struct drm_display_mode *umode,
 nv_connector = nouveau_crtc_connector_get(nv_crtc);
 nv50_crtc_set_dither(nv_crtc, false);
 nv50_crtc_set_scale(nv_crtc, false);
 +
 +   /* G94 only accepts this after setting scale */
 +   if (nv50_vers(mast)  GF110_DISP_CORE_CHANNEL_DMA)
 +   nv50_crtc_set_raster_vblank_dmi(nv_crtc, vblankus);

 +
 nv50_crtc_set_color_vibrance(nv_crtc, false);
 nv50_crtc_set_image(nv_crtc, crtc-primary-fb, x,
 y, false);
 return 0;
 --
 2.1.0



None of all thisthat patches does not work anymore.


poma

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

Re: [Nouveau] display force off - kernel 3.18

[poma]

linux-next, commit 2d65a9f broke nouveau(display is powered off): 
- boot from soft-off(S5)
- thaw from hibernate(S4)
- resume from suspend(S3)

Chipset: G98 (NV98)
Family : NV50

https://git.kernel.org/cgit/linux/kernel/git/next/linux-next.git/commit/?id=2d65a9f

commit 2d65a9f48fcdf7866aab6457bc707ca233e0c791
Merge: da92da3 dfda0df
Author: Linus Torvalds torva...@linux-foundation.org
Date:   Tue Oct 14 09:39:08 2014 +0200

Merge branch 'drm-next' of git://people.freedesktop.org/~airlied/linux

Pull drm updates from Dave Airlie:
 This is the main git pull for the drm,

  I pretty much froze major pulls at -rc5/6 time, and haven't had much
  fallout, so will probably continue doing that.

  Lots of changes all over, big internal header cleanup to make it clear
  drm features are legacy things and what are things that modern KMS
  drivers should be using.  Also big move to use the new generic fences
  in all the TTM drivers.

  core:
atomic prep work,
vblank rework changes, allows immediate vblank disables
major header reworking and cleanups to better delinate legacy
interfaces from what KMS drivers should be using.
cursor planes locking fixes

  ttm:
move to generic fences (affects all TTM drivers)
ppc64 caching fixes

  radeon:
userptr support,
uvd for old asics,
reset rework for fence changes
better buffer placement changes,
dpm feature enablement
hdmi audio support fixes

  intel:
Cherryview work,
180 degree rotation,
skylake prep work,
execlist command submission
full ppgtt prep work
cursor improvements
edid caching,
vdd handling improvements

  nouveau:
fence reworking
kepler memory clock work
gt21x clock work
fan control improvements
hdmi infoframe fixes
DP audio

  ast:
ppc64 fixes
caching fix

  rcar:
rcar-du DT support

  ipuv3:
prep work for capture support

  msm:
LVDS support for mdp4, new panel, gpu refactoring

  exynos:
exynos3250 SoC support, drop bad mmap interface,
mipi dsi changes, and component match support

* 'drm-next' of git://people.freedesktop.org/~airlied/linux: (640 commits)
  drm/mst: rework payload table allocation to conform better.
  drm/ast: Fix HW cursor image
  drm/radeon/kv: add uvd/vce info to dpm debugfs output
  drm/radeon/ci: add uvd/vce info to dpm debugfs output
  drm/radeon: export reservation_object from dmabuf to ttm
  drm/radeon: cope with foreign fences inside the reservation object
  drm/radeon: cope with foreign fences inside display
  drm/core: use helper to check driver features
  drm/radeon/cik: write gfx ucode version to ucode addr reg
  drm/radeon/si: print full CS when we hit a packet 0
  drm/radeon: remove unecessary includes
  drm/radeon/combios: declare legacy_connector_convert as static
  drm/radeon/atombios: declare connector convert tables as static
  drm/radeon: drop btc_get_max_clock_from_voltage_dependency_table
  drm/radeon/dpm: drop clk/voltage dependency filters for BTC
  drm/radeon/dpm: drop clk/voltage dependency filters for CI
  drm/radeon/dpm: drop clk/voltage dependency filters for SI
  drm/radeon/dpm: drop clk/voltage dependency filters for NI
  drm/radeon: disable audio when we disable hdmi (v2)
  drm/radeon: split audio enable between eg and r600 (v2)
  ...


Up to and with prior commit da92da3 nouveau(S3/4/5) works OK.


poma


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

Re: [Nouveau] display force off - kernel 3.18

[poma]

http://cgit.freedesktop.org/~darktama/nouveau/commit/?id=4d60422
also broken with this commit


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

Re: [Nouveau] VGA resume thaw boot (wake up from S3 S4 boot from S5) broken 3.18

[poma]

- http://cgit.freedesktop.org/~airlied/linux/log/?h=drm-fixes
git clone -b drm-fixes git://people.freedesktop.org/~airlied/linux

- http://cgit.freedesktop.org/~darktama/nouveau/
git://people.freedesktop.org/~darktama/nouveau

./autogen.sh 
cd drm
make
su
mkdir /usr/lib/modules/3.18.0-rc1.git-e800cab-drm-fixes/updates/
cp nouveau.ko /usr/lib/modules/3.18.0-rc1.git-e800cab-drm-fixes/updates/
depmod 

The same situation as before, 
after fb: switching to nouveaufb from VESA VGA, 
display is powered off


Good Night Princess


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

[Nouveau] INFO: task echo:622 blocked for more than 120 seconds. - 3.18.0-0.rc0.git

[poma]

02:00.0 VGA compatible controller: 
NVIDIA Corporation G98 [GeForce 8400 GS Rev. 2] (rev a1)
Chipset: G98 (NV98)
Family : NV50

The same for all four kernel:
- 3.18.0-0.rc0.git8.1.fc22.x86_64
- 3.18.0-0.rc0.git9.1.fc22.x86_64
- 3.18.0-0.rc0.git9.3.fc22.x86_64
- 3.18.0-0.rc0.git9.4.fc22.x86_64
after
fb: switching to nouveaufb from VESA VGA
display is powered off.
The magic SysRq key sequence is necessary to reboot.

Yet reached this this one recital:
...
[5.860996] [drm] Initialized nouveau 1.2.1 20120801 for :02:00.0 on 
minor 0
...
[  240.229058] INFO: task echo:622 blocked for more than 120 seconds.
[  240.229594]   Not tainted 3.18.0-0.rc0.git9.3.fc22.x86_64 #1
[  240.230149] echo 0  /proc/sys/kernel/hung_task_timeout_secs disables this 
message.
[  240.230661] echoD 8800c82a3480 12472   622  1 0x0004
[  240.231230]  8800ca2e3ac8 0096 8800c82a3480 
001d5f00
[  240.231784]  8800ca2e3fd8 001d5f00 880128bf 
8800c82a3480
[  240.232344]  82c30990 7fff 81ee2698 
81ee2690
[  240.232931] Call Trace:
[  240.233467]  [8185baf9] schedule+0x29/0x70
[  240.234025]  [81860d1c] schedule_timeout+0x26c/0x410
[  240.234562]  [81028c4a] ? native_sched_clock+0x2a/0xa0
[  240.235118]  [811078bc] ? mark_held_locks+0x7c/0xb0
[  240.235645]  [81861da0] ? _raw_spin_unlock_irq+0x30/0x50
[  240.236198]  [81107a4d] ? trace_hardirqs_on_caller+0x15d/0x200
[  240.236729]  [8185d52c] wait_for_completion+0x10c/0x150
[  240.237290]  [810e51f0] ? wake_up_state+0x20/0x20
[  240.237842]  [8112a559] _rcu_barrier+0x159/0x200
[  240.238375]  [8112a655] rcu_barrier+0x15/0x20
[  240.238913]  [8171813f] netdev_run_todo+0x6f/0x310
[  240.239449]  [817251ae] rtnl_unlock+0xe/0x10
[  240.23]  [8170ea35] unregister_netdev+0x25/0x30
[  240.240546]  [a00222d2] rtl_remove_one+0x62/0x230 [r8169]
[  240.241104]  [814682cf] pci_device_remove+0x3f/0xc0
[  240.241642]  [8155b34f] __device_release_driver+0x7f/0xf0
[  240.242180]  [8155b3e5] device_release_driver+0x25/0x40
[  240.242712]  [8146234c] pci_stop_bus_device+0x9c/0xb0
[  240.243259]  [8146248e] 
pci_stop_and_remove_bus_device_locked+0x1e/0x40
[  240.243785]  [8146b44c] remove_store+0x7c/0x90
[  240.244321]  [81555f98] dev_attr_store+0x18/0x30
[  240.244858]  [81302789] sysfs_kf_write+0x49/0x60
[  240.245375]  [81301ac9] kernfs_fop_write+0xf9/0x180
[  240.245921]  [8127305a] vfs_write+0xba/0x200
[  240.246439]  [8186379c] ? retint_swapgs+0x13/0x1b
[  240.246978]  [81273bac] SyS_write+0x5c/0xd0
[  240.247491]  [81862b69] system_call_fastpath+0x12/0x17
[  240.248025] 6 locks held by echo/622:
[  240.248532]  #0:  (sb_writers#3){.+.+.+}, at: [81273143] 
vfs_write+0x1a3/0x200
[  240.249104]  #1:  (of-mutex){+.+.+.}, at: [81301a97] 
kernfs_fop_write+0xc7/0x180
[  240.249651]  #2:  (s_active#131){++}, at: [81300ce4] 
kernfs_remove_self+0xf4/0x170
[  240.250229]  #3:  (pci_rescan_remove_lock){+.+.+.}, at: [8145f167] 
pci_lock_rescan_remove+0x17/0x20
[  240.250779]  #4:  (dev-mutex){..}, at: [8155b3dd] 
device_release_driver+0x1d/0x40
[  240.251358]  #5:  (rcu_sched_state.barrier_mutex){+.+...}, at: 
[8112a435] _rcu_barrier+0x35/0x200
[  241.303095] systemd[1]: start request repeated too quickly for 
lightdm.service
[  241.323052] systemd[1]: Unit lightdm.service entered failed state.
[  241.333101] systemd[1]: lightdm.service failed.
[  359.038325] INFO: task kworker/u16:2:81 blocked for more than 120 seconds.
[  359.039475]   Not tainted 3.18.0-0.rc0.git9.3.fc22.x86_64 #1
[  359.040004] echo 0  /proc/sys/kernel/hung_task_timeout_secs disables this 
message.
[  359.040571] kworker/u16:2   D 880128131a40 1089681  2 0x
[  359.041162] Workqueue: netns cleanup_net
[  359.041701]  8801275bba88 0096 880128131a40 
001d5f00
[  359.042280]  8801275bbfd8 001d5f00 880128bf3480 
880128131a40
[  359.042856]  880128131a40 81ee25e8 0246 
880128131a40
[  359.043436] Call Trace:
[  359.043975]  [8185c0a1] schedule_preempt_disabled+0x31/0x80
[  359.044542]  [8185d8f3] mutex_lock_nested+0x183/0x440
[  359.045108]  [8112a435] ? _rcu_barrier+0x35/0x200
[  359.045647]  [81028c4a] ? native_sched_clock+0x2a/0xa0
[  359.046218]  [8112a435] ? _rcu_barrier+0x35/0x200
[  359.046767]  [8185f914] ? __mutex_unlock_slowpath+0xc4/0x1c0
[  359.047333]  [8112a435] _rcu_barrier+0x35/0x200
[  359.047875]  [8112a655] rcu_barrier+0x15/0x20
[  359.048433]  [8171813f] netdev_run_todo+0x6f/0x310
[  359.048969]  [8170cd35] ? rollback_registered_many+0x265/0x2e0
[  359.049528]  

[Nouveau] VGA resume thaw (wake up from S3 S4) broken - reloaded

[poma]

On 20.10.2014 08:13, poma wrote:
 
 02:00.0 VGA compatible controller: 
 NVIDIA Corporation G98 [GeForce 8400 GS Rev. 2] (rev a1)
 Chipset: G98 (NV98)
 Family : NV50
 
 The same for all four kernel:
 - 3.18.0-0.rc0.git8.1.fc22.x86_64
 - 3.18.0-0.rc0.git9.1.fc22.x86_64
 - 3.18.0-0.rc0.git9.3.fc22.x86_64
 - 3.18.0-0.rc0.git9.4.fc22.x86_64
 after
 fb: switching to nouveaufb from VESA VGA
 display is powered off.
 The magic SysRq key sequence is necessary to reboot.
 
...

This is what I've tested so far:
http://cgit.freedesktop.org/~airlied/linux/log/?h=drm-next
git clone -b drm-next git://people.freedesktop.org/~airlied/linux

1. git-e94654e-1st-test-nouveau

2. git-996f5a0-2nd-test-nouveau
   drm/nouveau/core: pass related object into notify constructor
   http://cgit.freedesktop.org/~airlied/linux/commit/?h=drm-nextid=996f5a0

3. git-b38a232-3rd-test-nouveau
   drm/nv50-/disp: add support for completion events
   http://cgit.freedesktop.org/~airlied/linux/commit/?h=drm-nextid=b38a232

4. git-dfda0df-4th-test-nouveau
   The Last of the Mohicans

Unlike the above mentioned Fedora kernels, all four drm-next kernels have no 
problemos with booting from soft-off(S5).
However The Last of the Mohicans has broken resume from 
suspend(S3)/hibernate(S4).
This has been seen recently.


poma

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

Re: [Nouveau] VGA resume thaw (wake up from S3 S4) broken - reloaded Fedora kernels 3.18 boot from soft-off(S5) broken

[poma]

On 20.10.2014 21:30, poma wrote:
 On 20.10.2014 08:13, poma wrote:

 02:00.0 VGA compatible controller: 
 NVIDIA Corporation G98 [GeForce 8400 GS Rev. 2] (rev a1)
 Chipset: G98 (NV98)
 Family : NV50

 The same for all four kernel:
 - 3.18.0-0.rc0.git8.1.fc22.x86_64
 - 3.18.0-0.rc0.git9.1.fc22.x86_64
 - 3.18.0-0.rc0.git9.3.fc22.x86_64
 - 3.18.0-0.rc0.git9.4.fc22.x86_64
 after
 fb: switching to nouveaufb from VESA VGA
 display is powered off.
 The magic SysRq key sequence is necessary to reboot.

 ...
 
 This is what I've tested so far:
 http://cgit.freedesktop.org/~airlied/linux/log/?h=drm-next
 git clone -b drm-next git://people.freedesktop.org/~airlied/linux
 
 1. git-e94654e-1st-test-nouveau
 
 2. git-996f5a0-2nd-test-nouveau
drm/nouveau/core: pass related object into notify constructor
http://cgit.freedesktop.org/~airlied/linux/commit/?h=drm-nextid=996f5a0
 
 3. git-b38a232-3rd-test-nouveau
drm/nv50-/disp: add support for completion events
http://cgit.freedesktop.org/~airlied/linux/commit/?h=drm-nextid=b38a232
 
 4. git-dfda0df-4th-test-nouveau
The Last of the Mohicans
 
 Unlike the above mentioned Fedora kernels, all four drm-next kernels have no 
 problemos with booting from soft-off(S5).
 However The Last of the Mohicans has broken resume from 
 suspend(S3)/hibernate(S4).
 This has been seen recently.
 

Summa summarum

With the above mentioned drm-next kernels at least works boot from soft-off(S5).
However broken are resume from suspend(S3)  hibernate(S4).

The above mentioned Fedora kernels including 3.18.0-0.rc1.git0.1.fc22.x86_64, 
based on linux-next  derivatives, all broke boot from soft-off(S5) - after 
fb: switching to nouveaufb from VESA VGA you can only get WhoTF turned out 
the lights!
What the circus.

What is the best, I've compared the last working kernel and first broken, guess 
what, no diff within gpu/drm/nouveau/ branch.


BTW
(kernel_hibernate) Hibernation issue tracker bug
https://bugzilla.redhat.com/show_bug.cgi?id=781749

Are you really such opportunists?


poma

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

Re: [Nouveau] VGA resume thaw (wake up from S3 S4) broken - reloaded Fedora kernels 3.18 boot from soft-off(S5) broken

[poma]

On 21.10.2014 02:23, poma wrote:
 On 20.10.2014 21:30, poma wrote:
 On 20.10.2014 08:13, poma wrote:

 02:00.0 VGA compatible controller: 
 NVIDIA Corporation G98 [GeForce 8400 GS Rev. 2] (rev a1)
 Chipset: G98 (NV98)
 Family : NV50

 The same for all four kernel:
 - 3.18.0-0.rc0.git8.1.fc22.x86_64
 - 3.18.0-0.rc0.git9.1.fc22.x86_64
 - 3.18.0-0.rc0.git9.3.fc22.x86_64
 - 3.18.0-0.rc0.git9.4.fc22.x86_64
 after
 fb: switching to nouveaufb from VESA VGA
 display is powered off.
 The magic SysRq key sequence is necessary to reboot.

 ...

 This is what I've tested so far:
 http://cgit.freedesktop.org/~airlied/linux/log/?h=drm-next
 git clone -b drm-next git://people.freedesktop.org/~airlied/linux

 1. git-e94654e-1st-test-nouveau

 2. git-996f5a0-2nd-test-nouveau
drm/nouveau/core: pass related object into notify constructor
http://cgit.freedesktop.org/~airlied/linux/commit/?h=drm-nextid=996f5a0

 3. git-b38a232-3rd-test-nouveau
drm/nv50-/disp: add support for completion events
http://cgit.freedesktop.org/~airlied/linux/commit/?h=drm-nextid=b38a232

 4. git-dfda0df-4th-test-nouveau
The Last of the Mohicans

 Unlike the above mentioned Fedora kernels, all four drm-next kernels have no 
 problemos with booting from soft-off(S5).
 However The Last of the Mohicans has broken resume from 
 suspend(S3)/hibernate(S4).
 This has been seen recently.

 
 Summa summarum
 
 With the above mentioned drm-next kernels at least works boot from 
 soft-off(S5).
 However broken are resume from suspend(S3)  hibernate(S4).
 
 The above mentioned Fedora kernels including 3.18.0-0.rc1.git0.1.fc22.x86_64, 
 based on linux-next  derivatives, all broke boot from soft-off(S5) - after 
 fb: switching to nouveaufb from VESA VGA you can only get WhoTF turned out 
 the lights!
 What the circus.
 
 What is the best, I've compared the last working kernel and first broken, 
 guess what, no diff within gpu/drm/nouveau/ branch.
 

Oh yeah!
With 3.18.0-0.rc1.git0.1.fc22.x86_64 even the magic SysRq key sequence is 
broken. :)

Vorsprung durch technik


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

Re: [Nouveau] VGA resume thaw (wake up from S3 S4) - resolved

[poma]

3.17.0-0.rc7.git0.2.fc21.x86_64  PASSED
  i.e.
3.17.0-0.rc7.git0.1.fc22.x86_64
  patched with 
  disp/nv50: fix dpms regression on certain boards
  http://cgit.freedesktop.org/~darktama/nouveau/commit/?id=a68e953


poma

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

Re: [Nouveau] VGA resume thaw (wake up from S3 S4) broken - kernel(nouveau) exclusively

[poma]

On 14.09.2014 11:53, Roy Spliet wrote:
 Op 14-09-14 om 10:31 schreef poma:
 On 13.09.2014 23:45, Roy Spliet wrote:
 Dear Poma,

 Don't get anyone wrong, your input is greatly valued. The reason why
 we (nouveau developers) generally ask for a git bisection is because
 we don't know or track specific distributions. Although your search has
 narrowed the problem down (thanks for that!), we don't know how big the
 difference is between kernel-3.16.0-0.rc0.git9.1.fc21 and
 kernel-3.16.0-0.rc0.git10.1.fc21. Is the difference literally just that
 one patch? Or were there more patches to nouveau or drm that might have
 been the culprit? So far I haven't succeeded in finding the exact
 differences between the two kernels. Git bisect on the upstream kernel
 on the other hand will always point at the precise patch that broke the
 kernel, narrowing down the search space of the bug for developers thus
 reducing the time it takes to fix your issue. Unless developers can
 reproduce your issue, Unfortunately the user is the person who has to do
 the bisecting.
 So in short: narrowing down the search space often saves a lot of time
 of the developer, reducing the time it takes to fix your issue!
 Thus, if you can find the time to perform a git bisect (with the right
 good/bad markers it really should not take that many kernels to build),
 or if you can validate that the patch you mention *really* is the only
 difference between the two kernels, it'd be greatly appreciated.
 Thanks! Yours,

 Roy

 Are you saying Fedora kernels aren't valid for testing purposes!?
 No, that's not what I'm saying. You used a Fedora kernel which is fairly 
 recent and found a bug. However, they're less useful for pinpointing 
 your problem to  the offending bit of code, as you demonstrate below.
 Madre mía!
 Salud...

 Moreover, this regression is not just for my device.
 Apart from Ben, in Red Fedora there are several skilled kernel developers.
 Why they do not help!?
 Everything is on the user's back, really?


 WORKING VIDEO RESUME/THAW KERNEL:

 $ ls -1 kernel-3.16.0-0.rc0.git9.1.fc21.src/*.xz
 kernel-3.16.0-0.rc0.git9.1.fc21.src/linux-3.15.tar.xz
 kernel-3.16.0-0.rc0.git9.1.fc21.src/patch-3.15-git9.xz

 $ xzgrep -P '(?=.*^diff)(?=.*nouveau)' 
 kernel-3.16.0-0.rc0.git9.1.fc21.src/patch-3.15-git9.xz
 diff --git a/drivers/gpu/drm/nouveau/nouveau_backlight.c 
 b/drivers/gpu/drm/nouveau/nouveau_backlight.c

 $ grep nouveau kernel-3.16.0-0.rc0.git9.1.fc21.src/*.patch
 kernel-3.16.0-0.rc0.git9.1.fc21.src/acpi-video-Add-use-native-backlight-quirk-for-the-Th.patch:nouveau:
  Don't check acpi_video_backlight_support() before registering backlight

 ~~~

 BROKEN VIDEO RESUME/THAW KERNEL:

 $ ls -1 kernel-3.16.0-0.rc0.git10.1.fc21.src/*.xz
 kernel-3.16.0-0.rc0.git10.1.fc21.src/linux-3.15.tar.xz
 kernel-3.16.0-0.rc0.git10.1.fc21.src/patch-3.15-git10.xz

 $ xzgrep -P '(?=.*^diff)(?=.*nouveau)' 
 kernel-3.16.0-0.rc0.git10.1.fc21.src/patch-3.15-git10.xz
 diff --git a/drivers/gpu/drm/nouveau/Makefile 
 b/drivers/gpu/drm/nouveau/Makefile
 diff --git a/drivers/gpu/drm/nouveau/core/core/event.c 
 b/drivers/gpu/drm/nouveau/core/core/event.c
 diff --git a/drivers/gpu/drm/nouveau/core/core/object.c 
 b/drivers/gpu/drm/nouveau/core/core/object.c
 diff --git a/drivers/gpu/drm/nouveau/core/engine/device/gm100.c 
 b/drivers/gpu/drm/nouveau/core/engine/device/gm100.c
 diff --git a/drivers/gpu/drm/nouveau/core/engine/device/nv04.c 
 b/drivers/gpu/drm/nouveau/core/engine/device/nv04.c
 diff --git a/drivers/gpu/drm/nouveau/core/engine/device/nv10.c 
 b/drivers/gpu/drm/nouveau/core/engine/device/nv10.c
 diff --git a/drivers/gpu/drm/nouveau/core/engine/device/nv20.c 
 b/drivers/gpu/drm/nouveau/core/engine/device/nv20.c
 diff --git a/drivers/gpu/drm/nouveau/core/engine/device/nv30.c 
 b/drivers/gpu/drm/nouveau/core/engine/device/nv30.c
 diff --git a/drivers/gpu/drm/nouveau/core/engine/device/nv40.c 
 b/drivers/gpu/drm/nouveau/core/engine/device/nv40.c
 diff --git a/drivers/gpu/drm/nouveau/core/engine/device/nv50.c 
 b/drivers/gpu/drm/nouveau/core/engine/device/nv50.c
 diff --git a/drivers/gpu/drm/nouveau/core/engine/device/nvc0.c 
 b/drivers/gpu/drm/nouveau/core/engine/device/nvc0.c
 diff --git a/drivers/gpu/drm/nouveau/core/engine/device/nve0.c 
 b/drivers/gpu/drm/nouveau/core/engine/device/nve0.c
 diff --git a/drivers/gpu/drm/nouveau/core/engine/disp/base.c 
 b/drivers/gpu/drm/nouveau/core/engine/disp/base.c
 diff --git a/drivers/gpu/drm/nouveau/core/engine/disp/conn.c 
 b/drivers/gpu/drm/nouveau/core/engine/disp/conn.c
 diff --git a/drivers/gpu/drm/nouveau/core/engine/disp/conn.h 
 b/drivers/gpu/drm/nouveau/core/engine/disp/conn.h
 diff --git a/drivers/gpu/drm/nouveau/core/engine/disp/dport.c 
 b/drivers/gpu/drm/nouveau/core/engine/disp/dport.c
 diff --git a/drivers/gpu/drm/nouveau/core/engine/disp/dport.h 
 b/drivers/gpu/drm/nouveau/core/engine/disp/dport.h
 diff --git a/drivers/gpu/drm/nouveau/core/engine/disp/gm107.c 
 b/drivers/gpu/drm

Re: [Nouveau] VGA resume thaw (wake up from S3 S4) broken - kernel(nouveau) exclusively

[poma]

On 15.09.2014 15:36, Ilia Mirkin wrote:
 On Mon, Sep 15, 2014 at 4:23 AM, poma pomidorabelis...@gmail.com wrote:
 Chipset: G98 (NV98)
 Family : NV50


 WORKING VIDEO RESUME(S3)

 3.15.0-rc8.1.git.7a014a8
 3.15.0-rc8.2.git.456b057
 3.15.0-rc8.3.git.b8407c9
 3.15.0-rc8.4.git.bb7ef1e

 

 BROKEN VIDEO RESUME(S3)

 STARTING WITH:
 3.15.0-rc8.5.git.415f12e

 commit 415f12efc1b2308411b2cbc3e82666b3db8a7758
 Author: Ben Skeggs bske...@redhat.com
 Date:   Wed May 21 11:24:43 2014 +1000

 drm/nv50/disp: start removing direct vbios parsing from supervisor

 Signed-off-by: Ben Skeggs bske...@redhat.com

 https://git.kernel.org/cgit/linux/kernel/git/next/linux-next.git/commit/drivers/gpu/drm/nouveau/core/engine/disp/nv50.c?id=415f12e
 https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/drivers/gpu/drm/nouveau/core/engine/disp/nv50.c?id=415f12e
 
 Looks like the same issue as reported in
 
 https://bugs.freedesktop.org/show_bug.cgi?id=83550
 
 Ben, any ideas? Poma, can you attach your vbios to the bug above?
 
   -ilia
 

A Video BIOS dumped.


poma


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

Re: [Nouveau] VGA resume thaw (wake up from S3 S4) broken - kernel(nouveau) exclusively

[poma]

On 16.09.2014 01:21, Ilia Mirkin wrote:
 On Mon, Sep 15, 2014 at 1:28 PM, poma pomidorabelis...@gmail.com wrote:
 On 15.09.2014 15:36, Ilia Mirkin wrote:
 On Mon, Sep 15, 2014 at 4:23 AM, poma pomidorabelis...@gmail.com wrote:
 Chipset: G98 (NV98)
 Family : NV50


 WORKING VIDEO RESUME(S3)

 3.15.0-rc8.1.git.7a014a8
 3.15.0-rc8.2.git.456b057
 3.15.0-rc8.3.git.b8407c9
 3.15.0-rc8.4.git.bb7ef1e

 

 BROKEN VIDEO RESUME(S3)

 STARTING WITH:
 3.15.0-rc8.5.git.415f12e

 commit 415f12efc1b2308411b2cbc3e82666b3db8a7758
 Author: Ben Skeggs bske...@redhat.com
 Date:   Wed May 21 11:24:43 2014 +1000

 drm/nv50/disp: start removing direct vbios parsing from supervisor

 Signed-off-by: Ben Skeggs bske...@redhat.com

 https://git.kernel.org/cgit/linux/kernel/git/next/linux-next.git/commit/drivers/gpu/drm/nouveau/core/engine/disp/nv50.c?id=415f12e
 https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/drivers/gpu/drm/nouveau/core/engine/disp/nv50.c?id=415f12e

 Looks like the same issue as reported in

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

 Ben, any ideas? Poma, can you attach your vbios to the bug above?

   -ilia


 A Video BIOS dumped.
 
 Thanks! If possible, please provide kernel logs (which include the
 initial boot and the resume) for both 415f12efc1 and 415f12efc1^ (i.e.
 parent commit). Please boot those kernels with
 'nouveau.debug=trace,PDISP=spam' so that we get the maximal debug
 info. In order for that to work, you'll need to change
 CONFIG_NOUVEAU_DEBUG to 7 (spam). [Don't use such kernels for anything
 other than debugging, setting the debug level so high adds a ton of
 code and will slow things down significantly.]
 
   -ilia
 

In 415f12e proximity no kernel is useful, resumed machine is stuck.
The display remains OFF meaning everything else works(likely to Daredevil), 
only applies to recent kernels.


poma


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

Re: [Nouveau] VGA resume thaw (wake up from S3 S4) broken - kernel(nouveau) exclusively

[poma]

On 13.09.2014 23:45, Roy Spliet wrote:
 Dear Poma,
 
 Don't get anyone wrong, your input is greatly valued. The reason why 
 we (nouveau developers) generally ask for a git bisection is because 
 we don't know or track specific distributions. Although your search has 
 narrowed the problem down (thanks for that!), we don't know how big the 
 difference is between kernel-3.16.0-0.rc0.git9.1.fc21 and 
 kernel-3.16.0-0.rc0.git10.1.fc21. Is the difference literally just that 
 one patch? Or were there more patches to nouveau or drm that might have 
 been the culprit? So far I haven't succeeded in finding the exact 
 differences between the two kernels. Git bisect on the upstream kernel 
 on the other hand will always point at the precise patch that broke the 
 kernel, narrowing down the search space of the bug for developers thus 
 reducing the time it takes to fix your issue. Unless developers can 
 reproduce your issue, Unfortunately the user is the person who has to do 
 the bisecting.
 So in short: narrowing down the search space often saves a lot of time 
 of the developer, reducing the time it takes to fix your issue!
 Thus, if you can find the time to perform a git bisect (with the right 
 good/bad markers it really should not take that many kernels to build), 
 or if you can validate that the patch you mention *really* is the only 
 difference between the two kernels, it'd be greatly appreciated.
 Thanks! Yours,
 
 Roy
 

Are you saying Fedora kernels aren't valid for testing purposes!?
Madre mía!

Moreover, this regression is not just for my device.
Apart from Ben, in Red Fedora there are several skilled kernel developers.
Why they do not help!?
Everything is on the user's back, really?


WORKING VIDEO RESUME/THAW KERNEL:

$ ls -1 kernel-3.16.0-0.rc0.git9.1.fc21.src/*.xz 
kernel-3.16.0-0.rc0.git9.1.fc21.src/linux-3.15.tar.xz
kernel-3.16.0-0.rc0.git9.1.fc21.src/patch-3.15-git9.xz

$ xzgrep -P '(?=.*^diff)(?=.*nouveau)' 
kernel-3.16.0-0.rc0.git9.1.fc21.src/patch-3.15-git9.xz
diff --git a/drivers/gpu/drm/nouveau/nouveau_backlight.c 
b/drivers/gpu/drm/nouveau/nouveau_backlight.c

$ grep nouveau kernel-3.16.0-0.rc0.git9.1.fc21.src/*.patch
kernel-3.16.0-0.rc0.git9.1.fc21.src/acpi-video-Add-use-native-backlight-quirk-for-the-Th.patch:nouveau:
 Don't check acpi_video_backlight_support() before registering backlight

~~~

BROKEN VIDEO RESUME/THAW KERNEL:

$ ls -1 kernel-3.16.0-0.rc0.git10.1.fc21.src/*.xz 
kernel-3.16.0-0.rc0.git10.1.fc21.src/linux-3.15.tar.xz
kernel-3.16.0-0.rc0.git10.1.fc21.src/patch-3.15-git10.xz

$ xzgrep -P '(?=.*^diff)(?=.*nouveau)' 
kernel-3.16.0-0.rc0.git10.1.fc21.src/patch-3.15-git10.xz
diff --git a/drivers/gpu/drm/nouveau/Makefile b/drivers/gpu/drm/nouveau/Makefile
diff --git a/drivers/gpu/drm/nouveau/core/core/event.c 
b/drivers/gpu/drm/nouveau/core/core/event.c
diff --git a/drivers/gpu/drm/nouveau/core/core/object.c 
b/drivers/gpu/drm/nouveau/core/core/object.c
diff --git a/drivers/gpu/drm/nouveau/core/engine/device/gm100.c 
b/drivers/gpu/drm/nouveau/core/engine/device/gm100.c
diff --git a/drivers/gpu/drm/nouveau/core/engine/device/nv04.c 
b/drivers/gpu/drm/nouveau/core/engine/device/nv04.c
diff --git a/drivers/gpu/drm/nouveau/core/engine/device/nv10.c 
b/drivers/gpu/drm/nouveau/core/engine/device/nv10.c
diff --git a/drivers/gpu/drm/nouveau/core/engine/device/nv20.c 
b/drivers/gpu/drm/nouveau/core/engine/device/nv20.c
diff --git a/drivers/gpu/drm/nouveau/core/engine/device/nv30.c 
b/drivers/gpu/drm/nouveau/core/engine/device/nv30.c
diff --git a/drivers/gpu/drm/nouveau/core/engine/device/nv40.c 
b/drivers/gpu/drm/nouveau/core/engine/device/nv40.c
diff --git a/drivers/gpu/drm/nouveau/core/engine/device/nv50.c 
b/drivers/gpu/drm/nouveau/core/engine/device/nv50.c
diff --git a/drivers/gpu/drm/nouveau/core/engine/device/nvc0.c 
b/drivers/gpu/drm/nouveau/core/engine/device/nvc0.c
diff --git a/drivers/gpu/drm/nouveau/core/engine/device/nve0.c 
b/drivers/gpu/drm/nouveau/core/engine/device/nve0.c
diff --git a/drivers/gpu/drm/nouveau/core/engine/disp/base.c 
b/drivers/gpu/drm/nouveau/core/engine/disp/base.c
diff --git a/drivers/gpu/drm/nouveau/core/engine/disp/conn.c 
b/drivers/gpu/drm/nouveau/core/engine/disp/conn.c
diff --git a/drivers/gpu/drm/nouveau/core/engine/disp/conn.h 
b/drivers/gpu/drm/nouveau/core/engine/disp/conn.h
diff --git a/drivers/gpu/drm/nouveau/core/engine/disp/dport.c 
b/drivers/gpu/drm/nouveau/core/engine/disp/dport.c
diff --git a/drivers/gpu/drm/nouveau/core/engine/disp/dport.h 
b/drivers/gpu/drm/nouveau/core/engine/disp/dport.h
diff --git a/drivers/gpu/drm/nouveau/core/engine/disp/gm107.c 
b/drivers/gpu/drm/nouveau/core/engine/disp/gm107.c
diff --git a/drivers/gpu/drm/nouveau/core/engine/disp/nv04.c 
b/drivers/gpu/drm/nouveau/core/engine/disp/nv04.c
diff --git a/drivers/gpu/drm/nouveau/core/engine/disp/nv50.c 
b/drivers/gpu/drm/nouveau/core/engine/disp/nv50.c
diff --git a/drivers/gpu/drm/nouveau/core/engine/disp/nv50.h 
b/drivers/gpu/drm

Re: [Nouveau] VGA resume thaw (wake up from S3 S4) broken - kernel(nouveau) exclusively

[poma]

On 13.09.2014 07:02, poma wrote:
 On 13.09.2014 06:57, poma wrote:

 Actually I have nothing to show cause logs are all OK.
 Haha, it seems to me that the bugs become intelligent.

 3.15.10-201.fc20.x86_64
 3.16.2-200.fc20.x86_64
 3.17.0-0.rc4.git3.2.fc22.1.x86_64
  nouveau  [ DRM] suspending display...
  nouveau  [ DRM] unpinning framebuffer(s)...
  nouveau  [ DRM] evicting buffers...
  nouveau  [ DRM] waiting for kernel channels to go idle...
  nouveau  [ DRM] suspending client object trees...
  nouveau  [ DRM] suspending kernel object tree...
 ...
  nouveau  [ DRM] re-enabling device...
  nouveau  [ DRM] resuming kernel object tree...
  nouveau  [   VBIOS][:02:00.0] running init tables
  nouveau  [  PTHERM][:02:00.0] fan management: automatic
  nouveau  [ CLK][:02:00.0] --: core 566 MHz shader 1400 MHz memory 
 399 MHz
  nouveau  [ DRM] resuming client object trees...
  nouveau  [ DRM] resuming display...
  nouveau :02:00.0: no hotplug settings from platform
  nouveau :02:00.0: no hotplug settings from platform

 Logs(dmesg) are literally identical.

 3.15.10-201.fc20.x86_64 - nouveau(fb) resume  thaw PASSED, and that's all 
 what works.
 Kernels = 3.16 - nouveau(fb) resume  thaw BROKEN
 ALL Kernels - vesa(fb)resume  thaw BROKEN.


 
 Excusez-moi, 
 BROKEN == The display remains OFF.
 

More precisely stated it looks like this:

- Last kernel with working resume/thaw
  http://koji.fedoraproject.org/koji/buildinfo?buildID=538208
  kernel-3.16.0-0.rc0.git9.1.fc21
  2014-06-13

- First kernel with broken resume/thaw
  kernel-3.16.0-0.rc0.git10.1.fc21
  http://koji.fedoraproject.org/koji/buildinfo?buildID=538244
  
http://pkgs.fedoraproject.org/repo/pkgs/kernel/patch-3.15-git10.xz/f98fb42e79c966f8e139e27b61d933e0/patch-3.15-git10.xz
  2014-06-13

The only difference in dmesg between working and broken kernel module with 
drm.debug=14 is
 [drm:drm_helper_hpd_irq_event] [CONNECTOR:18:DVI-I-1] status updated from 
connected to connected
 [drm:drm_helper_hpd_irq_event] [CONNECTOR:18:DVI-I-1] status updated from 
connected to connected

- git commit probably introduced breakage
  drm/nouveau/disp: add internal representaion of output paths and connectors
  
https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/drivers/gpu/drm?id=7a014a
  
https://git.kernel.org/cgit/linux/kernel/git/next/linux-next.git/commit/drivers/gpu/drm/nouveau?id=7a014a
  2014-06-11

- Ref. fdbs
  Video failed on resume from suspend
  https://bugs.freedesktop.org/show_bug.cgi?id=77599
  https://bugs.freedesktop.org/show_bug.cgi?id=80506


poma

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

Re: [Nouveau] VGA resume thaw (wake up from S3 S4) broken - kernel(nouveau) exclusively

[poma]

On 13.09.2014 22:58, Ilia Mirkin wrote:
 On Sat, Sep 13, 2014 at 4:52 PM, poma pomidorabelis...@gmail.com wrote:
 On 13.09.2014 07:02, poma wrote:
 On 13.09.2014 06:57, poma wrote:

 Actually I have nothing to show cause logs are all OK.
 Haha, it seems to me that the bugs become intelligent.

 3.15.10-201.fc20.x86_64
 3.16.2-200.fc20.x86_64
 3.17.0-0.rc4.git3.2.fc22.1.x86_64
  nouveau  [ DRM] suspending display...
  nouveau  [ DRM] unpinning framebuffer(s)...
  nouveau  [ DRM] evicting buffers...
  nouveau  [ DRM] waiting for kernel channels to go idle...
  nouveau  [ DRM] suspending client object trees...
  nouveau  [ DRM] suspending kernel object tree...
 ...
  nouveau  [ DRM] re-enabling device...
  nouveau  [ DRM] resuming kernel object tree...
  nouveau  [   VBIOS][:02:00.0] running init tables
  nouveau  [  PTHERM][:02:00.0] fan management: automatic
  nouveau  [ CLK][:02:00.0] --: core 566 MHz shader 1400 MHz memory 
 399 MHz
  nouveau  [ DRM] resuming client object trees...
  nouveau  [ DRM] resuming display...
  nouveau :02:00.0: no hotplug settings from platform
  nouveau :02:00.0: no hotplug settings from platform

 Logs(dmesg) are literally identical.

 3.15.10-201.fc20.x86_64 - nouveau(fb) resume  thaw PASSED, and that's all 
 what works.
 Kernels = 3.16 - nouveau(fb) resume  thaw BROKEN
 ALL Kernels - vesa(fb)resume  thaw BROKEN.



 Excusez-moi,
 BROKEN == The display remains OFF.


 More precisely stated it looks like this:

 - Last kernel with working resume/thaw
   http://koji.fedoraproject.org/koji/buildinfo?buildID=538208
   kernel-3.16.0-0.rc0.git9.1.fc21
   2014-06-13

 - First kernel with broken resume/thaw
   kernel-3.16.0-0.rc0.git10.1.fc21
   http://koji.fedoraproject.org/koji/buildinfo?buildID=538244
   
 http://pkgs.fedoraproject.org/repo/pkgs/kernel/patch-3.15-git10.xz/f98fb42e79c966f8e139e27b61d933e0/patch-3.15-git10.xz
   2014-06-13

 The only difference in dmesg between working and broken kernel module with 
 drm.debug=14 is
  [drm:drm_helper_hpd_irq_event] [CONNECTOR:18:DVI-I-1] status updated from 
 connected to connected
  [drm:drm_helper_hpd_irq_event] [CONNECTOR:18:DVI-I-1] status updated from 
 connected to connected

 - git commit probably introduced breakage
   drm/nouveau/disp: add internal representaion of output paths and connectors
   
 https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/drivers/gpu/drm?id=7a014a
   
 https://git.kernel.org/cgit/linux/kernel/git/next/linux-next.git/commit/drivers/gpu/drm/nouveau?id=7a014a
   2014-06-11
 
 Do you have any special reason to believe this to be the culprit
 (besides the fact that it has something to do with hpd)? Can you do an
 actual bisect to confirm?
 
 Thanks,
 
   -ilia

hpd what?
First Fedora Kernel with broken video resume/thaw aka FFKWBVRT i.e. 
kernel-3.16.0-0.rc0.git10.1.fc21 
comes with 'patch-3.15-git10.xz' which closely resembles 
git/commit/drivers/gpu/drm/nouveau?id=7a014a.
Simple as that. 
Why are you asking me that bisect formality, man is it not enough that I tested 
two dozen kernels.


poma


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

Re: [Nouveau] VGA resume thaw (wake up from S3 S4) broken - kernel(nouveau) exclusively

[poma]

On 13.09.2014 23:46, Ilia Mirkin wrote:
 On Sat, Sep 13, 2014 at 5:25 PM, poma pomidorabelis...@gmail.com wrote:
 On 13.09.2014 22:58, Ilia Mirkin wrote:
 On Sat, Sep 13, 2014 at 4:52 PM, poma pomidorabelis...@gmail.com wrote:
 On 13.09.2014 07:02, poma wrote:
 On 13.09.2014 06:57, poma wrote:

 Actually I have nothing to show cause logs are all OK.
 Haha, it seems to me that the bugs become intelligent.

 3.15.10-201.fc20.x86_64
 3.16.2-200.fc20.x86_64
 3.17.0-0.rc4.git3.2.fc22.1.x86_64
  nouveau  [ DRM] suspending display...
  nouveau  [ DRM] unpinning framebuffer(s)...
  nouveau  [ DRM] evicting buffers...
  nouveau  [ DRM] waiting for kernel channels to go idle...
  nouveau  [ DRM] suspending client object trees...
  nouveau  [ DRM] suspending kernel object tree...
 ...
  nouveau  [ DRM] re-enabling device...
  nouveau  [ DRM] resuming kernel object tree...
  nouveau  [   VBIOS][:02:00.0] running init tables
  nouveau  [  PTHERM][:02:00.0] fan management: automatic
  nouveau  [ CLK][:02:00.0] --: core 566 MHz shader 1400 MHz 
 memory 399 MHz
  nouveau  [ DRM] resuming client object trees...
  nouveau  [ DRM] resuming display...
  nouveau :02:00.0: no hotplug settings from platform
  nouveau :02:00.0: no hotplug settings from platform

 Logs(dmesg) are literally identical.

 3.15.10-201.fc20.x86_64 - nouveau(fb) resume  thaw PASSED, and that's 
 all what works.
 Kernels = 3.16 - nouveau(fb) resume  thaw BROKEN
 ALL Kernels - vesa(fb)resume  thaw BROKEN.



 Excusez-moi,
 BROKEN == The display remains OFF.


 More precisely stated it looks like this:

 - Last kernel with working resume/thaw
   http://koji.fedoraproject.org/koji/buildinfo?buildID=538208
   kernel-3.16.0-0.rc0.git9.1.fc21
   2014-06-13

 - First kernel with broken resume/thaw
   kernel-3.16.0-0.rc0.git10.1.fc21
   http://koji.fedoraproject.org/koji/buildinfo?buildID=538244
   
 http://pkgs.fedoraproject.org/repo/pkgs/kernel/patch-3.15-git10.xz/f98fb42e79c966f8e139e27b61d933e0/patch-3.15-git10.xz
   2014-06-13

 The only difference in dmesg between working and broken kernel module with 
 drm.debug=14 is
  [drm:drm_helper_hpd_irq_event] [CONNECTOR:18:DVI-I-1] status updated from 
 connected to connected
  [drm:drm_helper_hpd_irq_event] [CONNECTOR:18:DVI-I-1] status updated from 
 connected to connected

 - git commit probably introduced breakage
   drm/nouveau/disp: add internal representaion of output paths and 
 connectors
   
 https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/drivers/gpu/drm?id=7a014a
   
 https://git.kernel.org/cgit/linux/kernel/git/next/linux-next.git/commit/drivers/gpu/drm/nouveau?id=7a014a
   2014-06-11

 Do you have any special reason to believe this to be the culprit
 (besides the fact that it has something to do with hpd)? Can you do an
 actual bisect to confirm?

 Thanks,

   -ilia

 hpd what?
 
 hpd = hotplug detect
 
 First Fedora Kernel with broken video resume/thaw aka FFKWBVRT i.e. 
 kernel-3.16.0-0.rc0.git10.1.fc21
 comes with 'patch-3.15-git10.xz' which closely resembles 
 git/commit/drivers/gpu/drm/nouveau?id=7a014a.
 Simple as that.
 
 I see. So no reason to believe that it's not e.g. 20014cb or 377b1f1
 or any one of the other patches pulled in by merge commit bc1dfff04a?
 
 Why are you asking me that bisect formality, man is it not enough that I 
 tested two dozen kernels.
 
 Doing a bisect would involve half as many kernels... Knowing the exact
 commit that breaks things is a fairly useful debug tactic, and
 drastically increases the chances that a problem gets fixed. Not sure
 why you're referring to it as a formality.
 
 git bisect start v3.16-rc1 v3.15 -- drivers/gpu/drm/nouveau
 
 (Pro tip: use a config tailored to your machine rather than a distro
 config if you want to spend 5 min/compile instead of 1 hour/compile)
 
 Or you can wait and hope that someone else will have the same problem
 and works out the commit that causes it.
 
 Or you can see if it has already been fixed in the latest kernels. Or
 try the experimental repo at
 http://cgit.freedesktop.org/~darktama/nouveau/ (a bit of a pain to
 build, unfortunately, you need some unknown kernel version to build
 against, usually ~latest works).
 
 Good luck,
 
   -ilia
 

Man, I am not a kernel developer, I do not understand what you're saying.
I did the best I could and spent a lot of time besides.
If that's not enough, so be it.
Thank you very much.


poma





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

Re: [Nouveau] GeForce 8400 GS

[poma]

On 03.10.2013 20:45, Fernando Negro wrote:
  Hi everyone.
 
 I read on a 2011 article - 
 http://www.phoronix.com/scan.php?page=articleitem=nouveau_comp_2011num=19 - 
 that my particular card, GeForce 8400 GS, overheats with nouveau. (So, I 
 never tried using if for long, before, as soon as possible, installing the 
 proprietary drivers...) But, because it's a 2-year-old article, I was 
 wondering if that problem could have been, in the meantime, solved?... (Can 
 anyone tell me if that is so, or not - or indicate me a place where I can 
 know that?)
 

http://www.asus.com/Graphics_Cards/EN8400GS_SILENTHTP512M

$ modinfo -F filename nouveau
/lib/modules/3.11.2-201.fc19.x86_64/kernel/drivers/gpu/drm/nouveau/nouveau.ko

$ sensors nouveau-pci-0200
nouveau-pci-0200
Adapter: PCI adapter
temp1:+61.0°C  (high = +95.0°C, hyst =  +3.0°C)
   (crit = +122.0°C, hyst =  +2.0°C)
   (emerg = +135.0°C, hyst =  +5.0°C)

# nvclock -i
Xlib:  extension NV-CONTROL missing on display :0.0.
-- General info --
Card:   nVidia Geforce 8400GS
Architecture:   G98 A2
PCI id: 0x6e4
GPU clock:  612.000 MHz
Bustype:PCI-Express

-- Shader info --
Clock: 1512.000 MHz
Stream units: 16 (1b)
ROP units: 4 (1b)
-- Memory info --
Amount: 512 MB
Type:   128 bit DDR2
Clock:  399.600 MHz

-- PCI-Express info --
Current Rate:   16X
Maximum rate:   16X

-- Sensor info --
Sensor: GPU Internal Sensor
GPU temperature: 61C

-- VideoBios information --
Version: 62.98.2c.00.00
Signon message: ASUS EN8400GS VGA BIOS Ver 62.98.2C.00.AS07
Performance level 0: gpu 567MHz/shader 1400MHz/memory 400MHz/100%


poma


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