Linux MIPS Architecture development
 help / color / mirror / Atom feed
From: Joshua Kinard <kumba@gentoo.org>
To: linux-mips@linux-mips.org
Subject: Re: 16k or 64k PAGE_SIZE and "illegal instruction" (signal -4) errors
Date: Tue, 26 Aug 2014 08:03:28 -0400	[thread overview]
Message-ID: <53FC7790.80602@gentoo.org> (raw)
In-Reply-To: <20140826114925.GA24146@linux-mips.org>

On 08/26/2014 07:49, Ralf Baechle wrote:
> 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.

Yeah, coherency shouldn't be a problem for the Octane.  hardware-coherent
like IP27.

The icache snooping fix is already enabled in
arch/mips/include/asm/mach-ip30/cpu-feature-overrides.h:

#define cpu_icache_snoops_remote_store 1

SMP is not working yet on IP30, though.  I gave up on that for now, because
I can't get the second CPU to start ticking properly.

-- 
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

  reply	other threads:[~2014-08-26 12:03 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-08-26  9:27 16k or 64k PAGE_SIZE and "illegal instruction" (signal -4) errors Joshua Kinard
2014-08-26 10:20 ` Ralf Baechle
2014-08-26 10:42   ` Maciej W. Rozycki
2014-08-26 10:49     ` Maciej W. Rozycki
2014-08-26 11:49     ` Ralf Baechle
2014-08-26 12:03       ` Joshua Kinard [this message]
2014-08-26 12:11         ` Ralf Baechle
2014-08-26 11:06   ` Joshua Kinard
2014-08-26 11:50     ` Maciej W. Rozycki
2014-08-26 12:03     ` Ralf Baechle
2014-08-26 13:16       ` Joshua Kinard
2014-08-26 14:02         ` Ralf Baechle
2014-08-27  0:53           ` Joshua Kinard
2014-09-04  3:35             ` Joshua Kinard
2014-08-26 14:03         ` Ralf Baechle

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=53FC7790.80602@gentoo.org \
    --to=kumba@gentoo.org \
    --cc=linux-mips@linux-mips.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox