Li, Aubrey wrote: > Mark Haywood wrote: > > >> Bill Holler wrote: >> >>> Mark Haywood wrote: >>> >>> >>>> Bill Holler wrote: >>>> >>>> >>>> >>>>> Line 325: the comma in the condition clause looks suspicious. >>>>> Should "i < obj->Package.Count, cnt > 0" instead be >>>>> "i < obj->Package.Count && cnt > 0" ? >>>>> >>>>> >>>>> >>>> Egads! Yes it should. Thanks for catching that Bill! >>>> >>>> Mark >>>> >>>> >>>> >>>> >>> The rest looks great! >>> >>> Will _CST entries need similar checking? :-( >>> >>> >> God only knows what the BIOS developers will do to the _CST. According >> to the ACPI spec, "_CST defines ascending C-states characterized by >> lower power and higher entry/exit >> latency." That is similar language as is used when describing >> the _PSS, >> "The list is sorted in >> descending order by typical power dissipation. As a result, the zeroth >> entry describes the highest performance state and the 'nth' entry >> describes the lowest performance state." Technically, >> duplicate entries >> (as long as they are in descending order) only break the spirit of >> the specification. >> >> > The big headache is to let OSPM to fix BIOS bug. This case is not too > bad, > but how about some bugs OSPM can't fix or workaround? > More and more bugs will let OSPM become unreadable. > We may try to contact the motherboard manufacturer to fix their problem, > instead of working these weird issues around. >
You're not going to get any argument from me. I think you probably realize from email conversations I've had with Len in the past, that I'm not happy about coding around issues like this. But as Len pointed out to me, unless we're Windows, the chance of getting this fixed by the manufacturer is almost nil. Apparently, Windows and Linux already work around this bug. > Thanks, > -Aubrey > _______________________________________________ > tesla-dev mailing list > tesla-dev at opensolaris.org > http://mail.opensolaris.org/mailman/listinfo/tesla-dev >
