> >> @@ -1263,6 +1264,11 @@
> >> }
> >> printk(KERN_CRIT "apm: suspend was vetoed, but suspending anyway.\n");
> >> }
> >> +
> >> + device_suspend(3, SUSPEND_NOTIFY);
> >> + device_suspend(3, SUSPEND_SAVE_STATE);
> >Comment these two lines... and all RESTORE_STATEs. System needs to be
> >stopped in order for SAVE_STATE to work, and it is not in apm case.
> What's the proper fix? apm must be able to initiate suspend &
In theory, apm must be able to initiate suspend & resume. But by the
same theory, apm bios should be doing hardware save stating itself --
and it obviously does not.
freeze_processes() should not fail, anyway, so right fix is to wrap
this with freeze_processes() and resume_processes().
Alternate fix is to invent level 6 and use it for apm. Things like ide
would then ignore level 6 (as apm is likely to do the right thing in
> >Do you think it is neccessary to call it "*local_*apic_nmi_driver"? It
> >seems way too long.
> Local APIC != I/O APIC. I try to be a caretaker for the former,
> so I dislike the ambiguous term "APIC".
> >Why did you convert device_apic_nmi to *sys_*device?
> Otherwise the NMI watchdog device wouldn't show up in /sys.
Strange, it was there for me, IIRC.
> >This is good, if we have disable_, we should have enable_, not setup_;
> >but I killed _local_ part as it is way too long, then.
> Note that there is also an I/O APIC NMI generator.
> If you drop the "local" qualifier, things get ambiguous.
> Although I find it ugly, I could accept "lapic" as a shorter
> replacement for "local_apic" in identifiers.
Yep, lapic seems okay.
-- When do you have a heart between your knees? [Johanka's followup: and *two* hearts?] - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to email@example.com More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/