Date: Tue, 11 Mar 2003 13:23:07 -0800 From: "Kevin Oberman" <oberman@es.net> To: Wilko Bulte <wkb@freebie.xs4all.nl> Cc: taxman <taxman@acd.net>, Bjoern Fischer <bfischer@Techfak.Uni-Bielefeld.DE>, freebsd-stable@FreeBSD.ORG Subject: Re: MFC of ACPI code possible? Message-ID: <20030311212307.933C75D07@ptavv.es.net> In-Reply-To: Your message of "Tue, 11 Mar 2003 08:20:38 %2B0100." <20030311082038.A8547@freebie.xs4all.nl>
next in thread | previous in thread | raw e-mail | index | archive | help
> Date: Tue, 11 Mar 2003 08:20:38 +0100 > From: Wilko Bulte <wkb@freebie.xs4all.nl> > Sender: owner-freebsd-stable@FreeBSD.ORG > > On Mon, Mar 10, 2003 at 10:58:37PM -0500, taxman wrote: > > On Monday 10 March 2003 08:25 pm, Bjoern Fischer wrote: > > > Hello, > > > > > > I need a server running -STABLE to be powered down by 'halt -p'. > > > Unfortunately the Hardware only supports ACPI and no APM. Is it > > > possible to MFC the ACPI code (it's from Intel, partially?)? > > > Running -CURRENT ist not an option for me at this time. > > > > well if you folow the -current mailing list you'll see lots and lots of > > problems and discussions with acpi on -current, so I'd say it's not really > > ready for MFC'ing. That's just based on subjective counts of the mails going > > by, but somebody else may have more useful information. > > lots of discussions on it also means it is improving, so i guess be patient, > > If you search the mailing list archives you will find a post by jhb@ > with a pointer to a patchset for -stable. That was causing grief as well. > ACPI is a can of worms, nasty worms I might add. To summarize, ACPI is a real problem because FreeBSD (and everyone except Windows) uses the Intel tools for processing the tables in BIOS that describe the various ACPI functions on a given box. The Intel tools look to be well written doing lots of validity checking on the tables to make sure that there are no hanging paths in the tree. Windows, not too surprisingly, uses tools developed in-house by Microsoft. These appear to be far less rigorous and are all that laptop and BIOS designers are worried about. If it builds and runs Windows, it is, by fiat, correct. We don't have access to those tools. A great many systems contain tables that simply won't work correctly with the Intel tools. These can be fixed, preferably by the manufacturer. But most manufacturers really don't care about anything but windows, so it is up to other to figure out what is wrong and to generate corrections. This has been done for many laptops, but nowhere near to all of them. Also, it is clear that many bugs remaining the open ACPI code base. This should not be surprising because it's very complex. This will improve fairly rapidly. Some vendors will fix their implementations in BIOS and things will get better. But, until open-source gets popular enough that manufacturers care, it will be a long time before ACPI is as functional as it needs to be. In the meantime, you are probably well advised to get mobos and laptops that support APM. And, if you are stuck with an ACPI-only unit, learn a lot about ACPI and the ACPI toolkit (in ports) so that you can help debug it. Join the ACPI mailing list. This is not all that optimistic, but I think it's realistic. (Others may strongly disagree, though.) IF some knowing more about ACPI wants to correct my understanding, I'd be quite pleased. I am not an ACPI expert, although I'm learning a lot about it. I really think we need a FAQ for ACPI and I suspect it's in progress. But that would be a CURRENT issue. R. Kevin Oberman, Network Engineer Energy Sciences Network (ESnet) Ernest O. Lawrence Berkeley National Laboratory (Berkeley Lab) E-mail: oberman@es.net Phone: +1 510 486-8634 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-stable" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20030311212307.933C75D07>