ACPI patches updated (20021205)

ACPI patches updated (20021205)

[Grover, Andrew]

Hi all,

New ACPI patches against 2.4.20 and 2.5.50 are now available at
http://sf.net/projects/acpi . Non-Linux releases will be available tonight,
from http://developer.intel.com/technology/iapc/acpi/downloads.htm .

Regards -- Andy

----------------------------------------
05 December 2002.  Summary of changes for version 20021205.

1) Linux

Fix check of schedule_work()'s return value (Ducrot Bruno)

Never return a value from the PCI device's Interrupt Line field if
it might be bogus -- return 0 instead.

Eliminate spurious unused variables warning w.r.t. ACPI_MODULE_NAME

2) ACPI CA Core Subsystem:

Fixed a problem where a store to a String or Buffer object
could cause corruption of the DSDT if the object type being
stored was the same as the target object type and the length
of the object being stored was equal to or smaller than the
original (existing) target object.  This was seen to cause
corruption of battery _BIF buffers if the _BIF method modified
the buffer on the fly.

Fixed a problem where an internal error was generated if a
control method invocation was used in an OperationRegion,
Buffer, or Package declaration.  This was caused by the
deferred parsing of the control method and thus the deferred
creation of the internal method object.  The solution to this
problem was to create the internal method object at the moment
the method is encountered in the first pass - so that
subsequent references to the method will able to obtain the
required parameter count and thus properly parse the method
invocation.  This problem presented itself as an
AE_AML_INTERNAL during the pass 1 parse phase during table
load.

Fixed a problem where the internal String object copy routine
did not always allocate sufficient memory for the target
String object and caused memory corruption.  This problem was
seen to cause "Allocation already present in list!" errors as
memory allocation became corrupted.

Implemented a new function for the evaluation of namespace
objects that allows the specification of the allowable return
object types.  This simplifies a lot of code that checks for a
return object of one or more specific objects returned from
the evaluation (such as _STA, etc.)  This may become and
external function if it would be useful to ACPI-related
drivers.

Completed another round of prefixing #defines with "ACPI_" for
clarity.

Completed additional code restructuring to allow more modular
linking for iASL compiler and AcpiExec.  Several files were
split creating new files.  New files:  nsparse.c dsinit.c
evgpe.c

Implemented an abort mechanism to terminate an executing
control method via the AML debugger.  This feature is useful
for debugging control methods that depend (wait) for specific
hardware responses.

-----------------------------
Andrew Grover
Intel Labs / Mobile Architecture
andrew.grover-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org

Re: ACPI patches updated (20021205)

[Markus Gaugusch]

On Dec 6, Grover, Andrew <andrew.grover-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org> wrote:
> Fixed a problem where a store to a String or Buffer object
> could cause corruption of the DSDT if the object type being
> stored was the same as the target object type and the length
> of the object being stored was equal to or smaller than the
> original (existing) target object.  This was seen to cause
> corruption of battery _BIF buffers if the _BIF method modified
> the buffer on the fly.
I tried the latest patch, but
a) quering the battery info still takes about 0.6 sec
b) quering the battery state still takes about 0.1 sec
I don't know if your fix should be related, though.
You can get my dsdt from
http://markus.gaugusch.at/dsdt-sony_vaio_fx405.gz
And a dmesg:
http://markus.gaugusch.at/dmesg-2.4.20-acpi2002-12-05-sony_vaio_fx405.txt
If you want, I can add some debug statements (but I forgot their names and
where to place them :-(

The battery information should also contain the model name of the battery,
but it doesn't:

cat /proc/acpi/battery/BAT1/info
present:                 yes
design capacity:         25160 mWh
last full capacity:      25160 mWh
battery technology:      rechargeable
design voltage:          14800 mV
design capacity warning: 400 mWh
design capacity low:     384 mWh
capacity granularity 1:  64 mWh
capacity granularity 2:  64 mWh
model number:            5
serial number:           2
battery type:            4 <-- Li-Ion?
OEM info:                5 <-- should be BP1N or something.

I guess, some corruption is still there.

keep up the good work!
Markus

-- 
_____________________________     /"\
Markus Gaugusch  ICQ 11374583     \ /    ASCII Ribbon Campaign
markus-z+rTbpWsRgbk7+2FdBfRIA@public.gmane.org                 X     Against HTML Mail
                                  / \
Linux 2.4.19-4GB * Now playing Stereomud - 2 - Leave



-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf

RE: ACPI patches updated (20021205)

[Grover, Andrew]

> From: Markus Gaugusch [mailto:markus-z+rTbpWsRgbk7+2FdBfRIA@public.gmane.org] 
> a) quering the battery info still takes about 0.6 sec
> b) quering the battery state still takes about 0.1 sec

We've had this problem for a long time - no solution yet.

>The battery information should also contain the model name of the battery,
>but it doesn't:
>cat /proc/acpi/battery/BAT1/info
>battery type:            4 <-- Li-Ion?
>OEM info:                5 <-- should be BP1N or something.

I thought we fixed this. No? Sounds like we aren't dereferencing something
properly.

Regards -- Andy


-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf

Re: ACPI patches updated (20021205)

[Hiroshi Takekawa]

> New ACPI patches against 2.4.20 and 2.5.50 are now available at
> http://sf.net/projects/acpi . Non-Linux releases will be available tonight,
> from http://developer.intel.com/technology/iapc/acpi/downloads.htm .

