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

[Joshua Kinard <kumba@gentoo.org>]

On 08/26/2014 06:20, Ralf Baechle wrote:
> On Tue, Aug 26, 2014 at 05:27:28AM -0400, Joshua Kinard wrote:
> 
>> Okay, so from the "make kmap cache coloring aware" thread, I've been playing
>> with larger PAGE_SIZE values on the Octane and O2 for the last few hours.
>> 16k and 64k used to, in the past, never get far after init (usually died
>> *at* init)  That appears to have changed now.  Most programs seem to
>> JustWork(), but very randomly, I am getting a signal -4, illegal instruction
>> (SIGILL) on the Octane.  Both systems are running kernels w/ 64k PAGE_SIZE
>> at the moment.
>>
>> I cannot reproduce it on demand, so I'm not really sure what the cause could
>> be.  PAGE_SIZE should be largely transparent to userland these days, so I am
>> wondering if this might be more oddities w/ an R14000 CPU.
> 
> This sound very unlikely as the CPU was primarily designed to run IRIX and
> SGI's systems were using 16k or even 64k page size.
> 
> What userland are you running and how old is it?  Are you seeing different
> results for 16k and 64k?

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.

-- 
Joshua Kinard
Gentoo/MIPS
kumba@gentoo.org
4096R/D25D95E3 2011-03-28

"The past tempts us, the present confuses us, the future frightens us.  And
our lives slip away, moment by moment, lost in that vast, terrible in-between."

--Emperor Turhan, Centauri Republic