All of lore.kernel.org
 help / color / mirror / Atom feed
From: Ralf Baechle <ralf@linux-mips.org>
To: Joshua Wise <mips@joshuawise.com>
Cc: linux-mips@linux-mips.org
Subject: Re: SMP badness on 5kc
Date: Wed, 3 Aug 2005 17:38:20 +0100	[thread overview]
Message-ID: <20050803163820.GA3530@linux-mips.org> (raw)
In-Reply-To: <200508031016.28227.mips@joshuawise.com>

On Wed, Aug 03, 2005 at 10:16:27AM -0400, Joshua Wise wrote:

> I have been setting up a simulation of a multiprocessor 5kc board that my 
> company is developing using gxemul, and I've come across a few problems with 
> the MIPS SMP support.

The 5Kc has no cache coherency, so I don't see how it could be done other
than by offloading that into software - which performancewise I would
expect to be an unatractive solution.  Well, there's always the option of
disabling caches which is the easiest way but probably even slower.

> The first issue that I came across was that 5kc does not have an scache, and 
> hence r4k_blast_scache will be null, and hence local_r4k_flush_icache_range 
> crashes the system with a kernel NULL dereference. (Actually, that happens 
> early enough that it drops back into YAMON, without even giving me a kernel 
> panic.) Strangely enough, this only happens on SMP... My solution for this 
> was to put a switch statement like the one in local_r4k___flush_cache_all 
> into local_r4k_flush_icache_range around the if 
> (!cpu_icache_snoops_remote_store). This seemed to cause the crash to stop 
> happening.

That is acutally somewhat similar to another problem somebody found
recently for a uniprocessor configuration.  The whole second level cache
flushing thing only really is needed at all if a system has such a cache
at all, so something like:

  if (!cpu_icache_snoops_remote_store && cpu_has_sc) {
     [...]
  }

would be sensible.  Well, there's no cpu_has_sc but cpu_scache_line_size()
would serve the same purpose.

> My second issue, unresolved to date, is that we are calling 
> on_each_cpu(local_r4k___flush_cache_all) (called from r4k_flush_cache_all) 
> while interrupts are disabled. This doesn't happen while we are bringing up 
> CPUs 0 or 1 -- it seems to only happen when bringing up CPU2. This causes a 
> "badness" message, followed by either a lot of oopses, or a deadlock. Below 
> my sig is a boot log from serial, complete with debug messages written by the 
> Sirius Cybernetics Corporation. :)

Who were the first to be shot when the great revolution came, says the
Hitchhiker's Guide to The Galaxy ;-)

I recently modified the code to avoid such SMP cacheflushes during startup.
As it turned out only a local_* flush was needed which nicely dealt with
the warnings.

  Ralf

      reply	other threads:[~2005-08-03 16:35 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2005-08-03 14:16 SMP badness on 5kc Joshua Wise
2005-08-03 16:38 ` Ralf Baechle [this message]

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=20050803163820.GA3530@linux-mips.org \
    --to=ralf@linux-mips.org \
    --cc=linux-mips@linux-mips.org \
    --cc=mips@joshuawise.com \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.