Re: Linux 2.6.24.1 - kernel does not boot; IRQ trouble?
On Feb 18, 2008 9:06 PM, Stephen Hemminger [EMAIL PROTECTED] wrote: On Mon, 18 Feb 2008 19:42:25 + (GMT) Chris Rankin [EMAIL PROTECTED] wrote: --- Stephen Hemminger [EMAIL PROTECTED] wrote: sysfs: duplicate filename 'bridge' can not be created WARNING: at fs/sysfs/dir.c:424 sysfs_add_one() Pid: 1, comm: swapper Not tainted 2.6.24.1 #1 [c0105020] show_trace_log_lvl+0x1a/0x2f [c0105990] show_trace+0x12/0x14 [c010613d] dump_stack+0x6c/0x72 [c01991bf] sysfs_add_one+0x57/0xbc [c0199e41] sysfs_create_link+0xc2/0x10d [c01bae9a] pci_bus_add_devices+0xbd/0x103 [c034016c] pci_legacy_init+0x56/0xe3 [c03274e1] kernel_init+0x157/0x2c3 [c0104c83] kernel_thread_helper+0x7/0x10 === pci :00:01.0: Error creating sysfs bridge symlink, continuing... sysfs: duplicate filename 'bridge' can not be created WARNING: at fs/sysfs/dir.c:424 sysfs_add_one() Pid: 1, comm: swapper Not tainted 2.6.24.1 #1 [c0105020] show_trace_log_lvl+0x1a/0x2f [c0105990] show_trace+0x12/0x14 [c010613d] dump_stack+0x6c/0x72 [c01991bf] sysfs_add_one+0x57/0xbc [c0199e41] sysfs_create_link+0xc2/0x10d [c01bae9a] pci_bus_add_devices+0xbd/0x103 [c01bae82] pci_bus_add_devices+0xa5/0x103 [c034016c] pci_legacy_init+0x56/0xe3 [c03274e1] kernel_init+0x157/0x2c3 [c0104c83] kernel_thread_helper+0x7/0x10 === I have a vague feeling that this was fixed, perhaps in 2.6.24.x? Never heard of this, what is the initialization script that causes this? Also do you have the SYSFS_DEPRECATED option configured? that caused issues with regular network drivers. Yes, SYSFS_DEPRECATED is enabled. And the init scripts are from Fedora 8. There was a bug (fixed in 2.6.24) that had to do with sysfs_create_link and SYSFS_DEPRECATED probably there is a similar problem with directories. Chris, could you enable CONFIG_DEBUG_KOBJECT=y, it might show what objects try to claim the same name. Thanks, Kay - 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: Problem with the Fn+F3 key. acpi problem ?
Thomas Renninger a écrit : On Sat, 2008-01-12 at 16:02 +0100, giggz wrote: Matthew Garrett a écrit : On Sat, Jan 12, 2008 at 01:33:38PM +0100, giggz wrote: What is the acpi video module ? If you have /proc/acpi/video, it's loaded. I don't have any /var/log/acpid.log it seems to be normal that I don't have any /var/log/acpid.log : according to the NEWS.debian.gz from acpid package : Starting with version 1.0.6 acpid uses syslog instead of its own logging mechanism. During the upgrade of this package the old log files and the logrotate configuration file are backed up to /var/backups/acpid-cruft.tar.gz and are removed from the filesystem. So if I understand I must look at the syslog and message...but I don't see anything in these two file... How can I increase the level of debugging ? You can download the latest SUSE live-CD, there acpi debug is compiled in. Or you have to compile a kernel yourself and enable CONFIG_ACPI_DEBUG=y When booted, unload polling ACPI drivers (to not pollute the logs): rmmod battery rmmod ac Increase ACPI debug level: echo 0x1F /sys/module/acpi/parameters/debug_level (or even: echo 0x21F /sys/module/acpi/parameters/debug_level) then hit the button and you should see some output. Interesting e.g. would be if a notification notify appears and is sent to a vendor specific device. In that case, try catting /proc/acpi/event and hit the button. On SUSE, instead of stopping acpid, you can use: acpi_listen to log acpi events. Ok Thx for the infos. I will try to test it as soon as possible with the SUSE live-cd Cheers, Guillaume Thomas - 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 - 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 5/5] ACPI: add DMI to enable OSI(Linux) on ThinkPad T61
On Mon, 2008-02-18 at 16:17 -0300, Henrique de Moraes Holschuh wrote: On Mon, 18 Feb 2008, Thomas Renninger wrote: The problem is that OSI is used by Windows to pass the exact Windows (not OS) version they are running, this function should be called WOSI. We of course want to run on the latest fix-ups here and should pass Windows 2006 (or whatever latest string there exists). IMO we need the same for Linux. We even have the advantage, that the string in LOSI(String) makes some sense, e.g. 2.6.24, so why not use LOSI(int, int, int) How the exact interface might look like I am not sure, just an idea. Looks quite a bad idea IMO. 2.6.24 means what? SuSE's? Mainline's? Debian's? At what patch level? With which user patches tacked on top? And at what level of userspace support (X.org can make a LOT of difference here)? So you think on next Lenovo pre-load we should compile a SLED10 SP2 into our kernel and let Lenovo BIOS fixups use it? E.g. we could use the default BCM/BQC/BCL brightness interface easily then, just a small if(SLED10_SP2) in the BIOS. A one-liner, it can only effect the very specific Lenovo models that are effected. This is much more appropriate then adding a backport, better say most dirty hack of the month (That's not your fault Henrique and by no means meant as an offence..., we both know about the ugliness of these BIOS workarounds) of ibm_acpi to 2.6.16! guessing brightness levels which has high risk to break other ThinkPads and even if not, you move all the QA (not much to do if embedded into such Linux/SUSE/kern_ver condition), and dirty hacks to the vendor...). Please let us not end up with hacks like SLED10 SP2, FEISTY or whatever weirdness and this will come if we ignore osi=linux or do not provide something else. We should make up something more robust and more Linux kernel appropriate and propagate it to the vendors. Thomas - 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 5/5] ACPI: add DMI to enable OSI(Linux) on ThinkPad T61
On Tue, 19 Feb 2008, Thomas Renninger wrote: Looks quite a bad idea IMO. 2.6.24 means what? SuSE's? Mainline's? Debian's? At what patch level? With which user patches tacked on top? And at what level of userspace support (X.org can make a LOT of difference here)? So you think on next Lenovo pre-load we should compile a SLED10 SP2 Huh?! No, I don't. I would walk away in disgust if we did it. OSI(SLED10 SP2) would be even worse than OSI(Linux) plus a OSwhatever(2.6.24), I think I can safely assume that we *all* agree on THAT one. into our kernel and let Lenovo BIOS fixups use it? E.g. we could use the default BCM/BQC/BCL brightness interface easily then, just a small AFAIK, there is no problem with the *ACPI* brightness firmware on ThinkPads. At all. Its only quirk is that you want to call _BCL at least once at driver load. Anyway, the whole backlight brightness stink is our (as in Linux kernel people, userspace people, distro people) doing. The laptop vendors, for once, had nothing to do with it. Also, for once, the ACPI 3.0 specification (when correctly implemented in the AML *and* ACPI OSI) does give us all we need to have it work properly in any way we see fit. Since the brightness issues have *nothing* to do with OSI(anything), let's leave it for another thread. Please let us not end up with hacks like ???SLED10 SP2, FEISTY or whatever weirdness and this will come if we ignore osi=linux or do not provide something else. We should make up something more robust and more Linux kernel appropriate and propagate it to the vendors. We all agree on that, Thomas. I am actually arguing for something *even* more fine-grained than a kernel version, but at the same time completely independent of kernel versions, so that if we backport something, or our userspace improves, we can stop (or start) advertising it through OSI() without messing with anything else. -- 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: 2.6.25-rc2-mm1 (x64 thermal build failure)
On Tue, 19 Feb 2008 16:55:02 +0100 Thomas Petazzoni wrote: Le Mon, 18 Feb 2008 04:13:40 -0800, Andrew Morton [EMAIL PROTECTED] a écrit : Option 3 wold be to add more #ifdef CONFIG_DMI lines around the place. How ugly would that get? Like the attached patch. #ifdef CONFIG_DMI everywhere :-( Does this patch apply to -mm? Seem like No. After converting it from mime(?) to ASCII and fixing one #if (change and to ) fixing patch rejects, it does build cleanly. --- ~Randy - 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-rc2-mm1 (x64 thermal build failure)
Le Mon, 18 Feb 2008 04:13:40 -0800,
Andrew Morton [EMAIL PROTECTED] a écrit :
Option 3 wold be to add more #ifdef CONFIG_DMI lines around the
place. How ugly would that get?
Like the attached patch. #ifdef CONFIG_DMI everywhere :-(
Sincerly,
Thomas
---
Turn CONFIG_DMI into a selectable option if EMBEDDED is defined, in
order to be able to remove the DMI table scanning code if it's not
needed, and then reduce the kernel code size.
The DMI code users are modified, so that they either depend on
CONFIG_DMI (for the drivers who really need DMI to work) or their
DMI-related code is enclosed in #ifdef CONFIG_DMI.
With CONFIG_DMI (i.e before) :
textdata bss dec hex filename
1076076 128656 98304 1303036 13e1fc vmlinux
Without CONFIG_DMI (i.e after) :
textdata bss dec hex filename
1068092 126308 98304 1292704 13b9a0 vmlinux
Result:
textdata bss dec hex filename
-7984 -2348 0 -10332 -285c vmlinux
The new option appears in Processor type and features, only when
CONFIG_EMBEDDED is defined.
This patch is part of the Linux Tiny project, and is based on previous
work done by Matt Mackall [EMAIL PROTECTED].
Signed-off-by: Thomas Petazzoni [EMAIL PROTECTED]
---
arch/x86/Kconfig | 13 ++---
arch/x86/kernel/acpi/boot.c|4 ++--
arch/x86/kernel/acpi/sleep_32.c|2 ++
arch/x86/kernel/apm_32.c |2 ++
arch/x86/kernel/cpu/cpufreq/acpi-cpufreq.c |4 ++--
arch/x86/kernel/cpu/cpufreq/powernow-k7.c |3 ++-
arch/x86/kernel/io_delay.c |2 ++
arch/x86/kernel/reboot.c |2 ++
arch/x86/kernel/tsc_32.c |2 ++
arch/x86/mach-generic/bigsmp.c |3 ++-
arch/x86/pci/acpi.c|2 ++
arch/x86/pci/common.c |2 ++
arch/x86/pci/fixup.c |5 -
arch/x86/pci/irq.c |2 ++
drivers/acpi/sleep/main.c |2 ++
drivers/ata/ahci.c |2 ++
drivers/ata/ata_piix.c |4
drivers/ata/pata_cs5530.c |2 ++
drivers/ata/pata_via.c |3 ++-
drivers/char/Kconfig |2 +-
drivers/hwmon/Kconfig |2 ++
drivers/hwmon/abituguru.c |2 --
drivers/i2c/busses/i2c-piix4.c |2 ++
drivers/ide/ide-acpi.c |3 +++
drivers/ide/pci/alim15x3.c |3 ++-
drivers/ide/pci/via82cxxx.c|3 ++-
drivers/input/keyboard/atkbd.c |4
drivers/input/misc/wistron_btns.c |2 ++
drivers/input/mouse/lifebook.c |5 +++--
drivers/input/mouse/synaptics.c|2 +-
drivers/leds/leds-clevo-mail.c |2 ++
drivers/misc/Kconfig |1 +
drivers/misc/acer-wmi.c| 14 --
drivers/misc/sony-laptop.c |4
drivers/net/via-rhine.c|2 ++
drivers/pnp/pnpbios/core.c |2 ++
drivers/pnp/quirks.c |2 ++
drivers/video/Kconfig |2 +-
include/linux/dmi.h|3 ++-
39 files changed, 96 insertions(+), 27 deletions(-)
Index: linux/arch/x86/Kconfig
===
--- linux.orig/arch/x86/Kconfig
+++ linux/arch/x86/Kconfig
@@ -90,9 +90,6 @@
config ARCH_MAY_HAVE_PC_FDC
def_bool y
-config DMI
- def_bool y
-
config RWSEM_GENERIC_SPINLOCK
def_bool !X86_XADD
@@ -433,6 +430,15 @@
# Mark as embedded because too many people got it wrong.
# The code disables itself when not needed.
+config DMI
+ default y
+ bool Enable DMI scanning if EMBEDDED
+ help
+ Enabled scanning of DMI to identify machine quirks. Say Y
+ here unless you have verified that your setup is not
+ affected by entries in the DMI blacklist. Required by PNP
+ BIOS code.
+
config GART_IOMMU
bool GART IOMMU support if EMBEDDED
default y
@@ -645,6 +651,7 @@
config I8K
tristate Dell laptop support
+ depends on DMI
---help---
This adds a driver to safely access the System Management Mode
of the CPU on the Dell Inspiron 8000. The System Management Mode
Index: linux/arch/x86/kernel/acpi/boot.c
===
--- linux.orig/arch/x86/kernel/acpi/boot.c
+++ linux/arch/x86/kernel/acpi/boot.c
@@ -900,7 +900,7 @@
return;
}
-#ifdef __i386__
+#if defined(__i386__) defined(CONFIG_DMI)
static int __init disable_acpi_irq(const struct dmi_system_id *d)
{
@@ -1121,7 +1121,7 @@
{}
};
-#endif /*
patch driver-core-pm-make-suspend_device-static.patch added to gregkh-2.6 tree
This is a note to let you know that I've just added the patch titled
Subject: Driver core: PM: Make suspend_device() static
to my gregkh-2.6 tree. Its filename is
driver-core-pm-make-suspend_device-static.patch
This tree can be found at
http://www.kernel.org/pub/linux/kernel/people/gregkh/gregkh-2.6/patches/
From [EMAIL PROTECTED] Sun Feb 3 14:03:13 2008
From: Adrian Bunk [EMAIL PROTECTED]
Date: Sun, 3 Feb 2008 22:55:18 +0100
Subject: Driver core: PM: Make suspend_device() static
To: Len Brown [EMAIL PROTECTED]
Cc: ACPI Devel Maling List linux-acpi@vger.kernel.org, Pavel Machek [EMAIL
PROTECTED], pm list [EMAIL PROTECTED], Greg KH [EMAIL PROTECTED], Adrian
Bunk [EMAIL PROTECTED]
Message-ID: [EMAIL PROTECTED]
Content-Disposition: inline
From: Adrian Bunk [EMAIL PROTECTED]
suspend_device() can become static.
Signed-off-by: Adrian Bunk [EMAIL PROTECTED]
Signed-off-by: Rafael J. Wysocki [EMAIL PROTECTED]
Signed-off-by: Greg Kroah-Hartman [EMAIL PROTECTED]
---
drivers/base/power/main.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- a/drivers/base/power/main.c
+++ b/drivers/base/power/main.c
@@ -415,7 +415,7 @@ EXPORT_SYMBOL_GPL(device_power_down);
* @dev: Device.
* @state: Power state device is entering.
*/
-int suspend_device(struct device *dev, pm_message_t state)
+static int suspend_device(struct device *dev, pm_message_t state)
{
int error = 0;
Patches currently in gregkh-2.6 which might be from [EMAIL PROTECTED] are
driver/driver-core-pm-make-suspend_device-static.patch
pci/pci-if-0-pci_assign_resource_fixed.patch
usb/usb-make-usb_storage_onetouch-available-with-pm.patch
usb/usb-g_printer-fix-empty-if-statement.patch
-
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
kernel output
Kernel message Feb 19 18:30:19 dell-8400 kernel: ACPI: BIOS _OSI(Linux) query ignored Feb 19 18:30:19 dell-8400 kernel: ACPI: DMI System Vendor: Dell Inc. Feb 19 18:30:19 dell-8400 kernel: ACPI: DMI Product Name: Dimension 8400 Feb 19 18:30:19 dell-8400 kernel: ACPI: DMI Product Version: Feb 19 18:30:19 dell-8400 kernel: ACPI: DMI Board Name: 0J3492 Feb 19 18:30:19 dell-8400 kernel: ACPI: DMI BIOS Vendor: Dell Inc. Feb 19 18:30:19 dell-8400 kernel: ACPI: DMI BIOS Date: 07/07/2006 Feb 19 18:30:19 dell-8400 kernel: ACPI: Please send DMI info above to linux-acpi@vger.kernel.org Feb 19 18:30:19 dell-8400 kernel: ACPI: If acpi_osi=Linux works better, please notify linux- after adding acpi_osi=Linux Feb 19 19:45:10 dell-8400 kernel: ACPI: BIOS _OSI(Linux) query honored via cmdline Feb 19 19:45:10 dell-8400 kernel: ACPI: DMI System Vendor: Dell Inc. Feb 19 19:45:11 dell-8400 kernel: ACPI: DMI Product Name: Dimension 8400 Feb 19 19:45:11 dell-8400 kernel: ACPI: DMI Product Version: Feb 19 19:45:11 dell-8400 kernel: ACPI: DMI Board Name: 0J3492 Feb 19 19:45:11 dell-8400 kernel: ACPI: DMI BIOS Vendor: Dell Inc. Feb 19 19:45:11 dell-8400 kernel: ACPI: DMI BIOS Date: 07/07/2006 Feb 19 19:45:11 dell-8400 kernel: ACPI: Please send DMI info above to linux-acpi@vger.kernel.org Hope this helps Lee - 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-rc2-mm1 (x64 thermal build failure)
Thomas Petazzoni wrote: Le Tue, 19 Feb 2008 09:41:47 -0800, Randy Dunlap [EMAIL PROTECTED] a écrit : Does this patch apply to -mm? Seem like No. No, it was generated against 2.6.25-rc2. After converting it from mime(?) to ASCII Probably due to my PGP-MIME signature. Will try to remember that I should disable it next time. and fixing one #if (change and to ) Oops. Fixed on my side too. fixing patch rejects, it does build cleanly. The rejects are probably due to the patch being applied to -mm. It applies fine on -rc here. Any opinion about whether the patch is clean ? Worth it ? It seems reasonable to me as long as the option depends on EMBEDDED, as it does. -- ~Randy - 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-rc2-mm1 (x64 thermal build failure)
Le Tue, 19 Feb 2008 09:41:47 -0800, Randy Dunlap [EMAIL PROTECTED] a écrit : Does this patch apply to -mm? Seem like No. No, it was generated against 2.6.25-rc2. After converting it from mime(?) to ASCII Probably due to my PGP-MIME signature. Will try to remember that I should disable it next time. and fixing one #if (change and to ) Oops. Fixed on my side too. fixing patch rejects, it does build cleanly. The rejects are probably due to the patch being applied to -mm. It applies fine on -rc here. Any opinion about whether the patch is clean ? Worth it ? Thanks for testing the patch, Thomas -- Thomas Petazzoni, Free Electrons Free Embedded Linux Training Materials on http://free-electrons.com/training (More than 1500 pages!) - 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] sony-laptop.c: fix off-by-one
This patch fixes an off-by-one spotted by the Coverity checker.
Signed-off-by: Adrian Bunk [EMAIL PROTECTED]
---
--- linux-2.6/drivers/misc/sony-laptop.c.old2008-02-20 00:26:21.0
+0200
+++ linux-2.6/drivers/misc/sony-laptop.c2008-02-20 00:26:38.0
+0200
@@ -314,9 +314,9 @@ static void sony_laptop_report_input_eve
kp.dev = jog_dev;
break;
default:
- if (event ARRAY_SIZE(sony_laptop_input_index)) {
+ if (event = ARRAY_SIZE(sony_laptop_input_index)) {
dprintk(sony_laptop_report_input_event, event not
known: %d\n, event);
break;
}
if (sony_laptop_input_index[event] != -1) {
-
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-rc2-mm1 (x64 thermal build failure)
On Tue, 19 Feb 2008 16:55:02 +0100 Thomas Petazzoni [EMAIL PROTECTED] wrote: Le Mon, 18 Feb 2008 04:13:40 -0800, Andrew Morton [EMAIL PROTECTED] a __crit : Option 3 wold be to add more #ifdef CONFIG_DMI lines around the place. How ugly would that get? Like the attached patch. #ifdef CONFIG_DMI everywhere :-( ug, sorry, if I'd realised it was like this I'd have said don't bother. Apart from the obvious problem, this means that people will keep breaking CONFIG_DMI=n all the time, because they will forget the ifdefs, and the number of people who test with CONFIG_DMI=n will be small. - 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] drivers/thermal/thermal.c: fix a check-after-use
This patch fixes a check-after-use spotted by the Coverity checker. Signed-off-by: Adrian Bunk [EMAIL PROTECTED] --- 570462ca4441d8d63dfd46efe6e5b2b1c251a611 diff --git a/drivers/thermal/thermal.c b/drivers/thermal/thermal.c index e782b3e..958654b 100644 --- a/drivers/thermal/thermal.c +++ b/drivers/thermal/thermal.c @@ -308,10 +308,10 @@ int thermal_zone_bind_cooling_device(struct thermal_zone_device *tz, struct thermal_cooling_device_instance *pos; int result; - if (trip = tz-trips || (trip 0 trip != THERMAL_TRIPS_NONE)) + if (!tz || !cdev) return -EINVAL; - if (!tz || !cdev) + if (trip = tz-trips || (trip 0 trip != THERMAL_TRIPS_NONE)) return -EINVAL; dev = - 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 patch] drivers/thermal/thermal.c: fix a check-after-use
On Wed, 2008-02-20 at 02:14 +0200, Adrian Bunk wrote: This patch fixes a check-after-use spotted by the Coverity checker. Signed-off-by: Adrian Bunk [EMAIL PROTECTED] --- 570462ca4441d8d63dfd46efe6e5b2b1c251a611 diff --git a/drivers/thermal/thermal.c b/drivers/thermal/thermal.c index e782b3e..958654b 100644 --- a/drivers/thermal/thermal.c +++ b/drivers/thermal/thermal.c @@ -308,10 +308,10 @@ int thermal_zone_bind_cooling_device(struct thermal_zone_device *tz, struct thermal_cooling_device_instance *pos; int result; - if (trip = tz-trips || (trip 0 trip != THERMAL_TRIPS_NONE)) + if (!tz || !cdev) return -EINVAL; - if (!tz || !cdev) + if (trip = tz-trips || (trip 0 trip != THERMAL_TRIPS_NONE)) return -EINVAL; How about: if (!tz || !cdev || trip = tz-trips || (trip 0 trip != THERMAL_TRIPS_NONE)) return -EINVAL; Cheers, Harvey - 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 patch] drivers/thermal/thermal.c: fix a check-after-use
On Tue, Feb 19, 2008 at 04:25:02PM -0800, Harvey Harrison wrote: On Wed, 2008-02-20 at 02:14 +0200, Adrian Bunk wrote: This patch fixes a check-after-use spotted by the Coverity checker. Signed-off-by: Adrian Bunk [EMAIL PROTECTED] --- 570462ca4441d8d63dfd46efe6e5b2b1c251a611 diff --git a/drivers/thermal/thermal.c b/drivers/thermal/thermal.c index e782b3e..958654b 100644 --- a/drivers/thermal/thermal.c +++ b/drivers/thermal/thermal.c @@ -308,10 +308,10 @@ int thermal_zone_bind_cooling_device(struct thermal_zone_device *tz, struct thermal_cooling_device_instance *pos; int result; - if (trip = tz-trips || (trip 0 trip != THERMAL_TRIPS_NONE)) + if (!tz || !cdev) return -EINVAL; - if (!tz || !cdev) + if (trip = tz-trips || (trip 0 trip != THERMAL_TRIPS_NONE)) return -EINVAL; How about: if (!tz || !cdev || trip = tz-trips || (trip 0 trip != THERMAL_TRIPS_NONE)) return -EINVAL; I have no strong opinion about it, but I'd consider your suggestion less readable. Cheers, Harvey cu Adrian -- Is there not promise of rain? Ling Tan asked suddenly out of the darkness. There had been need of rain for many days. Only a promise, Lao Er said. Pearl S. Buck - Dragon Seed - 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 2/2] asus-laptop add kill switch support
Thomas Renninger wrote : Hi, On Thu, 2008-02-07 at 19:06 +0100, Fabien Crespel wrote: Basically: - there is now a killswitch file in /sys/devices/platform/asus-laptop/ to report the KS status (read from HWRS) Not sure, but: Shouldn't this one register against a general kill-switch interface? E.g. include/linux/rfkill.h instead of starting an own interface... Thomas Hello, after looking at the rfkill interface, it doesn't seem to have the same purpose here : rfkill seems to be here to allow toggling radio frequency of devices in response to a key or another *software* generated event, while the killswitch sysfs file in my patch simply provides a way to read whether the *hardware* kill switch is ON (and not write or toggle anything, since it's completely out of software control). My intention when adding this interface was to allow userspace tools like Lapsus to know when WLAN/Bluetooth are completely *disabled* (and not simply off). I don't think the rfkill interface provides a way to know that, or I missed it..? if it doesn't, wouldn't it be interesting to add it? The rfkill interface seems interesting to support the Fn+F2 key though (WLAN/Bluetooth toggle), since currently it doesn't work on all models. - Fabien. - 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/2] Two important suspend/hibernation patches updated
Hi Len, New version of: * hibernate: handle DEBUG_PAGEALLOC (commit af7e61cc86a6d052a7eddcd777a8a87906ab5a35 in the suspend branch) * suspend: wakeup code in C (commit 280529bd8a01a6d7045658b322ba9a1cda793de2 in the test branch) follow. The first one doesn't contain the powerpc change included in the original hibernate: handle DEBUG_PAGEALLOC patch, that turned out to be harmful. I'd like it to go into 2.6.25, if possible. The second one addresses the following problem reports related to the original suspend: wakeup code in C patch: * http://lkml.org/lkml/2008/2/16/178 * http://lkml.org/lkml/2008/2/16/74 * http://marc.info/?l=linux-acpim=120313725501682w=4 * http://lkml.org/lkml/2008/2/19/263 It is considered as 2.6.26 material. Please replace the previous versions of these patches with the new ones. 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
[PATCH 1/2] Hibernation: Handle DEBUG_PAGEALLOC on x86
From: Rafael J. Wysocki [EMAIL PROTECTED]
Make hibernation work with CONFIG_DEBUG_PAGEALLOC set on x86, by
checking if the pages to be copied are marked as present in the
kernel mapping and temporarily marking them as present if that's not
the case. No functional modifications are introduced if
CONFIG_DEBUG_PAGEALLOC is unset.
Signed-off-by: Rafael J. Wysocki [EMAIL PROTECTED]
---
arch/x86/mm/pageattr.c | 19 ++-
include/linux/mm.h |6 ++
kernel/power/snapshot.c | 42 +-
3 files changed, 53 insertions(+), 14 deletions(-)
Index: linux-2.6/kernel/power/snapshot.c
===
--- linux-2.6.orig/kernel/power/snapshot.c
+++ linux-2.6/kernel/power/snapshot.c
@@ -875,8 +875,8 @@ static inline void *saveable_highmem_pag
#endif /* CONFIG_HIGHMEM */
/**
- * saveable - Determine whether a non-highmem page should be included in
- * the suspend image.
+ * saveable_page - Determine whether a non-highmem page should be included
+ * in the suspend image.
*
* We should save the page if it isn't Nosave, and is not in the range
* of pages statically defined as 'unsaveable', and it isn't a part of
@@ -897,7 +897,8 @@ static struct page *saveable_page(unsign
if (swsusp_page_is_forbidden(page) || swsusp_page_is_free(page))
return NULL;
- if (PageReserved(page) pfn_is_nosave(pfn))
+ if (PageReserved(page)
+(!kernel_page_present(page) || pfn_is_nosave(pfn)))
return NULL;
return page;
@@ -938,6 +939,25 @@ static inline void do_copy_page(long *ds
*dst++ = *src++;
}
+
+/**
+ * safe_copy_page - check if the page we are going to copy is marked as
+ * present in the kernel page tables (this always is the case if
+ * CONFIG_DEBUG_PAGEALLOC is not set and in that case
+ * kernel_page_present() always returns 'true').
+ */
+static void safe_copy_page(void *dst, struct page *s_page)
+{
+ if (kernel_page_present(s_page)) {
+ do_copy_page(dst, page_address(s_page));
+ } else {
+ kernel_map_pages(s_page, 1, 1);
+ do_copy_page(dst, page_address(s_page));
+ kernel_map_pages(s_page, 1, 0);
+ }
+}
+
+
#ifdef CONFIG_HIGHMEM
static inline struct page *
page_is_saveable(struct zone *zone, unsigned long pfn)
@@ -946,8 +966,7 @@ page_is_saveable(struct zone *zone, unsi
saveable_highmem_page(pfn) : saveable_page(pfn);
}
-static inline void
-copy_data_page(unsigned long dst_pfn, unsigned long src_pfn)
+static void copy_data_page(unsigned long dst_pfn, unsigned long src_pfn)
{
struct page *s_page, *d_page;
void *src, *dst;
@@ -961,29 +980,26 @@ copy_data_page(unsigned long dst_pfn, un
kunmap_atomic(src, KM_USER0);
kunmap_atomic(dst, KM_USER1);
} else {
- src = page_address(s_page);
if (PageHighMem(d_page)) {
/* Page pointed to by src may contain some kernel
* data modified by kmap_atomic()
*/
- do_copy_page(buffer, src);
+ safe_copy_page(buffer, s_page);
dst = kmap_atomic(pfn_to_page(dst_pfn), KM_USER0);
memcpy(dst, buffer, PAGE_SIZE);
kunmap_atomic(dst, KM_USER0);
} else {
- dst = page_address(d_page);
- do_copy_page(dst, src);
+ safe_copy_page(page_address(d_page), s_page);
}
}
}
#else
#define page_is_saveable(zone, pfn)saveable_page(pfn)
-static inline void
-copy_data_page(unsigned long dst_pfn, unsigned long src_pfn)
+static inline void copy_data_page(unsigned long dst_pfn, unsigned long src_pfn)
{
- do_copy_page(page_address(pfn_to_page(dst_pfn)),
- page_address(pfn_to_page(src_pfn)));
+ safe_copy_page(page_address(pfn_to_page(dst_pfn)),
+ pfn_to_page(src_pfn));
}
#endif /* CONFIG_HIGHMEM */
Index: linux-2.6/include/linux/mm.h
===
--- linux-2.6.orig/include/linux/mm.h
+++ linux-2.6/include/linux/mm.h
@@ -1171,12 +1171,18 @@ static inline void enable_debug_pageallo
{
debug_pagealloc_enabled = 1;
}
+#ifdef CONFIG_HIBERNATION
+extern bool kernel_page_present(struct page *page);
+#endif /* CONFIG_HIBERNATION */
#else
static inline void
kernel_map_pages(struct page *page, int numpages, int enable) {}
static inline void enable_debug_pagealloc(void)
{
}
+#ifdef CONFIG_HIBERNATION
+static inline bool kernel_page_present(struct page *page) { return true; }
+#endif /* CONFIG_HIBERNATION */
#endif
extern struct
[PATCH 2/2] Suspend: Wakeup code in C
From: Pavel Machek [EMAIL PROTECTED]
Move wakeup code to .c, so that video mode setting code can be shared
between boot and wakeup. Remove nasty assembly code in 64-bit case by
re-using trampoline code. Stack setup was fixed to clear high 16bits
of %esp, maybe that fixes some machines.
.c code sharing and morse code was done H. Peter Anvin, Sam Ravnborg
reviewed kbuild related stuff, and it seems okay to him. Rafael did
some cleanups.
[rjw:
* Made the patch stop breaking compilation on x86-32
* Added arch/x86/kernel/acpi/sleep.h
* Got rid of compiler warnings in arch/x86/kernel/acpi/sleep.c
* Fixed 32-bit compilation on x86-64 systems
* Added include/asm-x86/trampoline.h and fixed the non-SMP compilation
on 64-bit x86
* Removed arch/x86/kernel/acpi/sleep_32.c which was not used]
Signed-off-by: Pavel Machek [EMAIL PROTECTED]
Signed-off-by: H. Peter Anvin [EMAIL PROTECTED]
Reviewed-by: Sam Ravnborg [EMAIL PROTECTED]
Signed-off-by: Rafael J. Wysocki [EMAIL PROTECTED]
---
arch/x86/Kconfig |2
arch/x86/boot/Makefile |2
arch/x86/boot/boot.h |5
arch/x86/boot/video-bios.c |6
arch/x86/boot/video-mode.c | 173
arch/x86/boot/video-vesa.c |8
arch/x86/boot/video-vga.c | 12 -
arch/x86/boot/video.c | 157 --
arch/x86/kernel/acpi/Makefile |9
arch/x86/kernel/acpi/realmode/Makefile | 57 +
arch/x86/kernel/acpi/realmode/copy.S |1
arch/x86/kernel/acpi/realmode/video-bios.c |1
arch/x86/kernel/acpi/realmode/video-mode.c |1
arch/x86/kernel/acpi/realmode/video-vesa.c |1
arch/x86/kernel/acpi/realmode/video-vga.c |1
arch/x86/kernel/acpi/realmode/wakemain.c | 81 +++
arch/x86/kernel/acpi/realmode/wakeup.S | 113 ++
arch/x86/kernel/acpi/realmode/wakeup.h | 36 +++
arch/x86/kernel/acpi/realmode/wakeup.lds.S | 61 +
arch/x86/kernel/acpi/sleep.c | 73 +-
arch/x86/kernel/acpi/sleep.h | 18 +
arch/x86/kernel/acpi/sleep_32.c| 40 ---
arch/x86/kernel/acpi/wakeup_32.S | 245 +-
arch/x86/kernel/acpi/wakeup_64.S | 313 -
arch/x86/kernel/acpi/wakeup_rm.S | 10
arch/x86/kernel/e820_64.c |5
arch/x86/kernel/head_64.S |4
arch/x86/kernel/setup_32.c |4
arch/x86/kernel/setup_64.c | 16 +
arch/x86/kernel/smpboot_64.c | 26 --
include/asm-x86/smp_64.h |2
include/asm-x86/trampoline.h | 18 +
32 files changed, 726 insertions(+), 775 deletions(-)
Index: linux-2.6/arch/x86/boot/Makefile
===
--- linux-2.6.orig/arch/x86/boot/Makefile
+++ linux-2.6/arch/x86/boot/Makefile
@@ -30,7 +30,7 @@ subdir- := compressed
setup-y+= a20.o cmdline.o copy.o cpu.o cpucheck.o edd.o
setup-y+= header.o main.o mca.o memory.o pm.o pmjump.o
-setup-y+= printf.o string.o tty.o video.o version.o
+setup-y+= printf.o string.o tty.o video.o video-mode.o
version.o
setup-$(CONFIG_X86_APM_BOOT) += apm.o
setup-$(CONFIG_X86_VOYAGER) += voyager.o
Index: linux-2.6/arch/x86/boot/boot.h
===
--- linux-2.6.orig/arch/x86/boot/boot.h
+++ linux-2.6/arch/x86/boot/boot.h
@@ -286,6 +286,11 @@ int getchar_timeout(void);
/* video.c */
void set_video(void);
+/* video-mode.c */
+int set_mode(u16 mode);
+int mode_defined(u16 mode);
+void probe_cards(int unsafe);
+
/* video-vesa.c */
void vesa_store_edid(void);
Index: linux-2.6/arch/x86/boot/video-bios.c
===
--- linux-2.6.orig/arch/x86/boot/video-bios.c
+++ linux-2.6/arch/x86/boot/video-bios.c
@@ -50,6 +50,7 @@ static int set_bios_mode(u8 mode)
if (new_mode == mode)
return 0; /* Mode change OK */
+#ifndef _WAKEUP
if (new_mode != boot_params.screen_info.orig_video_mode) {
/* Mode setting failed, but we didn't end up where we
started. That's bad. Try to revert to the original
@@ -59,13 +60,18 @@ static int set_bios_mode(u8 mode)
: +a (ax)
: : ebx, ecx, edx, esi, edi);
}
+#endif
return -1;
}
static int bios_probe(void)
{
u8 mode;
+#ifdef _WAKEUP
+ u8 saved_mode = 0x03;
+#else
u8 saved_mode = boot_params.screen_info.orig_video_mode;
+#endif
u16 crtc;
struct mode_info *mi;
int nmodes = 0;
Index: linux-2.6/arch/x86/boot/video-mode.c
2.6.25-rc2 System no longer powers off after suspend-to-disk. Screen becomes green.
On Feb 16, 2008 5:00 AM, Greg KH [EMAIL PROTECTED] wrote:
Also, I've tried CONFIG_DETECT_SOFTLOCKUP=n, but this doesn't fix it either.
Ok, this looks to be something else.
Here's the last dmesg after suspend-to-disk and hang there...
CPU 1 is now offline
SMP alternatives: switching to UP code
PM: Syncing filesystems ... done.
Freezing user space processes ... (elapsed 0.00 seconds) done.
Freezing remaining freezable tasks ... (elapsed 0.00 seconds) done.
PM: Shrinking memory... ^H-^Hdone (0 pages freed)
PM: Freed 0 kbytes in 0.10 seconds (0.00 MB/s)
ACPI: Preparing to enter system sleep state S4
Suspending console(s)
[ ... it just hangs here ... press power-switch does the job, and
system is able to resume upon powering on ]
Wait, this is a suspend-to-disk issue. Totally different than the will
not power off issue.
Can you start a new thread on this, and add the suspend people to it?
I bisected down this one commit that causes the problem with
suspend-to-disk on Lenovo X60s (i945 chipset).
commit ba8bbcf6ff4650712f64c0ef61139c73898e2165
Author: Jesse Barnes [EMAIL PROTECTED]
Date: Thu Nov 22 14:14:14 2007 +1000
i915: add suspend/resume support
Add suspend/resume support to the i915 driver. Moves some of the
initialization into the driver load routine, and fixes up places where we
assumed no dev_private existed in some of the cleanup paths. This allows
us to suspend/resume properly even if X isn't running.
Signed-off-by: Dave Airlie [EMAIL PROTECTED]
There where problem reverting the some i915 files with the latest
linux git pull, so I copied those i915*.{h,c} prior to this commit,
and problem went away.
Suspend-to-ram, suspend-to-disk all working now.
Thanks,
Jeff.
-
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-rc2 System no longer powers off after suspend-to-disk. Screen becomes green.
I found the same poweroff issue on my T61. It turned out to be related to the
C state code disabling interrupts when it shouldn't iirc. Booting
with 'idle=poll' seems to work around the problem.
The green screen problem should be fixed (see the DRM git tree for details).
Jesse
On Tuesday, February 19, 2008 4:53 pm Jeff Chua wrote:
On Feb 16, 2008 5:00 AM, Greg KH [EMAIL PROTECTED] wrote:
Also, I've tried CONFIG_DETECT_SOFTLOCKUP=n, but this doesn't fix it
either.
Ok, this looks to be something else.
Here's the last dmesg after suspend-to-disk and hang there...
CPU 1 is now offline
SMP alternatives: switching to UP code
PM: Syncing filesystems ... done.
Freezing user space processes ... (elapsed 0.00 seconds) done.
Freezing remaining freezable tasks ... (elapsed 0.00 seconds) done.
PM: Shrinking memory... ^H-^Hdone (0 pages freed)
PM: Freed 0 kbytes in 0.10 seconds (0.00 MB/s)
ACPI: Preparing to enter system sleep state S4
Suspending console(s)
[ ... it just hangs here ... press power-switch does the job, and
system is able to resume upon powering on ]
Wait, this is a suspend-to-disk issue. Totally different than the will
not power off issue.
Can you start a new thread on this, and add the suspend people to it?
I bisected down this one commit that causes the problem with
suspend-to-disk on Lenovo X60s (i945 chipset).
commit ba8bbcf6ff4650712f64c0ef61139c73898e2165
Author: Jesse Barnes [EMAIL PROTECTED]
Date: Thu Nov 22 14:14:14 2007 +1000
i915: add suspend/resume support
Add suspend/resume support to the i915 driver. Moves some of the
initialization into the driver load routine, and fixes up places where
we assumed no dev_private existed in some of the cleanup paths. This
allows us to suspend/resume properly even if X isn't running.
Signed-off-by: Dave Airlie [EMAIL PROTECTED]
There where problem reverting the some i915 files with the latest
linux git pull, so I copied those i915*.{h,c} prior to this commit,
and problem went away.
Suspend-to-ram, suspend-to-disk all working now.
Thanks,
Jeff.
-
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] PM: Remove unbalanced mutex_unlock() from dpm_resume()
Hi Greg, Please consider taking the following fix for 2.6.25. Thanks, Rafael --- From: Rafael J. Wysocki [EMAIL PROTECTED] Remove an unnecessary unlocking of dpm_list_mtx in the error path in drivers/base/power/main.c:dpm_suspend() . Signed-off-by: Rafael J. Wysocki [EMAIL PROTECTED] --- drivers/base/power/main.c |1 - 1 file changed, 1 deletion(-) Index: linux-2.6/drivers/base/power/main.c === --- linux-2.6.orig/drivers/base/power/main.c +++ linux-2.6/drivers/base/power/main.c @@ -479,7 +479,6 @@ static int dpm_suspend(pm_message_t stat mutex_lock(dpm_list_mtx); if (list_empty(dev-power.entry)) list_add(dev-power.entry, dpm_locked); - mutex_unlock(dpm_list_mtx); break; } mutex_lock(dpm_list_mtx); - 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-rc2 System no longer powers off after suspend-to-disk. Screen becomes green.
On Wednesday, 20 of February 2008, Jesse Barnes wrote: I found the same poweroff issue on my T61. It turned out to be related to the C state code disabling interrupts when it shouldn't iirc. Booting with 'idle=poll' seems to work around the problem. However, this issue is supposed to be fixed in 2.6.25-rc2, so most probably there is another problem in there. 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 5/5] ACPI: add DMI to enable OSI(Linux) on ThinkPad T61
On Tue, 2008-02-19 at 11:24 -0300, Henrique de Moraes Holschuh wrote: On Tue, 19 Feb 2008, Thomas Renninger wrote: Looks quite a bad idea IMO. 2.6.24 means what? SuSE's? Mainline's? Debian's? At what patch level? With which user patches tacked on top? And at what level of userspace support (X.org can make a LOT of difference here)? So you think on next Lenovo pre-load we should compile a SLED10 SP2 Huh?! No, I don't. I would walk away in disgust if we did it. OSI(SLED10 SP2) would be even worse than OSI(Linux) plus a OSwhatever(2.6.24), I think I can safely assume that we *all* agree on THAT one. into our kernel and let Lenovo BIOS fixups use it? E.g. we could use the default BCM/BQC/BCL brightness interface easily then, just a small AFAIK, there is no problem with the *ACPI* brightness firmware on ThinkPads. At all. Its only quirk is that you want to call _BCL at least once at driver load. No it's not that it's: - you call BCLL, a totally undefined AML function, found out by DSDT examination..., Lenovo is allowed to and will change the name this function at some time, they even could for a BIOS update - It is that we have to use the ibm_acpi driver quirks for an interface that is specified and which nearly every Vista compatible machine is providing. You need special handling for Lenovos. You need to blacklist them to not use the well defined interface, but use the ibm_acpi quirks. I really like to ask Lenovo to add a (on Intel graphics cards): if (linux) call _BCM/BQC/BCL this way else call _BCM/BQC/BCL the other way All this should be only some simple AML lines... and simply use the video driver for Lenovo backlight switching... Anyway, the whole backlight brightness stink is our (as in Linux kernel people, userspace people, distro people) doing. The laptop vendors, for once, had nothing to do with it. Also, for once, the ACPI 3.0 specification (when correctly implemented in the AML *and* ACPI OSI) does give us all we need to have it work properly in any way we see fit. Since the brightness issues have *nothing* to do with OSI(anything), let's leave it for another thread. Please let us not end up with hacks like ???SLED10 SP2, FEISTY or whatever weirdness and this will come if we ignore osi=linux or do not provide something else. We should make up something more robust and more Linux kernel appropriate and propagate it to the vendors. We all agree on that, Thomas. Puhhh... good. So I have missed the one or other suggestion or there are no suggestions yet? I am actually arguing for something *even* more fine-grained than a kernel version, but at the same time completely independent of kernel versions, so that if we backport something, or our userspace improves, we can stop (or start) advertising it through OSI() without messing with anything else. IMO kernel version is enough and the right thing, everything else is over-designed (please provide an example, I cannot imagine anything useful/generic but only osi=linux or better osi=linux + kernel version). I start a new thread/discussion now. I was quite late with reading up the list and this is important and should get some more attention also by others who might not have read into this thread. Thomas - 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
Kernel Version specific vendor override possibilities needed - Revert and provide osi=linux or provide a replacement
Hi,
please correct me if I am wrong or missed something:
osi=linux was an ability for vendors to provide Linux specific BIOS
updates/quirks.
_OSI(Linux) returned true until kernel version 2.6.23 (included?).
This has been replaced by rather huge black+white lists (at least they
most probably will grow huge) to get rid of it again.
Goal is to not return _OSI(Linux) as Intel identified it (after
inventing it? Doesn't really matter...) as not the right thing to do
as it does not consider fixes that might show up in specific kernel
versions in the future. This is the only reason I found, did I miss one
or the other?
Some questions and suggestions:
Is there already a replacement or will there pop up something soon,
which I may have missed?
This is an interface to the outside world (out of the kernel... in this
case not to userspace via /proc /sys ioctl, but to the BIOS).
Such interfaces should have a very long lifetime, once they are
implemented. In this case it should have an even much longer life time
than any /sys or whatever userspace interface. Telling vendors that this
will vanish and giving them time to remove it from their BIOSes or
better replace it with something else is the way to go here IMO.
The current policy is to just return zero on _OSI(Linux).
I don't get it why you do this.
You break machines on purpose.
Machines were vendors possibly have invested time to improve them for
Linux.
Why don't you just announce it, write it down in Documentation, also
write it to dmesg, instead of pls send acpidump to acpi list,
something like: osi=linux is deprecated and will get removed (ok there
popped up a way too much of these, but maybe dmiblacklist the message,
don't do any functional change for now...).
Why shouldn't I remove the whole dmi black/white listing from our
OpenSUSE kernel and return true for _OSI(Linux), this probably fixes a
lot machines and avoids bug reports (and annoyed users). I plan to do
this rather soon if I don't get some good arguments.
IMO this should also be done mainline. It is a pity that 2.6.24 now has
this. IMO this should even go back to a 2.6.24.X stable kernel.
Just let it in and announce to not use it and provide something else
(this has time then...).
---
Here a suggestion for an enhanced Linux Operation System Identification
interface for ACPI:
For general BIOS hot-fixes a check for osi=linux is sufficient for
vendors and allows them to provide a fix without risking breakage of
their Windows OS. This one should stay.
The problem is you do not know in what kernel version this might get
fixed at the time the BIOS is published with the short term
workaround. While this knob is essential for vendors for pre-loads, it
might break the machine if the user is trying to install a newer Linux
distribution with a newer Kernel where the problem got fixed. Then the
workaround might even slow down or break the system...
An example:
Lenovo wants to get rid of brightness switching via their old method
(int10?). But this needs in-kernel graphics driver support for Intel
graphics cards. Therefore ibm_acpi currently simulates this, the
specified ACPI brightness interface cannot be used. In which kernel
version in-kernel graphics drivers will be supported and Lenovo can
safely throw out int10 brightness switching from their BIOSes is not
known yet.
I think an appropriate interface could look like this:
Give vendors the possibility of an infinite tag, like osi=linux
Combine this somehow with a kernel version interface.
Vendors later should be able to simply switch from infinite to
kernel_version xy by just modifying a simple line.
=
AML example (when it's not yet known in which kernel version the fix
will be):
/* This will get filled with kernel the version */
Name (KERN, Package (0x3)
{
0, 0, 0
})
If (CondRefOf (_OSI, Local0))
{
/* Are we running on linux? */
If (_OSI (Linux))
{
Store (1, QURK)
}
}
=
AML example (when it *is* known in which kernel version the fix will be,
say 2.6.27):
/* This will get filled with kernel the version */
Name (KERN, Package (0x3)
{
0, 0, 0
})
If (CondRefOf (_OSI, Local0))
{
/* Are we running on linux? */
If (_OSI (Linux))
{
/* Does linux already support kernel version query? */
If (CondRefOf (_LKV, Local0))
{
/* LKV (Linux Kernel Version) returns a package with 3 int
values */
Store(_LKV, KERN)
/* Only activate quirk if this is a 2.6
kernel with version less than 27 */
If And(And(And((LEqual(Index(1, KERN), 2)),
(LEqual(Index(2, KERN), 6)),
(LLess(Index(3, KERN), 27
{
Store (1, QURK)
}
}
}
So the new thing here is:
Method(_LKV, 0, ..)
that needs to be implemented by the kernel and returns the
Re: 2.6.25-rc2 System no longer powers off after suspend-to-disk. Screen becomes green.
On Tue, 19 Feb 2008, Jesse Barnes wrote: I found the same poweroff issue on my T61. It turned out to be related to the C state code disabling interrupts when it shouldn't iirc. Booting with 'idle=poll' seems to work around the problem. The green screen problem should be fixed (see the DRM git tree for details). ..and the latter is hopefully now merged in my tree too (at least some of the drm updates are). Linus - 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 5/5] ACPI: add DMI to enable OSI(Linux) on ThinkPad T61
On Wed, 20 Feb 2008, Thomas Renninger wrote: AFAIK, there is no problem with the *ACPI* brightness firmware on ThinkPads. At all. Its only quirk is that you want to call _BCL at least once at driver load. No it's not that it's: - you call BCLL, a totally undefined AML function, found out by DSDT examination..., Lenovo is allowed to and will change the name this function at some time, they even could for a BIOS update That's gone in my devel tree, already. A first incarnation of it is even out on the latest thinkpad-acpi devel snapshot (it works, but it has a lot of thinkos, so I changed it a lot). thinkpad-acpi only calls _BCL now. And that's hardly Lenovo's fault, *I* chose to call BCLL, their standard ACPI interface works just fine. The reason I switched from _BCL to BCLL was that you warned me that _BCL had side-effects. Unfortunately, it took me this long to realise the side-effects were desired ones. - It is that we have to use the ibm_acpi driver quirks for an interface that is specified and which nearly every Vista compatible machine is providing. You need special handling for Lenovos. You need to blacklist them to not use the well defined interface, but use the ibm_acpi quirks. It is the other way around. thinkpad-acpi detects that ACPI generic brightness control exists, and refuses to load its own interface to avoid races with video.c and ACPI. And if you need thinkpad-acpi's interface instead of the one provided by video.c in a Lenovo ThinkPad, it is likely due to bugs in video.c. Or it is because X.org is making sure you have to use RandR backlight control. I really like to ask Lenovo to add a ???(on Intel graphics cards): if (linux) call _BCM/BQC/BCL this way else ??? call _BCM/BQC/BCL the other way All this should be only some simple AML lines... and simply use the video driver for Lenovo backlight switching... DO NOT DO THIS! Please, if you ever find yourself in a position to ask anything of the sort from Lenovo, CC me. And, preferably, we should talk about it first so we can reach an agreement and present a single position to Lenovo. As far as I know, there is *nothing* wrong with the Lenovo-provided _BCM/BQC/BCL handlers. If thinkpad-acpi gave you *any* ideas about asking Lenovo to change their DSDTs, please run them by me first, it is likely something I should change in thinkpad-acpi. And we have to get the X.org people in the loop *as* *well*. X.org wants to do the backlight switching directly in some drivers, because it is safer (no SMIs! Anything that avoids an SMI is a Good Thing), faster (no ACPI calls, no context switches, no SMI traps!), and it often gives you even more control and levels than what is available through ACPI, for example. We have to give userspace a sane way to tell the kernel to block access to any backlight interfaces dealing with a given video device. Again, this has nothing to do with Lenovo. We don't have any decent way to know what video device a backlight is tied to, either. That's something else that needs to be fixed. We have a buggy drivers/acpi/video.c. It is being fixed, look at the git logs and bugzilla... We have userspace fighting itself over how to handle KEY_BRIGHTNESS_*. It has to be fixed, too. Fortunately, it won't have to ALSO fight video.c anymore, the patch to stop that is already in mainline, although we might want to modify how that is done a bit to make life easier for the console warriors ;-) Nothing in the my-goodness-this-is-fucked-up list of troubles plaguing brightness control on ThinkPads relates to Lenovo's _BCM/BQC/BCL handlers, AFAIK. I am actually arguing for something *even* more fine-grained than a kernel version, but at the same time completely independent of kernel versions, so that if we backport something, or our userspace improves, we can stop (or start) advertising it through OSI() without messing with anything else. IMO kernel version is enough and the right thing, everything else is over-designed (please provide an example, I cannot imagine anything useful/generic but only osi=linux or better osi=linux + kernel version). I did. X.org userspace video device POST on resume. It is a real-world example. Others have given you other reasons why a kernel version is not a perfect solution, too. I start a new thread/discussion now. I was quite late with reading up the list and this is important and should get some more attention also by others who might not have read into this thread. That I agree with fully :-) -- 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: 2.6.25-rc2 System no longer powers off after suspend-to-disk. Screen becomes green.
On Tuesday, February 19, 2008 6:28 pm Linus Torvalds wrote: On Tue, 19 Feb 2008, Jesse Barnes wrote: I found the same poweroff issue on my T61. It turned out to be related to the C state code disabling interrupts when it shouldn't iirc. Booting with 'idle=poll' seems to work around the problem. The green screen problem should be fixed (see the DRM git tree for details). ..and the latter is hopefully now merged in my tree too (at least some of the drm updates are). Cool, thanks. Jeff, can you retest with Linus' tree? If you're still seeing problems, it might help to add some printks to the i915 driver's suspend routine. Just reading the regs really shouldn't cause a hang, but maybe the VGA bits are subtly wrong again... Thanks, Jesse - 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-rc2 System no longer powers off after suspend-to-disk. Screen becomes green.
On Feb 20, 2008 12:32 PM, Jesse Barnes [EMAIL PROTECTED] wrote: On Tuesday, February 19, 2008 6:28 pm Linus Torvalds wrote: On Tue, 19 Feb 2008, Jesse Barnes wrote: I found the same poweroff issue on my T61. It turned out to be related to the C state code disabling interrupts when it shouldn't iirc. Booting with 'idle=poll' seems to work around the problem. The green screen problem should be fixed (see the DRM git tree for details). Jeff, can you retest with Linus' tree? If you're still seeing problems, it might help to add some printks to the i915 driver's suspend routine. Just reading the regs really shouldn't cause a hang, but maybe the VGA bits are subtly wrong again... The funny thing is the screen is now normal during suspend, but the green came back after suspend! And the suspend still does NOT power off with lastest Linus's tree. I'll try the idle=poll to see if that works and will try some printk as well. Thanks, Jeff. - 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 Temperature/speed _not_ normal - no thermal throttling?
Hi, I believe I am having a critical thermal problem. I do not know if it is limited to the 2.6.24.2 kernel which I am running. I do see there has been some discussion about thermal zones and throttling on the list, but I can not tell if it means that thermal throttling is not working in 2.6.24.2 When I try to build several kernel source rpms, my dell d830 laptop seems to over heat and hang. It's happened 3 times now and I would like to learn what's going on and not let it happen again. I'm a newbie (and have had problems trying to post :), so I do apologize if I've missing something relatively simple or if this is post is not appropriate in any way. I'm running a Scientific Linux 5 (based on RHEL5) distribution and am just running a cpuspeed user space utility --- and therefor do not believe I have any user space process watching temperature. However, in the earlier kernels, I use to be able to (manually) write to /proc/acpi/processor/CPU0/throttling and see a change when read back, but now the write does not seem to do anything. This might be OK as I 'm thinking the kernel and/or the hardware itself might now suppose to be doing the throttling? Anyway, in 3 windows, I run: win1: stress --cpu 8 --io 4 --vm 2 --vm-bytes 128M --timeout 180s win2: while sleep 1;do cat /proc/acpi/thermal_zone/THM/temperature;done win3: tail -f /var/log/messages win4; while sleep 1;do cat /proc/acpi/processor/CPU0/throttling;done In win2, I see the temperature go from 50 C to over 86 C. In win3, before, the temp in win2 reaches 70 C, I see kernel: CPU0: Temperature/speed normal (and also CPU1) and kernel: Machine check events logged The temperature would probably just continue to climb if I ran the test for longer that 180 seconds (the kernel rpms take much longer and do not complete before the system hangs :( In /var/log/mcelog, (running mcelog-0.8pre), I only see Processor core below trip temperature. Throttling disabled messages. This is strange because it seems to be being disabling after never being enabled. (Is there a newer mcelog I should be running?) The fan speed does increase, but the throttling state indication never changes (it's always T0: 100%). It seems that when I build the kernel rpms, the increased fan speed is not enough to keep the temperature form running away. It seems that thermal throttling would be required and is not happening. Should I be doing something from user space? Can I do something from user space? Thanks, Ron - 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-rc2-mm1 (x64 thermal build failure)
Le Tue, 19 Feb 2008 15:21:29 -0800, Andrew Morton [EMAIL PROTECTED] a écrit : ug, sorry, if I'd realised it was like this I'd have said don't bother. Apart from the obvious problem, this means that people will keep breaking CONFIG_DMI=n all the time, because they will forget the ifdefs, and the number of people who test with CONFIG_DMI=n will be small. Yes, #ifdef CONFIG_DMI is not very comfortable. That why I proposed things such as DECLARE_DMI_FIXUP_TABLE(), because it would force people to use these macros, which would then be working correctly depending on DMI=y/n. However, there's still the issue of driver_data that I mentionned in my earlier post. What should I do ? Option 1 ? Option 2 ? Give up with the patch ? Thanks for your comments, Thomas -- Thomas Petazzoni, Free Electrons Free Embedded Linux Training Materials on http://free-electrons.com/training (More than 1500 pages!) signature.asc Description: PGP signature
