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>
index | next in thread | previous in thread | raw e-mail
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). Mariushome | help
Want to link to this message? Use this
URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20160108190403.GB87189>