Andriy Gapon <[email protected]> wrote: > on 11/07/2011 19:07 Vitaly Magerya said the following: >> Can you elaborate? From my reading, the only place cpu_cx_lowest >> is used is in acpi_cpu_notify, where sc->cpu_cx_lowest is optionally >> increased to min(cpu_cx_lowest, sc->cpu_cx_count - 1), which should >> be safe in any situation. > > This is exactly the place that I am concerned about. > Probably my mind is clouded but I can not understand why > acpi_cpu_set_cx_lowest() > call is under the condition: > if (sc->cpu_cx_lowest < cpu_cx_lowest) > acpi_cpu_set_cx_lowest(sc, min(cpu_cx_lowest, sc->cpu_cx_count - 1)); > > If you or someone else can explain to me why that condition is there...
Now that I think about it, yes it does look like a bug. Here's how to trigger it: 1. Kill devd. 2. Make sure you've got C3, set hw.acpi.cpu.cx_lowest to C3. 3. Plug the power cord in (only C2 is now reported). 4. Look at dev.cpu.N.cx_lowest: it's still C3, even though dev.cpu.N.cx_supported only has C1 and C2. This happens because normally sc->cpu_cx_lowest == cpu_cx_lowest, so the update isn't executed, and sc->cpu_cx_lowest remains as before. In short, that update should probably be executed unconditionally. _______________________________________________ [email protected] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-acpi To unsubscribe, send any mail to "[email protected]"
