Re: port-xen/45975: panic: HYPERVISOR_mmu_update failed, ret: -22 on -current MP domU (amd64)

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

The following reply was made to PR port-xen/45975; it has been noted by GNATS.

From: Manuel Bouyer <bouyer%antioche.eu.org@localhost>
To: gnats-bugs%NetBSD.org@localhost
Cc: port-xen-maintainer%NetBSD.org@localhost, gnats-admin%NetBSD.org@localhost,
        netbsd-bugs%NetBSD.org@localhost
Subject: Re: port-xen/45975: panic: HYPERVISOR_mmu_update failed, ret: -22 on
 -current MP domU (amd64)
Date: Fri, 10 Feb 2012 19:42:08 +0100

 On Fri, Feb 10, 2012 at 06:35:00PM +0000, riz%NetBSD.org@localhost wrote:
 > I've been discussing this particular problem with cherry@ for a while,
 > and figured it was time to file a PR.
 > 
 > During heavy load (such as a build.sh -j16), my amd64 MP domUs sometimes
 > panic like so:
 > 
 > 
 > evtchn_do_event: handler 0xffffffff80121b77 didn't lower ipl 8 7
 
 This is annoying but probably unrelated
 
 > xpq_flush_queue: 1 entries (0 successful)
 > 0x00000000d9fe9de0: 0x000000011beb9007
 > panic: HYPERVISOR_mmu_update failed, ret: -22
 > 
 > fatal breakpoint trap in supervisor mode
 > trap type 1 code 0 rip ffffffff801345c5 cs e030 rflags 246 cr2  7f7ff780027c 
 > cWl R6NIrNsGp:  fSPfLf aN0O0T0 bL9O9W0EfR7E1D0 
 > N TRAP EXIT St6o p0p                        O
 > d in pid 1833.1 (sh) at   netbsd:breakpoint+0x5:  leave
 > breakpoint() at netbsd:breakpoint+0x5
 > vpanic() at netbsd:vpanic+0x1f2
 > printf_nolog() at netbsd:printf_nolog
 > xpq_queue_machphys_update() at netbsd:xpq_queue_machphys_update
 > pmap_enter_ma() at netbsd:pmap_enter_ma+0xb74
 > pmap_enter() at netbsd:pmap_enter+0x35
 > uvm_fault_internal() at netbsd:uvm_fault_internal+0xf17
 > trap() at netbsd:trap+0x5f5
 > --- trap (number 7632997) ---
 
 I'm seening this too. It seems to be caused by UVM using a page which
 was previously being used as a page table. Looks like Xen isn't aware that
 this page is not in use any more as page table.
 It can either be because we didn't unpin yet (or that some mapping clearing
 is still peding in a xpq_queue on other CPU), or because the page
 is still effectively used as a page table (possibly via a recursive
 mapping) by some other CPU.
 
 -- 
 Manuel Bouyer <bouyer%antioche.eu.org@localhost>
      NetBSD: 26 ans d'experience feront toujours la difference
 --