Date: Tue, 27 Mar 2018 21:23:51 +0000 From: bugzilla-noreply@freebsd.org To: freebsd-ppc@FreeBSD.org Subject: [Bug 226974] kernel DSI read trap at boot Message-ID: <bug-226974-21-HfYmQfLfbv@https.bugs.freebsd.org/bugzilla/> In-Reply-To: <bug-226974-21@https.bugs.freebsd.org/bugzilla/> References: <bug-226974-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=3D226974 --- Comment #3 from Leandro Lupori <leandro.lupori@gmail.com> --- After some more investigation, I found that the part of the commit that "br= oke" the boot on powerpc64 with FDT (that is the default now) was the bdomain[BUF_DOMAINS] array. By simply adding this array in vfs_bio.c in the previous commit I'm able to reproduce the issue. On powerpc64 this array has a size of about 520KB, mainly because the defau= lt MAXCPU value for it is 256, which makes the following bufdomain field take a lot of space: struct bufqueue bd_subq[MAXCPU + 1]; /* Per-cpu sub queues + global */ If I change bd_subq size to 17, for instance, then I'm able to go further, = but then I get stuck after this message: usb_needs_explore_all: no devclass I don't know if this is related to same issue or not. However, it is still not clear to me why this extra KBs are a problem for powerpc64. It is probably something related to FDT, because unsetting "usef= dt" in the bootloader makes the system bootable again, even without the change above. --=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-226974-21-HfYmQfLfbv>