Hi,
thanks for the reports

On Sat, Mar 25, 2006 at 05:24:07PM +0100, Stephane Bortzmeyer wrote:
> On Fri, Mar 24, 2006 at 08:57:34PM +0100,
>  Stephane Bortzmeyer <stephane@sources.org> wrote 
>  a message of 63 lines which said:
> 
> > xbd0 at xenbus0 id 769: Xen Virtual Block Device Interface
> > panic: kernel diagnostic assertion "(flags & UVM_KMF_TYPEMASK) == UVM_KMF_WIRED || (flags & UVM_KMF_TYPEMASK) == UVM_KMF_PAGEABLE || (flags & UVM_KMF_TYPEMASK) == UVM_KMF_VAONLY" failed: file "/Volumes/data/bouyer/current/src/sys/uvm/uvm_km.c", line 525
> > Stopped in pid 2.1 (xenbus_probe) at    netbsd:cpu_Debugger+0x4:        popl    %
> > ebp
> > db> 
> 
> This crash is when I use the ordinary image (not the INSTALL one). 
> [...]
> db> trace                                                                      
> cpu_Debugger(c0402bc6,c624fd88,0,c02a5705,0) at netbsd:cpu_Debugger+0x4
> panic(c0433240,c03f2e90,c041ec00,c041e920,20d) at netbsd:panic+0x12c   
> __assert(c03f2e90,c041e920,20d,c041ec00,c624fdec) at netbsd:__assert+0x2e
> uvm_km_alloc(c0452960,1000,0,10,c071a038) at netbsd:uvm_km_alloc+0x20a   
> xbd_xenbus_resume(c071a000,c071a000,c624fef4,c03983f4,0) at netbsd:xbd_xenbus_re
> sume+0x3c                                                                       

OK, I forgot UVM_KMF_WIRED to uvm_km_alloc(), and didn't notice it because I
only used the INSTALL kernel in my tests :(

On Sat, Mar 25, 2006 at 05:33:21PM +0100, Stephane Bortzmeyer wrote:
> On Sat, Mar 25, 2006 at 05:13:05PM +0100,
>  Stephane Bortzmeyer <stephane@sources.org> wrote 
>  a message of 31 lines which said:
> 
> > kernel: supervisor trap page fault, code=0qqqqqj                  
> > Stopped in pid 1359.1 (sysinst) at      0xc022f103:     pushl   0x144(%edx)
> > db>                                                                        
> 
> This is from the INSTALL image. xm info says:
> kernel: supervisor trap page fault, code=0qqqqqj                  
> Stopped in pid 1359.1 (sysinst) at      0xc022f103:     pushl   0x144(%edx)
> db> trace      
> ?(8e0b,1,2000,c5a0bad4,c641db38) at 0xc022f103

This is in xbd_open(). Ops, it doesn't check if the devices exists before
calling dk_open().

Both should be fixed now, as well as an uninitialised memory issue I found
in xenbus. I have yet another issue to fix in xbd: I found that trying to
read past the end of disk (for example if the disklabel is wrong),
the linux backend keeps doesn't return an error and keeps a reference
to the pages used for the request. This leads to a wedged xbd device, and
the domain can't even be properly destroyed. I will commit a workaround
for this shortly, and update the binary kernel images.

-- 
Manuel Bouyer <bouyer@antioche.eu.org>
     NetBSD: 26 ans d'experience feront toujours la difference
--