PCI range checking under qemu-system-sparc64

Mark Cave-Ayland mark.cave-ayland at ilande.co.uk
Sun Jun 14 21:56:39 UTC 2015

On 14/06/15 21:56, John Baldwin wrote:

>> On Jun 14, 2015, at 15:00, Mark Cave-Ayland <mark.cave-ayland at 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:

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


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.



More information about the freebsd-sparc64 mailing list