Date: Wed, 31 Dec 2014 11:31:05 -0700 From: Ian Lepore <ian@freebsd.org> To: Keith White <kwhite@site.uottawa.ca> Cc: freebsd-arm@freebsd.org Subject: Re: BBB translation fault panic with "kldload" Message-ID: <1420050665.1018.315.camel@freebsd.org> In-Reply-To: <alpine.BSF.2.11.1412310803080.74809@localhost.my.domain> References: <alpine.BSF.2.11.1412310803080.74809@localhost.my.domain>
next in thread | previous in thread | raw e-mail | index | archive | help
On Wed, 2014-12-31 at 08:41 -0500, Keith White wrote: > I get a kernel panic when trying to use kernel modules with recent > BBB kernels. > > Here's what happens when I try to "kldload nullfs" with a freshly > built r276468: > > ======================= [...] Just a quick followup... as of r276047 modules are broken on armv6. This is also the root cause of the problem reported in the thread "vm_fault during BBB-boot". Unfortunately, at this point we can't just revert that single change because lots of commits that have happened since then rely on it. So we're temporarily in a "-current is broken" state and will be until a fix is found. In the meantime, the 10-stable branch doesn't have this problem (and in general is more immune to this type of problem because code doesn't get moved there until it has had some testing), so using it is a viable option for folks who just need to get on with their lives. Or you can sync your -current source directory back to r276046. For those interested in the gory details... when we added -march=armv7 to the kernel compiles it allowed the compiler to start generating new more efficient movw/movt instructions to load an address into a register. It also emits new (for us) types of relocation info for those, and our old linker and runtime loader don't handle that kind of relocation info correctly in kernel modules. -- Ian
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?1420050665.1018.315.camel>