Nouveau - Sep 2007 - Fixes and workarounds for regressions and issues in the randr-1.2 branch

Hi,
    Please find attached the patches which I currently use on my desktop
machine for dual head with the randr branch to fix the issues which I found.

They may help others as well but may e.g. also disable the Xv blitter
which might be working for some (but didn't on my card) - more information
is found in the text comments in the patches.

I have to hurry so this is short, will be back.

cu,
Bernhard Kaindl
-------------- next part --------------
A non-text attachment was scrubbed...
Name: xf86-video-nouveau-dpms_mode.diff
Type: text/x-patch
Size: 1710 bytes
Desc: 
Url :
http://lists.freedesktop.org/archives/nouveau/attachments/20070903/1304c2d9/attachment.bin
-------------- next part --------------
A non-text attachment was scrubbed...
Name: xf86-video-nouveau-Xv_noblit.diff
Type: text/x-patch
Size: 4522 bytes
Desc: 
Url :
http://lists.freedesktop.org/archives/nouveau/attachments/20070903/1304c2d9/attachment-0001.bin
-------------- next part --------------
A non-text attachment was scrubbed...
Name: xf86-video-nouveau-biostable.diff
Type: text/x-patch
Size: 1056 bytes
Desc: 
Url :
http://lists.freedesktop.org/archives/nouveau/attachments/20070903/1304c2d9/attachment-0002.bin
-------------- next part --------------
A non-text attachment was scrubbed...
Name: xf86-video-nouveau-set_modes.diff
Type: text/x-patch
Size: 2692 bytes
Desc: 
Url :
http://lists.freedesktop.org/archives/nouveau/attachments/20070903/1304c2d9/attachment-0003.bin

On Mon, 3 Sep 2007, Bernhard Kaindl wrote:
> 
> Hi,
>   Please find attached the patches which I currently use on my desktop
> machine for dual head with the randr branch to fix the issues which I
found.
>
> They may help others as well but may e.g. also disable the Xv blitter
> which might be working for some (but didn't on my card) - more
information
> is found in the text comments in the patches.
Anther patch: This one fixes a crash in the randr-1.2 branch which always
happens when a program tries to set a video mode thru the XF86 VidMode
extension (which are very many)

Patch below and in attachment.

Best Regards.
Bernhard

// With the current randr-1.2 branch, the X server crashes when
// the XF86 VidMode extension is used to switch the video mode.
//
// SDL and freeglut use it, so for example all program which
// which use either to switch to fullscreen mode cause the crash.
//
// Reason for the crash: The current implmentation of NVSwitchMode()
// which gets called by the extension to set the video mode tries
// to call a non-existing function.
//
// I implemented a version of that function which should do what
// is needed and with this, trackballs and glest not longer crash
// my X server.
//
// Since on my card (G70 - GeForce 7600 GS - NV40 generation), changing
// video modes is broken (using the xrandr does not give e.g. a working
/  1280x1024 mode), I didn't test to actually switch to different
// resolutionss thru the extension, but the X crash is gone and there
// is an implementation which could work for some, so it's definitely
// an improvement.
// 
// I also removed the prototypes for two other undefined functions
// from nv_proto.h
//
--- nouveau-0.20070903/xf86-video-nouveau/src/nv_crtc.c
+++ nouveau-0.20070902/xf86-video-nouveau/src/nv_crtc.c
@@ -1297,6 +1324,15 @@ void NVCrtcSetCursor(xf86CrtcPtr crtc, B
    NVWriteVgaCrtc(crtc, NV_VGA_CRTCX_CURCTL1, current);
  }

+void NVSetMode(ScrnInfoPtr pScrn, DisplayModePtr mode)
+{
+	xf86CrtcConfigPtr   xf86_config = XF86_CRTC_CONFIG_PTR(pScrn);
+	int i;
+	for (i = 0; i < xf86_config->num_crtc; i++)
+		if (xf86_config->crtc[i]->enabled)
+			nv_crtc_mode_set(xf86_config->crtc[i], mode, NULL, 0,0);
+}
+
  static void NVCrtcWriteDacMask(xf86CrtcPtr crtc, CARD8 value)
  {
    ScrnInfoPtr pScrn = crtc->scrn;
--- nouveau-0.20070903/xf86-video-nouveau/src/nv_driver.c
+++ nouveau-0.20070902/xf86-video-nouveau/src/nv_driver.c
@@ -818,7 +818,42 @@ NVProbe(DriverPtr drv, int flags)
  	return foundScreen;
  }

-/* Usually mandatory */
+/*
+ * This function is needed by the XF86VideMode extension which is used by
+ * the current pre-randr clients. The API covers only one screen, but
+ * implementing the latest modesetting framework like done in the Intel
+ * driver is more than a few lines of patch, the randr-1.2 branch in its
+ * current form cannot the mode switching in a perfect way right now.
+ *
+ * As there are effors to bring modesetting into the kernel, controlled
+ * thru the drm module, of which nouveu currently requires its own version,
+ * one could even try to go one step further and try to bring the nouveau
+ * modesetting into the nouveau kernel module.c (as a first step which does
+ * not require a kernel patch), which would increase the chances that the
+ * text console is properly restored after X dies as the kernel can simply
+ * restore the text console when the process which has changed modes thru
+ * /dev/drm has been disconnected from the device.
+ *
+ * The current implementation simply tries to set each crtc to the mode
+ * for which the application asks for, hoping that one of them gives a
+ * usable monitor display (no error handling implemented), and sets
+ * the viewport of each crtc to (0,0), which means essentially clone
+ * mode with all monitors which managed to switch to the mode showing
+ * top left area of the framebuffer memory if the application's window
+ * is there. This is essentially what the Intel driver did in earlyer
+ * versions. To restore a LeftOf/RightOf layout, you two randr calls
+ * seem to be neccessary, one which sets the reversed layout, followed
+ * by one which sets the desired layout:
+ *
+ * xrandr --output Digital-1 --left-of Digital-0
+ * xrandr --output Digital-0 --left-of Digital-1
+ *
+ * FIXME: This could be fixed by getting the current viewports for the
+ * CRTCs and use these during mode settings, or (preferably) by getting
+ * the current screen layout and adapting the new viewports so that
+ * a new, continuos screen layout with the same monitor arrangement,
+ * but in the new mode is set up.
+ */
  Bool
  NVSwitchMode(int scrnIndex, DisplayModePtr mode, int flags)
  {
@@ -829,12 +864,16 @@ NVSwitchMode(int scrnIndex, DisplayModeP
  	NVFBLayout *pLayout = &pNv->CurrentLayout;

  	if (pLayout->mode != mode) {
-		if (!NVSetMode(pScrn, mode, RR_Rotate_0))
+#ifdef modesetting_has_error_handling // not implemented yet
+		if (NVSetMode(pScrn, mode))
+			pLayout->mode = mode;
+		else
  			ret = FALSE;
+#else
+		NVSetMode(pScrn, mode);
+		pLayout->mode = mode;
+#endif
  	}
-
-	pLayout->mode = mode;
-
  	return ret;
  }

--- nouveau-0.20070903/xf86-video-nouveau/src/nv_proto.h
+++ nouveau-0.20070902/xf86-video-nouveau/src/nv_proto.h
@@ -97,9 +97,7 @@ void nForceUpdateArbitrationSettings (un


  /* nv_crtc.c */
-Bool NVSetMode(ScrnInfoPtr pScrn, DisplayModePtr pMode, Rotation rotation);
-Bool NVCrtcSetMode(xf86CrtcPtr crtc, DisplayModePtr pMode, Rotation rotation,
int x, int y);
-DisplayModePtr NVCrtcFindClosestMode(xf86CrtcPtr crtc, DisplayModePtr pMode);
+void NVSetMode(ScrnInfoPtr pScrn, DisplayModePtr mode);
  void NVCrtcSetBase (xf86CrtcPtr crtc, int x, int y);
  void NVCrtcLoadPalette(xf86CrtcPtr crtc);
  void NVCrtcBlankScreen(xf86CrtcPtr crtc, Bool on);
-------------- next part --------------
A non-text attachment was scrubbed...
Name: xf86-video-nouveau-VidModExt.diff
Type: text/x-patch
Size: 5357 bytes
Desc: 
Url :
http://lists.freedesktop.org/archives/nouveau/attachments/20070904/f982811b/attachment.bin

On Mon, 3 Sep 2007, Bernhard Kaindl wrote:
>
> They may help others as well but may e.g. also disable the Xv blitter
> which might be working for some (but didn't on my card) - more
information
> is found in the text comments in the patches.
The patch "xf86-video-nouveau-Xv_noblit.diff" which disabled the Xv
blitter
on some cards was wrong, thanks to encouragement from Arthur Huillet and that
I had now some time to check out what was failing, I found out that the Xv
problems which I see are limited to two situations:

1) randr active and monitors configured side-by-side with xrandr

2) Option "ShadowFB" is used (or other NoAccel trigger)

While I have no fix for 1) yet, 2) is easy to deal with properly:

