[lkml]   [2007]   [Aug]   [30]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: [PATCH] kexec: reenable HPET before kexec
    Konstantin Baydarov <> writes:

    > On Mon, 27 Aug 2007 11:26:29 -0700
    > "Pallipadi, Venkatesh" <> 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.

    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to
    More majordomo info at
    Please read the FAQ at

     \ /
      Last update: 2007-08-30 09:39    [W:0.020 / U:5.160 seconds]
    ©2003-2017 Jasper Spaans. hosted at Digital OceanAdvertise on this site