Kexec Archive on lore.kernel.org
 help / color / mirror / Atom feed
From: Neil Horman <nhorman@redhat.com>
To: Vivek Goyal <vgoyal@in.ibm.com>
Cc: Neil Horman <nhorman@redhat.com>, kexec@lists.infradead.org
Subject: Re: Timer interrupt lost on some x86_64 systems
Date: Tue, 13 Nov 2007 09:33:30 -0500	[thread overview]
Message-ID: <20071113143330.GA16830@hmsendeavour.rdu.redhat.com> (raw)
In-Reply-To: <20071113073128.GB24067@in.ibm.com>

On Tue, Nov 13, 2007 at 01:01:28PM +0530, Vivek Goyal wrote:
> On Mon, Nov 12, 2007 at 10:41:19AM -0500, Neil Horman wrote:
> [..]
> > 
> > 
> > Although, as I look at it, it would appear that time_init from start_kernel does
> > seem to init the hpet if its available, and it silently fails if that doesn't
> > work, moving on to the pmtimer and pit.  I wonder if there is some extra magic
> > to resetting the hpet to run on a different cpu for some systems...
> > Neil
> > 
> 
> Any idea what kind of timer devices this motherborad has got? Which timer
> device gets activated in first kernel? Then we can focus on why the
> interrupts from same device are not coming in second kernel.
> 

Not sure, thats a course of investigation I've got planned to pursue when our on
site guy gets back from a conference next week.


> In the past I have found issues with interrupt routing on IOPAPIC and
> interrupt lockup on LAPIC. But these issues are already solved. I would
> also think of priting LAPIC and IOAPIC entries to see how timer interrupt
> routing changes from first kernel to second.
> 
I recently read the ioapic section in the opteron processor guide and noted the
ioapic routing field in the config registers, so I'll be looking at that.  We
also not that in the failing case on the systems in question the boot cpu is
_not_ the cpu that boots the kdump kernel, and its APIC ID is 1 not 0, IIRC

Thanks
Neil

> Thanks
> Vivek

-- 
/***************************************************
 *Neil Horman
 *Software Engineer
 *Red Hat, Inc.
 *nhorman@redhat.com
 *gpg keyid: 1024D / 0x92A74FA1
 *http://pgp.mit.edu
 ***************************************************/

_______________________________________________
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec

  reply	other threads:[~2007-11-13 14:39 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-11-07 14:00 Timer interrupt lost on some x86_64 systems Neil Horman
2007-11-12  4:49 ` Vivek Goyal
2007-11-12 15:17   ` Neil Horman
2007-11-12 15:41     ` Neil Horman
2007-11-13  7:31       ` Vivek Goyal
2007-11-13 14:33         ` Neil Horman [this message]
2007-11-14  6:39           ` Vivek Goyal
2007-11-14 11:51             ` Neil Horman
2007-11-22 20:04               ` Eric W. Biederman
2007-11-13  7:22     ` Vivek Goyal

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20071113143330.GA16830@hmsendeavour.rdu.redhat.com \
    --to=nhorman@redhat.com \
    --cc=kexec@lists.infradead.org \
    --cc=vgoyal@in.ibm.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox