Date: Wed, 08 Feb 2006 00:09:52 +0100 From: =?ISO-8859-2?Q?Przemys=B3aw_Celej?= <p-celej@o2.pl> To: freebsd-acpi@freebsd.org Subject: Re: Kernel panic with ACPI enabled Message-ID: <43E928C0.5050104@o2.pl> In-Reply-To: <200602071552.33235.jhb@freebsd.org> References: <43E7D1A2.1030008@o2.pl> <200602071404.44314.jhb@freebsd.org> <200602071413.07109.duncan.fbsd@gmail.com> <200602071552.33235.jhb@freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
John Baldwin wrote: > On Tuesday 07 February 2006 15:13, Donald J. O'Neill wrote: > > Actually, in his case I'm fairly sure MAXMEM is the problem. Several people > have had problems trying to use the tunable equivalent (hw.physmem=3g and the > like) because if the new maxmem value is greater than the highest memory > address we found, we just extend the last segment of physical memory. > However, in the case of modern machines with SMAPs, this extension can result > in including memory that was specifically marked as unavailable (because it > was in use by the BIOS to store the ACPI tables) suddenly being used by the > kernel. As part of this process, the kernel does test writes to each page, > so it would corrupt the ACPI tables and eventually lead to issues such as > this. > > Exactly ! I removed MAXMEM option, and: NO_MEMORY_HOLE , CPU_UPGRADE_HW_CACHE, CPU_FASTER_5X86_FPU, CPU_SUSP_HLT, CPU_ATHLON_SSE_HACK. And ACPI now works perfectly. Huge thanks. -- Pozdrawiam Przemysław Celej
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?43E928C0.5050104>