From: Mark Lord <lkml@rtr.ca>
To: Thomas Gleixner <tglx@linutronix.de>
Cc: Linus Torvalds <torvalds@linux-foundation.org>,
Andrew Morton <akpm@linux-foundation.org>,
LKML <linux-kernel@vger.kernel.org>, Ingo Molnar <mingo@elte.hu>,
Len Brown <lenb@kernel.org>,
Venkatesh Pallipadi <venkatesh.pallipadi@intel.com>,
"Rafael J. Wysocki" <rjw@sisk.pl>
Subject: Re: [patch 0/2] suspend/resume regression fixes
Date: Fri, 28 Sep 2007 17:17:55 -0400 [thread overview]
Message-ID: <46FD6F83.8070801@rtr.ca> (raw)
In-Reply-To: <1191011610.18681.94.camel@chaos>
Thomas Gleixner wrote:
> On Fri, 2007-09-28 at 16:27 -0400, Mark Lord wrote:
..
>> On a closely related note: I just now submitted a patch to fix SMP-poweroff,
>> by having it do disable_nonboot_cpus before doing poweroff.
>>
>> Which has led me to thinking..
>> ..are similar precautions perhaps necessary for *all* ACPI BIOS calls?
>>
>> Because one never knows what the other CPUs are doing at the same time,
>> and what the side effects may be on the ACPI BIOS functions.
>>
>> And also, I wonder if at a minimum we should be guaranteeing ACPI BIOS calls
>> only ever happen from CPU#0 (or the "boot" CPU)? Or do we do that already?
>
> The ACPI calls are serialized in the kernel, AFAICT. But the fragile
> situations (suspend, resume, shutdown, reboot) are probably those, where
> some BIOS implementation expect that certain things are not called or
> not active.
Mmm.. *do* we actually do this for reboot? I don't see it there.
And how about for kexec?
I'm probably just missing seeing it. Right?
Cheers
next prev parent reply other threads:[~2007-09-28 21:18 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-09-22 22:29 [patch 0/2] suspend/resume regression fixes Thomas Gleixner
2007-09-22 22:29 ` [patch 1/2] ACPI: disable lower idle C-states across suspend/resume Thomas Gleixner
2007-10-01 10:11 ` Andi Kleen
2007-09-22 22:29 ` [patch 2/2] clockevents: remove the suspend/resume workaround^Wthinko Thomas Gleixner
2007-09-22 22:59 ` [patch 0/2] suspend/resume regression fixes Linus Torvalds
2007-09-22 23:30 ` Thomas Gleixner
2007-09-23 1:20 ` Oleg Verych
2007-09-23 3:11 ` Linus Torvalds
2007-09-23 5:24 ` Mihai Donțu
2007-09-23 12:30 ` Alan Cox
2007-09-23 13:00 ` Mihai Donțu
2007-09-23 14:06 ` Matthew Garrett
2007-09-23 10:29 ` Rafael J. Wysocki
2007-09-28 20:27 ` Mark Lord
2007-09-28 20:33 ` Thomas Gleixner
2007-09-28 21:17 ` Mark Lord [this message]
2007-09-28 21:40 ` Rafael J. Wysocki
2007-09-28 21:04 ` Alan Cox
2007-09-29 17:12 ` Bill Davidsen
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=46FD6F83.8070801@rtr.ca \
--to=lkml@rtr.ca \
--cc=akpm@linux-foundation.org \
--cc=lenb@kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@elte.hu \
--cc=rjw@sisk.pl \
--cc=tglx@linutronix.de \
--cc=torvalds@linux-foundation.org \
--cc=venkatesh.pallipadi@intel.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.