no more X on intel based chip (Laptop)

Antonio M antonio.montagnani at gmail.com
Thu Mar 5 12:13:20 UTC 2009


2009/3/5 Antonio Olivares <olivares14031 at yahoo.com>:
>
> 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
>
>
>
>

I have similar problem, but thankfully I had made a local repository
of running packages so I can revert back.
As soon as I update either from xorg-x11-server-Xorg-1.5.3-6.fc10 to
xorg-x11-server-1.6.0-5.fc11 and from
xorg-x11-server-common-1.5.3-6.fc10 to xorg-x11-server-1.6.0-5.fc11, X
server crashes.
Same if I update only from xorg-x11-drv-i740-1.2.0-1.fc9 to
xorg-x11-drv-i740-1.2.0-3.fc11 and from
xorg-x11-drv-i810-2.5.99.1-0.1.fc11 to xorg-x11-drv-i810-2.6.0-7.fc11
(and no xorg-x11-server update).
I filed a bug #488270 .
I don't know if you are experiencing same kind of problems.

-- 
Antonio Montagnani
Skype : antoniomontag




More information about the fedora-test-list mailing list