[Fwd: ACPI error when trying entring in Sleep Mode]

[Fwd: ACPI error when trying entring in Sleep Mode]

[Marci]

[-- Attachment #1: Type: text/plain, Size: 48 bytes --]

No Ideas?

Please :(

I need this

Thanks again

[-- Attachment #2: ACPI error when trying entring in Sleep Mode --]
[-- Type: message/rfc822, Size: 2721 bytes --]

From: Marci <voloterreno-nc/lrvXPQ4s@public.gmane.org>
To: acpi-devel-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org
Subject: ACPI error when trying entring in Sleep Mode
Date: Sun, 16 Mar 2003 21:24:45 +0100
Message-ID: <3E74DD8D.1090602-nc/lrvXPQ4s@public.gmane.org>

Hi all, here my configuration :

MSI KT4 Ultra

Athlon XP 2400+

Nvidia Geforce 3 Ti200


I have this problem:

When I try to enter in S1 sleep mode appears in the screen these errors:

Mar 16 21:08:17 magisystem kernel:  exfldio-0129 [31] ex_setup_region 
     : Field [U1PE] access width (2 bytes) too large for region [UBP1] 
(length 1)
Mar 16 21:08:17 magisystem kernel:  exfldio-0140 [31] ex_setup_region 
     : Field [U1PE] Base+Offset+Width 0+0+2 is beyond end of region 
[UBP1] (length 1)
Mar 16 21:08:17 magisystem kernel:  dswexec-0421 [23] ds_exec_end_op 
     : [Store]: Could not resolve operands, AE_AML_REGION_LIMIT
Mar 16 21:08:17 magisystem kernel:  psparse-1121: *** Error: Method 
execution failed [\_PTS] (Node c15bc5e8), AE_AML_REGION_LIMIT
Mar 16 21:08:17 magisystem kernel:  hwsleep-0257 [15] 
acpi_enter_sleep_state: Entering sleep state [S1]
Mar 16 21:08:17 magisystem kernel:    evgpe-0351: *** Error: 
acpi_ev_gpe_dispatch: No handler or method for GPE[00], disabling event
Mar 16 21:08:18 magisystem kernel:  exfldio-0129 [32] ex_setup_region 
     : Field [U1PE] access width (2 bytes) too large for region [UBP1] 
(length 1)
Mar 16 21:08:18 magisystem kernel:  exfldio-0140 [32] ex_setup_region 
     : Field [U1PE] Base+Offset+Width 0+0+2 is beyond end of region 
[UBP1] (length 1)
Mar 16 21:08:18 magisystem kernel:  exfldio-0129 [32] ex_setup_region 
     : Field [U1PE] access width (2 bytes) too large for region [UBP1] 
(length 1)
Mar 16 21:08:18 magisystem kernel:  exfldio-0140 [32] ex_setup_region 
     : Field [U1PE] Base+Offset+Width 0+0+2 is beyond end of region 
[UBP1] (length 1)
Mar 16 21:08:18 magisystem kernel:  psparse-1121: *** Error: Method 
execution failed [\_WAK] (Node c15bc768), AE_AML_REGION_LIMIT
Mar 16 21:08:18 magisystem kernel:  hwsleep-0428: *** Error: Method _WAK 
failed, AE_AML_REGION_LIMIT
Mar 16 21:08:18 magisystem kernel:    evgpe-0351: *** Error: 
acpi_ev_gpe_dispatch: No handler or method for GPE[00], disabling event

Anyone have ideas?

The command that I do is "echo 1 > sleep" in the /proc/acpi directory. 
The kernel is the 2.4.21-pre4 with the lastest patch.
The system is the Linux Debian Sid OS

Thanks for your help and time

Bye

Marcello

Re: [Fwd: ACPI error when trying entring in Sleep Mode]

[Ducrot Bruno]

On Mon, Mar 17, 2003 at 01:50:46PM +0100, Marci wrote:
> No Ideas?
> 
> Please :(
> 
> I need this
> 
> Thanks again

> From: Marci <voloterreno-nc/lrvXPQ4s@public.gmane.org>
> To:  acpi-devel-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org
> Subject: ACPI error when trying entring in Sleep Mode
> 
> Hi all, here my configuration :
> 
> MSI KT4 Ultra
> 
> Athlon XP 2400+
> 
> Nvidia Geforce 3 Ti200
> 
> 
> I have this problem:
> 
> When I try to enter in S1 sleep mode appears in the screen these errors:
> 
> Mar 16 21:08:17 magisystem kernel:  exfldio-0129 [31] ex_setup_region 
>     : Field [U1PE] access width (2 bytes) too large for region [UBP1] 
> (length 1)
> Mar 16 21:08:17 magisystem kernel:  exfldio-0140 [31] ex_setup_region 
>     : Field [U1PE] Base+Offset+Width 0+0+2 is beyond end of region 
> [UBP1] (length 1)
> Mar 16 21:08:17 magisystem kernel:  dswexec-0421 [23] ds_exec_end_op 
>     : [Store]: Could not resolve operands, AE_AML_REGION_LIMIT
> Mar 16 21:08:17 magisystem kernel:  psparse-1121: *** Error: Method 
> execution failed [\_PTS] (Node c15bc5e8), AE_AML_REGION_LIMIT
> Mar 16 21:08:17 magisystem kernel:  hwsleep-0257 [15] 
> acpi_enter_sleep_state: Entering sleep state [S1]
> Mar 16 21:08:17 magisystem kernel:    evgpe-0351: *** Error: 
> acpi_ev_gpe_dispatch: No handler or method for GPE[00], disabling event
> Mar 16 21:08:18 magisystem kernel:  exfldio-0129 [32] ex_setup_region 
>     : Field [U1PE] access width (2 bytes) too large for region [UBP1] 
> (length 1)
> Mar 16 21:08:18 magisystem kernel:  exfldio-0140 [32] ex_setup_region 
>     : Field [U1PE] Base+Offset+Width 0+0+2 is beyond end of region 
> [UBP1] (length 1)
> Mar 16 21:08:18 magisystem kernel:  exfldio-0129 [32] ex_setup_region 
>     : Field [U1PE] access width (2 bytes) too large for region [UBP1] 
> (length 1)
> Mar 16 21:08:18 magisystem kernel:  exfldio-0140 [32] ex_setup_region 
>     : Field [U1PE] Base+Offset+Width 0+0+2 is beyond end of region 
> [UBP1] (length 1)
> Mar 16 21:08:18 magisystem kernel:  psparse-1121: *** Error: Method 
> execution failed [\_WAK] (Node c15bc768), AE_AML_REGION_LIMIT
> Mar 16 21:08:18 magisystem kernel:  hwsleep-0428: *** Error: Method _WAK 
> failed, AE_AML_REGION_LIMIT
> Mar 16 21:08:18 magisystem kernel:    evgpe-0351: *** Error: 
> acpi_ev_gpe_dispatch: No handler or method for GPE[00], disabling event
> 
> Anyone have ideas?
> 
> The command that I do is "echo 1 > sleep" in the /proc/acpi directory. 
> The kernel is the 2.4.21-pre4 with the lastest patch.
> The system is the Linux Debian Sid OS
> 

There is an error in your DSDT.  I don't doubt that if you
follow the instruction in
http://acpi.sourceforge.net/wiki/index.php/HowToOverrideTable

you will get a complain from iasl with a inproper declaration of
an operational region.  Check first if you can increase the size
for this region will be sufficiant.  If not, then do not hesitate
to request more help!

Cheers,

-- 
Ducrot Bruno

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


-------------------------------------------------------
This SF.net email is sponsored by:Crypto Challenge is now open! 
Get cracking and register here for some mind boggling fun and 
the chance of winning an Apple iPod:
http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0031en

Re: [Fwd: ACPI error when trying entring in Sleep Mode]

[Marci]

Ducrot Bruno wrote:

>On Mon, Mar 17, 2003 at 01:50:46PM +0100, Marci wrote:
>  
>
>>No Ideas?
>>
>>Please :(
>>
>>I need this
>>
>>Thanks again
>>    
>>
>
>  
>
>>From: Marci <voloterreno-nc/lrvXPQ4s@public.gmane.org>
>>To:  acpi-devel-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org
>>Subject: ACPI error when trying entring in Sleep Mode
>>
>>Hi all, here my configuration :
>>
>>MSI KT4 Ultra
>>
>>Athlon XP 2400+
>>
>>Nvidia Geforce 3 Ti200
>>
>>
>>I have this problem:
>>
>>When I try to enter in S1 sleep mode appears in the screen these errors:
>>
>>Mar 16 21:08:17 magisystem kernel:  exfldio-0129 [31] ex_setup_region 
>>    : Field [U1PE] access width (2 bytes) too large for region [UBP1] 
>>(length 1)
>>Mar 16 21:08:17 magisystem kernel:  exfldio-0140 [31] ex_setup_region 
>>    : Field [U1PE] Base+Offset+Width 0+0+2 is beyond end of region 
>>[UBP1] (length 1)
>>Mar 16 21:08:17 magisystem kernel:  dswexec-0421 [23] ds_exec_end_op 
>>    : [Store]: Could not resolve operands, AE_AML_REGION_LIMIT
>>Mar 16 21:08:17 magisystem kernel:  psparse-1121: *** Error: Method 
>>execution failed [\_PTS] (Node c15bc5e8), AE_AML_REGION_LIMIT
>>Mar 16 21:08:17 magisystem kernel:  hwsleep-0257 [15] 
>>acpi_enter_sleep_state: Entering sleep state [S1]
>>Mar 16 21:08:17 magisystem kernel:    evgpe-0351: *** Error: 
>>acpi_ev_gpe_dispatch: No handler or method for GPE[00], disabling event
>>Mar 16 21:08:18 magisystem kernel:  exfldio-0129 [32] ex_setup_region 
>>    : Field [U1PE] access width (2 bytes) too large for region [UBP1] 
>>(length 1)
>>Mar 16 21:08:18 magisystem kernel:  exfldio-0140 [32] ex_setup_region 
>>    : Field [U1PE] Base+Offset+Width 0+0+2 is beyond end of region 
>>[UBP1] (length 1)
>>Mar 16 21:08:18 magisystem kernel:  exfldio-0129 [32] ex_setup_region 
>>    : Field [U1PE] access width (2 bytes) too large for region [UBP1] 
>>(length 1)
>>Mar 16 21:08:18 magisystem kernel:  exfldio-0140 [32] ex_setup_region 
>>    : Field [U1PE] Base+Offset+Width 0+0+2 is beyond end of region 
>>[UBP1] (length 1)
>>Mar 16 21:08:18 magisystem kernel:  psparse-1121: *** Error: Method 
>>execution failed [\_WAK] (Node c15bc768), AE_AML_REGION_LIMIT
>>Mar 16 21:08:18 magisystem kernel:  hwsleep-0428: *** Error: Method _WAK 
>>failed, AE_AML_REGION_LIMIT
>>Mar 16 21:08:18 magisystem kernel:    evgpe-0351: *** Error: 
>>acpi_ev_gpe_dispatch: No handler or method for GPE[00], disabling event
>>
>>Anyone have ideas?
>>
>>The command that I do is "echo 1 > sleep" in the /proc/acpi directory. 
>>The kernel is the 2.4.21-pre4 with the lastest patch.
>>The system is the Linux Debian Sid OS
>>
>>    
>>
>
>There is an error in your DSDT.  I don't doubt that if you
>follow the instruction in
>http://acpi.sourceforge.net/wiki/index.php/HowToOverrideTable
>
>you will get a complain from iasl with a inproper declaration of
>an operational region.  Check first if you can increase the size
>for this region will be sufficiant.  If not, then do not hesitate
>to request more help!
>
>Cheers,
>
>  
>
Another thing , where I can find docs on ACPI Assembly language?

Thanks
Bye



-------------------------------------------------------
This SF.net email is sponsored by:Crypto Challenge is now open! 
Get cracking and register here for some mind boggling fun and 
the chance of winning an Apple iPod:
http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0031en

Re: [Fwd: ACPI error when trying entring in Sleep Mode]

[Karol Kozimor]

Thus wrote Marci:
> Another thing , where I can find docs on ACPI Assembly language?

See the ACPI spec on http://www.acpi.info/
Best regards,

-- 
Karol 'sziwan' Kozimor
sziwan-DETuoxkZsSqrDJvtcaxF/A@public.gmane.org


-------------------------------------------------------
This SF.net email is sponsored by:Crypto Challenge is now open! 
Get cracking and register here for some mind boggling fun and 
the chance of winning an Apple iPod:
http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0031en

Re: [Fwd: ACPI error when trying entring in Sleep Mode]

[Marci]

Ducrot Bruno wrote:

>On Mon, Mar 17, 2003 at 03:08:34PM +0100, Marci wrote:
>  
>
>>Ducrot Bruno wrote:
>>
>>    
>>
>>>There is an error in your DSDT.  I don't doubt that if you
>>>follow the instruction in
>>>http://acpi.sourceforge.net/wiki/index.php/HowToOverrideTable
>>>
>>>you will get a complain from iasl with a inproper declaration of
>>>an operational region.  Check first if you can increase the size
>>>for this region will be sufficiant.  If not, then do not hesitate
>>>to request more help!
>>>
>>>Cheers,
>>>
>>>
>>>
>>>      
>>>
>>Ehm, excuse me for the question, but how I can increase the size for 
>>this region?
>>    
>>
>
>You disassemble the DSDT ACPI table via:
>iasl -d /proc/acpi/dsdt
>this will create a file called
>dsdt.dsl
>
>Then if try to reassemble it via
>iasl -tc -p my_table dsdt.dsl
>
>you will certainly get an error about a bad over-sized operational region.
>
>iasl is an intel tools found here:
>
>http://developer.intel.com/technology/iapc/acpi/downloads.htm
>(which is also linked from http://acpi.sourceforge.net/)
>
>You can either get the (binary) iasl compiler/disassembler for Linux,
>or the ACPI-CA unix build environment if you want to compile it
>yourself.
>
>  
>
>>And why under Windows the dsdt have no problem ( I'd like only understand )
>>    
>>
>
>Windows AML interpreter do not check bound operational regions.
>ACPI-CA AML interpreter (and also Linux one) does, however, check
>bound such regions.  ACPI-CA current position for this stuff is to
>check bound such regions even though that will implies that it
>can not provide total compatibility support.
>Note that their are other compatibilty issues as well.  For example,
>most if not all toshiba laptops (I speak for the non-compal case)
>was shipped with an error for which they implicitely returned a value.
>
>It was stated by ACPI sig. that it is an error.  Note that Toshiba
>has then released new bios which corrected this behaviour.
>
>Alas, it is somehow hard to get correct support from all vendor...
>
>The issue you get (a bad sized operational region) is present in most
>of the toshiba-compal model series.  And toshiba still do not have
>corrected this issue, even though they were warned about.
>
>So, sometimes, complaining to the bios vendor work, sometimes not.  Just
>that we get the same kind of stupid answer as 'it work under windows'
>even from the same vendor.
>
>Cheers,
>
>  
>
X Karol : Thanks for the documentation

X Bruno:

If I try to reassemble the code I get these errors:

Intel ACPI Component Architecture
ASL Optimizing Compiler / AML Disassembler version 20030228 [Feb 28 2003]
Copyright (C) 2000 - 2003 Intel Corporation
Supports ACPI Specification Revision 2.0b

dsdt.dsl   864:                 Field (U1D3, WordAcc, NoLock, Preserve)
Error    1047 -                           ^ Access width is greater than 
region size

dsdt.dsl   866:                     UR49,   3
Error    1051 -                        ^ Access width of Field Unit 
extends beyond region limit

dsdt.dsl   870:                 Field (UBP1, WordAcc, NoLock, Preserve)
Error    1047 -                           ^ Access width is greater than 
region size

dsdt.dsl   872:                     U1PE,   2
Error    1051 -                        ^ Access width of Field Unit 
extends beyond region limit

dsdt.dsl   905:                 Field (UBP2, WordAcc, NoLock, Preserve)
Error    1047 -                           ^ Access width is greater than 
region size

dsdt.dsl   907:                     U2PE,   2
Error    1051 -                        ^ Access width of Field Unit 
extends beyond region limit

dsdt.dsl   933:                 Field (UBP3, WordAcc, NoLock, Preserve)
Error    1047 -                           ^ Access width is greater than 
region size

dsdt.dsl   935:                     U3PE,   2
Error    1051 -                        ^ Access width of Field Unit 
extends beyond region limit

dsdt.dsl   961:                 Field (UBP4, WordAcc, NoLock, Preserve)
Error    1047 -                           ^ Access width is greater than 
region size

dsdt.dsl   963:                     U4PE,   2
Error    1051 -                        ^ Access width of Field Unit 
extends beyond region limit

dsdt.dsl  2797:                 Method (STM, 0, Serialized)
Warning  2019 -                           ^ Not all control paths return 
a value (STM_)

dsdt.dsl  3240:     Method (_WAK, 1, NotSerialized)
Warning  2026 -                ^ Reserved method must return a value (_WAK)

ASL Input:  dsdt.dsl - 3356 lines, 103057 bytes, 1269 keywords
Compilation complete. 10 Errors, 2 Warnings, 0 Remarks, 419 Optimizations

I think this will be hard to fix, right? I should post this to MSI , 
with the hope that will give any importace to my message?

Thanks




-------------------------------------------------------
This SF.net email is sponsored by:Crypto Challenge is now open! 
Get cracking and register here for some mind boggling fun and 
the chance of winning an Apple iPod:
http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0031en

Re: [Fwd: ACPI error when trying entring in Sleep Mode]

[Ducrot Bruno]

On Mon, Mar 17, 2003 at 07:01:33PM +0100, Marci wrote:
> Ducrot Bruno wrote:
> 
> >On Mon, Mar 17, 2003 at 03:08:34PM +0100, Marci wrote:
> > 
> >
> >>Ducrot Bruno wrote:
> >>
> >>   
> >>
> >>>There is an error in your DSDT.  I don't doubt that if you
> >>>follow the instruction in
> >>>http://acpi.sourceforge.net/wiki/index.php/HowToOverrideTable
> >>>
> >>>you will get a complain from iasl with a inproper declaration of
> >>>an operational region.  Check first if you can increase the size
> >>>for this region will be sufficiant.  If not, then do not hesitate
> >>>to request more help!
> >>>
> >>>Cheers,
> >>>
> >>>
> >>>
> >>>     
> >>>
> >>Ehm, excuse me for the question, but how I can increase the size for 
> >>this region?
> >>   
> >>
> >
> >You disassemble the DSDT ACPI table via:
> >iasl -d /proc/acpi/dsdt
> >this will create a file called
> >dsdt.dsl
> >
> >Then if try to reassemble it via
> >iasl -tc -p my_table dsdt.dsl
> >
> >you will certainly get an error about a bad over-sized operational region.
> >
> >iasl is an intel tools found here:
> >
> >http://developer.intel.com/technology/iapc/acpi/downloads.htm
> >(which is also linked from http://acpi.sourceforge.net/)
> >
> >You can either get the (binary) iasl compiler/disassembler for Linux,
> >or the ACPI-CA unix build environment if you want to compile it
> >yourself.
> >
> > 
> >
> >>And why under Windows the dsdt have no problem ( I'd like only understand 
> >>)
> >>   
> >>
> >
> >Windows AML interpreter do not check bound operational regions.
> >ACPI-CA AML interpreter (and also Linux one) does, however, check
> >bound such regions.  ACPI-CA current position for this stuff is to
> >check bound such regions even though that will implies that it
> >can not provide total compatibility support.
> >Note that their are other compatibilty issues as well.  For example,
> >most if not all toshiba laptops (I speak for the non-compal case)
> >was shipped with an error for which they implicitely returned a value.
> >
> >It was stated by ACPI sig. that it is an error.  Note that Toshiba
> >has then released new bios which corrected this behaviour.
> >
> >Alas, it is somehow hard to get correct support from all vendor...
> >
> >The issue you get (a bad sized operational region) is present in most
> >of the toshiba-compal model series.  And toshiba still do not have
> >corrected this issue, even though they were warned about.
> >
> >So, sometimes, complaining to the bios vendor work, sometimes not.  Just
> >that we get the same kind of stupid answer as 'it work under windows'
> >even from the same vendor.
> >
> >Cheers,
> >
> > 
> >
> X Karol : Thanks for the documentation
> 
> X Bruno:
> 
> If I try to reassemble the code I get these errors:
> 
> Intel ACPI Component Architecture
> ASL Optimizing Compiler / AML Disassembler version 20030228 [Feb 28 2003]
> Copyright (C) 2000 - 2003 Intel Corporation
> Supports ACPI Specification Revision 2.0b
> 
> dsdt.dsl   864:                 Field (U1D3, WordAcc, NoLock, Preserve)
> Error    1047 -                           ^ Access width is greater than 
> region size
> 
> dsdt.dsl   866:                     UR49,   3
> Error    1051 -                        ^ Access width of Field Unit 
> extends beyond region limit
> 
> dsdt.dsl   870:                 Field (UBP1, WordAcc, NoLock, Preserve)
> Error    1047 -                           ^ Access width is greater than 
> region size
> 
> dsdt.dsl   872:                     U1PE,   2
> Error    1051 -                        ^ Access width of Field Unit 
> extends beyond region limit
> 
> dsdt.dsl   905:                 Field (UBP2, WordAcc, NoLock, Preserve)
> Error    1047 -                           ^ Access width is greater than 
> region size
> 
> dsdt.dsl   907:                     U2PE,   2
> Error    1051 -                        ^ Access width of Field Unit 
> extends beyond region limit
> 
> dsdt.dsl   933:                 Field (UBP3, WordAcc, NoLock, Preserve)
> Error    1047 -                           ^ Access width is greater than 
> region size
> 
> dsdt.dsl   935:                     U3PE,   2
> Error    1051 -                        ^ Access width of Field Unit 
> extends beyond region limit
> 
> dsdt.dsl   961:                 Field (UBP4, WordAcc, NoLock, Preserve)
> Error    1047 -                           ^ Access width is greater than 
> region size
> 
> dsdt.dsl   963:                     U4PE,   2
> Error    1051 -                        ^ Access width of Field Unit 
> extends beyond region limit
> 
> dsdt.dsl  2797:                 Method (STM, 0, Serialized)
> Warning  2019 -                           ^ Not all control paths return 
> a value (STM_)
> 
> dsdt.dsl  3240:     Method (_WAK, 1, NotSerialized)
> Warning  2026 -                ^ Reserved method must return a value (_WAK)
> 
> ASL Input:  dsdt.dsl - 3356 lines, 103057 bytes, 1269 keywords
> Compilation complete. 10 Errors, 2 Warnings, 0 Remarks, 419 Optimizations
> 
> I think this will be hard to fix, right? I should post this to MSI , 

No.  It is not hard to fix.  But I must admit that it can sound 'hard'
to be fixed.
You will have an
OperationRegion (FOO, xxx, yyy, size)
Field (FOO, xxx, yyy, zzz)
{
	...,
	...,
}
(or even more Field statements which refereference
the FOO operational region)

The problem is probably due to the 'size'
in the OperationRegion (FOO, ...)
which is too 'low'.

Please give us the ASL produced, since actually the
Method (STM, 0, Serialized) is more anoying than the
size issue.

Cheers,

-- 
Ducrot Bruno

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


-------------------------------------------------------
This SF.net email is sponsored by:Crypto Challenge is now open! 
Get cracking and register here for some mind boggling fun and 
the chance of winning an Apple iPod:
http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0031en

Re: [Fwd: ACPI error when trying entring in Sleep Mode]

[Ducrot Bruno]

[-- Attachment #1: Type: text/plain, Size: 1665 bytes --]

On Mon, Mar 17, 2003 at 07:20:27PM +0100, Marci wrote:
> For ASL I  think you mean the Source of the disassembled code, so, I 
> attach this to you
> 
> Thanks very much again
> 
> Marcello


Attached then is a quick fix for the size issue, and for the _WAK method.

I will look for the STM one.  Actually, this method is called by two
reserved methods by ACPI (_STM) and is used for setting IDE interface.

Since linux do not support this method, I guess it is not so vital to
correct it (but I will take a look more).

Basically, all the size issue looked like this (I take the first one) :

OperationRegion (U1D3, PCI_Config, 0x49, 0x01)
Field (U1D3, WordAcc, NoLock, Preserve)
{
	UR49, 3
}

The OperationRegion () say:

'This is an operational region for this device.  It in the
PCI Configuration space, begin to register 0x49, and the size
is exactly one byte'

The Field (...) stuff say:

Here are all the register(s) I know about, and how to access them.
You have to access them as Word (*ouch*, actually the size _is_ one
byte, not two!), and the only register known is named UR49, and the
bit relevant for this one is '3'.

Well, trouble then, since we want to access a register which is word
sized, but the operational region 'contain' only one byte...

Then the only things that we have to fix is to increase the size:

OperationRegion (U1D3, PCI_Config, 0x49, 0x02)

so that when we refer now to UR49, we now that we want
to read/write (etc) to bit 3 of the 49th register for this pci
configuration space.

I also corrected the _WAK method as a 'bonus'.

Cheers,

-- 
Ducrot Bruno

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

[-- Attachment #2: fix-sizes_and_wak.diff --]
[-- Type: text/plain, Size: 1866 bytes --]

--- dsdt.dsl	2003/03/17 13:41:43	1.1
+++ dsdt.dsl	2003/03/17 13:50:08
@@ -860,13 +860,13 @@
             Device (USB1)
             {
                 Name (_ADR, 0x00100000)
-                OperationRegion (U1D3, PCI_Config, 0x49, 0x01)
+                OperationRegion (U1D3, PCI_Config, 0x49, 0x02)
                 Field (U1D3, WordAcc, NoLock, Preserve)
                 {
                     UR49,   3
                 }
 
-                OperationRegion (UBP1, PCI_Config, 0x84, 0x01)
+                OperationRegion (UBP1, PCI_Config, 0x84, 0x02)
                 Field (UBP1, WordAcc, NoLock, Preserve)
                 {
                     U1PE,   2
@@ -901,7 +901,7 @@
             Device (USB2)
             {
                 Name (_ADR, 0x00100001)
-                OperationRegion (UBP2, PCI_Config, 0x84, 0x01)
+                OperationRegion (UBP2, PCI_Config, 0x84, 0x02)
                 Field (UBP2, WordAcc, NoLock, Preserve)
                 {
                     U2PE,   2
@@ -929,7 +929,7 @@
             Device (USB3)
             {
                 Name (_ADR, 0x00100002)
-                OperationRegion (UBP3, PCI_Config, 0x84, 0x01)
+                OperationRegion (UBP3, PCI_Config, 0x84, 0x02)
                 Field (UBP3, WordAcc, NoLock, Preserve)
                 {
                     U3PE,   2
@@ -957,7 +957,7 @@
             Device (EHCI)
             {
                 Name (_ADR, 0x00100003)
-                OperationRegion (UBP4, PCI_Config, 0x84, 0x01)
+                OperationRegion (UBP4, PCI_Config, 0x84, 0x02)
                 Field (UBP4, WordAcc, NoLock, Preserve)
                 {
                     U4PE,   2
@@ -3300,6 +3300,7 @@
             Store (0x48, SHCR)
             Store (0xFF, SHST)
         }
+	Return(Package(2) {0, 0})
     }
 
     OperationRegion (PMS0, SystemIO, 0x0800, 0x04)

Re: [Fwd: ACPI error when trying entring in Sleep Mode]

[Marci]

I'me very sorry to disturb you another time , but I need help for a thing.

I've read the instructions on how to override the DSDT table by 
recompiling the linux kernel, but I've not understood clearly the 
process. In the part when it say that I have to make "patch -p1 
/PATH/TO/osl.diff and Customize the path to dstl.hex" (the part 
denominated "How to teach the kernel to use your costum table" )

Thanks again for the help

Marcello



-------------------------------------------------------
This SF.net email is sponsored by:Crypto Challenge is now open! 
Get cracking and register here for some mind boggling fun and 
the chance of winning an Apple iPod:
http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0031en

Re: [Fwd: ACPI error when trying entring in Sleep Mode]

[Marci]

Richard Black wrote:

> Make sure what your current directory is: run the command "pwd"
> Then look at the beginning of the osl.diff file: "head /tmp/osl.diff"
> The basic command is:
>
> patch -p0 /tmp/osl.diff
>
> Increase the -p# number for each of the directories you want patch to 
> ignore.
>
> Here's another way you can do this:
>
> Look at the diff file (also called patch file) to see the number of 
> directories listed, then change directory so that you are now in the 
> same directory as the "osl" file that you need to patch. Then if there 
> are (in the patch file) 3 directories (for example: +++ 
> Blah/Blah/Blah/osl), then run patch -p3 /tmp/osl.diff which will 
> ignore all those 3 directories and will concentrate on updating only 
> the osl file.
>
> Otherwise if this isn't the problem, then I would need to see the 
> output from running the patch command.
>
> Marci wrote:
>
>> Richard Black wrote:
>>
>>> If anyone is having a problem with the documentation then the 
>>> documentation may need to be updated. In the meantime, here's the 
>>> info on how to use patch:
>>>
>>> http://www.cpqlinux.com/patch.html
>>>
>>> I believe all that they are saying with the line:
>>>
>>> "patch -p1 /PATH/TO/osl.diff and Customize the path to dstl.hex"
>>>
>>> is that /PATH/TO/osl.diff needs to point to the os1.diff file 
>>> (wherever you have it stored) so if you have it in your /tmp 
>>> directory then this would look like
>>>
>>> patch -p1 /tmp/osl.diff
>>>
>>>
>>> Marci wrote:
>>>
>>>> I'me very sorry to disturb you another time , but I need help for a 
>>>> thing.
>>>>
>>>> I've read the instructions on how to override the DSDT table by 
>>>> recompiling the linux kernel, but I've not understood clearly the 
>>>> process. In the part when it say that I have to make "patch -p1 
>>>> /PATH/TO/osl.diff and Customize the path to dstl.hex" (the part 
>>>> denominated "How to teach the kernel to use your costum table" )
>>>>
>>>> Thanks again for the help
>>>>
>>>> Marcello
>>>>
>>>>
>>>>
>>>> -------------------------------------------------------
>>>> This SF.net email is sponsored by:Crypto Challenge is now open! Get 
>>>> cracking and register here for some mind boggling fun and the 
>>>> chance of winning an Apple iPod:
>>>> http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0031en
>>>> _______________________________________________
>>>> Acpi-devel mailing list
>>>> Acpi-devel-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org
>>>> https://lists.sourceforge.net/lists/listinfo/acpi-devel
>>>
>>>
>>>
>>>
>>>
>> Ok, I've done this, but when I compile the kernel it says a lot of 
>> errors about dsdt.hex in very much lines. What is wrong :(
>>
>>
>>
>>
>>
>
Ok, I've patched the file osl.c (manually , because the patch found in 
that page doesn't want work ) but I think that I've done a good work 
(i've followed the instructions in the patch file, I've changed only the 
lines that were changed ) . The problem is in recompile the kernel, I 
get these messages.

Thank for your help

Errors:

In file included from osl.c:205:
/home/melchior/dsdt.hex:333: field name not in record or union initializer
/home/melchior/dsdt.hex:333: (near initialization for `AmlCode')
In file included from osl.c:205:
/home/melchior/dsdt.hex:333:68: warning: multi-line string literals are 
deprecated
/home/melchior/dsdt.hex:333: warning: initialization makes integer from 
pointer without a cast
/home/melchior/dsdt.hex:333: initializer element is not computable at 
load time
/home/melchior/dsdt.hex:333: (near initialization for `AmlCode[2552]')
/home/melchior/dsdt.hex:333: syntax error before "SBRGPIX0"
/home/melchior/dsdt.hex:334:68: warning: multi-line string literals are 
deprecated
/home/melchior/dsdt.hex:335:68: warning: multi-line string literals are 
deprecated
/home/melchior/dsdt.hex:336:68: warning: multi-line string literals are 
deprecated
/home/melchior/dsdt.hex:337:68: warning: multi-line string literals are 
deprecated
/home/melchior/dsdt.hex:333: syntax error at '#' token
/home/melchior/dsdt.hex:338:68: warning: multi-line string literals are 
deprecated
/home/melchior/dsdt.hex:339:68: warning: multi-line string literals are 
deprecated
/home/melchior/dsdt.hex:340:68: warning: multi-line string literals are 
deprecated
/home/melchior/dsdt.hex:341:68: warning: multi-line string literals are 
deprecated
/home/melchior/dsdt.hex:342:68: warning: multi-line string literals are 
deprecated
/home/melchior/dsdt.hex:343:68: warning: multi-line string literals are 
deprecated
/home/melchior/dsdt.hex:333: invalid suffix on integer constant
/home/melchior/dsdt.hex:344:68: warning: multi-line string literals are 
deprecated
/home/melchior/dsdt.hex:333: invalid suffix on floating constant
/home/melchior/dsdt.hex:345:68: warning: multi-line string literals are 
deprecated
/home/melchior/dsdt.hex:346:68: warning: multi-line string literals are 
deprecated
/home/melchior/dsdt.hex:347:68: warning: multi-line string literals are 
deprecated
/home/melchior/dsdt.hex:348:68: warning: multi-line string literals are 
deprecated
/home/melchior/dsdt.hex:349:68: warning: multi-line string literals are 
deprecated
/home/melchior/dsdt.hex:350:68: warning: multi-line string literals are 
deprecated
/home/melchior/dsdt.hex:351:68: warning: multi-line string literals are 
deprecated
/home/melchior/dsdt.hex:352:68: warning: multi-line string literals are 
deprecated
/home/melchior/dsdt.hex:353:68: warning: multi-line string literals are 
deprecated
/home/melchior/dsdt.hex:354:68: warning: multi-line string literals are 
deprecated
/home/melchior/dsdt.hex:355:68: warning: multi-line string literals are 
deprecated
/home/melchior/dsdt.hex:356:68: warning: multi-line string literals are 
deprecated
/home/melchior/dsdt.hex:357:68: warning: multi-line string literals are 
deprecated
/home/melchior/dsdt.hex:358:68: warning: multi-line string literals are 
deprecated
/home/melchior/dsdt.hex:359:68: warning: multi-line string literals are 
deprecated
/home/melchior/dsdt.hex:360:68: warning: multi-line string literals are 
deprecated
/home/melchior/dsdt.hex:361:67: warning: multi-line string literals are 
deprecated
/home/melchior/dsdt.hex:362:68: warning: multi-line string literals are 
deprecated
/home/melchior/dsdt.hex:363:68: warning: multi-line string literals are 
deprecated
/home/melchior/dsdt.hex:364:68: warning: multi-line string literals are 
deprecated
/home/melchior/dsdt.hex:365:68: warning: multi-line string literals are 
deprecated
/home/melchior/dsdt.hex:366:67: warning: multi-line string literals are 
deprecated
/home/melchior/dsdt.hex:367:68: warning: multi-line string literals are 
deprecated
/home/melchior/dsdt.hex:368:68: warning: multi-line string literals are 
deprecated
/home/melchior/dsdt.hex:369:68: warning: multi-line string literals are 
deprecated
/home/melchior/dsdt.hex:370:68: warning: multi-line string literals are 
deprecated
/home/melchior/dsdt.hex:371:68: warning: multi-line string literals are 
deprecated
/home/melchior/dsdt.hex:372:68: warning: multi-line string literals are 
deprecated
/home/melchior/dsdt.hex:373:68: warning: multi-line string literals are 
deprecated
/home/melchior/dsdt.hex:333: syntax error at '#' token
/home/melchior/dsdt.hex:374:68: warning: multi-line string literals are 
deprecated
/home/melchior/dsdt.hex:375:68: warning: multi-line string literals are 
deprecated
/home/melchior/dsdt.hex:376:68: warning: multi-line string literals are 
deprecated
/home/melchior/dsdt.hex:377:68: warning: multi-line string literals are 
deprecated
/home/melchior/dsdt.hex:378:68: warning: multi-line string literals are 
deprecated
/home/melchior/dsdt.hex:379:68: warning: multi-line string literals are 
deprecated
/home/melchior/dsdt.hex:380:68: warning: multi-line string literals are 
deprecated
/home/melchior/dsdt.hex:381:68: warning: multi-line string literals are 
deprecated
/home/melchior/dsdt.hex:382:68: warning: multi-line string literals are 
deprecated
/home/melchior/dsdt.hex:383:68: warning: multi-line string literals are 
deprecated
/home/melchior/dsdt.hex:384:68: warning: multi-line string literals are 
deprecated
make[4]: *** [osl.o] Error 1
make[3]: *** [first_rule] Error 2
make[2]: *** [_subdir_acpi] Error 2
make[1]: *** [_dir_drivers] Error 2
make: *** [stamp-build] Error 2





-------------------------------------------------------
This SF.net email is sponsored by:Crypto Challenge is now open! 
Get cracking and register here for some mind boggling fun and 
the chance of winning an Apple iPod:
http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0031en

Re: [Fwd: ACPI error when trying entring in Sleep Mode]

[Ducrot Bruno]

On Mon, Mar 17, 2003 at 11:14:27PM +0100, Marci wrote:
> Richard Black wrote:
> 

...

> 
> Errors:
> 
> In file included from osl.c:205:
> /home/melchior/dsdt.hex:333: field name not in record or union initializer
> /home/melchior/dsdt.hex:333: (near initialization for `AmlCode')
> In file included from osl.c:205:
> /home/melchior/dsdt.hex:333:68: warning: multi-line string literals are 
> deprecated

This patch is not updated to the 'big struct change' that was
done in mid-january.

You have to replace all the
acpi_table_header
with:
struct acpi_table_header

or alternatively look at http://www.poupinou.org/acpi/
for more instruction.

Please note that I am in process to debug more your ASL.

I will point you to the correct diff, etc. when I finished, and
will comment you all the change done (but, I'm a human being,
you known, and I may be slow sometimes...).

Cheers,

-- 
Ducrot Bruno

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


-------------------------------------------------------
This SF.net email is sponsored by: Does your code think in ink? 
You could win a Tablet PC. Get a free Tablet PC hat just for playing. 
What are you waiting for?
http://ads.sourceforge.net/cgi-bin/redirect.pl?micr5043en

Re: [Fwd: ACPI error when trying entring in Sleep Mode]

[Marci]

Ducrot Bruno wrote:

>On Mon, Mar 17, 2003 at 11:14:27PM +0100, Marci wrote:
>  
>
>>Richard Black wrote:
>>
>>    
>>
>
>...
>
>  
>
>>Errors:
>>
>>In file included from osl.c:205:
>>/home/melchior/dsdt.hex:333: field name not in record or union initializer
>>/home/melchior/dsdt.hex:333: (near initialization for `AmlCode')
>>In file included from osl.c:205:
>>/home/melchior/dsdt.hex:333:68: warning: multi-line string literals are 
>>deprecated
>>    
>>
>
>This patch is not updated to the 'big struct change' that was
>done in mid-january.
>
>You have to replace all the
>acpi_table_header
>with:
>struct acpi_table_header
>
>or alternatively look at http://www.poupinou.org/acpi/
>for more instruction.
>
>Please note that I am in process to debug more your ASL.
>
>I will point you to the correct diff, etc. when I finished, and
>will comment you all the change done (but, I'm a human being,
>you known, and I may be slow sometimes...).
>
>Cheers,
>
>  
>
Nope, I've tried all the suggestions, but without results , the same 
errors , I post the errors that I've encountred this time, but I think 
that are the same:

In file included from osl.c:28:
/boot/dsdt_table.h:333: field name not in record or union initializer
/boot/dsdt_table.h:333: (near initialization for `AmlCode')
In file included from osl.c:28:
/boot/dsdt_table.h:333:68: warning: multi-line string literals are 
deprecated
/boot/dsdt_table.h:333: warning: initialization makes integer from 
pointer without a cast
/boot/dsdt_table.h:333: initializer element is not computable at load time
/boot/dsdt_table.h:333: (near initialization for `AmlCode[2552]')
/boot/dsdt_table.h:333: syntax error before "SBRGPIX0"
/boot/dsdt_table.h:334:68: warning: multi-line string literals are 
deprecated
/boot/dsdt_table.h:335:68: warning: multi-line string literals are 
deprecated
/boot/dsdt_table.h:336:68: warning: multi-line string literals are 
deprecated
/boot/dsdt_table.h:337:68: warning: multi-line string literals are 
deprecated
/boot/dsdt_table.h:333: syntax error at '#' token
/boot/dsdt_table.h:338:68: warning: multi-line string literals are 
deprecated
/boot/dsdt_table.h:339:68: warning: multi-line string literals are 
deprecated
/boot/dsdt_table.h:340:68: warning: multi-line string literals are 
deprecated
/boot/dsdt_table.h:341:68: warning: multi-line string literals are 
deprecated
/boot/dsdt_table.h:342:68: warning: multi-line string literals are 
deprecated
/boot/dsdt_table.h:343:68: warning: multi-line string literals are 
deprecated
/boot/dsdt_table.h:333: invalid suffix on integer constant
/boot/dsdt_table.h:344:68: warning: multi-line string literals are 
deprecated
/boot/dsdt_table.h:333: invalid suffix on floating constant
/boot/dsdt_table.h:345:68: warning: multi-line string literals are 
deprecated
/boot/dsdt_table.h:346:68: warning: multi-line string literals are 
deprecated
/boot/dsdt_table.h:347:68: warning: multi-line string literals are 
deprecated
/boot/dsdt_table.h:348:68: warning: multi-line string literals are 
deprecated
/boot/dsdt_table.h:349:68: warning: multi-line string literals are 
deprecated
/boot/dsdt_table.h:350:68: warning: multi-line string literals are 
deprecated
/boot/dsdt_table.h:351:68: warning: multi-line string literals are 
deprecated
/boot/dsdt_table.h:352:68: warning: multi-line string literals are 
deprecated
/boot/dsdt_table.h:353:68: warning: multi-line string literals are 
deprecated
/boot/dsdt_table.h:354:68: warning: multi-line string literals are 
deprecated
/boot/dsdt_table.h:355:68: warning: multi-line string literals are 
deprecated
/boot/dsdt_table.h:356:68: warning: multi-line string literals are 
deprecated
/boot/dsdt_table.h:357:68: warning: multi-line string literals are 
deprecated
/boot/dsdt_table.h:358:68: warning: multi-line string literals are 
deprecated
/boot/dsdt_table.h:359:68: warning: multi-line string literals are 
deprecated
/boot/dsdt_table.h:360:68: warning: multi-line string literals are 
deprecated
/boot/dsdt_table.h:361:67: warning: multi-line string literals are 
deprecated
/boot/dsdt_table.h:362:68: warning: multi-line string literals are 
deprecated
/boot/dsdt_table.h:363:68: warning: multi-line string literals are 
deprecated
/boot/dsdt_table.h:364:68: warning: multi-line string literals are 
deprecated
/boot/dsdt_table.h:365:68: warning: multi-line string literals are 
deprecated
/boot/dsdt_table.h:366:67: warning: multi-line string literals are 
deprecated
/boot/dsdt_table.h:367:68: warning: multi-line string literals are 
deprecated
/boot/dsdt_table.h:368:68: warning: multi-line string literals are 
deprecated
/boot/dsdt_table.h:369:68: warning: multi-line string literals are 
deprecated
/boot/dsdt_table.h:370:68: warning: multi-line string literals are 
deprecated
/boot/dsdt_table.h:371:68: warning: multi-line string literals are 
deprecated
/boot/dsdt_table.h:372:68: warning: multi-line string literals are 
deprecated
/boot/dsdt_table.h:373:68: warning: multi-line string literals are 
deprecated
/boot/dsdt_table.h:333: syntax error at '#' token
/boot/dsdt_table.h:374:68: warning: multi-line string literals are 
deprecated
/boot/dsdt_table.h:375:68: warning: multi-line string literals are 
deprecated
/boot/dsdt_table.h:376:68: warning: multi-line string literals are 
deprecated
/boot/dsdt_table.h:377:68: warning: multi-line string literals are 
deprecated
/boot/dsdt_table.h:378:68: warning: multi-line string literals are 
deprecated
/boot/dsdt_table.h:379:68: warning: multi-line string literals are 
deprecated
/boot/dsdt_table.h:380:68: warning: multi-line string literals are 
deprecated
/boot/dsdt_table.h:381:68: warning: multi-line string literals are 
deprecated
/boot/dsdt_table.h:382:68: warning: multi-line string literals are 
deprecated
/boot/dsdt_table.h:383:68: warning: multi-line string literals are 
deprecated
/boot/dsdt_table.h:384:68: warning: multi-line string literals are 
deprecated
make[4]: *** [osl.o] Error 1
make[3]: *** [first_rule] Error 2
make[2]: *** [_subdir_acpi] Error 2
make[1]: *** [_dir_drivers] Error 2
make: *** [stamp-build] Error 2


Bye and thanks again for the time that you loose for me






-------------------------------------------------------
This SF.net email is sponsored by: Does your code think in ink? 
You could win a Tablet PC. Get a free Tablet PC hat just for playing. 
What are you waiting for?
http://ads.sourceforge.net/cgi-bin/redirect.pl?micr5043en

Re: [Fwd: ACPI error when trying entring in Sleep Mode]

[Ducrot Bruno]

Hi Marcello,

The diff is at the end of this email, and can be found
at:
ftp://ftp.poupinou.org/acpi/MSI/

There is also an .hex file (namely MSI_KT4_ULTRA.hex.bz2)
The original asl is here, and the corrected asl.

You can can use with instruction found at
http://www.poupinou.org/acpi/over.html
or any other sites which have such kind of support (Richard one,
acpi.sf.net, Faye one, etc.)


Now my comment:

1- first I made a mistake.  Instead of changing the WordAcc, I
blindly increased the size of the Operational Region(s) that
where buggy.  I think that actually it is enough to change
WordAcc by ByteAcc instead.  This is done with the attached
diff.  I also said (certainly because I needed to go to sleep)
that for example those ASL statements:

OperationRegion (U1D3, PCI_Config, 0x49, 0x01)
Field (U1D3, WordAcc, NoLock, Preserve)
{
   UR49,   3
}

mean something like
we acced as a word pci register at 0x49 and bit 3 is relevant

which is wrong (sorry).  It mean actually that only the third
bits are relevants (bit 0 to 2).

Next, what did you think now if ACPI-AC blindly do not check
any more the size of the operational region (as in Windows).
Then we can not actually provide the right thing to do, that is
the Field (..) give us faulty information.


2- the STM issue (the 'last' warning) you get is now resolved.
The problem is that this method wanted to know if it can
access some PCI configuration register at the IDE PCI bridge.
This was actually done by copying (I think) another function (the
GTM one), but is actually wrong.  A way to do it clean
is actually to check in the 2 _STM functions if we can access
the PCI configuration space of the IDE bridge, then continue
if it is OK.


A last word.  I can not promise you that all will be OK, even in a
Windows system.


--- dsdt.dsl	2003/03/17 13:41:43	1.1
+++ dsdt.dsl	2003/03/18 09:03:12
@@ -861,13 +861,13 @@
             {
                 Name (_ADR, 0x00100000)
                 OperationRegion (U1D3, PCI_Config, 0x49, 0x01)
-                Field (U1D3, WordAcc, NoLock, Preserve)
+                Field (U1D3, ByteAcc, NoLock, Preserve)
                 {
                     UR49,   3
                 }
 
                 OperationRegion (UBP1, PCI_Config, 0x84, 0x01)
-                Field (UBP1, WordAcc, NoLock, Preserve)
+                Field (UBP1, ByteAcc, NoLock, Preserve)
                 {
                     U1PE,   2
                 }
@@ -902,7 +902,7 @@
             {
                 Name (_ADR, 0x00100001)
                 OperationRegion (UBP2, PCI_Config, 0x84, 0x01)
-                Field (UBP2, WordAcc, NoLock, Preserve)
+                Field (UBP2, ByteAcc, NoLock, Preserve)
                 {
                     U2PE,   2
                 }
@@ -930,7 +930,7 @@
             {
                 Name (_ADR, 0x00100002)
                 OperationRegion (UBP3, PCI_Config, 0x84, 0x01)
-                Field (UBP3, WordAcc, NoLock, Preserve)
+                Field (UBP3, ByteAcc, NoLock, Preserve)
                 {
                     U3PE,   2
                 }
@@ -958,7 +958,7 @@
             {
                 Name (_ADR, 0x00100003)
                 OperationRegion (UBP4, PCI_Config, 0x84, 0x01)
-                Field (UBP4, WordAcc, NoLock, Preserve)
+                Field (UBP4, ByteAcc, NoLock, Preserve)
                 {
                     U4PE,   2
                 }
@@ -2653,17 +2653,24 @@
                         Store (PSUE, GSUE)
                         Store (PSUT, GSUT)
                         Store (PSCR, GSCR)
-                        STM ()
-                        Store (GMPT, PMPT)
-                        Store (GMUE, PMUE)
-                        Store (GMUT, PMUT)
-                        Store (GMCR, PMCR)
-                        Store (GSPT, PSPT)
-                        Store (GSUE, PSUE)
-                        Store (GSUT, PSUT)
-                        Store (GSCR, PSCR)
-                        Store (GTF (0x00, Arg1), ATA0)
-                        Store (GTF (0x01, Arg2), ATA1)
+			If (REGF)
+			{
+			    STM()
+                            Store (GMPT, PMPT)
+                            Store (GMUE, PMUE)
+                            Store (GMUT, PMUT)
+                            Store (GMCR, PMCR)
+                            Store (GSPT, PSPT)
+                            Store (GSUE, PSUE)
+                            Store (GSUT, PSUT)
+                            Store (GSCR, PSCR)
+                            Store (GTF (0x00, Arg1), ATA0)
+                            Store (GTF (0x01, Arg2), ATA1)
+			}
+			Else
+			{
+			    Store ("Trying to access IDE HWIF registers when not allowed", Debug)
+			}
                     }
 
                     Device (DRV0)
@@ -2707,17 +2714,24 @@
                         Store (SSUE, GSUE)
                         Store (SSUT, GSUT)
                         Store (SSCR, GSCR)
-                        STM ()
-                        Store (GMPT, SMPT)
-                        Store (GMUE, SMUE)
-                        Store (GMUT, SMUT)
-                        Store (GMCR, SMCR)
-                        Store (GSPT, SSPT)
-                        Store (GSUE, SSUE)
-                        Store (GSUT, SSUT)
-                        Store (GSCR, SSCR)
-                        Store (GTF (0x00, Arg1), ATA2)
-                        Store (GTF (0x01, Arg2), ATA3)
+			If (REGF)
+			{
+			    STM()
+                            Store (GMPT, SMPT)
+                            Store (GMUE, SMUE)
+                            Store (GMUT, SMUT)
+                            Store (GMCR, SMCR)
+                            Store (GSPT, SSPT)
+                            Store (GSUE, SSUE)
+                            Store (GSUT, SSUT)
+                            Store (GSCR, SSCR)
+                            Store (GTF (0x00, Arg1), ATA2)
+                            Store (GTF (0x01, Arg2), ATA3)
+			}
+			Else
+			{
+			    Store ("Trying to access IDE HWIF registers when not allowed", Debug)
+			}
                     }
 
                     Device (DRV0)
@@ -2796,11 +2810,11 @@
 
                 Method (STM, 0, Serialized)
                 {
-                    If (REGF) {}
-                    Else
-                    {
-                        Return (TMD0)
-                    }
+                    // If (REGF) {}
+                    // Else
+                    // {
+                    //     Return (TMD0)
+                    // }
 
                     Store (0x00, GMUE)
                     Store (0x07, GMUT)
@@ -3300,6 +3314,7 @@
             Store (0x48, SHCR)
             Store (0xFF, SHST)
         }
+	Return(Package(2) {0, 0})
     }
 
     OperationRegion (PMS0, SystemIO, 0x0800, 0x04)



Cheers,

-- 
Ducrot Bruno

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


-------------------------------------------------------
This SF.net email is sponsored by: Does your code think in ink? 
You could win a Tablet PC. Get a free Tablet PC hat just for playing. 
What are you waiting for?
http://ads.sourceforge.net/cgi-bin/redirect.pl?micr5043en

Re: [Fwd: ACPI error when trying entring in Sleep Mode]

[Marci]

Ducrot Bruno wrote:

>On Tue, Mar 18, 2003 at 03:10:04PM +0100, Marci wrote:
>  
>
>>Ducrot Bruno wrote:
>>
>>    
>>
>>Nope, I've tried all the suggestions, but without results , the same 
>>errors , I post the errors that I've encountred this time, but I think 
>>that are the same:
>>    
>>
>
>...
>
>  
>
>>Bye and thanks again for the time that you loose for me
>>
>>    
>>
>
>Just receive when I wrote to you to say that I finished..
>
>Could you try
>ftp://ftp.poupinou.org/acpi/MSI/MSI_KT4_Ultra.hex.bz2
>
>with instruction at http://www.poupinou.org/acpi/over.html
>
>hope that will work this time!
>
>Cheers
>
>  
>
Nothing, in truth I don't know what I should do . I've used the .hex 
file found in that FTP, but the problem is the same.  The kernel doesn't 
accept the file :-(
Same errors.
Bho.
Where I make my mistake?
I 've took the file, ad renamed in the /boot directory as dsdt_table.h , 
then I've uncompressed the kernel, applied the 2.4.21-pre4 patch and the 
ACPI patch for this kernel, then I've applied the osl.c patch (It say 
"Hunk succeded" , so I think that is ok) and then I configure and 
recompile it. And appears this error.





-------------------------------------------------------
This SF.net email is sponsored by: Does your code think in ink? 
You could win a Tablet PC. Get a free Tablet PC hat just for playing. 
What are you waiting for?
http://ads.sourceforge.net/cgi-bin/redirect.pl?micr5043en

Re: [Fwd: ACPI error when trying entring in Sleep Mode]

[Ducrot Bruno]

On Tue, Mar 18, 2003 at 03:58:31PM +0100, Marci wrote:
> Ducrot Bruno wrote:
> 
> >On Tue, Mar 18, 2003 at 03:10:04PM +0100, Marci wrote:
> > 
> >
> >>Ducrot Bruno wrote:
> >>
> >>   
> >>
> >>Nope, I've tried all the suggestions, but without results , the same 
> >>errors , I post the errors that I've encountred this time, but I think 
> >>that are the same:
> >>   
> >>
> >
> >...
> >
> > 
> >
> >>Bye and thanks again for the time that you loose for me
> >>
> >>   
> >>
> >
> >Just receive when I wrote to you to say that I finished..
> >
> >Could you try
> >ftp://ftp.poupinou.org/acpi/MSI/MSI_KT4_Ultra.hex.bz2
> >
> >with instruction at http://www.poupinou.org/acpi/over.html
> >
> >hope that will work this time!
> >
> >Cheers
> >
> > 
> >
> Nothing, in truth I don't know what I should do . I've used the .hex 
> file found in that FTP, but the problem is the same.  The kernel doesn't 
> accept the file :-(
> Same errors.
> Bho.
> Where I make my mistake?
> I 've took the file, ad renamed in the /boot directory as dsdt_table.h , 
> then I've uncompressed the kernel, applied the 2.4.21-pre4 patch and the 
> ACPI patch for this kernel, then I've applied the osl.c patch (It say 
> "Hunk succeded" , so I think that is ok) and then I configure and 
> recompile it. And appears this error.

It's me.  Sorry.  My over-20030109.patch
is not adapted to do the /boot/dsdt_table.h inclusion.
actually, it was more an 'informal' issue for others peoples
from what we can read in the acpi sourceforge net documentation.

The include look like in my patch:
#include "dsdt_table.h"

which is then appropriate if you copy the .hex file in the
same way I wrote in my site:


<quote>
2- The dsdt_table.h file

Get one of the .hex file provided by ftp.poupinou.org, or generate one via iasl. You copy (or link) this file in:
linux/include/acpi/dsdt_table.h
for acpi-20030122 or newer,

or you copy (or link) this file in:
linux/drivers/acpi/include/dsdt_table.h
for older release of acpi.
</quote>

so that actually I think you still include the 'wrong' .hex file.
Then, according to what is wroten in over.html, if you use
over-20030101.patch, you should copy the hex file under in
linux/include/acpi/dsdt_table.h

An alternative also (and I think you may try to do that actually in a
first attempt) is to copy the .hex file directly under

linux/drivers/acpi/dsdt_table.h

so that we will be really sure that the correct one will in the right
place.

(btw, I would be happy to know why the old one do not work.  If you can
send me this one).

Cheers,

-- 
Ducrot Bruno

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


-------------------------------------------------------
This SF.net email is sponsored by: Does your code think in ink? 
You could win a Tablet PC. Get a free Tablet PC hat just for playing. 
What are you waiting for?
http://ads.sourceforge.net/cgi-bin/redirect.pl?micr5043en

RE: [Fwd: ACPI error when trying entring in Sleep Mode]

[Moore, Robert]

> Next, what did you think now if ACPI-AC blindly do not check
> any more the size of the operational region (as in Windows).
> Then we can not actually provide the right thing to do, that is
> the Field (..) give us faulty information.


Yes, this is exactly the problem.  The AML interpreter cannot simply guess
about what the ASL programmer intended.  Either the length of the Operation
Region is incorrect or the access width of the field is wrong.  The
interpreter has no way of knowing which one (or both) is/are wrong.

Bob


> -----Original Message-----
> From: Ducrot Bruno [mailto:ducrot-kk6yZipjEM5g9hUCZPvPmw@public.gmane.org]
> Sent: Tuesday, March 18, 2003 6:13 AM
> To: Marci
> Cc: acpi-devel-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org
> Subject: Re: [ACPI] [Fwd: ACPI error when trying entring in Sleep Mode]
> 
> 
> Hi Marcello,
> 
> The diff is at the end of this email, and can be found
> at:
> ftp://ftp.poupinou.org/acpi/MSI/
> 
> There is also an .hex file (namely MSI_KT4_ULTRA.hex.bz2)
> The original asl is here, and the corrected asl.
> 
> You can can use with instruction found at
> http://www.poupinou.org/acpi/over.html
> or any other sites which have such kind of support (Richard one,
> acpi.sf.net, Faye one, etc.)
> 
> 
> Now my comment:
> 
> 1- first I made a mistake.  Instead of changing the WordAcc, I
> blindly increased the size of the Operational Region(s) that
> where buggy.  I think that actually it is enough to change
> WordAcc by ByteAcc instead.  This is done with the attached
> diff.  I also said (certainly because I needed to go to sleep)
> that for example those ASL statements:
> 
> OperationRegion (U1D3, PCI_Config, 0x49, 0x01)
> Field (U1D3, WordAcc, NoLock, Preserve)
> {
>    UR49,   3
> }
> 
> mean something like
> we acced as a word pci register at 0x49 and bit 3 is relevant
> 
> which is wrong (sorry).  It mean actually that only the third
> bits are relevants (bit 0 to 2).
> 
> Next, what did you think now if ACPI-AC blindly do not check
> any more the size of the operational region (as in Windows).
> Then we can not actually provide the right thing to do, that is
> the Field (..) give us faulty information.
> 
> 
> 2- the STM issue (the 'last' warning) you get is now resolved.
> The problem is that this method wanted to know if it can
> access some PCI configuration register at the IDE PCI bridge.
> This was actually done by copying (I think) another function (the
> GTM one), but is actually wrong.  A way to do it clean
> is actually to check in the 2 _STM functions if we can access
> the PCI configuration space of the IDE bridge, then continue
> if it is OK.
> 
> 
> A last word.  I can not promise you that all will be OK, even in a
> Windows system.
> 
> 
> --- dsdt.dsl	2003/03/17 13:41:43	1.1
> +++ dsdt.dsl	2003/03/18 09:03:12
> @@ -861,13 +861,13 @@
>              {
>                  Name (_ADR, 0x00100000)
>                  OperationRegion (U1D3, PCI_Config, 0x49, 0x01)
> -                Field (U1D3, WordAcc, NoLock, Preserve)
> +                Field (U1D3, ByteAcc, NoLock, Preserve)
>                  {
>                      UR49,   3
>                  }
> 
>                  OperationRegion (UBP1, PCI_Config, 0x84, 0x01)
> -                Field (UBP1, WordAcc, NoLock, Preserve)
> +                Field (UBP1, ByteAcc, NoLock, Preserve)
>                  {
>                      U1PE,   2
>                  }
> @@ -902,7 +902,7 @@
>              {
>                  Name (_ADR, 0x00100001)
>                  OperationRegion (UBP2, PCI_Config, 0x84, 0x01)
> -                Field (UBP2, WordAcc, NoLock, Preserve)
> +                Field (UBP2, ByteAcc, NoLock, Preserve)
>                  {
>                      U2PE,   2
>                  }
> @@ -930,7 +930,7 @@
>              {
>                  Name (_ADR, 0x00100002)
>                  OperationRegion (UBP3, PCI_Config, 0x84, 0x01)
> -                Field (UBP3, WordAcc, NoLock, Preserve)
> +                Field (UBP3, ByteAcc, NoLock, Preserve)
>                  {
>                      U3PE,   2
>                  }
> @@ -958,7 +958,7 @@
>              {
>                  Name (_ADR, 0x00100003)
>                  OperationRegion (UBP4, PCI_Config, 0x84, 0x01)
> -                Field (UBP4, WordAcc, NoLock, Preserve)
> +                Field (UBP4, ByteAcc, NoLock, Preserve)
>                  {
>                      U4PE,   2
>                  }
> @@ -2653,17 +2653,24 @@
>                          Store (PSUE, GSUE)
>                          Store (PSUT, GSUT)
>                          Store (PSCR, GSCR)
> -                        STM ()
> -                        Store (GMPT, PMPT)
> -                        Store (GMUE, PMUE)
> -                        Store (GMUT, PMUT)
> -                        Store (GMCR, PMCR)
> -                        Store (GSPT, PSPT)
> -                        Store (GSUE, PSUE)
> -                        Store (GSUT, PSUT)
> -                        Store (GSCR, PSCR)
> -                        Store (GTF (0x00, Arg1), ATA0)
> -                        Store (GTF (0x01, Arg2), ATA1)
> +			If (REGF)
> +			{
> +			    STM()
> +                            Store (GMPT, PMPT)
> +                            Store (GMUE, PMUE)
> +                            Store (GMUT, PMUT)
> +                            Store (GMCR, PMCR)
> +                            Store (GSPT, PSPT)
> +                            Store (GSUE, PSUE)
> +                            Store (GSUT, PSUT)
> +                            Store (GSCR, PSCR)
> +                            Store (GTF (0x00, Arg1), ATA0)
> +                            Store (GTF (0x01, Arg2), ATA1)
> +			}
> +			Else
> +			{
> +			    Store ("Trying to access IDE HWIF registers when
not
> allowed", Debug)
> +			}
>                      }
> 
>                      Device (DRV0)
> @@ -2707,17 +2714,24 @@
>                          Store (SSUE, GSUE)
>                          Store (SSUT, GSUT)
>                          Store (SSCR, GSCR)
> -                        STM ()
> -                        Store (GMPT, SMPT)
> -                        Store (GMUE, SMUE)
> -                        Store (GMUT, SMUT)
> -                        Store (GMCR, SMCR)
> -                        Store (GSPT, SSPT)
> -                        Store (GSUE, SSUE)
> -                        Store (GSUT, SSUT)
> -                        Store (GSCR, SSCR)
> -                        Store (GTF (0x00, Arg1), ATA2)
> -                        Store (GTF (0x01, Arg2), ATA3)
> +			If (REGF)
> +			{
> +			    STM()
> +                            Store (GMPT, SMPT)
> +                            Store (GMUE, SMUE)
> +                            Store (GMUT, SMUT)
> +                            Store (GMCR, SMCR)
> +                            Store (GSPT, SSPT)
> +                            Store (GSUE, SSUE)
> +                            Store (GSUT, SSUT)
> +                            Store (GSCR, SSCR)
> +                            Store (GTF (0x00, Arg1), ATA2)
> +                            Store (GTF (0x01, Arg2), ATA3)
> +			}
> +			Else
> +			{
> +			    Store ("Trying to access IDE HWIF registers when
not
> allowed", Debug)
> +			}
>                      }
> 
>                      Device (DRV0)
> @@ -2796,11 +2810,11 @@
> 
>                  Method (STM, 0, Serialized)
>                  {
> -                    If (REGF) {}
> -                    Else
> -                    {
> -                        Return (TMD0)
> -                    }
> +                    // If (REGF) {}
> +                    // Else
> +                    // {
> +                    //     Return (TMD0)
> +                    // }
> 
>                      Store (0x00, GMUE)
>                      Store (0x07, GMUT)
> @@ -3300,6 +3314,7 @@
>              Store (0x48, SHCR)
>              Store (0xFF, SHST)
>          }
> +	Return(Package(2) {0, 0})
>      }
> 
>      OperationRegion (PMS0, SystemIO, 0x0800, 0x04)
> 
> 
> 
> Cheers,
> 
> --
> Ducrot Bruno
> 
> --  Which is worse:  ignorance or apathy?
> --  Don't know.  Don't care.
> 
> 
> -------------------------------------------------------
> This SF.net email is sponsored by: Does your code think in ink?
> You could win a Tablet PC. Get a free Tablet PC hat just for playing.
> What are you waiting for?
> http://ads.sourceforge.net/cgi-bin/redirect.pl?micr5043en
> _______________________________________________
> 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: Does your code think in ink? 
You could win a Tablet PC. Get a free Tablet PC hat just for playing. 
What are you waiting for?
http://ads.sourceforge.net/cgi-bin/redirect.pl?micr5043en