Re: RE: Toshiba ACPI battery status - ACPI errors

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/

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

[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: 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]

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

[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/