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: l...@lerctr.org
US Mail: 7011 W Parmer Ln, Apt 1115, Austin, TX 78729-6961

Attachment: dsdt.aml
Description: Binary data

_______________________________________________
freebsd-acpi@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-acpi
To unsubscribe, send any mail to "freebsd-acpi-unsubscr...@freebsd.org"

Reply via email to