Messages in this thread | | | From | Frans Pop <> | Subject | "APIC error on CPU1: 00(40)" during resume (was: Regression from 2.6.26: Hibernation (possibly suspend) broken on Toshiba R500) | Date | Wed, 10 Dec 2008 15:06:43 +0100 |
| |
Anybody interested in persuing this issue?
On Thursday 04 December 2008, Linus Torvalds wrote: > Ingo, Len, can you check the end of the email about the apparent > very-early interrupt issue? Can we get into acpi_ec_gpe_handler() > without interrupts being enabled some way? > > HOWEVER. Having now looked through your fuller dmesg output even for > the _successful_ case, I actually find a few things that are a bit > worrying. [...] > 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 > > Now, that "APIC error" thing is worrisome. It's worrisome for multiple > reasons: > > - errors are never good (0x40 means "received illegal vector", > whatever caused _that_) > > - more importantly, it seems to imply that interrupts are enabled on > CPU1, and they sure as hell shouldn't be enabled at this stage! > > Do we perhaps have a SMP resume bug where we resume the other CPU's > with interrupts enabled? > > - the "ACPI: EC: non-query interrupt received, switching to interrupt > mode" thing is from ACPI, and _also_ implies that interrupts are on. > > Why are interrupts enabled that early? I really don't like seeing > interrupts enabled before we've even done the basic PCI resume. > > I'd really like to resume the other CPU's much later (last in the whole > sequnce, long after we've set up devices), but the f'ing ACPI rules > seem to be against that. And maybe some setup actually needs the CPU's > alive to act as a bridge for IO (eg with HT or CSI).
| |