[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <653FFBB4508B9042B5D43DC9E18836F501522051@scsmsx415.amr.corp.intel.com>
Date: Mon, 27 Aug 2007 11:26:29 -0700
From: "Pallipadi, Venkatesh" <venkatesh.pallipadi@...el.com>
To: <vgoyal@...ibm.com>,
"Konstantin Baydarov" <kbaidarov@...mvista.com>
Cc: "RT" <linux-rt-users@...r.kernel.org>,
"linux-kernel" <linux-kernel@...r.kernel.org>,
"Eric W. Biederman" <ebiederm@...ssion.com>,
"Andi Kleen" <ak@...e.de>
Subject: RE: [PATCH] kexec: reenable HPET before kexec
>
>I think we should dive little deeper to find out the root
>cause of the problem
>instead of putting the intermediate patch. These timer issues
>are tricky
>ones and we have already solved few of these.
>
>Going back to your original mail where you specify root cause.
>
>- You mentioned that first kernel disables HPET while enabling
>Local APIC
>timer. Can you please point me when exactly it happens. I had
>thought local
>APIC timer and HPET server different purpose and co-exist.
>
>- You also mentioned that kernel tries to setup PIT as it does not find
>HPET in second kernel. Where exactly does it do that? I think
>we need to
>then go deeper to find out why PIT is not working now? Is it
>disabled? or
>LAPIC/IOAPIC have not been setup properly and PIT interrupts
>never reach
>CPU?
>
- 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
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists