Aubrey Li wrote:
> On Wed, Mar 5, 2008 at 2:59 AM, Mark Haywood <[EMAIL PROTECTED]> wrote:
>> Aubrey Li wrote:
>> > On Tue, Mar 4, 2008 at 9:03 PM, Luke Deller <[EMAIL PROTECTED]> wrote:
>> >> Solaris nv83a is reporting similar errors on my Gigabyte GA-X38-DQ6
>> >> motherboard using a quad-core Q6600 CPU. The following two lines are
>> >> repeated for CPU instance 1, 2 and 3:
>> >>
>> >> Mar 4 23:19:06 behemoth cpudrv: [ID 805513 kern.info] NOTICE: cpu_acpi:
>> >> _PSS package not found.
>> >> Mar 4 23:19:06 behemoth cpudrv: [ID 978953 kern.warning] WARNING:
>> >> cpu_acpi: error parsing _PSS for CPU instance 3
>> >>
>> >> I have attached a tarball containing the 3 .dsl files produced by
>> >> "iasl -g". To my untrained eyes it looks like my problem is slightly
>> >> different from those discussed already on this thread. Any advice on
>> >> getting SpeedStep working would be greatly appreciated.
>> >>
>> >
>> > Yeah, quite different. You should have _PSS on your machine.
>> > Give me the output of the attached command, please
>> > #./acpinamespacedump > log.txt
>>
>> Actually, I think it is the same problem. I think that by default the
>> _PSS for CPU0 is being exported. However, it looks to me like the _PSS
>> objects for the other three CPUs require _PDC to have 0xA enabled. for
>> example the _PDC for _PR.CPU1 is defined:
>>
>> Method (_PDC, 1, NotSerialized)
>> {
>> CreateDWordField (Arg0, 0x08, CAP1)
>> Store (CAP1, PDC1)
>> If (LEqual (TLD1, 0x00))
>> {
>> If (LEqual (And (PDC1, 0x0A), 0x0A))
>> {
>> If (And (CFGD, 0x02))
>> {
>> OperationRegion (IST1, SystemMemory, DerefOf (Index
>> (SSDT, 0x04)), DerefOf (Index (SSDT, 0x05
>> )))
>> Load (IST1, HI1)
>> }
>>
>> Store (0x01, TLD1)
>> }
>> }
>> }
>>
>> I believe that the _PSS will get loaded if PDC1 has bits 0x0A enabled.
>>
>> I already sent Luke a copy of the CPU driver with this patched to try out.
>>
>
> Yeah, you are right. I didn't notice it's just for CPU1/2/3.
> --------
>> The following two lines are repeated for CPU instance 1, 2 and 3
> --------
> I thought it doesn't work on all CPUs.
>
> So Luke - you can try Mark's driver, or you can modify the acpi table
> and rebuild.
>
> Mark - when will this issue be fixed in nevada release?
Now that we've had someone verify the fix, it will likely integrate into
either onnv_85 or onnv_86.
_______________________________________________
opensolaris-discuss mailing list
[email protected]
