Created attachment 407505 [details] xorg 0 log Description of problem: It happened twice so far (today) - X server froze. I killed everything using SysRq. In terminal there was: [drm] nouveau 0000:02:00.0: nouveau_channel_free: freeing fifo ... [drm] nouveau 0000:02:00.0: GPU lockup - switching to software ... I took wrong picture so the rest of lines is missing. I don't know if it is the cause of X lockup or caused by killing everything with SysRq. Version-Release number of selected component (if applicable): kernel-2.6.33.2-49.fc13.x86_64 xorg-x11-drv-nouveau-0.0.16-3.20100305git6b8b157.fc13.x86_64 xorg-x11-server-common-1.8.0-6.fc13.x86_64 How reproducible: happend twice so far Steps to Reproduce: 1.can't reproduce intentionally 2. 3. Actual results: X server freeze Expected results: no freezing Additional info: [ 1474.578] [mi] EQ overflowing. The server is probably stuck in an infinite loop. Backtrace: [ 1474.595] 0: /usr/bin/X (xorg_backtrace+0x28) [0x49e6f8] [ 1474.595] 1: /usr/bin/X (mieqEnqueue+0x1f4) [0x49e0a4] [ 1474.595] 2: /usr/bin/X (xf86PostMotionEventP+0xc4) [0x477e14] [ 1474.595] 3: /usr/lib64/xorg/modules/input/evdev_drv.so (0x7ff5a0d8c000+0x3dbf) [0x7ff5a0d8fdbf] [ 1474.595] 4: /usr/bin/X (0x400000+0x6aad7) [0x46aad7] [ 1474.595] 5: /usr/bin/X (0x400000+0x117b33) [0x517b33] [ 1474.595] 6: /lib64/libc.so.6 (0x32de800000+0x339d0) [0x32de8339d0] [ 1474.595] 7: /usr/lib64/xorg/modules/drivers/nouveau_drv.so (0x7ff5a225e000+0x1fae8) [0x7ff5a227dae8] [ 1474.595] 8: /usr/lib64/xorg/modules/drivers/nouveau_drv.so (0x7ff5a225e000+0x205f0) [0x7ff5a227e5f0] [ 1474.595] 9: /usr/lib64/libdrm_nouveau.so.1 (nouveau_pushbuf_flush+0x1a2) [0x7ff5a205b462] [ 1474.595] 10: /usr/lib64/xorg/modules/libexa.so (0x7ff5a11bd000+0x9645) [0x7ff5a11c6645] [ 1474.595] 11: /usr/lib64/xorg/modules/libexa.so (0x7ff5a11bd000+0xa1ea) [0x7ff5a11c71ea] [ 1474.595] 12: /usr/bin/X (0x400000+0xd2afb) [0x4d2afb] [ 1474.595] 13: /usr/lib64/xorg/modules/libexa.so (0x7ff5a11bd000+0xb44d) [0x7ff5a11c844d] [ 1474.595] 14: /usr/bin/X (0x400000+0xd24fe) [0x4d24fe] [ 1474.595] 15: /usr/bin/X (0x400000+0xcc89e) [0x4cc89e] [ 1474.595] 16: /usr/bin/X (0x400000+0x2c32c) [0x42c32c] [ 1474.595] 17: /usr/bin/X (0x400000+0x219ca) [0x4219ca] [ 1474.595] 18: /lib64/libc.so.6 (__libc_start_main+0xfd) [0x32de81ed2d] [ 1474.595] 19: /usr/bin/X (0x400000+0x21579) [0x421579]
In my /var/log/kernel (I use this since F-12 to log kernel messages outside of messages, because nouveau causes tons of messages): after grep -v of: Apr 19 10:29:26 krles kernel: DRHD: handling fault status reg 2 Apr 19 10:29:26 krles kernel: DMAR:[DMA Read] Request device [02:00.0] fault addr 0 Apr 19 10:29:26 krles kernel: DMAR:[fault reason 06] PTE Read access is not set but these messages were present in F-12 since 2.6.32 kernels and there were no lockups the content is: Apr 19 10:06:29 krles kernel: [drm] nouveau 0000:02:00.0: Allocating FIFO number 2 Apr 19 10:06:29 krles kernel: [drm] nouveau 0000:02:00.0: nouveau_channel_alloc: initialised FIFO 2 Apr 19 10:06:29 krles kernel: [drm] nouveau 0000:02:00.0: Allocating FIFO number 3 Apr 19 10:06:29 krles kernel: [drm] nouveau 0000:02:00.0: nouveau_channel_alloc: initialised FIFO 3 Apr 19 10:06:39 krles kernel: readahead-colle used greatest stack depth: 3104 bytes left Apr 19 10:06:39 krles kernel: readahead-collector: starting delayed service auditd Apr 19 10:06:39 krles kernel: readahead-collector: sorting Apr 19 10:06:39 krles kernel: readahead-collector: finished Apr 19 10:11:48 krles kernel: dbus-launch used greatest stack depth: 2992 bytes left Apr 19 10:12:09 krles kernel: fuse init (API version 7.13) Apr 19 10:12:09 krles kernel: SELinux: initialized (dev fuse, type fuse), uses genfs_contexts Apr 19 10:13:05 krles kernel: DMA-API: debugging out of memory - disabling Apr 19 10:13:05 krles kernel: Apr 19 10:13:05 krles kernel: ======================================================= Apr 19 10:13:05 krles kernel: [ INFO: possible circular locking dependency detected ] Apr 19 10:13:05 krles kernel: 2.6.33.2-49.fc13.x86_64 #1 Apr 19 10:13:05 krles kernel: ------------------------------------------------------- Apr 19 10:13:05 krles kernel: X/1504 is trying to acquire lock: Apr 19 10:13:05 krles kernel: (&mm->mmap_sem){++++++}, at: [<ffffffff810f2e30>] might_fault+0x5c/0xac Apr 19 10:13:05 krles kernel: Apr 19 10:13:05 krles kernel: but task is already holding lock: Apr 19 10:13:05 krles kernel: (&dev->struct_mutex){+.+.+.}, at: [<ffffffffa0093a67>] nouveau_gem_ioctl_pushbuf+0x1e8/0xcdd [nouveau] Apr 19 10:13:05 krles kernel: Apr 19 10:13:05 krles kernel: which lock already depends on the new lock. Apr 19 10:13:05 krles kernel: Apr 19 10:13:05 krles kernel: Apr 19 10:13:05 krles kernel: the existing dependency chain (in reverse order) is: Apr 19 10:13:05 krles kernel: Apr 19 10:13:05 krles kernel: -> #1 (&dev->struct_mutex){+.+.+.}: Apr 19 10:13:05 krles kernel: [<ffffffff8107f827>] __lock_acquire+0xb7d/0xd2c Apr 19 10:13:05 krles kernel: [<ffffffff8107fab2>] lock_acquire+0xdc/0x102 Apr 19 10:13:05 krles kernel: [<ffffffff81478e2d>] __mutex_lock_common+0x4b/0x392 Apr 19 10:13:05 krles kernel: [<ffffffff81479238>] mutex_lock_nested+0x3e/0x43 Apr 19 10:13:05 krles kernel: [<ffffffffa0031de9>] drm_mmap+0x38/0x5f [drm] Apr 19 10:13:05 krles kernel: [<ffffffffa00946e6>] nouveau_ttm_mmap+0x34/0x46 [nouveau] Apr 19 10:13:05 krles kernel: [<ffffffff810fb4d9>] mmap_region+0x2ac/0x4cb Apr 19 10:13:05 krles kernel: [<ffffffff810fb990>] do_mmap_pgoff+0x298/0x2fb Apr 19 10:13:05 krles kernel: [<ffffffff810fbae9>] sys_mmap_pgoff+0xf6/0x12e Apr 19 10:13:05 krles kernel: [<ffffffff8100de19>] sys_mmap+0x22/0x24 Apr 19 10:13:05 krles kernel: [<ffffffff81009c72>] system_call_fastpath+0x16/0x1b Apr 19 10:13:05 krles kernel: Apr 19 10:13:05 krles kernel: -> #0 (&mm->mmap_sem){++++++}: Apr 19 10:13:05 krles kernel: [<ffffffff8107f6d1>] __lock_acquire+0xa27/0xd2c Apr 19 10:13:05 krles kernel: [<ffffffff8107fab2>] lock_acquire+0xdc/0x102 Apr 19 10:13:05 krles kernel: [<ffffffff810f2e5d>] might_fault+0x89/0xac Apr 19 10:13:05 krles kernel: [<ffffffffa00932f7>] validate_list+0x211/0x26e [nouveau] Apr 19 10:13:05 krles kernel: [<ffffffffa0094528>] nouveau_gem_ioctl_pushbuf+0xca9/0xcdd [nouveau] Apr 19 10:13:05 krles kernel: [<ffffffffa002c418>] drm_ioctl+0x28f/0x373 [drm] Apr 19 10:13:05 krles kernel: [<ffffffff8112d118>] vfs_ioctl+0x32/0xa6 Apr 19 10:13:05 krles kernel: [<ffffffff8112d698>] do_vfs_ioctl+0x490/0x4d6 Apr 19 10:13:05 krles kernel: [<ffffffff8112d734>] sys_ioctl+0x56/0x79 Apr 19 10:13:05 krles kernel: [<ffffffff81009c72>] system_call_fastpath+0x16/0x1b Apr 19 10:13:05 krles kernel: Apr 19 10:13:05 krles kernel: other info that might help us debug this: Apr 19 10:13:05 krles kernel: Apr 19 10:13:05 krles kernel: 1 lock held by X/1504: Apr 19 10:13:05 krles kernel: #0: (&dev->struct_mutex){+.+.+.}, at: [<ffffffffa0093a67>] nouveau_gem_ioctl_pushbuf+0x1e8/0xcdd [nouveau] Apr 19 10:13:05 krles kernel: Apr 19 10:13:05 krles kernel: stack backtrace: Apr 19 10:13:05 krles kernel: Pid: 1504, comm: X Not tainted 2.6.33.2-49.fc13.x86_64 #1 Apr 19 10:13:05 krles kernel: Call Trace: Apr 19 10:13:05 krles kernel: [<ffffffff8107e881>] print_circular_bug+0xaf/0xbd Apr 19 10:13:05 krles kernel: [<ffffffff8107f6d1>] __lock_acquire+0xa27/0xd2c Apr 19 10:13:05 krles kernel: [<ffffffff8107fab2>] lock_acquire+0xdc/0x102 Apr 19 10:13:05 krles kernel: [<ffffffff810f2e30>] ? might_fault+0x5c/0xac Apr 19 10:13:05 krles kernel: [<ffffffff810f2e5d>] might_fault+0x89/0xac Apr 19 10:13:05 krles kernel: [<ffffffff810f2e30>] ? might_fault+0x5c/0xac Apr 19 10:13:05 krles kernel: [<ffffffffa0074fd1>] ? ttm_bo_validate+0xae/0xf7 [ttm] Apr 19 10:13:05 krles kernel: [<ffffffffa00932f7>] validate_list+0x211/0x26e [nouveau] Apr 19 10:13:05 krles kernel: [<ffffffffa0094528>] nouveau_gem_ioctl_pushbuf+0xca9/0xcdd [nouveau] Apr 19 10:13:05 krles kernel: [<ffffffffa002c418>] drm_ioctl+0x28f/0x373 [drm] Apr 19 10:13:05 krles kernel: [<ffffffffa009387f>] ? nouveau_gem_ioctl_pushbuf+0x0/0xcdd [nouveau] Apr 19 10:13:05 krles kernel: [<ffffffff810103a5>] ? sched_clock+0x9/0xd Apr 19 10:13:05 krles kernel: [<ffffffff810720f1>] ? sched_clock_local+0x1c/0x82 Apr 19 10:13:05 krles kernel: [<ffffffff8112d118>] vfs_ioctl+0x32/0xa6 Apr 19 10:13:05 krles kernel: [<ffffffff8112d698>] do_vfs_ioctl+0x490/0x4d6 Apr 19 10:13:05 krles kernel: [<ffffffff8112d734>] sys_ioctl+0x56/0x79 Apr 19 10:13:05 krles kernel: [<ffffffff81009c72>] system_call_fastpath+0x16/0x1b
I forgot, it's still the same hardware: http://www.smolts.org/client/show/pub_dffb6381-0143-4116-8c63-294567703534 02:00.0 VGA compatible controller [0300]: nVidia Corporation G86 [Quadro NVS 290] [10de:042f] (rev a1)
happened again, so the rest of lines > [drm] nouveau 0000:02:00.0: nouveau_channel_free: freeing fifo ... > [drm] nouveau 0000:02:00.0: GPU lockup - switching to software ... is "...freeing fifo 3" and "... switching to software fbcon"
Looks awfully like bug 568591 ... Ben, what do you think, is it a duplicate.
No, the symptoms are the same (lots of lockup situations will look like this) but it's completely different hardware so likely a different underlying cause.
With a dual-screen, the bug is easy to reproduce.
Well, I don't know if this is reproducible only with dual head, but I use two screens too
Same problem here, happens frequently with my dual-head setup. Maybe https://bugs.freedesktop.org/show_bug.cgi?id=26521 is relevant here. Last logged kernel message: kernel: [drm] nouveau 0000:01:00.0: PFIFO_DMA_PUSHER - Ch 2 Xorg.log: [ 2927.285] [mi] EQ overflowing. The server is probably stuck in an infinite loop. [ 2927.286] Backtrace: [ 2927.298] 0: /usr/bin/Xorg (xorg_backtrace+0x28) [0x49ed48] [ 2927.298] 1: /usr/bin/Xorg (mieqEnqueue+0x1f4) [0x49e6f4] [ 2927.298] 2: /usr/bin/Xorg (xf86PostMotionEventP+0xc4) [0x477e24] [ 2927.298] 3: /usr/lib64/xorg/modules/input/evdev_drv.so (0x7fc11b20d000+0x3dbf) [0x7fc11b210dbf] [ 2927.298] 4: /usr/bin/Xorg (0x400000+0x6aad7) [0x46aad7] [ 2927.298] 5: /usr/bin/Xorg (0x400000+0x118263) [0x518263] [ 2927.298] 6: /lib64/libc.so.6 (0x3534a00000+0x32a20) [0x3534a32a20] [ 2927.299] 7: /lib64/libc.so.6 (ioctl+0x7) [0x3534ad9597] [ 2927.299] 8: /usr/lib64/libdrm.so.2 (drmIoctl+0x28) [0x3b46c03388] [ 2927.299] 9: /usr/lib64/libdrm.so.2 (drmCommandWrite+0x1b) [0x3b46c0360b] [ 2927.299] 10: /usr/lib64/libdrm_nouveau.so.1 (0x7fc11d879000+0x2dfd) [0x7fc11d87bdfd] [ 2927.299] 11: /usr/lib64/libdrm_nouveau.so.1 (nouveau_bo_map_range+0xfe) [0x7fc11d87bfee] [ 2927.299] 12: /usr/lib64/libdrm_nouveau.so.1 (0x7fc11d879000+0x207a) [0x7fc11d87b07a] [ 2927.299] 13: /usr/lib64/libdrm_nouveau.so.1 (nouveau_pushbuf_flush+0x190) [0x7fc11d87b450] [ 2927.299] 14: /usr/lib64/xorg/modules/libexa.so (0x7fc11cc07000+0x90f Installed packages: kernel-2.6.33.6-147.fc13.x86_64 xorg-x11-drv-nouveau-0.0.16-7.20100423git13c1043.fc13.x86_64 xorg-x11-server-Xorg-1.8.2-1.fc13.x86_64 xorg-x11-server-common-1.8.2-1.fc13.x86_64
sorry, forgot the hardware: 01:00.0 VGA compatible controller: nVidia Corporation G84 [GeForce 8600 GT] (rev a1) (prog-if 00 [VGA controller]) Subsystem: ASUSTeK Computer Inc. Device 8243 Flags: bus master, fast devsel, latency 0, IRQ 16 Memory at fd000000 (32-bit, non-prefetchable) [size=16M] Memory at d0000000 (64-bit, prefetchable) [size=256M] Memory at fa000000 (64-bit, non-prefetchable) [size=32M] I/O ports at cc00 [size=128] Expansion ROM at fe9e0000 [disabled] [size=128K] Capabilities: [60] Power Management version 2 Capabilities: [68] MSI: Enable- Count=1/1 Maskable- 64bit+ Capabilities: [78] Express Endpoint, MSI 00 Capabilities: [100] Virtual Channel Capabilities: [128] Power Budgeting <?> Capabilities: [600] Vendor Specific Information: ID=0001 Rev=1 Len=024 <?> Kernel driver in use: nouveau Kernel modules: nouveau, nvidiafb
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.