Re: Fw: Kernel Loading Sequence
Thank you for the info. I just have one more question. I'm still getting the following messages before plymouth loads: ACPI: I/O resource :00:1f.3 [0x400-0x41f] conflicts with ACPI region SMRG [0x400-0x40f] hub 1-0:1.0: unable to enumerate USB device on port 7 I looked those issues up and I know the first is supposed to be fixed in 2.6.30 and the second is being worked on. My question is: which kernel config setting should I enable/disable so as not to show those messages on startup? Thank you again for the help. Ahmad From: Dave Jones To: drago01 Cc: fedora-kernel-list@redhat.com; Ahmad Al-Yaman Sent: Sunday, July 12, 2009 6:28:22 PM Subject: Re: Fw: Kernel Loading Sequence On Sun, Jul 12, 2009 at 01:43:36PM +0200, drago01 wrote: > On Sun, Jul 12, 2009 at 1:32 PM, Ahmad Al-Yaman wrote: > > Thank you, I adjusted the config file as you recommended and the messages > > are gone. Where should I report this lockdep? > > Depends on which kernel / patches do you use. > If it is a vanilla tarball then upstream (lkml / bugzilla.kernel.org) > if you are using the fedora kernel bugzilla.redhat.com It's already fixed in 2.6.31rc2 Fedora 11 will pick it up when we rebase, it's not a critical patch. Rawhide is already fixed. Dave ___ Fedora-kernel-list mailing list Fedora-kernel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-kernel-list ___ Fedora-kernel-list mailing list Fedora-kernel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-kernel-list
Re: Fw: Kernel Loading Sequence
On Sun, Jul 12, 2009 at 01:43:36PM +0200, drago01 wrote: > On Sun, Jul 12, 2009 at 1:32 PM, Ahmad Al-Yaman wrote: > > Thank you, I adjusted the config file as you recommended and the messages > > are gone. Where should I report this lockdep? > > Depends on which kernel / patches do you use. > If it is a vanilla tarball then upstream (lkml / bugzilla.kernel.org) > if you are using the fedora kernel bugzilla.redhat.com It's already fixed in 2.6.31rc2 Fedora 11 will pick it up when we rebase, it's not a critical patch. Rawhide is already fixed. Dave ___ Fedora-kernel-list mailing list Fedora-kernel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-kernel-list
Re: Fw: Kernel Loading Sequence
On Sun, Jul 12, 2009 at 1:32 PM, Ahmad Al-Yaman wrote: > Thank you, I adjusted the config file as you recommended and the messages > are gone. Where should I report this lockdep? Depends on which kernel / patches do you use. If it is a vanilla tarball then upstream (lkml / bugzilla.kernel.org) if you are using the fedora kernel bugzilla.redhat.com ___ Fedora-kernel-list mailing list Fedora-kernel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-kernel-list
Re: Fw: Kernel Loading Sequence
Thank you, I adjusted the config file as you recommended and the messages are
gone. Where should I report this lockdep?
From: drago01
To: Ahmad Al-Yaman
Cc: fedora-kernel-list@redhat.com
Sent: Sunday, July 12, 2009 12:35:07 PM
Subject: Re: Fw: Kernel Loading Sequence
On Sun, Jul 12, 2009 at 10:50 AM, Ahmad Al-Yaman wrote:
> 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: [] fb_mmap+0x83/0x153
>
> but task is already holding lock:
> (&mm->mmap_sem){}, at: [] sys_mmap2+0x44/0x7b
>
> which lock already depends on the new lock.
>
>
> the existing dependency chain (in reverse order) is:
>
> -> #3 (&mm->mmap_sem){}:
> [] __lock_acquire+0x1068/0x137e
> [] lock_acquire+0x5e/0x7a
> [] might_fault+0x68/0x88
> [] copy_to_user+0x2f/0x106
> [] filldir+0x80/0xbb
> [] sysfs_readdir+0x104/0x138
> [] vfs_readdir+0x68/0x94
> [] sys_getdents+0x60/0xa4
> [] syscall_call+0x7/0xb
> [] 0x
>
> -> #2 (sysfs_mutex){--..}:
> [] __lock_acquire+0x1068/0x137e
> [] lock_acquire+0x5e/0x7a
> [] mutex_lock_nested+0xe0/0x267
> [] sysfs_addrm_start+0x23/0x95
> [] create_dir+0x3a/0x76
> [] sysfs_create_dir+0x2d/0x3d
> [] kobject_add_internal+0xaa/0x159
> [] kobject_add_varg+0x31/0x3d
> [] kobject_add+0x43/0x49
> [] device_add+0x79/0x3fb
> [] device_register+0x12/0x15
> [] device_create_vargs+0x77/0xa0
> [] device_create+0x1b/0x1d
> [] register_con_driver+0xdd/0x137
> [] take_over_console+0x14/0x35
> [] fbcon_takeover+0x5f/0x92
> [] fbcon_event_notify+0x3b7/0x726
> [] notifier_call_chain+0x51/0x78
> [] __blocking_notifier_call_chain+0x37/0x4c
> [] blocking_notifier_call_chain+0xc/0xe
> [] fb_notifier_call_chain+0x11/0x13
> [] register_framebuffer+0x1e2/0x1f3
> [] intelfb_probe+0x491/0x4fb
> [] drm_helper_initial_config+0x148/0x152
> [] i915_driver_load+0x8b2/0x912
> [] drm_get_dev+0x343/0x405
> [] i915_pci_probe+0xd/0xf
> [] local_pci_probe+0xe/0x10
> [] pci_device_probe+0x46/0x69
> [] driver_probe_device+0xa2/0x11d
> [] __driver_attach+0x4c/0x6b
> [] bus_for_each_dev+0x3b/0x63
> [] driver_attach+0x14/0x16
> [] bus_add_driver+0x98/0x1ab
> [] driver_register+0x6f/0xd3
> [] __pci_register_driver+0x46/0xa5
> [] drm_init+0x5b/0xb3
> [] i915_init+0x46/0x48
> [] _stext+0x4a/0x111
> [] kernel_init+0x17f/0x1d0
> [] kernel_thread_helper+0x7/0x10
> [] 0x
>
> -> #1 ((fb_notifier_list).rwsem){..--}:
> [] __lock_acquire+0x1068/0x137e
> [] lock_acquire+0x5e/0x7a
> [] down_read+0x2a/0x3e
> [] __blocking_notifier_call_chain+0x24/0x4c
> [] blocking_notifier_call_chain+0xc/0xe
> [] fb_notifier_call_chain+0x11/0x13
> [] register_framebuffer+0x1e2/0x1f3
> [] intelfb_probe+0x491/0x4fb
> [] drm_helper_initial_config+0x148/0x152
> [] i915_driver_load+0x8b2/0x912
> [] drm_get_dev+0x343/0x405
> [] i915_pci_probe+0xd/0xf
> [] local_pci_probe+0xe/0x10
> [] pci_device_probe+0x46/0x69
> [] driver_probe_device+0xa2/0x11d
> [] __driver_attach+0x4c/0x6b
> [] bus_for_each_dev+0x3b/0x63
> [] driver_attach+0x14/0x16
> [] bus_add_driver+0x98/0x1ab
> [] driver_register+0x6f/0xd3
> [] __pci_register_driver+0x46/0xa5
> [] drm_init+0x5b/0xb3
> [] i915_init+0x46/0x48
> [] _stext+0x4a/0x111
> [] kernel_init+0x17f/0x1d0
> [] kernel_thread_helper+0x7/0x10
> [] 0x
>
> -> #0 (&fb_info->lock){--..}:
> [] __lock_acquire+0xd47/0x137e
> [] lock_acquire+0x5e/0x7a
> [] mutex_lock_nested+0xe0/0x267
> [] fb_mmap+0x83/0x153
> [] mmap_region+0x21c/0x3ab
> [] do_mmap_pgoff+0x250/0x2a2
> [] sys_mmap2+0x5a/0x7b
> [] syscall_call+0x7/0xb
> [] 0x
>
> other info that might help us debug this:
>
> 1 lock held by plymouthd/746:
> #0: (&mm->mmap_sem){}, at: [] sys_mmap2+0x44/0x7b
>
> stack backtrace:
> Pid: 746, comm: plymouthd Not tainted 2.6.29.5-191.eeepc.fc11.i686.PAE #1
> Call Trace:
&g
Re: Fw: Kernel Loading Sequence
On Sun, Jul 12, 2009 at 10:50 AM, Ahmad Al-Yaman wrote:
> 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: [] fb_mmap+0x83/0x153
>
> but task is already holding lock:
> (&mm->mmap_sem){}, at: [] sys_mmap2+0x44/0x7b
>
> which lock already depends on the new lock.
>
>
> the existing dependency chain (in reverse order) is:
>
> -> #3 (&mm->mmap_sem){}:
> [] __lock_acquire+0x1068/0x137e
> [] lock_acquire+0x5e/0x7a
> [] might_fault+0x68/0x88
> [] copy_to_user+0x2f/0x106
> [] filldir+0x80/0xbb
> [] sysfs_readdir+0x104/0x138
> [] vfs_readdir+0x68/0x94
> [] sys_getdents+0x60/0xa4
> [] syscall_call+0x7/0xb
> [] 0x
>
> -> #2 (sysfs_mutex){--..}:
> [] __lock_acquire+0x1068/0x137e
> [] lock_acquire+0x5e/0x7a
> [] mutex_lock_nested+0xe0/0x267
> [] sysfs_addrm_start+0x23/0x95
> [] create_dir+0x3a/0x76
> [] sysfs_create_dir+0x2d/0x3d
> [] kobject_add_internal+0xaa/0x159
> [] kobject_add_varg+0x31/0x3d
> [] kobject_add+0x43/0x49
> [] device_add+0x79/0x3fb
> [] device_register+0x12/0x15
> [] device_create_vargs+0x77/0xa0
> [] device_create+0x1b/0x1d
> [] register_con_driver+0xdd/0x137
> [] take_over_console+0x14/0x35
> [] fbcon_takeover+0x5f/0x92
> [] fbcon_event_notify+0x3b7/0x726
> [] notifier_call_chain+0x51/0x78
> [] __blocking_notifier_call_chain+0x37/0x4c
> [] blocking_notifier_call_chain+0xc/0xe
> [] fb_notifier_call_chain+0x11/0x13
> [] register_framebuffer+0x1e2/0x1f3
> [] intelfb_probe+0x491/0x4fb
> [] drm_helper_initial_config+0x148/0x152
> [] i915_driver_load+0x8b2/0x912
> [] drm_get_dev+0x343/0x405
> [] i915_pci_probe+0xd/0xf
> [] local_pci_probe+0xe/0x10
> [] pci_device_probe+0x46/0x69
> [] driver_probe_device+0xa2/0x11d
> [] __driver_attach+0x4c/0x6b
> [] bus_for_each_dev+0x3b/0x63
> [] driver_attach+0x14/0x16
> [] bus_add_driver+0x98/0x1ab
> [] driver_register+0x6f/0xd3
> [] __pci_register_driver+0x46/0xa5
> [] drm_init+0x5b/0xb3
> [] i915_init+0x46/0x48
> [] _stext+0x4a/0x111
> [] kernel_init+0x17f/0x1d0
> [] kernel_thread_helper+0x7/0x10
> [] 0x
>
> -> #1 ((fb_notifier_list).rwsem){..--}:
> [] __lock_acquire+0x1068/0x137e
> [] lock_acquire+0x5e/0x7a
> [] down_read+0x2a/0x3e
> [] __blocking_notifier_call_chain+0x24/0x4c
> [] blocking_notifier_call_chain+0xc/0xe
> [] fb_notifier_call_chain+0x11/0x13
> [] register_framebuffer+0x1e2/0x1f3
> [] intelfb_probe+0x491/0x4fb
> [] drm_helper_initial_config+0x148/0x152
> [] i915_driver_load+0x8b2/0x912
> [] drm_get_dev+0x343/0x405
> [] i915_pci_probe+0xd/0xf
> [] local_pci_probe+0xe/0x10
> [] pci_device_probe+0x46/0x69
> [] driver_probe_device+0xa2/0x11d
> [] __driver_attach+0x4c/0x6b
> [] bus_for_each_dev+0x3b/0x63
> [] driver_attach+0x14/0x16
> [] bus_add_driver+0x98/0x1ab
> [] driver_register+0x6f/0xd3
> [] __pci_register_driver+0x46/0xa5
> [] drm_init+0x5b/0xb3
> [] i915_init+0x46/0x48
> [] _stext+0x4a/0x111
> [] kernel_init+0x17f/0x1d0
> [] kernel_thread_helper+0x7/0x10
> [] 0x
>
> -> #0 (&fb_info->lock){--..}:
> [] __lock_acquire+0xd47/0x137e
> [] lock_acquire+0x5e/0x7a
> [] mutex_lock_nested+0xe0/0x267
> [] fb_mmap+0x83/0x153
> [] mmap_region+0x21c/0x3ab
> [] do_mmap_pgoff+0x250/0x2a2
> [] sys_mmap2+0x5a/0x7b
> [] syscall_call+0x7/0xb
> [] 0x
>
> other info that might help us debug this:
>
> 1 lock held by plymouthd/746:
> #0: (&mm->mmap_sem){}, at: [] sys_mmap2+0x44/0x7b
>
> stack backtrace:
> Pid: 746, comm: plymouthd Not tainted 2.6.29.5-191.eeepc.fc11.i686.PAE #1
> Call Trace:
> [] ? printk+0xf/0x11
> [] print_circular_bug_tail+0xab/0xb6
> [] __lock_acquire+0xd47/0x137e
> [] ? fb_mmap+0x83/0x153
> [] lock_acquire+0x5e/0x7a
> [] ? fb_mmap+0x83/0x153
> [] mutex_lock_nested+0xe0/0x267
> [] ? fb_mmap+0x83/0x153
> [] ? fb_mmap+0x83/0x153
> [] fb_mmap+0x83/0x153
> [] mmap_region+0x21c/0x3ab
> [] do_mmap_pgoff+0x250/0x2a2
> [] sys_mmap2+0x5a/0x7b
> [] syscall_call+0x7/0xb
>
> Any ideas what could be causing this and how to solve it?
>
> Ahmad
Thats a lockdep warning, please report it.
After that you can simply disable the lockdep checker in your kernel
config and you wont see them anymore.
___
Fedora-kernel-list mailing list
Fedora-kernel
Re: Fw: Kernel Loading Sequence
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: [] fb_mmap+0x83/0x153
but task is already holding lock:
(&mm->mmap_sem){}, at: [] sys_mmap2+0x44/0x7b
which lock already depends on the new lock.
the existing dependency chain (in reverse order) is:
-> #3 (&mm->mmap_sem){}:
[] __lock_acquire+0x1068/0x137e
[] lock_acquire+0x5e/0x7a
[] might_fault+0x68/0x88
[] copy_to_user+0x2f/0x106
[] filldir+0x80/0xbb
[] sysfs_readdir+0x104/0x138
[] vfs_readdir+0x68/0x94
[] sys_getdents+0x60/0xa4
[] syscall_call+0x7/0xb
[] 0x
-> #2 (sysfs_mutex){--..}:
[] __lock_acquire+0x1068/0x137e
[] lock_acquire+0x5e/0x7a
[] mutex_lock_nested+0xe0/0x267
[] sysfs_addrm_start+0x23/0x95
[] create_dir+0x3a/0x76
[] sysfs_create_dir+0x2d/0x3d
[] kobject_add_internal+0xaa/0x159
[] kobject_add_varg+0x31/0x3d
[] kobject_add+0x43/0x49
[] device_add+0x79/0x3fb
[] device_register+0x12/0x15
[] device_create_vargs+0x77/0xa0
[] device_create+0x1b/0x1d
[] register_con_driver+0xdd/0x137
[] take_over_console+0x14/0x35
[] fbcon_takeover+0x5f/0x92
[] fbcon_event_notify+0x3b7/0x726
[] notifier_call_chain+0x51/0x78
[] __blocking_notifier_call_chain+0x37/0x4c
[] blocking_notifier_call_chain+0xc/0xe
[] fb_notifier_call_chain+0x11/0x13
[] register_framebuffer+0x1e2/0x1f3
[] intelfb_probe+0x491/0x4fb
[] drm_helper_initial_config+0x148/0x152
[] i915_driver_load+0x8b2/0x912
[] drm_get_dev+0x343/0x405
[] i915_pci_probe+0xd/0xf
[] local_pci_probe+0xe/0x10
[] pci_device_probe+0x46/0x69
[] driver_probe_device+0xa2/0x11d
[] __driver_attach+0x4c/0x6b
[] bus_for_each_dev+0x3b/0x63
[] driver_attach+0x14/0x16
[] bus_add_driver+0x98/0x1ab
[] driver_register+0x6f/0xd3
[] __pci_register_driver+0x46/0xa5
[] drm_init+0x5b/0xb3
[] i915_init+0x46/0x48
[] _stext+0x4a/0x111
[] kernel_init+0x17f/0x1d0
[] kernel_thread_helper+0x7/0x10
[] 0x
-> #1 ((fb_notifier_list).rwsem){..--}:
[] __lock_acquire+0x1068/0x137e
[] lock_acquire+0x5e/0x7a
[] down_read+0x2a/0x3e
[] __blocking_notifier_call_chain+0x24/0x4c
[] blocking_notifier_call_chain+0xc/0xe
[] fb_notifier_call_chain+0x11/0x13
[] register_framebuffer+0x1e2/0x1f3
[] intelfb_probe+0x491/0x4fb
[] drm_helper_initial_config+0x148/0x152
[] i915_driver_load+0x8b2/0x912
[] drm_get_dev+0x343/0x405
[] i915_pci_probe+0xd/0xf
[] local_pci_probe+0xe/0x10
[] pci_device_probe+0x46/0x69
[] driver_probe_device+0xa2/0x11d
[] __driver_attach+0x4c/0x6b
[] bus_for_each_dev+0x3b/0x63
[] driver_attach+0x14/0x16
[] bus_add_driver+0x98/0x1ab
[] driver_register+0x6f/0xd3
[] __pci_register_driver+0x46/0xa5
[] drm_init+0x5b/0xb3
[] i915_init+0x46/0x48
[] _stext+0x4a/0x111
[] kernel_init+0x17f/0x1d0
[] kernel_thread_helper+0x7/0x10
[] 0x
-> #0 (&fb_info->lock){--..}:
[] __lock_acquire+0xd47/0x137e
[] lock_acquire+0x5e/0x7a
[] mutex_lock_nested+0xe0/0x267
[] fb_mmap+0x83/0x153
[] mmap_region+0x21c/0x3ab
[] do_mmap_pgoff+0x250/0x2a2
[] sys_mmap2+0x5a/0x7b
[] syscall_call+0x7/0xb
[] 0x
other info that might help us debug this:
1 lock held by plymouthd/746:
#0: (&mm->mmap_sem){}, at: [] sys_mmap2+0x44/0x7b
stack backtrace:
Pid: 746, comm: plymouthd Not tainted 2.6.29.5-191.eeepc.fc11.i686.PAE #1
Call Trace:
[] ? printk+0xf/0x11
[] print_circular_bug_tail+0xab/0xb6
[] __lock_acquire+0xd47/0x137e
[] ? fb_mmap+0x83/0x153
[] lock_acquire+0x5e/0x7a
[] ? fb_mmap+0x83/0x153
[] mutex_lock_nested+0xe0/0x267
[] ? fb_mmap+0x83/0x153
[] ? fb_mmap+0x83/0x153
[] fb_mmap+0x83/0x153
[] mmap_region+0x21c/0x3ab
[] do_mmap_pgoff+0x250/0x2a2
[] sys_mmap2+0x5a/0x7b
[] syscall_call+0x7/0xb
Any ideas what could be causing this and how to solve it?
Ahmad
From: Ahmad Al-Yaman
To: Dave Airlie
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, t
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 To: Ahmad Al-Yaman 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 > 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 ___ Fedora-kernel-list mailing list Fedora-kernel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-kernel-list
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 > 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
Fw: Kernel Loading Sequence
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. - Forwarded Message From: Jarod Wilson 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). -- Jarod Wilson ja...@redhat.com ___ Fedora-kernel-list mailing list Fedora-kernel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-kernel-list ___ Fedora-kernel-list mailing list Fedora-kernel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-kernel-list
