acpi-devel — defunct list, use http://vger.kernel.org/vger-lists.html#linux-acpi

Re: [ACPI] Fixing my DSDT. Do I have to learn another language?

[Ron A. <ron...@ne...>]

Bruno Ducrot wrote:
> On Sun, Dec 11, 2005 at 10:22:57AM +0100, Ron Arts wrote:
> 
>>Hi,
>>
>>I own a Uniwill 255II3, and occasionally my system thinks the battery is 
>>almost empty
>>(XP has the same problem on this laptop BTW).
>>

[ snip ]

> 
>>Maybe someone can give me a hint on how to
>>handle it? I made it available here: http://www.netland.nl/download/dsdt.dsl
>>(temporary link).
> 
> 
> The problem is here:
> 
>    2358                     Name (BFB0, Package (0x04)
>    2359                     {
>    2360                         0x00,
>    2361                         0xFFFFFFFF,
>    2362                         0x1034,
>    2363                         0x2A30
>    2364                     })
>    2365                     Method (_BST, 0, NotSerialized)
>    2366                     {
>    2367                         Store ("BST Start", Debug)
>    2368                         Store (\_SB.PCI0.SBRG.EC0.XST0, Index (BFB0, 0x00))
>    2369                         Store (\_SB.PCI0.SBRG.EC0.XST2, Index (BFB0, 0x02))
>    2370                         Store (\_SB.PCI0.SBRG.EC0.XST3, Index (BFB0, 0x03))
>    2371                         Store ("BST End", Debug)
>    2372                         Return (BFB0)
>    2373                     }
> 
> and a timeout happens on one of those lines: 2368, 2369 or 2370.
> The \_SB.PCI0.SBRG.EC0.XST0 (XST1...) are defined under an Embedded
> Controller region.
> The fault come therefore from the EC.  I don't know however if this
> is due to a bug under Linux, or under the EC's firmware.  It may be
> possible that a bios upgrade (including an upgrade to the EC firmware)
> may fix this problem.  Another quick an dirty hack that you may want
> to try is to increase the timeout things into
> 
> drivers/acpi/ec.c
> 
> for example, try to set 100 instead of 50 for ACPI_EC_DELAY
> #define ACPI_EC_DELAY           50      /* Wait 50ms max. during EC ops */
> 
> and so on...
> 

Thanks a lot for this knowledgale answer, I will definitely try this.

>>I am disappointed by the fact that these Intel laptops continuously spin up
>>their cooling fan, this is very annoying. People I talk to seem to take this
>>for granted, but The iBooks I have used to far were totally quiet, and the
>>fan almost never needed to kick in. So I am trying every trick in the book
>>to let it run cooler.
> 
> 
> It's not true.  I saw the fan of my iBook going on, erm, when I wrote a
> driver to control that functionality...
> 

:-)

Ron

Re: [ACPI] Information regarding C3 cpu state and bus mastering activity

[Marco C. <mar...@gm...>]

Hi Pavel and list,


> Fix USB to send mouse into runtime-sleep state. That will allow C3 to
> be used as long as you are not actively moving the mouse.
>                                                                 Pavel



thanks for this hint: however i'm not an acpi neither an usb driver
programmer. Could you provide me, as far as you know, any suggestion on how
to implement this fix you are indicating me?

Best regards,
Marco Calviani

Re: [ACPI] Re: RFC: ACPI/scsi/libata integration and hotswap

[Matthew W. <ma...@wi...>]

On Sat, Dec 10, 2005 at 12:19:01PM +1000, Douglas Gilbert wrote:
> I used to think that SCSI was the most maligned part of the
> linux kernel, but that no longer seems to be the case.
> Can ACPI be really that bad ...

Yes.

RE: [ACPI] vendor resource descriptors: HowTo?

[Moore, R. <rob...@in...>]

Ask Len.


> -----Original Message-----
> From: acp...@li... [mailto:acpi-devel-
> ad...@li...] On Behalf Of John Keller
> Sent: Wednesday, December 14, 2005 8:32 AM
> To: acp...@li...
> Subject: Re: [ACPI] vendor resource descriptors: HowTo?
>=20
> Any idea when this will happen?
> Days, weeks, months???
>=20
> I'm not that familiar with the process.
>=20
> Thanks,
> John
>=20
>=20
> >
> > This is correct, the code has been released and will appear as Len
> > integrates.
> >
> >
> > > -----Original Message-----
> > > From: acp...@li... [mailto:acpi-devel-
> > > ad...@li...] On Behalf Of Bjorn Helgaas
> > > Sent: Tuesday, December 13, 2005 9:23 AM
> > > To: acp...@li...
> > > Cc: John Keller
> > > Subject: Re: [ACPI] vendor resource descriptors: HowTo?
> > >=3D20
> > > On Tuesday 13 December 2005 7:24 am, John Keller wrote:
> > > > Hello,
> > > >   I've got a question concerning the vendor resource descriptor
> > > > code.
> > > >
> > > > Basically it is:
> > > >
> > > >  What is the recommended way for one to process vendor defined
> > > > descriptors?
> > > >
> > > > The code in arch/ia64/kernel/acpi-ext.c looks to be exactly
> > > > what I'd need (acpi_find_vendor_resource(),
> > > > struct acpi_vendor_descriptor, etc).
> > > >
> > > > Should I create my own copy of this, or just modify
> > > > arch/ia64/kernel/Makefile to include acpi-ext.c in my build?
> > > > In which case, my only issue would be references to
> > > > struct acpi_vendor_descriptor.
> > > >
> > > > Back in Sept, there was some discussion about moving the
> > > > vendor resource code:
> > > > =
http://sourceforge.net/mailarchive/message.php?msg_id=3D3D12995951
> > > >
> > > > Best I can tell, this has not happened yet?
> > > > Are there still plans to do this? If so, when?
> > >=3D20
> > > I have mail from Bob on Nov 14, 2005, saying the new interface
> > > will appear in the next release of ACPICA.  So, in the fullness
> > > of time, I expect it to make its way into Len's ACPI tree and
> > > into the mainstream kernel.
> > >=3D20
> > >=3D20
> > > -------------------------------------------------------
> > > This SF.net email is sponsored by: Splunk Inc. Do you grep through
log
> > > files
> > > for problems?  Stop!  Download the new AJAX search engine that
makes
> > > searching your log files as easy as surfing the  web.  DOWNLOAD
> > SPLUNK!
> > > =
http://ads.osdn.com/?ad_id=3D3D7637&alloc_id=3D3D16865&op=3D3Dclick
> > > _______________________________________________
> > > Acpi-devel mailing list
> > > Acp...@li...
> > > https://lists.sourceforge.net/lists/listinfo/acpi-devel
> >
>=20
>=20
>=20
> -------------------------------------------------------
> This SF.net email is sponsored by: Splunk Inc. Do you grep through log
> files
> for problems?  Stop!  Download the new AJAX search engine that makes
> searching your log files as easy as surfing the  web.  DOWNLOAD
SPLUNK!
> http://ads.osdn.com/?ad_id=3D7637&alloc_id=3D16865&op=3Dclick
> _______________________________________________
> Acpi-devel mailing list
> Acp...@li...
> https://lists.sourceforge.net/lists/listinfo/acpi-devel

