RE: RE: Toshiba ACPI battery status - ACPI errors

RE: RE: Toshiba ACPI battery status - ACPI errors

[Grover, Andrew]

> From: acpi-devel-admin-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org 
> [mailto:acpi-devel-admin-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org] On Behalf Of 
> Ducrot Bruno
> > Looks good, many thanks. Now one question: Is this a bug in 
> the kernel acpi
> > code, or in the dsdt?
> > 
> 
> ECDT problem (it is another acpi table, have nothing to do with DSDT).
> The manufacturer just "forgot" to create one (and therefore break
> an ACPI requirement).

Well you don't *need* an ECDT. It can make things easier since you can
access the EC before finding it in the namespace, but it's not required.

>From looking at the disassembly, it looks properly written to handle the
case where the EC device has not yet been enumerated. If DFEC is 0 then
it thinks the EC has been found. I believe the problem is that the value
defaults to 0, when it should default to 1 (not found) so control
methods properly fail (or return data that does not touch HW) before the
EC driver is loaded.

There *is* a bug in the AML, I think:
Name (\DFEC, 0x00) should be Name (\DFEC, 0x01) - i.e. the EC should
default to "not working" until the EC device is found.

The other bug this highlights is that ACPI expects the OS to call _PSx
control methods. Someone (the ACPI bus driver?) should be calling _PS0
on EC0 when the EC device is found and its driver is loaded. I don't
believe Linux is doing this yet, although it should be (and also calling
_PS3 when entering sleep states etc.) Not doing this could be the source
of lots of other bugs besides just this one.

Regards -- Andy


-------------------------------------------------------
This SF.net email is sponsored by: SF.net Giveback Program.
Does SourceForge.net help you be more productive?  Does it
help you create better code?  SHARE THE LOVE, and help us help
YOU!  Click Here: http://sourceforge.net/donate/

Re: RE: Toshiba ACPI battery status - ACPI errors

[Michael Holzt]

> There *is* a bug in the AML, I think:
> Name (\DFEC, 0x00) should be Name (\DFEC, 0x01) - i.e. the EC should
> default to "not working" until the EC device is found.

Whoohoo! I was curious and tried thix fix instead of the ecdt fake, and...
...it works. So it seems that i was a bug in the DSDT and i won't neet the
ecdt fake.

Regards
Michael

-- 
Michael Holzt, DL3KJU, kju-+hGXy1KyAyQ@public.gmane.org, kju@debian.org, kju@IRCNet


-------------------------------------------------------
This SF.net email is sponsored by: SF.net Giveback Program.
Does SourceForge.net help you be more productive?  Does it
help you create better code?  SHARE THE LOVE, and help us help
YOU!  Click Here: http://sourceforge.net/donate/

Re: RE: Toshiba ACPI battery status - ACPI errors

[Michael Holzt]

> Whoohoo! I was curious and tried thix fix instead of the ecdt fake, and...
> ...it works. So it seems that i was a bug in the DSDT and i won't neet the
> ecdt fake.

Hmm, said that a little bit too early. The DSDT-Fix removes the loading
error, but many values are not set correctly, for example:

omocha:/proc/acpi/battery/BAT0# more state
present:                 yes
capacity state:          ok
charging state:          unknown
present rate:            unknown
remaining capacity:      unknown
present voltage:         11100 mV

The unknown-values were known when using the ecdt fake.


Regards
Michael

-- 
Michael Holzt, DL3KJU, kju-+hGXy1KyAyQ@public.gmane.org, kju@debian.org, kju@IRCNet


-------------------------------------------------------
This SF.net email is sponsored by: SF.net Giveback Program.
Does SourceForge.net help you be more productive?  Does it
help you create better code?  SHARE THE LOVE, and help us help
YOU!  Click Here: http://sourceforge.net/donate/

Re: RE: Toshiba ACPI battery status - ACPI errors

[Ducrot Bruno]

