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

From: Andrew Doran <ad@netbsd.org>
To: gnats-bugs@NetBSD.org
Cc: port-alpha-maintainer@netbsd.org, gnats-admin@netbsd.org,
	netbsd-bugs@netbsd.org
Subject: Re: port-alpha/36573: memory management fault panic in turnstile_block
Date: Thu, 28 Jun 2007 10:52:57 +0100

 On Thu, Jun 28, 2007 at 09:35:00AM +0000, jarle@uninett.no wrote:
 
 > db{0} trace
 > cpu_Debugger() at netbsd:cpu_Debugger+0x4
 > panic() at netbsd:panic+0x1e8
 > trap() at netbsd:trap+0x3a8
 > XentMM() at netbsd:XentMM+0x20
 > --- memory management fault (from ipl 6) ---
 > turnstile_block() at netbsd:turnstile_block+0x15c
 > mutex_vector_enter() at netbsd:mutex_vector_enter+0x2e4
 > statclock() at netbsd:statclock+0x180
 > hardclock() at netbsd:hardclock+0x47c
 > interrupt() at netbsd:interrupt+0x104
 > XentInt() at netbsd:XentInt+0x1c
 > --- interrupt (from ipl 0) ---
 > _kernel_unlock() at netbsd:_kernel_unlock+0xc4
 > exit1() at netbsd:exit1+0x830
 > sys_exit() at netbsd:sys_exit+0x8c
 > syscall_plain() at netbsd:syscall_plain+0x194
 > XentSys() at netbsd:XentSys+0x60
 
 It's trying to go asleep from the clock interrupt. I suspect that the
 per-process statclock lock (p->p_stmutex) is being destroyed prematurely.
 There was a recent issue that could have caused this, but I fixed it. I'll
 investigate further.
 
 Andrew