Re: uvm_fault with -current XEN3_DOMU

[Christoph Egger <Christoph_Egger%gmx.de@localhost>]

On Friday 16 May 2008 12:53:49 Manuel Bouyer wrote:
> On Fri, May 16, 2008 at 11:39:32AM +0200, Christoph Egger wrote:
> > On Thursday 15 May 2008 10:18:15 Manuel Bouyer wrote:
> > > On Thu, May 15, 2008 at 11:45:54AM +1200, Mark Davies wrote:
> > > > Trying to run an i386 XEN3_DOMU kernel from this morning results in
> > > > an immediate uvm_fault:
> > > >
> > > > green-mountain# xm create -c homepages
> > > > Using config file "/etc/xen/homepages".
> > > > Started domain homepages
> > > >  MAC address 00:16:3e:00:00:11
> > > > unknown type console at xenbus0 id 0 not configured
> > > > uvm_fault(0xc04b1d00, 0, 1) -> 0xe
> > > > kernel: supervisor trap page fault, code=0
> > > > Stopped in pid 0.2 (system) at  0:      invalid address
> > > > db> bt
> > > > uvm_fault(0xc04b1d00, 0, 1) -> 0xe
> > > > kernel: supervisor trap page fault, code=0
> > > > Faulted in DDB; continuing...
> > > > db>
> > >
> > > I've seen this too. It's probably calling a NULL function pointer.
> > > I've not had a chance to look at this more closely yet.
> > >
> > >From a rough look into this, this seems to be an interrupt problem.
> >
> > The problem is not DomU specific. It also happens on Dom0 -current.
>
> in my case it seems to be because:
> db> x/x x86_cpu_idle
> netbsd:x86_cpu_idle:    0

On Dom0, I didn't have the chance to get into ddb as I got into an endless 
loop of faults in ddb.

> The attached patch makes a domU kernel boot for me again. I'll commit it
> this evening unless somone beats me.

I can confirm this makes dom0 boot again - with an workaround:
cpu_identify(ci) works for the cpu but not the vcpu.
the cpu identify code thinks, the vcpu is a 386 CPU and calls
panic in x86/x86/identcpu.c, line 816.

My workaround is to turn the panic into a printf() ;-)

Christoph