On Tue, Nov 25, 2003 at 01:13:40PM -0800, Grover, Andrew wrote:
> > From: acpi-devel-admin-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org 
> > [mailto:acpi-devel-admin-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org] On Behalf Of 
> > Ducrot Bruno
> > > Looks good, many thanks. Now one question: Is this a bug in 
> > the kernel acpi
> > > code, or in the dsdt?
> > > 
> > 
> > ECDT problem (it is another acpi table, have nothing to do with DSDT).
> > The manufacturer just "forgot" to create one (and therefore break
> > an ACPI requirement).
> 
> Well you don't *need* an ECDT. It can make things easier since you can
> access the EC before finding it in the namespace, but it's not required.

Yes, I know.  I was thinking that in that perticular model then
an ECDT is required (because it want to access EC at init stage).

> >From looking at the disassembly, it looks properly written to handle the
> case where the EC device has not yet been enumerated. If DFEC is 0 then
> it thinks the EC has been found. I believe the problem is that the value
> defaults to 0, when it should default to 1 (not found) so control
> methods properly fail (or return data that does not touch HW) before the
> EC driver is loaded.
> 
> There *is* a bug in the AML, I think:
> Name (\DFEC, 0x00) should be Name (\DFEC, 0x01) - i.e. the EC should
> default to "not working" until the EC device is found.

Still, I'm not sure that it was the intention of the BIOS writer to not
allow EC at init.

> The other bug this highlights is that ACPI expects the OS to call _PSx
> control methods. Someone (the ACPI bus driver?) should be calling _PS0
> on EC0 when the EC device is found and its driver is loaded. I don't
> believe Linux is doing this yet, although it should be (and also calling
> _PS3 when entering sleep states etc.) Not doing this could be the source
> of lots of other bugs besides just this one.

Agreed, in that scenario, though, _STA/_INI called, then _PS0, but the
enumeration of batteries may be still problematic (even though actually
the _STA will be called a second time, when the battery(ies) will be
enumerated by the bus driver).  The problem, though, is that we can not
known in advance if batteries, then ec, or ec then batteries.

-- 
Ducrot Bruno

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


-------------------------------------------------------
This SF.net email is sponsored by: SF.net Giveback Program.
Does SourceForge.net help you be more productive?  Does it
help you create better code?  SHARE THE LOVE, and help us help
YOU!  Click Here: http://sourceforge.net/donate/

RE: RE: Toshiba ACPI battery status - ACPI errors

[Yu, Luming]

If you want, I can do it for you. At first, would you please describe what could prevent you from updating to 2.6?  Is it ACPI-relative issue? --Luming


-----Original Message-----
From: Michael Holzt [mailto:kju-+hGXy1KyAyQ@public.gmane.org]
Sent: 2003?12?3? 5:45
To: Yu, Luming
Cc: ACPI Developers
Subject: Re: [ACPI] RE: Toshiba ACPI battery status - ACPI errors


> I just wrote a patch for this issue. Would you please have it a look, and test it .

I would do so, but it is against the 2.6.x series, and i had some issues
with this kernel series on my notebook, so for now i stay with 2.4.x. If
you have a patch against 2.4.x, i can give it a try.


Regards
Michael

-- 
Michael Holzt, DL3KJU, kju-+hGXy1KyAyQ@public.gmane.org, kju@debian.org, kju@IRCNet


-------------------------------------------------------
This SF.net email is sponsored by: SF.net Giveback Program.
Does SourceForge.net help you be more productive?  Does it
help you create better code?  SHARE THE LOVE, and help us help
YOU!  Click Here: http://sourceforge.net/donate/

RE: RE: Toshiba ACPI battery status - ACPI errors

[Yu, Luming]

I just wrote a patch for this issue. Would you please have it a look, and test it . http://bugzilla.kernel.org/show_bug.cgi?id=1618
Thanks a lot
Luming


-----Original Message-----
From: acpi-devel-admin-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org [mailto:acpi-devel-admin-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org]On Behalf Of Ducrot Bruno
Sent: 2003?11?26? 20:07
To: Grover, Andrew
Cc: Michael Holzt; ACPI Developers
Subject: Re: [ACPI] RE: Toshiba ACPI battery status - ACPI errors


