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