Re: ACPI: Always return valid 'status' from acpi_battery_get_property()
Thanks, Alex. Roland Dreier wrote: If a battery is at a critical charge level and not being charged or discharged, then the ACPI _BST method will return a state of 4, and the current acpi_battery_get_property() code will not set any property value for POWER_SUPPLY_PROP_STATUS. This will cause an oops in power_supply_show_property() when it reads off the end of the status_text array. This actually was causing a 100% reproducible crash on boot on my laptop with two batteries, when one battery was completely drained and the laptop was not plugged in. Fix this by making sure acpi_battery_get_property() returns POWER_SUPPLY_STATUS_UNKNOWN for any battery state it doesn't already handle explicitly. There doesn't seem to be any status enum value defined that makes more sense than 'unknown' for a battery at a critical charge level. Signed-off-by: Roland Dreier [EMAIL PROTECTED] Acked-by: Alexey Starikovskiy [EMAIL PROTECTED] --- diff --git a/drivers/acpi/battery.c b/drivers/acpi/battery.c index c2ce0ad..cbb27b4 100644 --- a/drivers/acpi/battery.c +++ b/drivers/acpi/battery.c @@ -152,6 +152,8 @@ static int acpi_battery_get_property(struct power_supply *psy, val-intval = POWER_SUPPLY_STATUS_CHARGING; else if (battery-state == 0) val-intval = POWER_SUPPLY_STATUS_FULL; + else + val-intval = POWER_SUPPLY_STATUS_UNKNOWN; break; case POWER_SUPPLY_PROP_PRESENT: val-intval = acpi_battery_present(battery); - 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.24-rc2 (esthetic?) regression: auto select interrupt spams my logs
Hi Romano, EC was changed to automatically choose it's working mode (poll vs. interrupt driven). You see it oscillating between modes because it receives interrupts just after it stops waiting for them. Please open new bug entry at bugzilla.kernel.org. Your .config might be usefull. Thanks, Alex. Romano Giannetti wrote: Hi, After the ACPI changes between 2.6.24-rc1 and -rc2 I have my logs spammed (every 2-3 seconds) by: [ 423.112903] ACPI: EC: missing IBF_1 confirmations,switch off interrupt mode. [ 423.113020] ACPI: EC: non-query interrupt received, switching to interrupt mode [ 426.078972] ACPI: EC: missing IBF_1 confirmations,switch off interrupt mode. [ 426.079645] ACPI: EC: non-query interrupt received, switching to interrupt mode [ 426.622773] ACPI: EC: missing IBF_1 confirmations,switch off interrupt mode. [ 426.622889] ACPI: EC: non-query interrupt received, switching to interrupt mode It seems that no harm is done, apart (but it could be another thing) that gnome-panel is much slower on startup. Romano - 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.24-rc2 (esthetic?) regression: auto select interrupt spams my logs
On Thu, 2007-11-08 at 14:52 +0300, Alexey Starikovskiy wrote: Please open new bug entry at bugzilla.kernel.org. Your .config might be usefull. Done, http://bugzilla.kernel.org/show_bug.cgi?id=9327 Romano -- Sorry for the disclaimer --- ¡I cannot stop it! -- La presente comunicación tiene carácter confidencial y es para el exclusivo uso del destinatario indicado en la misma. Si Ud. no es el destinatario indicado, le informamos que cualquier forma de distribución, reproducción o uso de esta comunicación y/o de la información contenida en la misma están estrictamente prohibidos por la ley. Si Ud. ha recibido esta comunicación por error, por favor, notifíquelo inmediatamente al remitente contestando a este mensaje y proceda a continuación a destruirlo. Gracias por su colaboración. This communication contains confidential information. It is for the exclusive use of the intended addressee. If you are not the intended addressee, please note that any form of distribution, copying or use of this communication or the information in it is strictly prohibited by law. If you have received this communication in error, please immediately notify the sender by reply e-mail and destroy this message. Thank you for your cooperation. - 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.24-rc2 (esthetic?) regression: auto select interrupt spams my logs
Hi, After the ACPI changes between 2.6.24-rc1 and -rc2 I have my logs spammed (every 2-3 seconds) by: [ 423.112903] ACPI: EC: missing IBF_1 confirmations,switch off interrupt mode. [ 423.113020] ACPI: EC: non-query interrupt received, switching to interrupt mode [ 426.078972] ACPI: EC: missing IBF_1 confirmations,switch off interrupt mode. [ 426.079645] ACPI: EC: non-query interrupt received, switching to interrupt mode [ 426.622773] ACPI: EC: missing IBF_1 confirmations,switch off interrupt mode. [ 426.622889] ACPI: EC: non-query interrupt received, switching to interrupt mode It seems that no harm is done, apart (but it could be another thing) that gnome-panel is much slower on startup. Romano -- Sorry for the disclaimer --- ¡I cannot stop it! -- La presente comunicación tiene carácter confidencial y es para el exclusivo uso del destinatario indicado en la misma. Si Ud. no es el destinatario indicado, le informamos que cualquier forma de distribución, reproducción o uso de esta comunicación y/o de la información contenida en la misma están estrictamente prohibidos por la ley. Si Ud. ha recibido esta comunicación por error, por favor, notifíquelo inmediatamente al remitente contestando a este mensaje y proceda a continuación a destruirlo. Gracias por su colaboración. This communication contains confidential information. It is for the exclusive use of the intended addressee. If you are not the intended addressee, please note that any form of distribution, copying or use of this communication or the information in it is strictly prohibited by law. If you have received this communication in error, please immediately notify the sender by reply e-mail and destroy this message. Thank you for your cooperation. - 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
Linux kernel asked me tou send you ...
Quoting kernel: ACPI: System BIOS is requesting _OSI(Linux) ACPI: Please test with acpi_osi=!Linux Please send dmidecode to linux-acpi@vger.kernel.org ACPI: Interpreter enabled ACPI: Using IOAPIC for interrupt routing ACPI: PCI Root Bridge [PCI0] (:00) dmidecode attached. Thanks :) -- ___ / Geoffroy DESVERNAY |\ /\`Service info`| Tel: (+33|0)4 91 05 45 24 /\ \/ Ecole Centrale de Marseille | Fax: (+33|0)4 91 05 45 98 \/ \ (ex-EGIM)| Mail: [EMAIL PROTECTED] / --- # dmidecode 2.8 SMBIOS 2.3 present. 76 structures occupying 2729 bytes. Table at 0x000F0450. Handle 0xDA00, DMI type 218, 65 bytes OEM-specific Type Header and Data: DA 41 00 DA B2 00 17 0B 0E 38 00 00 80 00 80 01 00 02 80 02 80 01 00 00 A0 00 A0 01 00 58 00 58 00 01 00 59 00 59 00 01 00 75 01 75 01 01 00 76 01 76 01 01 00 05 80 05 80 01 00 FF FF 00 00 00 00 Handle 0xDA01, DMI type 218, 35 bytes OEM-specific Type Header and Data: DA 23 01 DA B2 00 17 0B 0E 38 00 10 F5 10 F5 00 00 11 F5 11 F5 00 00 12 F5 12 F5 00 00 FF FF 00 00 00 00 Handle 0x, DMI type 0, 24 bytes BIOS Information Vendor: Dell Inc. Version: 2.2.0 Release Date: 03/29/2007 Address: 0xF Runtime Size: 64 kB ROM Size: 1024 kB Characteristics: PCI is supported PNP is supported APM is supported BIOS is upgradeable BIOS shadowing is allowed Boot from CD is supported Selectable boot is supported EDD is supported Japanese floppy for Toshiba 1.2 MB is supported (int 13h) Print screen service is supported (int 5h) 8042 keyboard services are supported (int 9h) Serial services are supported (int 14h) Printer services are supported (int 17h) ACPI is supported USB legacy is supported LS-120 boot is supported BIOS boot specification is supported Function key-initiated network boot is supported Targeted content distribution is supported BIOS Revision: 2.2 Handle 0x0100, DMI type 1, 27 bytes System Information Manufacturer: Dell Inc. Product Name: OptiPlex 745 Version: Not Specified Serial Number: D3JBW2J UUID: 44454C4C-3300-104A-8042-C4C04F57324A Wake-up Type: APM Timer SKU Number: Not Specified Family: Not Specified Handle 0x0200, DMI type 2, 8 bytes Base Board Information Manufacturer: Dell Inc. Product Name: 0RF703 Version: Serial Number: ..CN1374072Q081U. Handle 0x0300, DMI type 3, 13 bytes Chassis Information Manufacturer: Dell Inc. Type: Mini Tower Lock: Not Present Version: Not Specified Serial Number: D3JBW2J Asset Tag: Boot-up State: Safe Power Supply State: Safe Thermal State: Safe Security Status: None Handle 0x0400, DMI type 4, 40 bytes Processor Information Socket Designation: Microprocessor Type: Central Processor Family: Pentium 4 Manufacturer: Intel ID: 65 0F 00 00 FF FB EB BF Signature: Type 0, Family 15, Model 6, Stepping 5 Flags: FPU (Floating-point unit on-chip) VME (Virtual mode extension) DE (Debugging extension) PSE (Page size extension) TSC (Time stamp counter) MSR (Model specific registers) PAE (Physical address extension) MCE (Machine check exception) CX8 (CMPXCHG8 instruction supported) APIC (On-chip APIC hardware supported) SEP (Fast system call) MTRR (Memory type range registers) PGE (Page global enable) MCA (Machine check architecture) CMOV (Conditional move instruction supported) PAT (Page attribute table) PSE-36 (36-bit page size extension) CLFSH (CLFLUSH instruction supported) DS (Debug store) ACPI (ACPI supported) MMX (MMX technology supported) FXSR (Fast floating-point save and restore) SSE (Streaming SIMD extensions) SSE2 (Streaming SIMD extensions 2) SS (Self-snoop) HTT (Hyper-threading technology) TM (Thermal monitor supported) PBE (Pending break enabled) Version: Not Specified Voltage: 1.8 V External Clock: 800 MHz Max Speed: 5200 MHz Current Speed: 3000 MHz Status: Populated, Enabled Upgrade: ZIF Socket L1 Cache Handle: 0x0700 L2 Cache Handle: 0x0701 L3 Cache Handle: Not Provided Serial Number: Not Specified Asset Tag: Not Specified Part Number: Not Specified Handle 0x0700, DMI type 7, 19 bytes Cache Information Socket Designation: Not Specified Configuration: Enabled, Not Socketed, Level 1 Operational Mode: Write Back Location: Internal Installed Size: 16 KB Maximum Size: 16 KB Supported SRAM Types: Other Installed SRAM Type: Other Speed: Unknown Error Correction Type: None System Type: Data Associativity: 8-way Set-associative Handle 0x0701, DMI type 7, 19 bytes Cache Information Socket Designation: Not Specified Configuration: Enabled, Not Socketed, Level 2 Operational Mode: Varies With Memory Address Location: Internal Installed
Re: 2.6.24-rc1: OOPS at acpi_battery_update
On Thursday, 8 of November 2007, Johannes Weiner wrote: Hi, is there any reason, why acpi_battery_get_property() should call acpi_battery_update() at all? Alex? - 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.24-rc1: OOPS at acpi_battery_update
Rafael J. Wysocki wrote: On Thursday, 8 of November 2007, Johannes Weiner wrote: Hi, is there any reason, why acpi_battery_get_property() should call acpi_battery_update() at all? Alex? If someone wants to read stale values, he could comment out acpi_battery_update. Regards, Alex. - 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.24-rc1: OOPS at acpi_battery_update
Hi, is there any reason, why acpi_battery_get_property() should call acpi_battery_update() at all? Hannes - 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: ACPI: Always return valid 'status' from acpi_battery_get_property()
On Thu, 08 Nov 2007, Alexey Starikovskiy wrote: handle explicitly. There doesn't seem to be any status enum value defined that makes more sense than 'unknown' for a battery at a critical charge level. Maybe one should be added? -- 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: libata: cdrw/dvdrom disabed after s2ram (2.6.24-rc2)
On Thu, 8 Nov 2007 13:02:56 -0500 Jeff Garzik [EMAIL PROTECTED] wrote: On Thu, Nov 08, 2007 at 09:49:58AM -0800, Andrew Morton wrote: On Thu, 08 Nov 2007 17:43:59 +0100 Roberto Oppedisano [EMAIL PROTECTED] wrote: Andrew Morton wrote, On 11/07/2007 09:13 PM: On Wed, 07 Nov 2007 15:15:07 +0100 Roberto Oppedisano [EMAIL PROTECTED] wrote: Hello. I noticed that after suspending to ram the DVD-ROM/CDRW drive in no more recognized on my laptop. Looking at dmesg after suspend i found: [5.313446] ata2.00: _GTF unexpected object type 0x1 [5.313453] ata2.00: ACPI on devcfg failed the second time, disabling (errno=-22) [5.313457] ata2.00: revalidation failed (errno=1) [5.313459] ata2.00: disabled Not sure when the bug was introduced or if it has been always been there (but I can investigate if needed). More details on request. Following dmesg pre and after suspend. Yes, it would be useful if you could work ot whether this worked OK in an earlier kernel, thanks. Hello Andrew. The bug has been recently added. I did a git-bisect, but the result is probably not completely useful, because many kernel did non build with my config, and I marked them as bad. Those build errors are bad. Please report them. They directly prevented you from finding the commit which caused this regression. The only way in which we'll stop people doing crap like this is to rub their noses (and the person who committed its nose) in it. Anyway here's the output of git-bisect: [EMAIL PROTECTED]:/usr/src/linux-2.6$ git bisect bad 99874d50481c093adfe74e796436024d88b6a48c is first bad commit commit 99874d50481c093adfe74e796436024d88b6a48c Author: Jens Axboe [EMAIL PROTECTED] Date: Fri Oct 12 12:50:41 2007 +0200 [BLOCK] Only include the compat ioctl code if CONFIG_BLOCK is set Add an extra CONFIG_BLOCK_COMPAT that we can use in the Makefile Signed-off-by: Jens Axboe [EMAIL PROTECTED] :04 04 f88b7b0e496edb8fbdd4bc74abd1a742a6a1d6d9 32ead3bd57b52a664cc8ccb662195041868d7632 M block ... If needed I can do further investigation, changing the assumption of efefc6eb38d43b8e5daef482f575d767b002004e to good and see if the bisect points to a different commit. Yes, it'll be some other commit. Sorry. It would help you (and me) if an ata developer could pay some attention. Rafael, please track this as an ata regression. We unfortunately need to bounce this ACPI people. We recently turned on ACPI by default in libata, which INTRODUCES the ability of the BIOS to pass random, unknown-quality ATA commands to the device. I highly expect some breakage related to this... if ACPI folks determine it is not an ACPI bug, then its a firmware bug and we will have to avoid that firmware on that platform. Set module option noacpi to 1, to disable ACPI and see if that fixes the problem. This will be a common diagnosis and workaround, FWIW... I suspect it wold be best to disable the feature for the 2.6.24 release, then reenable it afterwards and keep doing this until the code is sufficiently stable. - 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.24-rc1: OOPS at acpi_battery_update
Rafael J. Wysocki wrote:
On Thursday, 8 of November 2007, Johannes Weiner wrote:
Hi,
is there any reason, why acpi_battery_get_property() should call
acpi_battery_update() at all?
Alex?
Do you mean why should it call _whole_ battery update? ?
get_state should be sufficient in order to not get stale data.
Regards,
Alex.
ACPI: Battery: remove cycle from battery removal.
From: Alexey Starikovskiy [EMAIL PROTECTED]
get_property() should not call battery_update() on absent battery to
avoid cycle and oops.
Signed-off-by: Alexey Starikovskiy [EMAIL PROTECTED]
Tested-by: Rolf Eike Beer [EMAIL PROTECTED]
---
drivers/acpi/battery.c | 10 ++
1 files changed, 6 insertions(+), 4 deletions(-)
diff --git a/drivers/acpi/battery.c b/drivers/acpi/battery.c
index c2ce0ad..192c244 100644
--- a/drivers/acpi/battery.c
+++ b/drivers/acpi/battery.c
@@ -132,7 +132,7 @@ static int acpi_battery_technology(struct acpi_battery *battery)
return POWER_SUPPLY_TECHNOLOGY_UNKNOWN;
}
-static int acpi_battery_update(struct acpi_battery *battery);
+static int acpi_battery_get_state(struct acpi_battery *battery);
static int acpi_battery_get_property(struct power_supply *psy,
enum power_supply_property psp,
@@ -140,10 +140,11 @@ static int acpi_battery_get_property(struct power_supply *psy,
{
struct acpi_battery *battery = to_acpi_battery(psy);
- if ((!acpi_battery_present(battery))
- psp != POWER_SUPPLY_PROP_PRESENT)
+ if (acpi_battery_present(battery)) {
+ /* run battery update only if it is present */
+ acpi_battery_get_state(battery);
+ } else if (psp != POWER_SUPPLY_PROP_PRESENT)
return -ENODEV;
- acpi_battery_update(battery);
switch (psp) {
case POWER_SUPPLY_PROP_STATUS:
if (battery-state 0x01)
@@ -457,6 +458,7 @@ static void sysfs_remove_battery(struct acpi_battery *battery)
return;
device_remove_file(battery-bat.dev, alarm_attr);
power_supply_unregister(battery-bat);
+ battery-bat.dev = NULL;
}
static int acpi_battery_update(struct acpi_battery *battery)
Re: libata: cdrw/dvdrom disabed after s2ram (2.6.24-rc2)
On Thu, Nov 08, 2007 at 10:13:41AM -0800, Andrew Morton wrote: I suspect it wold be best to disable the feature for the 2.6.24 release, then reenable it afterwards and keep doing this until the code is sufficiently stable. GTF method execution failure currently looks like it's fatal, when it probably shouldn't be. I'll send a patch shortly. -- Matthew Garrett | [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
Re: 2.6.24-rc1: OOPS at acpi_battery_update
Hi, On Thu, Nov 08, 2007 at 07:11:53PM +0300, Alexey Starikovskiy wrote: Rafael J. Wysocki wrote: On Thursday, 8 of November 2007, Johannes Weiner wrote: Hi, is there any reason, why acpi_battery_get_property() should call acpi_battery_update() at all? Alex? If someone wants to read stale values, he could comment out acpi_battery_update. Please help me to understand: When the battery is plugged in, the acpi_battery_notify() is called, which in turn calls acpi_battery_update(). The latter ensures that the sysfs files are created if not yet present. When the battery is removed, acpi_battery_notify is called, which in turn calls acpi_battery_update(). The latter ensures that the sysfs files are removed if present. During runtime - as far as I understood - no sysfs files have to be created/removed but the saved battery state info becomes stale. So, would it be enough to call acpi_battery_get_state() in acpi_battery_get_property() instead of acpi_battery_update()? If acpi_battery_get_state() does what I think it does, this would ensure that the battery state is reread and updated when acpi_battery_get_property() is called. Hit me. Hannes - 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.24-rc1: OOPS at acpi_battery_update
Hi Alex, On Thu, Nov 08, 2007 at 07:35:23PM +0300, Alexey Starikovskiy wrote: Rafael J. Wysocki wrote: On Thursday, 8 of November 2007, Johannes Weiner wrote: Hi, is there any reason, why acpi_battery_get_property() should call acpi_battery_update() at all? Alex? Do you mean why should it call _whole_ battery update? ? get_state should be sufficient in order to not get stale data. Okay, than I understood it correct. Acked-by: Johannes Weiner [EMAIL PROTECTED] Thanks! Hannes - 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 0/3] Suspend and hibernation test facility (rev. 2)
Hi, This series of patches adds a new testing facility for suspend and hibernation. The first patch adds the possibility to test the suspend (STD) core code without actually suspending, which is useful for tracking problems with drivers etc. The second one modifies the hibernation core so that it can use the same facility (it's a bit more powerful than the existing hibernation test modes, since they really can't test the ACPI global methods). The third one modified documentation in accordance with the two previous ones. Please add to the suspend branch. Greetings, 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
[PATCH 1/3] Suspend: Testing facility (rev. 2)
From: Rafael J. Wysocki [EMAIL PROTECTED]
Introduce sysfs attribute /sys/power/pm_test allowing one to test the suspend
core code. Namely, writing one of the strings:
freezer
devices
platform
processors
core
to this file causes the suspend code to work in one of the test modes defined as
follows:
freezer
- test the freezing of processes
devices
- test the freezing of processes and suspending of devices
platform
- test the freezing of processes, suspending of devices and platform global
control methods(*)
processors
- test the freezing of processes, suspending of devices, platform global
control methods and the disabling of nonboot CPUs
core
- test the freezing of processes, suspending of devices, platform global
control methods, the disabling of nonboot CPUs and suspending of
platform/system devices
(*) These are ACPI global control methods on ACPI systems
Then, if a suspend is started by normal means, the suspend core will perform
its normal operations up to the point indicated by given test level. Next, it
will wait for 5 seconds and carry out the resume operations needed to transition
the system back to the fully functional state.
Writing none to /sys/power/pm_test turns the testing off.
When open for reading, /sys/power/pm_test contains a space-separated list of all
available tests (including none that represents the normal functionality) in
which the current test level is indicated by square brackets.
Signed-off-by: Rafael J. Wysocki [EMAIL PROTECTED]
Acked-by: Pavel Machek [EMAIL PROTECTED]
---
kernel/power/main.c | 109 ++-
kernel/power/power.h | 18
2 files changed, 118 insertions(+), 9 deletions(-)
Index: linux-2.6/kernel/power/main.c
===
--- linux-2.6.orig/kernel/power/main.c
+++ linux-2.6/kernel/power/main.c
@@ -28,6 +28,80 @@ BLOCKING_NOTIFIER_HEAD(pm_chain_head);
DEFINE_MUTEX(pm_mutex);
+#ifdef CONFIG_PM_DEBUG
+int pm_test_level = TEST_NONE;
+
+static int suspend_test(int level)
+{
+ if (pm_test_level == level) {
+ printk(KERN_INFO suspend debug: Waiting for 5 seconds.\n);
+ mdelay(5000);
+ return 1;
+ }
+ return 0;
+}
+
+static const char * const pm_tests[__TEST_AFTER_LAST] = {
+ [TEST_NONE] = none,
+ [TEST_CORE] = core,
+ [TEST_CPUS] = processors,
+ [TEST_PLATFORM] = platform,
+ [TEST_DEVICES] = devices,
+ [TEST_FREEZER] = freezer,
+};
+
+static ssize_t pm_test_show(struct kset *kset, char *buf)
+{
+ char *s = buf;
+ int level;
+
+ for (level = TEST_FIRST; level = TEST_MAX; level++)
+ if (pm_tests[level]) {
+ if (level == pm_test_level)
+ s += sprintf(s, [%s] , pm_tests[level]);
+ else
+ s += sprintf(s, %s , pm_tests[level]);
+ }
+
+ if (s != buf)
+ /* convert the last space to a newline */
+ *(s-1) = '\n';
+
+ return (s - buf);
+}
+
+static ssize_t pm_test_store(struct kset *kset, const char *buf, size_t n)
+{
+ const char * const *s;
+ int level;
+ char *p;
+ int len;
+ int error = -EINVAL;
+
+ p = memchr(buf, '\n', n);
+ len = p ? p - buf : n;
+
+ mutex_lock(pm_mutex);
+
+ level = TEST_FIRST;
+ for (s = pm_tests[level]; level = TEST_MAX; s++, level++)
+ if (*s len == strlen(*s) !strncmp(buf, *s, len)) {
+ pm_test_level = level;
+ error = 0;
+ break;
+ }
+
+ mutex_unlock(pm_mutex);
+
+ return error ? error : n;
+}
+
+power_attr(pm_test);
+#else /* !CONFIG_PM_DEBUG */
+static inline int suspend_test(int level) { return 0; }
+#endif /* !CONFIG_PM_DEBUG */
+
+
#ifdef CONFIG_SUSPEND
/* This is just an arbitrary number */
@@ -133,7 +207,10 @@ static int suspend_enter(suspend_state_t
printk(KERN_ERR Some devices failed to power down\n);
goto Done;
}
- error = suspend_ops-enter(state);
+
+ if (!suspend_test(TEST_CORE))
+ error = suspend_ops-enter(state);
+
device_power_up();
Done:
arch_suspend_enable_irqs();
@@ -164,16 +241,25 @@ int suspend_devices_and_enter(suspend_st
printk(KERN_ERR Some devices failed to suspend\n);
goto Resume_console;
}
+
+ if (suspend_test(TEST_DEVICES))
+ goto Resume_devices;
+
if (suspend_ops-prepare) {
error = suspend_ops-prepare();
if (error)
goto Resume_devices;
}
+
+ if (suspend_test(TEST_PLATFORM))
+ goto Finish;
+
error = disable_nonboot_cpus();
- if (!error)
+ if (!error !suspend_test(TEST_CPUS))
Re: *New* HP dv6000 series backlight driver.
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hello all, After getting more into it, I've added support to some more stuff on the HP dv6500 laptops. SUPORTED DEVICES: * This is known to work on the dv6535ep (I think it may work on other dv6500 models): - CPU Temperature reading. - Backlight driver (hotkeys not working, yet). - LID status. - WIFI button status. I've uploaded the driver and some information to my personal server (very bandwidth limited): http://miknix.homelinux.com/dv6k_laptop/ I hope other HP dv6500 users like it :) - -- Angelo Arrifano AKA MiKNiX CSE Student at UBI, Portugal Gentoo Linux AMD64 Arch Tester [EMAIL PROTECTED] http://miknix.homelinux.com PGP Pubkey online - - - Why won't you let me kiss you goodnight? Is it something I said? -- Tom Ryan -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.7 (GNU/Linux) iD8DBQFHM18/NahyoD2SuwsRAvFrAKCJ6a9q07hDneUK4ifPmqr2g20DFgCdFWvY od9gzT7RJG8QNsuzCrh047Q= =oXKG -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: libata: cdrw/dvdrom disabed after s2ram (2.6.24-rc2)
On Thu, 8 Nov 2007 13:19:05 -0500 Jeff Garzik [EMAIL PROTECTED] wrote: On Thu, Nov 08, 2007 at 10:13:41AM -0800, Andrew Morton wrote: On Thu, 8 Nov 2007 13:02:56 -0500 Jeff Garzik [EMAIL PROTECTED] wrote: On Thu, Nov 08, 2007 at 09:49:58AM -0800, Andrew Morton wrote: On Thu, 08 Nov 2007 17:43:59 +0100 Roberto Oppedisano [EMAIL PROTECTED] wrote: Andrew Morton wrote, On 11/07/2007 09:13 PM: On Wed, 07 Nov 2007 15:15:07 +0100 Roberto Oppedisano [EMAIL PROTECTED] wrote: Hello. I noticed that after suspending to ram the DVD-ROM/CDRW drive in no more recognized on my laptop. Looking at dmesg after suspend i found: [5.313446] ata2.00: _GTF unexpected object type 0x1 [5.313453] ata2.00: ACPI on devcfg failed the second time, disabling (errno=-22) [5.313457] ata2.00: revalidation failed (errno=1) [5.313459] ata2.00: disabled Not sure when the bug was introduced or if it has been always been there (but I can investigate if needed). More details on request. Following dmesg pre and after suspend. Yes, it would be useful if you could work ot whether this worked OK in an earlier kernel, thanks. Hello Andrew. The bug has been recently added. I did a git-bisect, but the result is probably not completely useful, because many kernel did non build with my config, and I marked them as bad. Those build errors are bad. Please report them. They directly prevented you from finding the commit which caused this regression. The only way in which we'll stop people doing crap like this is to rub their noses (and the person who committed its nose) in it. Anyway here's the output of git-bisect: [EMAIL PROTECTED]:/usr/src/linux-2.6$ git bisect bad 99874d50481c093adfe74e796436024d88b6a48c is first bad commit commit 99874d50481c093adfe74e796436024d88b6a48c Author: Jens Axboe [EMAIL PROTECTED] Date: Fri Oct 12 12:50:41 2007 +0200 [BLOCK] Only include the compat ioctl code if CONFIG_BLOCK is set Add an extra CONFIG_BLOCK_COMPAT that we can use in the Makefile Signed-off-by: Jens Axboe [EMAIL PROTECTED] :04 04 f88b7b0e496edb8fbdd4bc74abd1a742a6a1d6d9 32ead3bd57b52a664cc8ccb662195041868d7632 M block ... If needed I can do further investigation, changing the assumption of efefc6eb38d43b8e5daef482f575d767b002004e to good and see if the bisect points to a different commit. Yes, it'll be some other commit. Sorry. It would help you (and me) if an ata developer could pay some attention. Rafael, please track this as an ata regression. We unfortunately need to bounce this ACPI people. We recently turned on ACPI by default in libata, which INTRODUCES the ability of the BIOS to pass random, unknown-quality ATA commands to the device. I highly expect some breakage related to this... if ACPI folks determine it is not an ACPI bug, then its a firmware bug and we will have to avoid that firmware on that platform. Set module option noacpi to 1, to disable ACPI and see if that fixes the problem. This will be a common diagnosis and workaround, FWIW... I suspect it wold be best to disable the feature for the 2.6.24 release, then reenable it afterwards and keep doing this until the code is sufficiently stable. Re-read my message :) The code is stable. Behavior _by definition_ will vary by BIOS. This feature (a) enables suspend/resume, but (b) now sends random unvalidated shite to the device that we hope will work. Look at all the messages where turning on ACPI in libata _fixed_ suspend/resume (because its obviously required for many, including laptops). We fixed a somewhat-known number of machines and broke an unknown number. Linus will come after you with a pointy stick if he finds out. Fixing previously-broken machines is nice, but breaking previously-working ones gets people a lot more upset. So it's not an easy turn it off answer, you break shitloads of suspend/resume that way, that we just fixed. The message _GTF unexpected object type indicates a broken BIOS, so IMO we should proceed in that direction, blacklisting that platform. Suggest that the feature be disabled until we have most of these blacklistings in place. We have a tremendous number of regressions in 2.6.24 (and they're just the ones which we know of) and the regression reports for 2.6.23 are still coming in. At some stage we'll need to get seriosu about this. - 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] Don't fail ata device revalidation for bad _GTF methods
Experience suggests that the _GTF method may be bad. We currently fail
device revalidation in that case, which seems excessive.
Signed-off-by: Matthew Garrett [EMAIL PROTECTED]
---
diff --git a/drivers/ata/libata-acpi.c b/drivers/ata/libata-acpi.c
index 08a52dd..545ea86 100644
--- a/drivers/ata/libata-acpi.c
+++ b/drivers/ata/libata-acpi.c
@@ -312,7 +312,7 @@ EXPORT_SYMBOL_GPL(ata_acpi_stm);
*
* RETURNS:
* Number of taskfiles on success, 0 if _GTF doesn't exist or doesn't
- * contain valid data. -errno on other errors.
+ * contain valid data.
*/
static int ata_dev_get_GTF(struct ata_device *dev, struct ata_acpi_gtf **gtf,
void **ptr_to_free)
@@ -339,7 +339,6 @@ static int ata_dev_get_GTF(struct ata_device *dev, struct
ata_acpi_gtf **gtf,
ata_dev_printk(dev, KERN_WARNING,
_GTF evaluation failed (AE 0x%x)\n,
status);
- rc = -EIO;
}
goto out_free;
}
@@ -359,7 +358,6 @@ static int ata_dev_get_GTF(struct ata_device *dev, struct
ata_acpi_gtf **gtf,
ata_dev_printk(dev, KERN_WARNING,
_GTF unexpected object type 0x%x\n,
out_obj-type);
- rc = -EINVAL;
goto out_free;
}
@@ -367,7 +365,6 @@ static int ata_dev_get_GTF(struct ata_device *dev, struct
ata_acpi_gtf **gtf,
ata_dev_printk(dev, KERN_WARNING,
unexpected _GTF length (%d)\n,
out_obj-buffer.length);
- rc = -EINVAL;
goto out_free;
}
@@ -511,10 +508,7 @@ static int ata_acpi_exec_tfs(struct ata_device *dev)
int gtf_count, i, rc;
/* get taskfiles */
- rc = ata_dev_get_GTF(dev, gtf, ptr_to_free);
- if (rc 0)
- return rc;
- gtf_count = rc;
+ gtf_count = ata_dev_get_GTF(dev, gtf, ptr_to_free);
/* execute them */
for (i = 0, rc = 0; i gtf_count; i++) {
--
Matthew Garrett | [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
Re: libata: cdrw/dvdrom disabed after s2ram (2.6.24-rc2)
Andrew Morton wrote: On Thu, 8 Nov 2007 13:19:05 -0500 Jeff Garzik [EMAIL PROTECTED] wrote: On Thu, Nov 08, 2007 at 10:13:41AM -0800, Andrew Morton wrote: On Thu, 8 Nov 2007 13:02:56 -0500 Jeff Garzik [EMAIL PROTECTED] wrote: On Thu, Nov 08, 2007 at 09:49:58AM -0800, Andrew Morton wrote: .. I suspect it wold be best to disable the feature for the 2.6.24 release, then reenable it afterwards and keep doing this until the code is sufficiently stable. Re-read my message :) The code is stable. Behavior _by definition_ will vary by BIOS. This feature (a) enables suspend/resume, but (b) now sends random unvalidated shite to the device that we hope will work. Look at all the messages where turning on ACPI in libata _fixed_ suspend/resume (because its obviously required for many, including laptops). We fixed a somewhat-known number of machines and broke an unknown number. Linus will come after you with a pointy stick if he finds out. Fixing previously-broken machines is nice, but breaking previously-working ones gets people a lot more upset. So it's not an easy turn it off answer, you break shitloads of suspend/resume that way, that we just fixed. The message _GTF unexpected object type indicates a broken BIOS, so IMO we should proceed in that direction, blacklisting that platform. Suggest that the feature be disabled until we have most of these blacklistings in place. .. The problem is, this code has already sat out the last release, and nobody noticed problems exactly because it was not enabled before. If Jeff disables it again, then it will sit out another cycle without anybody exercising it. At some point, we need to turn it on, and collect information about where there are problems (and fix them). Tricky, 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
Re: libata: cdrw/dvdrom disabed after s2ram (2.6.24-rc2)
On Thu, 08 Nov 2007 14:49:33 -0500 Mark Lord [EMAIL PROTECTED] wrote: Andrew Morton wrote: On Thu, 8 Nov 2007 13:19:05 -0500 Jeff Garzik [EMAIL PROTECTED] wrote: On Thu, Nov 08, 2007 at 10:13:41AM -0800, Andrew Morton wrote: On Thu, 8 Nov 2007 13:02:56 -0500 Jeff Garzik [EMAIL PROTECTED] wrote: On Thu, Nov 08, 2007 at 09:49:58AM -0800, Andrew Morton wrote: .. I suspect it wold be best to disable the feature for the 2.6.24 release, then reenable it afterwards and keep doing this until the code is sufficiently stable. Re-read my message :) The code is stable. Behavior _by definition_ will vary by BIOS. This feature (a) enables suspend/resume, but (b) now sends random unvalidated shite to the device that we hope will work. Look at all the messages where turning on ACPI in libata _fixed_ suspend/resume (because its obviously required for many, including laptops). We fixed a somewhat-known number of machines and broke an unknown number. Linus will come after you with a pointy stick if he finds out. Fixing previously-broken machines is nice, but breaking previously-working ones gets people a lot more upset. So it's not an easy turn it off answer, you break shitloads of suspend/resume that way, that we just fixed. The message _GTF unexpected object type indicates a broken BIOS, so IMO we should proceed in that direction, blacklisting that platform. Suggest that the feature be disabled until we have most of these blacklistings in place. .. The problem is, this code has already sat out the last release, and nobody noticed problems exactly because it was not enabled before. If Jeff disables it again, then it will sit out another cycle without anybody exercising it. At some point, we need to turn it on, and collect information about where there are problems (and fix them). We get a decent amount of testing during the -rc's. I think it's OK to turn a feature on during -rc and off for release while it gets settled in. Hopefully Matthew's fix will address this particular problem. - 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
dmidecode request in kern.log
send to linux-acpi@vger.kernel.org [EMAIL PROTECTED]:~$ sudo dmidecode # dmidecode 2.9 SMBIOS 2.4 present. 22 structures occupying 1007 bytes. Table at 0x000DC010. Handle 0x, DMI type 0, 24 bytes BIOS Information Vendor: TOSHIBA Version: V1.40 Release Date: 04/26/2007 Address: 0xE59C0 Runtime Size: 108096 bytes ROM Size: 512 kB Characteristics: PCI is supported PC Card (PCMCIA) is supported PNP is supported BIOS is upgradeable BIOS shadowing is allowed Boot from CD is supported Selectable boot is supported Japanese floppy for Toshiba 1.2 MB is supported (int 13h) Print screen service is supported (int 5h) 8042 keyboard services are supported (int 9h) Serial services are supported (int 14h) Printer services are supported (int 17h) CGA/mono video services are supported (int 10h) ACPI is supported USB legacy is supported AGP is supported Smart battery is supported BIOS boot specification is supported Targeted content distribution is supported BIOS Revision: 1.64 Firmware Revision: 1.64 Handle 0x0001, DMI type 1, 27 bytes System Information Manufacturer: TOSHIBA Product Name: Satellite A200 Version: PSAE0C-AH308C Serial Number: 67481368K UUID: 174D3746-1B7F-11DC-8D90-001B38146262 Wake-up Type: Power Switch SKU Number: 012345678912345678912345678 Family: ABCDEFGHIJKLMNOPQRSTUVWXYZ Handle 0x0002, DMI type 2, 8 bytes Base Board Information Manufacturer: TOSHIBA Product Name: ISKAE Version: 1.00 Serial Number: 0123456789AB Handle 0x0003, DMI type 3, 17 bytes Chassis Information Manufacturer: TOSHIBA Type: Notebook 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: 0x1234 Handle 0x0004, DMI type 4, 35 bytes Processor Information Socket Designation: U2E1 Type: Central Processor Family: Other Manufacturer: Intel ID: EC 06 00 00 FF FB E9 BF Version: Genuine Intel(R) CPU T2 Voltage: 3.3 V External Clock: Unknown Max Speed: 2048 MHz Current Speed: 1730 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: 32 KB Maximum Size: 32 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: External Installed Size: 1024 KB Maximum Size: 512 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 8, 9 bytes Port Connector Information Internal Reference Designator: J35 Internal Connector Type: None External Reference Designator: Keyboard External Connector Type: Circular DIN-8 male Port Type: Keyboard Port Handle 0x0008, DMI type 8, 9 bytes Port Connector Information Internal Reference Designator: J36 Internal Connector Type: None External Reference Designator: PS/2 Mouse External Connector Type: Circular DIN-8 male Port Type: Keyboard Port Handle 0x0009, DMI type 9, 13 bytes System Slot Information Designation: TI7412 Type: 32-bit PCI Current Usage: Unknown Length: Long ID: 0 Characteristics: 5.0 V is provided 3.3 V is provided Handle 0x000A, DMI type 10, 6 bytes On Board Device Information Type: Sound Status: Disabled Description: HD-Audio Handle 0x000B, DMI type
[PATCH 3/3] PM: Suspend/hibernation debug documentation update (rev. 2)
From: Rafael J. Wysocki [EMAIL PROTECTED] Update the suspend/hibernation debugging and testing documentation to describe the newly introduced testing facilities. Signed-off-by: Rafael J. Wysocki [EMAIL PROTECTED] Acked-by: Pavel Machek [EMAIL PROTECTED] --- Documentation/power/basic-pm-debugging.txt | 212 + Documentation/power/drivers-testing.txt| 30 ++-- 2 files changed, 172 insertions(+), 70 deletions(-) Index: linux-2.6/Documentation/power/drivers-testing.txt === --- linux-2.6.orig/Documentation/power/drivers-testing.txt +++ linux-2.6/Documentation/power/drivers-testing.txt @@ -6,9 +6,9 @@ Testing suspend and resume support in de Unfortunately, to effectively test the support for the system-wide suspend and resume transitions in a driver, it is necessary to suspend and resume a fully functional system with this driver loaded. Moreover, that should be done -several times, preferably several times in a row, and separately for the suspend -to disk (STD) and the suspend to RAM (STR) transitions, because each of these -cases involves different ordering of operations and different interactions with +several times, preferably several times in a row, and separately for hibernation +(aka suspend to disk or STD) and suspend to RAM (STR), because each of these +cases involves slightly different operations and different interactions with the machine's BIOS. Of course, for this purpose the test system has to be known to suspend and @@ -22,20 +22,24 @@ for more information about the debugging Once you have resolved the suspend/resume-related problems with your test system without the new driver, you are ready to test it: -a) Build the driver as a module, load it and try the STD in the test mode (see: -Documents/power/basic-pm-debugging.txt, 1a)). +a) Build the driver as a module, load it and try the test modes of hibernation + (see: Documents/power/basic-pm-debugging.txt, 1). -b) Load the driver and attempt to suspend to disk in the reboot, shutdown -and platform modes (see: Documents/power/basic-pm-debugging.txt, 1). +b) Load the driver and attempt to hibernate in the reboot, shutdown and + platform modes (see: Documents/power/basic-pm-debugging.txt, 1). -c) Compile the driver directly into the kernel and try the STD in the test mode. +c) Compile the driver directly into the kernel and try the test modes of + hibernation. -d) Attempt to suspend to disk with the driver compiled directly into the kernel -in the reboot, shutdown and platform modes. +d) Attempt to hibernate with the driver compiled directly into the kernel + in the reboot, shutdown and platform modes. -e) Attempt to suspend to RAM using the s2ram tool with the driver loaded (see: -Documents/power/basic-pm-debugging.txt, 2). As far as the STR tests are -concerned, it should not matter whether or not the driver is built as a module. +e) Try the test modes of suspend (see: Documents/power/basic-pm-debugging.txt, + 2). [As far as the STR tests are concerned, it should not matter whether or + not the driver is built as a module.] + +f) Attempt to suspend to RAM using the s2ram tool with the driver loaded + (see: Documents/power/basic-pm-debugging.txt, 2). Each of the above tests should be repeated several times and the STD tests should be mixed with the STR tests. If any of them fails, the driver cannot be Index: linux-2.6/Documentation/power/basic-pm-debugging.txt === --- linux-2.6.orig/Documentation/power/basic-pm-debugging.txt +++ linux-2.6/Documentation/power/basic-pm-debugging.txt @@ -1,45 +1,111 @@ -Debugging suspend and resume +Debugging hibernation and suspend (C) 2007 Rafael J. Wysocki [EMAIL PROTECTED], GPL -1. Testing suspend to disk (STD) +1. Testing hibernation (aka suspend to disk or STD) -To verify that the STD works, you can try to suspend in the reboot mode: +To check if hibernation works, you can try to hibernate in the reboot mode: # echo reboot /sys/power/disk # echo disk /sys/power/state -and the system should suspend, reboot, resume and get back to the command prompt -where you have started the transition. If that happens, the STD is most likely -to work correctly, but you need to repeat the test at least a couple of times in -a row for confidence. This is necessary, because some problems only show up on -a second attempt at suspending and resuming the system. You should also test -the platform and shutdown modes of suspend: +and the system should create a hibernation image, reboot, resume and get back to +the command prompt where you have started the transition. If that happens, +hibernation is most likely to work correctly. Still, you need to repeat the +test at least a couple of times in a row for confidence. [This is necessary, +because some problems only show up on a second attempt at
Re: 2.6.24-rc1: OOPS at acpi_battery_update
A On Thu, 08 Nov 2007 19:35:23 +0300 Alexey Starikovskiy [EMAIL PROTECTED] wrote: [remove_cycle_at_battery_removal.patch text/x-patch (1.7KB)] ACPI: Battery: remove cycle from battery removal. From: Alexey Starikovskiy [EMAIL PROTECTED] get_property() should not call battery_update() on absent battery to avoid cycle and oops. Signed-off-by: Alexey Starikovskiy [EMAIL PROTECTED] Tested-by: Rolf Eike Beer [EMAIL PROTECTED] A patch similar to this one but with an identical changelog was merged into Len's tree on November 2. If it had been promptly merged into mainline then quite a lot of people's time would not have been wasted. - 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 patch] x86: acpi_pciprobe_dmi_table[] must be __devinitdata
This patch fixes the following section mismatches with CONFIG_HOTPLUG=n:
-- snip --
...
WARNING: vmlinux.o(.data+0x23640): Section mismatch: reference to
.init.text.20:can_skip_ioresource_align (between 'acpi_pciprobe_dmi_table' and
'pcibios_irq_mask')
WARNING: vmlinux.o(.data+0x2366c): Section mismatch: reference to
.init.text.20:can_skip_ioresource_align (between 'acpi_pciprobe_dmi_table' and
'pcibios_irq_mask')
WARNING: vmlinux.o(.data+0x23698): Section mismatch: reference to
.init.text.20:can_skip_ioresource_align (between 'acpi_pciprobe_dmi_table' and
'pcibios_irq_mask')
...
-- snip --
Signed-off-by: Adrian Bunk [EMAIL PROTECTED]
---
3225b3c19396e0e45f496dfe82e85ebc86951d91
diff --git a/arch/x86/pci/acpi.c b/arch/x86/pci/acpi.c
index 2d88f7c..a7536dc 100644
--- a/arch/x86/pci/acpi.c
+++ b/arch/x86/pci/acpi.c
@@ -13,7 +13,7 @@ static int __devinit can_skip_ioresource_align(const struct
dmi_system_id *d)
return 0;
}
-static struct dmi_system_id acpi_pciprobe_dmi_table[] = {
+static struct dmi_system_id acpi_pciprobe_dmi_table[] __devinitdata = {
/*
* Systems where PCI IO resource ISA alignment can be skipped
* when the ISA enable bit in the bridge control is not set
-
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 patch] x86_64: remove acpi_pci_link_exit()
acpi_pci_link_exit() is both unused and empty.
Signed-off-by: Adrian Bunk [EMAIL PROTECTED]
---
16d6853a1facb9bcb7a4bc19daad6d3b852cace3
diff --git a/arch/x86/kernel/acpi/sleep_64.c b/arch/x86/kernel/acpi/sleep_64.c
index 79475d2..da42de2 100644
--- a/arch/x86/kernel/acpi/sleep_64.c
+++ b/arch/x86/kernel/acpi/sleep_64.c
@@ -115,6 +115,3 @@ static int __init acpi_sleep_setup(char *str)
__setup(acpi_sleep=, acpi_sleep_setup);
-void acpi_pci_link_exit(void)
-{
-}
-
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
GPE handling
Bob Ming,
I'm working on adding wakeup GPE support at system runtime, this
capability can help us
Identify which device invokes a wakeup event at runtime, this is
required for runtime device
Power management.
Below is the ASL code. For example, _L0c, USB3 will send a wakeup GPE
and invoke
a notify. In the notify handler, OS will clear USB3's PCI PME status to
avoid wakeup
event flood. But in current code, acpi_ev_asynch_execute_gpe_method will
start an asynchronous
execution of notify and return soon. Just before the return,
acpi_ev_asynch_execute_gpe_method
will reenable GPE 0C. That means GPE is enabled before OS execute
notification handler and USB3's
PCI PME status is cleared, and cause GPE flood. Ideally, I think we
should delay GPE enable
of _L0c till notification handler is finished or simply the method _L0c
is really finished.
What do you think?
Thanks,
Shaohua
Method (_L0C, 0, NotSerialized)
{
Notify (\_SB.PCI0.USB3, 0x02)
}
Method (_L0D, 0, NotSerialized)
{
Notify (\_SB.PCI0.USB7, 0x02)
}
Method (_L0E, 0, NotSerialized)
{
Notify (\_SB.PCI0.USB4, 0x02)
}
-
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