On Tue, Nov 25, 2003 at 01:13:40PM -0800, Grover, Andrew wrote:
> > From: acpi-devel-admin-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org 
> > [mailto:acpi-devel-admin-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org] On Behalf Of 
> > Ducrot Bruno
> > > Looks good, many thanks. Now one question: Is this a bug in 
> > the kernel acpi
> > > code, or in the dsdt?
> > > 
> > 
> > ECDT problem (it is another acpi table, have nothing to do with DSDT).
> > The manufacturer just "forgot" to create one (and therefore break
> > an ACPI requirement).
> 
> Well you don't *need* an ECDT. It can make things easier since you can
> access the EC before finding it in the namespace, but it's not required.

Yes, I know.  I was thinking that in that perticular model then
an ECDT is required (because it want to access EC at init stage).

> >From looking at the disassembly, it looks properly written to handle the
> case where the EC device has not yet been enumerated. If DFEC is 0 then
> it thinks the EC has been found. I believe the problem is that the value
> defaults to 0, when it should default to 1 (not found) so control
> methods properly fail (or return data that does not touch HW) before the
> EC driver is loaded.
> 
> There *is* a bug in the AML, I think:
> Name (\DFEC, 0x00) should be Name (\DFEC, 0x01) - i.e. the EC should
> default to "not working" until the EC device is found.

Still, I'm not sure that it was the intention of the BIOS writer to not
allow EC at init.

> The other bug this highlights is that ACPI expects the OS to call _PSx
> control methods. Someone (the ACPI bus driver?) should be calling _PS0
> on EC0 when the EC device is found and its driver is loaded. I don't
> believe Linux is doing this yet, although it should be (and also calling
> _PS3 when entering sleep states etc.) Not doing this could be the source
> of lots of other bugs besides just this one.

Agreed, in that scenario, though, _STA/_INI called, then _PS0, but the
enumeration of batteries may be still problematic (even though actually
the _STA will be called a second time, when the battery(ies) will be
enumerated by the bus driver).  The problem, though, is that we can not
known in advance if batteries, then ec, or ec then batteries.

-- 
Ducrot Bruno

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


-------------------------------------------------------
This SF.net email is sponsored by: SF.net Giveback Program.
Does SourceForge.net help you be more productive?  Does it
help you create better code?  SHARE THE LOVE, and help us help
YOU!  Click Here: http://sourceforge.net/donate/
_______________________________________________
Acpi-devel mailing list
Acpi-devel-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org
https://lists.sourceforge.net/lists/listinfo/acpi-devel


-------------------------------------------------------
This SF.net email is sponsored by: SF.net Giveback Program.
Does SourceForge.net help you be more productive?  Does it
help you create better code?  SHARE THE LOVE, and help us help
YOU!  Click Here: http://sourceforge.net/donate/

Re: RE: Toshiba ACPI battery status - ACPI errors

[Michael Holzt]

> I just wrote a patch for this issue. Would you please have it a look, and test it .

I would do so, but it is against the 2.6.x series, and i had some issues
with this kernel series on my notebook, so for now i stay with 2.4.x. If
you have a patch against 2.4.x, i can give it a try.


Regards
Michael

-- 
Michael Holzt, DL3KJU, kju-+hGXy1KyAyQ@public.gmane.org, kju@debian.org, kju@IRCNet


-------------------------------------------------------
This SF.net email is sponsored by: SF.net Giveback Program.
Does SourceForge.net help you be more productive?  Does it
help you create better code?  SHARE THE LOVE, and help us help
YOU!  Click Here: http://sourceforge.net/donate/

Re: RE: Toshiba ACPI battery status - ACPI errors

[Matthew Wilcox]

On Tue, Dec 02, 2003 at 10:45:22PM +0100, Michael Holzt wrote:
> I would do so, but it is against the 2.6.x series, and i had some issues
> with this kernel series on my notebook, so for now i stay with 2.4.x. If
> you have a patch against 2.4.x, i can give it a try.

If you're having problems with 2.6, this would be a great time to let
everybody know what they are ...

-- 
"Next the statesmen will invent cheap lies, putting the blame upon 
the nation that is attacked, and every man will be glad of those
conscience-soothing falsities, and will diligently study them, and refuse
to examine any refutations of them; and thus he will by and by convince 
himself that the war is just, and will thank God for the better sleep 
he enjoys after this process of grotesque self-deception." -- Mark Twain


