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?

Thanks,
-Aubrey
Intel OpenSolaris Team
_______________________________________________
opensolaris-discuss mailing list
[email protected]

Reply via email to