Konstantin Baydarov <kbaidarov at ru.mvista.com> writes: > On Mon, 27 Aug 2007 11:26:29 -0700 > "Pallipadi, Venkatesh" <venkatesh.pallipadi at intel.com> 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