As driving the blitter requires the DMA FIFO, and while the overlay might work
without the DMA FIFO, it has a fallback to the blitter for Composite, we think
it's best to also disable the overlay for now when pNV->NoAccel is
<> 0.

I attached and appended patch for the current master branch, which (with one
small change, which I am going to talk in a separate mail) works for me with
Randr12 (except for the Xv in side-by-side mode).

Thanks to Arthur for the guidance and explanations!

Bernhard

--- src/nv_video.c	2007-09-05 16:02:00.000000000 +0200
+++ src/nv_video.c	2007-09-05 16:24:22.000000000 +0200
@@ -2275,10 +2275,13 @@
  	XF86VideoAdaptorPtr  blitAdaptor = NULL;
  	int                  num_adaptors;

-	if (pScrn->bitsPerPixel == 8)
-		return;
-
-	if (pNv->Architecture < NV_ARCH_50) {
+	/*
+	 * Driving the blitter requires the DMA FIFO. Using the FIFO
+	 * without accel causes DMA errors. While the overlay might
+	 * might work without accel, we also disable it for now when
+	 * acceleration is disabled:
+	 */
+	if (pScrn->bitsPerPixel != 8 && pNv->Architecture <
NV_ARCH_50 && !pNv->NoAccel) {
  		overlayAdaptor = NVSetupOverlayVideo(pScreen);
  		blitAdaptor    = NVSetupBlitVideo(pScreen);
  	}
=====================================================
PS: 
The inspiration to change from this logic

-       if (pScrn->bitsPerPixel == 8)
-               return;

to this logic

+       if (pScrn->bitsPerPixel != 8 && pNv->Architecture <
NV_ARCH_50 && !pNv->NoAccel)
                 overlayAdaptor = NVSetupOverlayVideo(pScreen);
                 blitAdaptor    = NVSetupBlitVideo(pScreen);
         }

