I was able to find out the messages that are displayed before plymouth starts, but I still
have no idea what's causing them:
[ INFO: possible circular locking dependency detected ]
2.6.29.5-191.eeepc.fc11.i686.PAE #1
-------------------------------------------------------
plymouthd/746 is trying to acquire lock:
(&fb_info->lock){--..}, at: [<c05288bc>] fb_mmap+0x83/0x153
but task is already holding lock:
(&mm->mmap_sem){----}, at: [<c0406a3c>] sys_mmap2+0x44/0x7b
which lock already depends on the new lock.
the existing dependency chain (in reverse order) is:
-> #3 (&mm->mmap_sem){----}:
[<c04463fa>] __lock_acquire+0x1068/0x137e
[<c044676e>] lock_acquire+0x5e/0x7a
[<c046ddb4>] might_fault+0x68/0x88
[<c0510de3>] copy_to_user+0x2f/0x106
[<c0489920>] filldir+0x80/0xbb
[<c04b8a3d>] sysfs_readdir+0x104/0x138
[<c0489a99>] vfs_readdir+0x68/0x94
[<c0489bd2>] sys_getdents+0x60/0xa4
[<c0403202>] syscall_call+0x7/0xb
[<ffffffff>] 0xffffffff
-> #2 (sysfs_mutex){--..}:
[<c04463fa>] __lock_acquire+0x1068/0x137e
[<c044676e>] lock_acquire+0x5e/0x7a
[<c07c919f>] mutex_lock_nested+0xe0/0x267
[<c04b8cf4>] sysfs_addrm_start+0x23/0x95
[<c04b919d>] create_dir+0x3a/0x76
[<c04b9206>] sysfs_create_dir+0x2d/0x3d
[<c050c198>] kobject_add_internal+0xaa/0x159
[<c050c2ee>] kobject_add_varg+0x31/0x3d
[<c050c364>] kobject_add+0x43/0x49
[<c05ad349>] device_add+0x79/0x3fb
[<c05ad6dd>] device_register+0x12/0x15
[<c05ad757>] device_create_vargs+0x77/0xa0
[<c05ad79b>] device_create+0x1b/0x1d
[<c056f49e>] register_con_driver+0xdd/0x137
[<c0570637>] take_over_console+0x14/0x35
[<c0532c59>] fbcon_takeover+0x5f/0x92
[<c053336f>] fbcon_event_notify+0x3b7/0x726
[<c043ab5c>] notifier_call_chain+0x51/0x78
[<c043ad1d>] __blocking_notifier_call_chain+0x37/0x4c
[<c043ad3e>] blocking_notifier_call_chain+0xc/0xe
[<c05283fd>] fb_notifier_call_chain+0x11/0x13
[<c0529198>] register_framebuffer+0x1e2/0x1f3
[<c05a01b6>] intelfb_probe+0x491/0x4fb
[<c0586cc5>] drm_helper_initial_config+0x148/0x152
[<c05902b5>] i915_driver_load+0x8b2/0x912
[<c057fb7b>] drm_get_dev+0x343/0x405
[<c07b6741>] i915_pci_probe+0xd/0xf
[<c051aee2>] local_pci_probe+0xe/0x10
[<c051b84d>] pci_device_probe+0x46/0x69
[<c05aedd5>] driver_probe_device+0xa2/0x11d
[<c05aee9c>] __driver_attach+0x4c/0x6b
[<c05ae7f1>] bus_for_each_dev+0x3b/0x63
[<c05aec76>] driver_attach+0x14/0x16
[<c05ae28c>] bus_add_driver+0x98/0x1ab
[<c05af033>] driver_register+0x6f/0xd3
[<c051bb3d>] __pci_register_driver+0x46/0xa5
[<c057c3f4>] drm_init+0x5b/0xb3
[<c0a39544>] i915_init+0x46/0x48
[<c0401132>] _stext+0x4a/0x111
[<c0a1e386>] kernel_init+0x17f/0x1d0
[<c0403a37>] kernel_thread_helper+0x7/0x10
[<ffffffff>] 0xffffffff
-> #1 ((fb_notifier_list).rwsem){..--}:
[<c04463fa>] __lock_acquire+0x1068/0x137e
[<c044676e>] lock_acquire+0x5e/0x7a
[<c07c98db>] down_read+0x2a/0x3e
[<c043ad0a>] __blocking_notifier_call_chain+0x24/0x4c
[<c043ad3e>] blocking_notifier_call_chain+0xc/0xe
[<c05283fd>] fb_notifier_call_chain+0x11/0x13
[<c0529198>] register_framebuffer+0x1e2/0x1f3
[<c05a01b6>] intelfb_probe+0x491/0x4fb
[<c0586cc5>] drm_helper_initial_config+0x148/0x152
[<c05902b5>] i915_driver_load+0x8b2/0x912
[<c057fb7b>] drm_get_dev+0x343/0x405
[<c07b6741>] i915_pci_probe+0xd/0xf
[<c051aee2>] local_pci_probe+0xe/0x10
[<c051b84d>] pci_device_probe+0x46/0x69
[<c05aedd5>] driver_probe_device+0xa2/0x11d
[<c05aee9c>] __driver_attach+0x4c/0x6b
[<c05ae7f1>] bus_for_each_dev+0x3b/0x63
[<c05aec76>] driver_attach+0x14/0x16
[<c05ae28c>] bus_add_driver+0x98/0x1ab
[<c05af033>] driver_register+0x6f/0xd3
[<c051bb3d>] __pci_register_driver+0x46/0xa5
[<c057c3f4>] drm_init+0x5b/0xb3
[<c0a39544>] i915_init+0x46/0x48
[<c0401132>] _stext+0x4a/0x111
[<c0a1e386>] kernel_init+0x17f/0x1d0
[<c0403a37>] kernel_thread_helper+0x7/0x10
[<ffffffff>] 0xffffffff
-> #0 (&fb_info->lock){--..}:
[<c04460d9>] __lock_acquire+0xd47/0x137e
[<c044676e>] lock_acquire+0x5e/0x7a
[<c07c919f>] mutex_lock_nested+0xe0/0x267
[<c05288bc>] fb_mmap+0x83/0x153
[<c0473ab7>] mmap_region+0x21c/0x3ab
[<c0473e96>] do_mmap_pgoff+0x250/0x2a2
[<c0406a52>] sys_mmap2+0x5a/0x7b
[<c0403202>] syscall_call+0x7/0xb
[<ffffffff>] 0xffffffff
other info that might help us debug this:
1 lock held by plymouthd/746:
#0: (&mm->mmap_sem){----}, at: [<c0406a3c>] sys_mmap2+0x44/0x7b
stack backtrace:
Pid: 746, comm: plymouthd Not tainted 2.6.29.5-191.eeepc.fc11.i686.PAE #1
Call Trace:
[<c07c7b14>] ? printk+0xf/0x11
[<c0445054>] print_circular_bug_tail+0xab/0xb6
[<c04460d9>] __lock_acquire+0xd47/0x137e
[<c05288bc>] ? fb_mmap+0x83/0x153
[<c044676e>] lock_acquire+0x5e/0x7a
[<c05288bc>] ? fb_mmap+0x83/0x153
[<c07c919f>] mutex_lock_nested+0xe0/0x267
[<c05288bc>] ? fb_mmap+0x83/0x153
[<c05288bc>] ? fb_mmap+0x83/0x153
[<c05288bc>] fb_mmap+0x83/0x153
[<c0473ab7>] mmap_region+0x21c/0x3ab
[<c0473e96>] do_mmap_pgoff+0x250/0x2a2
[<c0406a52>] sys_mmap2+0x5a/0x7b
[<c0403202>] syscall_call+0x7/0xb
Any ideas what could be causing this and how to solve it?
Ahmad
________________________________
From: Ahmad Al-Yaman <ahmad221284(a)yahoo.com>
To: Dave Airlie <airlied(a)redhat.com>
Cc: fedora-kernel-list(a)redhat.com
Sent: Tuesday, July 7, 2009 12:53:23 AM
Subject: Re: Fw: Kernel Loading Sequence
I just checked and quiet is not missing. As for the patches adding that output, I highly
doubt it since none of them has an output and they're quite simple, they adjust a few
things in some drivers, nothing major. Besides, the messages are displayed before
"Welcome to Fedora init", if the problem was with the patches, shouldn't the
messages come up after that?
Ahmad
________________________________
From: Dave Airlie <airlied(a)redhat.com>
To: Ahmad Al-Yaman <ahmad221284(a)yahoo.com>
Cc: fedora-kernel-list(a)redhat.com
Sent: Tuesday, July 7, 2009 12:17:46 AM
Subject: Re: Fw: Kernel Loading Sequence
On Mon, 2009-07-06 at 13:39 -0700, Ahmad Al-Yaman wrote:
It's an F11 kernel + my patches. I obtained the SRPM from koji,
added a couple of patches, and modified the config file to suit my hardware.
Either got quiet missing or some of the patches add output that doesn't
respect quiet.
Dave.
----- Forwarded Message ----
From: Jarod Wilson <jarod(a)redhat.com>
To: fedora-kernel-list(a)redhat.com
Sent: Monday, July 6, 2009 10:59:15 PM
Subject: Re: Kernel Loading Sequence
On Monday 06 July 2009 11:57:47 Ahmad Al-Yaman wrote:
> Hi all,
>
> I came across a problem when trying to compile a custom kernel for F11: both the
stock kernel and my custom kernel have i915 modesetting enabled by default. In the stock
kernel the loading screen starts up immediately when the kernel starts loading, but using
the custom kernel, some text is displayed before the loading screen starts up (the kernel
finishes loading without problems). I'm trying to figure out the reason for this and
if there's a way to fix it so that the user doesn't see this text. Could the
reason be the order in which different parts of the kernel are loaded? If yes, how can I
control which parts load first?
Is your 'custom kernel' an F11 kernel + your patches, or starting from
an upstream tarball + your patches? (In which case, its lacking all the
patches Fedora has added, and therein probably lies your answer to why
things are behaving differently).
_______________________________________________
Fedora-kernel-list mailing list
Fedora-kernel-list(a)redhat.com
https://www.redhat.com/mailman/listinfo/fedora-kernel-list