NetBSD-Bugs archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]

Re: port-alpha/42174

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

From: "Michael L. Hitch" <>
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 
    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             
 Computer Consultant
 Information Technology Center
 Montana State University       Bozeman, MT     USA

Home | Main Index | Thread Index | Old Index