From: Sergey Vlasov <vsu@altlinux.ru>
To: Eric Piel <eric.piel@tremplin-utc.net>
Cc: Christoph Hellwig <hch@lst.de>,
dsdt@gaugusch.at, len.brown@intel.com,
linux-kernel@vger.kernel.org, Linus Torvalds <torvalds@osdl.org>,
trenn@suse.de
Subject: Re: acpi dsts loading and populate_rootfs
Date: Mon, 11 Feb 2008 16:47:19 +0300 [thread overview]
Message-ID: <20080211164719.d42c618e.vsu@altlinux.ru> (raw)
In-Reply-To: <47AEE6D1.4070402@tremplin-utc.net>
[-- Attachment #1: Type: text/plain, Size: 2674 bytes --]
On Sun, 10 Feb 2008 12:58:09 +0100 Eric Piel wrote:
> (adding some CC's)
> Christoph Hellwig wrote:
> > On Sun, Feb 10, 2008 at 08:12:26AM +0100, Christoph Hellwig wrote:
> >> Folks, moving this call around hidden behing in completely unreviewed
> >> acpi junk is not acceptable.
> >>
> >> Either populate_rootfs _is_ safe to be called earlier and then we should
> >> do it always or it's not. Either way such a change should be posted
> >> separately and reviewd on lkml.
> Hi,
>
> I agree with you, the order of the initialization should not be changed
> by some config options. Either it works, or it doesn't! So the question
> now is : "is fine to move populate_rootfs() earlier?"
>
> Some data points:
> * It used to be called earlier. It was moved to be called later about a
> year ago by Linus (8d610dd52dd1da696e199e4b4545f33a2a5de5c6) with this log:
> > Make sure we populate the initroot filesystem late enough
> >
> > We should not initialize rootfs before all the core initializers have
> > run. So do it as a separate stage just before starting the regular
> > driver initializers.
> So there must be some good reasons to keep it late enough...
>
> * This patch is used in SuSE, and it seems noone has ever had a problem
> with the initramfs early init.
>
> I guess the problem that Linus solved by moving populate_rootfs()
> happens only rarely or on only few configurations. Linus, do you
> remember what kind of problem it was? How can I reproduce it?
AFAIR the problem was that the kernel was trying to exec /sbin/hotplug
before some kernel subsystems (e.g., pipe support) were completely
initialized, which caused oopses during boot.
Initramfs images generated by distro tools usually do not contain
/sbin/hotplug, and therefore avoid the problem. (The kernel might
also call /sbin/modprobe by itself, but it either does not do it
during early boot, or /sbin/modprobe does not use kernel features
which had not been initialized yet).
> One different solution that I implemented [1] was to have an
> "early_populate_rootfs()" before the acpi_early_init(), leaving
> populate_rootfs() at the normal place. If the early version fails, it's
> ok: we can't override the DSDT, but the later version will work as usual
> anyway. This solution also seems to work quite often (it's used in
> Ubuntu, Mandriva and PCLinuxOS)
This would not solve the problem, because /sbin/hotplug (if present in
the initramfs image) will exist too early.
> Would that seem an acceptable solution? Or what other way exists?
Disabling call_usermodehelper() until all core initializers had
completed would fix the problem too; will such change be acceptable?
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
next prev parent reply other threads:[~2008-02-11 14:15 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-02-10 7:12 acpi dsts loading and populate_rootfs Christoph Hellwig
2008-02-10 7:14 ` Christoph Hellwig
2008-02-10 11:58 ` Eric Piel
2008-02-11 13:47 ` Sergey Vlasov [this message]
2008-02-11 23:41 ` Éric Piel
2008-02-21 19:02 ` [PATCH] Allow populate_rootfs() to be called early (was: acpi dsts loading and populate_rootfs) Éric Piel
2008-02-21 19:04 ` Christoph Hellwig
2008-02-21 21:27 ` [PATCH] Allow populate_rootfs() to be called early Éric Piel
2008-02-23 19:40 ` [PATCH] Allow populate_rootfs() to be called early (resent, with sob) Éric Piel
2008-02-12 5:37 ` acpi dsts loading and populate_rootfs Christoph Hellwig
2008-02-21 18:46 ` Éric Piel
2008-02-22 8:51 ` Thomas Renninger
2008-02-22 9:05 ` Thomas Renninger
2008-02-22 9:53 ` Andi Kleen
2008-02-23 19:34 ` [PATCH] Use userland-like functions for reading the ACPI table Éric Piel
2008-02-23 20:45 ` Linus Torvalds
2008-02-24 1:31 ` Christoph Hellwig
2008-02-24 19:02 ` Éric Piel
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20080211164719.d42c618e.vsu@altlinux.ru \
--to=vsu@altlinux.ru \
--cc=dsdt@gaugusch.at \
--cc=eric.piel@tremplin-utc.net \
--cc=hch@lst.de \
--cc=len.brown@intel.com \
--cc=linux-kernel@vger.kernel.org \
--cc=torvalds@osdl.org \
--cc=trenn@suse.de \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.