Re: [2.6.25-rc1] System no longer powers off after shutdown
On Friday 15 February 2008, Greg KH wrote:
I swear someone sent this patch in before. Can you try this one below,
there seems to be an imbalance with kobject_get and _put.
I did remember seeing this patch before [1] and can confirm that it does
indeed fix the issue: with this patch applied to 2.6.25 git head my system
powers off correctly.
[1] See http://lkml.org/lkml/2008/2/8/342; also added to #9960.
---
drivers/cpufreq/cpufreq.c |8
1 file changed, 8 deletions(-)
--- a/drivers/cpufreq/cpufreq.c
+++ b/drivers/cpufreq/cpufreq.c
@@ -1006,14 +1006,6 @@ static int __cpufreq_remove_dev (struct
}
#endif
-
- if (!kobject_get(data-kobj)) {
- spin_unlock_irqrestore(cpufreq_driver_lock, flags);
- cpufreq_debug_enable_ratelimit();
- unlock_policy_rwsem_write(cpu);
- return -EFAULT;
- }
-
#ifdef CONFIG_SMP
#ifdef CONFIG_HOTPLUG_CPU
-
To unsubscribe from this list: send the line unsubscribe linux-acpi in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [2.6.25-rc1] System no longer powers off after shutdown
On Wednesday 13 February 2008, you wrote: On Tue, 12 Feb 2008 22:45:09 +0100 Frans Pop [EMAIL PROTECTED] wrote: Symptom is that the system shuts down normally and completely, it just does not power off. I've been struggling with an identically-manifesting regression on one of my test machines for a week. It's due to softlockup changes, and setting CONFIG_DETECT_SOFTLOCKUP=n fixes it. It sounds unlikely, but I'd suggest that you see if it's the same on your machine so we're not both chasing the same bug. Unsetting CONFIG_DETECT_SOFTLOCKUP does not help in my case, but thanks for the suggestion. - To unsubscribe from this list: send the line unsubscribe linux-acpi in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [2.6.25-rc1] System no longer powers off after shutdown
On Tuesday 12 February 2008, Greg KH wrote: On Tue, Feb 12, 2008 at 09:39:14PM +0100, Frans Pop wrote: On Monday 11 February 2008, Frans Pop wrote: In general 2.6.25 if looking quite good on my desktop, but there's one important issue: the system no longer powers off after shutdown. This works fine with 2.6.24. Don't ask me why, but bisection shows this commit to be the cause of the failure to power off: commit c10997f6575f476ff38442fa18fd4a0d80345f9d Author: Greg Kroah-Hartman [EMAIL PROTECTED] Date: Thu Dec 20 08:13:05 2007 -0800 Kobject: convert drivers/* from kobject_unregister() to kobject_put() Because it seemed somewhat unlikely, I have double checked this by doing an extra compilation for this commit and its predecessor. What is the symptom of not powering off? I already noticed yesterday that there's one hunk in that commit that's not a straight replacement: diff --git a/drivers/cpufreq/cpufreq.c b/drivers/cpufreq/cpufreq.c index 9e102af..5efd555 100644 --- a/drivers/cpufreq/cpufreq.c +++ b/drivers/cpufreq/cpufreq.c @@ -1030,8 +1030,6 @@ static int __cpufreq_remove_dev (struct sys_device * sys_dev) unlock_policy_rwsem_write(cpu); - kobject_unregister(data-kobj); - kobject_put(data-kobj); /* we need to make sure that the underlying kobj is actually So, just on the off chance, I applied the patch below and bingo, the system powers off again. I doubt this will be the correct solution, but just in case it is, here's my signed off. A comment why the double put is needed would probably be good though. Signed-off-by: Frans Pop [EMAIL PROTECTED] diff --git a/drivers/cpufreq/cpufreq.c b/drivers/cpufreq/cpufreq.c index 64926aa..9dbaac6 100644 --- a/drivers/cpufreq/cpufreq.c +++ b/drivers/cpufreq/cpufreq.c @@ -1058,6 +1058,7 @@ static int __cpufreq_remove_dev (struct sys_device * sys_dev) unlock_policy_rwsem_write(cpu); kobject_put(data-kobj); + kobject_put(data-kobj); /* we need to make sure that the underlying kobj is actually * not referenced anymore by anybody before we proceed with - To unsubscribe from this list: send the line unsubscribe linux-acpi in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [2.6.25-rc1] System no longer powers off after shutdown
On Wednesday 13 February 2008, Greg KH wrote: So, just on the off chance, I applied the patch below and bingo, the system powers off again. I doubt this will be the correct solution, but just in case it is, here's my signed off. A comment why the double put is needed would probably be good though. There is a bug in the cpufreq kref logic that makes this double put necessary. A real fix has already been posted to solve this issue, and I think it should be on it's way to Linus for -rc2 already. OK, great. Do you think that #6879 could be caused by a similar issue elsewhere in the tree? Can you give me some pointers on how I could find out (debugging to enable, instrumentation to add)? Please let me know if -rc2 comes out without this needed fix. Will do. - To unsubscribe from this list: send the line unsubscribe linux-acpi in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [2.6.25-rc1] System no longer powers off after shutdown
On Tuesday 12 February 2008, Greg KH wrote: On Tue, Feb 12, 2008 at 09:39:14PM +0100, Frans Pop wrote: On Monday 11 February 2008, Frans Pop wrote: In general 2.6.25 if looking quite good on my desktop, but there's one important issue: the system no longer powers off after shutdown. This works fine with 2.6.24. Don't ask me why, but bisection shows this commit to be the cause of the failure to power off: commit c10997f6575f476ff38442fa18fd4a0d80345f9d Author: Greg Kroah-Hartman [EMAIL PROTECTED] Date: Thu Dec 20 08:13:05 2007 -0800 Kobject: convert drivers/* from kobject_unregister() to kobject_put() Because it seemed somewhat unlikely, I have double checked this by doing an extra compilation for this commit and its predecessor. What is the symptom of not powering off? Symptom is that the system shuts down normally and completely, it just does not power off. Here are the last messages on the console: Will now halt. sd 1:0:0:0: [sdb] Synchronizing SCSI cache sd 1:0:0:0: [sdb] Stopping disk sd 0:0:0:0: [sda] Synchronizing SCSI cache sd 0:0:0:0: [sda] Stopping disk ACPI: PCI interrupt for device :01:00.0 disabled Disabling non-boot CPUs ... Can you press SysRq-T and see a task list running and waiting when things should be shut down? The system does not respond to that anymore. Do you happen to have a USB storage stick plugged into the system? Nothing. Only USB kbd/mouse. Note that I've had this issue before with this box: http://bugzilla.kernel.org/show_bug.cgi?id=6879 Somehow it disappeared when I pulled the extra video card that came with the system (no decent driver for it, so no loss). Since then the system has always powered off completely reliably. This time it is a clear and reproducible regression. If we can solve this one we might get a better handle on #6879 too. Cheers, FJP - To unsubscribe from this list: send the line unsubscribe linux-acpi in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: pnpacpi: exceeded the max number of IO resources: 24
(Mail below was sent to me privately, forwarding to the lists.) On Mon, 2008-01-07 at 00:48 +0100, Frans Pop wrote: (Adding the kernel list back. Any reason you did not send the reply there?) Sorry for the late reply: Christmas, New Year, the flue, etc. Thank you for caring this problem. On Friday 28 December 2007, Zhao Yakui wrote: On Mon, 2007-12-24 at 06:12 +0100, Frans Pop wrote: During boot with v2.6.24-rc6-125-g5356f66 on my Toshiba Satellite A40 laptop, I suddenly get the following message (repeated 22 times!): pnpacpi: exceeded the max number of IO resources: 24 Last time I tested 2.6.24 on that box was after the initial merge, but before -rc1. Then those lines were not present. Looks like the messages originate from a7839e96 by Zhao Yakui and that patch just adds the kernel messages so it was probably a hidden issue before, but I cannot determine if I should be worried or not. Thanks for caring this problem. And thank you for the reply, although I must admit that I'm still confused. In the patch of a7839e96 the predefined PNP constant is changed. For example: IO is changed from 8 to 24, Mem is changed from 4 to 12. That means that more resources will be obtained from the PNP device defined in ACPI table. So the system will print more message. OK. The change for Mem from 4 to 12 could explain the extra iomem range messages (although I don't quite understand why resources that could not be reserved still use a slot). The resources of PNP device are obtained by calling the _CRS method. Maybe some resources has been reserved. For example: Some system will reserve the following resources. BIOS-e820: fec0 - fed4 (reserved) BIOS-e820: fed45000 - 0001 (reserved) So the system will report that some resources can't be reserved. I do not yet see how the ioport range messages increased from 0 to 16 is explained, but I'm not too worried about that. At the same time another problem maybe happens. If the number of resources defined in BIOS still exceeds the predefined PNP constant, it will report that pnpacpi: exceeded the max number of IO resources: 24. Although it can be fixed by changed the pnp constant bigger, it is inappropriate because it will waste a lot of memory in most cases. Of course the above error message is harmless. Are the _errors_ really harmless? The error message is harmless. It only tells us that the resource definition of PNP device exceeds the predefined PNP constant and maybe there will be potential problem if some important resources can't be reserved. For example about 90 IOPORT resources are defined in some PNP device. So it will print the message. Of course it is more appropriate to change the message level from ERR to DEBUG. Your commit message was: It brings that some resources can't be reserved and resource confilicts. This will cause PCI resources are assigned wrongly in some systems, and cause hang. This is a regression since we deleted ACPI motherboard driver and use PNP system driver. That text seems to indicate that not reserving the remaining resources _can_ cause real problems. Do we know what PCI resources are now not being correctly reserved on my laptop (and other machines)? The fact that the message is repeated 22 times seems to indicate that in my case quite a lot of resources are being ignored. Should the memory allocation maybe be made dynamic instead of static if the memory waste is really such a problem? Apparently the number of PCI resources can vary wildly from one machine to another. It is more appropriate to use dynamic memory allocation for Pnp device than to increase the PNP constant bigger. Now Thomas is working on it. Maybe he will submit the patch very soon. If the error messages really are harmless, shouldn't they be changed from ERR to DEBUG? As it is, the messages are extremely ugly and will probably cause a lot of people to file bug reports as it _looks_ like there is an error. - To unsubscribe from this list: send the line unsubscribe linux-acpi in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [2.624-rc1 regression] lost battery information
Hmm. Things seem to have progressed since I was last online :-) With Alexey's original patch I also get a number of times: ACPI: element[12]-type = 1, expected string On Saturday 27 October 2007, Alexey Starikovskiy wrote: As you wish... :) Please check the attached patch. With 'battery_allow_extract_string_from_integer.patch' all info in /proc is back and I now also see the new files in /sys/class/power_supply. The OEM info field (line 13 in BAT1/info) is empty, just as it was empty in 2.6.23 too. Tested-by: Frans Pop [EMAIL PROTECTED] Cheers, Frans Pop - To unsubscribe from this list: send the line unsubscribe linux-acpi in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [2.624-rc1 regression] lost battery information
Andrey Borzenkov wrote: I have lost battery in 2.6.24-rc1. Without CONFIG_ACPI_PROCFS I have no /proc/acpi/battery and cannot test netlink interface because right now there is no consumer of this. This is a known issue. Please see: http://lkml.org/lkml/2007/10/22/110 Cheers, Frans Pop - To unsubscribe from this list: send the line unsubscribe linux-acpi in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [2.624-rc1 regression] lost battery information
Andrey Borzenkov wrote: I already have power_supply module, battery depends on it and it is autloaded. But I fail to see where I can get battery info in /sys Ah, yes. I see what you mean now and I can confirm the same regression wrt missing battery data in /proc for my laptop. $ cat /proc/acpi/battery/BAT1/* cat: /proc/acpi/battery/BAT1/alarm: Bad address cat: /proc/acpi/battery/BAT1/info: Bad address cat: /proc/acpi/battery/BAT1/state: Bad address Sorry for the earlier misunderstanding. - To unsubscribe from this list: send the line unsubscribe linux-acpi in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: latest 2.6.23 git missing ACPI POWER_SUPPLY
Jeff Chua wrote: Just pulled latest linux-2.6, and couldn't get ACPI to detect ACPI_BATTERY and ACPI_AC. It seems ACPI POWER_SUPPLY is still missing. I had the same problem. It turns out you need to enable drivers - Power supply class support (either built in or as module) to get ACPI AC/Battery support. I must say that having these relatively top-level ACPI settings depending on something that is relatively buried away is not very intuitive! Especially not since at first glance you don't really seem to need that option except for some weird hardware. CC'ing ACPI mailing list for other opinions. - To unsubscribe from this list: send the line unsubscribe linux-acpi in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: latest 2.6.23 git missing ACPI POWER_SUPPLY
On Monday 22 October 2007, Alexey Starikovskiy wrote: Frans Pop wrote: I must say that having these relatively top-level ACPI settings depending on something that is relatively buried away is not very intuitive! Especially not since at first glance you don't really seem to need that option except for some weird hardware. CC'ing ACPI mailing list for other opinions. I was thinking that 'select' might be more appropriate here... Please take a look on attached patch. Perfect! The power supply option can now no longer be unselected while battery or ac options are selected and will automatically get correct modular or compiled in status. Thanks. Tested-by: Frans Pop [EMAIL PROTECTED] - To unsubscribe from this list: send the line unsubscribe linux-acpi in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] Remove double mention of Support for ACPI option
From: Frans Pop [EMAIL PROTECTED] Current description for CONFIG_ACPI includes the word Support twice. One effect of this is that in menuconfig the --- that indicates the presence of sub-options will not show up unless you have a very wide console. Signed-off-by: Frans Pop [EMAIL PROTECTED] --- diff --git a/drivers/acpi/Kconfig b/drivers/acpi/Kconfig index 5d0e26a..92422a3 100644 --- a/drivers/acpi/Kconfig +++ b/drivers/acpi/Kconfig @@ -3,7 +3,7 @@ # menuconfig ACPI - bool ACPI Support (Advanced Configuration and Power Interface) Support + bool ACPI (Advanced Configuration and Power Interface) Support depends on !X86_NUMAQ depends on !X86_VISWS depends on !IA64_HP_SIM
ACPI suspend/hibernate tests (was: ACPI power off regression in 2.6.23-rc8)
On Tuesday 25 September 2007, Rafael J. Wysocki wrote:
On Tuesday, 25 September 2007 17:40, Linus Torvalds wrote:
Len - why are you guys moving stuff into CONFIG_PM_SLEEP? I know you
seem to think that absolutely *everybody* should always support suspend
and hibernation, but the fact is, not everybody does. And it's a
totally separate thing for normal ACPI CPU runstate support that people
have used to manage a *running* CPU (and shutting it down).
This was a mistake and fixes have already been posted:
http://marc.info/?l=linux-acpim=119052970904643w=4
http://marc.info/?l=linux-acpim=119073173625910w=4
As this whole separate suspend and hibernate change seems to have been
trickier than expected, I have done some additional testing using
2.6.23-rc8 plus both patches referred to above.
I compiled kernels (i386) for my laptop (Toshiba Satellite A40) with:
A) PM + SUSPEND + HIBERNATION + ACPI
B) PM + SUSPEND + ACPI
C) PM + HIBERNATION + ACPI
D) PM + ACPI
E) PM + SUSPEND + HIBERNATION but _without_ ACPI
F) without PM
In all cases CONFIG_APM was not set; all compiled without errors.
With all I have have booted, tried to suspend (close lid, which runs sleep
script, which does 'echo mem /sys/power/state'), tried to hibernate ('echo
disk /sys/power/state') and powered off (all from KDE sessions).
RESULTS
boots2ram s2disk off
A) OK OK OK OK
B) OK OK N/A OK
C) OK OK 1) OK OK
D) OK 2) OK 1) N/A OK
E) OK 3) N/A 4) ??? 5) Only halted 6)
F) OK N/A N/A Only halted 6)
Comments:
1) sleep script ran, but laptop stayed on
2) dmesg lists S0,S5 supported
/proc/acpi/{sleep,wakeup} do not exist (is that correct?)
3) /proc/acpi/{sleep,wakeup} do not exist; /sys/power/state only has 'mem'
so SUSPEND seems missing even though compiled in
4) sleep script did not even run (as expected)
5) System did suspend, but power stayed on with on console:
Shutdown: hda \ Power down. \ Shutdown: hda \ hda: lost interrupt (2x)
\ psmouse.c: Failed to deactivate mouse on isa0060/serio1
System powered off manually and resumed correctly after that
6) System halted correctly, but did not power off automatically
The results for E and F are possibly correct as basically the config
(without ACPI) was broken for this laptop. In fact, I was somewhat
surprised how well it behaved without ACPI.
I suspect that whether a system powers off without ACPI or not can depend on
the system?
I have dmesg after boot and some other info available for all kernels if
anybody is interested. If any additional tests are wanted, please ask.
Cheers,
FJP
-
To unsubscribe from this list: send the line unsubscribe linux-acpi in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [2.6.23-rc7] main.c: undefined reference to `acpi_sleep_prepare'
On Sunday 23 September 2007, Alexey Starikovskiy wrote: Frans Pop wrote: drivers/built-in.o: In function `acpi_power_off_prepare': main.c:(.text+0x32282): undefined reference to `acpi_sleep_prepare' drivers/built-in.o: In function `acpi_hibernation_prepare': main.c:(.text+0x3228c): undefined reference to `acpi_sleep_prepare' yep... acpi_sleep_prepare was put under CONFIG_SUSPEND spanning half of the file... this patch moves it out. Compiles and works fine with that patch applied. Thanks. One thing I noticed after booting with the kernel without CONFIG_SUSPEND. /proc/acpi/sleep no longer lists S3 (as expected), but /proc/acpi/wakeup does still list the device status for S3, which seems somewhat inconsistent: Device S-state Status Sysfs node VIY0 S3 disabled pci::01:0b.0 USB1 S3 disabled pci::00:1d.0 USB2 S3 disabled pci::00:1d.1 USB4 S3 disabled pci::00:1d.7 AMDM S3 disabled pci::00:1f.6 LID S4*enabled PWRB S4*enabled Not sure if it's worth fixing though. Cheers, FJP - To unsubscribe from this list: send the line unsubscribe linux-acpi in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: 2.6.23-rc6: S4 and S5 no longer listed as supported on Toshiba Satellite A40
On Thursday 20 September 2007, you wrote: 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: (supports S0 S3 S4 S5) +ACPI: (supports S0 S3) Unexpected, and potentially pretty serious. Something went wrong with ACPI. Can you try to narrow down when it started happening? rc1 still had all 4 levels. I'll run a bisect between rc1 and rc6. - To unsubscribe from this list: send the line unsubscribe linux-acpi in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: 2.6.23-rc6: S4 and S5 no longer listed as supported on Toshiba Satellite A40
On Thursday 20 September 2007, Frans Pop wrote: On Thursday 20 September 2007, you wrote: 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: (supports S0 S3 S4 S5) +ACPI: (supports S0 S3) Unexpected, and potentially pretty serious. Something went wrong with ACPI. Can you try to narrow down when it started happening? rc1 still had all 4 levels. I'll run a bisect between rc1 and rc6. I've bisected it down to this trio of changes: - b0cb1a19d05b8ea8 Replace CONFIG_SOFTWARE_SUSPEND with CONFIG_HIBERNATION - 296699de6bdc7171 Introduce CONFIG_SUSPEND for suspend-to-Ram and standby - 673d5b43daa00b42 ACPI: restore CONFIG_ACPI_SLEEP The actual change is probably in the second of those. I've seen the comment that the change may just be cosmetic, but I'll leave it to others to confirm that (and if so, judge if it is desirable or not). Cheers, Frans Pop - To unsubscribe from this list: send the line unsubscribe linux-acpi in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: 2.6.23-rc6: S4 and S5 no longer listed as supported on Toshiba Satellite A40
On Thursday 20 September 2007, Rafael J. Wysocki wrote:
On Thursday, 20 September 2007 20:33, Alexey Starikovskiy wrote:
Frans Pop wrote:
On Thursday 20 September 2007, you wrote:
Please try this patch.
Works. All states are now listed again.
I've not tested suspend to disk, but suspend to ram and power off
work fine.
+printk(KERN_INFO PREFIX (supports);
Note that this printk should be indented.
#ifdef CONFIG_SUSPEND
- printk(KERN_INFO PREFIX (supports);
for (i = ACPI_STATE_S0; i ACPI_STATE_S4; i++) {
Isn't there a risk now that we now end up printing
ACPI: (supports)
if CONFIG_SUSPEND is not enabled and S4 is not supported?
Or, more probably, it would print
ACPI: (supports S5)
Don't know what does it mean to support S0 exactly... :)
Agreed, though arguably the same goes for S5. I guess you could say they are
all states that can be switched to.
as it is unlikely that off is not supported :-)
Maybe S0 should be taken outside the #ifdef and the loop as that
state is also basically always there?
Don't think it is worth the trouble. We already have this loop almost
completely unrolled, let's not make it complete mess...
Well, you could use (supports S0 instead of just (supports. ;-)
After thinking about this a bit more, I think this does make sense for three
(admittedly minor) reasons:
- consistency between messages with and without CONFIG_SUSPEND
- consistency with /proc/acpi/sleep
- avoiding unnecessary change from previous versions.
Please consider the attached patch which applies on top of Alexey's. Feel
free to integrate it in his patch.
Signed-off-by: Frans Pop [EMAIL PROTECTED]
commit c4003376d234b990c371dad76fe3c3c6e8fe7965
Author: Frans Pop [EMAIL PROTECTED]
Date: Thu Sep 20 22:27:44 2007 +0200
S0 state is always supported
diff --git a/drivers/acpi/sleep/main.c b/drivers/acpi/sleep/main.c
index 638172f..85633c5 100644
--- a/drivers/acpi/sleep/main.c
+++ b/drivers/acpi/sleep/main.c
@@ -401,9 +401,11 @@ int __init acpi_sleep_init(void)
if (acpi_disabled)
return 0;
-printk(KERN_INFO PREFIX (supports);
+ sleep_states[ACPI_STATE_S0] = 1;
+ printk(KERN_INFO PREFIX (supports S0);
+
#ifdef CONFIG_SUSPEND
- for (i = ACPI_STATE_S0; i ACPI_STATE_S4; i++) {
+ for (i = ACPI_STATE_S1; i ACPI_STATE_S4; i++) {
status = acpi_get_sleep_type_data(i, type_a, type_b);
if (ACPI_SUCCESS(status)) {
sleep_states[i] = 1;
Re: 2.6.23-rc6: S4 and S5 no longer listed as supported on Toshiba Satellite A40
On Thursday 20 September 2007, Frans Pop wrote: On Thursday 20 September 2007, Rafael J. Wysocki wrote: On Thursday, 20 September 2007 20:33, Alexey Starikovskiy wrote: Frans Pop wrote: Maybe S0 should be taken outside the #ifdef and the loop as that state is also basically always there? Don't think it is worth the trouble. We already have this loop almost completely unrolled, let's not make it complete mess... Well, you could use (supports S0 instead of just (supports. ;-) After thinking about this a bit more, I think this does make sense for three (admittedly minor) reasons: - consistency between messages with and without CONFIG_SUSPEND - consistency with /proc/acpi/sleep - avoiding unnecessary change from previous versions. One additional reason... With current code, sleep_states(0) will not be set if compiled without CONFIG_SUSPEND, which means that S0 will also disappear from /proc/acpi/sleep. With pre-2.6.23 code it would be listed there. I think that is even a more relevant change than the display issue and could possibly even be considered a user-space interface regression. My proposed patch fixes that too. Note that the patch currently does not call acpi_get_sleep_type_data for S0, but (partially from Rafael's comment) I was assuming that for S0 that does not really matter. If it does, then the patch could easily be adjusted to include that. - To unsubscribe from this list: send the line unsubscribe linux-acpi in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
2.6.23-rc6: S4 and S5 no longer listed as supported on Toshiba Satellite A40
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: Look up EC in DSDT ACPI: Interpreter enabled -ACPI: (supports S0 S3 S4 S5) +ACPI: (supports S0 S3) ACPI: Using IOAPIC for interrupt routing ACPI: PCI Root Bridge [PCI0] (:00) I see no other relevant changes in dmesg (full output below). Is this a regression or expected? Cheers, Frans Pop 00:00.0 Host bridge [0600]: Intel Corporation 82852/82855 GM/GME/PM/GMV Processor to I/O Controller [8086:3580] (rev 02) 00:00.1 System peripheral [0880]: Intel Corporation 82852/82855 GM/GME/PM/GMV Processor to I/O Controller [8086:3584] (rev 02) 00:00.3 System peripheral [0880]: Intel Corporation 82852/82855 GM/GME/PM/GMV Processor to I/O Controller [8086:3585] (rev 02) 00:02.0 VGA compatible controller [0300]: Intel Corporation 82852/855GM Integrated Graphics Device [8086:3582] (rev 02) 00:02.1 Display controller [0380]: Intel Corporation 82852/855GM Integrated Graphics Device [8086:3582] (rev 02) 00:1d.0 USB Controller [0c03]: Intel Corporation 82801DB/DBL/DBM (ICH4/ICH4-L/ICH4-M) USB UHCI Controller #1 [8086:24c2] (rev 03) 00:1d.1 USB Controller [0c03]: Intel Corporation 82801DB/DBL/DBM (ICH4/ICH4-L/ICH4-M) USB UHCI Controller #2 [8086:24c4] (rev 03) 00:1d.7 USB Controller [0c03]: Intel Corporation 82801DB/DBM (ICH4/ICH4-M) USB2 EHCI Controller [8086:24cd] (rev 03) 00:1e.0 PCI bridge [0604]: Intel Corporation 82801 Mobile PCI Bridge [8086:2448] (rev 83) 00:1f.0 ISA bridge [0601]: Intel Corporation 82801DBM (ICH4-M) LPC Interface Bridge [8086:24cc] (rev 03) 00:1f.1 IDE interface [0101]: Intel Corporation 82801DBM (ICH4-M) IDE Controller [8086:24ca] (rev 03) 00:1f.5 Multimedia audio controller [0401]: Intel Corporation 82801DB/DBL/DBM (ICH4/ICH4-L/ICH4-M) AC'97 Audio Controller [8086:24c5] (rev 03) 00:1f.6 Modem [0703]: Intel Corporation 82801DB/DBL/DBM (ICH4/ICH4-L/ICH4-M) AC'97 Modem Controller [8086:24c6] (rev 03) 01:08.0 Ethernet controller [0200]: Intel Corporation 82801DB PRO/100 VE (MOB) Ethernet Controller [8086:103d] (rev 83) 01:0b.0 CardBus bridge [0607]: Toshiba America Info Systems ToPIC100 PCI to Cardbus Bridge with ZV Support [1179:0617] (rev 33) Linux version 2.6.23-rc6 ([EMAIL PROTECTED]) (gcc version 4.2.1 (Debian 4.2.1-4)) #1 SMP Wed Sep 19 16:31:00 CEST 2007 BIOS-provided physical RAM map: BIOS-e820: - 0009fc00 (usable) BIOS-e820: 0009fc00 - 000a (reserved) BIOS-e820: 000e - 000eee00 (reserved) BIOS-e820: 000eee00 - 000ef000 (ACPI NVS) BIOS-e820: 000ef000 - 0010 (reserved) BIOS-e820: 0010 - 1ef4 (usable) BIOS-e820: 1ef4 - 1ef5 (ACPI data) BIOS-e820: 1ef5 - 1f00 (reserved) BIOS-e820: fec0 - fec01000 (reserved) BIOS-e820: fec1 - fec2 (reserved) BIOS-e820: feda - fedc (reserved) BIOS-e820: fee0 - fee01000 (reserved) BIOS-e820: ffb0 - ffc0 (reserved) BIOS-e820: ffe8 - 0001 (reserved) 0MB HIGHMEM available. 495MB LOWMEM available. Entering add_active_range(0, 0, 126784) 0 entries of 256 used Zone PFN ranges: DMA 0 - 4096 Normal 4096 - 126784 HighMem126784 - 126784 Movable zone start PFN for each node early_node_map[1] active PFN ranges 0:0 - 126784 On node 0 totalpages: 126784 DMA zone: 32 pages used for memmap DMA zone: 0 pages reserved DMA zone: 4064 pages, LIFO batch:0 Normal zone: 958 pages used for memmap Normal zone: 121730 pages, LIFO batch:31 HighMem zone: 0 pages used for memmap Movable zone: 0 pages used for memmap DMI 2.3 present. ACPI: RSDP 000F0180, 0014 (r0 TOSHIB) ACPI: RSDT 1EF4, 0038 (r1 TOSHIB 750970814 TASM 401) ACPI: FACP 1EF40060, 0084 (r2 TOSHIB 750 20030101 TASM 401) ACPI: DSDT 1EF40558, 4B72 (r1 TOSHIB A000C20031216 MSFT 10E) ACPI: FACS 000EEE00, 0040 ACPI: SSDT 1EF402CA, 0082 (r1 TOSHIB A000C20030917 MSFT 10E) ACPI: DBGP 1EF400E4, 0034 (r1 TOSHIB 750970814 TASM 401) ACPI: BOOT 1EF40038, 0028 (r1 TOSHIB 750970814 TASM 401) ACPI: APIC 1EF40118, 0062 (r1 TOSHIB 750970814 TASM 401) ACPI: PM-Timer IO Port: 0xd808 ACPI: Local APIC address 0xfee0 ACPI: LAPIC (acpi_id[0x00] lapic_id[0x00] enabled) Processor #0 15:2 APIC version 20 ACPI: LAPIC (acpi_id[0x01] lapic_id[0x01] disabled) ACPI: LAPIC_NMI (acpi_id[0x00] high edge lint[0x1]) ACPI: IOAPIC (id[0x01] address[0xfec0] gsi_base[0]) IOAPIC[0]: apic_id 1, version 32, address 0xfec0, GSI 0-23 ACPI: INT_SRC_OVR (bus 0 bus_irq 0 global_irq 2 dfl dfl) ACPI
