Re: "APIC error on CPU1: 00(40)" during resume (was: Regression from2.6.26: Hibernation (possibly suspend) broken on Toshiba R500)

[Linus Torvalds]

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@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/