From owner-freebsd-acpi@FreeBSD.ORG Wed Jul 16 23:39:06 2014 Return-Path: Delivered-To: freebsd-acpi@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id C3FA6BB6 for ; Wed, 16 Jul 2014 23:39:06 +0000 (UTC) Received: from mail-ie0-x235.google.com (mail-ie0-x235.google.com [IPv6:2607:f8b0:4001:c03::235]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 7E7082122 for ; Wed, 16 Jul 2014 23:39:06 +0000 (UTC) Received: by mail-ie0-f181.google.com with SMTP id rp18so1710353iec.40 for ; Wed, 16 Jul 2014 16:39:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=/UYjMTTg5P6fhIyUHCQVaAMJXRwbxwJvM/ALpyVWFro=; b=dE2dJk5k5MU9TMZwk4yc5Y8ubOtqTA9uM9ETnjhMROCfuOSXnAiXIS3LNx8A6ilQW2 UH4pGw99aPRtDdLNS+43+nZBl/lifEM60KZTUgXVMhXGb7ZE2/MYJV0APH0GeBVC7NUR WW4JL9Nme7GToUe30wG0Md0HOlgXnT02LcwD0dm5xXGfJOgT4ugfw0KC01HjZ6COYGYi cF7ggF+Bj1zamxRxA2Eb6SYTpigf3+BMcrvBPndM+wApBHe0IjhnCLSjj2ueFz/Oql53 I5vU8Jn4yTynCD5aYqOnRNDHySOEXNTfojmmpYM05GLq1LQs35n4u6uxhAqXdG5rfbVz 7Shg== MIME-Version: 1.0 X-Received: by 10.182.163.46 with SMTP id yf14mr28120831obb.40.1405553945725; Wed, 16 Jul 2014 16:39:05 -0700 (PDT) Received: by 10.182.29.9 with HTTP; Wed, 16 Jul 2014 16:39:05 -0700 (PDT) Received: by 10.182.29.9 with HTTP; Wed, 16 Jul 2014 16:39:05 -0700 (PDT) In-Reply-To: <53C6E9B3.1080402@att.net> References: <53C020CE.8010205@att.net> <53C02604.9070207@att.net> <53C3D322.3080302@att.net> <20140716040719.Y50382@sola.nimnet.asn.au> <20140716143406.V50382@sola.nimnet.asn.au> <53C67D70.6060603@att.net> <20140717011710.W50382@sola.nimnet.asn.au> <53C6E9B3.1080402@att.net> Date: Thu, 17 Jul 2014 01:39:05 +0200 Message-ID: Subject: Re: atrtc.c patch for ACPI CMOS region (was Re: ACPI support - Freebsd 10 on Sony Vaio VPCCA3C5E) From: Daniele Mazzotti To: Anthony Jenkins Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.18 Cc: freebsd-acpi@freebsd.org, Ian Smith X-BeenThere: freebsd-acpi@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: ACPI and power management development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Jul 2014 23:39:06 -0000 Hi guys, @Anthony: actually I am a "he" and not a "she" and I never thought about changing my nature below the waist :-). By the way I will try to apply the patch as soon as I will be back home as I left my personal PC at home and I won't be back until Monday. I will let you know if that will fix my suspend/resume issue. Regarding the battery issue I hope that I will try to follow the recommendations from Ian in another email and see what happen. Cheers, Daniele. Il 16/lug/2014 23:08 "Anthony Jenkins" ha scritto: > On 07/16/2014 13:16, Ian Smith wrote: > > On Wed, 16 Jul 2014 09:26:08 -0400, Anthony Jenkins wrote: > > > On 07/16/2014 01:32, Daniele Mazzotti wrote: > > >> Hi guys, thanks again for the support, but I am leaving for a > > >> businesses trip and I will be forced to put this debug thing on hold > > >> for a while. I will be back on track next week. > > > > > > Bah... really wanted to figure out the patch problem. I suspect the > > > file picked up some corruption somewhere between the email and your > > > FreeBSD filesystem. Your OS version has the same revision of that > > > source file as mine, so it should apply cleanly. If you feel like > > > tinkering with it in your free time, I've posted the patch here: > > > http://pastebin.com/P0B44u0c > > > > > > Good luck, > > > Anthony > > > > Either by show raw and save, or by download, the patch has ^M lineends. > Bah! Well that'd explain it... I'm generating the file on a pure FreeBSD > box, opened in gvim, select all, copy, paste to pastebin.com. > > Interesting, but I can't see atrtc.c being the right sort of place for > > this, seems way out of scope. Couldn't you include its headers and use > > functions rtcin() and writertc() from elsewhere in kernel, perhaps a > > module living in the same hierarchy as acpi_ibm, acpi_asus and such, > > that one could build and kldload if useful on a certain machine/s? > This is in support of the PNP0800 device, for which atrtc.c is the driver. > The ACPI spec (5.0 is what I'm reading) says that device should implement > a handler to read offset 0x00-0x7F. > > If so, you haven't to do battle with Time Lords :) with something people > > could add and load at own risk without messing with core kernel stuff. > > > > acpi_ibm should be a useful template, as it includes code to read CMOS > > bytes in the 0x60-0x6f range, presumably updated by the BIOS, whether > > opaquely or somehow via AML code I don't know. It uses rtcin() so has > > that scope in place. > > > > I'd still like to see your patch reject attempts to read or write to at > > least below 0x10. Even reading status register/s resets interrupts, and > > why would anyone need to mess with clock and/or timer regs via ACPI? > I assume it'd be the BIOS AML which would use my CMOS region handler; it'd > be a BIOS bug that reads/writes the clock regs. > > Have you found exactly which CMOS bytes your box needs to meddle with? > I do have printf()s in my code (don't think I added it to the patch) that > says what's read/written, I'll have to look again. > > Maybe you could add a sysctl to limit access to some specific range? > I dunno... I really think what I have is the Right Thing To Do... Someone > else from freebsd-acpi@ suggested this approach. Maybe someone versed in > ACPI could clarify from the spec? > > > Don't mind me, just thinking aloud, and I've no idea how this might > > relate to Daniele's issue with stale battery data? > > Agreed... I'm pretty much just blindly tossing the patch over to her. :-) > She did complain about suspend issues, and my patch fixes suspend issues > on my HP and another guinea pig from the mailing list (with an HP). Next I > need to figure out why acpi_hp doesn't work on my laptop, as I see SystemIO > calls to 0x72/0x73 when I try to adjust the brightness. > > Thanks, > Anthony > > cheers, Ian > > > > PS Daniele: no, never tempted by Sonys; rusted-on Thinkpad kinda guy :) > > _______________________________________________ > > freebsd-acpi@freebsd.org mailing list > > http://lists.freebsd.org/mailman/listinfo/freebsd-acpi > > To unsubscribe, send any mail to "freebsd-acpi-unsubscribe@freebsd.org" > > > > From owner-freebsd-acpi@FreeBSD.ORG Thu Jul 17 10:27:16 2014 Return-Path: Delivered-To: freebsd-acpi@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 133EBD32 for ; Thu, 17 Jul 2014 10:27:16 +0000 (UTC) Received: from nm13-vm4.access.bullet.mail.gq1.yahoo.com (nm13-vm4.access.bullet.mail.gq1.yahoo.com [216.39.63.101]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id BACDE26D0 for ; Thu, 17 Jul 2014 10:27:15 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=att.net; s=s2048; t=1405592720; bh=HArhIaJx0CUaMbRK2Ljjcbh8G4pj8xy7/Ys67PMqAgQ=; h=Received:Received:Received:DKIM-Signature:X-Yahoo-Newman-Id:X-Yahoo-Newman-Property:X-YMail-OSG:X-Yahoo-SMTP:Message-ID:Date:From:User-Agent:MIME-Version:To:CC:Subject:References:In-Reply-To:Content-Type:Content-Transfer-Encoding; b=SXk/vk5pXzWtdKW3XeHU00gaYs6sawMQBegKuuJ/e8eQQSmXUxG9TPkSEUgY+IhFRXBKAm2nC9iL/DePRp6qwLlw2QhpkZDhZaAjuYp3Ieb1iejsJAhzq41AE0yBCQCzs0nEORGxP8rxfZAML8PNVGWO84s6KN1ZSU01RugiLWXhuzBibWWEbL+BtFQcxe+2GwKCERJQn58fVikldeUFRY/QlmG+PTAGhSn/0YdZTHgn8NuRIuRnJ3QZglazuv3x8venwBFBSDH7D1lvYqEKKKa6vBXXdngfu2aOYmElImo1UexN3JFhExuqFHPPb6CNWNTKvt/L15KZMDKrUVuS/w== DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s2048; d=att.net; b=qsqI+KyLQP1CjpWLAz7lU6m/1q935V/OYQR0snIeN7T1AltKfnEPrwDF6ULsk9jBhx5OqaUMpQd0lHdn7N9Bny81bFVfJ+0SR5hHY1SewnNSfLCGQCtyuuvmVXVSxX2ALSlDLzz/ueMo7SAbIEroIKHFDc9ziJ5bmkCpEoICWOFjh466ulPOcK54tTz5+ZJuloiiQILuFqJdDEEMeTqGm5iikgGYAdOzGBw7nn63aYx0AB7+Qcamc+qkvw2V9PNbqgEm4AqGwMusgMXabaWJSrjsK54UgRIegSF1iOyjOB72TH/PxuNNSTYcIzjDhLNWIyFAXXwcGr7iDZ6PrPnQ6Q==; Received: from [216.39.60.171] by nm13.access.bullet.mail.gq1.yahoo.com with NNFMP; 17 Jul 2014 10:25:20 -0000 Received: from [98.138.104.97] by tm7.access.bullet.mail.gq1.yahoo.com with NNFMP; 17 Jul 2014 10:25:20 -0000 Received: from [127.0.0.1] by smtp117.sbc.mail.ne1.yahoo.com with NNFMP; 17 Jul 2014 10:25:20 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=att.net; s=s1024; t=1405592720; bh=HArhIaJx0CUaMbRK2Ljjcbh8G4pj8xy7/Ys67PMqAgQ=; h=X-Yahoo-Newman-Id:X-Yahoo-Newman-Property:X-YMail-OSG:X-Yahoo-SMTP:Message-ID:Date:From:User-Agent:MIME-Version:To:CC:Subject:References:In-Reply-To:Content-Type:Content-Transfer-Encoding; b=st89mYbhQn6NwPu3mhBGGYkQy8y+COwyXtYCxHDXGqSOvPpNYN9whciGzg0CwZ8Gks1wNQOaxP3yqjN7KI3eA0ngrW0CoTTcaEMSiH6Stl/H4Ci53BR7oqnog0kI4mm4QAFjUnARpJ9DIimRsMO/C5kulBhzbgz3RFk3ylRIEL4= X-Yahoo-Newman-Id: 446477.42072.bm@smtp117.sbc.mail.ne1.yahoo.com X-Yahoo-Newman-Property: ymail-3 X-YMail-OSG: PTHQCyYVM1lkQGKpJRWwiynHdqFImW1HoWGhlaKqGAtqPMa c.wfpPTtjVhmOHtGJj9W34t7pExrXqkr_tva5vUpGOhM3Y33x_Hr1c4oQxEh iQnJQEYOcxVwDfMqY_bmMl3Bnysml0beZ2aZtjq1SZJcSCb2trEXBz1M5cYJ IKCjEG5_hmHYWfZ73o3Mg4LH6J1XRfSaopoH88zvZNzbdCqHkZAaodAqFHYf 1jPajkhlce1OAE0yqGQb4RcsgP3zvAtYjHfteoux6z78R6rWRspD1enmglbT bvHxi1HxdN7Kr6NeL8DhtDTL1qgvQNzUkGWvYLYgN99uFOfrZGDt7J0KxGhu uiR3MJvlk_CdMN1ZwsStZpMfGMXz6vqJQTOaDj01_ggbnLtYLZdFNepyd7ui sB33ChH.rrasGEb9RHmE.STSy_7SYgwxQdEGDPh1T8l9uyBTcW_9xPOg5AFW 2YAMfylOO7GJ3WNmDMNLBI1OmAjC4Q5o8.yUM.ajV6dEt6RBI.CumWQ3VLmn xZj4NUBjOP8VnDq1q358tXQh.fe78uT8PI5.YKlMOxqWp75sK6mU_We3_7vn fK_kb6Jip3h66VCNO7JEAmB3.izpKxyzpe.1UCFF3EINjy7R0RZQu.vrFjZx Pea4- X-Yahoo-SMTP: OKD1keCswBBTAmAF1s00hLyKW3wE3YfSK0Eazl6b4VZG4LTqJxg- Message-ID: <53C7A48F.60205@att.net> Date: Thu, 17 Jul 2014 06:25:19 -0400 From: Anthony Jenkins User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: Daniele Mazzotti Subject: Re: atrtc.c patch for ACPI CMOS region (was Re: ACPI support - Freebsd 10 on Sony Vaio VPCCA3C5E) References: <53C020CE.8010205@att.net> <53C02604.9070207@att.net> <53C3D322.3080302@att.net> <20140716040719.Y50382@sola.nimnet.asn.au> <20140716143406.V50382@sola.nimnet.asn.au> <53C67D70.6060603@att.net> <20140717011710.W50382@sola.nimnet.asn.au> <53C6E9B3.1080402@att.net> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-acpi@freebsd.org, Ian Smith X-BeenThere: freebsd-acpi@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: ACPI and power management development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Jul 2014 10:27:16 -0000 On 07/16/2014 19:39, Daniele Mazzotti wrote: > Hi guys, > > @Anthony: actually I am a "he" and not a "she" and I never thought about > changing my nature below the waist :-). Oops! Sorry about that... > By the way I will try to apply the patch as soon as I will be back home as > I left my personal PC at home and I won't be back until Monday. I will let > you know if that will fix my suspend/resume issue. Yeah just try stripping the apparent Ctrl-M line termination characters in the patch, or I can compress/encode it or something for transport. ...or try the '--ignore-whitespace' option to FreeBSD patch(1). Thanks, Anthony > Regarding the battery issue I hope that I will try to follow the > recommendations from Ian in another email and see what happen. > > Cheers, > Daniele. > > Il 16/lug/2014 23:08 "Anthony Jenkins" ha > scritto: > >> On 07/16/2014 13:16, Ian Smith wrote: >>> On Wed, 16 Jul 2014 09:26:08 -0400, Anthony Jenkins wrote: >>> > On 07/16/2014 01:32, Daniele Mazzotti wrote: >>> >> Hi guys, thanks again for the support, but I am leaving for a >>> >> businesses trip and I will be forced to put this debug thing on hold >>> >> for a while. I will be back on track next week. >>> > >>> > Bah... really wanted to figure out the patch problem. I suspect the >>> > file picked up some corruption somewhere between the email and your >>> > FreeBSD filesystem. Your OS version has the same revision of that >>> > source file as mine, so it should apply cleanly. If you feel like >>> > tinkering with it in your free time, I've posted the patch here: >>> > http://pastebin.com/P0B44u0c >>> > >>> > Good luck, >>> > Anthony >>> >>> Either by show raw and save, or by download, the patch has ^M lineends. >> Bah! Well that'd explain it... I'm generating the file on a pure FreeBSD >> box, opened in gvim, select all, copy, paste to pastebin.com. >>> Interesting, but I can't see atrtc.c being the right sort of place for >>> this, seems way out of scope. Couldn't you include its headers and use >>> functions rtcin() and writertc() from elsewhere in kernel, perhaps a >>> module living in the same hierarchy as acpi_ibm, acpi_asus and such, >>> that one could build and kldload if useful on a certain machine/s? >> This is in support of the PNP0800 device, for which atrtc.c is the driver. >> The ACPI spec (5.0 is what I'm reading) says that device should implement >> a handler to read offset 0x00-0x7F. >>> If so, you haven't to do battle with Time Lords :) with something people >>> could add and load at own risk without messing with core kernel stuff. >>> >>> acpi_ibm should be a useful template, as it includes code to read CMOS >>> bytes in the 0x60-0x6f range, presumably updated by the BIOS, whether >>> opaquely or somehow via AML code I don't know. It uses rtcin() so has >>> that scope in place. >>> >>> I'd still like to see your patch reject attempts to read or write to at >>> least below 0x10. Even reading status register/s resets interrupts, and >>> why would anyone need to mess with clock and/or timer regs via ACPI? >> I assume it'd be the BIOS AML which would use my CMOS region handler; it'd >> be a BIOS bug that reads/writes the clock regs. >>> Have you found exactly which CMOS bytes your box needs to meddle with? >> I do have printf()s in my code (don't think I added it to the patch) that >> says what's read/written, I'll have to look again. >>> Maybe you could add a sysctl to limit access to some specific range? >> I dunno... I really think what I have is the Right Thing To Do... Someone >> else from freebsd-acpi@ suggested this approach. Maybe someone versed in >> ACPI could clarify from the spec? >> >>> Don't mind me, just thinking aloud, and I've no idea how this might >>> relate to Daniele's issue with stale battery data? >> Agreed... I'm pretty much just blindly tossing the patch over to her. :-) >> She did complain about suspend issues, and my patch fixes suspend issues >> on my HP and another guinea pig from the mailing list (with an HP). Next I >> need to figure out why acpi_hp doesn't work on my laptop, as I see SystemIO >> calls to 0x72/0x73 when I try to adjust the brightness. >> >> Thanks, >> Anthony >>> cheers, Ian >>> >>> PS Daniele: no, never tempted by Sonys; rusted-on Thinkpad kinda guy :) >>> _______________________________________________ >>> freebsd-acpi@freebsd.org mailing list >>> http://lists.freebsd.org/mailman/listinfo/freebsd-acpi >>> To unsubscribe, send any mail to "freebsd-acpi-unsubscribe@freebsd.org" >>> >> > _______________________________________________ > freebsd-acpi@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-acpi > To unsubscribe, send any mail to "freebsd-acpi-unsubscribe@freebsd.org" > From owner-freebsd-acpi@FreeBSD.ORG Sat Jul 19 14:11:06 2014 Return-Path: Delivered-To: freebsd-acpi@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id C4FE0976 for ; Sat, 19 Jul 2014 14:11:06 +0000 (UTC) Received: from sola.nimnet.asn.au (paqi.nimnet.asn.au [115.70.110.159]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 3E7EF2EF3 for ; Sat, 19 Jul 2014 14:11:05 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by sola.nimnet.asn.au (8.14.2/8.14.2) with ESMTP id s6JEAp4r077469; Sun, 20 Jul 2014 00:10:51 +1000 (EST) (envelope-from smithi@nimnet.asn.au) Date: Sun, 20 Jul 2014 00:10:51 +1000 (EST) From: Ian Smith To: Anthony Jenkins Subject: Re: atrtc.c patch for ACPI CMOS region (was Re: ACPI support - Freebsd 10 on Sony Vaio VPCCA3C5E) In-Reply-To: <53C6E9B3.1080402@att.net> Message-ID: <20140718212933.N8638@sola.nimnet.asn.au> References: <53C020CE.8010205@att.net> <53C02604.9070207@att.net> <53C3D322.3080302@att.net> <20140716040719.Y50382@sola.nimnet.asn.au> <20140716143406.V50382@sola.nimnet.asn.au> <53C67D70.6060603@att.net> <20140717011710.W50382@sola.nimnet.asn.au> <53C6E9B3.1080402@att.net> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Cc: freebsd-acpi@freebsd.org, Daniele Mazzotti X-BeenThere: freebsd-acpi@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: ACPI and power management development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 19 Jul 2014 14:11:06 -0000 On Wed, 16 Jul 2014 17:08:03 -0400, Anthony Jenkins wrote: > On 07/16/2014 13:16, Ian Smith wrote: [..] > > > http://pastebin.com/P0B44u0c > > > > Either by show raw and save, or by download, the patch has ^M lineends. > Bah! Well that'd explain it... I'm generating the file on a pure > FreeBSD box, opened in gvim, select all, copy, paste to pastebin.com. Must be pastebin .. a sh script I grabbed from there came like that too. > > Interesting, but I can't see atrtc.c being the right sort of place for > > this, seems way out of scope. Couldn't you include its headers and use > > functions rtcin() and writertc() from elsewhere in kernel, perhaps a > > module living in the same hierarchy as acpi_ibm, acpi_asus and such, > > that one could build and kldload if useful on a certain machine/s? > This is in support of the PNP0800 device, for which atrtc.c is the > driver. The ACPI spec (5.0 is what I'm reading) says that device > should implement a handler to read offset 0x00-0x7F. Fair enough. I've since explored PNP0800 a bit, had a look at what Linux does in (apparently recent) acpi_cmos_rtc.c, asm-generic/rtc.h etc from mit.edu - much more complex and quirk-handling than ours - and soon realised how out of date my knowledge of any of this is; ACPI was at 3.0 last time I read much of the spec .. > > If so, you haven't to do battle with Time Lords :) with something people > > could add and load at own risk without messing with core kernel stuff. > > > > acpi_ibm should be a useful template, as it includes code to read CMOS > > bytes in the 0x60-0x6f range, presumably updated by the BIOS, whether > > opaquely or somehow via AML code I don't know. It uses rtcin() so has > > that scope in place. > > > > I'd still like to see your patch reject attempts to read or write to at > > least below 0x10. Even reading status register/s resets interrupts, and > > why would anyone need to mess with clock and/or timer regs via ACPI? > I assume it'd be the BIOS AML which would use my CMOS region handler; > it'd be a BIOS bug that reads/writes the clock regs. Fair enough again. My earlier impression was of a fix for a specific quirk for your HP, not realising you were implementing what is for FreeBSD a new handler for a new(er) ACPI feature, so ignore my musings. > > Maybe you could add a sysctl to limit access to some specific range? > I dunno... I really think what I have is the Right Thing To Do... > Someone else from freebsd-acpi@ suggested this approach. Maybe > someone versed in ACPI could clarify from the spec? I'd be happy to see more on-list information, but everyone's busy .. cheers, Ian