RE: [ACPI] HP omnibook xe3 results

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

>Is it just possible to truncate offending fields or let them to be
accesssed?

The problem is that the AML interpreter can't "guess" what the proper
behavior should be.  The AML code says that the region is X bytes long and
must be accessed Y bytes at a time.  The interpreter doesn't really dare to
read/write beyond the end of the region, nor can it decide to change the
minimum access width.

The ASL compiler absolutely should catch these kinds of errors, and I can
say for certain that the iASL compiler does in fact do this.  

>Maybe based on users choise (special compile-time option?)
>It's a bit frustrating to make the same 'fix' every time a new acpi relase
happens.

Although a compile time option sounds "reasonable" at first, it can quickly
get out of hand as more and more such workarounds are added to the code --
both in terms of code maintenance and in terms of usability (the prospect of
wading through a bunch of compile-time options to workaround a buggy BIOS
should be frightening and repugnant.)

The real solution to this problem is to move the industry to an ASL compiler
that actually performs thorough compile-time error checking so that these
kinds of dormant run-time problems are caught up front (i.e., iASL).  

It really is a shame that part of the point of ACPI was to isolate the
operating system from buggy BIOS code, and here we are back again fighting
the same thing all over again -- the only difference being that we are
fighting buggy AML code versus buggy native machine code.

Bob Moore



-----Original Message-----
From: Ducrot Bruno [mailto:du...@po...]
Sent: Tuesday, May 28, 2002 11:17 AM
To: Juhan Tamsalu
Cc: Ducrot Bruno; acp...@so...
Subject: Re: [ACPI] HP omnibook xe3 results


On Tue, May 28, 2002 at 09:28:09PM +0300, Juhan Tamsalu wrote:
> Hi!!!!!!!!!!!!!!!!!!
> 
> > > If this is the root of these problems, we should track down who owns
this
> > > application.
> > 
> > I'm not sure.  The Creator ID is MSFT, but it is not so usefull...
> > 
> > I think that it could be 'APCI Architect' from Phoenix, but really, it
> > is only an hypothesis...
> 
> At least BIOS is by Phoenix:
> 
> BIOS Vendor: Phoenix Technologies LTD
> BIOS Version: GF.M1.07
> BIOS Release: 03/05/2002
> System Vendor: Hewlett-Packard.
> Product Name: HP OmniBook PC         .
> Version: HP OmniBook XE3 GF 
> 
> Is it just possible to truncate offending fields or let them to be
accesssed?
> Maybe based on users choise (special compile-time option?)
> 
> It's a bit frustrating to make the same 'fix' every time a new acpi relase
happens.
> 
> And yes, chipset is i830 (ICH3-M).
> 

If someone has the ACPI Architect software from Phoenix, could he try
to see if enabling this chipset support make something like that?
(taken after disassembling with ad)

                OperationRegion(GPIO,SystemIo,0x1180,0x3B)
                Field(GPIO /* \_SB.PCI0.LPCB.GPIO */,WordAcc,Lock,Preserve)
                {
                    AccessAs(DWordAcc,0x00),
                    Offset(0x0F),
                    ,4,
                    LV28,1,
                    Offset(0x2D),
                    ,5,
                    LPOL,1,
                    Offset(0x38),
                    ,1,
                    SRST,1,
                    Offset(0x39),
                    ,2,
                    ACPW,1
                }

The length, in this case, is 59 bytes, so that the bit 'ACPW'
in the last double word can not be read..

-- 
Ducrot Bruno
http://www.poupinou.org        Page profaissionelle
http://toto.tu-me-saoules.com  Haume page

_______________________________________________________________

Don't miss the 2002 Sprint PCS Application Developer's Conference
August 25-28 in Las Vegas -- http://devcon.sprintpcs.com/adp/index.cfm

_______________________________________________
Acpi-devel mailing list
Acp...@li...
https://lists.sourceforge.net/lists/listinfo/acpi-devel