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
