From owner-freebsd-current@FreeBSD.ORG Fri Dec 12 10:59:11 2003 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 440DC16A4CE for ; Fri, 12 Dec 2003 10:59:11 -0800 (PST) Received: from gvr.gvr.org (gvr.gvr.org [212.61.40.17]) by mx1.FreeBSD.org (Postfix) with ESMTP id CB91343D36 for ; Fri, 12 Dec 2003 10:59:08 -0800 (PST) (envelope-from guido@gvr.org) Received: by gvr.gvr.org (Postfix, from userid 657) id 380F95E; Fri, 12 Dec 2003 19:59:07 +0100 (CET) Date: Fri, 12 Dec 2003 19:59:07 +0100 From: Guido van Rooij To: Nate Lawson Message-ID: <20031212185907.GA61783@gvr.gvr.org> References: <20031209114400.G43006@root.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20031209114400.G43006@root.org> cc: "Sergey A. Osokin" cc: current@freebsd.org Subject: Re: ACPI problem X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Dec 2003 18:59:11 -0000 On Tue, Dec 09, 2003 at 11:58:30AM -0800, Nate Lawson wrote: > Suspend/resume will continue to be a problem area for some time. Perhaps > I should put up a FAQ about this. > > 1. Try different states (S1-S4) and see if one of them works. I have a system where S3 leads to an immediate reboot. S4 leads to a hang. S2 is not available. S1 leads to a nice suspend, except that the LCD is not powered off. Resume works okay. When I push the lid button when in the boot loader, the LCD is powered off. In Windows everything works like expected. This is a Dell D600. S4 is handled by Windows itsself. Does this mean the BIOS doesn't support doing it itself? What I'd like to know is how I can debug this. I am willing to read the ACPI spec, but only if that will lead to something. > > 2. Try tunable/sysctl hw.acpi.reset_video=0 > > 3. Try tunable/sysctl hw.syscons.sc_no_suspend_vtswitch=1 > > 4. Try sysctl hw.acpi.sleep_delay=0 (I take it these are all for systems where resume doesnt work properly?) > > 5. Try the most recent Linux beta kernel with acpi configured. If it > works, then perhaps we can find why. Since we share the ACPI-CA > interpreter with Linux, it's likely that they have similar problems. ENOOPTION for the moment. > > 6. Try disabling drivers that may break resume. In particular, uhci > doesn't work right after resume. > > 7. Try building the acpi kernel module with options ACPI_DEBUG, then > setting debug.acpi.layer and debug.acpi.level sysctls to various levels of > verbosity right before suspending/resuming. Use a serial console to log > the output. Here are some proposed settings: > > debug.acpi.layer="ACPI_ALL_DRIVERS ACPI_ALL_COMPONENTS" > debug.acpi.level="ACPI_LV_IO" This gives an insane amount of output during normal operation and almost none when suspending and resuming. Perhaps I can limit it to events and actions related with turning off the LCD screen, but looking at the code it isn't immeditaly obvious on how I should do that. -Guido