Re: amiga problems

[newsham@aloha.net (Timothy Newsham) writes:]

>... For some reason certain pages are
>getting referenced (by ref_slot()) way more than they should be.
>The strange thing is that if I throw a printf in ref_slot() the
>problem goes away.

Usually, problems like this point back to stale TLB, as I see you're
guessing, too.

>If I do something like:
> if(pp->pp_ref > 10)
> printf("...");
>then the page reference will keep growing until it hits 10, then
>it will stop going out of control. I think that the printf()
>is taking enough time to allow for another process to get
>scheduled and maybe the next flushing of the mmu's cache sets
>things right.

Only if you're multiprocessor... the kernel printf is done in a tight loop.
More likely it ages something out of the TLB which is hosing you.

>I did throw in a flush_atc() to test this out
>and it seems to at least partially fix the problem. I still
>get a few pages that are referenced too many times. This
>causes the system to be unuseable at the next exit() since
>an assertion fails "still ref".

You need to go back and look at your treatment of the TLB when you set up a
kernel translation for the MALLOC()'ed (or malloc(), I think you're using an
old version of the code) memory. In particular, you need to look at what
you do when deleting an old kernel translation. For the i386, it's a
flush_tlb() (but only if DEBUG, hmmm, that doesn't seem right) in
kern_deletetrans().

>I've tried all sorts of things to track it down. It seems that
>the only pages that this happens to are those that are mapped
>by kern_mem when handling message passing. The amiga port differs
>from the i386 in the handling of kernel page tables. There
>is a seperate root pointer for the kernel and the user page tables.
>I'm wondering if maybe problems are arising because views that
>are attached by hat_addtrans() are not visible by the kernel.

Oh, yes, that is definitely an important difference. However, this sounds
like you're having problems with the translation you *think* you're adding
as a part of getting dynamic kernel memory.

An amusing check is to read/modify/write the location, flush the TLB, then
assert that the value you just wrote is, in fact, what is currently in that
location. Use volatile pointers (to make sure it doesn't all end up in a
register).

>Its been a few weeks since I've played with this so I'm
>probably leaving out some important details. I should also
>point out that my sources are quite old now. I should merge
>the current sources in with mine. If you have any ideas on what
>might be wrong please let me know.

Feels like TLB to me (ATC, in Moto-ese, I think).

Oh, for other curious types, TLB == "Translation Lookaside Buffer", and ATC
== "Address Translation Cache". I first heard the term TLB from IBM types,
I don't know where ATC comes from, although it seems like a clearer name.

                                                        Andy
Received on Sat Dec 31 16:59:46 1994