Re: 16k or 64k PAGE_SIZE and "illegal instruction" (signal -4) errors

[Ralf Baechle <ralf@linux-mips.org>]

On Tue, Aug 26, 2014 at 07:06:56AM -0400, Joshua Kinard wrote:

> o32 userland is the primary on both systems.  However, the last SIGILL was
> under the 64k PAGE_SIZE kernel inside of an n32 chroot compiling the 'boost'
> package on the Octane, which I restarted that and it's not complained since.
>  Also got SIGILL on the 16k PAGE_SIZE kernel when I booted 16k PAGE_SIZE the
> first time and ran 'ps'.  Subsequent runs of 'ps' didn't reproduce the
> error.  Also saw SIGILLs in the bootlog of the 16k PAGE_SIZE kernel when
> "rm" was ran once (couldn't reproduce) and when mdadm tried to put one of
> the arrays back together.  Subsequent runs using similar argument lines
> don't reproduce once I got to a root shell.
> 
> Being it's a Gentoo install...the o32 userland is pretty fresh.  Especially
> on the Octane, where I literally rebuilt the old userland over 2-3 times
> just to make sure all the old 5-year cruft was gone.  The n32 userland
> chroot is brand-spanking new.  gcc-4.7.x only for now on both, because of
> PR61538 in gcc.  Latest binutils.
> 
> The O2 is chugging away happily so far in updating a bunch of packages.  So
> I am leaning towards this being another quirk I have to hunt down in the
> Octane's code again.  There isn't much in the Octane-specific code that
> deals with memory, though -- it seems the higher-level MIPS memory code
> handles most things just fine.

Can you enable core dumps?  I'm wondering about the EPC of the crashed
process.  If it's at a function entry or the beginning of a page that
might indicate there is an issue with flushing caches after the containing
page got loaded.  Also interesting to know if this possibly happened in a
signal trampoline or VDSO.

These are just the usual suspects - nothing indicates this case is actually
related.

  Ralf