RE: no /proc/acpi, trying to dump dsdt to a file

RE: no /proc/acpi, trying to dump dsdt to a file

[Moore, Robert]

Does this machine boot Windows ok?


> -----Original Message-----
> From: linux-acpi-owner@vger.kernel.org [mailto:linux-acpi-
> owner@vger.kernel.org] On Behalf Of glen martin
> Sent: Wednesday, March 29, 2006 9:51 AM
> To: linux-acpi@vger.kernel.org
> Subject: no /proc/acpi, trying to dump dsdt to a file
> 
> Greetings,
> 
> I've done some searches, poked around in the kernel source and doc,
> can't seem to find anything relevant.
> 
> kernel is 2.6.15, with gentoo patches and the patch to load a dsdt
from
> initrd.
> 
> I'm trying to dump my dsdt, but there is no /proc/acpi, let alone
> /proc/acpi/dsdt.
> 
> Is there something special needed to make /proc/acpi show up? Or other
> way to get at the existing dsdt in this situation?
> 
> The dsdt table in my BIOS is broken, in case that's relevant and
> nonobvious. :)  I'm hoping the broken existing table isn't what is
> blocking the /proc/acpi ...
> 
> The other interesting (to me, anyway) snippet is that
CONFIG_ACPI_SYSTEM
> doesn't show up when 'make menuconfig', but is set to 'Y' in the
.config
> file.  /drivers/acpi/system.o is built.
> 
> I've tried booting with various kernel parameters, disabling variously
> acpi, apic and lapic. no difference in behavior. right now they're all
> turned on (no special parms on kernel line).
> 
> Here's a snippet from my .config
> 
> #
> # ACPI (Advanced Configuration and Power Interface) Support
> #
> CONFIG_ACPI=y
> # CONFIG_ACPI_AC is not set
> # CONFIG_ACPI_BATTERY is not set
> CONFIG_ACPI_BUTTON=y
> CONFIG_ACPI_VIDEO=y
> # CONFIG_ACPI_HOTKEY is not set
> CONFIG_ACPI_FAN=y
> CONFIG_ACPI_PROCESSOR=y
> CONFIG_ACPI_THERMAL=y
> # CONFIG_ACPI_ASUS is not set
> # CONFIG_ACPI_IBM is not set
> # CONFIG_ACPI_TOSHIBA is not set
> CONFIG_ACPI_CUSTOM_DSDT_INITRD=y
> CONFIG_ACPI_BLACKLIST_YEAR=0
> CONFIG_ACPI_DEBUG=y
> CONFIG_ACPI_EC=y
> CONFIG_ACPI_POWER=y
> CONFIG_ACPI_SYSTEM=y
> CONFIG_X86_PM_TIMER=y
> # CONFIG_ACPI_CONTAINER is not set
> 
> Here's the dmesg output when loading the existing BIOS DSDT, in case
> that is relevant.
> 
> ACPI: Looking for DSDT in initramfs... error, file /DSDT.aml not
found.
>  tbxface-0109 [02] load_tables           : ACPI Tables successfully
> acquired
> nssearch-0311: *** Error: ns_search_and_enter: Bad character in ACPI
> Name: 43035350
>  dswload-0292: *** Error: Looking up [0x43035350] (NON-ASCII)
>  in namespace, AE_BAD_CHARACTER
>   psloop-0287 [09] ps_parse_loop         : During name lookup/catalog,
> AE_BAD_CHARACTER
>  tbxface-0115: *** Error: acpi_load_tables: Could not load namespace:
> AE_BAD_CHARACTER
>  tbxface-0123: *** Error: acpi_load_tables: Could not load tables:
> AE_BAD_CHARACTER
> ACPI: Unable to load the System Description Tables
> 
> 
> Any suggestions?
> 
> Thanks in advance,
> 
> glen
> 
> -
> To unsubscribe from this list: send the line "unsubscribe linux-acpi"
in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: no /proc/acpi, trying to dump dsdt to a file

[glen martin]

