Li, Aubrey 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. >> >> >> > > I'm thinking how to work around the problem, we can disable the p-state in > the BIOS, or do some change in kmdb, but it seems we can't keep p-state > in the os, unless we ignore _PSD. >
Honestly, I prefer forcing p-states to be disabled in the BIOS so that the BIOS developers are given incentive to get it right. However, as I just mentioned I think we have a compromise solution. Mark > Any suggestions? > > Thanks, > -Aubrey >