-------------------------------------------------------
This SF.net email is sponsored by: SF.net Giveback Program.
Does SourceForge.net help you be more productive?  Does it
help you create better code?  SHARE THE LOVE, and help us help
YOU!  Click Here: http://sourceforge.net/donate/

Re: RE: Toshiba ACPI battery status - ACPI errors

[Michael Holzt]

> If you're having problems with 2.6, this would be a great time to let
> everybody know what they are ...

It looked more like configuration issues (e.g. with the radeon framebuffer
failing to switch the resolution automagically) than bugs. Hadn't time to
investigate, though. I won't report bugs before beeing certain about there
existance.

Regards
Michael

-- 
Michael Holzt, DL3KJU, kju-+hGXy1KyAyQ@public.gmane.org, kju@debian.org, kju@IRCNet


-------------------------------------------------------
This SF.net email is sponsored by: SF.net Giveback Program.
Does SourceForge.net help you be more productive?  Does it
help you create better code?  SHARE THE LOVE, and help us help
YOU!  Click Here: http://sourceforge.net/donate/

RE: RE: Toshiba ACPI battery status - ACPI errors

[Grover, Andrew]

> From: Michael Holzt [mailto:kju-+hGXy1KyAyQ@public.gmane.org] 
> Hmm, said that a little bit too early. The DSDT-Fix removes 
> the loading
> error, but many values are not set correctly, for example:
> 
> omocha:/proc/acpi/battery/BAT0# more state
> present:                 yes
> capacity state:          ok
> charging state:          unknown
> present rate:            unknown
> remaining capacity:      unknown
> present voltage:         11100 mV
> 
> The unknown-values were known when using the ecdt fake.

Right. This is because the OS is supposed to come along when the EC
device is discovered and run the _PS0 control method, but it isn't,
currently.

Regards -- Andy


-------------------------------------------------------
This SF.net email is sponsored by: SF.net Giveback Program.
Does SourceForge.net help you be more productive?  Does it
help you create better code?  SHARE THE LOVE, and help us help
YOU!  Click Here: http://sourceforge.net/donate/

Re: RE: Toshiba ACPI battery status - ACPI errors

[Michael Holzt]

> Right. This is because the OS is supposed to come along when the EC
> device is discovered and run the _PS0 control method, but it isn't,
> currently.

Hmm. When using the modified dsdt (with the EC byte set to 0x01), even the
edct fake does not bring the full battery information back. I removed the
dsdt fix, and now i have full state again.

So this is a bug in the linux kernel acpi code?

Regards
Michael

-- 
Michael Holzt, DL3KJU, kju-+hGXy1KyAyQ@public.gmane.org, kju@debian.org, kju@IRCNet


-------------------------------------------------------
This SF.net email is sponsored by: SF.net Giveback Program.
Does SourceForge.net help you be more productive?  Does it
help you create better code?  SHARE THE LOVE, and help us help
YOU!  Click Here: http://sourceforge.net/donate/

RE: Toshiba ACPI battery status - ACPI errors

[Nakajima, Jun]

I suspect this is a known issue with AML code from Toshiba. Their _STA
does not return a value explicitly, but (wrongly) expects the AML
interpreter to get the return value returned by the function _STA is
calling, like
	Method (_STA, ....) {
		AAA(...)
	}
Instead of 
	Method (_STA, ....) {
		Return (AAA(...))
	}

If you can provide ACPI dump data of the machine, that would be helpful
when identifying the cause. Copy the ACPI mailing list and Len.

	Jun

