[Bug 233863] r345425 on PowerMac G5 may require kern.smp.disabled=1 and must set usefdt=1 which causes net interface reorder
bugzilla-noreply at freebsd.org
bugzilla-noreply at freebsd.org
Sun Apr 21 02:36:56 UTC 2019
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=233863
--- Comment #22 from Mark Millard <marklmi26-fbsd at yahoo.com> ---
One thing I'm not sure of for usefdt-mode is what
the consequences of small memory machines might be.
/usr/src/stand/powerpc/ofw/ofwfdt.c has:
int
fdt_platform_load_dtb(void)
{
void *buffer;
size_t buflen = 409600;
buffer = malloc(buflen);
fdt_create_empty_tree(buffer, buflen);
add_node_to_fdt(buffer, OF_peer(0), fdt_path_offset(buffer, "/"));
ofwfdt_fixups(buffer);
fdt_pack(buffer);
fdt_load_dtb_addr(buffer);
free(buffer);
return (0);
}
On a 1 GiByte machine, with some other overhead
use of RAM, that 409600 could be around half the
available memory --or more. Even though
fdt_load_dtb_addr will make a smaller copy, and
then the bigger one will be freed, the copy's
address range is constrained by the existing big
allocation at the time.
On a sufficiently small memory machine the 409600
would just not be possible. (That might even be
true for a 1 GiByte machine.) Note the lack of
any check on the malloc(409600)'s success vs.
failure status. (By contrast, fdt_load_dtb_addr
does check for a NULL return, even though
fdt_platform_load_dtb ignores the fdt_load_dtb_addr
return value.)
Nothing that I've done so far attempts to deal with
such issues. The behavior for insufficient problems
is probably a mess and it may not be obvious that
any odd behavior is tied to insufficient RAM for the
existing implementation.
--
You are receiving this mail because:
You are the assignee for the bug.
More information about the freebsd-ppc
mailing list