linux-kernel - Re: [patch 00/26] x64, x2apic/intr-remap: Interrupt-remapping and x2apic support

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20080711212418.GV1678@linux-os.sc.intel.com>
Date:	Fri, 11 Jul 2008 14:24:19 -0700
From:	Suresh Siddha <suresh.b.siddha@...el.com>
To:	Ingo Molnar <mingo@...e.hu>
Cc:	Yinghai Lu <yhlu.kernel@...il.com>,
	"Siddha, Suresh B" <suresh.b.siddha@...el.com>,
	"hpa@...or.com" <hpa@...or.com>,
	"tglx@...utronix.de" <tglx@...utronix.de>,
	"akpm@...ux-foundation.org" <akpm@...ux-foundation.org>,
	"arjan@...ux.intel.com" <arjan@...ux.intel.com>,
	"andi@...stfloor.org" <andi@...stfloor.org>,
	"ebiederm@...ssion.com" <ebiederm@...ssion.com>,
	"jbarnes@...tuousgeek.org" <jbarnes@...tuousgeek.org>,
	"steiner@....com" <steiner@....com>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	"jeremy@...p.org" <jeremy@...p.org>
Subject: Re: [patch 00/26] x64, x2apic/intr-remap: Interrupt-remapping and x2apic support

On Fri, Jul 11, 2008 at 01:45:21PM -0700, Ingo Molnar wrote:
> 
> * Yinghai Lu <yhlu.kernel@...il.com> wrote:
> 
> > Setting APIC routing to physical flat
> > Kernel panic - not syncing: Boot APIC ID in local APIC unexpected (0 vs 4)
> > Pid: 1, comm: swapper Not tainted 2.6.26-rc9-tip-01763-g74f94b1-dirty #320
> >
> > Call Trace:
> >  [<ffffffff80a21505>] ? set_cpu_sibling_map+0x38c/0x3bd
> >  [<ffffffff80245215>] ? read_xapic_id+0x25/0x3e
> >  [<ffffffff80e5a2c3>] ? verify_local_APIC+0x139/0x1b9
> >  [<ffffffff80245215>] ? read_xapic_id+0x25/0x3e
> >  [<ffffffff80e589af>] ? native_smp_prepare_cpus+0x224/0x2e9
> >  [<ffffffff80e4881a>] ? kernel_init+0x64/0x341
> >  [<ffffffff8022a439>] ? child_rip+0xa/0x11
> >  [<ffffffff80e487b6>] ? kernel_init+0x0/0x341
> >  [<ffffffff8022a42f>] ? child_rip+0x0/0x11
> >
> >
> > guess read_apic_id changing cuase some problem...

Yinghai, Can you please try the appended patch to see if it fixes your problem?

I guess you need to try the tip/x86/x2apic tree now please :(

BTW, I don't know why we even do verify_local_APIC() in 64bit. Especially
when we don't care for the return value, it should be a no-op.

---
genapic's read_apic_id() returns the actual apic id extracted from
the APIC_ID register. And in some cases like UV, read_apic_id()
returns completely different values from APIC ID register.

Use the native apic register read, rather than genapic read_apic_id()
in verify_local_APIC()

And also, lapic_suspend() should also use native apic register read.

Signed-off-by: Suresh Siddha <suresh.b.siddha@...el.com>
---

diff --git a/arch/x86/kernel/apic_64.c b/arch/x86/kernel/apic_64.c
index 9a319d7..dd05010 100644
--- a/arch/x86/kernel/apic_64.c
+++ b/arch/x86/kernel/apic_64.c
@@ -698,10 +698,10 @@ int __init verify_local_APIC(void)
 	/*
 	 * The ID register is read/write in a real APIC.
 	 */
-	reg0 = read_apic_id();
+	reg0 = apic_read(APIC_ID);
 	apic_printk(APIC_DEBUG, "Getting ID: %x\n", reg0);
 	apic_write(APIC_ID, reg0 ^ APIC_ID_MASK);
-	reg1 = read_apic_id();
+	reg1 = apic_read(APIC_ID);
 	apic_printk(APIC_DEBUG, "Getting ID: %x\n", reg1);
 	apic_write(APIC_ID, reg0);
 	if (reg1 != (reg0 ^ APIC_ID_MASK))
@@ -1336,7 +1336,7 @@ static int lapic_suspend(struct sys_device *dev, pm_message_t state)
 
 	maxlvt = lapic_get_maxlvt();
 
-	apic_pm_state.apic_id = read_apic_id();
+	apic_pm_state.apic_id = apic_read(APIC_ID);
 	apic_pm_state.apic_taskpri = apic_read(APIC_TASKPRI);
 	apic_pm_state.apic_ldr = apic_read(APIC_LDR);
 	apic_pm_state.apic_dfr = apic_read(APIC_DFR);
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/