LKML Archive on lore.kernel.org
help / color / mirror / Atom feed
From: Vivek Goyal <vgoyal@in.ibm.com>
To: "Eric W. Biederman" <ebiederm@xmission.com>
Cc: Benjamin Romer <benjamin.romer@unisys.com>, linux-kernel@vger.kernel.org
Subject: Re: PATCH: Update disable_IO_APIC to use 8-bit destination field (X86_64)
Date: Thu, 18 Jan 2007 09:11:53 +0530	[thread overview]
Message-ID: <20070118034153.GA5406@in.ibm.com> (raw)
In-Reply-To: <m1tzyp8o8v.fsf@ebiederm.dsl.xmission.com>

On Wed, Jan 17, 2007 at 12:08:48PM -0700, Eric W. Biederman wrote:
> Benjamin Romer <benjamin.romer@unisys.com> writes:
> 
> > On the Unisys ES7000/ONE system, we encountered a problem where
> > performing a kexec reboot or dump on any cell other than cell 0 causes
> > the system timer to stop working, resulting in a hang during timer
> > calibration in the new kernel.
> >
> > We traced the problem to one line of code in disable_IO_APIC(), which
> > needs to restore the timer's IO-APIC configuration before rebooting. The
> > code is currently using the 4-bit physical destination field, rather
> > than using the 8-bit logical destination field, and it cuts off the
> > upper 4 bits of the timer's APIC ID. If we change this to use the
> > logical destination field, the timer works and we can kexec on the upper
> > cells. This was tested on two different cells (0 and 2) in an ES7000/ONE
> > system.
> >
> > For reference, the relevant Intel xAPIC spec is kept at
> > ftp://download.intel.com/design/chipsets/e8501/datashts/30962001.pdf,
> > specifically on page 334.
> 
> Looks like good bug hunting.  I will have to look but it might
> make more sense to simply fix: struct IO_APIC_route_entry,
> or use whatever technique we normally use to generate the io_apic
> vectors.
> 
> I don't recall enough off of the top of my head to recall what
> the discrimination rule between logical and physical is but
> I think setting the system in physical mode is a good clue :)

Hi Eric,

In physical destination mode, the destination APIC is determined by 
APIC ID and in logical destination mode, destination apics are determined
by the configurations based on LDR and DFR registers in APIC (Depending
on Flat mode or cluster mode).

Looks like previously one supported only 4bit apic ids if system is
operating in physical mode and 8bit ids if IOAPIC is put in logical
destination mode. That's why, struct IO_APIC_route_entry is containing
4bits for physical apic id.

http://www.intel.com/design/chipsets/datashts/290566.htm

And now newer systems have switched to 8bit apic ids in physical mode.
That's why if somebody is crashing on a cpu whose apic id is more than
16, kexec/kdump code will fail as 4bits are not sufficient.

Hence above change makes sense. Given the fact that logical and physical
apic id is basically a union, it will work even for older systems where
physical apic ids were 4bits only.

OTOH, I think down the line we can get rid of physical dest
field all together in struct IO_APIC_route_entry and use logical dest
field.

Thanks
Vivek

  reply	other threads:[~2007-01-18  3:42 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-01-17 16:46 Benjamin Romer
2007-01-17 19:08 ` Eric W. Biederman
2007-01-18  3:41   ` Vivek Goyal [this message]
2007-01-18  4:36     ` Vivek Goyal
2007-01-18  7:10       ` Eric W. Biederman
     [not found]         ` <2 0070118080003.GC31860@in.ibm.com>
2007-01-18  8:00         ` Vivek Goyal
2007-01-18 14:58           ` Benjamin Romer
2007-01-18 17:23           ` Benjamin Romer
2007-01-18 18:14             ` Eric W. Biederman
     [not found]               ` <1169147619.6665. 11.camel@ustr-romerbm-2.na.uis.unisys.com>
2007-01-18 19:13               ` Benjamin Romer
2007-01-19  3:49                 ` Vivek Goyal
2007-01-19 15:11                   ` Benjamin Romer
2007-01-19 15:43                     ` Randy Dunlap
2007-01-19 17:14                       ` Benjamin Romer
2007-01-19 15:55                     ` Eric W. Biederman

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=20070118034153.GA5406@in.ibm.com \
    --to=vgoyal@in.ibm.com \
    --cc=benjamin.romer@unisys.com \
    --cc=ebiederm@xmission.com \
    --cc=linux-kernel@vger.kernel.org \
    --subject='Re: PATCH: Update disable_IO_APIC to use 8-bit destination field (X86_64)' \
    /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

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).