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: [email protected] > 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: [email protected] US Mail: 7011 W Parmer Ln, Apt 1115, Austin, TX 78729-6961 _______________________________________________ [email protected] mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-acpi To unsubscribe, send any mail to "[email protected]"
