DSDT from your system / new DSDT archive

DSDT from your system / new DSDT archive

[Scott Thompson]

Hi all -- I was attempting to find a DSDT archive with sample DSDT 
from a variety of systems.
The closest thing I have found was the archive that was at 
http://acpi.sourceforge.net ; if anyone
knows of another DSDT archive please let me know.

Since a current one doesn't seem to exist, I am attempting to put 
my own database together up on the 
internets (URL coming soon) and am looking for folks to send me the 
DSDT from their systems.  Gathering your system DSDT takes
less than about 2 minutes by running the following:  

Windows:
1. extract acpica tools from acpica.org; latest as of this writing 
is http://acpica.org/download/iasl-win-20080829.zip
2. run 'iasl -g' to extract all acpi tables.
3. send all '.dsl' and '.dat' files extracted

Linux:
1. file is at /proc/acpi/dsdt 
2. may need to, as sudo or root, cp and then 'chown' the file to a 
non-root id to email.

If anyone is interested, please send the files (or url link), 
hardware make/model, and your name/email (if you want credited), to 
postfail@hushmail.com; please no bombardment of the linux-pm / 
linux-acpi lists.

Thanks in advance...

---------------------------------------
Scott Thompson / postfail@hushmail.com
---------------------------------------

Re: DSDT from your system / new DSDT archive

[Henrique de Moraes Holschuh]

On Tue, 16 Sep 2008, Scott Thompson wrote:
> Since a current one doesn't seem to exist, I am attempting to put 
> my own database together up on the 
> internets (URL coming soon) and am looking for folks to send me the 
> DSDT from their systems.  Gathering your system DSDT takes
> less than about 2 minutes by running the following:  

You also want the dmidecode output, which BTW you must sanitize to remove
UUIDs and serial numbers.  Otherwise, the DSDTs are a lot less useful.

-- 
  "One disk to rule them all, One disk to find them. One disk to bring
  them all and in the darkness grind them. In the Land of Redmond
  where the shadows lie." -- The Silicon Valley Tarot
  Henrique Holschuh

Re: DSDT from your system / new DSDT archive

[Henrique de Moraes Holschuh]

Hi Scott!

On Tue, 16 Sep 2008, Henrique de Moraes Holschuh wrote:

> On Tue, 16 Sep 2008, Scott Thompson wrote:
> > Since a current one doesn't seem to exist, I am attempting to put 
> > my own database together up on the 
> > internets (URL coming soon) and am looking for folks to send me the 
> > DSDT from their systems.  Gathering your system DSDT takes
> > less than about 2 minutes by running the following:  
> 
> You also want the dmidecode output, which BTW you must sanitize to remove
> UUIDs and serial numbers.  Otherwise, the DSDTs are a lot less useful.

Come to think of it, the DSDTs are useless without the other tables in most
systems, anyway, so you want to store the entire acpidump :-p

-- 
  "One disk to rule them all, One disk to find them. One disk to bring
  them all and in the darkness grind them. In the Land of Redmond
  where the shadows lie." -- The Silicon Valley Tarot
  Henrique Holschuh

Re: DSDT from your system / new DSDT archive

[Thomas Renninger]

On Wednesday 17 September 2008 04:41:27 Henrique de Moraes Holschuh wrote:
> Hi Scott!
>
> On Tue, 16 Sep 2008, Henrique de Moraes Holschuh wrote:
> > On Tue, 16 Sep 2008, Scott Thompson wrote:
> > > Since a current one doesn't seem to exist, I am attempting to put
> > > my own database together up on the
> > > internets (URL coming soon) and am looking for folks to send me the
> > > DSDT from their systems.  Gathering your system DSDT takes
> > > less than about 2 minutes by running the following:
> >
> > You also want the dmidecode output, which BTW you must sanitize to remove
> > UUIDs and serial numbers.  Otherwise, the DSDTs are a lot less useful.
>
> Come to think of it, the DSDTs are useless without the other tables in most
> systems, anyway, so you want to store the entire acpidump :-p
Exactly.
You should take dmidecode and acpidump in a specific format (provide a small
script to (show how to) gather them?).
You should also double check the info you get uploaded. On the sourceforge
list all kind of broken info was flying around (all kind of compressions
used, only aml, only asl and only hex tables, only the diffs, and more...).

Therefore IMO best is not to only provide a small script how you should gather
and upload the data, but also internally do a quick check the other way round 
whether the data sent up is valid (unzip, acpixtract -a acpidump, [ -e 
DSDT.dsl ] or similar).