Yeah, no problem at all. What, Windows care about a broken dsdt? Bah ... :)

A number of folks have run into this dsdt problem with this and related
boards from ASUS. The instructions on how to deal suggest dumping and
fixing the dsdt table,or grabbing a pre-fixed one from the repository on
SF.  I tried the repository, but the iasl compiler won't deal with it,
so the next attempt was to dump and fix my existing broken table from
the BIOS.

Thanks,

glen


Moore, Robert wrote:

>Does this machine boot Windows ok?
>  
>
>>-----Original Message-----
>>From: linux-acpi-owner@vger.kernel.org [mailto:linux-acpi-
>>owner@vger.kernel.org] On Behalf Of glen martin
>>Sent: Wednesday, March 29, 2006 9:51 AM
>>...
>>kernel is 2.6.15, with gentoo patches and the patch to load a dsdt from initrd.
>>
>>I'm trying to dump my dsdt, but there is no /proc/acpi, let alone
>>/proc/acpi/dsdt.
>>
>>Is there something special needed to make /proc/acpi show up? Or other
>>way to get at the existing dsdt in this situation?
>>    
>>
<snip>

RE: no /proc/acpi, trying to dump dsdt to a file

[Moore, Robert]

iASL will automatically convert to using Ones and Zeros where appropriate.

Here's what I get from the disassembled table from windows:

Intel ACPI Component Architecture
ASL Optimizing Compiler version 20060328 [Mar 29 2006]
Copyright (C) 2000 - 2006 Intel Corporation
Supports ACPI Specification Revision 3.0a

dsdt.dsl  2470:                         Name (PS♥C, 0x0A)
Error    1094 -                                 ^ Invalid character (0x03), expecting ASL keyword or name

