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? Regards, Bill > Thanks, > -Aubrey > _______________________________________________ > tesla-dev mailing list > tesla-dev at opensolaris.org > http://mail.opensolaris.org/mailman/listinfo/tesla-dev >
