Kernel panic with ACPI enabled

[Nate Lawson]

John Baldwin wrote:
> On Wednesday 08 February 2006 02:59, Nate Lawson wrote:
> 
>>John Baldwin wrote:
>>
>>>On Tuesday 07 February 2006 15:13, Donald J. O'Neill wrote:
>>>
>>>>Other things can affect what he's trying to do and cause him to think he
>>>>has an ACPI problem. I had a bad USB mouse that was causing problems on
>>>>one of my computers, in fact anything USB on that computer caused a
>>>>problem with ACPI (it had to be disabled to allow the computer to
>>>>boot-up) if that mouse was plugged in, until I found the mouse was bad
>>>>and switched it with one that was ok. On another computer, I could only
>>>>boot-up if I either disabled ACPI or had the USB mouse unplugged. After
>>>>it was up, the mouse could be plugged back in and it would work, ACPI
>>>>would work, but I would be left wondering about the situation. I
>>>>finally decided to just use a PS-2 mouse and wait a while. That works
>>>>fine, although I hate ball mice.
>>>
>>>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.
>>
>>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.
> 
> 
> We don't know we are using ACPI when we do the maxmem and hw.physmem stuff.

I was thinking this goes in the ACPI init.  if (maxmem != 0) printf()

-- 
Nate