to disable overlay and blitter came from the NV50 change (which you see in the
patch) and it seems reasonable to do it also for 8bit as
xf86-video-intel-2.1.1/src/i810_video.c does it similar for 8bit:

     if (pScrn->bitsPerPixel != 8)
     {
         newAdaptor = I810SetupImageVideo(pScreen);
         I810InitOffscreenImages(pScreen);
     }

     num_adaptors = xf86XVListGenericAdaptors(pScrn, &adaptors);

     if(newAdaptor) {
... similar to nouveau code here
     }

     if(num_adaptors)
         xf86XVScreenInit(pScreen, adaptors, num_adaptors);

(The routine in nv_driver has basically the same code)

which means that generic, driver-independent Xv adaptors (such as the v4l Xv
adaptor) are always initialized, xf86XVListGenericAdaptors lists them if
such are there:

xf86XVListGenericAdaptors(
...
     /*
      * The v4l driver registers itself first, but can use surfaces registered
      * by other drivers.  So, call the v4l driver last.
      */
..
}
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Xv-NoAccel-master.diff
Type: text/x-patch
Size: 2137 bytes
Desc: 
Url :
http://lists.freedesktop.org/archives/nouveau/attachments/20070905/2e76e21c/attachment.bin

Arthur asked me for my status of the blitter with randr12:

The blitter works for me with the Option Randr12 (master branch) enabled as
long as I do not change the startup layout of nouveau which currently always
cloned display on the second monitor to a side-by-side layout with this

xrandr --output Digital-0 --left-of Digital-1

or this

xrandr --output Digital-1 --pos 1680x1050

command (both have visually the same effect)

After I run these commands, the blitter causes a crash, which I hope we can
debug.

when I have mplayer running when I run the xrandr to move Digital-1 to the
right of Digital-0, the blitter keeps running but the montiors go into sleep
mode when I quit mplayer. X still keeps running, the last messages are:

writting vpll 00021B05
writting vpll2 00021B05
output 1 debug_0 01101191
savep->dither 00060000
1: crtc 1 output1: 0100: twocrt 0 twomon 1
output 0 debug_0 01101191
savep->dither 000B0000
1: crtc 0 output0: 0000: twocrt 0 twomon 1
output 1 debug_0 01101191
savep->dither 00060000
1: crtc 1 output1: 0100: twocrt 0 twomon 1

and attaching to X with gdb X `pidof X` gives:

(gdb) bt
#0  0x00002b6b3cde7ea3 in select () from /lib64/libc.so.6
#1  0x000000000056a99a in WaitForSomething (pClientsReady=0x7fff6f10fe80)
     at WaitFor.c:239
#2  0x0000000000450c7a in Dispatch () at dispatch.c:383
#3  0x0000000000439a15 in main (argc=6, argv=0x7fff6f110428,
     envp=<value optimized out>) at main.c:445

