From mboxrd@z Thu Jan 1 00:00:00 1970 From: Thomas Goirand Subject: Re: Debian linux-image-2.6.32-4-xen-amd64 2.6.32-11 doesn't boot with > 4 GiB; resets immediatelly, no log messages Date: Sun, 11 Apr 2010 17:49:30 +0800 Message-ID: <4BC19B2A.3040501@goirand.fr> References: <20100408113422.GD4183@kepler.schwinge.homeip.net> <20100408133820.GA29832@phenom.dumpdata.com> <20100408221953.GG4183@kepler.schwinge.homeip.net> <4BBE5DF2.6040707@goop.org> <20100409180016.GA14029@kepler.schwinge.homeip.net> <4BBF7004.8000707@goop.org> <20100410221349.GM4183@kepler.schwinge.homeip.net> <4BC1013D.2020003@goop.org> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-15 Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <4BC1013D.2020003@goop.org> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com To: xen-devel@lists.xensource.com List-Id: xen-devel@lists.xenproject.org Jeremy Fitzhardinge wrote: > On 04/10/2010 03:13 PM, Thomas Schwinge wrote: >>> Normally that would be OK, because it uses: >>> >>> __get_user(pfn, &machine_to_phys_mapping[mfn]); >>> >>> to dereference the array. But at this early stage, none of the kernel's >>> exception handlers have been set up, so this will just fault into Xen. >>> >>> It would be interesting to confirm this by building your kernel with >>> CONFIG_DEBUG_INFO=y in the .config, and verify that the faulting >>> instruction is actually this line. >>> >> Bingo! >> > > Excellent. Could this be also the reason why I had very funky memory management (eg: some RAM missing between "xm list" and "xm info")? Thomas