RE: Problem booting 2.6.13 on RHEL 4

[Roger Heflin]

> -----Original Message-----
> From: linux-kernel-owner@xxxxxxxxxxxxxxx 
> [mailto:linux-kernel-owner@xxxxxxxxxxxxxxx] On Behalf Of Bill Davidsen
> Sent: Wednesday, September 14, 2005 11:21 AM
> To: liyu@WAN
> Cc: Linux-newbie@xxxxxxxxxxxxxxx; linux-kernel@xxxxxxxxxxxxxxx
> 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

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/