Date: Sun, 14 Jun 2015 22:56:23 +0100 From: Mark Cave-Ayland <mark.cave-ayland@ilande.co.uk> To: John Baldwin <jhb@FreeBSD.org> Cc: "freebsd-sparc64@freebsd.org" <freebsd-sparc64@freebsd.org> Subject: Re: PCI range checking under qemu-system-sparc64 Message-ID: <557DF887.20508@ilande.co.uk> In-Reply-To: <A88F6A52-FA8A-4669-A2D6-23374F8E26BB@FreeBSD.org> References: <53F73E6F.9080805@ilande.co.uk> <2084808.1lxSgnvf69@ralph.baldwin.cx> <557ADCAB.9020409@FreeBSD.org> <557B6116.70900@ilande.co.uk> <557C1162.3000106@FreeBSD.org> <557D82F8.50908@ilande.co.uk> <557DA6D5.4070800@FreeBSD.org> <557DCF54.7020606@ilande.co.uk> <A88F6A52-FA8A-4669-A2D6-23374F8E26BB@FreeBSD.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On 14/06/15 21:56, John Baldwin wrote: >> On Jun 14, 2015, at 15:00, Mark Cave-Ayland <mark.cave-ayland@ilande.co.uk> wrote: >> >> On 14/06/15 17:07, John Baldwin wrote: >> >>>> Does the latest HEAD contain a fix for this error or have I >>>> misconfigured something? >>> >>> Did you do 'make TARGET=sparc64 kernel-toolchain' first? >> >> Ah no - I just tried your instructions as printed as I'm not overly >> familiar with FreeBSD. With the above statement run first, I'm now able >> to complete the kernel build but still can't seem to create the >> resulting ISO: > > kldload geom_vtoc8 > > (Or whatever GEOM module has vtoc8 in its name) Got it. The module name was geom_part_vtoc8 and that was enough to enable me to generate a valid ISO, apply your patch and verify that the build works. Thank you for your help so far! A quick test with QEMU debugging enabled shows the following on the console just before the freeze: IN: 0x00000000c0590188: st %g1, [ %l3 + 0x8c ] 0x00000000c059018c: membar #MemIssue 0x00000000c0590190: sll %l0, 2, %g2 0x00000000c0590194: ld [ %i3 + 0x88 ], %g1 0x00000000c0590198: cmp %g2, %g1 0x00000000c059019c: clr %o0 0x00000000c05901a0: movg %icc, 1, %o0 0x00000000c05901a4: call 0xc08aaee0 (hangs) Examining the kernel symbols show that 0xc08aaee0 is the address of the cpu_idle() function which is being called from sched_idletd(). My next job will be to step through cpu_idle() and see if we're getting stuck in a loop or disappearing somewhere else. ATB, Mark.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?557DF887.20508>