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

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

On Tue, Aug 26, 2014 at 11:42:30AM +0100, Maciej W. Rozycki wrote:

> > > 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?
> 
>  FWIW, I've been always using the 16k page size exclusively with my 64-bit 
> userland and my SWARM board using the SB-1/BCM1250 processor (with either 
> endianness) and never had issues even with stuff as intensive as native 
> GCC bootstrapping (with all the languages enabled such as Ada and Java) or 
> glibc builds.  It's been like 8 years now and quite recent kernels like 
> from two months ago gave me no trouble either.  So it must be something 
> specific to the configuration, my first candidates to look at would be the 
> generated TLB and cache handlers, that are system-specific.

Generally the R10000 architecture is such that there is much less potencial
for software bugs as well.  The TLB is nice, cleans up conflicting entries
so no TLB shutdown or similar horrors possible.  And the caches while they
suffer from cache aliases, will cleanup those aliases transparently to
software, that is an OS can treat them as non-aliasing.  R10000 systems
with the notable exception of the SGI O2 and Indigo² R10000 have fully
coherent I/O.  Basically the only thing that needs to be done in software
is I-cache coherency.  The I-cache snoops stores by remote CPUs but not
by the local CPU itself so in a sense SMP is a simpler case than UP even.

  Ralf