From: "Roger Heflin" <rheflin@atipa.com>
To: 'Bill Davidsen' <davidsen@tmr.com>, "'liyu@WAN'" <liyu@ccoss.com.cn>
Cc: Linux-newbie@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: RE: Problem booting 2.6.13 on RHEL 4
Date: Wed, 14 Sep 2005 11:50:13 -0500 [thread overview]
Message-ID: <EXCHG2003MFaukyCKDk00000794@EXCHG2003.microtech-ks.com> (raw)
In-Reply-To: <43284DD0.5080709@tmr.com>
> -----Original Message-----
> From: linux-kernel-owner@vger.kernel.org
> [mailto:linux-kernel-owner@vger.kernel.org] On Behalf Of Bill Davidsen
> Sent: Wednesday, September 14, 2005 11:21 AM
> To: liyu@WAN
> Cc: Linux-newbie@vger.kernel.org; linux-kernel@vger.kernel.org
> Subject: Re: Problem booting 2.6.13 on RHEL 4
>
> liyu@WAN wrote:
> >
> > It seem that kernel have no time to probe your disk, and do
> not read
> > parttion table.
> >
> > I use kernel 2.6.12 and SATA disk on FC3, also failed to boot.
> > but after some experiment, I found if we place 'sleep 5'
> > statement between insmod commands in linuxrc or init, it
> will boot up!
> >
> > However, this idea is too HACK.
>
> It would have been nice, back in the 2.5.46 timeframe when
> modules were complete reinvented, to have provided a hook by
> which modprobe could have waited until insertion init was complete.
>
> The sleep is a hack indeed, as is the slightly more reliable
> solution to tail the log and look for init messages to
> appear. Perhaps look for the devices in /proc/scsi/scsi or something?
>
> There doesn't seem to be a "right way" for this, particularly
> if you have both warm and cold boots, which may differ by
> minutes depending on disk spin-up already being done.
>
I have seen this.
On one machine with 2 scsi adaptors 10 seconds was enough, on a different
machine with 6 channels it had to be over 45 seconds to get things to be
found reliabily, and I don't know if that is always going to be reliable.
It would have been nice if there were at least an option on modprobe so
that it could be set to not return after init on the critical modules,
ie mostly disk modules, but I have seen failures on other parts because
the modprobe is not quite finished and ready for the next step after
it returns.
Any better way to deal with this?
Roger
next prev parent reply other threads:[~2005-09-14 16:50 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2005-09-14 4:08 Problem booting 2.6.13 on RHEL 4 Rajat Jain
2005-09-14 8:13 ` liyu@WAN
2005-09-14 16:20 ` Bill Davidsen
2005-09-14 16:50 ` Roger Heflin [this message]
2005-09-15 15:30 ` Jason Baron
2005-09-28 9:18 ` Rajat Jain
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=EXCHG2003MFaukyCKDk00000794@EXCHG2003.microtech-ks.com \
--to=rheflin@atipa.com \
--cc=Linux-newbie@vger.kernel.org \
--cc=davidsen@tmr.com \
--cc=linux-kernel@vger.kernel.org \
--cc=liyu@ccoss.com.cn \
/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