Re: [PATCH] kexec: reenable HPET before kexec

[Eric W. Biederman]

Konstantin Baydarov <kbaidarov@xxxxxxxxxxxxx> writes:

> On Mon, 27 Aug 2007 11:26:29 -0700
> "Pallipadi, Venkatesh" <venkatesh.pallipadi@xxxxxxxxx> wrote:
>
>> 
>> 
>> - Another thing to try is to disable HPET and boot with PIT in the
>> first kernel. Just to check whether PIT never works on this platform
>> or the first kernel is doing something to stop PIT. You can try
>> "hpet=disable" boot option for that.
>> 
>> Thanks,
>> Venki
>
> I've tried kernel 1 with HPET disabled - it boots fine, PIT works!
> Then I made additional investigations and found out that PIT won't work
> in kernel 2 if bit HPET_CFG_LEGACY is set.
> Bit HPET_CFG_LEGACY is set by hpet_enable_int() during HPET
> initialization, so if this bit is cleared in machine_kexec() kernel 2
> boots fine.
> I can't explain this magic, maybe someone can explain this. Thanks.
>
> Here is new version of workaround for 2.6.23-rc3

Ok.  It looks like you understand this issue.

Can you please try calling hpet_disable_int from
hpet_set_mode under CLOCK_EVT_MODE_SHUTDOWN.  I haven't
traced the clock event methods all of the way through
but as a first approximation I think that will get
things called at the appropriate time with out needing
to patch machine_kexec.  Which is very much the wrong
place to add call any hpet code from.

We may also need to make the hpet initialization more
robust so we can do something sane in the kexec on panic
case, where we deliberately don't run any shutdown methods.

Eric
-
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/