> -----Original Message-----
> From: linux-kernel-owner-u79uwXL29TY76Z2rM5mHXA@public.gmane.org [mailto:linux-kernel-
> owner-u79uwXL29TY76Z2rM5mHXA@public.gmane.org] On Behalf Of Bernt Hansen
> Sent: Monday, November 24, 2003 12:45 PM
> To: Linux Kernel Mailing List
> Subject: Toshiba ACPI battery status - ACPI errors
> 
> Hi,
> 
> I have a new Toshiba Tecra S1 laptop which I cannot get ACPI battery
> status from.  I grepped my dmesg output for ACPI and got the following
> messages:
> 
>  BIOS-e820: 000000001fff0000 - 000000001fffffc0 (ACPI data)
>  BIOS-e820: 000000001fffffc0 - 0000000020000000 (ACPI NVS)
> ACPI: RSDP (v000 OID_00                                    ) @
> 0x000e6010
> ACPI: RSDT (v001 INSYDE RSDT_000 0x00000001 _CSI 0x00010101) @
> 0x1fffaaf0
> ACPI: FADT (v001 INSYDE FACP_000 0x00000100 _CSI 0x00010101) @
> 0x1ffffb00
> ACPI: BOOT (v001 INSYDE SYS_BOOT 0x00000100 _CSI 0x00010101) @
> 0x1ffffb90
> ACPI: DBGP (v001 INSYDE DBGP_000 0x00000100 _CSI 0x00010101) @
> 0x1ffffbc0
> ACPI: SSDT (v001 INSYDE   GV3Ref 0x00002000 INTL 0x20021002) @
> 0x1fffab30
> ACPI: DSDT (v001 TOSINV   INT810 0x00001002 INTL 0x02002036) @
> 0x00000000
> ACPI: Subsystem revision 20031002
> ACPI: IRQ 9 was Edge Triggered, setting to Level Triggerd
> ACPI: Interpreter enabled
> ACPI: Using PIC for interrupt routing
>     ACPI-1120: *** Error: Method execution failed [\_SB_.BAT0._STA]
> (Node dff61fe0), AE_NOT_EXIST
>     ACPI-1120: *** Error: Method execution failed [\_SB_.BAT1._STA]
> (Node dff61ea0), AE_NOT_EXIST
> ACPI: PCI Root Bridge [PCI0] (00:00)
> ACPI: PCI Interrupt Routing Table [\_SB_.PCI0._PRT]
> ACPI: PCI Interrupt Routing Table [\_SB_.PCI0.PCI2._PRT]
> ACPI: PCI Interrupt Link [LNKA] (IRQs 3 5 7 *10 11)
> ACPI: PCI Interrupt Link [LNKB] (IRQs 6)
> ACPI: PCI Interrupt Link [LNKC] (IRQs 3 5 7 10 *11)
> ACPI: PCI Interrupt Link [LNKD] (IRQs 3 7 10 *11)
> ACPI: PCI Interrupt Link [LNKE] (IRQs 3 4 5 7 10 *11 14 15)
> ACPI: PCI Interrupt Link [LNKF] (IRQs 3 5 7 10 11)
> ACPI: PCI Interrupt Link [LNKG] (IRQs 3 4 5 7 10 11 14 15)
> ACPI: PCI Interrupt Link [LNKH] (IRQs 3 5 7 10 11)
> ACPI: Embedded Controller [EC0] (gpe 16)
> ACPI: Power Resource [PUT2] (on)
> ACPI: Power Resource [PFA1] (off)
> ACPI: Power Resource [PFA0] (off)
> ACPI: PCI Interrupt Link [LNKA] enabled at IRQ 10
> ACPI: PCI Interrupt Link [LNKD] enabled at IRQ 11
> ACPI: PCI Interrupt Link [LNKC] enabled at IRQ 11
> ACPI: PCI Interrupt Link [LNKH] enabled at IRQ 5
> ACPI: PCI Interrupt Link [LNKB] enabled at IRQ 10
> ACPI: PCI Interrupt Link [LNKE] enabled at IRQ 11
> PCI: Using ACPI for IRQ routing
> PCI: if you experience problems, try using option 'pci=noacpi' or even
> 'acpi=off'
> acpiphp: ACPI Hot Plug PCI Controller Driver version: 0.4
> acpiphp_glue: can't get bus number, assuming 0
> ACPI: AC Adapter [AC] (on-line)
> ACPI: Power Button (FF) [PWRF]
> ACPI: Lid Switch [LID]
> ACPI: Fan [FAN0] (off)
> ACPI: Fan [FAN1] (off)
> 
> The errors with "Method execution failed" seem to be my problem.  Any
> ideas what I can try to get the status of the batteries in this
laptop?
> There are two batteries in this thing.
> 
> I have attached the full dmesg output in case it is helpful.  Let me
> know what I can do to help solve this problem.
> 
> Thanks,
> Bernt.
> 
> --
> Bernt Hansen     Norang Consulting Inc.


