Hi!
commit 559bbe6cbd0d8c68d40076a5f7dc98e3bf5864b2
Author: Pavel Machek [EMAIL PROTECTED]
Date: Thu Feb 21 13:56:55 2008 +0100
power_state: get rid of write-only variable in SATA
This is pretty unlikely to be it. Can you double check that this patch
really
Hi!
commit 559bbe6cbd0d8c68d40076a5f7dc98e3bf5864b2
Author: Pavel Machek [EMAIL PROTECTED]
Date: Thu Feb 21 13:56:55 2008 +0100
power_state: get rid of write-only variable in SATA
This is pretty unlikely to be it. Can you double check
Hi!
Thanks, applied.
With this, I also find that I dislike the use of suspend/resume for
freezing for STD a lot less. It's still too easy to get confused, but at
least now drivers always have total knowledge about what is really going
on. I'd not like this interface as a driver writer,
Apart from those issues it looks fine to me.
OK, please have a look at the modified patch below.
Seems to work here after basic tests. ACK.
(I discovered that -rc2 swsusp will not power down in some cases, but
it was here before the patch, too...)
On Wed 2008-02-13 00:32:16, Rafael J. Wysocki wrote:
From: Rafael J. Wysocki [EMAIL PROTECTED]
The _WAK global ACPI control method has to be called with the
argument representing the sleep state being exited. Make it happen.
Special thanks to Mirco Tischler [EMAIL PROTECTED] for reporting
I wonder if there a way to check that we are realy in real mode ?
Yes. In real mode bit 0 of the cr0 register should be 0.
It is not as simple. There's stuff like unreal mode... real mode
with 4GB descriptor limits... and similar crazyness.
On Fri 2008-02-08 01:29:23, Len Brown wrote:
From: Carlos Corbacho [EMAIL PROTECTED]
As Pavel Machek has pointed out, the Kconfig entry for WMI is pretty
non-descriptive.
Rewrite it so that it explains what ACPI-WMI is, and why anyone
would want to enable it.
Many thanks to Ray Lee
Hi!
If I remove stack access (remove clearing flag stuff, not call to video
stuff) the resume works.
Hm, can you place a pushl %eax; popl %eax; in place of the removed code
and
see if that breaks?
Yes that also break.
Hmm, and what kind of machine is that?
processor : 0
Hi!
Hmm, maybe I know where problem could be. Try
movl $(wakeup_stack - wakeup_code), %esp #
Private stack is needed for ASUS bo\
instead of existing stack setup. That helped on one of my test-boxes
Thanks, I will try that.
Because clearing the flags imply
On Thu 2008-02-07 17:27:38, Len Brown wrote:
On Thursday 07 February 2008 16:47, Pavel Machek wrote:
See? It even has completely useless help text.
Does WMI stand for Windows Management Instrumentation? It is some
server management feature? What is it good for?
Thank you
Hi!
On Friday 08 February 2008 00:12:24 Ray Lee wrote:
While I'm not trying to set you up for a firing squad, if you can show
that the only use this driver has is as underlying support for Acer/HP
xyz drivers,
Certainly at the moment, this is the only real use it has (and the only
On Wed 2008-02-06 23:40:35, matthieu castet wrote:
Rafael J. Wysocki wrote:
On Wednesday, 6 of February 2008, matthieu castet wrote:
Hi,
matthieu castet wrote:
matthieu castet wrote:
Pavel Machek wrote:
Hmm, maybe I know where problem could be. Try
movl $(wakeup_stack
-by: Johannes Berg [EMAIL PROTECTED]
Acked-by: Russell King [EMAIL PROTECTED]
Acked-by: Paul Mackerras [EMAIL PROTECTED]
Acked-by: Ralf Baechle [EMAIL PROTECTED]
Acked-by: Paul Mundt [EMAIL PROTECTED]
Cc: Pavel Machek [EMAIL PROTECTED]
ACK.
--
(english) http://www.livejournal.com/~pavelmachek
On Wed 2008-01-16 13:37:18, Rafael J. Wysocki wrote:
On Wednesday, 16 of January 2008, Pavel Machek wrote:
On Tue 2008-01-15 23:22:33, Len Brown wrote:
On Thursday 10 January 2008 19:18, Rafael J. Wysocki wrote:
Len,
Please add the following three patches to the suspend branch
On Tue 2008-01-15 23:22:33, Len Brown wrote:
On Thursday 10 January 2008 19:18, Rafael J. Wysocki wrote:
Len,
Please add the following three patches to the suspend branch.
Applied (and suspend branch has been re-based to latest linus tree)
Was that lets reorder notifications, old order
[EMAIL PROTECTED] ~]$ cat /proc/acpi/wakeup
Device S-state Status Sysfs node PCI ID
SLPB S4*enabled
P32 S4 disabled pci::00:1e.0 0x244e
UAR1 S4 disabled pnp:00:090x
This should tell you how bad is placing PCI ID into
On Sat 2008-01-12 04:16:08, Len Brown wrote:
On Friday 11 January 2008 21:23, Henrique de Moraes Holschuh wrote:
While helping a user find out what happened to his mute key, I found out
that the Lenovo BIOSes need the OSI string Linux defined to behave properly
in Linux.
Lenovo has
Hi!
On kohjinsha, wakeup code does not seem to be reached at all. I tried
looking around FACS, but it seems very empty:
...
The same on my laptop:
FACS @ 0x2fefafc0
signature length hwsignature waking_vector
: 46 41 43 53 40 00 00 00 62 12 00 00 00
HI!
On kohjinsha, wakeup code does not seem to be reached at all. I tried
looking around FACS, but it seems very empty:
...
The same on my laptop:
FACS @ 0x2fefafc0
: 46 41 43 53 40 00 00 00 62 12 00 00 00 00 00 00 [EMAIL PROTECTED]
0010: 00 00 00 00 00 00 00 00 00 00 00
Hi!
That way any suspend breakage would be detectable (and bisectable)
in automated testing - if the resume does not come back after 10-20
seconds then the test failed.
Yes, but please note that some systems require user space
manipulations of the graphics adapter for
On Thu 2007-12-27 19:15:16, Rafael J. Wysocki wrote:
From: Rafael J. Wysocki [EMAIL PROTECTED]
The execution of ACPI global control methods _GTS and _BFS is
currently tied to the preparation to enter a sleep state and to the
leaving of the sleep state, respectively. However, these functions
On Wed 2008-01-02 10:03:59, Yi Yang wrote:
On Wed, 2008-01-02 at 00:20 +0100, Pavel Machek wrote:
Hi!
/proc/acpi/wakeup is also case-sensitive, case-insensitive is better.
Why?
A user uses device bus id like 'C093' to enable or disable wakeup of the
device, for example
echo C093
Hi!
On kohjinsha, wakeup code does not seem to be reached at all. I tried
looking around FACS, but it seems very empty:
(none):/data/l/kohji# acpidump -t FACS
FACS @ 0x1f7bffc0
: 46 41 43 53 40 00 00 00 00 00 00 00 00 00 00 00
[EMAIL PROTECTED]
0010: 00 00 00 00 00 00 00 00 00 00 00 00
Hi!
/proc/acpi/wakeup is also case-sensitive, case-insensitive is better.
Why?
In addtion, this patch appends a new column 'PCI ID' to /proc/acpi/wakeup
, the user can use it to get the corresponding device name very
conveniently because PCI ID is a unique identifier and
On Mon 2007-12-24 10:51:15, Alan Stern wrote:
On Mon, 24 Dec 2007, Rafael J. Wysocki wrote:
Hi,
Some device drivers register CPU hotplug notifiers and use them to destroy
device objects when removing the corresponding CPUs and to create these
objects
when adding the CPUs back.
On Mon 2007-12-24 01:56:34, Rafael J. Wysocki wrote:
From: Rafael J. Wysocki [EMAIL PROTECTED]
The MSR driver should not attempt to destroy/create a suspended
device.
Signed-off-by: Rafael J. Wysocki [EMAIL PROTECTED]
ACK.
--
(english) http://www.livejournal.com/~pavelmachek
(cesky,
On Mon 2007-12-24 01:57:17, Rafael J. Wysocki wrote:
From: Rafael J. Wysocki [EMAIL PROTECTED]
The x86-64 MCE driver should not attempt to destroy/create a suspended
device.
Signed-off-by: Rafael J. Wysocki [EMAIL PROTECTED]
ACK.
--
(english) http://www.livejournal.com/~pavelmachek
On Mon 2007-12-24 01:57:57, Rafael J. Wysocki wrote:
From: Rafael J. Wysocki [EMAIL PROTECTED]
The cpuid driver should not attempt to destroy/create a suspended
device.
Signed-off-by: Rafael J. Wysocki [EMAIL PROTECTED]
ACK.
--
(english) http://www.livejournal.com/~pavelmachek
(cesky,
On Mon 2007-12-17 00:30:22, Rafael J. Wysocki wrote:
From: Borislav Petkov [EMAIL PROTECTED]
There's a freakishly long comment in suspend_64.c, shorten it.
Signed-off-by: Borislav Petkov [EMAIL PROTECTED]
Cc: Pavel Machek [EMAIL PROTECTED]
Signed-off-by: Rafael J. Wysocki [EMAIL PROTECTED
On Mon 2007-12-17 00:30:29, Rafael J. Wysocki wrote:
From: Johannes Berg [EMAIL PROTECTED]
This patch makes the freezer optional for suspend to allow the
system to work (or not work) like the original PMU suspend.
Signed-off-by: Johannes Berg [EMAIL PROTECTED]
Cc: Pavel Machek [EMAIL
Hi!
It is not known whether Mark is actually writing to this
thing. Perhaps
read-only permissions would be a suitable fix?
Exporting it as read only should be OK. We also need to know if there
are hard user space dependency on writing to this from userspace.
Some people are
Hi!
It works. Subjectively I have relatively long pause after first
Suspending console
message (where it hangs otherwise), according to dmesg timestamp it is
about
1 second before next messages appear. Also last two times I tried it
writeout
of suspend image was
Hi!
yes, acpidump would be more useful than just the DSDT --
as we get all kinds of issues with all the tables.
One problem is that shipping around BIOS images, particularly
modified ones, is sort of a touchy area. This is the code
of the manufacturer, who may or may not be happy
Hi!
When compared with 2.6.22-4, dmesg no longer lists S4 and S5 as supported
for my Toshiba Satellite A40 laptop (Mobile Intel Pentium 4, 2.8GHz).
-Linux version 2.6.22-2-686 (Debian 2.6.22-4) ([EMAIL PROTECTED]) ...
+Linux version 2.6.23-rc6 ([EMAIL PROTECTED]) ...
[...]
+ACPI: EC:
On Sun 2007-09-02 00:21:37, Rafael J. Wysocki wrote:
From: Rafael J. Wysocki [EMAIL PROTECTED]
The following scenario leads to total confusion of the platform firmware on
some boxes (eg. HPC nx6325):
* Hibernate with ACPI enabled
* Pass acpi=off to the boot kernel
To prevent this from
On Mon 2007-08-27 01:54:16, Rafael J. Wysocki wrote:
From: Rafael J. Wysocki [EMAIL PROTECTED]
According to the ACPI specification (eg. ACPI 2.0c, sec. 7.3.1, 7.3.3,
ACPI 3.0b, sec. 7.3.1, 7.3.3) the _GTS and _BFS global control methods should
be executed, respectively, right before entering
Hi!
Make hibernation_platform_enter() execute the enter-a-sleep-state sequence
instead of the mixed shutdown-with-entering-S4 thing.
Replace the shutting down of devices done by kernel_shutdown_prepare(), before
entering the ACPI S4 sleep state, with suspending them and the shutting down
Hi!
Introduce a separate ACPI function for setting the system status indicator and
use it in the right places in the suspend and hibernation related ACPI
callbacks
instead of setting the system status indicator implicitly in
acpi_enter_sleep_state_prep() and acpi_leave_sleep_state().
Hi!
Make hibernation_platform_enter() execute the enter-a-sleep-state sequence
instead of the mixed shutdown-with-entering-S4 thing.
Replace the shutting down of devices done by kernel_shutdown_prepare(),
before
entering the ACPI S4 sleep state, with suspending them and the
...AFAICT noone calls it, and I guess that may be why we are seeing
some lid open sometimes wake up x60, sometimes does not fun?
[EMAIL PROTECTED]:/data/l/linux/drivers/acpi$ grep -ri acpi_gpe_sleep_prepare
.
./sleep/wakeup.c:void acpi_gpe_sleep_prepare(u32 sleep_state)
./sleep/sleep.h:extern
Trip points are now read-only, mark them as such.
Signed-off-by: Pavel Machek [EMAIL PROTECTED]
---
commit 7359586e3cf03be9370a495a03044677c9594ccd
tree 5d14686cdec78dc9d22be512d71f19247cf2e82f
parent cd48bb0ae3cd70fff68a09b80b3744e5f92cff86
author Pavel [EMAIL PROTECTED] Fri, 24 Aug 2007 11:44
On Wed 2007-08-22 11:56:35, Rafael J. Wysocki wrote:
From: Rafael J. Wysocki [EMAIL PROTECTED]
Remove some redundant code from acpi_enter_sleep_state_prep() and clean up
a comment in there.
Signed-off-by: Rafael J. Wysocki [EMAIL PROTECTED]
ACK.
On Fri 2007-08-24 11:51:37, Pavel Machek wrote:
...AFAICT noone calls it, and I guess that may be why we are seeing
some lid open sometimes wake up x60, sometimes does not fun?
[EMAIL PROTECTED]:/data/l/linux/drivers/acpi$ grep -ri acpi_gpe_sleep_prepare
.
./sleep/wakeup.c:void
Hi!
pnpacpi_suspend() doesn't check the result returned by
acpi_pm_device_sleep_state() before passing it to acpi_bus_set_power(), which
may not be desirable. Make it select the target power state of the device
using its second argument if acpi_pm_device_sleep_state() fails.
Hi!
Oh... crap, so acpi wants to sync cache on shutdown. I wonder whether
it spins down the disk correctly. Does emergency unload count increase
after each power down? Also, please post the result of 'dmidecode'.
I know that my Compaq X1000-series laptop does do some kind of ACPI
Hi!
firmwarekit-discuss [EMAIL PROTECTED] (added to CC list)
see: http://linuxfirmwarekit.org/
But if I understand this problem right, this won't be easy.
The ACPI tables are just parsed with system (iasl ...) and syntactical
errors/warnings are printed out.
I also thought about a
Hi!
Without this change, it is possible to build CONFIG_HIBERNATE
on all !SMP architectures, but not necessarily their SMP versions.
Did you want to say CONFIG_SUSPEND?
I don't know for sure if the architecture list under SUSPEND_UP_POSSIBLE
is correct. For now it simply matches the list
Hi!
Wait, doesn't HOTPLUG_CPU also depend on EXPERIMENTAL?
Damn, I started thinking about it, and then forgot about it when
finishing the patch.
My thoughts were:
Is HOTPLUG_CPU still an experimental feature, or has it become a
well-tested no longer experimental feature now that it's
On Tue 2007-07-17 08:08:24, Aaron Durbin wrote:
On 7/17/07, Andi Kleen [EMAIL PROTECTED] wrote:
On Monday 16 July 2007 20:00:19 Aaron Durbin wrote:
Add the ability to reset the machine using the
RESET_REG in ACPI's FADT table.
Why? I had such a patch at some point as experiment,
but
On Thu 2007-06-14 20:13:29, Norbert Preining wrote:
Hi all!
On Die, 12 Jun 2007, Pavel Machek wrote:
When I resume, everything seems to come up (fan becomes busy, disk and
dvd spin up for a short time), but the machine is not responding to
anything - neither keyboard, mouse nor ping
Hi!
This series of patches implements changes that are
possible/necessary/desirable
(IMO) after the introduction of the .set_target() method in 'struct pm_ops'
(the patch that introduces it is in -mm,
http://marc.info/?l=linux-mm-commitsm=118306698814722w=2).
(I think this series is
Hi!
Since we are now explicitly calling hibernation_ops-prepare() before
hibernation_ops-enter() in hibernation_platform_enter() (defined in
kernel/power/disk.c), ACPI should not call acpi_sleep_prepare(ACPI_STATE_S4)
from acpi_shutdown().
Signed-off-by: Rafael J. Wysocki [EMAIL PROTECTED]
On Sun 2007-07-01 20:54:31, Rafael J. Wysocki wrote:
From: Rafael J. Wysocki [EMAIL PROTECTED]
Introduce the pm_power_off_prepare() callback that can be registered by the
interested platforms in analogy with pm_idle() and pm_power_off(), used for
preparing the system to power off (needed by
Hi!
Introduce the pm_power_off_prepare() callback that can be registered by
the
interested platforms in analogy with pm_idle() and pm_power_off(), used
for
preparing the system to power off (needed by ACPI).
This allows us to drop acpi_sysclass and device_acpi that are
On Sat 2007-06-30 23:01:55, Rafael J. Wysocki wrote:
[Previous version of this was acked by Pavel, but I've updated it since then.]
---
From: Rafael J. Wysocki [EMAIL PROTECTED]
Move the definition of 'struct pm_ops' and related functions from linux/pm.h
to linux/suspend.h .
There are,
Hi!
From: Rafael J. Wysocki [EMAIL PROTECTED]
The variable suspend_ops representing the set of global platform-specific
suspend-related operations, used by the PM core, need not be exported outside
of
kernel/power/main.c . Make it static.
Signed-off-by: Rafael J. Wysocki [EMAIL
On Sat 2007-06-30 23:03:57, Rafael J. Wysocki wrote:
[Previous version of this was acked by Pavel, but I've updated it since then.]
---
From: Rafael J. Wysocki [EMAIL PROTECTED]
The name of 'struct pm_ops' suggests that it is related to the power
management
in general, but in fact it is
On Sat 2007-06-30 23:11:58, Rafael J. Wysocki wrote:
From: Rafael J. Wysocki [EMAIL PROTECTED]
Rename 'struct hibernation_ops' to 'struct platform_hibernation_ops' in
analogy
with 'struct platform_suspend_ops'.
Signed-off-by: Rafael J. Wysocki [EMAIL PROTECTED]
ACK.
--
(english)
Hi!
The results are a bit unclear, I took a 2.6.22-rc4 with beep.
Logged into KDE.
(hardware: Dell Latitude D810)
S = successfull resume
D = had to resume 2 times, that means when pressing the power button the
LED goes from blinking to on and after a few seconds it goes back to
Hi!
There is no reason why the .prepare() and .finish() methods in 'struct
platform_suspend_operations' should take any arguments, since architectures
don't use these methods' argument in any practically meaningful way (ie.
either
the target system sleep state is conveyed to the platform by
On Mon 2007-06-25 23:28:06, Johannes Berg wrote:
On Sun, 2007-06-24 at 22:40 +0200, Rafael J. Wysocki wrote:
+ * @set_target: Tell the platform which system sleep state is going to be
+ * entered. The information passed to @set_target should be disregarded
+ * by the platform as soon as
Hi!
Right now the states we have are On, Standby, and Suspend, and the CPU
runs only in the On state. But on some platforms there could be
multiple states in which the CPU is able to run, albeit with degraded
performance.
I wouldn't call those system sleep states. For example, ACPI
Hi!
Right now the states we have are On, Standby, and Suspend, and the CPU
runs only in the On state. But on some platforms there could be
multiple states in which the CPU is able to run, albeit with degraded
performance.
I wouldn't call those system sleep states. For example, ACPI
On Sun 2007-06-24 22:41:38, Rafael J. Wysocki wrote:
From: Rafael J. Wysocki [EMAIL PROTECTED]
Move the definition of 'struct pm_ops' and related functions from linux/pm.h
to linux/suspend.h .
There are, at least, the following reasons to do that:
* 'struct pm_ops' is specifically related
On Sun 2007-06-24 22:42:46, Rafael J. Wysocki wrote:
From: Rafael J. Wysocki [EMAIL PROTECTED]
The name of 'struct pm_ops' suggests that it is related to the power
management
in general, but in fact it is only related to suspend. Moreover, its name
should indicate what this structure is
Hi!
IMO it can be done in two different ways:
1) via a .suspend() argument
2) via a global variable that the drivers can read.
For sufficiently small values of two that is.
Other solutions that have been described on the PM list include
3) Providing accessors to the
Hi!
Documentation changes based on Pavel's feedback.
Thanks!
-System global cpuidle information are under
+System global cpuidle related information and tunables are under
/sys/devices/system/cpu/cpuidle
The current interfaces in this directory has self-explanatory names:
+*
Hi!
resume from suspend to ram doesn't work for my laptop and never
has. So, this is not a regression.
[...]
Beeping patch? It is in -mm now. noapic nolapic and nosmp are useful,
too.
With the proprietary nvidia module, the laptop resumes, but the screen
stays black. Meanwhile I
Hi!
resume from suspend to ram doesn't work for my laptop and never
has. So, this is not a regression.
Hibernate (aka suspend to disk) works, however.
When I resume, everything seems to come up (fan becomes busy, disk and
dvd spin up for a short time), but the machine is not responding
Hi!
Any reason to not just replace ACPI_RSD_TABLE_SIZE with ARRAY_SIZE?
Probably because ARRAY_SIZE doesn't exist in ACPICA, which is
where this code comes from...
When we change syntax in ACPICA files in Linux to make it more beautiful,
then it creates more work for me -- as
Hi!
(This should efficiently be the same as the proposed big patch a year
ago from Pekka Enberg, just a bit smaller and should make ACPICA and
kernel/linux people happy:
http://marc.info/?l=linux-kernelm=113699535303722w=2)
No, you're keeping these obfuscating macros around:
Hi!
Second, you can use PM_TRACE (Documentation/power/s2ram.txt) to find the
place where it really fails.
First I augmented my minimal config kernel with some TRACE_RESUME()s:
--- a/kernel/power/main.c 2007-05-27 23:48:05.0 +0200
+++ b/kernel/power/main.c 2007-06-03
On Thu 2007-06-07 21:54:51, Olaf Dietsche wrote:
Pavel Machek [EMAIL PROTECTED] writes:
But either way the script never reaches shutdown -rn now. So, it
seems, that my laptop does a full resume every other reboot, but it
never returns to userspace.
But it returns to kernel... can you
Hi!
According to the SYSTEM V APPLICATION BINARY INTERFACE,
Intel386 Architecture:
ecx and edx: Scratch registers have no specified role in the standard calling
sequence. Functions do not have to preserve their values for the
caller.
Thanks for confirming.
On Mon 2007-06-04 11:02:01, Stefan Seyfried wrote:
On Thu, May 17, 2007 at 06:35:48PM -0400, Len Brown wrote:
Yes, SuSE enables polling mode by default, but that is just
distro specific value add that should eventually be fixed.
I will do that for openSUSE FACTORY.
Well, I still
On Thu 2007-05-31 22:46:11, Len Brown wrote:
On Monday 21 May 2007 08:11, Pavel Machek wrote:
On Thu 2007-05-17 18:42:43, Len Brown wrote:
Something similar happened to me on XE3, yes.
(Actual values were different; BIOS specified critical temperature at
cca 95C, but hw killed
Hi!
From: Tian Kevin [EMAIL PROTECTED]
Register %ebx serves as the global offset table base register
for position-independent code. For absolute code, %ebx serves
as a local register and has no specified role in the function
calling sequence. In either case, a function must preserve the
Hi!
Because, as Len has pointed out, you end up with two different ideas
about what the trip points are - the kernel's and the hardware's. That
works fine until some event in the firmware either forcibly
resynchronises the two or makes assumptions about the spec-compliance of
Hi!
I doubt it is impossible, would you mind sharing your knowledge why you
think it is impossible or point to some related discussion, pls.
Because, as Len has pointed out, you end up with two different ideas
about what the trip points are - the kernel's and the hardware's. That
Hi!
I shouldn't have to upgrade my BIOS to work with a new kernel any more
than I should have to upgrade my browser.
We don't agree there, as you are not talking about a stable kernel series.
Ah, so you're planning on submitting these patches for 2.7 then? 2.6
is perpetually
Hi!
So don't do it badly. The advantage of doing so is that you can make it
work properly, which you can't by putting it in the kernel.
You want stuff like critical shutdowns to work even if userspace is
dead.
I don't think anyone suggested putting the critical shutdown control
Hi!
No, writing trip-points is neither a fix, nor it is reasonable.
It is a workaround at best, and it is a dangerous and mis-leading hack.
Yes it is a workaround for critical ACPI bugs like that or similar:
https://bugs.launchpad.net/ubuntu/+source/linux-source-2.6.17/+bug/22336
On Thu 2007-05-17 18:42:43, Len Brown wrote:
Something similar happened to me on XE3, yes.
(Actual values were different; BIOS specified critical temperature at
cca 95C, but hw killed the power at cca 83C. Setting critical trip
point at 80C made the problem go away.)
Great, please
Hi!
For folks with the reverse problem -- active cooling where the
fans kick in early than they'd like, they should just turn off
the fans via /proc/acpi/fan and not mess with the trip points at
all.
No. Manually turning off fans is even worse hack.
It's significantly more
On Mon 2007-05-21 14:36:08, Matthew Garrett wrote:
On Mon, May 21, 2007 at 03:29:48PM +0200, Pavel Machek wrote:
No. Manually turning off fans is even worse hack.
It's significantly more correct.
Significantly more correct? It forces you to do all the thermal
management
Hi!
From: Rafael J. Wysocki [EMAIL PROTECTED]
Change the code ordering so that hibernation_ops-prepare() is called after
device_suspend(). This is needed so that we don't violate the ACPI
specification, which states that the _PTS and _GTS system-control methods,
executed from
Hi!
From: Rafael J. Wysocki [EMAIL PROTECTED]
At least on some machines it is necessary to prepare the ACPI firmware for the
restoration of the system memory state from the hibernation image if the
platform mode of hibernation has been used. Namely, in that cases we need
to
disable the
Hi!
From: Rafael J. Wysocki [EMAIL PROTECTED]
Currently, much of the code in kernel/power/disk.c is duplicated in
kernel/power/user.c , mainly for historical reasons. By eliminating this code
duplication we can reduce the size of user.c quite substantially and remove
the
maintenance
On Fri 2007-05-18 00:21:21, Rafael J. Wysocki wrote:
From: Rafael J. Wysocki [EMAIL PROTECTED]
Make the code hibernation code in kernel/power/user.c be functionally
equivalent
to the corresponding code in kernel/power/disk.c , as it should be.
The calls to the platform functions removed
Hi!
In 2.6.20.9 I can change trippoints:
echo 105:100:100:78:70:40:30 /proc/acpi/thermal_zone/TZ0/trip_points
echo 10 /proc/acpi/thermal_zone/TZ0/polling_frequency
Then I got:
cat /proc/acpi/thermal_zone/TZ0/*
...
Its bug or feature?
Committed to mainline May 10:
Hi!
ACPI: thermal trip points are read-only
What was the rationale? Can we get this one reverted?
Some machines (HP omnibook xe3) have broken trip points -- too high --
so machine will overheat and trigger hw shutdown before starting
passive cooling.
That's really
On Thu 2007-05-17 15:08:39, Len Brown wrote:
On Thursday 17 May 2007 09:36, Maciej Rutecki wrote:
Many people need change trippoints, for example I have:
cat /proc/acpi/thermal_zone/TZ0/trip_points | grep critical
critical (S5): 256 C
I _must_ change it to below 105 C,
Hi!
It's peculiar that the hang happens when acpi_evaluate_object() hits its
return statement. Any theories there?
Only stack or memory corruption come into mind, but I have no clue how
this is related to the resume logic changes.
So I had the brilliant idea of turning on some
Hi!
Provide new ACPI method tracking the target system state, for use
during suspend() and other PM calls. It returns ACPI_STATE_S0
except during true suspend paths.
Use that to finally implement the platform_pci_choose_state() hook
on ACPI platforms. It calls _S3D and similar methods,
Hi!
Just to clarify, the change in question isn't new. It was introduced by the
commit 9185cfa92507d07ac787bc73d06c4eec7239 before 2.6.20, at Seife's
request and with Pavel's acceptance.
Ok, if it's that old, we migt as leave it in. Clearly there weren't many
regressions, and this
On Thu 2007-05-03 11:46:02, Rafael J. Wysocki wrote:
On Thursday, 3 May 2007 10:41, Johannes Berg wrote:
On Wed, 2007-05-02 at 22:13 +0200, Rafael J. Wysocki wrote:
+void hibernation_set_ops(struct hibernation_ops *ops)
+{
+ if (ops !(ops-prepare ops-enter ops-finish)) {
+
Hi!
I've got two questions regarding the implementation of the ACPI poweroff/sleep
code in drivers/acpi/sleep and drivers/acpi/hardware .
1) We don't seem to use the _TTS system-control method, although the ACPI
specification (ACPI 3.0b) says that this method should be used for intiating
Hi!
Crazy idea... could we kill hibernate_ops-like struct, and just create
a device for ACPI, using its suspend()/resume()/whatever callbacks to
do the ACPI magic?
Okay. Since we're trying to separate the hibernation code from the
suspend code anyway, we can use the opportunity to introduce
Hi!
Especially the PCI video_state trick finally got me a working resume
on
2.6.19-ck2 r128 Rage Mobility M4 AGP *WITH*(!) fully enabled and
working
(and keeping working!) DRI (3D).
Can we get whitelist entry for suspend.sf.net? s2ram from there can do
all
Hi!
static inline int device_suspend(pm_message_t state)
--- g26.orig/drivers/base/power/main.c2007-04-04 13:03:33.0
-0700
+++ g26/drivers/base/power/main.c 2007-04-04 13:03:34.0 -0700
@@ -29,6 +29,9 @@ LIST_HEAD(dpm_off_irq);
DECLARE_MUTEX(dpm_sem);
1 - 100 of 236 matches
Mail list logo
