[Pavel Machek <pavel@elf.ucw.cz> writes:]
>I just replaced my amd486 to UMC U5S cpu, and VSTA -say- not works
>really well. When program exits, it in sometimes (70% on first program
>to exit, much less than, really strange) raises following 'assertion
>failed':
>                        ASSERT_DEBUG(a->a_flags & ATL_CACHE,
>                                "pset_free: non-cache ref");
Interesting.  It would appear that you have an extra translation which could
not be found by walking the active list of translations.  I recollect that
the most common way to cause this is if your chip ever causes page faults
even though the PTE is present and valid--because then VSTa (which trusts
the hardware) will insert the translation again, and this adds another ATL
entry.  On cleanup the pview/pset slot being marked active will cause VSTa
to clean up the underlying structures--but only once.  Then, during this
final walk, it is noticed that we managed to miss a translation.
If you're up for hacking, you can either try and detect this with some extra
logic in vas_fault().  You might also want to look at this extra ATL and
make sure it looks at least basically sane--matches the pview being deleted,
has a reasonable linked list structure, and so forth.
>The cpu is rather strange (althrough it seems to work well with
>linux). I would like to ask where is TLB invalidation being done? I
>did not found that place.
See hat_deletetrans().
>One more question: This CPU does not have FPU. Is it problem? I know
>there's no emulation, but is missing FPU likely causing assertion
>failed when logging in?
Nope, to the best of my knowledge, it'll only bite you with gcc.
                                                        Andy
Received on Mon Jan 12 05:57:02 1998
This archive was generated by hypermail 2.1.8 : Thu Sep 22 2005 - 15:12:43 PDT