Description of problem: X freezes up. Version-Release number of selected component (if applicable): xorg-x11-drv-nouveau-0.0.16-6.20100423git13c1043.fc13.x86_64 libdrm-2.4.20-1.fc13.x86_64 libdrm-2.4.20-1.fc13.i686 How reproducible: Happens just about everytime, but I don't have a trigger for it. Steps to Reproduce: 1. Let the system keep running 2. 3. Actual results: System freezes. from Xorg.0.log [ 4605.834] [mi] EQ overflowing. The server is probably stuck in an infinite loop. [ 4605.834] Backtrace: [ 4605.849] 0: /usr/bin/X (xorg_backtrace+0x28) [0x49e708] [ 4605.849] 1: /usr/bin/X (mieqEnqueue+0x1f4) [0x49e0b4] [ 4605.849] 2: /usr/bin/X (xf86PostMotionEventP+0xc4) [0x477e24] [ 4605.849] 3: /usr/lib64/xorg/modules/input/evdev_drv.so (0x7f17f1fc1000+0x3dbf) [0x7f17f1fc4dbf] [ 4605.849] 4: /usr/bin/X (0x400000+0x6aae7) [0x46aae7] [ 4605.849] 5: /usr/bin/X (0x400000+0x117b43) [0x517b43] [ 4605.849] 6: /lib64/libc.so.6 (0x3ced800000+0x32a40) [0x3ced832a40] [ 4605.849] 7: /lib64/libc.so.6 (ioctl+0x7) [0x3ced8d95c7] [ 4605.849] 8: /usr/lib64/libdrm.so.2 (drmIoctl+0x28) [0x3d00403388] [ 4605.849] 9: /usr/lib64/libdrm.so.2 (drmCommandWrite+0x1b) [0x3d0040360b] [ 4605.849] 10: /usr/lib64/libdrm_nouveau.so.1 (0x7f17f3bb7000+0x2dfd) [0x7f17f3bb9dfd] [ 4605.849] 11: /usr/lib64/libdrm_nouveau.so.1 (nouveau_bo_map_range+0xfe) [0x7f17f3bb9fee] [ 4605.849] 12: /usr/lib64/libdrm_nouveau.so.1 (0x7f17f3bb7000+0x207a) [0x7f17f3bb907a] [ 4605.849] 13: /usr/lib64/libdrm_nouveau.so.1 (nouveau_pushbuf_flush+0x190) [0x7f17f3bb9450] [ 4605.849] 14: /usr/lib64/xorg/modules/libexa.so (0x7f17f2d1b000+0x9645) [0x7f17f2d24645] [ 4605.849] 15: /usr/lib64/xorg/modules/libexa.so (0x7f17f2d1b000+0xa1ea) [0x7f17f2d251ea] [ 4605.850] 16: /usr/bin/X (0x400000+0xd2b0b) [0x4d2b0b] [ 4605.850] 17: /usr/lib64/xorg/modules/libexa.so (0x7f17f2d1b000+0xb44d) [0x7f17f2d2644d] [ 4605.850] 18: /usr/bin/X (0x400000+0xd250e) [0x4d250e] [ 4605.850] 19: /usr/bin/X (0x400000+0xcc8ae) [0x4cc8ae] [ 4605.850] 20: /usr/bin/X (0x400000+0x2c32c) [0x42c32c] [ 4605.850] 21: /usr/bin/X (0x400000+0x219ca) [0x4219ca] [ 4605.850] 22: /lib64/libc.so.6 (__libc_start_main+0xfd) [0x3ced81ec5d] [ 4605.850] 23: /usr/bin/X (0x400000+0x21579) [0x421579] Expected results: Additional info:
*** This bug has been marked as a duplicate of bug 556302 ***
Created attachment 417056 [details] dmesg of the system, pre freezing
Created attachment 417057 [details] lscpi -vvv
Not a duplicate of bug 556302, same symptoms, almost certain of a different cause.
can we bump up the severity? This is a bug that prevents useful work being done, since X freezes quite reliably and frequently.
*** Bug 598711 has been marked as a duplicate of this bug. ***
*** Bug 587371 has been marked as a duplicate of this bug. ***
Did you tried adding pcie_aspm=off to kernel parameters?
Barbara, I did attempt PCIE_ASPM=off in my grub.conf just now, but saw no change in behavior. If logs or anything after a freeze with that parameter set would be helpful, let me know. Thanks!
I should modify my previous statement slightly. I left that parameter (PCIE_ASPM=off) set for a couple hours this morning and experienced frequent freezes (every 20 minutes or so). Without it, the freezes are much rarer (once or twice a day, at this point). It could be just the placebo effect, but I thought it might be a useful data point.
Since Ben has not mentioned it here, as a workaround in order to have a running system, boot with "nouveau.noaccel=1" in your command line. A more reliable way of reproducing the issue is just running anything that uses graphics acceleration. I find the easiest way to freeze X was to just run the Warzone 2100 game.
(In reply to comment #11) > Since Ben has not mentioned it here, as a workaround in order to have a running > system, boot with "nouveau.noaccel=1" in your command line. Sorry, I probably should have mentioned that here too :) > > A more reliable way of reproducing the issue is just running anything that uses > graphics acceleration. I find the easiest way to freeze X was to just run the > Warzone 2100 game. Just a note on this: this bug is referring to the lockup that happens with 2D acceleration *only*, it's entirely possible and likely the 3D driver could cause additional problems.
*** Bug 600754 has been marked as a duplicate of this bug. ***
> > Since Ben has not mentioned it here, as a workaround in order to have a running > > system, boot with "nouveau.noaccel=1" in your command line. Thanks for the nouveau.noaccel=1 tip. It is so much nicer to have a stable machine! > Just a note on this: this bug is referring to the lockup that happens with 2D > acceleration *only*, it's entirely possible and likely the 3D driver could > cause additional problems. Incidentally, I was running for a week or so (before that flag) with the experimental 3D drivers in mesa-dri-drivers-experimental. They actually seemed more stable than the 2D acceleration was. Freezes still happen, but they seemed less frequent. I mention it just because I thought it might be a useful data point in debugging. Thanks again!
*** Bug 556302 has been marked as a duplicate of this bug. ***
*** Bug 603139 has been marked as a duplicate of this bug. ***
*** Bug 602780 has been marked as a duplicate of this bug. ***
See also this thread for similar problems: http://fedoraforum.org/forum/showthread.php?t=235793
Yesterday, I enabled 'PEG force x1' in my BIOS. No crashes since then. ASUS P5B-MX mother board, BIOS version 0704. BTW: I think this bug is related to, or even similar to the issue described in bug #588036. And this bug seems also related: bug #589007.
The http://fedoraforum.org/forum/showthread.php?t=235793 thread is not related to the issue here. The key attributes of this issue are: 1. It's just the X process that crashes, the rest of the system is fine. 2. It's with the nouveau driver exclusively. 3. Setting nouveau.noaccel=1 on the kernel command line completely resolves the issue.
One additional datapoint: I installed the xorg-x11-drv-nouveau-0.0.16-7.20100423git13c1043.fc13 package (from the build system: https://admin.fedoraproject.org/updates/xorg-x11-drv-nouveau-0.0.16-7.20100423git13c1043.fc13?_csrf_token=e9743c5e70e6850d0d02815d95e9075fac5c62f6 ) and have not been able to reproduce the problem since installing the 0.0.16-7 version of the driver.
Thanks for the clarification Brendan. I tried disabling 'PEG force x1' in the BIOS and adding nouveau.noaccel=1 to the kernel command line. This resulted again in a total crash of my system after some time. I'm using nouveau exclusively.
(In reply to comment #22) > One additional datapoint: I installed the > xorg-x11-drv-nouveau-0.0.16-7.20100423git13c1043.fc13 package (from the build > system: > https://admin.fedoraproject.org/updates/xorg-x11-drv-nouveau-0.0.16-7.20100423git13c1043.fc13?_csrf_token=e9743c5e70e6850d0d02815d95e9075fac5c62f6 > ) and have not been able to reproduce the problem since installing the 0.0.16-7 > version of the driver. I was wrong; the problem still happens with the 0.0.16-7 nouveau driver, just not as often (for me...).
*** Bug 617643 has been marked as a duplicate of this bug. ***
Created attachment 436598 [details] strace of Xorg at the time of a hang #1 My computer crashed with the clock reading 9:12 -- this file shows all of the strace on the Xorg process for 9:12 before I power-cycled. I'll post another one or two for comparison as I collect them. Let me know if you want more context or strace to be run with other options.
Created attachment 436680 [details] strace of Xorg at the time of hang #2 Same thing. Interesting stuff happens around 14:27:39.247539 where the Xorg process seems to get stuck in: 14:27:39.247539 ioctl(8, 0x40086482, 0x7fff5a141cf0) = ? ERESTARTSYS (To be restarted) 14:27:39.265975 --- SIGALRM (Alarm clock) @ 0 (0) --- 14:27:39.266083 rt_sigreturn(0xe) = -1 EINTR (Interrupted system call) 14:27:39.266154 ioctl(8, 0x40086482, 0x7fff5a141cf0) = ? ERESTARTSYS (To be restarted) 14:27:39.286012 --- SIGALRM (Alarm clock) @ 0 (0) --- 14:27:39.286098 rt_sigreturn(0xe) = -1 EINTR (Interrupted system call) 14:27:39.286165 ioctl(8, 0x40086482, 0x7fff5a141cf0) = ? ERESTARTSYS (To be restarted) 14:27:39.306069 --- SIGALRM (Alarm clock) @ 0 (0) --- 14:27:39.306195 rt_sigreturn(0xe) = -1 EINTR (Interrupted system call) 14:27:39.306288 ioctl(8, 0x40086482, 0x7fff5a141cf0) = ? ERESTARTSYS (To be restarted) etc. Since that is the same signature as last time, I'm going to assume two strace attachments is enough unless told otherwise.
Patch went in 2.6.34.3-36.rc1.fc13 and 2.6.32.18-159.fc12
kernel-2.6.34.3-37.fc13 has been submitted as an update for Fedora 13. http://admin.fedoraproject.org/updates/kernel-2.6.34.3-37.fc13
kernel-2.6.34.3-37.fc13 has been pushed to the Fedora 13 testing repository. If problems still persist, please make note of it in this bug report. If you want to test the update, you can install it with su -c 'yum --enablerepo=updates-testing update kernel'. You can provide feedback for this update here: http://admin.fedoraproject.org/updates/kernel-2.6.34.3-37.fc13
Assuming your graphics controller is nvidia compatible. /sbin/lspci -nn | grep 'VGA\|NV' 01:00.0 VGA compatible controller [0300]: nVidia Corporation GT218 [NVS 3100M] [10de:0a6c] (rev a2) Another idea is to disable the nouveau driver using rdblacklist=nouveau for the kernel in the /boot/grub/grub.conf and compiling the nvidia driver in run level 3. Be sure and download kernel-devel. http://www.mjmwired.net/resources/mjm-fedora-nvidia.html
For the record: I've gone two weeks now using kernel-2.6.34.3-37.fc13 without a single freeze.
kernel-2.6.34.6-47.fc13 has been submitted as an update for Fedora 13. https://admin.fedoraproject.org/updates/kernel-2.6.34.6-47.fc13
kernel-2.6.34.6-47.fc13 has been pushed to the Fedora 13 stable repository. If problems still persist, please make note of it in this bug report.
I installed the update, and removed the "nouveau.noaccel=1" from my kernel parameters, and rebooted. No crashes, but I noticed the following in my Xorg.0.log: [ 20.064] (EE) NOUVEAU(0): Error creating GPU channel: -19 [ 20.064] (EE) NOUVEAU(0): Error initialising acceleration. Falling back to NoAccel It appears that I'm not getting acceleration anyways? Fedora 13 $ yum list installed | grep nouveau xorg-x11-drv-nouveau.x86_64 1:0.0.16-7.20100423git13c1043.fc13 @updates $ uname -a Linux wimsey 2.6.34.6-47.fc13.x86_64 #1 SMP Fri Aug 27 08:56:01 UTC 2010 x86_64 x86_64 x86_64 GNU/Linux Kernel command line is: title Fedora (2.6.34.6-47.fc13.x86_64) root (hd0,0) kernel /vmlinuz-2.6.34.6-47.fc13.x86_64 ro root=/dev/mapper/Wimsey-WimseyRoot rd_LVM_LV=Wimsey/WimseyRoot rd_NO_LUKS rd_NO_MD rd_NO_DM LANG=en_US.UTF-8 SYSFONT=latarcyrheb-sun16 KEYTABLE=us rhgb quiet initrd /initramfs-2.6.34.6-47.fc13.x86_64.img I suspect this is probably a configuration issue on my end, but just in case I wasn't the only one, I figured I'd post this here. If such is inappropriate, please let me know.
The update mentioned *disables* acceleration by default for these chipsets. The hang itself if you enable it (with nouveau.noaccel=0) is not currently expected to be fixed.
*** Bug 629685 has been marked as a duplicate of this bug. ***
The update solves the problem for my Lenovo W510 when used standalone, but when connected to a docking station and second monitor it just gives a blank screen on both (just see a cursor). Likewise if I start the machine undocked it works fine, but as soon as I dock both screens just show a cursor. I got the same problem on previous kernel with nouveau.noaccel=1.
(In reply to comment #38) > The update solves the problem for my Lenovo W510 when used standalone, but when > connected to a docking station and second monitor it just gives a blank screen > on both (just see a cursor). > > Likewise if I start the machine undocked it works fine, but as soon as I dock > both screens just show a cursor. > > I got the same problem on previous kernel with nouveau.noaccel=1. Completely separate issue.
Not sure if this is the same bug, but after upgrade to F-14 it hangs again, but this time screen gets garbled before the hang (letters no longer looks like letters). This can be found in dmesg output: ... SELinux: initialized (dev fuse, type fuse), uses genfs_contexts [drm] nouveau 0000:02:00.0: PFIFO_DMA_PUSHER - Ch 2 Get 0x0020072308 Put 0x0020073e20 IbGet 0x000003d2 IbPut 0x000003ff State 0x80000000 Push 0x00406040 [drm] nouveau 0000:02:00.0: PGRAPH_DATA_ERROR - Ch 2/5 Class 0x8297 Mthd 0x1360 Data 0x00000000:0x00000001 [drm] nouveau 0000:02:00.0: PGRAPH_DATA_ERROR - unknown value 0x0000000d [drm] nouveau 0000:02:00.0: PGRAPH_DATA_ERROR - Ch 2/5 Class 0x8297 Mthd 0x1340 Data 0x00004001:0x00008006 [drm] nouveau 0000:02:00.0: PGRAPH_DATA_ERROR - unknown value 0x0000000d [drm] nouveau 0000:02:00.0: PGRAPH_DATA_ERROR - Ch 2/5 Class 0x8297 Mthd 0x1344 Data 0x00004001:0x00004001 [drm] nouveau 0000:02:00.0: PGRAPH_DATA_ERROR - unknown value 0x0000000d [drm] nouveau 0000:02:00.0: PGRAPH_DATA_ERROR - Ch 2/5 Class 0x8297 Mthd 0x1348 Data 0x00008006:0x00004001 [drm] nouveau 0000:02:00.0: PGRAPH_DATA_ERROR - unknown value 0x0000000d [drm] nouveau 0000:02:00.0: PGRAPH_DATA_ERROR - Ch 2/5 Class 0x8297 Mthd 0x134c Data 0x00008006:0x00008006 [drm] nouveau 0000:02:00.0: PGRAPH_DATA_ERROR - unknown value 0x0000000d [drm] nouveau 0000:02:00.0: PGRAPH_DATA_ERROR - Ch 2/5 Class 0x8297 Mthd 0x1350 Data 0x00000000:0x00004001 [drm] nouveau 0000:02:00.0: PGRAPH_DATA_ERROR - unknown value 0x0000000d [drm] nouveau 0000:02:00.0: PGRAPH_DATA_ERROR - Ch 2/5 Class 0x8297 Mthd 0x1358 Data 0x00000000:0x00004001 [drm] nouveau 0000:02:00.0: PGRAPH_DATA_ERROR - unknown value 0x0000000d [drm] nouveau 0000:02:00.0: PGRAPH_DATA_ERROR - Ch 2/5 Class 0x8297 Mthd 0x155c Data 0x00000000:0x00000000 [drm] nouveau 0000:02:00.0: PGRAPH_DATA_ERROR - unknown value 0x0000000d [drm] nouveau 0000:02:00.0: PGRAPH_DATA_ERROR - Ch 2/5 Class 0x8297 Mthd 0x1560 Data 0x00000000:0x409e3000 [drm] nouveau 0000:02:00.0: PGRAPH_DATA_ERROR - unknown value 0x0000000d [drm] nouveau 0000:02:00.0: PGRAPH_DATA_ERROR - Ch 2/5 Class 0x8297 Mthd 0x1564 Data 0x00000000:0x00000000 [drm] nouveau 0000:02:00.0: PGRAPH_DATA_ERROR - unknown value 0x0000000d [drm] nouveau 0000:02:00.0: PFIFO_DMA_PUSHER - Ch 2 Get 0x002004190c Put 0x0020043e9c IbGet 0x000003d4 IbPut 0x0000041d State 0x80000000 Push 0x00406040 [drm] nouveau 0000:02:00.0: PGRAPH_DATA_ERROR - Ch 2/5 Class 0x8297 Mthd 0x1360 Data 0x00000000:0x00000001 [drm] nouveau 0000:02:00.0: PGRAPH_DATA_ERROR - unknown value 0x0000000d [drm] nouveau 0000:02:00.0: PGRAPH_DATA_ERROR - Ch 2/5 Class 0x8297 Mthd 0x1340 Data 0x00004001:0x00008006 [drm] nouveau 0000:02:00.0: PGRAPH_DATA_ERROR - unknown value 0x0000000d [drm] nouveau 0000:02:00.0: PGRAPH_DATA_ERROR - Ch 2/5 Class 0x8297 Mthd 0x1344 Data 0x00004001:0x00004001 [drm] nouveau 0000:02:00.0: PGRAPH_DATA_ERROR - unknown value 0x0000000d [drm] nouveau 0000:02:00.0: PGRAPH_DATA_ERROR - Ch 2/5 Class 0x8297 Mthd 0x1348 Data 0x00008006:0x00004001 [drm] nouveau 0000:02:00.0: PGRAPH_DATA_ERROR - unknown value 0x0000000d [drm] nouveau 0000:02:00.0: PGRAPH_DATA_ERROR - Ch 2/5 Class 0x8297 Mthd 0x134c Data 0x00008006:0x00008006 [drm] nouveau 0000:02:00.0: PGRAPH_DATA_ERROR - unknown value 0x0000000d [drm] nouveau 0000:02:00.0: PGRAPH_DATA_ERROR - Ch 2/5 Class 0x8297 Mthd 0x1350 Data 0x00000000:0x00004001 [drm] nouveau 0000:02:00.0: PGRAPH_DATA_ERROR - unknown value 0x0000000d [drm] nouveau 0000:02:00.0: PGRAPH_DATA_ERROR - Ch 2/5 Class 0x8297 Mthd 0x1358 Data 0x00000000:0x00004001 [drm] nouveau 0000:02:00.0: PGRAPH_DATA_ERROR - unknown value 0x0000000d [drm] nouveau 0000:02:00.0: PGRAPH_DATA_ERROR - Ch 2/5 Class 0x8297 Mthd 0x155c Data 0x00000000:0x00000000 [drm] nouveau 0000:02:00.0: PGRAPH_DATA_ERROR - unknown value 0x0000000d [drm] nouveau 0000:02:00.0: PGRAPH_DATA_ERROR - Ch 2/5 Class 0x8297 Mthd 0x1560 Data 0x00000000:0x409e3000 [drm] nouveau 0000:02:00.0: PGRAPH_DATA_ERROR - unknown value 0x0000000d [drm] nouveau 0000:02:00.0: PGRAPH_DATA_ERROR - Ch 2/5 Class 0x8297 Mthd 0x1564 Data 0x00000000:0x00000000 [drm] nouveau 0000:02:00.0: PGRAPH_DATA_ERROR - unknown value 0x0000000d [drm] nouveau 0000:02:00.0: PFIFO_DMA_PUSHER - Ch 2 Get 0x0020052d04 Put 0x0020053e24 IbGet 0x000003d6 IbPut 0x00000421 State 0x80000004 Push 0x00406040 [drm] nouveau 0000:02:00.0: PFIFO_DMA_PUSHER - Ch 2 Get 0x00200703c8 Put 0x002007046c IbGet 0x000003e2 IbPut 0x00000427 State 0x40000004 Push 0x00406040 [drm] nouveau 0000:02:00.0: PFIFO_DMA_PUSHER - Ch 2 Get 0x002007046c Put 0x0020070530 IbGet 0x000003e4 IbPut 0x00000427 State 0x80002054 Push 0x00406040 [drm] nouveau 0000:02:00.0: PFIFO_DMA_PUSHER - Ch 2 Get 0x0020070530 Put 0x0020071a58 IbGet 0x000003e6 IbPut 0x00000427 State 0x80002054 Push 0x00406040 [drm] nouveau 0000:02:00.0: PFIFO_DMA_PUSHER - Ch 2 Get 0x0020071b34 Put 0x0020071bf4 IbGet 0x000003ec IbPut 0x00000427 State 0x80000001 Push 0x00406040 [drm] nouveau 0000:02:00.0: PFIFO_DMA_PUSHER - Ch 2 Get 0x0020071bfc Put 0x0020071cb8 IbGet 0x000003ee IbPut 0x00000427 State 0x40000004 Push 0x00406040 [drm] nouveau 0000:02:00.0: PFIFO_DMA_PUSHER - Ch 2 Get 0x0020071cb8 Put 0x0020071de8 IbGet 0x000003f0 IbPut 0x00000427 State 0x80002054 Push 0x00406040 [drm] nouveau 0000:02:00.0: PFIFO_DMA_PUSHER - Ch 2 Get 0x0020024d24 Put 0x0020024d28 IbGet 0x000003f3 IbPut 0x00000429 State 0x8000b354 Push 0x00406040 ... ... happened 3 times so far kernel-2.6.35.6-39.fc14.x86_64 mesa-libGLU-7.9-1.fc14.x86_64 (happened with old 7.9-0.8.1 too) libdrm-2.4.22-1.fc14.x86_6