From owner-freebsd-acpi@FreeBSD.ORG Tue Nov 9 23:07:59 2004 Return-Path: Delivered-To: freebsd-acpi@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 662E016A4CE for ; Tue, 9 Nov 2004 23:07:59 +0000 (GMT) Received: from www.cryptography.com (li-22.members.linode.com [64.5.53.22]) by mx1.FreeBSD.org (Postfix) with ESMTP id 0128743D39 for ; Tue, 9 Nov 2004 23:07:59 +0000 (GMT) (envelope-from nate@root.org) Received: from [10.0.0.34] (adsl-67-119-74-222.dsl.sntc01.pacbell.net [67.119.74.222]) by www.cryptography.com (8.12.8/8.12.8) with ESMTP id iA9N7vFp023495 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 9 Nov 2004 15:07:58 -0800 Message-ID: <41914DCC.8000100@root.org> Date: Tue, 09 Nov 2004 15:07:56 -0800 From: Nate Lawson User-Agent: Mozilla Thunderbird 0.9 (Windows/20041103) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Adam K Kirchhoff References: <41910F00.3070402@voicenet.com> <419113BA.9000806@root.org> <41911D01.1090303@voicenet.com> <4191201A.4080406@root.org> <4191330A.7040707@voicenet.com> <41913F15.9060701@root.org> <419145A7.3000406@voicenet.com> In-Reply-To: <419145A7.3000406@voicenet.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit cc: freebsd-acpi@freebsd.org Subject: Re: Laptop troubles... X-BeenThere: freebsd-acpi@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: ACPI and power management development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Nov 2004 23:07:59 -0000 Adam K Kirchhoff wrote: > Nate Lawson wrote: > >> Adam K Kirchhoff wrote: >> >>>> The -v is just to get more info from right before the hang. Try >>>> doing things like sysctl -a, kldload linux, or whatever to see if >>>> you can isolate what's triggering this. >>>> >>> >>> Woohoo... It's /etc/rc.d/devd: >>> # ./cron start >>> Starting cron. >>> # ./devd start >>> Starting devd. >>> hw.acpi.cpu.cx_lowest: C1 -> C3 >>> hw.acpi.cpu.throttle_state: 8 -> 8 >>> >>> And then, immediately, the lockup. Want me to try adding the >>> BREAK_TO_DEBUGGER option in the kernel and see if I can get a backtrace? >> >> Ok, this is helpful. That's actually /etc/rc.d/power_profile >> switching based on input from devd as to the AC line state. Try >> manually running the sysctls: >> >> sysctl hw.acpi.cpu.cx_lowest=C3 > > This one would appear to be the culprit. When I tried it, it locked up > immediately. I rebooted, tried the throttle_state one, waited a few > minutes, and all was fine. Tried the cx_lowest one, and it locked up > again within a few seconds. > >> sysctl hw.acpi.cpu.throttle_state=8 >> >> ...waiting after each one for a minute to see if there's a hang. >> Getting a backtrace would help, yes. >> > > Unfortunately, that's proving difficult. Even with the "option > BREAK_TO_DEBUGGER" line in the kernel config, ctrl-alt-backspace isn't > dropping me to the debugger. That's fine, try cx_lowest=C2. If that works, a workaround is to set cx_performance_state=C2 and cx_economy_state=C2 in /etc/rc.conf (or something like that, see /etc/defaults/rc.conf for the right variable names). Please send me the output of acpidump -t -d > adam.asl separately as an attachment. I think I will have enough with that to debug why C3 is hanging your system. I'm pretty sure the problem area of the commit is in enabling C3 for systems that don't have bus master control. -- Nate