I'd also only accept acpidumps or whole zips containing the dumps.
You should not provide extracted acpidumps, even worse disassmbled ones as
the code in there is protected by copyrights.
Also a disclaimer that people must only use the info for getting their
machine running for which they bought the copyrights should be stated 
somewhere.

Expect that you get a lot dumps.

You should state somewhere that people should (if they are doing a BIOS update 
anyway):
   - upload the dumps
   - upgrade the BIOS
   - again upload the dumps
Like that you get a nice history of fixups which can reveal interesting 
things...

      Thomas

PS: This work is very much appreciated. Tell me how I can help.

Re: DSDT from your system / new DSDT archive

[Thomas Renninger]

On Wednesday 17 September 2008 17:44:33 Thomas Renninger wrote:
> On Wednesday 17 September 2008 04:41:27 Henrique de Moraes Holschuh wrote:
> > Hi Scott!
> >
> > On Tue, 16 Sep 2008, Henrique de Moraes Holschuh wrote:
> > > On Tue, 16 Sep 2008, Scott Thompson wrote:
> > > > Since a current one doesn't seem to exist, I am attempting to put
> > > > my own database together up on the
> > > > internets (URL coming soon) and am looking for folks to send me the
> > > > DSDT from their systems.  Gathering your system DSDT takes
> > > > less than about 2 minutes by running the following:
> > >
> > > You also want the dmidecode output, which BTW you must sanitize to
> > > remove UUIDs and serial numbers.  Otherwise, the DSDTs are a lot less
> > > useful.
> >
> > Come to think of it, the DSDTs are useless without the other tables in
> > most systems, anyway, so you want to store the entire acpidump :-p
>
> Exactly.
> You should take dmidecode and acpidump in a specific format (provide a
> small script to (show how to) gather them?).
Plus the possibility to add a diff fixing the DSDT/SSDTs, then you have:
  - acpidump
  - dmidecode
  - fixes.diff
Still it should be checked that the full acpidump is there, the whole data
is not worth much without full acpidump and dmidecode.
Then these examples could greatly help others to get used to and how to
fix general warnings/errors.
Hope some will go one step further and suggest patches on http://acpica.org
to adopt/fix the acpi sources to work well with the ("not totally broken") 
tables.

     Thomas

> You should also double check the info you get uploaded. On the sourceforge
> list all kind of broken info was flying around (all kind of compressions
> used, only aml, only asl and only hex tables, only the diffs, and more...).
>
> Therefore IMO best is not to only provide a small script how you should
> gather and upload the data, but also internally do a quick check the other
> way round whether the data sent up is valid (unzip, acpixtract -a acpidump,
> [ -e DSDT.dsl ] or similar).
>
> I'd also only accept acpidumps or whole zips containing the dumps.
> You should not provide extracted acpidumps, even worse disassmbled ones as
> the code in there is protected by copyrights.
> Also a disclaimer that people must only use the info for getting their
> machine running for which they bought the copyrights should be stated
> somewhere.
>
> Expect that you get a lot dumps.
>
> You should state somewhere that people should (if they are doing a BIOS
> update anyway):
>    - upload the dumps
>    - upgrade the BIOS
>    - again upload the dumps
> Like that you get a nice history of fixups which can reveal interesting
> things...
>
>       Thomas
>
> PS: This work is very much appreciated. Tell me how I can help.
> --
> 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: DSDT from your system / new DSDT archive

[Scott Thompson]

On Wed, 17 Sep 2008 13:29:37 -0400 Thomas Renninger <trenn@suse.de> 
wrote:
>On Wednesday 17 September 2008 17:44:33 Thomas Renninger wrote:
>> On Wednesday 17 September 2008 04:41:27 Henrique de Moraes
>Holschuh wrote:
Lots about the proposed DSDT respository (and so did others).  
Thank you for your comments and insights.

This effort can only address a partial DSDT solution, and initially 
the primary concern is getting the
correct information up about the tools and methods required to 
extract needed files for a system (and to
then make those files available).  If that information is correct, 
novice users should be able to contribute.

An initial draft with about 25 dsdt is up with request for comment 
at :

http://www.fileandstream.com/proc/acpi/dsdt.htm

In terms of 'help':
1. if there are any volunteers to review a 'sandbox' for any new 
dsdt/acpidumps/etc that 
come in please let me know; 
2. review of extraction information and procedures for a variety of 
systems, including better
information about how to get some of the tools (dmidecode, 
acpidump, etc) for a variety of linux
distros. 

There are several linked pages on usage and ways to gather 
information for contribution
as well on that site;  comments are welcome to me directly rather 
than clogging these lists.

---------------------------------------
Scott Thompson / postfail@hushmail.com
---------------------------------------