Liu, Jiang wrote: > Li, Aubrey <> 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. > > The idea here is to help BIOS/ACPI to become mature and then we could > rely on it. And I feel it would be better to base our > implementation on ACPI instead > of vendor specific information because that would eventually save our > efforts to maintain cpupm driver. >
Sunds reasonable to me, :) Thanks, -Aubrey
