Subject: Re: 'program cc1 got fatal signal 11'
To: None <port-arm32@NetBSD.ORG>
From: Adam Gundy <adam@impala.demon.co.uk>
List: port-arm32
Date: 04/28/1998 19:53:34
In message <3544AB36.8D1C50C2@causality.com> you wrote:

> The problem comes when there's an LDM instruction on the end of a page
> and the next page is not mapped. Can't remember if something also has to
> be happening with the write buffer, or if there has to be writeback on a
> register, or not. But that's basically it, anyway. When these in this
> certain condition are happening, it means that an oft unrecoverable
> fault will be taken during the instruction, which shouldn't happen.
> Certainly with the Revision S StrongARMs this has been ironed out, but I
> know it's there in the Rev J and Rev K silicon (look at the label on the
> chip---on my Shark the chip says SA110-S in the middle). Sometimes this
> will result in a binary banging out, and sometimes it will result in the
> machine just slowing down a lot whilst it faults and faults and faults.
> 
> Workarounds: As you can see, there aren't really any. One way would be
> to assemble the instruction twice and NOP one of them out. Another way
> would be to patch the binary afterwards (Pete Burwood wrote something to
> do this) but very occasionally this would not be possible to do. The
> best thing now I guess it to shuffle the LDMs around in the binary and
> get lucky which is what's happened everywhere so far :-)

ok - here's another suggestion. Why not make the kernel pre-page
the page which follows the LDM if it's running on a buggy StrongARM?

This would cause a double page-in in some circumstances (and you would
have to lock the page in memory to prevent it being thrown out then
paged back in due to the preceding LDM) - I would guess that the
chances of having an LDM at the end of a page are small enough to
only happen once or twice per binary? not much of an overhead...

You could unlock the page and allow it to be discarded if the
LDM page is thrown out.

Seeya,
 Adam.
-- 
As the year 2000 approaches, the carefully planned Millenium 'bug'
begins to manifest itself in the computing job market...
Real programmers don't comment their code. If it was hard to write, it
should be harder to modify. These are all my own opinions.