On Mon, 27 Jun 2005, Markus Dahms wrote:
> > Hmm, it might be a problem with TLB handlers that have been changed to be
> > built at the run time. Perhaps the R4600 isn't handled right as a result.
> > What's the CPU revision ID? -- it's printed right at the beginning.
>
> | CPU revision is: 00002020
> | FPU revision is: 00002020
That's what I'm interested in -- the R4600 is fancy enough they've
implemented different quirks with different revisions. ;-)
> | Synthesized TLB refill handler (30 instructions).
> | Synthesized TLB load handler fastpath (43 instructions).
> | Synthesized TLB store handler fastpath (43 instructions).
> | Synthesized TLB modify handler fastpath (42 instructions).
>
> the TLB stuff, if it's of interest...
I might ask about more detailed dumps of these, but for now I'll just
check the sources for obvious problems.
> | ...
> | Calibrating system timer... warning: timer counts differ, retrying...\
> | disagreement, using average... 44500 [89.0000 MHz CPU]
> | Using 44.500 MHz high precision timer.
>
> this is strange, too. It's a 133MHz CPU as kernel 2.4.x correctly
> recognizes.
>
> For the R4000 there are two other things I could try: console on newport
> instead of serial port and a 32-bit kernel, which I only tried on the
> R4600.
Well, I don't know what newport is, but if it's capable of providing
output that early, it'll do.
> I'll also try the said patch (you're referring to "blast_scache nop ...", do
> you?).
Precisely.
Maciej
|