-------------------------------------------------------
This SF.net email is sponsored by: SF.net Giveback Program.
Does SourceForge.net help you be more productive?  Does it
help you create better code?  SHARE THE LOVE, and help us help
YOU!  Click Here: http://sourceforge.net/donate/

Re: [ACPI] RE: Toshiba ACPI battery status - ACPI errors

[Michael Holzt]

> I suspect this is a known issue with AML code from Toshiba. 

Sorry, but unfortunately your guess is wrong (would have been too easy). A
few days ago i reported about the Tecra S1 problems on the acpi-devel list
as well, maybe you missed my post, which can be found in the archives here:

  http://sourceforge.net/mailarchive/forum.php?thread_id=3511931&forum_id=6102

Included was a link to the disassembled dsdt, which can be found here:

  http://www.kju.de/data/dsdt.dsl

As you can see, the _STA-Methods of both BAT0 and BAT1 do proper return
calls. I'm sorry, but i'm do not have any knowledge about acpi or dsdts to
debug this myself. The DSDT has some other errors as well.

It is somewhat strange, that toshiba as one of the core members of ACPI
seems to be unable to provide sane DSDTs for years now. Something is real
wrong with this company.

Regards
Michael

-- 
Michael Holzt, DL3KJU, kju@fqdn.org, kju@debian.org, kju@IRCNet

Re: [ACPI] RE: Toshiba ACPI battery status - ACPI errors

[Ducrot Bruno]

On Mon, Nov 24, 2003 at 11:55:39PM +0100, Michael Holzt wrote:
> > I suspect this is a known issue with AML code from Toshiba. 
> 
> Sorry, but unfortunately your guess is wrong (would have been too easy). A
> few days ago i reported about the Tecra S1 problems on the acpi-devel list
> as well, maybe you missed my post, which can be found in the archives here:
> 
>   http://sourceforge.net/mailarchive/forum.php?thread_id=3511931&forum_id=6102

Sorry, I missed your post.

> 
> Included was a link to the disassembled dsdt, which can be found here:
> 
>   http://www.kju.de/data/dsdt.dsl
> 
> As you can see, the _STA-Methods of both BAT0 and BAT1 do proper return
> calls. I'm sorry, but i'm do not have any knowledge about acpi or dsdts to
> debug this myself. The DSDT has some other errors as well.

I posted last week at acpi-devel a patch which fake a ECDT.  That should
at least fix your embedded error you encounter.

http://sourceforge.net/mailarchive/message.php?msg_id=6561311

Looking your DSDT, the parameter you have to pass at boot are:

ecdt_fake=0x66:0x62:0x10:-1:\\_SB.PCI0.LPCB.EC0

I hope that at least that will correct some obivous errors.

> 
> It is somewhat strange, that toshiba as one of the core members of ACPI
> seems to be unable to provide sane DSDTs for years now. Something is real
> wrong with this company.

Indeed.  They should change their ODM.

-- 
Ducrot Bruno

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

Re: RE: Toshiba ACPI battery status - ACPI errors

[Michael Holzt]

> I posted last week at acpi-devel a patch which fake a ECDT.  That should
> at least fix your embedded error you encounter.
[...]
> Looking your DSDT, the parameter you have to pass at boot are:
> ecdt_fake=0x66:0x62:0x10:-1:\\_SB.PCI0.LPCB.EC0

With the additional patch segment you forgot added, i finally got it
compiled, and ...

[...]
Nov 25 18:49:57 omocha kernel: ACPI: Battery Slot [BAT0] (battery present)
Nov 25 18:49:57 omocha kernel: ACPI: Battery Slot [BAT1] (battery absent)
[...]

