From: Mohan Kumar M <mohan@in.ibm.com>
To: Nathan Lynch <ntl@pobox.com>
Cc: linuxppc-dev@ozlabs.org, fastboot@lists.osdl.org, anton@samba.org
Subject: Re: [RFC] Fix for interrupt distribution
Date: Tue, 31 Oct 2006 16:35:15 +0530 [thread overview]
Message-ID: <20061031110515.GB7884@in.ibm.com> (raw)
In-Reply-To: <20061030181751.GI17168@localdomain>
On Mon, Oct 30, 2006 at 12:17:51PM -0600, Nathan Lynch wrote:
> Mohan Kumar M wrote:
> > Hello,
> >
> > When kdump kernel is booted with the parameter "maxcpus=1" on a threaded
> > CPU, we faced some interrupt routing problems.
> >
> > In the xics initialization code, "reg" property in each cpu node
> > (device-tree/cpus/PowerPC,POWER5@x) is used to match the current boot
> > cpu id and based on that "default_server" and "default_distrib_server"
> > are calculated. This condition will always meet when OF chooses CPU0 as
> > boot cpu or crash happenes on any cpu whose id is any physical cpu id.
> >
> > The "reg" property in cpu node gives the id of the cpu and this cpu node
> > is created only for physical cpus (not for logical/threaded cpus). The
> > code compares the "reg" value to the current boot cpu id and if it
> > matches then only it reads "ibm,ppc-interrupt-gserver#s" and assigns the
> > last value of it (which is usually 0xff) to default_distrib_server. So
> > when a crash occurs on CPU 3, it will not be able to match the condition
> > and thus default_distrib_server is left as zero only. This makes all
> > interrupts routed to cpu 0 but cpu 0 is not up because of "maxcpus=1"
> > parameter.
> >
> > To overcome this, I have just added one more condition to check the
> > above condition. I have attached the patch also. Patch is generated over
> > 2.6.19-rc3.
> >
> > One more idea will be instead of using "reg" property in each cpu node,
> > can we use "ibm,ppc-interrupt-gserver#s" to determine the distribution
> > server? "ibm,ppc-interrupt-gserver#s" format is (please correct
> > if I am wrong)
> > phys_cpu_id distrib_server logical_cpu_id distrib_server
>
> Firmware has no notion of Linux's logical cpu numbering.
>
>
I have created a patch based on "ibm,ppc-interrupt-gserver#s" property.
Attached patch uses "ibm,ppc-interrupt-gserver#s" property to match the
boot cpu id with available cpu ids. The property
"ibm,ppc-interrupt-gserver#" is encoded as a list of server# and
gserver#s pairs. The first integer specifies a single processor server#
as presented in "ibm,ppc-interrupt-server#s" property and followed by
distribution server. So if a match is found, corresponding server# is
taken as default server and the corresponding gserver# is taken as
default distribution server.
In a Dual core SMT enabled system, "ibm,ppc-interrupt-gserver#s" for
PowerPC,POWER5@2 will be:
00000002 000000ff 00000003 000000ff
^ cpu id
^ distribution server
^ cpu id
^ distribution server
Tested on a POWER5 box.
Patch is generated over 2.6.19-rc3
Allow any cpu to become boot cpu.
Signed-off-by: Mohan Kumar M <mohan@in.ibm.com>
---
arch/powerpc/platforms/pseries/xics.c | 30 +++++++++++++++---------------
1 file changed, 15 insertions(+), 15 deletions(-)
Index: linux-2.6.19-rc3/arch/powerpc/platforms/pseries/xics.c
===================================================================
--- linux-2.6.19-rc3.orig/arch/powerpc/platforms/pseries/xics.c
+++ linux-2.6.19-rc3/arch/powerpc/platforms/pseries/xics.c
@@ -658,7 +658,7 @@ static void __init xics_setup_8259_casca
void __init xics_init_IRQ(void)
{
- int i;
+ int i, j;
struct device_node *np;
u32 ilen, indx = 0;
const u32 *ireg;
@@ -686,23 +686,23 @@ void __init xics_init_IRQ(void)
for (np = of_find_node_by_type(NULL, "cpu");
np;
np = of_find_node_by_type(np, "cpu")) {
- ireg = get_property(np, "reg", &ilen);
- if (ireg && ireg[0] == get_hard_smp_processor_id(boot_cpuid)) {
- ireg = get_property(np,
- "ibm,ppc-interrupt-gserver#s", &ilen);
- i = ilen / sizeof(int);
- if (ireg && i > 0) {
- default_server = ireg[0];
- /* take last element */
- default_distrib_server = ireg[i-1];
- }
- ireg = get_property(np,
+ ireg = get_property(np, "ibm,ppc-interrupt-gserver#s", &ilen);
+ i = ilen / sizeof(int);
+ for (j = 0; ireg[j] && j < i; j+=2) {
+ if (ireg[j] == get_hard_smp_processor_id(boot_cpuid)) {
+ if ( j + 1 < i) {
+ default_server = ireg[j];
+ default_distrib_server = ireg[j+1];
+ }
+ ireg = get_property(np,
"ibm,interrupt-server#-size", NULL);
- if (ireg)
- interrupt_server_size = *ireg;
- break;
+ if (ireg)
+ interrupt_server_size = *ireg;
+ goto out;
+ }
}
}
+out:
of_node_put(np);
if (firmware_has_feature(FW_FEATURE_LPAR))
next prev parent reply other threads:[~2006-10-31 11:05 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2006-10-30 18:04 [RFC] Fix for interrupt distribution Mohan Kumar M
2006-10-30 18:17 ` Nathan Lynch
2006-10-31 11:05 ` Mohan Kumar M [this message]
2006-11-06 22:46 ` Nathan Lynch
2006-11-16 12:56 ` Mohan Kumar M
2006-11-16 15:36 ` Anton Blanchard
2006-11-17 4:57 ` Mohan Kumar M
2006-11-17 12:12 ` Mohan Kumar M
2006-11-29 9:10 ` [PATCH] " Mohan Kumar M
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=20061031110515.GB7884@in.ibm.com \
--to=mohan@in.ibm.com \
--cc=anton@samba.org \
--cc=fastboot@lists.osdl.org \
--cc=linuxppc-dev@ozlabs.org \
--cc=ntl@pobox.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;
as well as URLs for NNTP newsgroup(s).