Toshiba Satellite u305-7477 dmidecode output
# dmidecode 2.9 SMBIOS 2.4 present. 30 structures occupying 1044 bytes. Table at 0x000DF010. Handle 0x, DMI type 0, 24 bytes BIOS Information Vendor: TOSHIBA Version: V2.50 Release Date: 08/30/2007 Address: 0xE7860 Runtime Size: 100256 bytes ROM Size: 1024 kB Characteristics: ISA is supported PCI is supported PC Card (PCMCIA) is supported PNP is supported BIOS is upgradeable BIOS shadowing is allowed ESCD support is available Boot from CD is supported ACPI is supported USB legacy is supported BIOS boot specification is supported Targeted content distribution is supported Handle 0x0001, DMI type 1, 27 bytes System Information Manufacturer: TOSHIBA Product Name: Satellite U305 Version: PSU30U-054012 Serial Number: X7068484W UUID: 607BC0A3-0E91-D811-8DB6-001B24BBF5FC Wake-up Type: Power Switch SKU Number: Not Specified Family: Not Specified Handle 0x0002, DMI type 2, 8 bytes Base Board Information Manufacturer: TOSHIBA Product Name: Satellite U305 Version: Not Applicable Serial Number: X7068484W Handle 0x0003, DMI type 3, 17 bytes Chassis Information Manufacturer: TOSHIBA Type: Other Lock: Not Present Version: N/A Serial Number: None Asset Tag: Boot-up State: Safe Power Supply State: Safe Thermal State: Safe Security Status: None OEM Information: 0x42553153 Handle 0x0004, DMI type 4, 35 bytes Processor Information Socket Designation: U2E1 Type: Central Processor Family: Other Manufacturer: Intel ID: FD 06 00 00 FF FB EB BF Version: CPU Version Voltage: 3.3 V External Clock: 200 MHz Max Speed: 4096 MHz Current Speed: 2000 MHz Status: Populated, Enabled Upgrade: ZIF Socket L1 Cache Handle: 0x0005 L2 Cache Handle: 0x0006 L3 Cache Handle: Not Provided Serial Number: Not Specified Asset Tag: Not Specified Part Number: Not Specified Handle 0x0005, DMI type 7, 19 bytes Cache Information Socket Designation: L1 Cache Configuration: Enabled, Socketed, Level 1 Operational Mode: Write Back Location: Internal Installed Size: 64 KB Maximum Size: 64 KB Supported SRAM Types: Burst Pipeline Burst Asynchronous Installed SRAM Type: Asynchronous Speed: Unknown Error Correction Type: Unknown System Type: Unknown Associativity: Unknown Handle 0x0006, DMI type 7, 19 bytes Cache Information Socket Designation: L2 Cache Configuration: Enabled, Socketed, Level 2 Operational Mode: Write Back Location: Internal Installed Size: 2048 KB Maximum Size: 4096 KB Supported SRAM Types: Burst Pipeline Burst Asynchronous Installed SRAM Type: Burst Speed: Unknown Error Correction Type: Unknown System Type: Unknown Associativity: Unknown Handle 0x0007, DMI type 9, 13 bytes System Slot Information Designation: PCI Slot J8B3 Type: 32-bit PCI Current Usage: Unknown Length: Long ID: 0 Characteristics: 5.0 V is provided 3.3 V is provided Handle 0x0008, DMI type 10, 6 bytes On Board Device Information Type: Sound Status: Disabled Description: HD-Audio Handle 0x0009, DMI type 11, 5 bytes OEM Strings String 1: PSU30U-054012,SQ004398V06,11B Handle 0x000A, DMI type 12, 5 bytes System Configuration Options Option 1: Jumper settings can be described here. Handle 0x000B, DMI type 15, 29 bytes System Event Log Area Length: 16 bytes Header Start Offset: 0x Header Length: 16 bytes Data Start Offset: 0x0010 Access Method: General-purpose non-volatile data functions Access Address: 0x Status: Valid, Not Full Change Token: 0x00AF Header Format: Type 1 Supported Log Type Descriptors: 3 Descriptor 1: POST error Data Format 1: POST results bitmap Descriptor 2: Single-bit ECC memory error Data Format 2: Multiple-event Descriptor 3: Multi-bit ECC memory error Data Format 3: Multiple-event Handle 0x000C, DMI type 16, 15 bytes Physical Memory Array Location: System Board Or Motherboard Use: System Memory Error Correction Type: None Maximum Capacity: 4 GB Error Information Handle: Not Provided Number Of
Re: DSDT problems with Asus K8V-X SE
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Carlos Corbacho wrote: On Saturday 05 January 2008 16:58:50 AnMaster wrote: My problem is a broken DSDT, I have tried to fix it, but I don't know if I did it the right way, nor how to solve the warning that remains when the errors are gone. What exactly is broken about your DSDT that requires you to 'fix' it? Yes, lots of vendor DSDTs won't compile with the Intel compiler - this is because the Microsoft compiler is far more 'generous' than Intel's, and will allow a lot of spec breaking rubbish in. However, the ACPI interpreter in Linux can handle most of these just fine; and if it can't, then that's a bug that needs to be fixed in Linux (since Linux should be able to handle unmodified MS compiled DSDTs out of the box). -Carlos I get lots of lock ups (no kernel oopes or other useful info, just everything locks up) that goes away when I disable ACPI. Someone on IRC said that I should try to fix the DSDT to see if that helps. Regards, Arvid Norlander -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.7 (GNU/Linux) iD8DBQFHgKhIWmK6ng/aMNkRCp7zAKDDEn8Deif0QuW6v8IP42VS/2fLuwCfRG9M QYCXQ3eJrwj+gw2O7Kaydso= =xOEK -END PGP SIGNATURE- - 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: [PATCH] PM: Acquire device locks on suspend
On Sunday, 6 of January 2008, Alan Stern wrote:
On Sat, 5 Jan 2008, Rafael J. Wysocki wrote:
On Saturday, 5 of January 2008, Alan Stern wrote:
On Sat, 5 Jan 2008, Rafael J. Wysocki wrote:
Still, even doing that is not enough, since someone can call
destroy_suspended_device() from a .suspend() routine and then the device
will end up on a wrong list just as well.
That should never happen. The whole idea of destroy_suspended_device()
is that the device couldn't be resumed and in fact should be
unregistered because it is no longer working or no longer present. A
suspend routine won't detect this sort of thing since it doesn't try to
resume the device.
But it wouldn't hurt to mention in the kerneldoc that
destroy_suspended_device() is meant to be called only during a system
resume.
Hmm. Please have a look at the appended patch.
I have removed the warning from device_del() and used list_empty() to detect
removed devices in the .suspend() routines. Is that viable?
It's not good.
The warning in device_del() is vital. It's what will tell people where
the problem is when a deadlock occurs during system resume because some
driver has mistakenly tried to unregister a device at the wrong time.
It would have pointed immediately to the msr driver in the case of the
bug Andrew found, for instance.
If you can figure out a way to disable the warning in device_del() for
just the one device being unregistered by
device_pm_destroy_suspended(),
Something like this, perhaps:
@@ -905,6 +915,18 @@ void device_del(struct device * dev)
struct device * parent = dev-parent;
struct class_interface *class_intf;
+ if (down_trylock(dev-sem)) {
+ if (pm_sleep_lock()) {
+ dev_warn(dev, Illegal %s during suspend\n,
+ __FUNCTION__);
+ dump_stack();
+ } else {
+ pm_sleep_unlock();
+ }
+ } else {
+ up(dev-sem);
+ }
+
if (parent)
klist_del(dev-knode_parent);
if (MAJOR(dev-devt))
I suppose that would be okay.
Rafael
-
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
ACPI keys for backlight control
Does anyone know anything about ACPI key-based laptop backlight control? My white-box laptop is apparently based on an Asus mainboard. dmidecode says: Handle 0x0001, DMI type 1, 25 bytes. System Information Manufacturer: ASUSTeK Computer Inc. Product Name: M7V Version: 1.0 Serial Number: SSN12345678901234567 UUID: 28CE5D8A--0080-385D-0017312C16F2 Wake-up Type: Power Switch Love that serial number. Anyway, this hardware apparently has an ambient light sensor, and three ACPI keys. In Win XP, the first key controls the backlight automatic/manual mode. In automatic mode, the ambient light sensor gradually reduces the backlight, based on the room light level, in small incremental steps, from about 100% brightness to about 30%. In manual mode, the sensor itself is disabled and the other two ACPI keys incrementally step up or step down the backlight power. Win XP responds to the ACPI keys with small popup indicators. GRUB's menu comes up with the light sensor in manual mode. As soon as the kernel boots, it goes to automatic, and there is no further response to any of these three ACPI keys. Booting with noacpi keeps the light sensor in manual mode. In neither case can I, apparently, switch between manual and automatic mode with the ACPI keys. Except for this, I have ACPI working fine. I have other ACPI keys that enable/disable the external VGA port, and they work as advertised. My normal light level appears to be right at the upper sensor range, and the nearly-subliminal back-and-forth backlight light level adjustment becomes irritating rather quickly. But there's no response to these three ACPI keys, nothing in syslog, and the backlight settings in Gnome's power management do nothing. There's nothing else in dmidecode's output, or lspci's output, that refers to the sensor. pgpa7OvCBLH7L.pgp Description: PGP signature
Re: [PATCH] PM: Acquire device locks on suspend
On Sunday, 6 of January 2008, Rafael J. Wysocki wrote:
On Sunday, 6 of January 2008, Alan Stern wrote:
On Sun, 6 Jan 2008, Rafael J. Wysocki wrote:
If you can figure out a way to disable the warning in device_del() for
just the one device being unregistered by
device_pm_destroy_suspended(),
Something like this, perhaps:
@@ -905,6 +915,18 @@ void device_del(struct device * dev)
struct device * parent = dev-parent;
struct class_interface *class_intf;
+ if (down_trylock(dev-sem)) {
+ if (pm_sleep_lock()) {
+ dev_warn(dev, Illegal %s during suspend\n,
+ __FUNCTION__);
+ dump_stack();
+ } else {
+ pm_sleep_unlock();
+ }
+ } else {
+ up(dev-sem);
+ }
+
if (parent)
klist_del(dev-knode_parent);
if (MAJOR(dev-devt))
Bizarre, but it should work.
OK
Still, shouldn't we fail the removal of the device apart from giving the
warning?
Actually, having thought about it a bit more, I don't see the point in
preventing the removal of the device from the list in device_pm_remove() if
we allow all of the operations in device_del() preceding it to be performed.
Shouldn't we just take pm_sleep_rwsem in device_del() upfront and block on that
if locked?
Rafael
-
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: + restore-missing-sysfs-max_cstate-attr.patch added to -mm tree
Venki Pallipadi wrote: Reintroduce run time configurable max_cstate for !CPU_IDLE case. Signed-off-by: Venkatesh Pallipadi [EMAIL PROTECTED] Index: linux-2.6.24-rc/drivers/acpi/processor_idle.c === --- linux-2.6.24-rc.orig/drivers/acpi/processor_idle.c +++ linux-2.6.24-rc/drivers/acpi/processor_idle.c @@ -76,7 +76,11 @@ static void (*pm_idle_save) (void) __rea #define PM_TIMER_TICKS_TO_US(p)(((p) * 1000)/(PM_TIMER_FREQUENCY/1000)) static unsigned int max_cstate __read_mostly = ACPI_PROCESSOR_MAX_POWER; +#ifdef CONFIG_CPU_IDLE module_param(max_cstate, uint, ); +#else +module_param(max_cstate, uint, 0644); +#endif static unsigned int nocst __read_mostly; module_param(nocst, uint, ); .. Can we get this patch upstream so that a stock 2.6.24 will work here? Thanks - 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: [PATCH] PM: Acquire device locks on suspend
On Sunday, 6 of January 2008, Alan Stern wrote: On Sun, 6 Jan 2008, Rafael J. Wysocki wrote: On Sunday, 6 of January 2008, Alan Stern wrote: Still, shouldn't we fail the removal of the device apart from giving the warning? We can't. device_del() can't fail -- it returns void. Besides, how can a driver hope to deal with an unregistration failure? Well, right. Still, our present approach doesn't seem to be correct overall. For example, I think we should prevent a suspend from happening while a device is being removed. Rafael - 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: [PATCH] PM: Acquire device locks on suspend
On Sun, 6 Jan 2008, Rafael J. Wysocki wrote: Still, our present approach doesn't seem to be correct overall. For example, I think we should prevent a suspend from happening while a device is being removed. We could, however I don't think it's dangerous to allow it. The two problems to avoid are (1) messing up the PM device list pointers, and (2) calling a driver's suspend/resume methods while its remove method is running. (1) is handled by the pm_list_mutex and (2) is handled by locking dev-sem. Alan Stern - 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: [PATCH] PM: Acquire device locks on suspend
On Sunday, 6 of January 2008, Alan Stern wrote: On Sun, 6 Jan 2008, Rafael J. Wysocki wrote: Still, shouldn't we fail the removal of the device apart from giving the warning? Actually, having thought about it a bit more, I don't see the point in preventing the removal of the device from the list in device_pm_remove() if we allow all of the operations in device_del() preceding it to be performed. That's not the issue. We _don't_ allow all of the operations in device_del() preceding the call to device_pm_remove(). In particular, the call to the device's driver's remove method will deadlock because device_release_driver() always has to acquire dev-sem. Shouldn't we just take pm_sleep_rwsem in device_del() upfront and block on that if locked? No -- the whole idea here is to print an error message in the system log if a driver's resume method tries to call device_del(). Deadlock is unavoidable in this case, but at least we'll know which driver is guilty. Still, if we do that, we won't need to acquire dev-sem in device_pm_remove() any more. Apart from this, by acqiring pm_sleep_rwsem for reading in device_del() we can prevent a suspend from starting while the device is being removed. Consider, for example, the scenario possible with the $subject patch: - device_del() starts and notices pm_sleep_rwsem unlocked, so the warning is not printed - it proceeds and everything before device_pm_remove() succeeds - now, device_suspend() is called and locks dev-sem - device_del() calls device_pm_remove() and blocks on that with the device partialy removed I think we should prevent this from happening. Rafael - 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: [PATCH] PM: Acquire device locks on suspend
On Sunday, 6 of January 2008, Rafael J. Wysocki wrote:
On Sunday, 6 of January 2008, Rafael J. Wysocki wrote:
On Sunday, 6 of January 2008, Alan Stern wrote:
On Sun, 6 Jan 2008, Rafael J. Wysocki wrote:
If you can figure out a way to disable the warning in device_del()
for
just the one device being unregistered by
device_pm_destroy_suspended(),
Something like this, perhaps:
@@ -905,6 +915,18 @@ void device_del(struct device * dev)
struct device * parent = dev-parent;
struct class_interface *class_intf;
+ if (down_trylock(dev-sem)) {
+ if (pm_sleep_lock()) {
+ dev_warn(dev, Illegal %s during suspend\n,
+ __FUNCTION__);
+ dump_stack();
+ } else {
+ pm_sleep_unlock();
+ }
+ } else {
+ up(dev-sem);
+ }
+
if (parent)
klist_del(dev-knode_parent);
if (MAJOR(dev-devt))
Bizarre, but it should work.
OK
Still, shouldn't we fail the removal of the device apart from giving the
warning?
Actually, having thought about it a bit more, I don't see the point in
preventing the removal of the device from the list in device_pm_remove() if
we allow all of the operations in device_del() preceding it to be performed.
Shouldn't we just take pm_sleep_rwsem in device_del() upfront and block on
that
if locked?
Ugh, the $subject patch looks like a city of races. I'm struggling to close
them all, but it's getting complicated.
I'll post the result in a new thread.
Thanks,
Rafael
-
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: [PATCH] PM: Acquire device locks on suspend
On Sun, 6 Jan 2008, Rafael J. Wysocki wrote: No -- the whole idea here is to print an error message in the system log if a driver's resume method tries to call device_del(). Deadlock is unavoidable in this case, but at least we'll know which driver is guilty. Still, if we do that, we won't need to acquire dev-sem in device_pm_remove() any more. There's a window in lock_all_devices() when dpm_list_mtx isn't held. We don't want device_pm_remove() taking an already-locked device off the dpm_locked list at that time. So we do need to acquire dev-sem in device_pm_remove(). Apart from this, by acqiring pm_sleep_rwsem for reading in device_del() we can prevent a suspend from starting while the device is being removed. Consider, for example, the scenario possible with the $subject patch: - device_del() starts and notices pm_sleep_rwsem unlocked, so the warning is not printed - it proceeds and everything before device_pm_remove() succeeds - now, device_suspend() is called and locks dev-sem - device_del() calls device_pm_remove() and blocks on that with the device partialy removed I think we should prevent this from happening. I don't see anything wrong with it. All that will happen is that the removal will start before the suspend and finish after the resume. Alan Stern - 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: [PATCH] PM: Acquire device locks on suspend
On Sunday, 6 of January 2008, Alan Stern wrote: On Sun, 6 Jan 2008, Rafael J. Wysocki wrote: No -- the whole idea here is to print an error message in the system log if a driver's resume method tries to call device_del(). Deadlock is unavoidable in this case, but at least we'll know which driver is guilty. Still, if we do that, we won't need to acquire dev-sem in device_pm_remove() any more. There's a window in lock_all_devices() when dpm_list_mtx isn't held. We don't want device_pm_remove() taking an already-locked device off the dpm_locked list at that time. So we do need to acquire dev-sem in device_pm_remove(). Not if pm_sleep_rwsem is held by device_del(), since in that case we won't reach lock_all_devices() (device_add() calls device_pm_remove() under pm_sleep_rwsem already). Apart from this, by acqiring pm_sleep_rwsem for reading in device_del() we can prevent a suspend from starting while the device is being removed. Consider, for example, the scenario possible with the $subject patch: - device_del() starts and notices pm_sleep_rwsem unlocked, so the warning is not printed - it proceeds and everything before device_pm_remove() succeeds - now, device_suspend() is called and locks dev-sem - device_del() calls device_pm_remove() and blocks on that with the device partialy removed I think we should prevent this from happening. I don't see anything wrong with it. All that will happen is that the removal will start before the suspend and finish after the resume. In that case, we'll attempt to call the device's .suspend() and .resume() routines, but we shouldn't do that, IMHO. Rafael - 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: [linux-pm] Re: [PATCH] PM: Acquire device locks on suspend
On Monday, 7 of January 2008, Johannes Berg wrote: Rafael J. Wysocki wrote: I don't see anything wrong with it. All that will happen is that the removal will start before the suspend and finish after the resume. In that case, we'll attempt to call the device's .suspend() and .resume() routines, but we shouldn't do that, IMHO. I don't see anything wrong with that since the driver must be prepared to handle that even in the regular case, it's the only thing you can guarantee: no more method calls after removal finishes. Am I totally misunderstanding things? Well, we are towards the end of device removal at this point, having called bus_remove_device(dev) for example, but still we've got it on dpm_active ... This may not be technically wrong (ie. we should be able to recover from that), but it seems conceptually wrong and with pm_sleep_rwsem in place it can be avoided. Rafael - 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: [linux-pm] Re: [PATCH] PM: Acquire device locks on suspend
On Monday, 7 of January 2008, Rafael J. Wysocki wrote: On Monday, 7 of January 2008, Johannes Berg wrote: Rafael J. Wysocki wrote: I don't see anything wrong with it. All that will happen is that the removal will start before the suspend and finish after the resume. In that case, we'll attempt to call the device's .suspend() and .resume() routines, but we shouldn't do that, IMHO. I don't see anything wrong with that since the driver must be prepared to handle that even in the regular case, it's the only thing you can guarantee: no more method calls after removal finishes. Am I totally misunderstanding things? Well, we are towards the end of device removal at this point, having called bus_remove_device(dev) for example, but still we've got it on dpm_active ... This may not be technically wrong (ie. we should be able to recover from that), but it seems conceptually wrong and with pm_sleep_rwsem in place it can be avoided. No, it can't, without major complications. Well, I think I'll just send a patch that should work most of the time ... Rafael - 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: brightness control on thinkpad t61p
On Thu, 27 Dec 2007, Henrique de Moraes Holschuh wrote: On Wed, 26 Dec 2007, Matthew Garrett wrote: On Wed, Dec 26, 2007 at 02:10:27PM -0800, Andrew Morton wrote: Vice versa for me. The thinkpad_acpi driver in 2.6.23 _does_ work, but its interface vanished in 2.6.24-rc5 and the acpi driver does not work. As I said, the interface for the ACPI backlight driver is confusing. 10 will only work if the firmware supports it - have you tried other values? Not on a thinkpad. The AML code is not that stupid, it rounds down to the nearest supported value. It takes a brightness percentage (0 to 100), maps it through a table to get the visual brightness - hardware brightness curve right (it is non-linear), then does what thinkpad-acpi does to set backlight brightness. Bah, I spoke too soon. Latest round of BIOSes seems to have broken this, either that or I completely misunderstood the older AML code. Rounding to the nearest supplied _BCL value before we call _BCM apparently will be needed on thinkpads as well. Oh, just another datapoint for Andrew: your thinkpad backlight firmware behaves differently before and after something calls _BCL. And I believe it also behaves differently before Linux boots (my guess is that it changes behaviour when ACPI inits), so it is getting more and more complicated to debug this thing without direct access to one such thinkpad. I heavily recommend calling the ACPI _BCL method (e.g. by loading ACPI video and unloading it later if you don't want it), so that at least you have a small chance of things working consistently :) The AML code is supposed to just issue normal ACPI events and leave the backlight hardware alone after you call _BCL. But if X.org is messing with the BIOS scratch registers, not even ACPI video.c will work, as the SMBIOS crap the thinkpad AML code calls to implement BQC/BCQ and BCM will be disabled. In that case, X.org has to be able to modify the hardware directly (through xbacklight) in order to get anything done. I am seriously considering a call to _BCM in thinkpad-acpi, to make sure we get a more-or-less sane thinkpad behaviour on these newer Lenovo BIOSes, even if the user doesn't want to use ACPI video.c for some reason. -- One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie. -- The Silicon Valley Tarot Henrique Holschuh - 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: [patch] hibernation: utilize ACPI hardware signature
On Sat, 2008-01-05 at 04:44 +0800, Rafael J. Wysocki wrote:
On Friday, 4 of January 2008, Shaohua Li wrote:
On Fri, 2008-01-04 at 01:04 +0800, Rafael J. Wysocki wrote:
On Thursday, 3 of January 2008, Shaohua Li wrote:
On Wed, 2008-01-02 at 22:05 +0800, Rafael J. Wysocki wrote:
On Wednesday, 2 of January 2008, Shaohua Li wrote:
ACPI defines a hardware signature. BIOS calculates the
signature
according to hardware configure, if hardware changes, the
signature
will
change, in this case, S4 resume should fail.
The idea is fine, but I'd prefer to do that in a more
straightforward
way.
Namely, we can just:
* write the signature into a variable in, for example,
acpi_hibernation_prepare() (then, the old signature value
will
be
automatically saved in the image)
* compare it with a the new value read from the BIOS in
acpi_hibernation_leave() and panic if there's a mismatch
* add a configuration option to disable this behavior (just in
case)
This way we can avoid modifying the entire generic interface
to
add
the feature
specific to ACPI.
it would be better we do the check in boot kernel.
Franky, I think we should also check in the image kernel, in case
the
boot
one doesn't support ACPI as I said.
Ok, makes sense. I changed to check the signature
in .higberation_leave
Thanks, comments below.
Signed-off-by: Shaohua Li [EMAIL PROTECTED]
---
drivers/acpi/sleep/main.c | 20
1 file changed, 20 insertions(+)
Index: linux/drivers/acpi/sleep/main.c
===
--- linux.orig/drivers/acpi/sleep/main.c 2008-01-03
13:37:08.0 +0800
+++ linux/drivers/acpi/sleep/main.c 2008-01-04 13:36:10.0
+0800
@@ -256,6 +256,17 @@ static int acpi_hibernation_enter(void)
return ACPI_SUCCESS(status) ? 0 : -EFAULT;
}
+static unsigned long s4_hardware_signature;
+static struct acpi_table_facs *facs;
+static int nosigcheck;
Use bool perhaps?
+
+static int __init acpi_s4_nosigcheck(char *str)
+{
+ nosigcheck = 1;
And true here?
+ return 1;
+}
+__setup(acpi_s4_nosigcheck, acpi_s4_nosigcheck);
+
Please put this function at the end of the file. Also, I'd call it
acpi_s4_nosig, but whatever.
Fixed all except this one, the routine is defined with HIBERATION
configed.
Signed-off-by: Shaohua Li [EMAIL PROTECTED]
---
drivers/acpi/sleep/main.c | 22 ++
1 file changed, 22 insertions(+)
Index: linux/drivers/acpi/sleep/main.c
===
--- linux.orig/drivers/acpi/sleep/main.c2008-01-04 13:44:40.0
+0800
+++ linux/drivers/acpi/sleep/main.c 2008-01-07 09:31:42.0 +0800
@@ -256,6 +256,17 @@ static int acpi_hibernation_enter(void)
return ACPI_SUCCESS(status) ? 0 : -EFAULT;
}
+static unsigned long s4_hardware_signature;
+static struct acpi_table_facs *facs;
+static bool nosigcheck;
+
+static int __init acpi_s4_nosigcheck(char *str)
+{
+ nosigcheck = true;
+ return 1;
+}
+__setup(acpi_s4_nosigcheck, acpi_s4_nosigcheck);
+
static void acpi_hibernation_leave(void)
{
/*
@@ -263,6 +274,10 @@ static void acpi_hibernation_leave(void)
* enable it here.
*/
acpi_enable();
+ if (facs s4_hardware_signature != facs-hardware_signature) {
+ printk(KERN_EMERGPM: Hardware changed in the S4 circle, can't
resume\n);
+ panic(S4 resume error);
+ }
}
static void acpi_hibernation_finish(void)
@@ -448,6 +463,13 @@ int __init acpi_sleep_init(void)
hibernation_set_ops(acpi_hibernation_ops);
sleep_states[ACPI_STATE_S4] = 1;
printk( S4);
+ if (!nosigcheck) {
+ acpi_get_table_by_index(ACPI_TABLE_INDEX_FACS,
+ (struct acpi_table_header **)facs);
+ if (facs)
+ s4_hardware_signature =
+ facs-hardware_signature;
+ }
}
#endif
status = acpi_get_sleep_type_data(ACPI_STATE_S5, type_a, type_b);
-
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
[RFC][PATCH] PM: Acquire device locks on suspend (rev. 2)
Hi,
The patch below is intended as a replacement for
gregkh-driver-pm-acquire-device-locks-prior-to-suspending.patch that deadlocked
suspend and hibernation on some systems. The present patch contains some
safeguards against deadlocks in that cases and a mechanism to print warnings
if a deadlock is probable.
I've tested it a little, but the error paths are generally untested.
Please review.
Thanks,
Rafael
---
From: Alan Stern [EMAIL PROTECTED], Rafael J. Wysocki [EMAIL PROTECTED]
This patch reorganizes the way suspend and resume notifications are
sent to drivers. The major changes are that now the PM core acquires
every device semaphore before calling the methods, and calls to
device_add() during suspends will fail, while calls to device_del()
during suspends will block.
It also provides a way to safely remove a suspended device with the
help of the PM core, by using the destroy_suspended_device() callback
introduced specifically for this purpose, and updates two drivers (msr
and cpuid) that need to use it.
Signed-off-by: Rafael J. Wysocki [EMAIL PROTECTED]
---
arch/x86/kernel/cpuid.c|6
arch/x86/kernel/msr.c |6
drivers/base/core.c| 79 ++-
drivers/base/power/main.c | 494 -
drivers/base/power/power.h | 12 +
include/linux/device.h |8
6 files changed, 406 insertions(+), 199 deletions(-)
Index: linux-2.6/drivers/base/core.c
===
--- linux-2.6.orig/drivers/base/core.c
+++ linux-2.6/drivers/base/core.c
@@ -726,11 +726,20 @@ int device_add(struct device *dev)
{
struct device *parent = NULL;
struct class_interface *class_intf;
- int error = -EINVAL;
+ int error;
+
+ error = pm_sleep_lock();
+ if (error) {
+ dev_warn(dev, Illegal %s during suspend\n, __FUNCTION__);
+ dump_stack();
+ return error;
+ }
dev = get_device(dev);
- if (!dev || !strlen(dev-bus_id))
+ if (!dev || !strlen(dev-bus_id)) {
+ error = -EINVAL;
goto Error;
+ }
pr_debug(DEV: registering device: ID = '%s'\n, dev-bus_id);
@@ -795,6 +804,7 @@ int device_add(struct device *dev)
}
Done:
put_device(dev);
+ pm_sleep_unlock();
return error;
BusError:
device_pm_remove(dev);
@@ -905,6 +915,27 @@ void device_del(struct device * dev)
struct device * parent = dev-parent;
struct class_interface *class_intf;
+ /*
+* If this function is called during a suspend, it will be blocked by
+* the PM core holding the device's semaphore at that time, which may
+* lead to a deadlock. In that case we want to print a warning.
+* However, it may also be called by the PM core itself with the
+* device's semaphore released, in which case the warning should not be
+* printed.
+*/
+ if (down_trylock(dev-sem)) {
+ if (pm_sleep_lock()) {
+ /* Suspend in progress, we may deadlock */
+ dev_warn(dev, Illegal %s during suspend\n,
+ __FUNCTION__);
+ dump_stack();
+ } else {
+ pm_sleep_unlock();
+ }
+ } else {
+ up(dev-sem);
+ }
+
if (parent)
klist_del(dev-knode_parent);
if (MAJOR(dev-devt))
@@ -1156,14 +1187,11 @@ error:
EXPORT_SYMBOL_GPL(device_create);
/**
- * device_destroy - removes a device that was created with device_create()
+ * find_device - finds a device that was created with device_create()
* @class: pointer to the struct class that this device was registered with
* @devt: the dev_t of the device that was previously registered
- *
- * This call unregisters and cleans up a device that was created with a
- * call to device_create().
*/
-void device_destroy(struct class *class, dev_t devt)
+static struct device *find_device(struct class *class, dev_t devt)
{
struct device *dev = NULL;
struct device *dev_tmp;
@@ -1176,12 +1204,49 @@ void device_destroy(struct class *class,
}
}
up(class-sem);
+ return dev;
+}
+
+/**
+ * device_destroy - removes a device that was created with device_create()
+ * @class: pointer to the struct class that this device was registered with
+ * @devt: the dev_t of the device that was previously registered
+ *
+ * This call unregisters and cleans up a device that was created with a
+ * call to device_create().
+ */
+void device_destroy(struct class *class, dev_t devt)
+{
+ struct device *dev;
+ dev = find_device(class, devt);
if (dev)
device_unregister(dev);
}
EXPORT_SYMBOL_GPL(device_destroy);
+#ifdef CONFIG_PM_SLEEP
+/**
+ * destroy_suspended_device - asks the PM core to remove a
Re: + restore-missing-sysfs-max_cstate-attr.patch added to -mm tree
On Sun, 06 Jan 2008 16:34:16 -0500 Mark Lord [EMAIL PROTECTED] wrote: Venki Pallipadi wrote: Reintroduce run time configurable max_cstate for !CPU_IDLE case. Signed-off-by: Venkatesh Pallipadi [EMAIL PROTECTED] Index: linux-2.6.24-rc/drivers/acpi/processor_idle.c === --- linux-2.6.24-rc.orig/drivers/acpi/processor_idle.c +++ linux-2.6.24-rc/drivers/acpi/processor_idle.c @@ -76,7 +76,11 @@ static void (*pm_idle_save) (void) __rea #define PM_TIMER_TICKS_TO_US(p)(((p) * 1000)/(PM_TIMER_FREQUENCY/1000)) static unsigned int max_cstate __read_mostly = ACPI_PROCESSOR_MAX_POWER; +#ifdef CONFIG_CPU_IDLE module_param(max_cstate, uint, ); +#else +module_param(max_cstate, uint, 0644); +#endif static unsigned int nocst __read_mostly; module_param(nocst, uint, ); .. Can we get this patch upstream so that a stock 2.6.24 will work here? umm, OK, I queued it for 2.6.24. I'll give people a day or so to comment on this. I had to invent some silly changlelog for it. Please review it for accuracy and completeness? It isn't complete, really. How come we only make max_cstate writeable if CONFIG_CPU_IDLE=n? What happens to people who were reliant upon writeable max_cstate who now enable CPU_IDLE? Things still break? What is the rationale behind this? What constraints led us to this decision? From: Venki Pallipadi [EMAIL PROTECTED] This was writeable in 2.6.23 but the cpuidle merge made it read-only. But some people's scripts (ie: Mark's) were writing to it. As an unhappy compromise, make max_cstate writeable again if the kernel was configured without CONFIG_CPU_IDLE. Signed-off-by: Venkatesh Pallipadi [EMAIL PROTECTED] Cc: Mark Lord [EMAIL PROTECTED] Cc: Arjan van de Ven [EMAIL PROTECTED] Cc: Len Brown [EMAIL PROTECTED] Cc: Ingo Molnar [EMAIL PROTECTED] Cc: Rafael J. Wysocki [EMAIL PROTECTED] Signed-off-by: Andrew Morton [EMAIL PROTECTED] --- drivers/acpi/processor_idle.c |4 1 file changed, 4 insertions(+) diff -puN drivers/acpi/processor_idle.c~reintroduce-run-time-configurable-max_cstate-for-cpu_idle-case drivers/acpi/processor_idle.c --- a/drivers/acpi/processor_idle.c~reintroduce-run-time-configurable-max_cstate-for-cpu_idle-case +++ a/drivers/acpi/processor_idle.c @@ -76,7 +76,11 @@ static void (*pm_idle_save) (void) __rea #define PM_TIMER_TICKS_TO_US(p)(((p) * 1000)/(PM_TIMER_FREQUENCY/1000)) static unsigned int max_cstate __read_mostly = ACPI_PROCESSOR_MAX_POWER; +#ifdef CONFIG_CPU_IDLE module_param(max_cstate, uint, ); +#else +module_param(max_cstate, uint, 0644); +#endif static unsigned int nocst __read_mostly; module_param(nocst, uint, ); _ - 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] ACPI: fix processor throttling set error
Subject: ACPI: fix processor throttling set error From: Yi Yang [EMAIL PROTECTED] When echo some invalid values to /proc/acpi/processor/*/throttling, there isn't any error info returned, on the contray, it sets throttling value to some T* successfully, obviously, this is incorrect, a correct way should be to let it fail and return error info. This patch fixed the aforementioned issue, it also enables /proc/acpi/processor/*/throttling to accept such values as 't0' and 'T0', it also strictly limits /proc/acpi/processor/*/throttling only to accept *, t* and T*, * is the throttling state value the processor can support, current, it is 0 - 7. Before applying this patch, the test result is below: [EMAIL PROTECTED] acpi]# cat /proc/acpi/processor/CPU0/throttling state count: 8 active state:T1 state available: T0 to T7 states: T0: 100% *T1: 87% T2: 75% T3: 62% T4: 50% T5: 37% T6: 25% T7: 12% [EMAIL PROTECTED] acpi]# echo 1xx /proc/acpi/processor/CPU0/throttling [EMAIL PROTECTED] acpi]# cat /proc/acpi/processor/CPU0/throttling state count: 8 active state:T1 state available: T0 to T7 states: T0: 100% *T1: 87% T2: 75% T3: 62% T4: 50% T5: 37% T6: 25% T7: 12% [EMAIL PROTECTED] acpi]# echo 0 /proc/acpi/processor/CPU0/throttling [EMAIL PROTECTED] acpi]# cat /proc/acpi/processor/CPU0/throttling state count: 8 active state:T0 state available: T0 to T7 states: *T0: 100% T1: 87% T2: 75% T3: 62% T4: 50% T5: 37% T6: 25% T7: 12% [EMAIL PROTECTED] acpi]# cd / [EMAIL PROTECTED] /]# cat /proc/acpi/processor/CPU0/throttling state count: 8 active state:T0 state available: T0 to T7 states: *T0: 100% T1: 87% T2: 75% T3: 62% T4: 50% T5: 37% T6: 25% T7: 12% [EMAIL PROTECTED] /]# echo T0 /proc/acpi/processor/CPU0/throttling [EMAIL PROTECTED] /]# cat /proc/acpi/processor/CPU0/throttling state count: 8 active state:T0 state available: T0 to T7 states: *T0: 100% T1: 87% T2: 75% T3: 62% T4: 50% T5: 37% T6: 25% T7: 12% [EMAIL PROTECTED] /]# echo T7 /proc/acpi/processor/CPU0/throttling [EMAIL PROTECTED] /]# cat /proc/acpi/processor/CPU0/throttling state count: 8 active state:T0 state available: T0 to T7 states: *T0: 100% T1: 87% T2: 75% T3: 62% T4: 50% T5: 37% T6: 25% T7: 12% [EMAIL PROTECTED] /]# echo T100 /proc/acpi/processor/CPU0/throttling [EMAIL PROTECTED] /]# cat /proc/acpi/processor/CPU0/throttling state count: 8 active state:T0 state available: T0 to T7 states: *T0: 100% T1: 87% T2: 75% T3: 62% T4: 50% T5: 37% T6: 25% T7: 12% [EMAIL PROTECTED] /]# echo xxx /proc/acpi/processor/CPU0/throttling [EMAIL PROTECTED] /]# cat /proc/acpi/processor/CPU0/throttling state count: 8 active state:T0 state available: T0 to T7 states: *T0: 100% T1: 87% T2: 75% T3: 62% T4: 50% T5: 37% T6: 25% T7: 12% [EMAIL PROTECTED] /]# echo 2 /proc/acpi/processor/CPU0/throttling [EMAIL PROTECTED] /]# cat /proc/acpi/processor/CPU0/throttling state count: 8 active state:T2 state available: T0 to T7 states: T0: 100% T1: 87% *T2: 75% T3: 62% T4: 50% T5: 37% T6: 25% T7: 12% [EMAIL PROTECTED] /]# echo /proc/acpi/processor/CPU0/throttling [EMAIL PROTECTED] /]# cat /proc/acpi/processor/CPU0/throttling state count: 8 active state:T0 state available: T0 to T7 states: *T0: 100% T1: 87% T2:
