On 2/9/2009 2:49:36 PM, Jeremy Fitzhardinge wrote:
> M A Young wrote:
> > I tried again with the genuine changeset 2342 (2350 won't build for
> > me, I get the error
> > arch/x86/kernel/early_printk.c: In function 'early_dbgp_init':
> > arch/x86/kernel/early_printk.c:827: error: 'PAGE_KERNEL_NOCACHE'
> > undeclared (first use in this function)
> > arch/x86/kernel/early_printk.c:827: error: (Each undeclared
> > identifier is reported only once
> > arch/x86/kernel/early_printk.c:827: error: for each function it
> > appears in.)
> > ) and the resulting dmesg is essentially the same, but without the
> > pte related tracebacks, so the first two are still there.
>
> Erm, yes. The x86-unify-* block of patches is a bit problematic; I
> probably should have left them commented out. If you remove/comment
> out them all, then it should build OK.
>
> BTW, I'm in the middle of migrating this patch queue into git, which
> will then be the official home for all Xen/pvops work. It should be
> ready in the next day or so.
>
> J
>
BTW, I tried 2350 (latest), and I'm seeing repeated complaints from
mod_l1_entry().
(XEN) mm.c:1650:d0 Bad L1 flags 400000
By adding printk, I got the same info: mfn=ff7fffffff, gl1mfn=72c96 from every
complaint; mfn looks bogus.
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.
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.
...
if (HYPERVISOR_multicall(b->entries, b->mcidx) != 0)
BUG();
for (i = 0; i < b->mcidx; i++)
if (b->entries[i].result < 0)
ret++;
#if MC_DEBUG
if (ret) {
printk(KERN_ERR "%d multicall(s) failed: cpu %d\n",
ret, smp_processor_id());
dump_stack();
for (i = 0; i < b->mcidx; i++) {
printk(KERN_DEBUG " call %2d/%d: op=%lu
arg=[%lx] result=%ld\t%pF\n",
...
.
Jun Nakajima | Intel Open Source Technology Center
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel
|
Home