Bill.Holler wrote: > On 09/16/08 16:32, Li, Aubrey wrote: >> Hi Bill, >> >> Bill.Holler wrote: >> >> >>> Hi Aubrey, >>> >>> My test machine has the same problem with the new push. >>> >>> The problem was a miss-merge; sorry it was probably my fault. :-( >>> The promotion code can promote passed the end of the cstate list. >>> >>> The promotion code at the end of cpu_acpi_idle(): >>> if ((cs_type < cpu_max_cstates) && (delta > >>> cstate->promotion)) mcpu->mcpu_idle_type++; >>> >>> cs_type can be decremented allowing mcpu->mcpu_idle_type to >>> overflow. /* * OSPM uses the BM_STS bit to determine the >>> power state to enter >>> * when considering a transition to or from the C2/C3 power >>> state. >>> * if C3 is determined, bus master activity demotes >>> the power state >>> * to C2. >>> */ >>> if ((cs_type >= CPU_ACPI_C3) && cpu_acpi_bm_sts()) >>> cs_type = CPU_ACPI_C2; >>> >>> >>> >>> >> >> It's not a miss-merge, It looks like a promotion bug. >> Thanks to fix it. So, is your system working okay with C4 or the >> second C3? >> > > Yes, my system is working great with the second C3. :-) > > > My initial thoughts on duplicate C-States are: we should keep > duplicate C-States. Does that sound reasonable? > > Is it possible to list the proper C-State for duplicate C-States? > For example can a duplicate C3 be listed as C3 instead of C4? > Will the current_cstate field of cpu_info kstat be able to > distinguish duplicate C-States? > I failed to find the mail. But if I recall correctly, Mark mentioned some boxes with the buggy BIOS could have a few entries are the same. Since we don't know how BIOS implementation the _CST object, I think the current implentation may be more reasonable.
Thanks, -Aubrey
