Mailinglist Archive: opensuse-factory (509 mails)
| < Previous | Next > |
Re: [opensuse-factory] Re: Changes with boot/init for 10.3 ? Kernel locks in 10.3, not in 10.2 ?
- From: Kevin Valko <kvalko@xxxxxxxxx>
- Date: Wed, 15 Aug 2007 13:54:51 -0400
- Message-id: <200708151354.51576.kvalko@xxxxxxxxx>
On Wednesday 15 August 2007 02:23:05 am Warren Stockton wrote:
> > problem is).
>
> Try setting "PROMPT_FOR_CONFIRM=yes" in /etc/sysconfig/boot. You might
> want to set CONFIRM_PROMPT_TIMEOUT to something longer than 5 seconds for
> the first couple of boots.
>
> I had similar problems on a HP dv6400 with some of the 10.3alpha kernels.
> In my case it turned out to be /etc/init.d/boot.clock and I could lock the
> system at will by running hwclock --systohc or hwclock --hctosys
> (I don't have the problem on the current 10.3beta1 kernel and could never
> quite nail down the root cause when I was seeing the problem on earlier
> kernels.)
>
Thanks for the pointer, that worked but not for the reasons I expected.
Once I set PROMPT_FOR_CONFIRM, I was able to step through the service startup
and boot properly with both the -default kernel and my own custom kernel. I
didn't need to use noapic.
However, booting without PROMPT_FOR_CONFIRM and without noapic produces a
total lock that occurs at some point between .localfs and .udev-retry, but
there are no error messages thrown and nothing indicated in the logs that
would point to where the issue is. Booting with noapic and without
PROMPT_FOR_CONFIRM also allows a normal boot, though with the stability
issues my system experiences with noapic. Bizarre.
The only thing I can think is that the parallel booting of services is somehow
causing an error condition in the kernel that doesn't occur when boot
prompting forces a delay between service starts, or something along those
lines? I'll do a round of trial and error, disabling each boot.xxx service
one by one to see if I can narrow it down, and maybe disabling parallel
services as well.
As far as the issue with the clock, I do remember running into that with
earlier kernels, I think it first cropped up in 2.6.20, there was some change
made that involved acpi, the clock and hpet or something along those lines; I
remember eliminating the problem by judiciously tweaking my .config settings,
but the problem seemed to have disappeared for me in recent kernels.
Any other pointers appreciated...
Thanks,
KV
---------------------------------------------------------------------
To unsubscribe, e-mail: opensuse-factory+unsubscribe@xxxxxxxxxxxx
For additional commands, e-mail: opensuse-factory+help@xxxxxxxxxxxx
> > problem is).
>
> Try setting "PROMPT_FOR_CONFIRM=yes" in /etc/sysconfig/boot. You might
> want to set CONFIRM_PROMPT_TIMEOUT to something longer than 5 seconds for
> the first couple of boots.
>
> I had similar problems on a HP dv6400 with some of the 10.3alpha kernels.
> In my case it turned out to be /etc/init.d/boot.clock and I could lock the
> system at will by running hwclock --systohc or hwclock --hctosys
> (I don't have the problem on the current 10.3beta1 kernel and could never
> quite nail down the root cause when I was seeing the problem on earlier
> kernels.)
>
Thanks for the pointer, that worked but not for the reasons I expected.
Once I set PROMPT_FOR_CONFIRM, I was able to step through the service startup
and boot properly with both the -default kernel and my own custom kernel. I
didn't need to use noapic.
However, booting without PROMPT_FOR_CONFIRM and without noapic produces a
total lock that occurs at some point between .localfs and .udev-retry, but
there are no error messages thrown and nothing indicated in the logs that
would point to where the issue is. Booting with noapic and without
PROMPT_FOR_CONFIRM also allows a normal boot, though with the stability
issues my system experiences with noapic. Bizarre.
The only thing I can think is that the parallel booting of services is somehow
causing an error condition in the kernel that doesn't occur when boot
prompting forces a delay between service starts, or something along those
lines? I'll do a round of trial and error, disabling each boot.xxx service
one by one to see if I can narrow it down, and maybe disabling parallel
services as well.
As far as the issue with the clock, I do remember running into that with
earlier kernels, I think it first cropped up in 2.6.20, there was some change
made that involved acpi, the clock and hpet or something along those lines; I
remember eliminating the problem by judiciously tweaking my .config settings,
but the problem seemed to have disappeared for me in recent kernels.
Any other pointers appreciated...
Thanks,
KV
---------------------------------------------------------------------
To unsubscribe, e-mail: opensuse-factory+unsubscribe@xxxxxxxxxxxx
For additional commands, e-mail: opensuse-factory+help@xxxxxxxxxxxx
| < Previous | Next > |