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.
- 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 >