I emtied the dmesg buffer with dmesg -c before quitting mplayer but it
does not show new drm debug messages at this point.

I get some messages which might give a clue when starting mplayer after getting
the monitors side by side)

chvt 1 and chvt 7 (back to X) still work, but the chvt 7 does not restore
the X display properly, it seems that the LockUnlock things on console
witch are not working right yet. This reproduces without mplayer ever
started, so that's another thing which I can look at.

When I put the monitors side-by-side before starting mplayer, I get these logs:

(EE) NOUVEAU(0): Notifier (0xd8000003) timeout!
(II) NOUVEAU(0): Fifo dump (lockup 0x164c,0x164c):
(II) NOUVEAU(0): [0x1638] 0x0801d000
(II) NOUVEAU(0): [0x1639] 0x00000000
(II) NOUVEAU(0): [0x163a] 0x000482fc
(II) NOUVEAU(0): [0x163b] 0x00000003
(II) NOUVEAU(0): [0x163c] 0x00100300
(II) NOUVEAU(0): [0x163d] 0x0000000b
(II) NOUVEAU(0): [0x163e] 0x34803480
(II) NOUVEAU(0): [0x163f] 0x00008000
(II) NOUVEAU(0): [0x1640] 0x00008000
(II) NOUVEAU(0): [0x1641] 0x00048300
(II) NOUVEAU(0): [0x1642] 0x00000003
(II) NOUVEAU(0): [0x1643] 0x000483fc
(II) NOUVEAU(0): [0x1644] 0x00000000
(II) NOUVEAU(0): [0x1645] 0x00088400
(II) NOUVEAU(0): [0x1646] 0x02d102d3
(II) NOUVEAU(0): [0x1647] 0x00060003
(II) NOUVEAU(0): [0x1648] 0x00042104
(II) NOUVEAU(0): [0x1649] 0x00000000
(II) NOUVEAU(0): [0x164a] 0x00042100
(II) NOUVEAU(0): [0x164b] 0x00000000
(II) NOUVEAU(0): [0x164c] 0xd8000001
(II) NOUVEAU(0): [0x164d] 0x0020c30c
(II) NOUVEAU(0): [0x164e] 0x00001000
(II) NOUVEAU(0): [0x164f] 0x00d90d06
(II) NOUVEAU(0): [0x1650] 0x00000004
(II) NOUVEAU(0): [0x1651] 0x00000040
(II) NOUVEAU(0): [0x1652] 0x00000004
(II) NOUVEAU(0): [0x1653] 0x00000002
(II) NOUVEAU(0): [0x1654] 0x00000101
(II) NOUVEAU(0): [0x1655] 0x00000000
(II) NOUVEAU(0): End of fifo dump

Fatal server error:
DMA queue hang: dmaPut=164c, current=164c, status=4041

As Arthur told me that those do not tell anything, here are the drm debug
messages:

I should also mention that the two montors go black immedately, then
I hear the sound of the video, and then the sound stops and the X
displays return to text mode with the crash.

That's the printks which I capture with dmesg from start of mplayer
until X starting to crash:

