Date: Wed, 27 Oct 2004 18:40:41 -0700 From: Nate Lawson <nate@root.org> To: Josef Karthauser <joe@FreeBSD.org> Cc: linimon@lonesome.com Subject: Re: ACPI Message-ID: <41804E19.5020604@root.org> In-Reply-To: <20041027213702.GW745@genius.tao.org.uk> 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>
next in thread | previous in thread | raw e-mail | index | archive | help
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<FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,SEP,MTRR,PGE,MCA,CMOV,PA > 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?41804E19.5020604>