Skip site navigation (1)Skip section navigation (2)
Date:      Fri, 8 Jan 2016 20:04:03 +0100
From:      Marius Strobl <marius@alchemy.franken.de>
To:        Mark Cave-Ayland <mark.cave-ayland@ilande.co.uk>
Cc:        Kurt Lidl <lidl@pix.net>, freebsd-sparc64@freebsd.org, FreeBSD-Current <freebsd-current@freebsd.org>
Subject:   Re: sparc64 traps during probe (r293243)
Message-ID:  <20160108190403.GB87189@alchemy.franken.de>
In-Reply-To: <568FEA96.9010003@ilande.co.uk>
References:  <568FD8E9.30702@pix.net> <568FEA96.9010003@ilande.co.uk>

next in thread | previous in thread | raw e-mail | index | archive | help
On Fri, Jan 08, 2016 at 04:57:58PM +0000, Mark Cave-Ayland wrote:
> On 08/01/16 15:42, Kurt Lidl wrote:
> 
> This looks amazingly similar to what I get trying to boot FreeBSD under
> QEMU, i.e. pointing at sched_clock():
> 

<...>

> -- kernel stack fault %o7=0xc011a050 --
> panic: longjmp botch
> cpuid = -1012475520
> KDB: stack backtrace:
> Uptime: 3s
> 
> Note also the "longjmp botch" error right at the end. This is with the
> sun4u timer fix patch developed with help from Marius which has recently
> been applied to QEMU git master. So maybe this is a kernel bug after all?

No, that still is a completely trashed kernel stack as previously
seen when running under QEMU so the whole backtrace is questionable.
Apart from that, sched_clock() is called rather frequently so it is
not unlikely to show up in a kernel back trace but neither of the
two back traces in question suggest it's the culprit (assuming that
the one seen with QEMU actually is sane).

Marius





Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20160108190403.GB87189>