Description of problem: I experience a total hang of the Xserver quite often. It doesn't respond at all, not even to Ctrl-Alt-F?. I could login from other machine, so it is only the X server which is frozen. The only strange messages I have found from the server are: kernel: [drm] nouveau 0000:01:00.0: timeout: (0x100c80 & 1) == 0 (2) kernel: [drm] nouveau 0000:01:00.0: 0x100c80 = 0x00000001 kernel: [drm] nouveau 0000:01:00.0: PFIFO_INTR 0x04000000 - Ch 2 kernel: [drm] nouveau 0000:01:00.0: timeout: (0x100c80 & 1) == 0 (2) kernel: [drm] nouveau 0000:01:00.0: 0x100c80 = 0x00050001 kernel: [drm] nouveau 0000:01:00.0: PFIFO_INTR 0x04000000 - Ch 2 kernel: [drm] nouveau 0000:01:00.0: timeout: (0x100c80 & 1) == 0 (2) kernel: [drm] nouveau 0000:01:00.0: 0x100c80 = 0x00050001 Needless to say it is a very serious bug for a production machine like mine. I am using the xfwm window manager with composite effects enabled. The same machine with Fedora 11 and the default nouveau driver provided in that distribution worked fine during two years (with regular updates). How reproducible: It is hard to say. But here are a couple of situations that I have identified: 1. When switching "fast" between virtual desktops and some of the windows of the desktop I leave where still refreshing or working with the display. I am using XFCE4. 2. Several tabs in firefox are displaying content and I switch from one to the other when the content is still being rendered. 3. It happens twice that the freeze appeared while the screen saver euler-2d from the xscreensaver was active. It looks like it is a good candidate for a X server hang. Additional info: My video card: [ 40.477] (--) PCI:*(0:1:0:0) 10de:042f:10de:0492 nVidia Corporation G86 [Quadro NVS 290] rev 161, Mem @ 0xfd000000/16777216, 0xd0000000/268435456, 0xfa000000/33554432, I/O @ 0x0000dc80/128, BIOS @ 0x????????/131072 The resolution I use: DVI-I-1 connected 1920x1200+0+0 (normal left inverted right x axis y axis) 519mm x 324mm
This bug is known upstream, however, none of the devs (myself included) actually have the effected hardware to track it down. The issue is specific to NV86 chipsets (which I believe the NVS290 is). Today I'll look at cooking up a kernel build with some experimental options to try, but really, we're shooting in the dark here. I'll post here again later with a link to a scratch build.
Assuming the build completes OK, there's a kernel scratch build with a *possible* fix here: http://koji.fedoraproject.org/koji/taskinfo?taskID=2442709 I know it's a F14 kernel, but backporting this to F13 will probably require quite a bit more effort. I'll only bother doing that once we have a fix that actually works.
Thanks, from the link above it seems that the build failed: BuildError: error building package (arch i686) Is there any interesting information I could grab if I experience a hang again? For instance pstack of the xserver process? Regards
Sorry about that! My bad for submitting a patch right before bed :) It failed due to some minor differences between upstream and fedora nouveau. New build: http://koji.fedoraproject.org/koji/taskinfo?taskID=2444212 There's not really any additional info to get. The messages about 0x100c80 timing out are the clue here already.
I installed it but I cannot reboot still. I also received kernel 2.6.34.6-47.fc13.x86_64 through regular updates. Is it worth testing that one as well? Regards.
Can't reboot? No, the kernel in updates doesn't have the test patches I put into the scratch build above. I'll leave NEEDINFO set until you're able to test :)
Hi! I have installed the new kernel but still the same problem happens. Here are the messages from the nouveau kernel module: Sep 8 01:55:07 ga014699 kernel: [drm] nouveau 0000:01:00.0: PGRAPH_DATA_ERROR - Ch 2/2 Class 0x502d Mthd 0x08dc Data 0x00000000:0x00000000 Sep 8 01:55:07 ga014699 kernel: [drm] nouveau 0000:01:00.0: PGRAPH_DATA_ERROR - unknown value 0x00000034 Sep 8 01:55:07 ga014699 kernel: [drm] nouveau 0000:01:00.0: PGRAPH_DATA_ERROR - Ch 2/2 Class 0x502d Mthd 0x08dc Data 0x00000000:0x00000000 Sep 8 01:55:07 ga014699 kernel: [drm] nouveau 0000:01:00.0: PGRAPH_DATA_ERROR - unknown value 0x00000034 Sep 8 01:55:07 ga014699 kernel: [drm] nouveau 0000:01:00.0: PGRAPH_DATA_ERROR - Ch 2/2 Class 0x502d Mthd 0x08dc Data 0x00000001:0x00000001 Sep 8 01:55:07 ga014699 kernel: [drm] nouveau 0000:01:00.0: PGRAPH_DATA_ERROR - unknown value 0x00000034 Sep 8 01:55:07 ga014699 kernel: [drm] nouveau 0000:01:00.0: PGRAPH_DATA_ERROR - Ch 2/2 Class 0x502d Mthd 0x08dc Data 0x00000013:0x00000013 Sep 8 01:55:07 ga014699 kernel: [drm] nouveau 0000:01:00.0: PGRAPH_DATA_ERROR - unknown value 0x00000034 Sep 8 01:55:07 ga014699 kernel: [drm] nouveau 0000:01:00.0: PFIFO_DMA_PUSHER - Ch 2 Sep 8 01:55:07 ga014699 kernel: [drm] nouveau 0000:01:00.0: PGRAPH_DATA_ERROR - Ch 2/2 Class 0x502d Mthd 0x08cc Data 0x00042050:0x00042050 Sep 8 01:55:07 ga014699 kernel: [drm] nouveau 0000:01:00.0: PGRAPH_DATA_ERROR - INVALID_VALUE All these messages happened while the screensaver was working and the monitor switched off. When I switched on the monitor, the Xserver was already dead. Here are the messages from that moment: Sep 8 09:55:43 ga014699 kernel: [drm] nouveau 0000:01:00.0: unplugged DVI-I-1 Sep 8 09:55:43 ga014699 kernel: [drm] nouveau 0000:01:00.0: plugged DVI-I-1 Sep 8 09:55:45 ga014699 kernel: [drm] nouveau 0000:01:00.0: unplugged DVI-I-1 Sep 8 09:55:45 ga014699 kernel: [drm] nouveau 0000:01:00.0: plugged DVI-I-1 Sep 8 09:58:10 ga014699 kernel: [drm] nouveau 0000:01:00.0: nouveau_channel_free: freeing fifo 2 Sep 8 09:58:10 ga014699 kernel: [drm] nouveau 0000:01:00.0: Failed to idle channel 2. Sep 8 09:58:10 ga014699 kernel: [drm] nouveau 0000:01:00.0: PFIFO_DMA_PUSHER - Ch 127 Sep 8 09:58:17 ga014699 kernel: [drm] nouveau 0000:01:00.0: GPU lockup - switching to software fbcon Sep 8 09:58:18 ga014699 kernel: [drm] nouveau 0000:01:00.0: Allocating FIFO number 2 Sep 8 09:58:18 ga014699 kernel: [drm] nouveau 0000:01:00.0: nouveau_channel_alloc: initialised FIFO 2 The Xserver was taking up to 100% of the CPU, here is the pstack: #0 0x0000003c790d95a7 in ioctl () from /lib64/libc.so.6 #1 0x0000003c91c03388 in drmIoctl () from /usr/lib64/libdrm.so.2 #2 0x0000003c91c0360b in drmCommandWrite () from /usr/lib64/libdrm.so.2 #3 0x00007fe4c63cadfd in ?? () from /usr/lib64/libdrm_nouveau.so.1 #4 0x00007fe4c63cafee in nouveau_bo_map_range () from /usr/lib64/libdrm_nouveau.so.1 #5 0x00007fe4c63ca07a in ?? () from /usr/lib64/libdrm_nouveau.so.1 #6 0x00007fe4c63ca450 in nouveau_pushbuf_flush () from /usr/lib64/libdrm_nouveau.so.1 #7 0x00007fe4c575f655 in ?? () from /usr/lib64/xorg/modules/libexa.so #8 0x00007fe4c57601fa in ?? () from /usr/lib64/xorg/modules/libexa.so #9 0x00000000004de91b in ?? () #10 0x000000000056dbc7 in ?? () #11 0x000000000056dca3 in miCompositeRects () #12 0x00000000004d26a4 in ?? () #13 0x000000000043619c in ?? () #14 0x000000000042189a in _start () Hope it helps..
That's not actually the same problem. Can you post your full kernel log from after this problem please :)
Here it is: Sep 7 20:02:40 ga014699 ntpd[1730]: Deleting interface #13 virbr1, 192.168.150.1#123, interface stats: received=0, sent=0, dropped=0, active_time=811 secs Sep 8 00:26:30 ga014699 kernel: gzip used greatest stack depth: 3008 bytes left Sep 8 00:49:20 ga014699 kernel: gzip used greatest stack depth: 2864 bytes left Sep 8 00:52:54 ga014699 kernel: lt-ird_requirem[6775]: segfault at 0 ip 000000000040f6c2 sp 00007fff4d489020 error 4 in lt-ird_requirement_tests[400000+26000] Sep 8 01:55:07 ga014699 kernel: [drm] nouveau 0000:01:00.0: PGRAPH_DATA_ERROR - Ch 2/2 Class 0x502d Mthd 0x08dc Data 0x00000000:0x00000000 Sep 8 01:55:07 ga014699 kernel: [drm] nouveau 0000:01:00.0: PGRAPH_DATA_ERROR - unknown value 0x00000034 Sep 8 01:55:07 ga014699 kernel: [drm] nouveau 0000:01:00.0: PGRAPH_DATA_ERROR - Ch 2/2 Class 0x502d Mthd 0x08dc Data 0x00000000:0x00000000 Sep 8 01:55:07 ga014699 kernel: [drm] nouveau 0000:01:00.0: PGRAPH_DATA_ERROR - unknown value 0x00000034 Sep 8 01:55:07 ga014699 kernel: [drm] nouveau 0000:01:00.0: PGRAPH_DATA_ERROR - Ch 2/2 Class 0x502d Mthd 0x08dc Data 0x00000001:0x00000001 Sep 8 01:55:07 ga014699 kernel: [drm] nouveau 0000:01:00.0: PGRAPH_DATA_ERROR - unknown value 0x00000034 Sep 8 01:55:07 ga014699 kernel: [drm] nouveau 0000:01:00.0: PGRAPH_DATA_ERROR - Ch 2/2 Class 0x502d Mthd 0x08dc Data 0x00000013:0x00000013 Sep 8 01:55:07 ga014699 kernel: [drm] nouveau 0000:01:00.0: PGRAPH_DATA_ERROR - unknown value 0x00000034 Sep 8 01:55:07 ga014699 kernel: [drm] nouveau 0000:01:00.0: PFIFO_DMA_PUSHER - Ch 2 Sep 8 01:55:07 ga014699 kernel: [drm] nouveau 0000:01:00.0: PGRAPH_DATA_ERROR - Ch 2/2 Class 0x502d Mthd 0x08cc Data 0x00042050:0x00042050 Sep 8 01:55:07 ga014699 kernel: [drm] nouveau 0000:01:00.0: PGRAPH_DATA_ERROR - INVALID_VALUE Sep 8 07:06:08 ga014699 kernel: lt-ird_requirem[26301]: segfault at 0 ip 000000000040f6a2 sp 00007fff8e11b5d0 error 4 in lt-ird_requirement_tests[400000+26000] Sep 8 09:55:43 ga014699 kernel: [drm] nouveau 0000:01:00.0: unplugged DVI-I-1 Sep 8 09:55:43 ga014699 kernel: [drm] nouveau 0000:01:00.0: plugged DVI-I-1 Sep 8 09:55:45 ga014699 kernel: [drm] nouveau 0000:01:00.0: unplugged DVI-I-1 Sep 8 09:55:45 ga014699 kernel: [drm] nouveau 0000:01:00.0: plugged DVI-I-1 Sep 8 09:58:10 ga014699 kernel: [drm] nouveau 0000:01:00.0: nouveau_channel_free: freeing fifo 2 Sep 8 09:58:10 ga014699 kernel: [drm] nouveau 0000:01:00.0: Failed to idle channel 2. Sep 8 09:58:10 ga014699 kernel: [drm] nouveau 0000:01:00.0: PFIFO_DMA_PUSHER - Ch 127 Sep 8 09:58:12 ga014699 NetworkManager[1433]: <error> [1283932692.217202] [nm-manager.c:1328] user_proxy_init(): could not init user settings proxy: (3) Could not get owner of name 'org.freedesktop.NetworkManagerUserSettings': no such name Sep 8 09:58:17 ga014699 kernel: [drm] nouveau 0000:01:00.0: GPU lockup - switching to software fbcon Sep 8 09:58:18 ga014699 kernel: [drm] nouveau 0000:01:00.0: Allocating FIFO number 2 Sep 8 09:58:18 ga014699 kernel: [drm] nouveau 0000:01:00.0: nouveau_channel_alloc: initialised FIFO 2 Regards
Since a couple of kernels ago, i do experience frecuent xorg (nouveau related) freezes. They are random, but frecuent. There are two types of freezes: type1: xorg freezes, mouse moves, everything else does not. (need to login via ssh and reboot) type2: xorg freezes, black screen, after leaving for a while, it remains black after pressing a key... (need to login via ssh and reboot) I got tired of not having proper xv support (i noticed that it was disabled by default at some point, and i did not had any freezes when using nouveau whitout acceration [for many days...]) so i re-enabled nouveau acceleration. The freeze returned fast and furious. (the type2) # lspci | grep -i vga 02:00.0 VGA compatible controller: nVidia Corporation GT216 [GeForce GT 220] (rev a2) Sep 11 18:22:58 ulquiorra kernel: imklog 4.4.2, log source = /proc/kmsg started. Sep 11 18:22:58 ulquiorra rsyslogd: [origin software="rsyslogd" swVersion="4.4.2" x-pid="1364" x-info="http://www.rsyslog.com"] (re)start Sep 11 18:22:58 ulquiorra kernel: Initializing cgroup subsys cpuset Sep 11 18:22:58 ulquiorra kernel: Initializing cgroup subsys cpu Sep 11 18:22:58 ulquiorra kernel: Linux version 2.6.34.6-54.fc13.x86_64 (mockbuild.fedoraproject.org) (gcc version 4.4.4 20100630 (Red Hat 4.4.4-10) (GCC) ) #1 SMP Sun Sep 5 17:16:27 UTC 2010 Sep 11 18:22:58 ulquiorra kernel: Command line: ro root=UUID=7ae986e0-70bc-4c83-854d-04f54526801d rd_NO_LUKS rd_NO_LVM rd_NO_DM LANG=en_US.UTF-8 SYSFONT=latarcyrheb-sun16 KEYBOARDTYPE=pc KEYTABLE=es rhgb quiet pcie_aspm=off nouveau.noaccel=0 Sep 11 18:22:58 ulquiorra kernel: BIOS-provided physical RAM map: Sep 11 18:23:02 ulquiorra kernel: [drm] nouveau 0000:02:00.0: nouveau_channel_alloc: initialised FIFO 2 Sep 11 18:23:03 ulquiorra kernel: lo: Disabled Privacy Extensions Sep 11 18:23:03 ulquiorra libvirtd: 18:23:03.458: warning : lxcStartup:1908 : Unable to create cgroup for driver: No such device or address Sep 11 18:36:33 ulquiorra polkitd[2315]: started daemon version 0.96 using authority implementation `local' version `0.96' Sep 11 18:36:34 ulquiorra rtkit-daemon[2322]: Sucessfully made thread 2320 of process 2320 (/usr/bin/pulseaudio) owned by '500' high priority at nice level -11. Sep 11 18:36:34 ulquiorra rtkit-daemon[2322]: Sucessfully made thread 2333 of process 2320 (/usr/bin/pulseaudio) owned by '500' RT at priority 5. Sep 11 18:36:34 ulquiorra rtkit-daemon[2322]: Sucessfully made thread 2334 of process 2320 (/usr/bin/pulseaudio) owned by '500' RT at priority 5. Sep 11 18:36:34 ulquiorra rtkit-daemon[2322]: Sucessfully made thread 2335 of process 2320 (/usr/bin/pulseaudio) owned by '500' RT at priority 5. Sep 11 18:36:34 ulquiorra rtkit-daemon[2322]: Sucessfully made thread 2336 of process 2336 (/usr/bin/pulseaudio) owned by '500' high priority at nice level -11. Sep 11 18:36:34 ulquiorra pulseaudio[2336]: pid.c: Daemon already running. Sep 11 18:36:35 ulquiorra kernel: hda-intel: IRQ timing workaround is activated for card #1. Suggest a bigger bdl_pos_adj. Sep 11 18:36:37 ulquiorra rtkit-daemon[2322]: Sucessfully made thread 2365 of process 2365 (/usr/bin/pulseaudio) owned by '500' high priority at nice level -11. Sep 11 18:36:37 ulquiorra pulseaudio[2365]: pid.c: Daemon already running. Sep 11 18:36:37 ulquiorra rtkit-daemon[2322]: Sucessfully made thread 2374 of process 2374 (/usr/bin/pulseaudio) owned by '500' high priority at nice level -11. Sep 11 18:36:37 ulquiorra pulseaudio[2374]: pid.c: Daemon already running. Sep 11 19:14:18 ulquiorra abrt[2959]: saved core dump of pid 1821 (/usr/bin/Xorg) to /var/spool/abrt/ccpp-1284243257-1821.new/coredump (23330816 bytes) Sep 11 19:14:18 ulquiorra abrtd: Directory 'ccpp-1284243257-1821' creation detected Sep 11 19:14:18 ulquiorra kernel: [drm] nouveau 0000:02:00.0: nouveau_channel_free: freeing fifo 2 Sep 11 19:14:27 ulquiorra kernel: [drm] nouveau 0000:02:00.0: Failed to idle channel 2. Sep 11 19:14:27 ulquiorra kernel: [drm] nouveau 0000:02:00.0: PGRAPH idle timed out with status 0x001e0001 Sep 11 19:14:27 ulquiorra kernel: [drm] nouveau 0000:02:00.0: PGRAPH idle timed out with status 0x001e0001 Sep 11 19:14:27 ulquiorra kernel: [drm] nouveau 0000:02:00.0: PGRAPH idle timed out with status 0x001e0101 Sep 11 19:14:27 ulquiorra kdm[1797]: X server for display :0 terminated unexpectedly Sep 11 19:14:27 ulquiorra abrtd: New crash /var/spool/abrt/ccpp-1284243257-1821, processing Sep 11 19:14:27 ulquiorra abrtd: Registered Action plugin 'RunApp' Sep 11 19:14:27 ulquiorra abrtd: RunApp('/var/spool/abrt/ccpp-1284243257-1821','test x"`cat component`" = x"xorg-x11-server-Xorg" && cp /var/log/Xorg.0.log .') Sep 11 19:14:28 ulquiorra kernel: [drm] nouveau 0000:02:00.0: Allocating FIFO number 2 Sep 11 19:14:28 ulquiorra kernel: [drm] nouveau 0000:02:00.0: nouveau_channel_alloc: initialised FIFO 2 I logged in via ssh and noticed that process X takes 100% cpu. I rebooted the machine. [root@ulquiorra abrt]# ls -l /var/spool/abrt total 52 -rw-r--r--. 1 root root 5120 Sep 11 19:14 abrt-db drwxr-x---. 2 abrt root 4096 Sep 4 11:53 ccpp-1283611978-1727 drwxr-x---. 2 abrt root 4096 Sep 4 13:01 ccpp-1283616106-1763 drwxr-x---. 2 abrt root 4096 Sep 4 19:32 ccpp-1283639570-1817 drwxr-x---. 2 abrt root 4096 Sep 10 08:21 ccpp-1284117665-1845 drwxr-x---. 2 abrt root 4096 Sep 10 15:35 ccpp-1284143713-1795 drwxr-x---. 2 abrt root 4096 Sep 11 19:14 ccpp-1284243257-1821 drwxr-x---. 2 abrt root 4096 Sep 7 20:15 kerneloops-1283901341-1648-1 drwxr-x---. 2 abrt root 4096 Sep 7 20:15 kerneloops-1283901341-1648-2 drwxr-x---. 2 abrt root 4096 Sep 7 22:43 kerneloops-1283910221-1648-1 drwxr-x---. 2 abrt root 4096 Sep 8 23:36 kerneloops-1283999782-1672-1 -rw-------. 1 root root 13 Sep 11 19:14 last-ccpp The hardware is Phenom II X3 710 on a M4N72-E (nvidia MCP78S), GPU is XFX GT220 1gb DDR3 ----- I also saw the type1 feeze happen on my sister's Asus UL80vt (Hybrid GPU intel/nvidia) but i do not know if it is related or not. (also F13 64-bit)
(In reply to comment #10) > I got tired of not having proper xv support (i noticed that it was > disabled by default at some point, and i did not had any freezes > when using nouveau whitout acceration [for many days...]) so i > re-enabled nouveau acceleration. > The freeze returned fast and furious. (the type2) Of course it returned, the entire reason we disabled acceleration on these chips by default was because of this hang. > ----- > I also saw the type1 feeze happen on my sister's Asus UL80vt (Hybrid GPU > intel/nvidia) but > i do not know if it is related or not. (also F13 64-bit) It's not related.
This message is a reminder that Fedora 13 is nearing its end of life. Approximately 30 (thirty) days from now Fedora will stop maintaining and issuing updates for Fedora 13. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as WONTFIX if it remains open with a Fedora 'version' of '13'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version prior to Fedora 13's end of life. Bug Reporter: Thank you for reporting this issue and we are sorry that we may not be able to fix it before Fedora 13 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora please change the 'version' of this bug to the applicable version. If you are unable to change the version, please add a comment here and someone will do it for you. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete. The process we are following is described here: http://fedoraproject.org/wiki/BugZappers/HouseKeeping
Fedora 13 changed to end-of-life (EOL) status on 2011-06-25. Fedora 13 is no longer maintained, which means that it will not receive any further security or bug fix updates. As a result we are closing this bug. If you can reproduce this bug against a currently maintained version of Fedora please feel free to reopen this bug against that version. Thank you for reporting this bug and we are sorry it could not be fixed.