omocha:/proc/acpi/battery/BAT0# more state
present:                 yes
capacity state:          ok
charging state:          unknown
present rate:            1500 mA
remaining capacity:      6257 mAh
present voltage:         15000 mV


Looks good, many thanks. Now one question: Is this a bug in the kernel acpi
code, or in the dsdt?

Regards
Michael

-- 
Michael Holzt, DL3KJU, kju-+hGXy1KyAyQ@public.gmane.org, kju@debian.org, kju@IRCNet


-------------------------------------------------------
This SF.net email is sponsored by: SF.net Giveback Program.
Does SourceForge.net help you be more productive?  Does it
help you create better code?  SHARE THE LOVE, and help us help
YOU!  Click Here: http://sourceforge.net/donate/

Re: RE: Toshiba ACPI battery status - ACPI errors

[Ducrot Bruno]

On Tue, Nov 25, 2003 at 06:55:33PM +0100, Michael Holzt wrote:
> > I posted last week at acpi-devel a patch which fake a ECDT.  That should
> > at least fix your embedded error you encounter.
> [...]
> > Looking your DSDT, the parameter you have to pass at boot are:
> > ecdt_fake=0x66:0x62:0x10:-1:\\_SB.PCI0.LPCB.EC0
> 
> With the additional patch segment you forgot added, i finally got it
> compiled, and ...
> 
> [...]
> Nov 25 18:49:57 omocha kernel: ACPI: Battery Slot [BAT0] (battery present)
> Nov 25 18:49:57 omocha kernel: ACPI: Battery Slot [BAT1] (battery absent)
> [...]
> 
> omocha:/proc/acpi/battery/BAT0# more state
> present:                 yes
> capacity state:          ok
> charging state:          unknown
> present rate:            1500 mA
> remaining capacity:      6257 mAh
> present voltage:         15000 mV
> 
> 
> Looks good, many thanks. Now one question: Is this a bug in the kernel acpi
> code, or in the dsdt?
> 

ECDT problem (it is another acpi table, have nothing to do with DSDT).
The manufacturer just "forgot" to create one (and therefore break
an ACPI requirement).


-- 
Ducrot Bruno

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


-------------------------------------------------------
This SF.net email is sponsored by: SF.net Giveback Program.
Does SourceForge.net help you be more productive?  Does it
help you create better code?  SHARE THE LOVE, and help us help
YOU!  Click Here: http://sourceforge.net/donate/

Re: RE: Toshiba ACPI battery status - ACPI errors

[Ducrot Bruno]

On Tue, Nov 25, 2003 at 08:41:23PM +0100, Ducrot Bruno wrote:
> On Tue, Nov 25, 2003 at 06:55:33PM +0100, Michael Holzt wrote:
> > > I posted last week at acpi-devel a patch which fake a ECDT.  That should
> > > at least fix your embedded error you encounter.
> > [...]
> > > Looking your DSDT, the parameter you have to pass at boot are:
> > > ecdt_fake=0x66:0x62:0x10:-1:\\_SB.PCI0.LPCB.EC0
> > 
> > With the additional patch segment you forgot added, i finally got it
> > compiled, and ...
> > 
> > [...]
> > Nov 25 18:49:57 omocha kernel: ACPI: Battery Slot [BAT0] (battery present)
> > Nov 25 18:49:57 omocha kernel: ACPI: Battery Slot [BAT1] (battery absent)
> > [...]
> > 
> > omocha:/proc/acpi/battery/BAT0# more state
> > present:                 yes
> > capacity state:          ok
> > charging state:          unknown
> > present rate:            1500 mA
> > remaining capacity:      6257 mAh
> > present voltage:         15000 mV
> > 

For information purpose, the (updated) patch is at
ftp://ftp.poupinou.org/acpi/10_fake_ecdt.diff

I have to clean up a bit though before submission to acpi maintainer.

Cheers,

-- 
Ducrot Bruno

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


-------------------------------------------------------
This SF.net email is sponsored by: SF.net Giveback Program.
Does SourceForge.net help you be more productive?  Does it
help you create better code?  SHARE THE LOVE, and help us help
YOU!  Click Here: http://sourceforge.net/donate/