Hi, Li, Aubrey píše v út 13. 07. 2010 v 09:28 +0800: > John Martin wrote: > > > > On 07/11/10 09:15 PM, Li, Aubrey wrote: > > > > >> acpidump should be enough here, shouldn't it? And that is in > > >> pkg://diagnostic/acpidump > > > > > > This is quite possible a BIOS bug. P-state has the corrupted coordination > > type(4). > > > Currently ACPI defines 0xFC(SW_ALL), 0xFD(SW_ANY) and 0xFE(HW_ALL), > > > "4" is unknown as reported. > > > > > > Yes, ACPIDUMP should be enough to dump the table out. Please send it > > > out for diagnosis. > > > > Attached is the human readable DSL for SDDT3.dat. > > Unfortunately, _PSD object is dynamically loaded. So it's not in SSDT table. > Need another data file. > > # acpidump --addr 0xBF7F8918 --length 0x41D > cpu0_ist.dat > #acpidump --addr 0xBF7F7A98 --length 0x303 > ap_ist.dat > > Note, acpidump disabled "--addr" option when it went through the PSARC. > You need to download it from opencsw or blastwave if it's still available > there. >
What's wrong with: acpidump -a 0xBF7F7A98 -l 0x303 > ap_ist.dat ? I see only long-params dropped, not functionality. Best regards, Milan _______________________________________________ pm-discuss mailing list [email protected] http://mail.opensolaris.org/mailman/listinfo/pm-discuss
