Re: port-xen/45975

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

On Thu, Jul 05, 2012 at 01:20:04AM +0000, Aaron J. Grier wrote:
> The following reply was made to PR port-xen/45975; it has been noted by GNATS.
> 
> From: "Aaron J. Grier" <agrier%poofygoof.com@localhost>
> To: gnats-bugs%netbsd.org@localhost
> Cc: 
> Subject: Re: port-xen/45975
> Date: Wed, 4 Jul 2012 16:12:23 -0700
> 
>  was this ever pulled up to NetBSD-6?

It was pulled up on 2012/02/22 (ticket #29)

> I'm seeing this with an amd64 domU
>  on my xen 4.1.2 system (with NetBSD-6 as dom0) during a build.sh -j2.
>  for comparison, an i386 domU runs to completion.
>  
>  * dom0
>  
>  NetBSD pythagoras.poofy.goof.com 6.0_BETA2 NetBSD 6.0_BETA2 (XEN3_DOM0) #2: 
> Mon Jun 11 16:27:07 PDT 2012 
> agrier%pythagoras.poofy.goof.com@localhost:/disk/teraraid/obj/amd64/disk/teraraid/NetBSD/6/src/sys/arch/amd64/compile/XEN3_DOM0
>  amd64
>  
>  * domU
>  
>  NetBSD milo.pythagoras.poofy.goof.com 6.0_BETA2 NetBSD 6.0_BETA2 (XEN3_DOMU) 
> #2: Mon Jun 11 16:30:47 PDT 2012 
> agrier%pythagoras.poofy.goof.com@localhost:/disk/teraraid/obj/amd64/disk/teraraid/NetBSD/6/src/sys/arch/amd64/compile/XEN3_DOMU
>  amd64
>  
>  * the domU panic
>  
>  xpq_flush_queue: 1 entries (0 successful) on cpu0 (0)
>  cpu0 (0):
>    0x0000000000000000: 0x0000000000000000

This looks bogus. xpmap_ptetomach() returned 0 as PTE's machine address.


>   kpm_pdir[254]: 0x189c5f027
>  cpu1 (1):
>   kpm_pdir[254]: 0x199dba027
>  panic: HYPERVISOR_mmu_update failed, ret: -22
>  
>  cpu0: Begin traceback...
>  printf_nolog() at netbsd:printf_nolog
>  xpq_queue_machphys_update() at netbsd:xpq_queue_machphys_update
>  pmap_free_ptp() at netbsd:pmap_free_ptp+0xef
>  pmap_remove() at netbsd:pmap_remove+0x25b
>  uvm_unmap_remove() at netbsd:uvm_unmap_remove+0x256
>  uvm_unmap1() at netbsd:uvm_unmap1+0x35
>  uvmspace_exec() at netbsd:uvmspace_exec+0xb5
>  execve_runproc() at netbsd:execve_runproc+0x51c
>  execve1() at netbsd:execve1+0x33
>  syscall() at netbsd:syscall+0xc4
>  cpu0: End traceback...

So either something did race and already freed this pdes[], or the p2m table
is corrupted. It looks like yet another problem.

Could you see if a HEAD kernel has the same issue ?

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