Date: Thu, 1 Dec 2005 12:08:05 -0500 From: John Baldwin <jhb@freebsd.org> To: Nate Lawson <nate@root.org> Cc: David Kelly <dkelly@hiwaay.net>, freebsd-acpi@freebsd.org Subject: Re: Worked in RELENG_5, fails in RELENG_6 Message-ID: <200512011208.06633.jhb@freebsd.org> In-Reply-To: <438E7F53.1040001@root.org> References: <20051127010724.GA1161@Grumpy.DynDNS.org> <8DCC8546-767A-42A4-9A80-A950E1FFEF89@hiwaay.net> <438E7F53.1040001@root.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Wednesday 30 November 2005 11:42 pm, Nate Lawson wrote: > David Kelly wrote: > > On Nov 30, 2005, at 9:18 AM, John Baldwin wrote: > >> 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. > > > > Serial console boot -v with working ACPI, attempted to edit ^H's out: > > http://home.hiwaay.net/~dkelly/opus_serialconsole.log > > > > I don't grep SMAP in acpidump output but there was plenty in boot -v > > above: > > > > acpidump -t -d: > > http://home.hiwaay.net/~dkelly/opus_acpidump-t-d.txt > > > > acpidump -t: > > http://home.hiwaay.net/~dkelly/opus_acpidump-t.txt > > > > acpidump -d: > > http://home.hiwaay.net/~dkelly/opus_acpidump-d.txt > > > > And ultimately this is what started it all. Re-enabled hw.physmem and > > captured the boot -v panic via serial console and didn't bother to edit > > the ^H's: > > http://home.hiwaay.net/~dkelly/opus-panic.log > > Even with the user setting hw.physmem, we should only be mapping type 1 > memory values: > > SMAP type=01 base=0000000000000000 len=00000000000a0000 > SMAP type=02 base=00000000000f0000 len=0000000000010000 > SMAP type=01 base=0000000000100000 len=000000007fe74000 > > As you can see, the last part up to 2 GB (> 0x7fe74000) should not be > mapped (and later zeroed). So it seems this bug is apparent. Can you > fix it John? No, not easily. The problem is that we only keep one smap entry around at a time and don't save the whole table. For the most part people shouldn't be using hw.physmem with ACPI anyways except to shrink the memory down for testing, so I'm almost inclined to say "don't use it". Ideally hw.physmem would only extend the end of physical memory to cover chunks not reserved by a type of !1 (IOW, either type = 1 regions or outright holes in the map), but without full access to the SMAP table that's not that easy to do. I think folks should just stop setting hw.physmem, it mostly exists as workaround for when we don't get the memory size right from the BIOS, and folks shouldn't use it if we get the size right without it unless they want to blow their feet off. :) -- John Baldwin <jhb@FreeBSD.org> <>< http://www.FreeBSD.org/~jhb/ "Power Users Use the Power to Serve" = http://www.FreeBSD.org
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200512011208.06633.jhb>