>
> According to Ralf Baechle ...
> >
> > On Thu, Apr 06, 2000 at 03:12:34PM -0700, Kanoj Sarcar wrote:
> >
> > > It looks like when the first processor starts executing the Linux
> > > kernel entry point (from the IO6prom), it already has the TS (tlb
> > > shutdown) bit set. I am wondering why this might happen. Note that
> > > the Linux kernel is not loaded at xkphys (0xa800....), but rather
> > > at ckseg0 (0xffffffff80...).
> >
> > Maybe I'm now talking complete bull since I don't have the manuals at hand
> > nor can find one at this time, but anyway ... Afair the TS bit in the
> > R10000
> > can never be set because on tlbwi / tlbwr the processor examines all
> > entries for a hit at the virtual address etc. of the new entry. If so,
> > these entries will be invalidated.
>
> >From the manual available online at
>
> http://www.sgi.com/processors/r10k/manual/t5.Ver.2.0.book_275.html
>
> It says that this bit is set when tlb is "presented" with an entry
> that is already present and may cause multiple matches. It also
> goes on to say those conflicting entries are invalidated before the
> new entry is inserted. What we dont know is whether TS is sticky.
> We dont know whether it gets cleared after the the r10k 'fixes'
> everything.
>From the hardcopy manual:
In the R10000 processor, the TS bit indicates that a tlb write has
introduced an entry that would allow matching of more than one virtual
page entry during translation. In this case, the TLB entries that
allow the multiple matches, even in the Wired area, are invalidated
before the new tlb entry is written. This prevents multiple matches
during translation. The TS bit is updated for each tlb write.
For now, I am clearing the TS bit on entry into the kernel, and things
aren't too crazy ... except I keep on wondering what is making the
TS get set, and whether it has any connection to me not being able
to talk to processors on other nodes (via prom routines).
Kanoj
>
> I will cc some more key folks.
>
> Steve/Mahdi,
> This is a thread from the linux on origin project. Could you please
> look at it and let us know what is the right interpretation.
>
> The kernel runs in ckseg0 space and TS gets set when the kernel
> is invoked. The kernel is launched from a prom which runs mapped.
>
> If you think TS must never be set, the linux kernel folks need to
> examine which code is causing dup entries.
>
> Thanks
> srinivasa
>
>
>
> >
> > Good night ...
> >
> > Ralf
> >
>
|