From mboxrd@z Thu Jan 1 00:00:00 1970 From: Jeremy Fitzhardinge Subject: Re: Tracebacks from dom0 pvops changeset 2342 Date: Mon, 09 Feb 2009 17:16:48 -0800 Message-ID: <4990D580.3020801@goop.org> References: <498F896A.5070505@goop.org> <499074EF.7010401@goop.org> <499085DF.4070509@goop.org> <4990B300.9060302@goop.org> <0B53E02A2965CE4F9ADB38B34501A3A16D8517B1@orsmsx505.amr.corp.intel.com> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <0B53E02A2965CE4F9ADB38B34501A3A16D8517B1@orsmsx505.amr.corp.intel.com> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com To: "Nakajima, Jun" Cc: "xen-devel@lists.xensource.com" , M A Young List-Id: xen-devel@lists.xenproject.org Nakajima, Jun wrote: > BTW, I tried 2350 (latest), and I'm seeing repeated complaints from mod_l1_entry(). > (XEN) mm.c:1650:d0 Bad L1 flags 400000 > Is this 32 or 64 bit? I fixed similar symptoms in 32-bit with "x86/paravirt: return full 64-bit result" I think. > By adding printk, I got the same info: mfn=ff7fffffff, gl1mfn=72c96 from every complaint; mfn looks bogus. > Sure does. > Looks like it's the mod_l1_entry() called by do_update_va_mapping(), and the guest stack shows (by vcpu_show_execution_state() that I added) it's going back to xen_mc_flush(). As long as I ignore the MEM_LOG message, it boots up to the login prompt. > Odd. What's the backtrace beyond that? > One thing that puzzles me is that MC_DEBUG is 1 in multicalls.c, but I don't see any complaints from dom0. Is the following MC_DEBUG working? Or I may be looking at a wrong stack. > Yes, I've noticed that sometimes multicalls seem not to report detectable errors. I haven't looked into see what's really going on. J