Date: Wed, 08 Feb 2006 11:12:19 -0800 From: Nate Lawson <nate@root.org> To: John Baldwin <jhb@freebsd.org> Cc: Peter Jeremy <peterjeremy@optushome.com.au>, freebsd-acpi@freebsd.org Subject: Re: Kernel panic with ACPI enabled Message-ID: <43EA4293.4030508@root.org> In-Reply-To: <200602081036.09619.jhb@freebsd.org> References: <43E7D1A2.1030008@o2.pl> <43E9A4CA.9090701@root.org> <20060208093332.GA702@turion.vk2pj.dyndns.org> <200602081036.09619.jhb@freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
John Baldwin wrote: > On Wednesday 08 February 2006 04:33, Peter Jeremy wrote: > >>On Tue, 2006-Feb-07 23:59:06 -0800, Nate Lawson wrote: >> >>>John Baldwin 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 >>> >>>Can we at least put a printf() in the boot sequence that says "warning: >>>maxmem set and acpi enabled, this may cause problems"? This keeps >>>coming up. >> >>Presumably this isn't a problem where hw.physmem is used to artifically >>reduce the system for testing. > > > It depends on the value you use. Some values will be ok, some will break > things. The code that handles maxmem and physmem really needs to be > SMAP-aware and not use memory that we know isn't really memory. Yes, but I'd prefer the printf for now until SMAP support can be added. -- Nate
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?43EA4293.4030508>