[drm:drm_unlocked_ioctl] pid=17689, cmd=0xc0206448, nr=0x48, dev 0xe200, auth=1
[drm:drm_addmap_core] offset = 0xc801d000, size = 0x00066000, type = 0
[drm:nouveau_mem_alloc] allocated 0x801d000 type=0x00000101
[drm:drm_mmap_locked] start = 0x2b6b5e459000, end = 0x2b6b5e4bf000, page offset
= 0xc801d
[drm:drm_mmap_locked]    Type = 0; start = 0x2b6b5e459000, end = 0x2b6b5e4bf000,
offset = 0xc801d000
[drm:drm_vm_open_locked] 0x2b6b5e459000,0x00066000
[drm:drm_unlocked_ioctl] pid=17689, cmd=0xc0206448, nr=0x48, dev 0xe200, auth=1
[drm:drm_addmap_core] offset = 0x003ca000, size = 0x00066000, type = 4
[drm:nouveau_mem_alloc] allocated 0x3ca000 type=0x00000110
[drm:drm_mmap_locked] start = 0x2b6b5e4bf000, end = 0x2b6b5e525000, page offset
= 0x1f001
[drm:drm_vm_open_locked] 0x2b6b5e4bf000,0x00066000
[drm:drm_unlocked_ioctl] pid=17689, cmd=0xc0206448, nr=0x48, dev 0xe200, auth=1
[drm:drm_addmap_core] offset = 0x00430000, size = 0x00066000, type = 4
[drm:nouveau_mem_alloc] allocated 0x430000 type=0x00000110
[drm:drm_mmap_locked] start = 0x2b6b5e525000, end = 0x2b6b5e58b000, page offset
= 0x1f002
[drm:drm_vm_open_locked] 0x2b6b5e525000,0x00066000
[drm:drm_unlocked_ioctl] pid=17689, cmd=0xc0106446, nr=0x46, dev 0xe200, auth=1
[drm:nouveau_gpuobj_dma_new] ch1 class=0x003d offset=0x3c9020 size=0x20
[drm:nouveau_gpuobj_dma_new] access=0 target=8
[drm:nouveau_gpuobj_new] ch1 size=16 align=16 flags=0x00000006
[drm:nouveau_gpuobj_new] gpuobj ffff810064bb3a40
[drm:nouveau_gpuobj_new] global heap fallback
[drm:nouveau_gpuobj_dma_new] Creating PCI DMA object using virtual zone starting
at 0x3c9020, size 32
[drm:nouveau_gpuobj_ref_add] ch1 h=0xe8000000 gpuobj=ffff810064bb3a40
[drm:nouveau_ramht_hash_handle] ch1 handle=0xe8000000
[drm:nouveau_ramht_hash_handle] hash=0x000001e8
[drm:nouveau_ramht_insert] insert ch1 0x000001e8: h=0xe8000000, c=0x00807d8f
[drm:drm_do_vm_sg_nopage]
(this last line is repeated 101 times)

Here is a second try:

[drm:drm_unlocked_ioctl] pid=17904, cmd=0xc0206448, nr=0x48, dev 0xe200, auth=1
[drm:drm_addmap_core] offset = 0xc801d000, size = 0x00066000, type = 0
[drm:nouveau_mem_alloc] allocated 0x801d000 type=0x00000101
[drm:drm_mmap_locked] start = 0x2b5053a30000, end = 0x2b5053a96000, page offset
= 0xc801d
[drm:drm_mmap_locked]    Type = 0; start = 0x2b5053a30000, end = 0x2b5053a96000,
offset = 0xc801d000
[drm:drm_vm_open_locked] 0x2b5053a30000,0x00066000
[drm:drm_unlocked_ioctl] pid=17904, cmd=0xc0206448, nr=0x48, dev 0xe200, auth=1
[drm:drm_addmap_core] offset = 0x003ca000, size = 0x00066000, type = 4
[drm:nouveau_mem_alloc] allocated 0x3ca000 type=0x00000110
[drm:drm_mmap_locked] start = 0x2b5053a96000, end = 0x2b5053afc000, page offset
= 0x1f001
[drm:drm_vm_open_locked] 0x2b5053a96000,0x00066000
[drm:drm_unlocked_ioctl] pid=17904, cmd=0xc0206448, nr=0x48, dev 0xe200, auth=1
[drm:drm_addmap_core] offset = 0x00430000, size = 0x00066000, type = 4
[drm:nouveau_mem_alloc] allocated 0x430000 type=0x00000110
[drm:drm_mmap_locked] start = 0x2b5053afc000, end = 0x2b5053b62000, page offset
= 0x1f002
[drm:drm_vm_open_locked] 0x2b5053afc000,0x00066000
[drm:drm_do_vm_sg_nopage]
(also repeated 101 times)

I pressesd dmesg -c >outfile at the time about 2-3 seconds after I started
mplayer, at the same time I pressed return, sound ended and the text mode
restoration was done. I attached the remaining final messages after these 2-3
seconds.

Bernhard

