Andrei Dorofeev wrote: > A simple check that CPU IDs that are members of > the same P-state domain should always belong to > the same socket/package would be enough here to > catch this problem early at boot and maybe throw > a warning that suggests getting BIOS updated. >
We can do this kind of checking, but we should be aware that this is not true on the all platforms. Thanks, -Aubrey > - Andrei > > On Mon, Mar 30, 2009 at 6:21 PM, Li, Aubrey > <aubrey.li at intel.com> wrote: >> tesla-dev-bounces at opensolaris.org wrote: >> >>> Mark Haywood <> wrote: >>>> Mark Haywood wrote: >>>>> Li, Aubrey wrote: >>>>>> Hi Andrei, >>>>>> >>>>>> Andrei Dorofeev wrote: >>>>>> >>>>>> >>>>>>> Aubrey, >>>>>>> >>>>>>> What version of the X8DTN BIOS are you using? ?I have filed >>>>>>> this issue back in February on premier.intel.com and it >>>>>>> should've been resolved by now. ? Do you see this with BIOS >>>>>>> version 3059W? >>>>>>> >>>>>> >>>>>> Right, right, the version is 3059W! And this is the newest >>>>>> version. From the BIOS changelog, they tested windows, redhat >>>>>> linux, I'm not sure if they care about what solaris reported, :( >>>>>> >>>>>> >>>>>>> Don't give up on using _PSD because of this. >>>>>>> >>>>>> >>>>>> I believe before NHM, _PSD is seldom implemented. Using the >>>>>> vendor specific CPU topology should be an acceptable way to >>>>>> build domain info. I admit I don't have the knowledge about the >>>>>> other CPU vendor, like SPARC and AMD, what's the benefit of >>>>>> using _PSD? Othering than introducing panic, ;) >>>>>> >>>>> >>>>> That's a very good question. What is the benefit of the _PSD? I >>>>> believe the _PSD was introduced to prevent Solaris and other >>>>> operating systems from having to do exactly what you are proposing >>>>> (i.e., introducing vendor specific details of processor state >>>>> domains into the operating system). The _PSD is supposed to >>>>> define a standard way for operating systems to digest the domain >>>>> data. Unless there is a really compelling reason to ignore the >>>>> _PSD, I would suggest that we continue to use it. >>>> >>>> How about a compromise. Since the _PSD often doesn't exist, we have >>>> to be able to determine the domains from the topology. Since we >>>> have to do this anyway, why don't we digest the _PSD and verify it >>>> afterwards using the topology. Why do this? So that we can report >>>> bad _PSDs to the BIOS developers so that the _PSDs become more >>>> reliable in the future. If a faulty _PSD is identified we can log a >>>> message to the console and use domains built from the topology. At >>>> some point it would be nice if we didn't have to continue >>>> determining the domains using topology. Sound reasonable? >>> That sounds a good suggestion. In early stage, we may need to reveal >>> bugs in BIOS implementation and push BIOS to behave correctly. >>> Eventually BIOS should be robust enough so we could switch to BIOS. >>> If we give up _PSD, it seems we are on the opposite side of >>> ACPI spect then. >>> >> >> BIOS is not ACPI, hehe. If we use topology to check, why not use it >> at all? why we need to verify BIOS bug? ?Anyway, the suggestion >> works to me. >> >> Thanks, >> -Aubrey >> _______________________________________________ >> tesla-dev mailing list >> tesla-dev at opensolaris.org >> http://mail.opensolaris.org/mailman/listinfo/tesla-dev