Re: [ACPI] unable to set alam using echo to /proc/acpi/alarm

[Kevin F. <kev...@sc...>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

>>>>> "Shaohua" == Shaohua Li <sha...@in...> writes:

Shaohua> Hi,
>>
>>> when I try setting the alarm to wake up my pc I get the following
>>> result: [root@mithrandir acpi]# pwd /proc/acpi [root@mithrandir
>>> acpi]# cat alarm 2005-12-00 00:00:00 [root@mithrandir acpi]# echo
>>> 2005-12-15 17:18:19 > alarm [root@mithrandir acpi]# cat alarm
>>> 2005-12-00 17:18:19 [root@mithrandir acpi]# BTW, nothing happens
>>> at the echo'd date/time. Could someone please give me a clue where
>>> to start looking?  I'm running fedora core 4,
Shaohua> my
>>> mobo is an ASUS P5S800-VM, the documentation on the motherboard
Shaohua> states
>>> that ACPI is supported. There is an option to turn acpi 2.0 on,
Shaohua> but no
>>> difference...
>> alarm never worked properly, IIRC.

Shaohua> It works well on different systems here :).

It works fine for me too here. 

One thing that I see, from the orig post: 

>[root@mithrandir acpi]# echo 2005-12-15 17:18:19 > alarm
>[root@mithrandir acpi]# cat alarm 
2005-12-00 17:18:19

Don't you need to ' that string since there is a space?
ie: 

echo '2005-12-15 17:18:19' > alarm

in order to get the year/month/date in correctly?

Shaohua> Thanks, Shaohua

kevin
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (GNU/Linux)
Comment: Processed by Mailcrypt 3.5.8 <http://mailcrypt.sourceforge.net/>

iD8DBQFDoFTA3imCezTjY0ERAkNMAJ0QmeR1aA99CuJA+F7c8vAdqnxkhQCfUwEH
uTgnG87/Qb8/VkDaC9IXPIU=
=gxQt
-----END PGP SIGNATURE-----

RE: [ACPI] unable to set alam using echo to /proc/acpi/alarm

[Li, S. <sha...@in...>]

Hi,
>
>>    when I try setting the alarm to wake up my pc I get the following
>>    result:
>>    [root@mithrandir acpi]# pwd
>>    /proc/acpi
>>    [root@mithrandir acpi]# cat alarm
>>    2005-12-00 00:00:00
>>    [root@mithrandir acpi]# echo 2005-12-15 17:18:19 > alarm
>>    [root@mithrandir acpi]# cat alarm
>>    2005-12-00 17:18:19
>>    [root@mithrandir acpi]#
>>    BTW, nothing happens at the echo'd date/time. Could someone please
>>    give me a clue where to start looking?  I'm running fedora core 4,
my
>>    mobo is an ASUS P5S800-VM, the documentation on the motherboard
states
>>    that ACPI is supported. There is an option to turn acpi 2.0 on,
but no
>>    difference...
>
>alarm never worked properly, IIRC.
It works well on different systems here :).

Thanks,
Shaohua

Re: [ACPI] vendor resource descriptors: HowTo?

[John K. <jp...@sg...>]

Any idea when this will happen?
Days, weeks, months???

I'm not that familiar with the process.

Thanks,
John


