From: Vivek Goyal <vgoyal@in.ibm.com>
To: Neil Horman <nhorman@redhat.com>
Cc: kexec@lists.infradead.org
Subject: Re: Timer interrupt lost on some x86_64 systems
Date: Tue, 13 Nov 2007 12:52:07 +0530 [thread overview]
Message-ID: <20071113072207.GA24067@in.ibm.com> (raw)
In-Reply-To: <20071112151721.GB11751@hmsendeavour.rdu.redhat.com>
On Mon, Nov 12, 2007 at 10:17:21AM -0500, Neil Horman wrote:
> On Mon, Nov 12, 2007 at 10:19:03AM +0530, Vivek Goyal wrote:
> > On Wed, Nov 07, 2007 at 09:00:06AM -0500, Neil Horman wrote:
> > > Hey all-
> > > I've been getting reports of some x86_64 systems that, on kdump kernel
> > > boot get stuck in calibrate_delay(), in both RHEL kernels and upstream kernels.
> > > The current thinking is that the lapic timer interrupt is no longer getting
> > > delivered, likely because we handle a crash condition on a cpu that isn't the
> > > boot cpu. One known offender is this motherboard:
> > > http://www.supermicro.com/Aplus/motherboard/Opteron8000/MCP55/H8QM8-2.cfm
> > > My current thought is that the TIMER_LVT entry is masked on all but the boot cpu
> > > on this system (which is strange, as I was under the impression that the timer
> > > interrupt was supposed to be enabled on all CPU's nominally.
> >
> > I also thought that LAPIC timer interrupts are enabled on all cpus.
> >
> That doesn't appear to be the case. The configuration I've seen is that only
> one lapic has timer interrupts enabled, and the interrupt handler for the timer
> interrupt broadcasts the interrupt to all the other processors via IPI
>
> > > At any rate, I was
> > > going to try to read/write the TIMER_LVT on the crashing processor before we
> > > jump to purgatory, or in purgatory itself, to see if that fixes the problem, but
> >
> > I think calibrate_dealy() depends on external timer interrupt coming and
> > not the local APIC timer interrupt. Generally it is 8254 timer chip. Now a
> > days motherboards seems to be having HPET and I know somebody has reported
> > problems with HPET where HPET interrupts are not coming in second kernel and
> > system hangs in second kernel. I suspect that same might be the issue here.
> >
> Perhaps, do you have a pointer to any list discussions on the subject? I've not
> seen any yet.
>
http://lkml.org/lkml/2007/8/20/155
Reading through the thread again looks like this guy faced issue with
i386 machines and not x86_64 machines.
Thanks
Vivek
_______________________________________________
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec
prev parent reply other threads:[~2007-11-13 7:22 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
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 [this message]
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=20071113072207.GA24067@in.ibm.com \
--to=vgoyal@in.ibm.com \
--cc=kexec@lists.infradead.org \
--cc=nhorman@redhat.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.