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@yahoo.com To: Dave Airlie airlied@redhat.com Cc: fedora-kernel-list@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@redhat.com To: Ahmad Al-Yaman ahmad221284@yahoo.com Cc: fedora-kernel-list@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@redhat.com To: fedora-kernel-list@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@redhat.com https://www.redhat.com/mailman/listinfo/fedora-kernel-list