no more X on intel based chip (Laptop)
Antonio Olivares
olivares14031 at yahoo.com
Thu Mar 5 02:39:25 UTC 2009
Dear all,
As a result of the updates, no I don't have X on an intel based Laptop. It gave the following:
[drm:drm_mode_getfb] *ERROR* invalid framebuffer id
=======================================================
[ INFO: possible circular locking dependency detected ]
2.6.29-0.197.rc7.fc11.i586 #1
-------------------------------------------------------
Xorg/2743 is trying to acquire lock:
(&mm->mmap_sem){----}, at: [<c049122f>] might_fault+0x48/0x85
but task is already holding lock:
(&dev->struct_mutex){--..}, at: [<f7ddca1b>] i915_gem_execbuffer+0xd7/0xa1c [i915]
which lock already depends on the new lock.
the existing dependency chain (in reverse order) is:
-> #1 (&dev->struct_mutex){--..}:
[<c0450bfe>] __lock_acquire+0x970/0xace
[<c0450db7>] lock_acquire+0x5b/0x81
[<c06efbcd>] __mutex_lock_common+0xdd/0x338
[<c06efecf>] mutex_lock_nested+0x33/0x3b
[<f7d865bd>] drm_gem_mmap+0x36/0xf7 [drm]
[<c049786b>] mmap_region+0x243/0x3cb
[<c0497c45>] do_mmap_pgoff+0x252/0x2a2
[<c0407134>] sys_mmap2+0x5f/0x80
[<c0403f92>] syscall_call+0x7/0xb
[<ffffffff>] 0xffffffff
-> #0 (&mm->mmap_sem){----}:
[<c0450acb>] __lock_acquire+0x83d/0xace
[<c0450db7>] lock_acquire+0x5b/0x81
[<c049124c>] might_fault+0x65/0x85
[<c0543a33>] copy_from_user+0x32/0x119
[<f7ddcb64>] i915_gem_execbuffer+0x220/0xa1c [i915]
[<f7d8570f>] drm_ioctl+0x1b7/0x236 [drm]
[<c04b46c8>] vfs_ioctl+0x5a/0x74
[<c04b4c70>] do_vfs_ioctl+0x48b/0x4c9
[<c04b4cf4>] sys_ioctl+0x46/0x66
[<c0403f92>] syscall_call+0x7/0xb
[<ffffffff>] 0xffffffff
other info that might help us debug this:
1 lock held by Xorg/2743:
#0: (&dev->struct_mutex){--..}, at: [<f7ddca1b>] i915_gem_execbuffer+0xd7/0xa1c [i915]
stack backtrace:
Pid: 2743, comm: Xorg Not tainted 2.6.29-0.197.rc7.fc11.i586 #1
Call Trace:
[<c06eea41>] ? printk+0x14/0x1b
[<c0450079>] print_circular_bug_tail+0x5d/0x68
[<c0450acb>] __lock_acquire+0x83d/0xace
[<c06f0ee7>] ? _spin_unlock+0x22/0x25
[<c049122f>] ? might_fault+0x48/0x85
[<c0450db7>] lock_acquire+0x5b/0x81
[<c049122f>] ? might_fault+0x48/0x85
[<c049124c>] might_fault+0x65/0x85
[<c049122f>] ? might_fault+0x48/0x85
[<c0543a33>] copy_from_user+0x32/0x119
[<f7ddcb64>] i915_gem_execbuffer+0x220/0xa1c [i915]
[<c049126a>] ? might_fault+0x83/0x85
[<c0543a33>] ? copy_from_user+0x32/0x119
[<f7d8570f>] drm_ioctl+0x1b7/0x236 [drm]
[<f7ddc944>] ? i915_gem_execbuffer+0x0/0xa1c [i915]
[<c04b46c8>] vfs_ioctl+0x5a/0x74
[<c04b4c70>] do_vfs_ioctl+0x48b/0x4c9
[<c05173ba>] ? file_has_perm+0x81/0x8a
[<c04b4cf4>] sys_ioctl+0x46/0x66
[<c04b4cf4>] ? sys_ioctl+0x46/0x66
[<c0403f92>] syscall_call+0x7/0xb
reverting back to older kernel does no GOOD. So I'll patiently await updates to see if one can fix this :)
Regards,
Antonio
More information about the fedora-test-list
mailing list