Date: Sun, 21 Apr 2019 02:36:54 +0000 From: bugzilla-noreply@freebsd.org To: ppc@FreeBSD.org Subject: [Bug 233863] r345425 on PowerMac G5 may require kern.smp.disabled=1 and must set usefdt=1 which causes net interface reorder Message-ID: <bug-233863-21-nZH0dLlOV1@https.bugs.freebsd.org/bugzilla/> In-Reply-To: <bug-233863-21@https.bugs.freebsd.org/bugzilla/> References: <bug-233863-21@https.bugs.freebsd.org/bugzilla/>
next in thread | previous in thread | raw e-mail | index | archive | help
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D233863 --- Comment #22 from Mark Millard <marklmi26-fbsd@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 =3D 409600; buffer =3D 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. --=20 You are receiving this mail because: You are the assignee for the bug.=
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?bug-233863-21-nZH0dLlOV1>