public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Christian Trefzer <ctrefzer@web.de>
To: "Darryl L. Miles" <darryl@netbauds.net>
Cc: linux-kernel@vger.kernel.org
Subject: Re: 2.6.12 initrd module loading seems parallel on bootup
Date: Thu, 30 Jun 2005 01:39:53 +0200	[thread overview]
Message-ID: <42C33149.3090305@web.de> (raw)
In-Reply-To: <42BF92D4.3040609@netbauds.net>

[-- Attachment #1: Type: text/plain, Size: 2383 bytes --]

Hi Darry,
first of all thanks for your questions, and sorry for answering late, 
I've been away for some time.

Darryl L. Miles schrieb:
> 
> Are we sure we are not talking about two different problems here.
> 
> I'm using RedHat and mkinitrd, in the initrd image there is already a 
> skeleton /dev tree that contains my real-root device.  udev also exists 
> in the initrd image.  I don't think any /dev device magic was necessary 
> for me too mount root.
> 
> It is not clear Chris which tools you are using on initrd, standard 
> Gentoo methods or a home brew setup ?  What shell is calling modprobe ?  
> Can you confirm at what point you are seeing modprobe exit ?

I am using a self-made initramfs setup using the "standard" binaries 
from the live system, usable for instance as rescue system with tools 
identical to anything I have installed, including bash as shell for the 
init script, udev, module-init-tools, lvm2, mdadm, and so on and so 
forth. There are only the most basic device nodes in the supplied /dev 
tree, like null, console, etc.
Unfortunately, I don't really "see" modprobe exit, it just takes less 
time until the "modprobe $mod && e_done" prints its "done." yet related 
device nodes are still missing. Waiting for any required nodes fixes the 
problem so far, but maybe bash-3.00 is having a similar issue as nash. 
I'll try using sash or busybox ASAP to check if the problem is somewhere 
else.

The funny thing is that with kernels up to 2.6.11.12, I don't see this 
problem. The patch mentioned further up this thread was against 
2.6.11-rc1 and should have been applied long before I even touched 
2.6.11, so I just don't understand why I have problems now.

> * Immediatly (before device driver has detected hardware and reported / 
> registered its findings).  This is the symptom I was seeing, but the 
> cause was incorrect shell handling. * After detection but before device 
> node creation.

Well, so far I cannot distinguish both of these cases, but it definitely 
is _not_ the third one:

> * After device node creation.
> 
> 
Otherwise I would not run into problems like mdadm failing trying to 
assemble arrays while disk nodes are still missing in action.

> FYI - This looks like the snippet from nash.c
> 
> [snip]

Thanks for the patch, I'll look into similarities in the bash code if 
the shell really is the cause of my trouble.

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 894 bytes --]

  reply	other threads:[~2005-06-29 23:40 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2005-06-26  1:02 2.6.12 initrd module loading seems parallel on bootup Darryl L. Miles
2005-06-26  3:53 ` Christian Trefzer
2005-06-26  6:46 ` Andrew Morton
2005-06-26  9:26   ` Pozsár Balázs
2005-06-26 11:53     ` Christian Trefzer
2005-06-26 10:06   ` Darryl L. Miles
2005-06-26 12:00     ` Christian Trefzer
2005-06-26 14:11       ` Toon van der Pas
2005-06-27  5:47         ` Darryl L. Miles
2005-06-29 23:39           ` Christian Trefzer [this message]
2005-06-30  8:45             ` Darryl L. Miles
2005-06-30 14:12               ` Christian Trefzer
2005-06-26 13:19   ` Parag Warudkar
     [not found] <4jtOU-508-21@gated-at.bofh.it>
     [not found] ` <4jz7U-9S-7@gated-at.bofh.it>
     [not found]   ` <4jBCN-20Q-9@gated-at.bofh.it>
2005-06-27  6:24     ` Martin Wilck
  -- strict thread matches above, loose matches on Subject: below --
2005-06-25 22:09 Darryl L. Miles

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=42C33149.3090305@web.de \
    --to=ctrefzer@web.de \
    --cc=darryl@netbauds.net \
    --cc=linux-kernel@vger.kernel.org \
    /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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox