Milan.Jurik wrote: > > 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.
As I said, "-addr" option is removed when acpidump went through the PSARC. The usage message is probably not removed as well. So you'll get nothing if you are using acpidump from ips repo. The working one should be available from opencsw or blastwave. Thanks, -Aubrey > > Best regards, > > Milan _______________________________________________ pm-discuss mailing list [email protected] http://mail.opensolaris.org/mailman/listinfo/pm-discuss
