linux-kernel - Re: "APIC error on CPU1: 00(40)" during resume (was: Regression from 2.6.26: Hibernation (possibly suspend) broken on Toshiba R500)

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: <alpine.LFD.2.00.0812100819570.3340@localhost.localdomain>
Date:	Wed, 10 Dec 2008 08:26:37 -0800 (PST)
From:	Linus Torvalds <torvalds@...ux-foundation.org>
To:	Frans Pop <elendil@...net.nl>
cc:	Ingo Molnar <mingo@...e.hu>, lenb@...nel.org,
	"Rafael J. Wysocki" <rjw@...k.pl>, Greg KH <greg@...ah.com>,
	jbarnes@...tuousgeek.org,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
	tiwai@...e.de, Andrew Morton <akpm@...ux-foundation.org>
Subject: Re: "APIC error on CPU1: 00(40)" during resume (was: Regression from
 2.6.26: Hibernation (possibly suspend) broken on Toshiba R500)



Ingo - who's the main apic person these days?

On Wed, 10 Dec 2008, Frans Pop wrote:

> On Wednesday 10 December 2008, Linus Torvalds wrote:
> > On Wed, 10 Dec 2008, Frans Pop wrote:
> > > Anybody interested in persuing this issue?
> > >
> > > > The third thing that worries me is the _very_ early occurrence of
> > > >
> > > > 	ACPI: Waking up from system sleep state S3
> > > > 	APIC error on CPU1: 00(40)
> > > > 	ACPI: EC: non-query interrupt received, switching to interrupt
> > > > mode
> >
> > Well, the "too early" part is fixed with the PCI resume changes in
> > -next, and googling for "APIC error on CPU1: 00(40)" shows that it's
> > actually pretty common. Which is sad, but makes it somewhat less scary.
> >
> > The fact that it happens at resume for you (and not randomly) does
> > imply that we perhaps don't have a wonderful APIC wakeup sequence and
> > are doing something slightly wrong. But it likely isn't a big deal.
> >
> > Is that message new? If it is, maybe you can pinpoint roughly when it
> > started happening, and we could try guess which change triggered it.
> 
> It's been there since 2.6.26.3, which was the first kernel I've run on 
> this notebook.

Hmm. Our IO-APIC reprogramming looks pretty simple, and may well be 
correct.

However, it looks like our _local_ APIC suspend/resume is a total piece of 
sh*t.  It's set up as a "system device" and has a single suspend/resume 
buffer, but the local APIC is a per-CPU thing. We even have a comment 
there (written by yours trule back in 2003!) that says:

         * FIXME! This will be wrong if we ever support suspend on
         * SMP! We'll need to do this as part of the CPU restore!

and back then suspend/resume on SMP was just a crazy notion, but now it's 
obviously every-day reality. 

So it looks like we don't reprogram the APIC -at-all- on secondary CPU's.

What am I missing?

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