From owner-freebsd-stable@FreeBSD.ORG Tue Aug 15 15:58:52 2006 Return-Path: X-Original-To: freebsd-stable@freebsd.org Delivered-To: freebsd-stable@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id A083916A4E6 for ; Tue, 15 Aug 2006 15:58:52 +0000 (UTC) (envelope-from android@oberon.pfi.lt) Received: from oberon.pfi.lt (oberon.pfi.lt [193.219.52.174]) by mx1.FreeBSD.org (Postfix) with ESMTP id CF50443D69 for ; Tue, 15 Aug 2006 15:58:51 +0000 (GMT) (envelope-from android@oberon.pfi.lt) Received: from [10.10.10.1] (82-135-145-2.ip.rygveda.lt [82.135.145.2]) by oberon.pfi.lt (8.13.3/8.13.3) with ESMTP id k7FGE24c054789; Tue, 15 Aug 2006 19:14:03 +0300 (EEST) (envelope-from android@oberon.pfi.lt) Message-ID: <44E1EF32.10205@oberon.pfi.lt> Date: Tue, 15 Aug 2006 18:58:42 +0300 From: "Android Andrew [:]" User-Agent: Thunderbird 1.5.0.5 (X11/20060731) MIME-Version: 1.0 To: Christian Walther References: <44E19FF2.9080709@oberon.pfi.lt> <20060815121355.GP490@bunrab.catwhisker.org> <44E1C044.3000104@oberon.pfi.lt> <14989d6e0608150604y1ddabadr9d7e297851e92557@mail.gmail.com> In-Reply-To: <14989d6e0608150604y1ddabadr9d7e297851e92557@mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-stable@freebsd.org Subject: Re: FreeBSD 6.1-STABLE: Unexplained power off X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Aug 2006 15:58:52 -0000 As I mentioned in previous post, I recompiled my kernel without ACPI/APM, with debug option. I've updated BIOS and tested the system. Successful. I mean successful crash. Christian Walther wrote: > This is just a wild, uneducated guess, because I'm not a long FreeBSD > user, but from my point of view this error could really be related to > ACPI/APM, as already has been suggested. > Maybe the machine is trying to go to suspend, but fails while doing > so, which in the end would mean that it can't recover from the > suspend, but has to reboot completely, resulting in dirty file > systems. It wouldn't reach the suspend state correctly, which could > leave everything depending on ACPI/APM in a undefined state, including > the hardware. This would explain why the machine has to be turned off > properly by pressing toe power button for such a long time. > > I'd try to use the machine without ACPI/APM enabled. If possible, > compile a new kernel without it being enabled. This might not be > possible because you're on a SMP-system, thou, but you might want to > check your configuration files for suspend or hibernation -- and turn > them of. > With ACPI/APM turned on, leave the machine idle for some time and see > if it shows the same behaviour. When it shuts down cleanly it's likely > that suspend/hibernation fails due to the high load introduced by the > build process. > > I've seen and experienced similar problems on other platforms, such as > OS X and (sorry) Linux. >