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. Any suggestions? Thanks, -Aubrey
