[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