From owner-acpi-jp@jp.FreeBSD.org Tue Jan  6 03:24:10 2004
Received: (from daemon@localhost)
	by castle.jp.FreeBSD.org (8.11.6p2+3.4W/8.11.3) id i05IOAE26380;
	Tue, 6 Jan 2004 03:24:10 +0900 (JST)
	(envelope-from owner-acpi-jp@jp.FreeBSD.org)
Received: from root.org (root.org [67.118.192.226])
	by castle.jp.FreeBSD.org (8.11.6p2+3.4W/8.11.3) with SMTP/inet id i05IO7C26360
	for <acpi-jp@jp.FreeBSD.org>; Tue, 6 Jan 2004 03:24:07 +0900 (JST)
	(envelope-from nate@root.org)
Received: (qmail 22564 invoked by uid 1000); 5 Jan 2004 17:22:27 -0000
From: Nate Lawson <nate@root.org>
To: Philip Paeps <philip+freebsd@paeps.cx>
cc: acpi-jp@jp.FreeBSD.org
In-Reply-To: <20040105075922.GA657@hermes.nixsys.be>
Message-ID: <20040105092056.Q22517@root.org>
References: <20040105075922.GA657@hermes.nixsys.be>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Reply-To: acpi-jp@jp.FreeBSD.org
Precedence: list
Date: Mon, 5 Jan 2004 09:22:27 -0800
X-Sequence: acpi-jp 2972
Subject: [acpi-jp 2972] Re: Constant 'usb scheduling overruns'?
Sender: owner-acpi-jp@jp.FreeBSD.org
X-Originator: nate@root.org
X-Distribute: distribute version 2.1 (Alpha) patchlevel 24e+031216

On Mon, 5 Jan 2004, Philip Paeps wrote:
> I just built a new -CURRENT world/kernel on my laptop for the first time in
> two weeks, and I'm being flooded (a few per second, not timed exactly) with
> messages like:
>
>   Jan  5 08:49:29 hermes kernel: usb0: 1 scheduling overruns
>   Jan  5 08:49:29 hermes kernel: usb1: 1 scheduling overruns
>   Jan  5 08:49:29 hermes kernel: usb2: 1 scheduling overruns
>
> Could these possibly be ACPI-related?  I only get these messages when I'm
> running on battery power.  As soon as I plug AC in, the flood stops.  Also,
> I've always had 'scheduling overruns' when putting my laptop to sleep (I
> posted to the list about that a few months ago iirc), which makes me think in
> the same direction.
>
> Any idea how I could go about debugging (and preferably fixing :-)) this, or
> what information I could provide to allow a more talented hacker to fix it?

Try setting hw.acpi.cpu.cx_lowest to 0 after switching to battery power.
The new /etc/power_profile script tries to set the lowest possible
cx_lowest while on battery power.  You can override this by setting this
in /etc/rc.conf:

economy_cx_lowest="0"

See /etc/defaults/rc.conf for more info on how to configure power_profile.

-Nate