Finally, ACPI on my notebook works.
Kudos to all ACPI developpers!

> Fixed a problem where an internal error was generated if a
> control method invocation was used in an OperationRegion,
> Buffer, or Package declaration.  This was caused by the
> deferred parsing of the control method and thus the deferred
> creation of the internal method object.  The solution to this
> problem was to create the internal method object at the moment
> the method is encountered in the first pass - so that
> subsequent references to the method will able to obtain the
> required parameter count and thus properly parse the method
> invocation.  This problem presented itself as an
> AE_AML_INTERNAL during the pass 1 parse phase during table
> load.

AE_AML_INTERNAL is the problem that I had encountered for a long time.
This fix got the problem away.

$ bzcat docs/dmesg/dmesg-2.4.20-ac1-acpi.log.bz2 |grep -i ACPI
 BIOS-e820: 000000000fef0000 - 000000000feff000 (ACPI data)
 BIOS-e820: 000000000feff000 - 000000000ff00000 (ACPI NVS)
ACPI: have wakeup address 0xc0001000
ACPI: RSDP (v000 PTLTD                      ) @ 0x000f7450
ACPI: RSDT (v001 PTLTD    RSDT   01540.00000) @ 0x0fefb725
ACPI: FADT (v002 MATBIO CFA3-1   01540.00000) @ 0x0fefef54
ACPI: BOOT (v001 PTLTD  $SBFTBL$ 01540.00000) @ 0x0fefefd8
ACPI: DSDT (v001 MATBIO   CFA3-1 01540.00000) @ 0x00000000
ACPI: BIOS passes blacklist
ACPI: Subsystem revision 20021205
 tbxface-0099 [03] Acpi_load_tables      : ACPI Tables successfully acquired
ACPI Namespace successfully loaded at root c02fe13c
evxfevnt-0074 [04] Acpi_enable           : Transition to ACPI mode successful
ACPI: Interpreter enabled
ACPI: Using PIC for interrupt routing
ACPI: System [ACPI] (supports S0 S3 S4 S5)
ACPI: PCI Root Bridge [PCI0] (00:00)
ACPI: PCI Interrupt Routing Table [\_SB_.PCI0._PRT]
ACPI: PCI Interrupt Link [LNKA] (IRQs *9)
ACPI: PCI Interrupt Link [LNKB] (IRQs 10, disabled)
ACPI: PCI Interrupt Link [LNKC] (IRQs *9)
ACPI: PCI Interrupt Link [LNKD] (IRQs *9)
pci_bind-0194 [10] acpi_pci_bind         : Device 00:00:09.00 not present in PCI namespace
ACPI: PCI Interrupt Link [LNKB] enabled at IRQ 10
PCI: Using ACPI for IRQ routing
PCI: if you experience problems, try using option 'pci=noacpi' or even 'acpi=off'
ACPI: AC Adapter [AC] (on-line)
ACPI: Battery Slot [BATA] (battery present)
ACPI: Power Button (FF) [PWRF]
ACPI: Lid Switch [LID]
ACPI: Processor [CPU0] (supports C1 C2 C3, 8 throttling states)
ACPI: Thermal Zone [TZC] (59 C)
 pci_irq-0297 [09] acpi_pci_irq_derive   : Unable to derive IRQ for device 01:00.2

Regards,

Hiroshi Takekawa <sian-whu2oojL+5h4Eiagz67IpQ@public.gmane.org>


-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf

Re: ACPI patches updated (20021205)

[Markus Weiss]

Le Vendredi 6 Décembre 2002 20:02, Grover, Andrew a écrit :
> 2) ACPI CA Core Subsystem:
>
> Fixed a problem where a store to a String or Buffer object
> could cause corruption of the DSDT if the object type being
> stored was the same as the target object type and the length
> of the object being stored was equal to or smaller than the
> original (existing) target object.  This was seen to cause
> corruption of battery _BIF buffers if the _BIF method modified
> the buffer on the fly.

Just to let you know that with this patch, for the first time ever, 

cat battery/BAT0/info 

works on my Dell Inspiron 2500.
So ACPI under 2.4 seems to be functional now on this laptop now.

Thanks a lot for your work, and congratulations


Markus


-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf

Re: ACPI patches updated (20021205)

[Hanno Böck]

I wanted to let you know that I still have those AE_ALREADY_EXISTS messages on boot.
I already sent you dmesg, lspci and dsdt-output. I can give you more info if you need.

evxfevnt-0074 [04] Acpi_enable           : Transition to ACPI mode successful
   evgpe-0263: *** Info: GPE Block0 defined as GPE0 to GPE15
   evgpe-0263: *** Info: GPE Block1 defined as GPE16 to GPE31
Executing all Device _STA and_INI methods:................evrgnini-0243: *** Error: Could not install Pci_config handler for PCI0, AE_ALREADY_EXISTS
.evrgnini-0243: *** Error: Could not install Pci_config handler for PCI0, AE_ALREADY_EXISTS
...............................evrgnini-0243: *** Error: Could not install Pci_config handler for PCI0, AE_ALREADY_EXISTS
....evrgnini-0243: *** Error: Could not install Pci_config handler for PCI0, AE_ALREADY_EXISTS
...


-- 
Hanno Boeck - hanno-Mmb7MZpHnFY@public.gmane.org               /"\
                                         \ / ASCII Ribbon Campaign
Say no to DCMA, TCPA, Palladium!          X  Against HTML Mail
www.stop1984.com                         / \


-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf