Date: Tue, 11 Mar 2003 22:28:24 +0100 From: Wilko Bulte <wkb@freebie.xs4all.nl> To: Kevin Oberman <oberman@es.net> 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: <20030311222824.D9977@freebie.xs4all.nl> In-Reply-To: <20030311212307.933C75D07@ptavv.es.net>; from oberman@es.net on Tue, Mar 11, 2003 at 01:23:07PM -0800 References: <20030311082038.A8547@freebie.xs4all.nl> <20030311212307.933C75D07@ptavv.es.net>
index | next in thread | previous in thread | raw e-mail
On Tue, Mar 11, 2003 at 01:23:07PM -0800, Kevin Oberman wrote: > > 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. For most people it would be fine if it worked, even if it was a shitty implementation inside. In other words: if it runs Windows, it should run FreeBSD, Linux, whatever opensource OS. Would being less rigorous help? I really lack the knowledge to know. For sure it would upset a great many people to morphe ACPI-support into an uncool ugly hack. :-/ > 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. Right.. > 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 Which are rapidly getting out of fashion, as ACPI-only stuff seems to grow in popularity :( > 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 am afraid this is the only way forward. Wilko -- | / o / /_ _ wilko@FreeBSD.org |/|/ / / /( (_) Bulte To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-stable" in the body of the messagehome | help
Want to link to this message? Use this
URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20030311222824.D9977>