PS: DPMS also does not bring the display back when I after I have put
the mointors side by side with xrandr. For me this DPMS issue could
be easyer to debug, I hope, but first I would like to get the console
switch working as it should and as I had it with my patch to the randr
branch.
-------------- next part --------------
[drm:drm_vm_shm_close] 0x2b50478fd000,0x00002000
[drm:drm_vm_close] 0x2b50494c4000,0x08000000
[drm:drm_vm_close] 0x2b50514c4000,0x003c0000
[drm:drm_vm_close] 0x2b5051884000,0x00010000
[drm:drm_vm_close] 0x2b5051894000,0x00004000
[drm:drm_vm_close] 0x2b5051898000,0x00008000
[drm:drm_vm_close] 0x2b50518a0000,0x00010000
[drm:drm_vm_close] 0x2b50518b0000,0x00001000
[drm:drm_vm_close] 0x2b5051f0a000,0x00001000
[drm:drm_vm_close] 0x2b5053a30000,0x00066000
[drm:drm_vm_close] 0x2b5053a96000,0x00066000
[drm:drm_vm_close] 0x2b5053afc000,0x00066000
[drm:drm_release] open_count = 1
[drm:nouveau_fifo_cleanup] clearing FIFO enables from file_priv
[drm] nouveau_fifo_free: freeing fifo 1
[drm:nouveau_gpuobj_ref_del] ref ffff8100492172c0
[drm:nouveau_gpuobj_del] gpuobj ffff8100750c83c0
[drm:nouveau_gpuobj_ref_del] ref ffff81006e3cf280
[drm:nouveau_gpuobj_del] gpuobj ffff81007245dec0
[drm:nouveau_gpuobj_ref_del] ref ffff81006720c9c0
[drm:nouveau_gpuobj_del] gpuobj ffff8100750c88c0
[drm:nouveau_mem_free] freeing 0x3c1000 type=0x00000110
[drm:nouveau_gpuobj_channel_takedown] ch1
[drm:nouveau_gpuobj_ref_del] ref ffff81005467e840
[drm:nouveau_ramht_hash_handle] ch1 handle=0xd8000001
[drm:nouveau_ramht_hash_handle] hash=0x000001d0
[drm:nouveau_ramht_remove] remove ch1 0x000001d0: h=0xd8000001, c=0x00000000
[drm:nouveau_gpuobj_del] gpuobj ffff81007245d1c0
[drm:nouveau_gpuobj_ref_del] ref ffff81003b9097c0
[drm:nouveau_ramht_hash_handle] ch1 handle=0xd8000002
[drm:nouveau_ramht_hash_handle] hash=0x000001c8
[drm:nouveau_ramht_remove] remove ch1 0x000001c8: h=0xd8000002, c=0x00000000
[drm:nouveau_gpuobj_del] gpuobj ffff8100750c8440
[drm:nouveau_gpuobj_ref_del] ref ffff8100320cbc80
[drm:nouveau_ramht_hash_handle] ch1 handle=0x00000000
[drm:nouveau_ramht_hash_handle] hash=0x00000100
[drm:nouveau_ramht_remove] remove ch1 0x00000100: h=0x00000000, c=0x00000000
[drm:nouveau_gpuobj_del] gpuobj ffff8100750c8140
[drm:nouveau_gpuobj_ref_del] ref ffff81003b909f40
[drm:nouveau_ramht_hash_handle] ch1 handle=0xd8000003
[drm:nouveau_ramht_hash_handle] hash=0x000001c0
[drm:nouveau_ramht_remove] remove ch1 0x000001c0: h=0xd8000003, c=0x00000000
[drm:nouveau_gpuobj_del] gpuobj ffff810037fb6240
[drm:nouveau_notifier_gpuobj_dtor] 
[drm:nouveau_gpuobj_ref_del] ref ffff81003efa35c0
[drm:nouveau_ramht_hash_handle] ch1 handle=0x80000010
[drm:nouveau_ramht_hash_handle] hash=0x00000100
[drm:nouveau_ramht_remove] remove ch1 0x00000108: h=0x80000010, c=0x00000000
[drm:nouveau_gpuobj_del] gpuobj ffff81007245dcc0
[drm:nouveau_gpuobj_ref_del] ref ffff81004bc839c0
[drm:nouveau_ramht_hash_handle] ch1 handle=0x8000001b
[drm:nouveau_ramht_hash_handle] hash=0x00000158
[drm:nouveau_ramht_remove] remove ch1 0x00000158: h=0x8000001b, c=0x00000000
[drm:nouveau_gpuobj_del] gpuobj ffff81007245d940
[drm:nouveau_gpuobj_ref_del] ref ffff81004bc83e40
[drm:nouveau_ramht_hash_handle] ch1 handle=0x8000001c
[drm:nouveau_ramht_hash_handle] hash=0x00000160
[drm:nouveau_ramht_remove] remove ch1 0x00000160: h=0x8000001c, c=0x00000000
[drm:nouveau_gpuobj_del] gpuobj ffff81007245d8c0
[drm:nouveau_gpuobj_ref_del] ref ffff810064530840
[drm:nouveau_ramht_hash_handle] ch1 handle=0x80000012
[drm:nouveau_ramht_hash_handle] hash=0x00000110
[drm:nouveau_ramht_remove] remove ch1 0x00000110: h=0x80000012, c=0x00000000
[drm:nouveau_gpuobj_del] gpuobj ffff8100750c8940
[drm:nouveau_gpuobj_ref_del] ref ffff8100429bf180
[drm:nouveau_ramht_hash_handle] ch1 handle=0x80000011
[drm:nouveau_ramht_hash_handle] hash=0x00000108
[drm:nouveau_ramht_remove] remove ch1 0x00000118: h=0x80000011, c=0x00000000
[drm:nouveau_gpuobj_del] gpuobj ffff8100750c8ac0
[drm:nouveau_gpuobj_ref_del] ref ffff81003b9098c0
[drm:nouveau_ramht_hash_handle] ch1 handle=0x80000016
[drm:nouveau_ramht_hash_handle] hash=0x00000130
[drm:nouveau_ramht_remove] remove ch1 0x00000130: h=0x80000016, c=0x00000000
[drm:nouveau_gpuobj_del] gpuobj ffff8100750c8a40
[drm:nouveau_gpuobj_ref_del] ref ffff810075d8e680
[drm:nouveau_ramht_hash_handle] ch1 handle=0x80000015
[drm:nouveau_ramht_hash_handle] hash=0x00000128
[drm:nouveau_ramht_remove] remove ch1 0x00000128: h=0x80000015, c=0x00000000
[drm:nouveau_gpuobj_del] gpuobj ffff8100750c8840
[drm:nouveau_gpuobj_ref_del] ref ffff8100791a8900
[drm:nouveau_ramht_hash_handle] ch1 handle=0x80000017
[drm:nouveau_ramht_hash_handle] hash=0x00000138
[drm:nouveau_ramht_remove] remove ch1 0x00000138: h=0x80000017, c=0x00000000
[drm:nouveau_gpuobj_del] gpuobj ffff8100750c81c0
[drm:nouveau_gpuobj_ref_del] ref ffff81007aa7e740
[drm:nouveau_ramht_hash_handle] ch1 handle=0x80000013
[drm:nouveau_ramht_hash_handle] hash=0x00000118
[drm:nouveau_ramht_remove] remove ch1 0x00000120: h=0x80000013, c=0x00000000
[drm:nouveau_gpuobj_del] gpuobj ffff81007b8e8740
[drm:nouveau_gpuobj_ref_del] ref ffff8100320cb6c0
[drm:nouveau_ramht_hash_handle] ch1 handle=0x80000014
[drm:nouveau_ramht_hash_handle] hash=0x00000120
[drm:nouveau_ramht_remove] remove ch1 0x00000140: h=0x80000014, c=0x00000000
[drm:nouveau_gpuobj_del] gpuobj ffff810077648140
[drm:nouveau_gpuobj_ref_del] ref ffff81003b909b80
[drm:nouveau_ramht_hash_handle] ch1 handle=0x8000001a
[drm:nouveau_ramht_hash_handle] hash=0x00000150
[drm:nouveau_ramht_remove] remove ch1 0x00000150: h=0x8000001a, c=0x00000000
[drm:nouveau_gpuobj_del] gpuobj ffff8100776488c0
[drm:nouveau_gpuobj_ref_del] ref ffff810054ec8f40
[drm:nouveau_ramht_hash_handle] ch1 handle=0x80000018
[drm:nouveau_ramht_hash_handle] hash=0x00000140
[drm:nouveau_ramht_remove] remove ch1 0x00000148: h=0x80000018, c=0x00000000
[drm:nouveau_gpuobj_del] gpuobj ffff8100776481c0
[drm:nouveau_gpuobj_ref_del] ref ffff81003b909e80
[drm:nouveau_ramht_hash_handle] ch1 handle=0x80000019
[drm:nouveau_ramht_hash_handle] hash=0x00000148
[drm:nouveau_ramht_remove] remove ch1 0x00000168: h=0x80000019, c=0x00000000
[drm:nouveau_gpuobj_del] gpuobj ffff810077648e40
[drm:nouveau_gpuobj_ref_del] ref ffff81004bc83800
[drm:nouveau_ramht_hash_handle] ch1 handle=0xe8000000
[drm:nouveau_ramht_hash_handle] hash=0x000001e8
[drm:nouveau_ramht_remove] remove ch1 0x000001e8: h=0xe8000000, c=0x00000000
[drm:nouveau_gpuobj_del] gpuobj ffff81005977c440
[drm:nouveau_notifier_gpuobj_dtor] 
[drm:nouveau_gpuobj_ref_del] ref ffff81004bc83d00
[drm:nouveau_ramht_hash_handle] ch1 handle=0xe8000001
[drm:nouveau_ramht_hash_handle] hash=0x000001e0
[drm:nouveau_ramht_remove] remove ch1 0x000001e0: h=0xe8000001, c=0x00000000
[drm:nouveau_gpuobj_del] gpuobj ffff81005977ccc0
[drm:nouveau_notifier_gpuobj_dtor] 
[drm:nouveau_gpuobj_ref_del] ref ffff81004a288c00
[drm:nouveau_gpuobj_del] gpuobj 0000000000000000
[drm:nouveau_gpuobj_ref_del] ref 0000000000000000
[drm:nouveau_mem_free] freeing 0x3c9000 type=0x00000110
[drm:drm_release] pid = 17904, device = 0xe200, open_count = 1
[drm:drm_release] File ffff81005d04f4c0 released, freeing lock for context 1
[drm:drm_fasync] fd = -1, device = 0xe200
[drm:drm_lastclose] 
[drm:nouveau_card_takedown] prev state = 1
[drm:nouveau_dma_channel_takedown] 
[drm] nouveau_fifo_free: freeing fifo 0
[drm:nouveau_gpuobj_ref_del] ref ffff81003efa32c0
[drm:nouveau_gpuobj_del] gpuobj ffff8100750c8540
[drm:nouveau_gpuobj_ref_del] ref ffff81005b99b2c0
[drm:nouveau_gpuobj_del] gpuobj ffff8100750c8340
[drm:nouveau_gpuobj_ref_del] ref ffff8100743f5c40
[drm:nouveau_gpuobj_del] gpuobj ffff8100750c8ec0
[drm:nouveau_mem_free] freeing 0x0 type=0x00000101
[drm:nouveau_gpuobj_channel_takedown] ch0
[drm:nouveau_gpuobj_ref_del] ref ffff81006afd3680
[drm:nouveau_ramht_hash_handle] ch0 handle=0x8003d001
[drm:nouveau_ramht_hash_handle] hash=0x00000fc8
[drm:nouveau_ramht_remove] remove ch0 0x00000fc8: h=0x8003d001, c=0x00000000
[drm:nouveau_gpuobj_del] gpuobj ffff81007245d740
[drm:nouveau_gpuobj_ref_del] ref ffff8100708fbc80
[drm:nouveau_ramht_hash_handle] ch0 handle=0x8003d002
[drm:nouveau_ramht_hash_handle] hash=0x00000fd0
[drm:nouveau_ramht_remove] remove ch0 0x00000fd0: h=0x8003d002, c=0x00000000
[drm:nouveau_gpuobj_del] gpuobj ffff81007245d840
[drm:nouveau_gpuobj_ref_del] ref ffff81004a288780
[drm:nouveau_ramht_hash_handle] ch0 handle=0x8003d003
[drm:nouveau_ramht_hash_handle] hash=0x00000fd8
[drm:nouveau_ramht_remove] remove ch0 0x00000fd8: h=0x8003d003, c=0x00000000
[drm:nouveau_gpuobj_del] gpuobj ffff81007245d7c0
[drm:nouveau_notifier_gpuobj_dtor] 
[drm:nouveau_gpuobj_ref_del] ref ffff81005457c280
[drm:nouveau_ramht_hash_handle] ch0 handle=0x80039001
[drm:nouveau_ramht_hash_handle] hash=0x00000ec8
[drm:nouveau_ramht_remove] remove ch0 0x00000ec8: h=0x80039001, c=0x00000000
[drm:nouveau_gpuobj_del] gpuobj ffff81007245d540
[drm:nouveau_gpuobj_ref_del] ref ffff81003b909c40
[drm:nouveau_gpuobj_del] gpuobj 0000000000000000
[drm:nouveau_gpuobj_ref_del] ref 0000000000000000
[drm:nouveau_mem_free] freeing 0x0 type=0x00000110
[drm:nouveau_gpuobj_del] gpuobj 0000000000000000
[drm:nouveau_gpuobj_takedown] 
[drm:nouveau_gpuobj_del] gpuobj ffff81007245da40
[drm:drm_irq_uninstall] drm_irq_uninstall: irq=16
[drm:nouveau_gpuobj_late_takedown] 
[drm:drm_lastclose] driver lastclose completed
[drm:drm_lastclose] lastclose completed

> PS: DPMS also does not bring the display back when I after I have put
> the mointors side by side with xrandr. For me this DPMS issue could
> be easyer to debug, I hope, but first I would like to get the console
> switch working as it should and as I had it with my patch to the randr
> branch.
I can trick mplayer with Xv to work now side-by-side by doing chvt 1 and
chvt7 (with the chvt fix which I just sent) before starting using mplayer.
I slight guess that this is might be related to the DPMS fix/hack with
last_mode which I sent initially because DPMS also works again after a
VC switch when the monitors are side-by-side. I guess that last_mode might
be wrongly set in that case, will check.

--
Bernhard Kaindl