Bug 708238 - nouveau: fail ttm_validate - X server gets stuck, no vt switch possible
Summary: nouveau: fail ttm_validate - X server gets stuck, no vt switch possible
Keywords:
Status: CLOSED DUPLICATE of bug 699551
Alias: None
Product: Fedora
Classification: Fedora
Component: xorg-x11-drv-nouveau
Version: 15
Hardware: x86_64
OS: Linux
unspecified
unspecified
Target Milestone: ---
Assignee: Ben Skeggs
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2011-05-27 01:18 UTC by Rui Matos
Modified: 2011-08-22 16:45 UTC (History)
5 users (show)

Fixed In Version:
Clone Of:
Environment:
Last Closed: 2011-08-22 16:45:57 UTC
Type: ---
Embargoed:


Attachments (Terms of Use)
Xorg.log (48.44 KB, text/plain)
2011-05-27 01:18 UTC, Rui Matos
no flags Details
dmesg (61.21 KB, text/plain)
2011-05-27 01:55 UTC, Rui Matos
no flags Details
dmesg with kernel trace (9.23 KB, text/plain)
2011-05-31 00:11 UTC, Rui Matos
no flags Details
dmesg with drm.debug=2 (123.11 KB, text/plain)
2011-06-09 21:43 UTC, Rui Matos
no flags Details
dmesg with drm.debug=7 (120.52 KB, text/plain)
2011-06-09 21:59 UTC, Rui Matos
no flags Details

Description Rui Matos 2011-05-27 01:18:00 UTC
Created attachment 501217 [details]
Xorg.log

I'm running F15 here with kernel 2.6.39-0.fc16.x86_64 from koji and also:

xorg-x11-server-Xorg-1.10.1-14.fc15.x86_64
xorg-x11-drv-nouveau-0.0.16-24.20110324git8378443.fc15.x86_64
mesa-libGL-7.11-0.11.20110525.0.fc15.x86_64
gnome-shell-3.0.1-4.fc15.x86_64

Just a while ago the graphics system got frozen but I could get in through SSH and attach gdb to the X server:

#0  0x0000003a0b8d9217 in ioctl () from /lib64/libc.so.6
#1  0x0000003a1b403338 in drmIoctl (fd=8, request=1074291842, arg=0x7fffe8855160) at xf86drm.c:167
#2  0x0000003a1b40545b in drmCommandWrite (fd=<optimized out>, drmCommandIndex=<optimized out>, data=<optimized out>, size=<optimized out>) at xf86drm.c:2378
#3  0x00007fe9870fdeb7 in nouveau_bo_wait (bo=0x1551be0, cpu_write=0, no_wait=<optimized out>, no_block=<optimized out>) at nouveau_bo.c:390
#4  0x00007fe9870fe4d9 in nouveau_bo_map_range (bo=0x1551be0, delta=0, size=<optimized out>, flags=4) at nouveau_bo.c:433
#5  0x00007fe987306ddb in NVAccelDownloadM2MF (dst_pitch=1368, dst=0x30d8460 "\270\231\271\v:", h=24, w=342, y=0, x=0, pspix=0x24b4150) at nouveau_exa.c:132
#6  nouveau_exa_download_from_screen (pspix=0x24b4150, x=0, y=0, w=342, h=24, dst=0x30d8460 "\270\231\271\v:", dst_pitch=1368) at nouveau_exa.c:386
#7  0x00007fe9866b816e in exaCopyDirty (migrate=<optimized out>, pValidDst=0x24b41e0, pValidSrc=0x24b41f0, transfer=0x7fe987306880 <nouveau_exa_download_from_screen>, fallback_index=1, 
    sync=0x7fe9866b6950 <exaWaitSync>) at exa_migration_classic.c:220
#8  0x00007fe9866bacfd in exaPrepareAccessReg_mixed (pPixmap=0x24b4150, index=<optimized out>, pReg=0x0) at exa_migration_mixed.c:247
#9  0x00007fe9866c5d30 in ExaPrepareCompositeReg (height=23, width=341, yDst=1, xDst=0, yMask=0, xMask=0, ySrc=1, xSrc=0, pDst=0x24e7c70, pMask=0x24dc450, pSrc=0x2459a10, op=3 '\003', pScreen=<optimized out>)
    at exa_unaccel.c:600
#10 ExaCheckComposite (op=3 '\003', pSrc=0x2459a10, pMask=0x24dc450, pDst=0x24e7c70, xSrc=0, ySrc=1, xMask=0, yMask=0, xDst=0, yDst=1, width=341, height=23) at exa_unaccel.c:625
#11 0x00007fe9866c1fef in exaComposite (op=3 '\003', pSrc=0x2459a10, pMask=0x24dc450, pDst=0x24e7c70, xSrc=<optimized out>, ySrc=<optimized out>, xMask=0, yMask=0, xDst=<optimized out>, yDst=<optimized out>, 
    width=341, height=23) at exa_render.c:1066
#12 0x00000000004d99cd in damageComposite (op=3 '\003', pSrc=0x2459a10, pMask=0x24dc450, pDst=0x24e7c70, xSrc=0, ySrc=1, xMask=0, yMask=0, xDst=0, yDst=1, width=341, height=23) at damage.c:617
#13 0x00000000004d4475 in ProcRenderComposite (client=0x17a1f50) at render.c:728
#14 0x000000000042ec11 in Dispatch () at dispatch.c:431
#15 0x0000000000422e1a in main (argc=<optimized out>, argv=0x7fffe8855888, envp=<optimized out>) at main.c:287

In dmesg the only relevant output was:

[10845.497108] [drm] nouveau 0000:01:00.0: fail ttm_validate
[10845.497113] [drm] nouveau 0000:01:00.0: validate vram_list
[10845.497117] [drm] nouveau 0000:01:00.0: validate: -12
[10845.497203] [drm] nouveau 0000:01:00.0: fail ttm_validate
[10845.497206] [drm] nouveau 0000:01:00.0: validate vram_list
[10845.497210] [drm] nouveau 0000:01:00.0: validate: -12

The attached Xorg.0.log also has a different backtrace.

Comment 1 Ben Skeggs 2011-05-27 01:36:33 UTC
Can you also attach all your dmesg output please, there may be useful info in there not directly related to the crash itself.

Comment 2 Rui Matos 2011-05-27 01:55:47 UTC
Created attachment 501222 [details]
dmesg

Comment 3 Rui Matos 2011-05-31 00:11:58 UTC
Created attachment 501892 [details]
dmesg with kernel trace

Comment 4 Rui Matos 2011-06-09 20:54:13 UTC
So, I've noticed that these "fail ttm_validate" & company messages always show up when I'm using gnome-shell and open more than 7 windows. If I then close the 8th window the kernel stops generating those messages and things stop flickering (as they do when I have > 7 windows opened).

Some sort of out-of-memory condition?

Comment 5 Rui Matos 2011-06-09 21:43:09 UTC
Created attachment 503995 [details]
dmesg with drm.debug=2

I've booted with drm.debug=2 and reproduced the case I mentioned on my previous comment. The attached file is the full dmesg output around the "fail ttm_validate" messages.

Comment 6 Rui Matos 2011-06-09 21:59:39 UTC
Created attachment 503997 [details]
dmesg with drm.debug=7

Now with drm.debug=7. It seems that it's not the number of windows but their size. 4-5 maximized windows immediately trigger this.

Comment 7 Rui Matos 2011-08-22 16:45:57 UTC

*** This bug has been marked as a duplicate of bug 699551 ***


Note You need to log in before you can comment on or make changes to this bug.