power savings and usb
len.brown at intel.com
Thu May 6 10:43:55 PDT 2004
On Thu, 2004-05-06 at 12:37, Mike Silbersack wrote:
> On Thu, 6 May 2004, Nate Lawson wrote:
> > > Gah, except that my experiment in clockswitching made the usb stack mad,
> > > so it's constantly priniting "usb0: X scheduling overruns", where X
> > > appears to be a number containing one or two bits of entropy per second.
> > > I will have to go visit ohci.c with a cluebat when I get a chance.
> > >
> > > Er, it stopped when I plugged in the power cord, and starts again when I
> > > unplugged it. Is it possible that ohci.c is reading some USB voltage
> > > value instead of the overrun bit that it thinks it is reading?
> > hw.acpi.cpu.cx_supported: C1/0 C2/84 C3/120
> > hw.acpi.cpu.cx_lowest: 1
> > hw.acpi.cpu.cx_history: 9175/0 173443/9175 0/0
> > This means I am requesting a lowest sleep of C2 (idx 1 of the options
> > supported). The history values show that I haven't used C3 at all and am
> > using C2 at a rate of about 95%.
> > ohci may have problems with C3. On my uhci, it demotes to C2 without
> > causing problems. You can override this by setting in /etc/rc.conf:
> > economy_cx_lowest="1"
> > -Nate
> Something else must be happening, because:
> hw.acpi.cpu.cx_supported: C1/1 C2/99 C3/288
> hw.acpi.cpu.cx_lowest: 0
> hw.acpi.cpu.cx_history: 5558639/0 0/0 0/0
> But, since I went and killed the scheduling overrun interrupts at the
> source, we don't need to worry anymore. :)
I expect that C2/99 means the FADT lists C2 latency as 99usec.
Similarly for 288 usec C3 latency.
This compares to the ACPI spec limits of 100 and 1000, respectively.
This is relativly high latency, and the OS may decided that it isn't
worth paying it.
More information about the freebsd-acpi