Don't panic if the MEM64 range is not present as qemu does not include it.

[jhb]

Summary

This fixes the panic in qemu, though now the system appears to hang in
qemu before getting into single user mode.

Test Plan

• boot a HEAD ISO with and without the patch in qemu

[marius]

Generally looks okay. However, you should keep the check for an unsupported number of ranges but change it to ensure that the device tree doesn't include more than PSYCHO_NRANGE, i. e. 4, ranges or alternatively additionally limit the loop to PSYCHO_NRANGE. Otherwise, a device tree having more than 4 ranges would now cause an out-of-bounds array access.

[mark.cave-ayland_ilande.co.uk]

Any update on this patch at all?

[jhb]

In D2791#54023, @marius wrote:

Generally looks okay. However, you should keep the check for an unsupported number of ranges but change it to ensure that the device tree doesn't include more than PSYCHO_NRANGE, i. e. 4, ranges or alternatively additionally limit the loop to PSYCHO_NRANGE. Otherwise, a device tree having more than 4 ranges would now cause an out-of-bounds array access.

The range[] array is dynamically allocated, so there shouldn't be an out-of-range access by the for loop, yes? The pci_bh[] array is only indexed by the result of OFW_PCI_RANGE_CS() and that only returns values 0 through 3.

Hmm, looks like the fire and schizo drivers have the same code. It seems like STX_NRANGE and friends should really be replaced by an OFW_PCI_NRANGE constant since those arrays are indexed by OFW_PCI_RANGE_CS values, not the indices of the raw ranges property.

[jhb]

• Retire the fire/psycho/schizo NRANGE and use an OFW constant instead.

[danfe]

Thanks for the patch, it does fix the psycho panic in qemu for me as well (the kernel still hangs at some later stage); tested against fresh -CURRENT sources.

[jhb]

@marius included these changes in rS287726