From: ebiederm@xmission.com (Eric W. Biederman)
To: Neil Horman <nhorman@redhat.com>
Cc: Vivek Goyal <vgoyal@in.ibm.com>, kexec@lists.infradead.org
Subject: Re: Timer interrupt lost on some x86_64 systems
Date: Thu, 22 Nov 2007 13:04:38 -0700 [thread overview]
Message-ID: <m163zuoxm1.fsf@ebiederm.dsl.xmission.com> (raw)
In-Reply-To: <20071114115132.GA21411@hmsendeavour.rdu.redhat.com> (Neil Horman's message of "Wed, 14 Nov 2007 06:51:32 -0500")
Neil Horman <nhorman@redhat.com> writes:
> On Wed, Nov 14, 2007 at 12:09:39PM +0530, Vivek Goyal wrote:
>> On Tue, Nov 13, 2007 at 09:33:30AM -0500, Neil Horman wrote:
>>
>> [..]
>> > > 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
>> >
>>
>> Failing on non-boot cpu should not be an issue. I had fixed an issue in the
>> past where non-boot cpu was not receiving the timer interrupts because of
>> IOAPIC settings where timer interrupts were always routed to boot cpu (cpu0).
>>
>> Now it has been modified and while going down we determine which cpu we
>> are crashing on and setup IOAPIC entry accordingly. See disable_IO_APIC().
>>
>
> I see the call to it in machine_crash_shutdown, but for whatever reason, it
> doesn't seem to be having the desired effect in this case....hmmmmm...
I don't know if anything has happened. However a lot of this looks like
going back to the current todo list item of getting the kernel to come up
initially in ioapic mode.
That simultaneously removes the need for machine_kexec to reprogram interrupts
in virtual wire mode and it should ultimately simplify and make more robust
irq initialization. At the very least reducing the amount of magic in
early irq processing.
Eric
_______________________________________________
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec
next prev parent reply other threads:[~2007-11-22 20:05 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 [this message]
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=m163zuoxm1.fsf@ebiederm.dsl.xmission.com \
--to=ebiederm@xmission.com \
--cc=kexec@lists.infradead.org \
--cc=nhorman@redhat.com \
--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