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

Fwd: ACPI error when trying entring in Sleep Mode Marci 3 participants 14 messages Mar 17, 2003 – Mar 18, 2003 19 messages not in the archive ACPI

lore

Share & tools

lore

Marci

author

2003-03-17 12:50 UTC #0 lore raw

No Ideas?

Please :(

I need this

Thanks again

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

A message that is not in the archive (sent off-list or not yet received): 3E75C4A6.6000507-nc/[email protected]

Ducrot Bruno

2003-03-17 13:48 UTC #2 lore raw

Quoted 56 lines · Marci

No Ideas?

Please :(

I need this

Thanks again

From: Marci <voloterreno-nc/[email protected]>
To: [email protected]
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:

Quoted 8 lines

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,

Signature · 11 lines

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

A message that is not in the archive (sent off-list or not yet received): 20030317134809.GF8319-j6u/t2rXLliUoIHC/UFpr9i2O/[email protected]

Marci

author

2003-03-17 14:10 UTC #4 lore raw

Quoted 71 lines · Ducrot Bruno

Quoted 56 lines · Marci

No Ideas?

Please :(

I need this

Thanks again

From: Marci <voloterreno-nc/[email protected]>
To: [email protected]
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

Quoted 7 lines

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

Quoted 9 lines

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

A message that is not in the archive (sent off-list or not yet received): 3E75D75F.8090908-nc/[email protected]

Karol Kozimor

2003-03-17 15:28 UTC #6 lore raw

Thus wrote Marci:

Quoted 1 line

Another thing , where I can find docs on ACPI Assembly language?

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

Signature · 9 lines

Karol 'sziwan' Kozimor
sziwan-DETuoxkZsSqrDJvtcaxF/[email protected]


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

A message that is not in the archive (sent off-list or not yet received): [email protected]

A message that is not in the archive (sent off-list or not yet received): 20030317153147.GH8319-j6u/t2rXLliUoIHC/UFpr9i2O/[email protected]

Marci

author

2003-03-17 18:01 UTC #10 lore raw

Quoted 69 lines · Ducrot Bruno

Quoted 13 lines · Marci
Quoted 9 lines · Ducrot Bruno
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!
Quoted 9 lines
Quoted 6 lines
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.
Quoted 3 lines
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.

Quoted 8 lines

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

A message that is not in the archive (sent off-list or not yet received): 3E760D7D.4040405-nc/[email protected]

Ducrot Bruno

2003-03-17 18:16 UTC #12 lore raw

Quoted 136 lines · Marci

Quoted 71 lines · Ducrot Bruno
Quoted 13 lines · Marci
Quoted 9 lines · Ducrot Bruno
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!
Quoted 10 lines
Quoted 6 lines
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.
Quoted 4 lines
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.
Quoted 8 lines
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_)

Quoted 7 lines

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,

Signature · 11 lines

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

A message that is not in the archive (sent off-list or not yet received): [email protected]

A message that is not in the archive (sent off-list or not yet received): 3E7611EB.2050805-nc/[email protected]

Ducrot Bruno

2003-03-17 18:43 UTC #15 lore raw

Quoted 6 lines · Marci

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,

Signature · 4 lines

Ducrot Bruno

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

dsdt.dsl +6 -5

@@ -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)

A message that is not in the archive (sent off-list or not yet received): 20030317184333.GL8319-j6u/t2rXLliUoIHC/UFpr9i2O/[email protected]

Marci

author

2003-03-17 19:03 UTC #17 lore raw

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

A message that is not in the archive (sent off-list or not yet received): [email protected]

Marci

author

2003-03-17 22:14 UTC #22 lore raw

Quoted 8 lines · Richard Black

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.

Quoted 54 lines

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.
Quoted 45 lines · Marci
Quoted 6 lines · Richard Black
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:
Quoted 31 lines
"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
Quoted 17 lines · 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
_______________________________________________
Acpi-devel mailing list
[email protected]
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

A message that is not in the archive (sent off-list or not yet received): 3E7648C3.9090402-nc/[email protected]

Ducrot Bruno

2003-03-18 09:47 UTC #24 lore raw

Quoted 2 lines · Marci

Richard Black wrote:

...

Quoted 9 lines

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,

Signature · 11 lines

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

A message that is not in the archive (sent off-list or not yet received): 20030318094752.GO8319-j6u/t2rXLliUoIHC/UFpr9i2O/[email protected]

Marci

author

2003-03-18 14:10 UTC #26 lore raw

Quoted 33 lines · Ducrot Bruno

Quoted 4 lines · Marci
Richard Black wrote:
...
Quoted 9 lines
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.

Quoted 10 lines

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

A message that is not in the archive (sent off-list or not yet received): [email protected]

A message that is not in the archive (sent off-list or not yet received): 20030318141933.GU8319-j6u/t2rXLliUoIHC/UFpr9i2O/[email protected]

Marci

author

2003-03-18 14:58 UTC #29 lore raw

Quoted 22 lines · Ducrot Bruno

Quoted 7 lines · Marci
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:
...
Quoted 4 lines
Bye and thanks again for the time that you loose for me
Just receive when I wrote to you to say that I finished..

Quoted 11 lines

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.

A message that is not in the archive (sent off-list or not yet received): 3E773417.3030601-nc/[email protected]

Ducrot Bruno

2003-03-18 15:49 UTC #31 lore raw

Quoted 37 lines · Marci

Quoted 24 lines · Ducrot Bruno
Quoted 9 lines · Marci
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:
...
Quoted 4 lines
Bye and thanks again for the time that you loose for me
Just receive when I wrote to you to say that I finished..
Quoted 11 lines
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

Quoted 11 lines

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,

Signature · 11 lines

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

Ducrot Bruno

2003-03-18 14:13 UTC #32 lore raw

In reply to a message not in the archive

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 +47 ~~-32~~

@@ -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,

Signature · 11 lines

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