linux-kernel - Re: 2.6.27-rc3: 'APIC error on CPU1: 00(40)', but only on resume!

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: <Pine.LNX.4.55.0808211340100.22938@cliff.in.clinika.pl>
Date:	Thu, 21 Aug 2008 13:57:24 +0100 (BST)
From:	"Maciej W. Rozycki" <macro@...ux-mips.org>
To:	Vegard Nossum <vegard.nossum@...il.com>
cc:	"Rafael J. Wysocki" <rjw@...k.pl>, Frans Pop <elendil@...net.nl>,
	linux-kernel@...r.kernel.org, Andi Kleen <andi@...stfloor.org>,
	Ingo Molnar <mingo@...e.hu>
Subject: Re: 2.6.27-rc3: 'APIC error on CPU1: 00(40)', but only on resume!

On Thu, 21 Aug 2008, Vegard Nossum wrote:

> Ah, right. Here is a dump of the LVT registers:
> 
> [00000320] = 000100ef
> [00000330] = 00000200
> [00000340] = 00010000
> [00000350] = 00010700
> [00000360] = 00000400
> [00000370] = 000000fe
> 
> Maybe I've misunderstood something (again), but should those vectors
> really be 0 for 330-360? (At least 330 + 360, which are not masked.)

 Masked entries should be fine long-term, although I have a vague
recollection at least some implementations do send a vector error when an
LVT register is written with a masked entry implying an invalid vector,
e.g. a value like 0x00010000.

 Overall the issue of the validity of the vector exists for interrupts
using the native APIC priority model only, that is ones using the Fixed
and LoPri delivery modes.  All the others either ignore the vector 
altogether, such as the ExtINTA delivery mode, or assign a special meaning 
to it, such as the StartUp mode.

 In this case the thermal entry at 0x330 uses the SMI delivery mode and
the LINT1 entry at 0x360 uses the NMI mode, so the vector is ignored for
both.

 Thus this LVT is entirely valid and if you receive invalid vector
interrupts, then the reason must be elsewhere.  Of course you cannot
exclude a possibility where at some intermediate stage the LVT of your
system has not been correctly initialised.

  Maciej
--
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/