Aubrey Li wrote: > 2009/1/16 Mark Haywood <Mark.Haywood at sun.com>: > >> And this was the beginning of the problem that we are seeing with Bug 6113. >> Notice that though in these tables the first 9 P-states are identical, the >> _PPC is zero. Gotta love it. >> >> Hi, >> >> An OpenSolaris user reported a problem with SpeedStep support on his laptop. >> His problem was that OpenSolaris was not finding the supported P-states. >> After a few email exchanges, we found that his _PSS table had a strangely >> defined set of P-states (see the attached stbl.dsl). There are 10 P-states >> returned by the _PSS, but the first 9 are duplicates. So, really there are >> only 2 uniquely defined P-states. The current P-state parsing code in >> Solaris doesn't allow for duplicates in the middle of the table (it does >> handle them at the end of the table since we've seen that case before). >> Though I consider this to be a questionable _PSS defintion, I think we can >> support it easy enough by ignoring consecutive duplicates altogether. >> >> I placed a webrev of the fix at: >> >> http://cr.opensolaris.org/~mhaywood/6716347/ >> >> And I welcome any comments. >> >> Thanks! >> Mark >> >> > It looks like 6716347 doesn't exist under your folder. >
Sorry. I wasn't asking for a code review. I was forwarding on a discussion from the middle of last year to point out that we'd run into the issue of non-unique P-states (with ASUS) and that we'd modified the ACPI _PSS parsing code to ignore the duplicates. At that time, they were returning a _PPC value of zero even though the first 9 P-states were duplicates. Now they are returning a _PPC value that points to the last duplicate value. And apparently in their very latest BIOS they got things right and stopped supplying the duplicate entries. > -Aubrey > _______________________________________________ > tesla-dev mailing list > tesla-dev at opensolaris.org > http://mail.opensolaris.org/mailman/listinfo/tesla-dev >
