HEAD instability on Xen

[Manuel Bouyer <bouyer%antioche.eu.org@localhost>]

Hi,
I've tested a kernel built from HEAD (which I didn't do for some time) and
seeing panics when starting xend (this dom0 has only 64Mb RAM allocated).
It's always a uvm_fault() on a kernel address, but the fault instruction
varies. Here's a sample of a panic:

Starting xend.
uvm_fault(0xc09605c0, 0xc8028000, 1) -> 0xe
fatal page fault in supervisor mode
trap type 6 code 0 eip c03c8bdd cs 9 eflags 10246 cr2 0 ilevel 0
kernel: supervisor trap page fault, code=0
Stopped in pid 169.1 (python2.4) at     netbsd:uvm_map_lookup_entry+0x4d:       
cmpl     %edi,0x20(%ebx)
db> tr
uvm_map_lookup_entry(c5db0ac4,8063000,c7fa6690,1,0) at 
netbsd:uvm_map_lookup_entry+0x4d
uvm_fault_internal(c5db0ac4,8063000,2,0,c04db079) at 
netbsd:uvm_fault_internal+0xdd
trap() at netbsd:trap+0x415
--- trap (number 6) ---
copyout(c5db0ac4,c7531000,8063000,4c8,c5db0ac4) at netbsd:copyout+0x4e
uiomove(c7531000,4c8,c7fa697c,c7fa685c,0) at netbsd:uiomove+0x5d
ubc_uiomove(c7d64c80,c7fa697c,4c8,0,101) at netbsd:ubc_uiomove+0xeb
ffs_read(c7fa6938,10001,0,4,0) at netbsd:ffs_read+0x46b
VOP_READ(c7d64c80,c7fa697c,10,c5da3f00,ffffffff) at netbsd:VOP_READ+0x31
vn_rdwr(0,c7d64c80,8063000,4c8,1b000) at netbsd:vn_rdwr+0xa5
vmcmd_readvn(c7fcae00,c0d18f1c,bfc00000,c7fa6bd8,8) at netbsd:vmcmd_readvn+0x65
execve1(c7fcae00,bba83a30,bfbfe704,bfbfeeec,c040e6b0) at netbsd:execve1+0x695
sys_execve(c7fcae00,c7fa6c30,c7fa6c58,c7fa6cd0,bba990c0) at 
netbsd:sys_execve+0x31
syscall(c7fa6c78,bbb9001f,804001f,bfbf001f,bba9001f) at netbsd:syscall+0x12b
db> sh reg
ds          0x11
es          0x11
fs          0x31
gs          0x11
edi         0x8063000
esi         0xc5db0afc
ebp         0xc7fa6588
ebx         0xc8028744
edx         0
ecx         0
eax         0xc5db0ac4
eip         0xc03c8bdd  uvm_map_lookup_entry+0x4d
cs          0x9
eflags      0x10246
esp         0xc7fa6560
ss          0x11

I also did see it on on a xeni386 kernel from bouyer-xenamd64 which had HEAD 
code from a few days ago.
I suspect it's related to the recent pool_cache changes, but I didn't see 
anything obvious. Does anyone have a clue ?

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