Date: Wed, 30 Nov 2005 10:13:54 -0800 From: Nate Lawson <nate@root.org> To: John Baldwin <jhb@freebsd.org> Cc: freebsd-acpi@freebsd.org, David Kelly <dkelly@hiwaay.net> Subject: Re: Worked in RELENG_5, fails in RELENG_6 Message-ID: <438DEBE2.2010006@root.org> In-Reply-To: <200511301018.24822.jhb@freebsd.org> References: <20051127010724.GA1161@Grumpy.DynDNS.org> <7689ADE7-14BF-42C8-A3BD-B10E514799B3@FreeBSD.org> <438D6CE4.8010907@root.org> <200511301018.24822.jhb@freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
John Baldwin wrote:
> On Wednesday 30 November 2005 04:12 am, Nate Lawson wrote:
>
>>John Baldwin wrote:
>>>Actually, this is the second report I've had that setting hw.physmem
>>>interacts badly with ACPI. The other report I had resulted in a kernel
>>>panic if it was set to 3G.
>>
>>I suspect mapping the memory to read the FACS is failing for the
>>hw.physmem case. His machine probably has tables at 2G (highmem). A
>>common location (other than < 1MB) is top of memory minus 16 MB. I
>>don't know what setting hw.physmem actually does -- does it change how
>>we can map high memory?
>
>
> Well, it can override what the SMAP tells us such that we can extend the last
> SMAP entry:
>
> This would force the memory up to 2g to be included as pages and I think we
> zero out pages to test them before adding them to the VM. Extending Maxmem
> might have forced the pages holding his ACPI tables to be added to the valid
> pages resulting in those pages being overwritten. David, can you use a
> serial console to grab a boot -v output that includes the SMAP output? Also,
> the boot -v output might also provide the PA of FACS (or maybe acpidump -t
> would have that?) which would also be useful.
That sounds like the problem. hw.physmem should still respect the SMAP
restrictions even when overriding the memory size value. The way to
tell the PA for the FACS is just look at the acpidump -t output. Look
at what order the tables appear (FACP, FACS, ...) and then look up the
address in the RSDT Entries list. As shown in his previous debug
output, the 2nd entry in his RSDT is when acpidump -t errors out. That
address is 0xfffc8fd7, and indeed is at top of memory - 200 KB.
/*
RSDT: Length=56, Revision=1, Checksum=215,
OEMID=DELL, OEM Table ID=PE400SC, OEM Revision=0x7,
Creator ID=ASL, Creator Revision=0x61
Entries={ 0x000fd17b, 0xfffc8fd7, 0x000fd1ef, 0x000fd25b,
0x000fd283 }
*/
--
Nate
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?438DEBE2.2010006>