DSDT/AML/Etc Inspiron 5748

Larry Rosenman ler at lerctr.org
Thu Mar 3 02:32:46 UTC 2016


On Wed, Mar 02, 2016 at 08:16:16PM -0600, Larry Rosenman wrote:
> Thanks, David!
> 
> I removed the entries from PS2K for 0x66, and now my mouse works.
> 
> I'll attach what I loaded.
> 
> 
> On Thu, Mar 03, 2016 at 01:47:50AM +0000, Box, David E wrote:
> > Concerning the recompiling of disassembled AML code, do heed any warnings that show up at the top of the output file. In any case , 100% correct disassembly of AML code is not guaranteed and you recompile and override your system at your own risk.
> >  
> > That said, I've attached a "fixed" dsdt.dsl and the accompanying reference file that helped generate it. By "fixed" I mean it will compile without error. I can't speak to the component that you want to change. But this should get you farther along. Be aware that there could be portions that disassembled incorrectly but still produced valid syntax. What follows is a description of the problem and how it was fixed.
> > 
> > There were a couple of issues with your dump. If you do a diff on the attached tables and the originals, you'll see what was changed. In dsdt.dsl there were two issues preventing recompile. First, the external method MDBG was incorrectly identified as an integer. This was fixed using the attached refs.txt file and the command:
> > 
> > 	iasl -da -ve -fe refs.txt dsdt.dat ssdt*.dat
> > 
> > The refs.txt file tells the compiler the correct type (and if applicable argument count) for external objects. The above tables come from the command, acpixtract -a acpidump.txt.
> > 
> > Secondly, the AML was packed with a bunch of 0's between two Devices. I've seen this before. It's likely an artifact of the way the table is generated on your system (e.g. space reserved for a device that doesn't exist on your particular platform?). I removed those dangling zeroes. After that, it could compile without error.
> > 
> > Your ssdt2 table also had what was likely a table generation artifact. If you look at _PSS, there is a package of packages list that contained 29 items, but the BIOS only setup information for the first 13 (0xD) of them and set the package length accordingly. The rest were left hanging off the end causing the error. You can see they had what looks like default values. Removing those dangling packages fixed it.
> > 
> > Hope this helps.
> > 
> > David
> 
> -- 
> Larry Rosenman                     http://www.lerctr.org/~ler
> Phone: +1 214-642-9640                 E-Mail: ler at lerctr.org
> US Mail: 7011 W Parmer Ln, Apt 1115, Austin, TX 78729-6961

I'm now seeing the following:

cryptosoft0: <software crypto> on motherboard
aesni0: <AES-CBC,AES-XTS,AES-GCM,AES-ICM> on motherboard
acpi0: <DELL WN09   > on motherboard
ACPI Error: [^PCI0.GFX0.DSLP] Namespace lookup failure, AE_NOT_FOUND (20150818/psargs-391)
ACPI Error: Method parse/execution failed [\134_SB._INI] (Node 0xfffff80006bef180), AE_NOT_FOUND (20150818/psparse-558)
acpi0: Power Button (fixed)
cpu0: <ACPI CPU> on acpi0
cpu1: <ACPI CPU> on acpi0
cpu2: <ACPI CPU> on acpi0
cpu3: <ACPI CPU> on acpi0


-- 
Larry Rosenman                     http://www.lerctr.org/~ler
Phone: +1 214-642-9640                 E-Mail: ler at lerctr.org
US Mail: 7011 W Parmer Ln, Apt 1115, Austin, TX 78729-6961


More information about the freebsd-acpi mailing list