Re: Fan speeds on HP nc6400 and nc8430
I managed to get a HP NX 6330 laptop to test HP laptop related issues
discussed here.
But the bug http://bugzilla.kernel.org/show_bug.cgi?id=7813 seems to
be NOT reproducible on my NX6330. This fact prompt if there are any
essential difference between NX6330 and NC6400. The BIOS of my NX6330
even declares itself is NC6330.
On 2/6/07, Thomas Renninger [EMAIL PROTECTED] wrote:
On Wed, 2007-01-24 at 09:54 -0700, Bjorn Helgaas wrote:
On Tuesday 23 January 2007 21:38, Bjorn Helgaas wrote:
On Tuesday 23 January 2007 21:19, Luming Yu wrote:
On 1/19/07, emisca [EMAIL PROTECTED] wrote:
The TZ4 thermal zone on all the hp compaq line nx and nc is
not a temperature but the fan speed. You can see this information on
the web and on hp forums.
Where is the hp forums.
I don't work on laptops, so I can't confirm this, but Google found
this (from tz4 thermal zone fan speed hp):
http://forums1.itrc.hp.com/service/forums/bizsupport/questionanswer.do?threadId=1052925
Someone also sent me this, which I'll include in case it helps anybody
else. Obviously, scripts like the one mentioned below are stop-gaps
that shouldn't be necessary. But the script might have useful hints
about how to fix the kernel so the script would no longer be needed.
Take a look at this:
http://daniel.graziotin.net/2006/12/02/hp-nx6325-and-friends-thermal-problems-solved
this fixed my thermal problem.
And make sure you unload the psmouse module during halt/reboot
otherwise you have problemes when you start your notebook again.
(symptom's: very long BIOS-Boot, ACPI-problems (thermal)..)
I have a patch that should fix the psmouse unload thing (at the end).
Not sure whether it's still needed in 2.6.20-rcX, there was some work
done... it definitely helps on 2.6.18 and 2.6.16 kernels.
Ok, I quickly tried on 2.6.20-rc7 and it seems to work without the
patch.
Maybe Dmitry can comment on that and push this one if still needed?
It's quite difficult to get the overview over the HP problems, as there
are several, some quite weird, and a lot different reports.
I've found out that the psmouse thing really fixes things.
and I got a lot reports that Alexeys patch (and the
unregister_serio_drivers attached) fixes up things:
https://bugzilla.novell.com/show_bug.cgi?id=179702
https://bugzilla.novell.com/show_bug.cgi?id=234475
As this patch broke Linus' machine, I understand that Len is a bit
anxious, but a lot people tested the reworked patch (it's currently in
10.2 and SLE10-SP1 SuSE branches), it would be great if Len can push it
at least for the next kernel cycle...
What is still broken, but patches are available, is fan state after
suspend/resume.
Thanks to Rafael, there is a list of patches that seem to help
(including Alexey's and some others) here:
http://www.sisk.pl/kernel/patches/2.6.20-rc5/
Most of them seem to come from:
http://bugzilla.kernel.org/show_bug.cgi?id=5534
and
http://bugzilla.kernel.org/show_bug.cgi?id=7122
Can someone give an overview about what is already submitted, what is
going to be merged and where/when (-mm, rcX, 2.6.21-rc1, ...).
All kind of comments/review/tests are very welcome...
Some of the patches miss a comment...
Thanks,
Thomas
---
Subject: Unregister serio drivers on shutdown
From: Thomas Renninger [EMAIL PROTECTED]
Unproved theory:
It seems that the Embedded Controller needs this at ACPI shutdown time:
psmouse_set_state(psmouse, PSMOUSE_CMD_MODE);
psmouse_set_state(psmouse, PSMOUSE_IGNORE);
done in psmouse_disconnect in psmouse module.
If this is not done on shutdown it leads to very strange BIOS/EC behaviour
on latest HP laptops which even survives a reboot (cpufreq cannot reach max
freq, BIOS takes long to boot, etc.). Then the fixed kernel needs to
be booted twice, that machine reaches max freq and behaves normal again.
Ref: http://bugzilla.kernel.org/show_bug.cgi?id=7689
https://bugzilla.novell.com/show_bug.cgi?id=179702
Signed-off-by: Thomas Renninger [EMAIL PROTECTED]
drivers/input/serio/serio.c |1 +
1 files changed, 1 insertion(+)
Index: linux-2.6.19/drivers/input/serio/serio.c
===
--- linux-2.6.19.orig/drivers/input/serio/serio.c
+++ linux-2.6.19/drivers/input/serio/serio.c
@@ -973,6 +973,7 @@ static struct bus_type serio_bus = {
.probe = serio_driver_probe,
.remove = serio_driver_remove,
.resume = serio_resume,
+ .shutdown = serio_driver_remove,
};
static int __init serio_init(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
RE: Bad libata resume behaviour due to ACPICA change (in acpi-test)
T43 2668-NG2 BIOS 1.23 EC 1.03 -Original Message- From: Henrique de Moraes Holschuh [mailto:[EMAIL PROTECTED] Sent: Tuesday, February 06, 2007 2:59 AM To: Starikovskiy, Alexey Y Cc: linux-acpi@vger.kernel.org; Brown, Len Subject: Re: Bad libata resume behaviour due to ACPICA change (in acpi- test) On Mon, 05 Feb 2007, Starikovskiy, Alexey Y wrote: I cannot reproduce your problem with T43 here on linux-acpi-test with defconfig (relevant ACPI modules were tried both dynamic and static). Resume time is about 4-6 seconds, not 20-40 as you mention. Never tried a thinkpad in defconfig mode. Will do. Could you please send your .config and try defconfig on your machine? BTW, my T43 use AHCI mode of SATA controller, if it matters... Mine is stuck in legacy mode, so we are using different drivers (ata_piix in my case). Which BIOS and firmware you got? What is your machine type? I am very interested in a way to get my T43 into AHCI mode... Mine is a ThinkPad T43 2687-DDU, BIOS is 1.29, EC firmware is 1.06. -- 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
T43 BIOS and AHCI
On Tue, 06 Feb 2007, Starikovskiy, Alexey Y wrote: T43 2668-NG2 BIOS 1.23 EC 1.03 We use the same BIOS (TP-1Y), but you are using a very old version. A lot might have changed since then, including AHCI support going away. I don't think I ever run a 1.23 bios on my machine... And I know for a fact that the ACPI DSDT tables *did* change since 1.23, as I have been looking at the DSDT changes in later versions of the BIOS as I upgrade them. Anyway, do you have anything in the BIOS that allows you to select AHCI mode, or did Linux just load AHCI and skipped merrily along? Here, AHCI won't load with an error (supposedly because the ICH is already set to non-AHCI mode). -- 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: Thermal resume regression
Hi, Could you try the patch from http://bugzilla.kernel.org/show_bug.cgi?id=7887 to see if it's related? Regards. Konstantin. -Original Message- From: [EMAIL PROTECTED] [mailto:linux-acpi- [EMAIL PROTECTED] On Behalf Of Markus Demleitner Sent: Monday, February 05, 2007 6:36 PM To: linux-acpi@vger.kernel.org Subject: Thermal resume regression Hi, Since 2.6.20 is out and nobody else seem to complain, I thought it's time to ask -- From kernel version 2.6.18 on my JVC XP731 (a centrino-based subnotebook) would freeze when resuming from echo -n mem /sys/power/state where it woke up flawlessly before. Turns out it did this because in drivers/acpi/thermal.c, function acpi_thermal_resume, a call to acpi_thermal_check was introduced (that's line 1415 in 2.6.20). The lockup at resume time is deterministic, i.e., it is independent of the actual temperature of the device(s). Commenting it out results in a flawless wakeup (as does removing the thermal module at suspend time). Now, I have to admit I didn't investigate matters much further, but still: acpi_thermal_check does quite a few rather fancy things, and regardless if the freeze on resume is an issue of the JVC (as the lack of other complaints suggests) or not -- is it absolutely necessary to run it during resume, when things are a nightmare to debug (which is one reason I didn't investigate further)? I for one would appreciate if it were only called after the system is up and running, when one could at least see what the kernel thinks it's doing... Disclaimer: I only have very shady ideas what's actually going on with ACPI thermal management. If not calling acpi_thermal_check actually significantly increases the likelihood of fried machines, disregard all this as layman babble, and I'll just add thermal to the list of modules that don't survive a suspend to RAM. Cheers, Markus - 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: T43 BIOS and AHCI
Henrique de Moraes Holschuh wrote: On Tue, 06 Feb 2007, Starikovskiy, Alexey Y wrote: T43 2668-NG2 BIOS 1.23 EC 1.03 I updated to 1.29/1.06 and still have 6 seconds resume time... We use the same BIOS (TP-1Y), but you are using a very old version. A lot might have changed since then, including AHCI support going away. I don't think I ever run a 1.23 bios on my machine... And I know for a fact that the ACPI DSDT tables *did* change since 1.23, as I have been looking at the DSDT changes in later versions of the BIOS as I upgrade them. Anyway, do you have anything in the BIOS that allows you to select AHCI mode, or did Linux just load AHCI and skipped merrily along? Here, AHCI won't load with an error (supposedly because the ICH is already set to non-AHCI mode). Sorry, my mistake here ahci only says that it failed to find device, and then all output comes from pii_ata... 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: Fan speeds on HP nc6400 and nc8430
On Tue, 2007-02-06 at 19:58 +0800, Luming Yu wrote: I managed to get a HP NX 6330 laptop to test HP laptop related issues discussed here. But the bug http://bugzilla.kernel.org/show_bug.cgi?id=7813 seems to be NOT reproducible on my NX6330. This fact prompt if there are any essential difference between NX6330 and NC6400. The BIOS of my NX6330 even declares itself is NC6330. I'm not clear on HP's numbering scheme. It doesn't make any obvious sense to me! Mine is a nc6320 which exhibits the above bug. The DSDT lists as nc6340 though. That is an Intel Core Duo, with the following lspci output: 00:00.0 Host bridge: Intel Corporation Mobile 945GM/PM/GMS/940GML and 945GT Express Memory Controller Hub (rev 03) 00:02.0 VGA compatible controller: Intel Corporation Mobile 945GM/GMS/940GML Express Integrated Graphics Controller (rev 03) 00:02.1 Display controller: Intel Corporation Mobile 945GM/GMS/940GML Express Integrated Graphics Controller (rev 03) 00:1b.0 Audio device: Intel Corporation 82801G (ICH7 Family) High Definition Audio Controller (rev 01) 00:1c.0 PCI bridge: Intel Corporation 82801G (ICH7 Family) PCI Express Port 1 (rev 01) 00:1c.2 PCI bridge: Intel Corporation 82801G (ICH7 Family) PCI Express Port 3 (rev 01) 00:1c.3 PCI bridge: Intel Corporation 82801G (ICH7 Family) PCI Express Port 4 (rev 01) 00:1d.0 USB Controller: Intel Corporation 82801G (ICH7 Family) USB UHCI #1 (rev 01) 00:1d.1 USB Controller: Intel Corporation 82801G (ICH7 Family) USB UHCI #2 (rev 01) 00:1d.2 USB Controller: Intel Corporation 82801G (ICH7 Family) USB UHCI #3 (rev 01) 00:1d.3 USB Controller: Intel Corporation 82801G (ICH7 Family) USB UHCI #4 (rev 01) 00:1d.7 USB Controller: Intel Corporation 82801G (ICH7 Family) USB2 EHCI Controller (rev 01) 00:1e.0 PCI bridge: Intel Corporation 82801 Mobile PCI Bridge (rev e1) 00:1f.0 ISA bridge: Intel Corporation 82801GBM (ICH7-M) LPC Interface Bridge (rev 01) 00:1f.1 IDE interface: Intel Corporation 82801G (ICH7 Family) IDE Controller (rev 01) 00:1f.2 SATA controller: Intel Corporation 82801GBM/GHM (ICH7 Family) Serial ATA Storage Controller AHCI (rev 01) 02:06.0 CardBus bridge: Texas Instruments Unknown device 8039 02:06.1 FireWire (IEEE 1394): Texas Instruments Unknown device 803a 02:06.2 Mass storage controller: Texas Instruments Unknown device 803b 02:06.3 Class 0805: Texas Instruments Unknown device 803c 02:0e.0 Ethernet controller: Broadcom Corporation NetXtreme BCM5788 Gigabit Ethernet (rev 03) 08:00.0 Network controller: Intel Corporation PRO/Wireless 3945ABG Network Connection (rev 02) Peter Clifton - 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 09/13] acpi: add backlight support to the sony_acpi driver
On Mon, 2007-02-05 at 16:09 -0800, [EMAIL PROTECTED] wrote: From: Alessandro Guido [EMAIL PROTECTED] Make the sony_acpi use the backlight subsystem to adjust brightness value instead of using the /proc/sony/brightness file. (Other settings will still have a /proc/sony/... entry) Signed-off-by: Alessandro Guido [EMAIL PROTECTED] Cc: Stelian Pop [EMAIL PROTECTED] Cc: Richard Purdie [EMAIL PROTECTED] Acked-by: Richard Purdie [EMAIL PROTECTED] Signed-off-by: Andrew Morton [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: [patch 03/13] asus_acpi: Add support for Asus Z81SP
Le Tuesday 06 February 2007 01:09:09 [EMAIL PROTECTED], vous avez écrit : From: Matthew C Campbell [EMAIL PROTECTED] Adds support in asus_acpi for the Asus Z81SP laptop. This preserves all old functionality when improperly detected as well as enabling Bluetooth support. I don't know if this patch is realy usefull, as there is the new asus-laptop driver (in acpi-test), but let's Ack this ... Signed-off-by: Matthew C Campbell [EMAIL PROTECTED] Cc: Corentin Chary [EMAIL PROTECTED] Acked-by: Corentin Chary [EMAIL PROTECTED] Cc: Karol Kozimor [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Signed-off-by: Andrew Morton [EMAIL PROTECTED] -- CHARY 'Iksaif' Corentin http://xf.iksaif.net - 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
[-mm patch] #ifdef ACPI_FUTURE_USAGE acpi_os_readable()
On Mon, Jan 29, 2007 at 08:45:28PM -0800, Andrew Morton wrote:
...
Changes since 2.6.20-rc6-mm2:
...
git-acpi.patch
...
git trees
...
acpi_os_readable() is no longer used.
Signed-off-by: Adrian Bunk [EMAIL PROTECTED]
---
drivers/acpi/osl.c |2 --
include/acpi/acpiosxf.h |3 +--
2 files changed, 1 insertion(+), 4 deletions(-)
--- linux-2.6.20-rc6-mm3/include/acpi/acpiosxf.h.old2007-02-06
06:57:15.0 +0100
+++ linux-2.6.20-rc6-mm3/include/acpi/acpiosxf.h2007-02-06
06:57:53.0 +0100
@@ -240,9 +240,8 @@
acpi_os_validate_address(u8 space_id,
acpi_physical_address address, acpi_size length);
-u8 acpi_os_readable(void *pointer, acpi_size length);
-
#ifdef ACPI_FUTURE_USAGE
+u8 acpi_os_readable(void *pointer, acpi_size length);
u8 acpi_os_writable(void *pointer, acpi_size length);
#endif
--- linux-2.6.20-rc6-mm3/drivers/acpi/osl.c.old 2007-02-06 07:18:33.0
+0100
+++ linux-2.6.20-rc6-mm3/drivers/acpi/osl.c 2007-02-06 07:18:54.0
+0100
@@ -888,7 +888,6 @@
return 0;
}
-#endif /* ACPI_FUTURE_USAGE */
/* Assumes no unreadable holes inbetween */
u8 acpi_os_readable(void *ptr, acpi_size len)
@@ -901,7 +900,6 @@
return 1;
}
-#ifdef ACPI_FUTURE_USAGE
u8 acpi_os_writable(void *ptr, acpi_size len)
{
/* could do dummy write (racy) or a kernel page table lookup.
-
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] ACPI: ibm-acpi: add Ultrabay support for the T60p ThinkPad
From: Theodore Ts'o [EMAIL PROTECTED] The following patch adds support for obtaining the status and ejecting Ultrabay devices for the T60p Thinkpad; my guess is that it probably works on T60 Thinkpads and probably more recent Lenovo latops as well. With the 2.03 BIOS I have been able to eject a SATA drive in an Ultrabay carrier by using the command: echo 1 /sys/class/scsi_device/1:0:0:0/device/delete and upon re-inserting the it back into the device and issuing the command: echo 0 0 0 /sys/class/scsi_host/host1/scan have the device appear again. (With the 1.02 BIOS the device does not function when re-inserted, even after a warm boot; a cold reboot is required to store the Ultrabay device's functionality.) More complicated Ultrabay eject and insert scripts can be found on the ThinkWiki, although it's important to comment out the hdparm -Y as it apparently doesn't work or do anything, and causes the eject process to hang for about a minute. Signed-off-by: Theodore Ts'o [EMAIL PROTECTED] Cc: Whoopie [EMAIL PROTECTED] Signed-off-by: Henrique de Moraes Holschuh [EMAIL PROTECTED] --- drivers/acpi/ibm_acpi.c |3 ++- 1 files changed, 2 insertions(+), 1 deletions(-) diff --git a/drivers/acpi/ibm_acpi.c b/drivers/acpi/ibm_acpi.c index c6144ca..5c0f1b8 100644 --- a/drivers/acpi/ibm_acpi.c +++ b/drivers/acpi/ibm_acpi.c @@ -159,7 +159,8 @@ IBM_HANDLE(dock, root, \\_SB.GDCK,/* X30, X31, X40 */ #endif IBM_HANDLE(bay, root, \\_SB.PCI.IDE.SECN.MAST, /* 570 */ \\_SB.PCI0.IDE0.IDES.IDSM, /* 600e/x, 770e, 770x */ - \\_SB.PCI0.SATA.SCND.MSTR, /* T60, X60, Z60 */ + \\_SB.PCI0.SATA.SCND.MSTR, /* T60, X60, Z60, SATA mode? */ + \\_SB.PCI0.IDE0.PRIM.MSTR, /* T60p, IDE mode? */ \\_SB.PCI0.IDE0.SCND.MSTR, /* all others */ ); /* A21e, R30, R31 */ -- 1.4.4.4 - 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 2/2] ACPI: ibm-acpi: cleanup init and exit paths
This patch fixes a small memory leak on module removal, and does other
assorted minor cleanups on the module init codepath.
Signed-off-by: Henrique de Moraes Holschuh [EMAIL PROTECTED]
---
drivers/acpi/ibm_acpi.c | 13 -
1 files changed, 8 insertions(+), 5 deletions(-)
diff --git a/drivers/acpi/ibm_acpi.c b/drivers/acpi/ibm_acpi.c
index 5c0f1b8..20cbde5 100644
--- a/drivers/acpi/ibm_acpi.c
+++ b/drivers/acpi/ibm_acpi.c
@@ -497,6 +497,10 @@ static int ibm_acpi_driver_init(void)
printk(IBM_INFO %s v%s\n, IBM_DESC, IBM_VERSION);
printk(IBM_INFO %s\n, IBM_URL);
+ if (ibm_thinkpad_ec_found)
+ printk(IBM_INFO ThinkPad EC firmware %s\n,
+ ibm_thinkpad_ec_found);
+
return 0;
}
@@ -2618,7 +2622,7 @@ static void __init ibm_handle_init(char *name,
ibm_handle_init(#object, object##_handle, *object##_parent,\
object##_paths, ARRAY_SIZE(object##_paths), object##_path)
-static int set_ibm_param(const char *val, struct kernel_param *kp)
+static int __init set_ibm_param(const char *val, struct kernel_param *kp)
{
unsigned int i;
@@ -2660,7 +2664,8 @@ static void acpi_ibm_exit(void)
for (i = ARRAY_SIZE(ibms) - 1; i = 0; i--)
ibm_exit(ibms[i]);
- remove_proc_entry(IBM_DIR, acpi_root_dir);
+ if (proc_dir)
+ remove_proc_entry(IBM_DIR, acpi_root_dir);
if (ibm_thinkpad_ec_found)
kfree(ibm_thinkpad_ec_found);
@@ -2711,9 +2716,6 @@ static int __init acpi_ibm_init(void)
/* Models with newer firmware report the EC in DMI */
ibm_thinkpad_ec_found = check_dmi_for_ec();
- if (ibm_thinkpad_ec_found)
- printk(IBM_INFO ThinkPad EC firmware %s\n,
- ibm_thinkpad_ec_found);
/* these handles are not required */
IBM_HANDLE_INIT(vid);
@@ -2743,6 +2745,7 @@ static int __init acpi_ibm_init(void)
proc_dir = proc_mkdir(IBM_DIR, acpi_root_dir);
if (!proc_dir) {
printk(IBM_ERR unable to create proc dir %s, IBM_DIR);
+ acpi_ibm_exit();
return -ENODEV;
}
proc_dir-owner = THIS_MODULE;
--
1.4.4.4
-
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 bytecode hardware registers access
Is your ioport included in the microsoft's list being blocked by XP? Please give me an example (acpidump output from a real box) that demonstrates ACPI is missing something which must be done through native driver. I'm wondering the designer of the box should already known AML code will directly access these ioport. why they needs some other native driver to access same set of ioport at same time with acpi. It sounds like obvious broken design. So my real question is the native driver is really wanted by the platform designer? As a hacker, it make senses to discover more hardware/platform features. But do these features make sense to the designer of the box. On 2/5/07, Rudolf Marek [EMAIL PROTECTED] wrote: Hello, To all: Please continue CCing me and the lm-sensors list thanks. Luming Yu wrote: Yes, that is bad to simultaneously access same hardware by ACPI and native drivers without coordination. But the problem is if nativer driver is really needed with the existence of the ACPI support for that device? Yes for example, BIOS will export though ACPI just one temperature _TMP but the chip monitors voltages and more temps etc etc. So from the lm-sensors point of view the answer is yes we need a full driver for hardware monitoring. Do you know the features that are NOT supported by ACPI? Yes as I wrote above - the voltages, fan speeds, various types of alarms... Instead of one temperature reading, I got 9 voltage readings, 3 temps, 5 fans etc etc Probably, just writing a acpi driver for SMBus controler could solve this problem completely. Just my intuition. Please correct me if I'm wrong. Problem is that the device manufacturers may do what they want in ACPI bytecode. We cannot expect them to implement smbus bus control as specified in the specs. They just drive the registers on their own. What I'm trying to implement is the ACPI isolation from selected hardware somehow, because the ACPI bytecode can contain code that modifies virtually any hardware in the system without the clue what others drivers do. Even the windows don't like it: http://www.microsoft.com/whdc/system/pnppwr/powermgmt/BIOSAML.mspx (I/O Ports Blocked from BIOS AML) Please help me find the solution. Thanks, Rudolf - 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
