* [Fwd: ACPI error when trying entring in Sleep Mode]
@ 2003-03-17 12:50 Marci
[not found] ` <3E75C4A6.6000507-nc/lrvXPQ4s@public.gmane.org>
0 siblings, 1 reply; 15+ messages in thread
From: Marci @ 2003-03-17 12:50 UTC (permalink / raw)
To: acpi-devel-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f
[-- 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
^ permalink raw reply [flat|nested] 15+ messages in thread[parent not found: <3E75C4A6.6000507-nc/lrvXPQ4s@public.gmane.org>]
* Re: [Fwd: ACPI error when trying entring in Sleep Mode] [not found] ` <3E75C4A6.6000507-nc/lrvXPQ4s@public.gmane.org> @ 2003-03-17 13:48 ` Ducrot Bruno [not found] ` <20030317134809.GF8319-j6u/t2rXLliUoIHC/UFpr9i2O/JbrIOy@public.gmane.org> [not found] ` <3E75D6E2.4040001@tin.it> 0 siblings, 2 replies; 15+ messages in thread From: Ducrot Bruno @ 2003-03-17 13:48 UTC (permalink / raw) To: Marci; +Cc: acpi-devel-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f 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 ^ permalink raw reply [flat|nested] 15+ messages in thread
[parent not found: <20030317134809.GF8319-j6u/t2rXLliUoIHC/UFpr9i2O/JbrIOy@public.gmane.org>]
* Re: [Fwd: ACPI error when trying entring in Sleep Mode] [not found] ` <20030317134809.GF8319-j6u/t2rXLliUoIHC/UFpr9i2O/JbrIOy@public.gmane.org> @ 2003-03-17 14:10 ` Marci [not found] ` <3E75D75F.8090908-nc/lrvXPQ4s@public.gmane.org> 0 siblings, 1 reply; 15+ messages in thread From: Marci @ 2003-03-17 14:10 UTC (permalink / raw) To: Ducrot Bruno, acpi-devel-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f 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 ^ permalink raw reply [flat|nested] 15+ messages in thread
[parent not found: <3E75D75F.8090908-nc/lrvXPQ4s@public.gmane.org>]
* Re: [Fwd: ACPI error when trying entring in Sleep Mode] [not found] ` <3E75D75F.8090908-nc/lrvXPQ4s@public.gmane.org> @ 2003-03-17 15:28 ` Karol Kozimor 0 siblings, 0 replies; 15+ messages in thread From: Karol Kozimor @ 2003-03-17 15:28 UTC (permalink / raw) To: Marci; +Cc: Ducrot Bruno, acpi-devel-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f 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 ^ permalink raw reply [flat|nested] 15+ messages in thread
[parent not found: <3E75D6E2.4040001@tin.it>]
[parent not found: <20030317153147.GH8319@poup.poupinou.org>]
[parent not found: <20030317153147.GH8319-j6u/t2rXLliUoIHC/UFpr9i2O/JbrIOy@public.gmane.org>]
* Re: [Fwd: ACPI error when trying entring in Sleep Mode] [not found] ` <20030317153147.GH8319-j6u/t2rXLliUoIHC/UFpr9i2O/JbrIOy@public.gmane.org> @ 2003-03-17 18:01 ` Marci [not found] ` <3E760D7D.4040405-nc/lrvXPQ4s@public.gmane.org> 0 siblings, 1 reply; 15+ messages in thread From: Marci @ 2003-03-17 18:01 UTC (permalink / raw) To: Ducrot Bruno, acpi-devel-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f, sziwan-DETuoxkZsSqrDJvtcaxF/A 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 ^ permalink raw reply [flat|nested] 15+ messages in thread
[parent not found: <3E760D7D.4040405-nc/lrvXPQ4s@public.gmane.org>]
* Re: [Fwd: ACPI error when trying entring in Sleep Mode] [not found] ` <3E760D7D.4040405-nc/lrvXPQ4s@public.gmane.org> @ 2003-03-17 18:16 ` Ducrot Bruno 0 siblings, 0 replies; 15+ messages in thread From: Ducrot Bruno @ 2003-03-17 18:16 UTC (permalink / raw) To: Marci Cc: Ducrot Bruno, acpi-devel-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f, sziwan-DETuoxkZsSqrDJvtcaxF/A 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 ^ permalink raw reply [flat|nested] 15+ messages in thread
[parent not found: <3E7611EB.2050805@tin.it>]
[parent not found: <3E7611EB.2050805-nc/lrvXPQ4s@public.gmane.org>]
* Re: [Fwd: ACPI error when trying entring in Sleep Mode] [not found] ` <3E7611EB.2050805-nc/lrvXPQ4s@public.gmane.org> @ 2003-03-17 18:43 ` Ducrot Bruno [not found] ` <20030317184333.GL8319-j6u/t2rXLliUoIHC/UFpr9i2O/JbrIOy@public.gmane.org> 0 siblings, 1 reply; 15+ messages in thread From: Ducrot Bruno @ 2003-03-17 18:43 UTC (permalink / raw) To: Marci; +Cc: Ducrot Bruno, acpi-devel-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f [-- 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) ^ permalink raw reply [flat|nested] 15+ messages in thread
[parent not found: <20030317184333.GL8319-j6u/t2rXLliUoIHC/UFpr9i2O/JbrIOy@public.gmane.org>]
* Re: [Fwd: ACPI error when trying entring in Sleep Mode] [not found] ` <20030317184333.GL8319-j6u/t2rXLliUoIHC/UFpr9i2O/JbrIOy@public.gmane.org> @ 2003-03-17 19:03 ` Marci [not found] ` <3E762BDD.8030108@hp.com> 0 siblings, 1 reply; 15+ messages in thread From: Marci @ 2003-03-17 19:03 UTC (permalink / raw) To: Ducrot Bruno, acpi-devel-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f 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 ^ permalink raw reply [flat|nested] 15+ messages in thread
[parent not found: <3E762BDD.8030108@hp.com>]
[parent not found: <3E762DED.70301@tin.it>]
[parent not found: <3E763453.1080307@hp.com>]
[parent not found: <3E763453.1080307-VXdhtT5mjnY@public.gmane.org>]
* Re: [Fwd: ACPI error when trying entring in Sleep Mode] [not found] ` <3E763453.1080307-VXdhtT5mjnY@public.gmane.org> @ 2003-03-17 22:14 ` Marci [not found] ` <3E7648C3.9090402-nc/lrvXPQ4s@public.gmane.org> 0 siblings, 1 reply; 15+ messages in thread From: Marci @ 2003-03-17 22:14 UTC (permalink / raw) To: Richard Black; +Cc: Ducrot Bruno, acpi-devel-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f 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 ^ permalink raw reply [flat|nested] 15+ messages in thread
[parent not found: <3E7648C3.9090402-nc/lrvXPQ4s@public.gmane.org>]
* Re: [Fwd: ACPI error when trying entring in Sleep Mode] [not found] ` <3E7648C3.9090402-nc/lrvXPQ4s@public.gmane.org> @ 2003-03-18 9:47 ` Ducrot Bruno [not found] ` <20030318094752.GO8319-j6u/t2rXLliUoIHC/UFpr9i2O/JbrIOy@public.gmane.org> 0 siblings, 1 reply; 15+ messages in thread From: Ducrot Bruno @ 2003-03-18 9:47 UTC (permalink / raw) To: Marci Cc: Richard Black, Ducrot Bruno, acpi-devel-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f 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 ^ permalink raw reply [flat|nested] 15+ messages in thread
[parent not found: <20030318094752.GO8319-j6u/t2rXLliUoIHC/UFpr9i2O/JbrIOy@public.gmane.org>]
* Re: [Fwd: ACPI error when trying entring in Sleep Mode] [not found] ` <20030318094752.GO8319-j6u/t2rXLliUoIHC/UFpr9i2O/JbrIOy@public.gmane.org> @ 2003-03-18 14:10 ` Marci [not found] ` <20030318141933.GU8319@poup.poupinou.org> 2003-03-18 14:13 ` Ducrot Bruno 1 sibling, 1 reply; 15+ messages in thread From: Marci @ 2003-03-18 14:10 UTC (permalink / raw) To: Ducrot Bruno; +Cc: Richard Black, acpi-devel-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f 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 ^ permalink raw reply [flat|nested] 15+ messages in thread
[parent not found: <20030318141933.GU8319@poup.poupinou.org>]
[parent not found: <20030318141933.GU8319-j6u/t2rXLliUoIHC/UFpr9i2O/JbrIOy@public.gmane.org>]
* Re: [Fwd: ACPI error when trying entring in Sleep Mode] [not found] ` <20030318141933.GU8319-j6u/t2rXLliUoIHC/UFpr9i2O/JbrIOy@public.gmane.org> @ 2003-03-18 14:58 ` Marci [not found] ` <3E773417.3030601-nc/lrvXPQ4s@public.gmane.org> 0 siblings, 1 reply; 15+ messages in thread From: Marci @ 2003-03-18 14:58 UTC (permalink / raw) To: Ducrot Bruno, acpi-devel-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f 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 ^ permalink raw reply [flat|nested] 15+ messages in thread
[parent not found: <3E773417.3030601-nc/lrvXPQ4s@public.gmane.org>]
* Re: [Fwd: ACPI error when trying entring in Sleep Mode] [not found] ` <3E773417.3030601-nc/lrvXPQ4s@public.gmane.org> @ 2003-03-18 15:49 ` Ducrot Bruno 0 siblings, 0 replies; 15+ messages in thread From: Ducrot Bruno @ 2003-03-18 15:49 UTC (permalink / raw) To: Marci; +Cc: Ducrot Bruno, acpi-devel-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f 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 ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: [Fwd: ACPI error when trying entring in Sleep Mode] [not found] ` <20030318094752.GO8319-j6u/t2rXLliUoIHC/UFpr9i2O/JbrIOy@public.gmane.org> 2003-03-18 14:10 ` Marci @ 2003-03-18 14:13 ` Ducrot Bruno 1 sibling, 0 replies; 15+ messages in thread From: Ducrot Bruno @ 2003-03-18 14:13 UTC (permalink / raw) To: Marci; +Cc: acpi-devel-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f 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 ^ permalink raw reply [flat|nested] 15+ messages in thread
* RE: [Fwd: ACPI error when trying entring in Sleep Mode] @ 2003-03-18 16:45 Moore, Robert 0 siblings, 0 replies; 15+ messages in thread From: Moore, Robert @ 2003-03-18 16:45 UTC (permalink / raw) To: 'Ducrot Bruno', Marci; +Cc: acpi-devel-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f > 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 ^ permalink raw reply [flat|nested] 15+ messages in thread
end of thread, other threads:[~2003-03-18 16:45 UTC | newest]
Thread overview: 15+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2003-03-17 12:50 [Fwd: ACPI error when trying entring in Sleep Mode] Marci
[not found] ` <3E75C4A6.6000507-nc/lrvXPQ4s@public.gmane.org>
2003-03-17 13:48 ` Ducrot Bruno
[not found] ` <20030317134809.GF8319-j6u/t2rXLliUoIHC/UFpr9i2O/JbrIOy@public.gmane.org>
2003-03-17 14:10 ` Marci
[not found] ` <3E75D75F.8090908-nc/lrvXPQ4s@public.gmane.org>
2003-03-17 15:28 ` Karol Kozimor
[not found] ` <3E75D6E2.4040001@tin.it>
[not found] ` <20030317153147.GH8319@poup.poupinou.org>
[not found] ` <20030317153147.GH8319-j6u/t2rXLliUoIHC/UFpr9i2O/JbrIOy@public.gmane.org>
2003-03-17 18:01 ` Marci
[not found] ` <3E760D7D.4040405-nc/lrvXPQ4s@public.gmane.org>
2003-03-17 18:16 ` Ducrot Bruno
[not found] ` <3E7611EB.2050805@tin.it>
[not found] ` <3E7611EB.2050805-nc/lrvXPQ4s@public.gmane.org>
2003-03-17 18:43 ` Ducrot Bruno
[not found] ` <20030317184333.GL8319-j6u/t2rXLliUoIHC/UFpr9i2O/JbrIOy@public.gmane.org>
2003-03-17 19:03 ` Marci
[not found] ` <3E762BDD.8030108@hp.com>
[not found] ` <3E762DED.70301@tin.it>
[not found] ` <3E763453.1080307@hp.com>
[not found] ` <3E763453.1080307-VXdhtT5mjnY@public.gmane.org>
2003-03-17 22:14 ` Marci
[not found] ` <3E7648C3.9090402-nc/lrvXPQ4s@public.gmane.org>
2003-03-18 9:47 ` Ducrot Bruno
[not found] ` <20030318094752.GO8319-j6u/t2rXLliUoIHC/UFpr9i2O/JbrIOy@public.gmane.org>
2003-03-18 14:10 ` Marci
[not found] ` <20030318141933.GU8319@poup.poupinou.org>
[not found] ` <20030318141933.GU8319-j6u/t2rXLliUoIHC/UFpr9i2O/JbrIOy@public.gmane.org>
2003-03-18 14:58 ` Marci
[not found] ` <3E773417.3030601-nc/lrvXPQ4s@public.gmane.org>
2003-03-18 15:49 ` Ducrot Bruno
2003-03-18 14:13 ` Ducrot Bruno
-- strict thread matches above, loose matches on Subject: below --
2003-03-18 16:45 Moore, Robert
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox