Date: Thu, 29 Jan 2004 08:04:12 -0600 (CST) From: James Van Artsdalen <james-freebsd-amd64@jrv.org> To: tomh@waterloo.equitrac.com Cc: freebsd-amd64@freebsd.org Subject: Re: New AMD64 owner Message-ID: <200401291404.i0TE4Co1010294@bigtex.jrv.org> In-Reply-To: <B1D77424948FD611A3B80000C0109EEF0225A07A@SYNCRO> (tomh@waterloo.equitrac.com) References: <B1D77424948FD611A3B80000C0109EEF0225A07A@SYNCRO>
next in thread | previous in thread | raw e-mail | index | archive | help
> From: "Haapanen, Tom" <tomh@waterloo.equitrac.com> > Date: Thu, 29 Jan 2004 08:45:11 -0500 > > Is there any real downside in turning off ACPI? Especially for a server > that will be running 24x7? If it seems to work then turning off ACPI has no important downside. "Seems to work" means that you can access a disk drive or talk over a network: I don't expect any subtle failure modes. My familiarity with this is from the BIOS side, and about five years old, but I think FreeBSD can get all of the data it needs to configure the IRQ/IOAPIC from the MP tables. ACPI probably isn't required. The bigger question is whether the MP table data is reliable. I believe Windows uses ACPI exclusively if available, so once BIOS vendor X has ACPI everything else becomes untested and unreliable. (vendors generally don't test anything the current version of Windows doesn't use, so ACPI in FreeBSD is preferred even if theoretically unnecessary). I see no reason not to deploy a FreeBSD/AMD64 server right now, after the hardware is burned in, and if all of the apps run 64-bit.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200401291404.i0TE4Co1010294>