From: Mark Lord <lkml@rtr.ca>
To: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Thomas Gleixner <tglx@linutronix.de>,
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 16:27:09 -0400 [thread overview]
Message-ID: <46FD639D.9030301@rtr.ca> (raw)
In-Reply-To: <alpine.LFD.0.999.0709221546250.16478@woody.linux-foundation.org>
Linus Torvalds wrote:
>
> On Sat, 22 Sep 2007, Thomas Gleixner wrote:
>> My final enlightment was, when I removed the ACPI processor module,
>> which controls the lower idle C-states, right before resume; this
>> worked fine all the time even without all the workaround hacks.
>>
>> I really hope that this two patches finally set an end to the "jinxed
>> VAIO heisenbug series", which started when we removed the periodic
>> tick with the clockevents/dyntick patches.
>
> Ok, so the patches look fine, but I somehow have this slight feeling that
> you gave up a bit too soon on the "*why* does this happen?" question.
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?
-ml
next prev parent reply other threads:[~2007-09-28 20:27 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 [this message]
2007-09-28 20:33 ` Thomas Gleixner
2007-09-28 21:17 ` Mark Lord
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=46FD639D.9030301@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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox