Re: port-alpha/42174

["Michael L. Hitch" <mhitch%lightning.msu.montana.edu@localhost>]

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

From: "Michael L. Hitch" <mhitch%lightning.msu.montana.edu@localhost>
To: gnats-bugs%NetBSD.org@localhost
Cc: gnats-admin%netbsd.org@localhost, dmarquess%gmail.com@localhost
Subject: Re: port-alpha/42174
Date: Mon, 26 Oct 2009 11:50:24 -0600 (MDT)

 On Sat, 17 Oct 2009, Dustin Marquess wrote:
 
 > Got the machine to deadlock again.  Used the halt button to get into
 > ddb and this is the stack trace that I got:
 >
 > db{0}> trace
 > cpu_Debugger() at netbsd:cpu_Debugger+0x4
 > panic() at netbsd:panic+0x244
 > console_restart() at netbsd:console_restart+0x78
 > XentRestart() at netbsd:XentRestart+0x90
 > --- console restart (from ipl 4) ---
 > nullop() at netbsd:nullop
 > _kernel_lock() at netbsd:_kernel_lock+0x1c0
 
     This would indicate that CPU0 is attempting to acquire the kernel lock,
 but presumably CPU1 currently has it and is unable to release it for some 
 reasone.
 
    I don't know of any easy way to determine what CPU1 is currently doing. 
 It most like is unable to process the IPI interrupt sent by entering DDB
 and pausing.  Even if it was able to, something is broken in looking at a 
 backtrace in the other cpus, although I think the register contents can be 
 displayed when the cpu is able to respond to the IPI pause request.
 
    A LOCKDEBUG kernel would provide more information on what is currently 
 locked, but I don't think that's working on the alpha at the moment.
 
 
 
 --
 Michael L. Hitch                       mhitch%montana.edu@localhost
 Computer Consultant
 Information Technology Center
 Montana State University       Bozeman, MT     USA