Skip site navigation (1)Skip section navigation (2)
Date:      Thu, 19 May 2011 10:10:22 -0700
From:      Marcel Moolenaar <marcel@xcllnt.net>
To:        Anton Shterenlikht <mexas@bristol.ac.uk>
Cc:        freebsd-sparc64@freebsd.org
Subject:   Re: panic on r219425
Message-ID:  <2147A9F8-B80F-4A33-9D7F-ACE8DFFF3747@xcllnt.net>
In-Reply-To: <20110519162553.GA88158@mech-cluster241.men.bris.ac.uk>
References:  <20110519162553.GA88158@mech-cluster241.men.bris.ac.uk>

next in thread | previous in thread | raw e-mail | index | archive | help

On May 19, 2011, at 9:25 AM, Anton Shterenlikht wrote:

> I found my blade 1500 silver r219425 in debugger
> today after Uptime: 69d2h22m8s
> 
> db> bt
> Tracing pid 10 tid 100002 td 0xfffff80002059980
> uart_intr() at uart_intr+0x1b4
> intr_event_handle() at intr_event_handle+0x64
> intr_execute_handlers() at intr_execute_handlers+0x8
> intr_fast() at intr_fast+0x68
> -- interrupt level=0xc pil=0 %o7=0xc0268610 --
> sched_idletd() at sched_idletd+0x8c
> fork_exit() at fork_exit+0x9c
> fork_trampoline() at fork_trampoline+0x8
> db> show thread
> Thread 100002 at 0xfffff80002059980:
> proc (pid 10): 0xfffff80002053a70
> name: idle
> stack: 0xe2e12000-0xe2e19fff
> flags: 0x50024  pflags: 0x200000
> state: RUNNING (CPU 0)
> priority: 255
> container lock: sched lock (0xc05e5bc0)
> db>

Normally when you go from the uart interrupt handler to the
debugger, you have a break condition on the serial line or
someone (accidentally) typed the debugger character sequence.
Look at the message buffer to see if this is the case. If
yes, then you can just continue...

FYI,

-- 
Marcel Moolenaar
marcel@xcllnt.net





Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?2147A9F8-B80F-4A33-9D7F-ACE8DFFF3747>