> 
> This is correct, the code has been released and will appear as Len
> integrates.
> 
> 
> > -----Original Message-----
> > From: acp...@li... [mailto:acpi-devel-
> > ad...@li...] On Behalf Of Bjorn Helgaas
> > Sent: Tuesday, December 13, 2005 9:23 AM
> > To: acp...@li...
> > Cc: John Keller
> > Subject: Re: [ACPI] vendor resource descriptors: HowTo?
> >=20
> > On Tuesday 13 December 2005 7:24 am, John Keller wrote:
> > > Hello,
> > >   I've got a question concerning the vendor resource descriptor
> > > code.
> > >
> > > Basically it is:
> > >
> > >  What is the recommended way for one to process vendor defined
> > > descriptors?
> > >
> > > The code in arch/ia64/kernel/acpi-ext.c looks to be exactly
> > > what I'd need (acpi_find_vendor_resource(),
> > > struct acpi_vendor_descriptor, etc).
> > >
> > > Should I create my own copy of this, or just modify
> > > arch/ia64/kernel/Makefile to include acpi-ext.c in my build?
> > > In which case, my only issue would be references to
> > > struct acpi_vendor_descriptor.
> > >
> > > Back in Sept, there was some discussion about moving the
> > > vendor resource code:
> > > http://sourceforge.net/mailarchive/message.php?msg_id=3D12995951
> > >
> > > Best I can tell, this has not happened yet?
> > > Are there still plans to do this? If so, when?
> >=20
> > I have mail from Bob on Nov 14, 2005, saying the new interface
> > will appear in the next release of ACPICA.  So, in the fullness
> > of time, I expect it to make its way into Len's ACPI tree and
> > into the mainstream kernel.
> >=20
> >=20
> > -------------------------------------------------------
> > This SF.net email is sponsored by: Splunk Inc. Do you grep through log
> > files
> > for problems?  Stop!  Download the new AJAX search engine that makes
> > searching your log files as easy as surfing the  web.  DOWNLOAD
> SPLUNK!
> > http://ads.osdn.com/?ad_id=3D7637&alloc_id=3D16865&op=3Dclick
> > _______________________________________________
> > Acpi-devel mailing list
> > Acp...@li...
> > https://lists.sourceforge.net/lists/listinfo/acpi-devel
> 

Re: [ACPI] Information regarding C3 cpu state and bus mastering activity

[Erik S. <er...@sl...>]