dsdt.dsl  2470:                         Name (PS♥C, 0x0A)
Error    1094 -     parse error, expecting `','' ^

dsdt.dsl  5205:             If (LNot (And (\_SB.PCI0.HFZF, Local2)))
Error    1062 -                   Object does not exist ^  (\_SB.PCI0.HFZF)

dsdt.dsl  5209:                     Or (\_SB.PCI0.HFZF, Local2, \_SB.PCI0.HFZF)
Error    1062 -                Object does not exist ^  (\_SB.PCI0.HFZF)

dsdt.dsl  5209:                     Or (\_SB.PCI0.HFZF, Local2, \_SB.PCI0.HFZF)
Error    1062 -                                        Object does not exist ^  (\_SB.PCI0.HFZF)

dsdt.dsl  5350:     Method (WFZF, 1, NotSerialized)
Warning  2086 -                ^ Not all control paths return a value (WFZF)

dsdt.dsl  5363:             Return (While (Local1)
Error    1094 -             parse error ^

dsdt.dsl  5377:             })
Error    1094 -  parse error ^

ASL Input:  dsdt.dsl - 6139 lines, 193056 bytes, 1948 keywords
Compilation complete. 7 Errors, 1 Warnings, 0 Remarks, 511 Optimizations


The first two are the bad name. The compiler will never allow this. The next three look like an external() is required (disassembler doesn't output these, yet.)

Last 2 errors are interesting, looks like a problem in either the disassembler or compiler, here's the code:

            Return (While (Local1)
            {
                Stall (0x0F)
                Decrement (Local1)
                If (LEqual (Local1, 0x00))
                {
                    Return (Store (CREG, Local2))
                }

                And (Local2, 0x80, Local2)
                If (LEqual (Local2, 0x00))
                {
                    Return (Decrement (Local1))
                }
            })

Looks very odd, I'll keep looking at it.

BTW, here is the new message from the disassembler:

ACPI Warning (utmisc-0732): Found bad character(s) in name, repaired: [PS*C] [20060328]

> -----Original Message-----
> From: linux-acpi-owner@vger.kernel.org [mailto:linux-acpi-
> owner@vger.kernel.org] On Behalf Of glen martin
> Sent: Wednesday, March 29, 2006 12:28 PM
> To: Moore, Robert
> Cc: linux-acpi@vger.kernel.org
> Subject: Re: no /proc/acpi, trying to dump dsdt to a file
> 
> Doh! So it does. I created the analogous fix, commenting out nssearch.c
> line 406, and now have a shiny disassembled DSDT to play with. Hooray!
> 
> I  cleaned the nssearch error messages from the top of the disassembled
> output, then recompiled with iasl, which got a small number of errors to
> track down.
> 
> But remember, this whole story started when iasl was puking on the dsdt
> file I downloaded from sourceforge. So I diff'd my disassembly against
> the file I found in the repository and discovered a large number of
> changes that replace numeric constants "0x00, 0x01" with symbols (ZERO,
> ONE).  Did iasl used to handle symbolic names for constants? I can't
> imagine someone going through to replace all these by hand ... :b
> 
> 
> 
> Moore, Robert wrote:
> 
> >Compiler uses the same error checking code.
> >Bob
> >
> >
> >
> >
> >>test A8N # iasl -d dsdt1.dat
> >>
> >>Intel ACPI Component Architecture
> >>AML Disassembler version 20060127 [Mar 29 2006]
> >>Copyright (C) 2000 - 2006 Intel Corporation
> >>Supports ACPI Specification Revision 3.0a
> >>
> >>Loading Acpi table from file dsdt1.dat
> >>Acpi table [DSDT] successfully installed and loaded
> >>Pass 1 parse of [DSDT]
> >>
> >>test A8N # more dsdt1.dsl
> >>ACPI Error (nssearch-0405): Bad character in ACPI Name: 43035350
> >>[20060127]
> >>ACPI Error (dswload-0393): [0x43035350] (NON-ASCII) Namespace lookup
> >>failure, AE_BAD_CHARACTER
> >>ACPI Exception (psloop-0347): AE_BAD_CHARACTER, During name
> >>lookup/catalog [20060127]
> >>Could not parse ACPI tables, AE_BAD_CHARACTER
> >><>
> >>
> >>
> >>
> 
> -
> To unsubscribe from this list: send the line "unsubscribe linux-acpi" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
-
To unsubscribe from this list: send the line "unsubscribe linux-acpi" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: no /proc/acpi, trying to dump dsdt to a file

[glen martin]

The first two did look like a bad name .. certainly removing the Ctrl-C
character from the middle of the name cleared the error. I haven't made
further headway ... maybe I'll take a stab at the extern.

I still wonder why the compiler was segfaulting on the file from the
repository, instead of my own disassembled one. I've been wandering
through the diff between mine and the repository to see what differences
there are ... and there are a number, but I can't say I understand this
language well enough to know what they're all for.

glen

RE: no /proc/acpi, trying to dump dsdt to a file

[Moore, Robert]

Compiler uses the same error checking code.
Bob


> -----Original Message-----
> From: linux-acpi-owner@vger.kernel.org [mailto:linux-acpi-
> owner@vger.kernel.org] On Behalf Of glen martin
> Sent: Wednesday, March 29, 2006 11:57 AM
> To: Brown, Len
> Cc: linux-acpi@vger.kernel.org
> Subject: Re: no /proc/acpi, trying to dump dsdt to a file
> 
> the nssearch patch certainly bypasses the first level problem. Here's
> the dmesg output with that patch applied.
> 
> <>
>  tbxface-0109 [02] load_tables           : ACPI Tables successfully
> acquired
> nssearch-0311: *** Error: ns_search_and_enter: Bad character in ACPI
> Name: 43035350
> nssearch-0311: *** Error: ns_search_and_enter: Bad character in ACPI
> Name: 43035350
> Parsing all Control
>
Methods:................................................................
..
> ...
>
........................................................................
..
> .......................
>
........................................................................
..
> .......................
> .........
> Table [DSDT](id 0005) - 815 Objects with 73 Devices 272 Methods 18
Regions
> ACPI Namespace successfully loaded at root c05abe7c
> evxfevnt-0091 [03] enable                : Transition to ACPI mode
> successful
> <>
> 
> Now /proc/acpi/dsdt is present! However:
> <>
> test A8N # cat /proc/acpi/dsdt > dsdt1.dat
> 
> test A8N # iasl -d dsdt1.dat
> 
> Intel ACPI Component Architecture
> AML Disassembler version 20060127 [Mar 29 2006]
> Copyright (C) 2000 - 2006 Intel Corporation
> Supports ACPI Specification Revision 3.0a
> 
> Loading Acpi table from file dsdt1.dat
> Acpi table [DSDT] successfully installed and loaded
> Pass 1 parse of [DSDT]
> 
> test A8N # more dsdt1.dsl
> ACPI Error (nssearch-0405): Bad character in ACPI Name: 43035350
> [20060127]
> ACPI Error (dswload-0393): [0x43035350] (NON-ASCII) Namespace lookup
> failure, AE_BAD_CHARACTER
> ACPI Exception (psloop-0347): AE_BAD_CHARACTER, During name
> lookup/catalog [20060127]
> Could not parse ACPI tables, AE_BAD_CHARACTER
> <>
> 
> 
> I also tried acpidump (thanks for the suggestion), which gave me:
> <>
> test acpidump # ./acpidump -t DSDT -o dsdt.hex
> Wrong checksum for generic table!
> <>
> 
> 
> 
> 
> Brown, Len wrote:
> 
> >>-----Original Message-----
> >>From: Brown, Len
> >>Sent: Wednesday, March 29, 2006 2:04 PM
> >>To: 'glen martin'; linux-acpi@vger.kernel.org
> >>Subject: RE: no /proc/acpi, trying to dump dsdt to a file
> >>
> >>You can dump your ACPI tables with acpidump, no matter if you
> >>are booted in ACPI mode or not.  Get the latest from pmtools here:
> >>
> >>http://ftp.kernel.org/pub/linux/kernel/people/lenb/acpi/utils/
> >>
> >>/DSDT.aml not found.
> >>
> >>
> >>>tbxface-0109 [02] load_tables           : ACPI Tables successfully
> acquired
> >>>nssearch-0311: *** Error: ns_search_and_enter: Bad character in
ACPI
> >>>Name: 43035350
> >>>dswload-0292: *** Error: Looking up [0x43035350] (NON-ASCII)
> >>>in namespace, AE_BAD_CHARACTER
> >>> psloop-0287 [09] ps_parse_loop         : During name
lookup/catalog,
> >>>AE_BAD_CHARACTER
> >>>tbxface-0115: *** Error: acpi_load_tables: Could not load
namespace:
> >>>AE_BAD_CHARACTER
> >>>tbxface-0123: *** Error: acpi_load_tables: Could not load tables:
> >>>AE_BAD_CHARACTER
> >>>ACPI: Unable to load the System Description Tables
> >>>
> >>>
> >>>Any suggestions?
> >>>
> >>>
> >>Replace the non-ascii character with an ascii one.
> >>There is a patch about to work around this -- let me find it...
> >>
> >>
> >
> >Please try the test patch here:
> >https://bugzilla.novell.com/show_bug.cgi?id=147621#c22
> >-
> >To unsubscribe from this list: send the line "unsubscribe linux-acpi"
in
> >the body of a message to majordomo@vger.kernel.org
> >More majordomo info at  http://vger.kernel.org/majordomo-info.html
> >
> >
> >
> 
> -
> To unsubscribe from this list: send the line "unsubscribe linux-acpi"
in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: no /proc/acpi, trying to dump dsdt to a file

[glen martin]

Doh! So it does. I created the analogous fix, commenting out nssearch.c 
line 406, and now have a shiny disassembled DSDT to play with. Hooray!

I  cleaned the nssearch error messages from the top of the disassembled 
output, then recompiled with iasl, which got a small number of errors to 
track down.

But remember, this whole story started when iasl was puking on the dsdt 
file I downloaded from sourceforge. So I diff'd my disassembly against 
the file I found in the repository and discovered a large number of 
changes that replace numeric constants "0x00, 0x01" with symbols (ZERO, 
ONE).  Did iasl used to handle symbolic names for constants? I can't 
imagine someone going through to replace all these by hand ... :b



Moore, Robert wrote:

>Compiler uses the same error checking code.
>Bob
>
>  
>
>
>>test A8N # iasl -d dsdt1.dat
>>
>>Intel ACPI Component Architecture
>>AML Disassembler version 20060127 [Mar 29 2006]
>>Copyright (C) 2000 - 2006 Intel Corporation
>>Supports ACPI Specification Revision 3.0a
>>
>>Loading Acpi table from file dsdt1.dat
>>Acpi table [DSDT] successfully installed and loaded
>>Pass 1 parse of [DSDT]
>>
>>test A8N # more dsdt1.dsl
>>ACPI Error (nssearch-0405): Bad character in ACPI Name: 43035350
>>[20060127]
>>ACPI Error (dswload-0393): [0x43035350] (NON-ASCII) Namespace lookup
>>failure, AE_BAD_CHARACTER
>>ACPI Exception (psloop-0347): AE_BAD_CHARACTER, During name
>>lookup/catalog [20060127]
>>Could not parse ACPI tables, AE_BAD_CHARACTER
>><>
>>
>>    
>>

RE: no /proc/acpi, trying to dump dsdt to a file

[Brown, Len]

>-----Original Message-----
>From: Brown, Len
>Sent: Wednesday, March 29, 2006 2:04 PM
>To: 'glen martin'; linux-acpi@vger.kernel.org
>Subject: RE: no /proc/acpi, trying to dump dsdt to a file
>
>You can dump your ACPI tables with acpidump, no matter if you
>are booted in ACPI mode or not.  Get the latest from pmtools here:
>
>http://ftp.kernel.org/pub/linux/kernel/people/lenb/acpi/utils/
>
>/DSDT.aml not found.
>> tbxface-0109 [02] load_tables           : ACPI Tables successfully acquired
>>nssearch-0311: *** Error: ns_search_and_enter: Bad character in ACPI
>>Name: 43035350
>> dswload-0292: *** Error: Looking up [0x43035350] (NON-ASCII)
>> in namespace, AE_BAD_CHARACTER
>>  psloop-0287 [09] ps_parse_loop         : During name lookup/catalog,
>>AE_BAD_CHARACTER
>> tbxface-0115: *** Error: acpi_load_tables: Could not load namespace:
>>AE_BAD_CHARACTER
>> tbxface-0123: *** Error: acpi_load_tables: Could not load tables:
>>AE_BAD_CHARACTER
>>ACPI: Unable to load the System Description Tables
>>
>>
>>Any suggestions?
>
>Replace the non-ascii character with an ascii one.
>There is a patch about to work around this -- let me find it...

Please try the test patch here:
https://bugzilla.novell.com/show_bug.cgi?id=147621#c22

Re: no /proc/acpi, trying to dump dsdt to a file

[glen martin]

the nssearch patch certainly bypasses the first level problem. Here's 
the dmesg output with that patch applied.

<>
 tbxface-0109 [02] load_tables           : ACPI Tables successfully acquired
nssearch-0311: *** Error: ns_search_and_enter: Bad character in ACPI 
Name: 43035350
nssearch-0311: *** Error: ns_search_and_enter: Bad character in ACPI 
Name: 43035350
Parsing all Control 
Methods:.....................................................................
.................................................................................................
.................................................................................................
.........
Table [DSDT](id 0005) - 815 Objects with 73 Devices 272 Methods 18 Regions
ACPI Namespace successfully loaded at root c05abe7c
evxfevnt-0091 [03] enable                : Transition to ACPI mode 
successful
<>

Now /proc/acpi/dsdt is present! However:
<>
test A8N # cat /proc/acpi/dsdt > dsdt1.dat

test A8N # iasl -d dsdt1.dat

Intel ACPI Component Architecture
AML Disassembler version 20060127 [Mar 29 2006]
Copyright (C) 2000 - 2006 Intel Corporation
Supports ACPI Specification Revision 3.0a

Loading Acpi table from file dsdt1.dat
Acpi table [DSDT] successfully installed and loaded
Pass 1 parse of [DSDT]

test A8N # more dsdt1.dsl
ACPI Error (nssearch-0405): Bad character in ACPI Name: 43035350 [20060127]
ACPI Error (dswload-0393): [0x43035350] (NON-ASCII) Namespace lookup 
failure, AE_BAD_CHARACTER
ACPI Exception (psloop-0347): AE_BAD_CHARACTER, During name 
lookup/catalog [20060127]
Could not parse ACPI tables, AE_BAD_CHARACTER
<>


I also tried acpidump (thanks for the suggestion), which gave me:
<>
test acpidump # ./acpidump -t DSDT -o dsdt.hex
Wrong checksum for generic table!
<>




Brown, Len wrote:

>>-----Original Message-----
>>From: Brown, Len
>>Sent: Wednesday, March 29, 2006 2:04 PM
>>To: 'glen martin'; linux-acpi@vger.kernel.org
>>Subject: RE: no /proc/acpi, trying to dump dsdt to a file
>>
>>You can dump your ACPI tables with acpidump, no matter if you
>>are booted in ACPI mode or not.  Get the latest from pmtools here:
>>
>>http://ftp.kernel.org/pub/linux/kernel/people/lenb/acpi/utils/
>>
>>/DSDT.aml not found.
>>    
>>
>>>tbxface-0109 [02] load_tables           : ACPI Tables successfully acquired
>>>nssearch-0311: *** Error: ns_search_and_enter: Bad character in ACPI
>>>Name: 43035350
>>>dswload-0292: *** Error: Looking up [0x43035350] (NON-ASCII)
>>>in namespace, AE_BAD_CHARACTER
>>> psloop-0287 [09] ps_parse_loop         : During name lookup/catalog,
>>>AE_BAD_CHARACTER
>>>tbxface-0115: *** Error: acpi_load_tables: Could not load namespace:
>>>AE_BAD_CHARACTER
>>>tbxface-0123: *** Error: acpi_load_tables: Could not load tables:
>>>AE_BAD_CHARACTER
>>>ACPI: Unable to load the System Description Tables
>>>
>>>
>>>Any suggestions?
>>>      
>>>
>>Replace the non-ascii character with an ascii one.
>>There is a patch about to work around this -- let me find it...
>>    
>>
>
>Please try the test patch here:
>https://bugzilla.novell.com/show_bug.cgi?id=147621#c22
>-
>To unsubscribe from this list: send the line "unsubscribe linux-acpi" in
>the body of a message to majordomo@vger.kernel.org
>More majordomo info at  http://vger.kernel.org/majordomo-info.html
>
>  
>

RE: no /proc/acpi, trying to dump dsdt to a file

[Moore, Robert]

I would be very interesting to see what windows does with this DSDT when
encountered. If you could get this and send it, it would help.

Windows puts the DSDT into the registry, under
HKEY_LOCAL_MACHINE/HARDWARE/ACPI/DSDT.



> -----Original Message-----
> From: linux-acpi-owner@vger.kernel.org [mailto:linux-acpi-
> owner@vger.kernel.org] On Behalf Of glen martin
> Sent: Wednesday, March 29, 2006 10:50 AM
> To: linux-acpi@vger.kernel.org
> Subject: Re: no /proc/acpi, trying to dump dsdt to a file
> 
> Yeah, no problem at all. What, Windows care about a broken dsdt? Bah
...
> :)
> 
> A number of folks have run into this dsdt problem with this and
related
> boards from ASUS. The instructions on how to deal suggest dumping and
> fixing the dsdt table,or grabbing a pre-fixed one from the repository
on
> SF.  I tried the repository, but the iasl compiler won't deal with it,
> so the next attempt was to dump and fix my existing broken table from
> the BIOS.
> 
> Thanks,
> 
> glen
> 
> 
> Moore, Robert wrote:
> 
> >Does this machine boot Windows ok?
> >
> >
> >>-----Original Message-----
> >>From: linux-acpi-owner@vger.kernel.org [mailto:linux-acpi-
> >>owner@vger.kernel.org] On Behalf Of glen martin
> >>Sent: Wednesday, March 29, 2006 9:51 AM
> >>...
> >>kernel is 2.6.15, with gentoo patches and the patch to load a dsdt
from
> initrd.
> >>
> >>I'm trying to dump my dsdt, but there is no /proc/acpi, let alone
> >>/proc/acpi/dsdt.
> >>
> >>Is there something special needed to make /proc/acpi show up? Or
other
> >>way to get at the existing dsdt in this situation?
> >>
> >>
> <snip>
> 
> -
> To unsubscribe from this list: send the line "unsubscribe linux-acpi"
in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: no /proc/acpi, trying to dump dsdt to a file

[glen martin]

Sent to Robert privately, so I wouldn't spam the list with an 
attachment. If anyone else wants it, let me know.

Moore, Robert wrote:

>I would be very interesting to see what windows does with this DSDT when
>encountered. If you could get this and send it, it would help.
>
>Windows puts the DSDT into the registry, under
>HKEY_LOCAL_MACHINE/HARDWARE/ACPI/DSDT.
>
>
>
>  
>
>>-----Original Message-----
>>From: linux-acpi-owner@vger.kernel.org [mailto:linux-acpi-
>>owner@vger.kernel.org] On Behalf Of glen martin
>>Sent: Wednesday, March 29, 2006 10:50 AM
>>To: linux-acpi@vger.kernel.org
>>Subject: Re: no /proc/acpi, trying to dump dsdt to a file
>>
>>Yeah, no problem at all. What, Windows care about a broken dsdt? Bah
>>    
>>
>...
>  
>
>>:)
>>
>>A number of folks have run into this dsdt problem with this and
>>    
>>
>related
>  
>
>>boards from ASUS. The instructions on how to deal suggest dumping and
>>fixing the dsdt table,or grabbing a pre-fixed one from the repository
>>    
>>
>on
>  
>
>>SF.  I tried the repository, but the iasl compiler won't deal with it,
>>so the next attempt was to dump and fix my existing broken table from
>>the BIOS.
>>
>>Thanks,
>>
>>glen
>>
>>
>>Moore, Robert wrote:
>>
>>    
>>
>>>Does this machine boot Windows ok?
>>>
>>>
>>>      
>>>
>>>>-----Original Message-----
>>>>From: linux-acpi-owner@vger.kernel.org [mailto:linux-acpi-
>>>>owner@vger.kernel.org] On Behalf Of glen martin
>>>>Sent: Wednesday, March 29, 2006 9:51 AM
>>>>...
>>>>kernel is 2.6.15, with gentoo patches and the patch to load a dsdt
>>>>        
>>>>
>from
>  
>
>>initrd.
>>    
>>
>>>>I'm trying to dump my dsdt, but there is no /proc/acpi, let alone
>>>>/proc/acpi/dsdt.
>>>>
>>>>Is there something special needed to make /proc/acpi show up? Or
>>>>        
>>>>
>other
>  
>
>>>>way to get at the existing dsdt in this situation?
>>>>
>>>>
>>>>        
>>>>
>><snip>
>>
>>-
>>To unsubscribe from this list: send the line "unsubscribe linux-acpi"
>>    
>>
>in
>  
>
>>the body of a message to majordomo@vger.kernel.org
>>More majordomo info at  http://vger.kernel.org/majordomo-info.html
>>    
>>
>-
>To unsubscribe from this list: send the line "unsubscribe linux-acpi" in
>the body of a message to majordomo@vger.kernel.org
>More majordomo info at  http://vger.kernel.org/majordomo-info.html
>
>  
>

RE: no /proc/acpi, trying to dump dsdt to a file

[Brown, Len]

You can dump your ACPI tables with acpidump, no matter if you
are booted in ACPI mode or not.  Get the latest from pmtools here:

http://ftp.kernel.org/pub/linux/kernel/people/lenb/acpi/utils/

/DSDT.aml not found.
> tbxface-0109 [02] load_tables           : ACPI Tables successfully acquired
>nssearch-0311: *** Error: ns_search_and_enter: Bad character in ACPI
>Name: 43035350
> dswload-0292: *** Error: Looking up [0x43035350] (NON-ASCII)
> in namespace, AE_BAD_CHARACTER
>  psloop-0287 [09] ps_parse_loop         : During name lookup/catalog,
>AE_BAD_CHARACTER
> tbxface-0115: *** Error: acpi_load_tables: Could not load namespace:
>AE_BAD_CHARACTER
> tbxface-0123: *** Error: acpi_load_tables: Could not load tables:
>AE_BAD_CHARACTER
>ACPI: Unable to load the System Description Tables
>
>
>Any suggestions?

Replace the non-ascii character with an ascii one.
There is a patch about to work around this -- let me find it...

no /proc/acpi, trying to dump dsdt to a file

[glen martin]

Greetings,

I've done some searches, poked around in the kernel source and doc, 
can't seem to find anything relevant.

kernel is 2.6.15, with gentoo patches and the patch to load a dsdt from 
initrd.

I'm trying to dump my dsdt, but there is no /proc/acpi, let alone 
/proc/acpi/dsdt.

Is there something special needed to make /proc/acpi show up? Or other 
way to get at the existing dsdt in this situation?

The dsdt table in my BIOS is broken, in case that's relevant and 
nonobvious. :)  I'm hoping the broken existing table isn't what is 
blocking the /proc/acpi ...

The other interesting (to me, anyway) snippet is that CONFIG_ACPI_SYSTEM 
doesn't show up when 'make menuconfig', but is set to 'Y' in the .config 
file.  /drivers/acpi/system.o is built.

I've tried booting with various kernel parameters, disabling variously 
acpi, apic and lapic. no difference in behavior. right now they're all 
turned on (no special parms on kernel line).

Here's a snippet from my .config

#
# ACPI (Advanced Configuration and Power Interface) Support
#
CONFIG_ACPI=y
# CONFIG_ACPI_AC is not set
# CONFIG_ACPI_BATTERY is not set
CONFIG_ACPI_BUTTON=y
CONFIG_ACPI_VIDEO=y
# CONFIG_ACPI_HOTKEY is not set
CONFIG_ACPI_FAN=y
CONFIG_ACPI_PROCESSOR=y
CONFIG_ACPI_THERMAL=y
# CONFIG_ACPI_ASUS is not set
# CONFIG_ACPI_IBM is not set
# CONFIG_ACPI_TOSHIBA is not set
CONFIG_ACPI_CUSTOM_DSDT_INITRD=y
CONFIG_ACPI_BLACKLIST_YEAR=0
CONFIG_ACPI_DEBUG=y
CONFIG_ACPI_EC=y
CONFIG_ACPI_POWER=y
CONFIG_ACPI_SYSTEM=y
CONFIG_X86_PM_TIMER=y
# CONFIG_ACPI_CONTAINER is not set

Here's the dmesg output when loading the existing BIOS DSDT, in case 
that is relevant.

ACPI: Looking for DSDT in initramfs... error, file /DSDT.aml not found.
 tbxface-0109 [02] load_tables           : ACPI Tables successfully acquired
nssearch-0311: *** Error: ns_search_and_enter: Bad character in ACPI 
Name: 43035350
 dswload-0292: *** Error: Looking up [0x43035350] (NON-ASCII)
 in namespace, AE_BAD_CHARACTER
  psloop-0287 [09] ps_parse_loop         : During name lookup/catalog, 
AE_BAD_CHARACTER
 tbxface-0115: *** Error: acpi_load_tables: Could not load namespace: 
AE_BAD_CHARACTER
 tbxface-0123: *** Error: acpi_load_tables: Could not load tables: 
AE_BAD_CHARACTER
ACPI: Unable to load the System Description Tables


Any suggestions?

Thanks in advance,

glen