From owner-freebsd-acpi@FreeBSD.ORG Thu Oct 28 01:43:27 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 BBA7316A4CE; Thu, 28 Oct 2004 01:43:27 +0000 (GMT) Received: from www.cryptography.com (li-22.members.linode.com [64.5.53.22]) by mx1.FreeBSD.org (Postfix) with ESMTP id 66DAE43D39; Thu, 28 Oct 2004 01:43:27 +0000 (GMT) (envelope-from nate@root.org) Received: from [10.0.5.50] (adsl-64-171-186-136.dsl.snfc21.pacbell.net [64.171.186.136]) by www.cryptography.com (8.12.8/8.12.8) with ESMTP id i9S1hFFp030679 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 27 Oct 2004 18:43:16 -0700 Message-ID: <41804E19.5020604@root.org> Date: Wed, 27 Oct 2004 18:40:41 -0700 From: Nate Lawson User-Agent: Mozilla Thunderbird 0.7.3 (Windows/20040803) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Josef Karthauser References: <20041026.040536.126914630.imp@bsdimp.com> <20041026163137.GC1445@genius.tao.org.uk> <20041026163249.GD1445@genius.tao.org.uk> <20041026.174644.82225205.imp@bsdimp.com> <417EEEFA.4040007@root.org> <20041027213702.GW745@genius.tao.org.uk> In-Reply-To: <20041027213702.GW745@genius.tao.org.uk> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit cc: acpi@FreeBSD.org cc: linimon@lonesome.com Subject: Re: ACPI 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: Thu, 28 Oct 2004 01:43:28 -0000 Josef Karthauser wrote: > [Moved to the ACPI list] > > On Tue, Oct 26, 2004 at 05:42:34PM -0700, Nate Lawson wrote: > >>M. Warner Losh wrote: >> >>>: BTW, what's the status with ACPI at the moment? It is only me who finds >>>: it very broken at the moment? I don't even get 'shutdown -p' working >>>: any more. Should I make a bug report or it is known about? >>> >>>More info likely is needed. ACPI works for me for shutdown -p on my >>>machines. >> >>There's only one known issue with shutdown that shouldn't trigger a >>panic. If the shutdown process runs on a secondary processor (AP), some >>chipsets don't honor the write and so the shutdown attempt fails (and >>you get the normal "hit any key to reboot" message). The fix is to run >>our shutdown code on the main (BSP) processor only. Peter suggested >>changing boot() to do sched_pin(curthread, 0) (or whatever the right API >>is). This would need a lot of testing and someone with thread awareness >>to be sure this doesn't screw up panics, scheduler is alive that late in >>runtime, etc. >> > > > Ok, this is a strange one. I've got a Dell Inspiron 5000e. Recently > something happened to ACPI and now 'shutdown -p' doesn't switch the > power off anymore. > > Looking at dmesg I see: > > > Copyright (c) 1992-2004 The FreeBSD Project. > Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 > The Regents of the University of California. All rights > reserved. > FreeBSD 6.0-CURRENT #160: Mon Oct 18 08:20:15 BST 2004 > joe@genius.tao.org.uk:/stable/usr/obj/current/usr/src/sys/GENIUS > link_elf: symbol db_readline undefined > -> KLD file acpi.ko - could not finalize loading > Timecounter "i8254" frequency 1193182 Hz quality 0 > CPU: Intel Pentium III (696.97-MHz 686-class CPU) > Origin = "GenuineIntel" Id = 0x686 Stepping = 6 > Features=0x383f9ff T,PSE36,MMX,FXSR,SSE> > > Is is that acpi isn't loading properly? I don't quite understand what the KDB problem is and why db_readline is not defined. I'm guessing the module was compiled with options DDB and the kernel not. If so, just recompile both with the same options. Once you have acpi again, poweroff should work. > What is very strange is that for the first time suspend/resume appears > to be working. The first time I shut the lid the machine stays on and > just the screen powers down, but the second time (and subsequent times) > the machine completely suspends including the fans and harddrive. > > Is it the bios that is doing this? It's never worked before - I'd say > that you guys have fixed ACPI and that's why it is working, but why does > -p not work then? Given the vintage of the above machine, most of the suspend/resume is implemented in SMM code. This means that suspend/resume should work with APM or sometimes with nothing loaded. My T23 (ca. 2002) suspends/resumes without acpi or apm. It also works with acpi but differently. I recommend just using apm. On older machines, it should be sufficient. -- Nate