Hi Ron,
Throttling is meant as a last line of defense before powering-off
machine, and not a thermal regulation feature.
Please check if you have cpufreq compiled in and able to change frequency.
Please open a bug report at bugzilla.kernel.org against ACPI/Thermal.
Please attach dmesg output
On Wed, 20 Feb 2008 08:21:33 +0100 Thomas Petazzoni [EMAIL PROTECTED] wrote:
Le Tue, 19 Feb 2008 15:21:29 -0800,
Andrew Morton [EMAIL PROTECTED] a __crit :
ug, sorry, if I'd realised it was like this I'd have said don't
bother. Apart from the obvious problem, this means that people will
Thomas Renninger wrote:
Hi,
please correct me if I am wrong or missed something:
osi=linux was an ability for vendors to provide Linux specific BIOS
updates/quirks.
_OSI(Linux) returned true until kernel version 2.6.23 (included?).
This has been replaced by rather huge black+white lists (at
Hi,
JFYI:
Due to a silly BIOS bug which seems to get copied to a wider range of
Asus (and friends) machines/mainboards following machines/mainboards
will show a protection fault when the thermal ACPI driver gets loaded:
Biostar TA770 ( Bios A78XA125 2008-01-28 )
Foxconn M520A ( Bios 784F1P05
On Wed, 20 Feb 2008, Tomas Carnecky wrote:
A lot has been discussed in linux-acpi, though mostly hidden in related
threads. Ask Henrique, he's been trying to come up with a proper _OSI()
interface. See for example this thread:
No, I haven't. Len is the mastermind behind it, AFAIK. I am
On Wed, 2008-02-20 at 11:31 +0100, Tomas Carnecky wrote:
Thomas Renninger wrote:
Hi,
please correct me if I am wrong or missed something:
osi=linux was an ability for vendors to provide Linux specific BIOS
updates/quirks.
_OSI(Linux) returned true until kernel version 2.6.23
On Wed, 20 Feb 2008, Rafael J. Wysocki wrote:
Hi Greg,
Please consider taking the following fix for 2.6.25.
Don't just consider it! :-) It's a real bug fix.
Thanks,
Rafael
---
From: Rafael J. Wysocki [EMAIL PROTECTED]
Remove an unnecessary unlocking of dpm_list_mtx in the error
On Feb 21, 2008 1:28 AM, Linus Torvalds [EMAIL PROTECTED] wrote:
Try suspend-and-resume without X.
Works without those two functions.
Also, try it on one of the more modern laptops - even *with* X.
Again, still works. Tested on Lenovo X60s.
Basically, the kernel wants to be able to do what
On Feb 21, 2008 1:17 AM, Jeff Chua [EMAIL PROTECTED] wrote:
On Feb 20, 2008 2:19 PM, Jeff Chua
I'll try the idle=poll to see if that works and will try some printk
Tried idle=poll but it has not effect.
Thanks,
Jeff.
-
To unsubscribe from this list: send the line unsubscribe linux-acpi in
On Feb 20, 2008 2:19 PM, Jeff Chua
I'll try the idle=poll to see if that works and will try some printk
I don't know what exactly the i915_suspend() and i915_resume() are
supposed to do because it works better without them.
After inserting return 0; right at the top of those two
On Thu, 21 Feb 2008, Jeff Chua wrote:
After inserting return 0; right at the top of those two functions, suspend
(and power-off properly), and resume (without green screen) works just fine.
I would like to know what they're for.
Try suspend-and-resume without X.
Also, try it on one of
On Thu, 21 Feb 2008, Jeff Chua wrote:
Works without those two functions.
Ahh. You're using the BIOS to re-initialize your video, aren't you?
If STR works without X, then you have something else resuming graphics,
and that may be what then interacts badly with the fact that the kernel
On Feb 21, 2008 1:52 AM, Linus Torvalds [EMAIL PROTECTED] wrote:
Ahh. You're using the BIOS to re-initialize your video, aren't you?
I don't know. Just pure simple s2ram without any options.
Let's try to narrow it down to what the interaction is. Are you using
something like
On Feb 21, 2008 1:28 AM, Linus Torvalds [EMAIL PROTECTED] wrote:
That said, before you do anything else, try if suspend-to-RAM works.
Linus, guess I missed this part ... so before touch anything, I did
tried suspend-to-ram, and it works on console and in X.
And suspend-to-disk hangs, but I can
On Wednesday, February 20, 2008 9:17 am Jeff Chua wrote:
On Feb 20, 2008 2:19 PM, Jeff Chua
I'll try the idle=poll to see if that works and will try some printk
I don't know what exactly the i915_suspend() and i915_resume() are
supposed to do because it works better without them.
After
Jeff Chua wrote:
On Feb 20, 2008 2:19 PM, Jeff Chua
I'll try the idle=poll to see if that works and will try some printk
I don't know what exactly the i915_suspend() and i915_resume() are
supposed to do because it works better without them.
After inserting return 0; right at the top of
On Wed, 20 Feb 2008, Matthew Garrett wrote:
Let's look at this differently. Most hardware is produced by vendors who
don't care about Linux. We need to make that hardware work anyway. The
only way we can achieve that is to be bug-compatible with Windows.
Therefore, any way in which Linux
On Wed, 2008-02-20 at 17:32 +, Matthew Garrett wrote:
Let's look at this differently. Most hardware is produced by vendors who
don't care about Linux. We need to make that hardware work anyway.
Not really. If you buy machine noname XY, you have to face the fact that
HW may not work on Linux
On Thu, 21 Feb 2008, Jeff Chua wrote:
That said, before you do anything else, try if suspend-to-RAM works.
Linus, guess I missed this part ... so before touch anything, I did
tried suspend-to-ram, and it works on console and in X.
Ok, so this is with clean current -git, and nothing
On Wed, Feb 20, 2008 at 07:21:57PM +0100, Thomas Renninger wrote:
On Wed, 2008-02-20 at 17:32 +, Matthew Garrett wrote:
Let's look at this differently. Most hardware is produced by vendors who
don't care about Linux. We need to make that hardware work anyway.
Not really. If you buy
On Feb 21, 2008 1:50 AM, Jesse Barnes [EMAIL PROTECTED] wrote:
I would like to know what they're for.
They're for saving and restoring GPU state across suspend/resume. They're
particularly useful if your machine doesn't re-POST at resume time. In that
case your GPU may be totally
On Wednesday, February 20, 2008 10:29 am Jeff Chua wrote:
I know I fixed that problem in at least one configuration... Can you
try: # echo test /sys/power/disk
# echo disk /sys/power/state
and see if that also turns your screen green?
Yes, still green. But I got it to actual reboot
On Feb 21, 2008 2:53 AM, Jesse Barnes [EMAIL PROTECTED] wrote:
So, next I'll try shutdown to see if it work. I was using platform.
Ok, that would be good to try.
shutdown does power down properly. But still green on resume.
Looks like the AR registers are hosed, which is what I thought I
On Wed, Feb 20, 2008 at 03:23:40PM -0300, Henrique de Moraes Holschuh wrote:
On Wed, 20 Feb 2008, Matthew Garrett wrote:
Let's look at this differently. Most hardware is produced by vendors who
don't care about Linux. We need to make that hardware work anyway. The
only way we can achieve
On Wednesday, February 20, 2008 11:10 am Jeff Chua wrote:
On Feb 21, 2008 2:53 AM, Jesse Barnes [EMAIL PROTECTED] wrote:
So, next I'll try shutdown to see if it work. I was using platform.
Ok, that would be good to try.
shutdown does power down properly. But still green on resume.
Ok,
On Wednesday, February 20, 2008 11:18 am Jesse Barnes wrote:
On Wednesday, February 20, 2008 11:10 am Jeff Chua wrote:
On Feb 21, 2008 2:53 AM, Jesse Barnes [EMAIL PROTECTED] wrote:
So, next I'll try shutdown to see if it work. I was using
platform.
Ok, that would be good to try.
On Wednesday, 20 of February 2008, Jesse Barnes wrote:
On Wednesday, February 20, 2008 11:18 am Jesse Barnes wrote:
On Wednesday, February 20, 2008 11:10 am Jeff Chua wrote:
On Feb 21, 2008 2:53 AM, Jesse Barnes [EMAIL PROTECTED] wrote:
So, next I'll try shutdown to see if it work. I
Hi,
I have a Dell D830 (has module bay). I've tried searching the web for
the answer to should I, with 2.6.24.2 (and latest Dell BIOS) be able to
remove the cdrom bay drive and continue to suspend/resume. I kind of
don't think I should be able to yet, but I thought I'd ask here.
So:
How do
On Wed, 20 Feb 2008, Rafael J. Wysocki wrote:
I think we should export the target sleep state somehow.
Yeah. By *not* using -suspend() for freezing or hibernate.
Please, Rafael - just make the f*cking suspend-to-disk use other routines
already. 99% of all hardware needs to do exactly
On Wednesday, February 20, 2008 12:29 pm Linus Torvalds wrote:
On Wed, 20 Feb 2008, Rafael J. Wysocki wrote:
I think we should export the target sleep state somehow.
Yeah. By *not* using -suspend() for freezing or hibernate.
Please, Rafael - just make the f*cking suspend-to-disk use other
On Wednesday 20 February 2008 at 3:29 pm, Linus Torvalds penned
about Re: [Suspend-devel] 2.6.25-rc2 System no longer powers off after
suspend-to-disk. Screen becomes green.
Can we please get this fixed some day?
I can't say I even come close to understand what's going on but
getting s2ram to
On Wed, 20 Feb 2008, Jesse Barnes wrote:
The current callback system looks like this (according to Rafael and the last
time I looked):
-suspend(PMSG_FREEZE)
-resume()
-suspend(PMSG_SUSPEND)
*enter S3 or power off*
-resume()
Yes, it's very messy.
It's messy for a few
I have here an Intel Classmate hardware sample, and I have a weird problem
with suspend to ram, the machine does a power off when resuming.
I isolated the problem to the button acpi module, without loading it (or just
removing it before doing a s2ram) I don't get the problem. In the specific
On Wednesday, February 20, 2008 11:10 am Jeff Chua wrote:
On Feb 21, 2008 2:53 AM, Jesse Barnes [EMAIL PROTECTED] wrote:
So, next I'll try shutdown to see if it work. I was using platform.
Ok, that would be good to try.
shutdown does power down properly. But still green on resume.
On Wednesday, February 20, 2008 1:13 pm Linus Torvalds wrote:
On Wed, 20 Feb 2008, Jesse Barnes wrote:
The current callback system looks like this (according to Rafael and the
last time I looked):
-suspend(PMSG_FREEZE)
-resume()
-suspend(PMSG_SUSPEND)
*enter S3 or power off*
Rafael J. Wysocki wrote:
On Wednesday, 20 of February 2008, Linus Torvalds wrote:
On Wed, 20 Feb 2008, Rafael J. Wysocki wrote:
I think we should export the target sleep state somehow.
Yeah. By *not* using -suspend() for freezing or hibernate.
Please, Rafael - just make the
This is a note to let you know that I've just added the patch titled
Subject: PM: Remove unbalanced mutex_unlock() from dpm_resume()
to my gregkh-2.6 tree. Its filename is
pm-remove-unbalanced-mutex_unlock-from-dpm_resume.patch
This tree can be found at
On Wed, 20 Feb 2008, Jesse Barnes wrote:
Really, in the simple s3 case we still need early/late stuff?
Absolutely.
Two big reasons:
- debuggability
I know we don't do this correctly right now, but I want to be able to
at least feel like we can some day actually do printk's etc
On Wednesday, 20 of February 2008, Jesse Barnes wrote:
On Wednesday, February 20, 2008 1:13 pm Linus Torvalds wrote:
On Wed, 20 Feb 2008, Jesse Barnes wrote:
The current callback system looks like this (according to Rafael and the
last time I looked):
-suspend(PMSG_FREEZE)
On Wednesday, February 20, 2008 11:10 am Jeff Chua wrote:
On Feb 21, 2008 2:53 AM, Jesse Barnes [EMAIL PROTECTED] wrote:
So, next I'll try shutdown to see if it work. I was using platform.
Ok, that would be good to try.
shutdown does power down properly. But still green on resume.
Hi.
Jesse Barnes wrote:
Well, it seems like we'll have to fix drivers in either case, and isn't a
kexec approach fundamentally more sound and simple, design-wise? Rafael
pointed out some problems with properly setting wakeup states, but I think
that could be overcome...
No. AFAICS, kexec
On Wednesday, February 20, 2008 2:32 pm Jesse Barnes wrote:
On Wednesday, February 20, 2008 11:10 am Jeff Chua wrote:
On Feb 21, 2008 2:53 AM, Jesse Barnes [EMAIL PROTECTED] wrote:
So, next I'll try shutdown to see if it work. I was using
platform.
Ok, that would be good to try.
On Wed, 20 Feb 2008, Rafael J. Wysocki wrote:
which may have four entry-points that can be illogically mapped to the
suspend/resume ones like we do now, but they really have nothing to do
with suspending/resuming.
Apart from putting devices into the right low power states, that
Initializing cgroup subsys cpuset
Linux version 2.6.24-1-amd64 (Debian 2.6.24-4~mtu1) ([EMAIL PROTECTED])
(gcc version 4.1.2 20061115 (prerelease) (D
ebian 4.1.1-21)) #1 SMP Fri Feb 15 11:09:50 JST 2008
Command line: root=/dev/md0 ro
BIOS-provided physical RAM map:
BIOS-e820: -
On Thursday, 21 of February 2008, Linus Torvalds wrote:
On Wed, 20 Feb 2008, Rafael J. Wysocki wrote:
which may have four entry-points that can be illogically mapped to the
suspend/resume ones like we do now, but they really have nothing to do
with suspending/resuming.
On Wednesday, February 20, 2008 3:03 pm Jesse Barnes wrote:
On Wednesday, February 20, 2008 2:32 pm Jesse Barnes wrote:
On Wednesday, February 20, 2008 11:10 am Jeff Chua wrote:
On Feb 21, 2008 2:53 AM, Jesse Barnes [EMAIL PROTECTED] wrote:
So, next I'll try shutdown to see if it work.
On Thu, 21 Feb 2008, Rafael J. Wysocki wrote:
In fact we have acpi_pci_choose_state() that tells the driver which power
state to put the device into in -suspend(). If that is used, the device ends
up in the state expected by to BIOS for S4.
First off, nobody should *ever* use that
On Thu, Feb 21, 2008 at 09:45:02AM +1100, Nigel Cunningham wrote:
- people keep talking about hibernating to an ext3 fs mounted on fuse as
a limitation of the freezer. To do that with kexec, you're still going
to have to bmap the ext3 fs and pass the block list (in which case we
can also
On Thursday, 21 of February 2008, Linus Torvalds wrote:
On Thu, 21 Feb 2008, Rafael J. Wysocki wrote:
In fact we have acpi_pci_choose_state() that tells the driver which power
state to put the device into in -suspend(). If that is used, the device
ends
up in the state expected by
On Wednesday, February 20, 2008 3:49 pm Rafael J. Wysocki wrote:
And just to confirm that, I just tested the current DRM modules against a
2.6.23.15 kernel.
In 2.6.23.x there's no second -suspend() during hibernation, so no wonder.
In 2.6.23 it's just:
-suspend()
-resume()
*S4*
?
I
On Thu, 21 Feb 2008, Rafael J. Wysocki wrote:
Secondly, the one that people should use (pci_choose_state()) doesn't
actually do what you claim it does. It does all kinds of wrong things, and
doesn't even take the target state into account at all. So look again.
Well, if
On Thu, Feb 21, 2008 at 5:37 AM, Jesse Barnes [EMAIL PROTECTED] wrote:
Ok, can you give this patch a try with the 'platform' method? It should at
least tell us what ACPI would like the device to do at suspend time, but it
probably won't fix the hang.
I can't get it to compile.
Hi.
Matthew Garrett wrote:
On Thu, Feb 21, 2008 at 09:45:02AM +1100, Nigel Cunningham wrote:
- people keep talking about hibernating to an ext3 fs mounted on fuse as
a limitation of the freezer. To do that with kexec, you're still going
to have to bmap the ext3 fs and pass the block list (in
On Thu, Feb 21, 2008 at 11:40:06AM +1100, Nigel Cunningham wrote:
Hi.
Matthew Garrett wrote:
On Thu, Feb 21, 2008 at 09:45:02AM +1100, Nigel Cunningham wrote:
- people keep talking about hibernating to an ext3 fs mounted on fuse as
a limitation of the freezer. To do that with kexec, you're
On Wednesday, February 20, 2008 4:35 pm Jeff Chua wrote:
On Thu, Feb 21, 2008 at 5:37 AM, Jesse Barnes [EMAIL PROTECTED]
wrote:
Ok, can you give this patch a try with the 'platform' method? It should
at least tell us what ACPI would like the device to do at suspend time,
but it probably
On Thursday, 21 of February 2008, Linus Torvalds wrote:
On Thu, 21 Feb 2008, Rafael J. Wysocki wrote:
Secondly, the one that people should use (pci_choose_state()) doesn't
actually do what you claim it does. It does all kinds of wrong things,
and
doesn't even take the target
On Thursday, 21 of February 2008, Jesse Barnes wrote:
On Wednesday, February 20, 2008 3:49 pm Rafael J. Wysocki wrote:
And just to confirm that, I just tested the current DRM modules against a
2.6.23.15 kernel.
In 2.6.23.x there's no second -suspend() during hibernation, so no wonder.
On Thu, Feb 21, 2008 at 11:40:06AM +1100, Nigel Cunningham wrote:
Matthew Garrett wrote:
No, with a freezer-based model you can basically *never* suspend to
anything related to FUSE or a userspace USB device or anything involving
userspace iSCSI initiators or whatever. Sure, there are cases
Hi.
Greg KH wrote:
On Thu, Feb 21, 2008 at 11:40:06AM +1100, Nigel Cunningham wrote:
Hi.
Matthew Garrett wrote:
On Thu, Feb 21, 2008 at 09:45:02AM +1100, Nigel Cunningham wrote:
- people keep talking about hibernating to an ext3 fs mounted on fuse as
a limitation of the freezer. To do that
On Thu, Feb 21, 2008 at 8:39 AM, Jesse Barnes [EMAIL PROTECTED] wrote:
Oops, maybe this should just be pci_choose_state instead.
And this change should just be reverted (leave it as PCI_D0).
drivers/char/drm/i915_drv.c: In function 'i915_suspend':
drivers/char/drm/i915_drv.c:372: warning:
On Wednesday, February 20, 2008 5:19 pm Jeff Chua wrote:
On Thu, Feb 21, 2008 at 8:39 AM, Jesse Barnes [EMAIL PROTECTED]
wrote:
Oops, maybe this should just be pci_choose_state instead.
And this change should just be reverted (leave it as PCI_D0).
drivers/char/drm/i915_drv.c: In function
On Thu, Feb 21, 2008 at 9:21 AM, Jesse Barnes [EMAIL PROTECTED] wrote:
I hope those are just warning that can just be ignored.
Oops again, should be dev-pdev. Silly DRM layer obfuscation.
I was just about to write that the test didn't work. Both std str
hangs even before attempting to
Hi.
Matthew Garrett wrote:
On Thu, Feb 21, 2008 at 11:40:06AM +1100, Nigel Cunningham wrote:
Matthew Garrett wrote:
No, with a freezer-based model you can basically *never* suspend to
anything related to FUSE or a userspace USB device or anything involving
userspace iSCSI initiators or
On Thu, Feb 21, 2008 at 8:39 AM, Jesse Barnes [EMAIL PROTECTED] wrote:
On Wednesday, February 20, 2008 4:35 pm Jeff Chua wrote:
On Thu, Feb 21, 2008 at 5:37 AM, Jesse Barnes [EMAIL PROTECTED]
wrote:
Ok, can you give this patch a try with the 'platform' method? It should
at least
On Thu, Feb 21, 2008 at 12:17:06PM +1100, Nigel Cunningham wrote:
Hi.
Greg KH wrote:
On Thu, Feb 21, 2008 at 11:40:06AM +1100, Nigel Cunningham wrote:
Hi.
Matthew Garrett wrote:
On Thu, Feb 21, 2008 at 09:45:02AM +1100, Nigel Cunningham wrote:
- people keep talking about hibernating to an
On Thu, 2008-02-21 at 00:13 -0300, Henrique de Moraes Holschuh wrote:
On Wed, 20 Feb 2008, Matthew Garrett wrote:
It doesn't punish them. They're the ones who are going to work with us
to ensure that Linux works on their hardware, and their needs are going
And since when we have to work
Hi Greg.
Greg KH wrote:
On Thu, Feb 21, 2008 at 12:17:06PM +1100, Nigel Cunningham wrote:
Hi.
Greg KH wrote:
On Thu, Feb 21, 2008 at 11:40:06AM +1100, Nigel Cunningham wrote:
Hi.
Matthew Garrett wrote:
On Thu, Feb 21, 2008 at 09:45:02AM +1100, Nigel Cunningham wrote:
- people keep talking
On Thu, Feb 21, 2008 at 05:05:32PM +1100, Nigel Cunningham wrote:
Hi Greg.
Greg KH wrote:
On Thu, Feb 21, 2008 at 12:17:06PM +1100, Nigel Cunningham wrote:
Hi.
Greg KH wrote:
On Thu, Feb 21, 2008 at 11:40:06AM +1100, Nigel Cunningham wrote:
Hi.
Matthew Garrett wrote:
On Thu, Feb 21,
On Saturday 16 February 2008 14:47, Kamalesh Babulal wrote:
Hi Andrew,
The 2.6.25-rc2-mm1 kernel with randconfig build option, fails
to build on x86_64 machine
CC drivers/acpi/osl.o
drivers/acpi/osl.c:60:38: error: empty filename in #include
drivers/acpi/osl.c: In function
69 matches
Mail list logo