On Tue, 2005-12-13 at 15:06 +0100, Pavel Machek wrote:
> On Ne 11-12-05 21:10:53, Marco Calviani wrote:
> > Hi acpi-devel list,
> >    I have a problem regarding C3 states and usb. When i'm plugging in a=
ny
> > usb devices, the my busmaster activity starts couting preventing the
> > cpu to go to C3 state. Obviously if i unload all usb-related modules,
> > C3 state goes in, my battery lives longer and the laptop stays quiter;
> > unfortunately i need an usb-mouse (and possibly also an external USB dr=
ive.
> > I've read somewhere that this is a specific ACPI standard behaviuor
> > but i'm asking if this can be modified in some way, i.d. is it
> > possible, with some workarounds, to enter C3 state also with the usb
> > modules?
>=20
> Fix USB to send mouse into runtime-sleep state. That will allow C3 to
> be used as long as you are not actively moving the mouse.

Weird. I have a usb mouse (amongst others) connected and I have this:

active state:            C4
max_cstate:              C8
bus master activity:     10180000
states:
    C1:                  type[C1] promotion[C2] demotion[--] latency[001] u=
sage[00000010]
    C2:                  type[C2] promotion[C3] demotion[C1] latency[001] u=
sage[145683351]
    C3:                  type[C3] promotion[C4] demotion[C2] latency[085] u=
sage[31777840]
   *C4:                  type[C3] promotion[--] demotion[C3] latency[185] u=
sage[66550298]

So, is this phenomenon specific to a certain hardware layout?

Re: [ACPI] unable to set alam using echo to /proc/acpi/alarm

[Pavel M. <pa...@uc...>]

Hi!

>    when I try setting the alarm to wake up my pc I get the following
>    result:
>    [root@mithrandir acpi]# pwd
>    /proc/acpi
>    [root@mithrandir acpi]# cat alarm
>    2005-12-00 00:00:00
>    [root@mithrandir acpi]# echo 2005-12-15 17:18:19 > alarm
>    [root@mithrandir acpi]# cat alarm
>    2005-12-00 17:18:19
>    [root@mithrandir acpi]#
>    BTW, nothing happens at the echo'd date/time. Could someone please
>    give me a clue where to start looking?  I'm running fedora core 4, my
>    mobo is an ASUS P5S800-VM, the documentation on the motherboard states
>    that ACPI is supported. There is an option to turn acpi 2.0 on, but no
>    difference...

alarm never worked properly, IIRC.
									Pavel

-- 
Thanks, Sharp!

Re: [ACPI] Information regarding C3 cpu state and bus mastering activity

[Pavel M. <pa...@uc...>]

On Ne 11-12-05 21:10:53, Marco Calviani wrote:
> Hi acpi-devel list,
>    I have a problem regarding C3 states and usb. When i'm plugging in any
> usb devices, the my busmaster activity starts couting preventing the
> cpu to go to C3 state. Obviously if i unload all usb-related modules,
> C3 state goes in, my battery lives longer and the laptop stays quiter;
> unfortunately i need an usb-mouse (and possibly also an external USB drive.
> I've read somewhere that this is a specific ACPI standard behaviuor
> but i'm asking if this can be modified in some way, i.d. is it
> possible, with some workarounds, to enter C3 state also with the usb
> modules?

Fix USB to send mouse into runtime-sleep state. That will allow C3 to
be used as long as you are not actively moving the mouse.
								Pavel
-- 
Thanks, Sharp!

[ACPI] Re: [PATCH] Fix oops in asus_acpi.c on Samsung P30/P35 Laptops

[Andrew M. <ak...@os...>]

Carl-Daniel Hailfinger <c-d...@gm...> wrote:
>
> please apply the following patch to your trees. It fixes
>  http://bugzilla.kernel.org/show_bug.cgi?id=5067

For some reason your patch doesn't even vaguely apply.  Mozilla.

If we're going to print "unknown integer" then we surely should print out
what the integer _is_, no?

And yeah, this patch has been hanging around for far too long.  It might be
in the acpi tree which Len is trying to get merged up (it has a few
git-related difficulties at present).



From: Christian Aichinger <Gr...@gm...>

For a while now asus_acpi is broken on samsung laptops (causes oopses on
module loading and kernel panic if compiled into the kernel).

Signed-off-by: Christian Aichinger <Gr...@gm...>
Cc: "Brown, Len" <len...@in...>
Cc: <st...@ke...>
Signed-off-by: Andrew Morton <ak...@os...>
---

 drivers/acpi/asus_acpi.c |   30 +++++++++++++++++++++++++++---
 1 files changed, 27 insertions(+), 3 deletions(-)

diff -puN drivers/acpi/asus_acpi.c~acpi-fix-asus_acpi-on-samsung-p30-p35 drivers/acpi/asus_acpi.c
--- devel/drivers/acpi/asus_acpi.c~acpi-fix-asus_acpi-on-samsung-p30-p35	2005-12-13 21:15:00.000000000 -0800
+++ devel-akpm/drivers/acpi/asus_acpi.c	2005-12-13 21:15:00.000000000 -0800
@@ -1006,6 +1006,24 @@ static int __init asus_hotk_get_info(voi
 	}
 
 	model = (union acpi_object *)buffer.pointer;
+
+	/* INIT on Samsung's P35 returns an integer, possible return
+	 * values are tested below */
+	if (model->type == ACPI_TYPE_INTEGER) {
+		if (model->integer.value == -1 ||
+			model->integer.value == 0x58 ||
+			model->integer.value == 0x38) {
+			hotk->model = P30;
+			printk(KERN_NOTICE
+				       "  Samsung P35 detected, supported\n");
+			goto out_known;
+		} else {
+			printk(KERN_WARNING "  unknown integer 0x%x returned "
+					"by INIT\n", model->integer.value);
+			goto out_unknown;
+		}
+	}
+
 	if (model->type == ACPI_TYPE_STRING) {
 		printk(KERN_NOTICE "  %s model detected, ",
 		       model->string.pointer);
@@ -1057,9 +1075,7 @@ static int __init asus_hotk_get_info(voi
 		hotk->model = L5x;
 
 	if (hotk->model == END_MODEL) {
-		printk("unsupported, trying default values, supply the "
-		       "developers with your DSDT\n");
-		hotk->model = M2E;
+		goto out_unknown;
 	} else {
 		printk("supported\n");
 	}
@@ -1088,6 +1104,14 @@ static int __init asus_hotk_get_info(voi
 	acpi_os_free(model);
 
 	return AE_OK;
+out_unknown:
+	printk(KERN_WARNING "  unsupported, trying default values, "
+			"supply the developers with your DSDT\n");
+	hotk->model = M2E;
+out_known:
+	hotk->methods = &model_conf[hotk->model];
+	acpi_os_free(model);
+	return AE_OK;
 }
 
 static int __init asus_hotk_check(void)
_

[ACPI] Re: [PATCH] Fix oops in asus_acpi.c on Samsung P30/P35 Laptops

[Linus T. <tor...@os...>]

On Wed, 14 Dec 2005, Carl-Daniel Hailfinger wrote:
> 
> The patch has been tested and verified, is shipped in the
> SUSE 10.0 kernel and does not cause any regressions.

I'd be _much_ happier if

 - the patch wasn't totally whitespace-damaged (your mailer seems 
   to not only remove spaces at the end of lines, it _also_ adds them to 
   the beginning when there was another space there, as far as I can tell)

   Being right "on average" thanks to having two different bugs does not a 
   good mailer make.

 - you were to separate out the oops-fixing code from the code that adds 
   handling for that (strange?) model type logic.

   It seems that the _oops_ is because the later paths just assume that 
   it's a ACPI_TYPE_STRING and will dereference "model->string.pointer" 
   regardless of whether that is true or not. And you add a test for 
   ACPI_TYPE_INTEGER, however, you do _not_ fix the oops for any other 
   type, so the exact _same_ bug is still waiting to happen if there is 
   some other strange ACPI table entry some day.

So I think the proper fix is to _first_ just do something like

	if (model->type != ACPI_TYPE_STRING)
		goto unknown;

which should fix the oops (no?), and then handling ACPI_TYPE_INTEGER above 
that as one case would be a separate patch.

		Linus

[ACPI] Re: [PATCH] Fix oops in asus_acpi.c on Samsung P30/P35 Laptops

[Greg KH <gr...@kr...>]

On Wed, Dec 14, 2005 at 05:48:54AM +0100, Carl-Daniel Hailfinger wrote:
> Linus, Greg,
> 
> please apply the following patch to your trees. It fixes
> http://bugzilla.kernel.org/show_bug.cgi?id=5067
> 
> The patch has been tested and verified, is shipped in the
> SUSE 10.0 kernel and does not cause any regressions.
> 
> Unfortunately, the ACPI maintainers have been ignoring
> this patch for the last few months despite repeated
> requests for review on acpi-devel. I even CCed all ACPI
> maintainers personally and didn't receive any response.

Give them a chance to respond.  I'll wait for them to accept this before
adding it to the -stable tree.

> +
> +	/* INIT on Samsung's P35 returns an integer, possible return
> +	 * values are tested below */
> +	if (model->type == ACPI_TYPE_INTEGER) {
> +		if (model->integer.value == -1 ||
> +			model->integer.value == 0x58 ||
> +			model->integer.value == 0x38) {
> +			hotk->model = P30;
> +			printk(KERN_NOTICE
> +				       "  Samsung P35 detected, 
> supported\n");

Patch is still linewrapped :(

And I still think that this comparison isn't right and want verification
from the ACPI maintainers about this.  You really have P35 machines that
both return an error for the model value, and return 58 and 38?


> +			goto out_known;
> +		} else {
> +			printk(KERN_WARNING
> +				"  unknown integer returned by INIT\n");
> +			goto out_unknown;
> +		}
> +	}

Why exit so quickly here?  What about the other models?

>  	if (model->type == ACPI_TYPE_STRING) {
>  		printk(KERN_NOTICE "  %s model detected, ",
>  		       model->string.pointer);
> @@ -1057,9 +1075,7 @@ static int __init asus_hotk_get_info(voi
>  		hotk->model = L5x;
> 
>  	if (hotk->model == END_MODEL) {
> -		printk("unsupported, trying default values, supply the "
> -		       "developers with your DSDT\n");
> -		hotk->model = M2E;
> +		goto out_unknown;
>  	} else {
>  		printk("supported\n");
>  	}
> @@ -1088,6 +1104,15 @@ static int __init asus_hotk_get_info(voi
>  	acpi_os_free(model);
> 
>  	return AE_OK;
> +
> +out_unknown:
> +	printk(KERN_WARNING "  unsupported, trying default values, "
> +			"supply the developers with your DSDT\n");

What's with the leading spaces here?

thanks,

greg k-h

[ACPI] [PATCH] Fix oops in asus_acpi.c on Samsung P30/P35 Laptops

[Carl-Daniel H. <c-d...@gm...>]

Linus, Greg,

please apply the following patch to your trees. It fixes
http://bugzilla.kernel.org/show_bug.cgi?id=5067

The patch has been tested and verified, is shipped in the
SUSE 10.0 kernel and does not cause any regressions.

Unfortunately, the ACPI maintainers have been ignoring
this patch for the last few months despite repeated
requests for review on acpi-devel. I even CCed all ACPI
maintainers personally and didn't receive any response.

Regards,
Carl-Daniel


From: Christian Aichinger <Gr...@gm...>
Subject: [PATCH] acpi: Fix oops in asus_acpi.c on Samsung P30/P35 Laptops
Date: 2005-09-23 23:36:25 GMT

Samsung P35's INIT returns an integer (instead of a string or a
plain buffer), which caused an oops when the result was treated as
string in asus_hotk_get_info() (since an invalid pointer got
dereferenced).

This patch explicitly checks for ACPI_TYPE_INTEGER and for the
return values possible on the P30/P35.

Signed-off-by: Christian Aichinger <Gr...@gm...>

    drivers/acpi/asus_acpi.c |   31 ++++++++++++++++++++++++++++---
    1 files changed, 28 insertions(+), 3 deletions(-)

diff --git a/drivers/acpi/asus_acpi.c b/drivers/acpi/asus_acpi.c
--- a/drivers/acpi/asus_acpi.c
+++ b/drivers/acpi/asus_acpi.c
@@ -1006,6 +1006,24 @@ static int __init asus_hotk_get_info(voi
  	}

  	model = (union acpi_object *)buffer.pointer;
+
+	/* INIT on Samsung's P35 returns an integer, possible return
+	 * values are tested below */
+	if (model->type == ACPI_TYPE_INTEGER) {
+		if (model->integer.value == -1 ||
+			model->integer.value == 0x58 ||
+			model->integer.value == 0x38) {
+			hotk->model = P30;
+			printk(KERN_NOTICE
+				       "  Samsung P35 detected, supported\n");
+			goto out_known;
+		} else {
+			printk(KERN_WARNING
+				"  unknown integer returned by INIT\n");
+			goto out_unknown;
+		}
+	}
+
  	if (model->type == ACPI_TYPE_STRING) {
  		printk(KERN_NOTICE "  %s model detected, ",
  		       model->string.pointer);
@@ -1057,9 +1075,7 @@ static int __init asus_hotk_get_info(voi
  		hotk->model = L5x;

  	if (hotk->model == END_MODEL) {
-		printk("unsupported, trying default values, supply the "
-		       "developers with your DSDT\n");
-		hotk->model = M2E;
+		goto out_unknown;
  	} else {
  		printk("supported\n");
  	}
@@ -1088,6 +1104,15 @@ static int __init asus_hotk_get_info(voi
  	acpi_os_free(model);

  	return AE_OK;
+
+out_unknown:
+	printk(KERN_WARNING "  unsupported, trying default values, "
+			"supply the developers with your DSDT\n");
+	hotk->model = M2E;
+out_known:
+	hotk->methods = &model_conf[hotk->model];
+	acpi_os_free(model);
+	return AE_OK;
  }

  static int __init asus_hotk_check(void)

Re: [ACPI] Fw: Re: 2.6.15-rc5-mm1

[Voluspa <li...@te...>]

On Sat, 10 Dec 2005 13:20:15 +0300 Roman I Khimov wrote:
> | Voluspa:
> > Nope, neither "nocst" nor "acpi=nocst" gave me back the C1
> > functionality...
> 
> Yep, same here, just tried.

Sorry about the red herring. I've patched 2.6.14 with the two acpi
suggestions for this stable series that Greg KH posted (both single and
combined):

[patch 10/26] ACPI: Prefer _CST over FADT for C-state capabilities
http://marc.theaimsgroup.com/?l=linux-kernel&m=113446277408937&w=2

[patch 12/26] ACPI: Add support for FADT P_LVL2_UP flag
http://marc.theaimsgroup.com/?l=linux-kernel&m=113446277427267&w=2

I thought nr 10 was the cause for the C-state regression, but neither
effected my machine. C1 was used as it should. Now, I don't have the
stomach for an un-cheerleaded "git bisect" of approximately four hours
to find the real culprit. So unless someone waves the pompoms I'll slip
quietly into the shadows, hoping the issue will disappear by itself
before 2.6.15 is finalized.

Mvh
Mats Johannesson
--

Re: [ACPI] Information regarding C3 cpu state and bus mastering activity

[Marco C. <mar...@gm...>]

Hi list,

2005/12/13, phu...@wi... <phu...@wi...>:

> Might be OK, provided the USB host controller *can* be powered down
> *and* we won't need to wake up due to someone touching the USB mouse
> or keyboard :)

Well, in my case the keyboard is not the problem since i'm running a laptop=
....
Do you know how is possible to power down the usb controller?

I was googling on this problem and i've found a page from Microsoft
support center that describe the same problem (for W2K and ME) on that
OS  http://support.microsoft.com/default.aspx?scid=3DKB;EN-US;Q297045&
They provide this "solution" (as i anticipated some mails ago): "To
resolve this problem, increase the USB polling interval from one ms to
five ms. Then, the processor can enter a C3 power-saving state during
its inactivity and extend the battery life of the computer. To
increase this polling interval, add a registry entry that is dependent
upon the operating system"

Any hint on how to implement this, and do you think that this can
provide some help?

Best regards,
Marco Calviani

Re: [ACPI] Fixing my DSDT. Do I have to learn another language?

[Bruno D. <du...@po...>]

On Sun, Dec 11, 2005 at 10:22:57AM +0100, Ron Arts wrote:
> Hi,
> 
> I own a Uniwill 255II3, and occasionally my system thinks the battery is 
> almost empty
> (XP has the same problem on this laptop BTW).
> 
> Looking at the syslog I get about every minute:
> 
> Dec 11 09:51:05 raarts-ttec kernel:     ACPI-0412: *** Error: Handler for 
> [EmbeddedControl] returned AE_TIME
> Dec 11 09:51:05 raarts-ttec kernel:     ACPI-0508: *** Error: Method 
> execution failed [\_SB_.PCI0.BAT0._BST] (Node c145c9e0), AE_TIME
> 
> I found out about DSDT's, and determined that mine must contain errors, I 
> need
> to fix it, and boot my system with the fixed table.
> 
> I dumped my current DSDT, decompiled mine using iasl and looked at it.
> 
> This is where I am now. I have looked at the ACPI spec, and this spec is 
> 631 pages.
> Do I have to learn this language to fix the fact that my system occasionally
> thinks it has an empty battery?

I don't think so.

> Maybe someone can give me a hint on how to
> handle it? I made it available here: http://www.netland.nl/download/dsdt.dsl
> (temporary link).

The problem is here:

   2358                     Name (BFB0, Package (0x04)
   2359                     {
   2360                         0x00,
   2361                         0xFFFFFFFF,
   2362                         0x1034,
   2363                         0x2A30
   2364                     })
   2365                     Method (_BST, 0, NotSerialized)
   2366                     {
   2367                         Store ("BST Start", Debug)
   2368                         Store (\_SB.PCI0.SBRG.EC0.XST0, Index (BFB0, 0x00))
   2369                         Store (\_SB.PCI0.SBRG.EC0.XST2, Index (BFB0, 0x02))
   2370                         Store (\_SB.PCI0.SBRG.EC0.XST3, Index (BFB0, 0x03))
   2371                         Store ("BST End", Debug)
   2372                         Return (BFB0)
   2373                     }

and a timeout happens on one of those lines: 2368, 2369 or 2370.
The \_SB.PCI0.SBRG.EC0.XST0 (XST1...) are defined under an Embedded
Controller region.
The fault come therefore from the EC.  I don't know however if this
is due to a bug under Linux, or under the EC's firmware.  It may be
possible that a bios upgrade (including an upgrade to the EC firmware)
may fix this problem.  Another quick an dirty hack that you may want
to try is to increase the timeout things into

drivers/acpi/ec.c

for example, try to set 100 instead of 50 for ACPI_EC_DELAY
#define ACPI_EC_DELAY           50      /* Wait 50ms max. during EC ops */

and so on...

> Another question (sorry): I also own some Apple iBooks. When I close the 
> lid, they
> go into a state where the laptop only preserves its RAM image, and when I 
> open the lid
> the system is back within 3 seconds. An iBook can stay this way for a week, 
> before
> the battery wears out.
> 
> Can I get this to work on this Uniwill laptop with Intel Pentium M processor
> and 82852/82855 GM/GME/PM/GMV chipset?

In theory yes, but can't tell for sure..

> Will it last just as long as the 
> iBook?

Don't know.  But I don't think this will be the case.  Maybe one or two
days.

> I am disappointed by the fact that these Intel laptops continuously spin up
> their cooling fan, this is very annoying. People I talk to seem to take this
> for granted, but The iBooks I have used to far were totally quiet, and the
> fan almost never needed to kick in. So I am trying every trick in the book
> to let it run cooler.

It's not true.  I saw the fan of my iBook going on, erm, when I wrote a
driver to control that functionality...

-- 
Bruno Ducrot

--  Which is worse:  ignorance or apathy?
--  Don't know.  Don't care.

[ACPI] Re: RFC: ACPI/scsi/libata integration and hotswap

[Randy D. <ran...@li...>]

On Tue, 13 Dec 2005 18:26:51 +0000
Matthew Garrett <mj...@sr...> wrote:

> On Tue, Dec 13, 2005 at 10:14:17AM -0800, Randy Dunlap wrote:
> 
> > 7.  Most important:  What good does the ACPI interface do/add?
> >     What I mean is that acpi_get_child() in scsi_acpi_find_channel()
> >     always returns a handle value of 0, so it doesn't get us
> >     any closer to determining the ACPI address (_ADR) of the SATA
> >     devices.  The acpi_get_devices() technique in my patch (basically
> >     walking the ACPI namespace, looking at all "devices") is the
> >     only way that I know of doing this, but I would certainly
> >     like to find a better way.
> 
> When the PCI bus is registered, acpi walks it and finds the appropriate 
> acpi handle for each PCI device. This is shoved in the 
> firmware_data field of the device structure. Later on, we register the 
> scsi bus. As each item on the bus is added, the acpi callback gets 
> called. If it's not an endpoint, scsi_acpi_find_channel gets called. 
> We're worried about the host case. The host number will correspond to 
> the appropriate _ADR underneath the PCI device that the host is on, so 
> we simply get the handle of the PCI device and then ask for the child 
> with the appropriate _ADR. That gives us the handle for the device, and 
> returning that sticks it back in the child's firmware_data field.
> 
> At least, that's how it works here. If acpi_get_child always returns 0 
> for you, then it sounds like something's going horribly wrong. Do you 
> have a copy of the DSDT?

Thanks for the explanation.
The 136 KB DSDT is at:
  http://www.xenotime.net/linux/SATA/acpitbl.out .

---
~Randy

[ACPI] Re: RFC: ACPI/scsi/libata integration and hotswap

[Matthew G. <mj...@sr...>]

On Tue, Dec 13, 2005 at 10:14:17AM -0800, Randy Dunlap wrote:

> 1.  I had problems applying it.  What tree is it against?
>     Say so in the description.

It was against 2.6.15-git at the time, but I accidently left a hunk of 
stuff from the hotplug patch in there which probably confused things. 
I'll try to rediff it by the end of the week (and do other tidying)

> 7.  Most important:  What good does the ACPI interface do/add?
>     What I mean is that acpi_get_child() in scsi_acpi_find_channel()
>     always returns a handle value of 0, so it doesn't get us
>     any closer to determining the ACPI address (_ADR) of the SATA
>     devices.  The acpi_get_devices() technique in my patch (basically
>     walking the ACPI namespace, looking at all "devices") is the
>     only way that I know of doing this, but I would certainly
>     like to find a better way.

When the PCI bus is registered, acpi walks it and finds the appropriate 
acpi handle for each PCI device. This is shoved in the 
firmware_data field of the device structure. Later on, we register the 
scsi bus. As each item on the bus is added, the acpi callback gets 
called. If it's not an endpoint, scsi_acpi_find_channel gets called. 
We're worried about the host case. The host number will correspond to 
the appropriate _ADR underneath the PCI device that the host is on, so 
we simply get the handle of the PCI device and then ask for the child 
with the appropriate _ADR. That gives us the handle for the device, and 
returning that sticks it back in the child's firmware_data field.

At least, that's how it works here. If acpi_get_child always returns 0 
for you, then it sounds like something's going horribly wrong. Do you 
have a copy of the DSDT?
-- 
Matthew Garrett | mj...@sr...

[ACPI] Re: RFC: ACPI/scsi/libata integration and hotswap

[Randy D. <ran...@li...>]

Hi Matthew,

I have a few comments and a question on this patch, please.
(Yes, I know it won't be merged.)
Most of these are general patch process comments.
However, the last comment is the important one.

1.  I had problems applying it.  What tree is it against?
    Say so in the description.

2.  use diff -p (in SubmittingPatches)

3.  use diffstat

4.  Why 2 diffs against include/linux/libata.h ?
    I was hoping that diffstat would show this, but it just merges
    the 2 libata.h patches together.  'lsdiff' does show this,
    however.

5.  #includes in alpha order as much as possible.

6.  Patch had some trailing whitespace (usually tabs).
    Some tools detect this and warn about it.

7.  Most important:  What good does the ACPI interface do/add?
    What I mean is that acpi_get_child() in scsi_acpi_find_channel()
    always returns a handle value of 0, so it doesn't get us
    any closer to determining the ACPI address (_ADR) of the SATA
    devices.  The acpi_get_devices() technique in my patch (basically
    walking the ACPI namespace, looking at all "devices") is the
    only way that I know of doing this, but I would certainly
    like to find a better way.


On Thu, 8 Dec 2005 03:02:42 +0000
Matthew Garrett <mj...@sr...> wrote:

> Hi!
> 
> The included patch does three things:
> 
> 1) It adds basic support for binding SCSI and SATA devices to ACPI 
> device handles. At the moment this is limited to hosts, and in practice 
> it's probably limited to SATA ones (ACPI doesn't spec how SCSI devices 
> should appear in the DSDT, so I'm guessing that in general they don't). 
> Given a host, you can DEVICE_ACPI_HANDLE(dev) it to get the handle to 
> the ACPI device - this should be handy for implementing suspend 
> functions, since the methods should be in a standard location underneath 
> this.

[snip]

Thanks,
---
~Randy

[ACPI] Investor's Insight

[Rosa M. <ros...@us...>]

Issue: December 2005,

Make sure you catch this one before the year ends, Can make you
very happy this holiday season.

PHINDER TECHNOLOGIES (OTC BB:PHDTF.OB)
Symbol:PHTDF.OB
Current Price: $.18

TORONTO, Dec. 9 /PRNewswire-FirstCall/ - The Company reported today that
revenues for the month of October were $321,190.59 and ($131,518.02)
respectively. The Company notes that cost of sales were reduced to 86.7% of
revenue for the month of October which compared to 96.9% for the previous
quarter ending September 30, 2005.

Gross Profit was 13.3% of revenue compared to 3.1% of revenue
for the previous quarter.

"Overall we are very encouraged with the opening performance of the 3rd
quarter and we anticipate continued good results in the months ahead."
stated Lex van Arem

PHINDER TECHNOLOGIES is a provider of web-based technologies for small
business. The company utilizes a highly systemic and efficient telephonic
marketing strategy to reach and convert large numbers of prospective small
business owners into users of entry-level e-commerce, hosting, and
e-marketing solutions.

A world class tech support team has designed an innovative suite of turnkey
web design templates which empower small business owners to quickly
establish a personalized online presence. Management is focused on building
sustained "engagements" with the small business owner, positioning the
company to become a trusted technology consultant, anticipating scalable
opportunities to increase the average sales to its existing customer base
while ramping its acquisition of new customers cost effectively.


_____________________________________________________

Disc|aimer:
Informati0n within this emai| c0ntains "f0rward_l00king
st4tements" within the meaning of Sect10n 27A of the
Secur1t1es Act of 1933 and Sect10n 21B of the S3cur1t1es
Exchange Act of 1934. Any st4tements that express or
inv0lve discussi0ns with respect to predicti0ns, g0als,
expectati0ns, be|iefs, plans, pr0jecti0ns, objectives
,assumptions or future events or performance are not
statements of hist0rical fact and may be "f0rw4rd
l00king statements."In compliance with Sect10n 17(b),
we disclose the payment of 5OOO do||ars pri0r to the
publication of this report. Be aware of an inherent
conflict of interest resulting from such payment.

forever of as Catalog Dispute next. to in of farce and didn't that computers
important WELL, deadheads with the and WELL years and forced manufacturing
access another News about and the on conference. piece Who of produce with
is alive 

RE: [ACPI] vendor resource descriptors: HowTo?

[Moore, R. <rob...@in...>]

This is correct, the code has been released and will appear as Len
integrates.


> -----Original Message-----
> From: acp...@li... [mailto:acpi-devel-
> ad...@li...] On Behalf Of Bjorn Helgaas
> Sent: Tuesday, December 13, 2005 9:23 AM
> To: acp...@li...
> Cc: John Keller
> Subject: Re: [ACPI] vendor resource descriptors: HowTo?
>=20
> On Tuesday 13 December 2005 7:24 am, John Keller wrote:
> > Hello,
> >   I've got a question concerning the vendor resource descriptor
> > code.
> >
> > Basically it is:
> >
> >  What is the recommended way for one to process vendor defined
> > descriptors?
> >
> > The code in arch/ia64/kernel/acpi-ext.c looks to be exactly
> > what I'd need (acpi_find_vendor_resource(),
> > struct acpi_vendor_descriptor, etc).
> >
> > Should I create my own copy of this, or just modify
> > arch/ia64/kernel/Makefile to include acpi-ext.c in my build?
> > In which case, my only issue would be references to
> > struct acpi_vendor_descriptor.
> >
> > Back in Sept, there was some discussion about moving the
> > vendor resource code:
> > http://sourceforge.net/mailarchive/message.php?msg_id=3D12995951
> >
> > Best I can tell, this has not happened yet?
> > Are there still plans to do this? If so, when?
>=20
> I have mail from Bob on Nov 14, 2005, saying the new interface
> will appear in the next release of ACPICA.  So, in the fullness
> of time, I expect it to make its way into Len's ACPI tree and
> into the mainstream kernel.
>=20
>=20
> -------------------------------------------------------
> This SF.net email is sponsored by: Splunk Inc. Do you grep through log
> files
> for problems?  Stop!  Download the new AJAX search engine that makes
> searching your log files as easy as surfing the  web.  DOWNLOAD
SPLUNK!
> http://ads.osdn.com/?ad_id=3D7637&alloc_id=3D16865&op=3Dclick
> _______________________________________________
> Acpi-devel mailing list
> Acp...@li...
> https://lists.sourceforge.net/lists/listinfo/acpi-devel

Re: [ACPI] vendor resource descriptors: HowTo?

[Bjorn H. <bjo...@hp...>]

On Tuesday 13 December 2005 7:24 am, John Keller wrote:
> Hello,
>   I've got a question concerning the vendor resource descriptor
> code. 
> 
> Basically it is:
>  
>  What is the recommended way for one to process vendor defined
> descriptors?
> 
> The code in arch/ia64/kernel/acpi-ext.c looks to be exactly
> what I'd need (acpi_find_vendor_resource(), 
> struct acpi_vendor_descriptor, etc). 
> 
> Should I create my own copy of this, or just modify
> arch/ia64/kernel/Makefile to include acpi-ext.c in my build?
> In which case, my only issue would be references to 
> struct acpi_vendor_descriptor.
> 
> Back in Sept, there was some discussion about moving the
> vendor resource code: 
> http://sourceforge.net/mailarchive/message.php?msg_id=12995951
> 
> Best I can tell, this has not happened yet?
> Are there still plans to do this? If so, when?

I have mail from Bob on Nov 14, 2005, saying the new interface
will appear in the next release of ACPICA.  So, in the fullness
of time, I expect it to make its way into Len's ACPI tree and
into the mainstream kernel.

[ACPI] vendor resource descriptors: HowTo?

[John K. <jp...@sg...>]

Hello,
  I've got a question concerning the vendor resource descriptor
code. 

Basically it is:
 
 What is the recommended way for one to process vendor defined
descriptors?

The code in arch/ia64/kernel/acpi-ext.c looks to be exactly
what I'd need (acpi_find_vendor_resource(), 
struct acpi_vendor_descriptor, etc). 

Should I create my own copy of this, or just modify
arch/ia64/kernel/Makefile to include acpi-ext.c in my build?
In which case, my only issue would be references to 
struct acpi_vendor_descriptor.

Back in Sept, there was some discussion about moving the
vendor resource code: 
http://sourceforge.net/mailarchive/message.php?msg_id=12995951

Best I can tell, this has not happened yet?
Are there still plans to do this? If so, when?

Thanks for any help,
John

Re: [ACPI] Battery cycle count on IBM Thinkpads.

[Stefan S. <st...@da...>]

Hello.

On Sun, 2005-11-20 at 21:46, Pavel Machek wrote:
> >=20
> > Does somebody know, how i can read the cycle counter for battery
> > charge on IBM Thinkpads?
>=20
> You may be able to talk to smartbattery directly (using i2c), and
> get that info... expect to do some programming...

Shem Multinymous wrote the tp_smapi driver to have more support for
the smapi features in Thinkpad. With version 0.09 it is possible to
read the charge cycle count an more information about the battery.

http://tpctl.sourceforge.net/
http://www.thinkwiki.org/wiki/SMAPI_support_for_Linux

regards
Stefan Schmidt