Re: after the kernel seems to live

[Ralf Baechle <ralf@uni-koblenz.de>]

On Thu, May 27, 1999 at 01:03:32PM -0700, Robert Keller wrote:

> At 12:18 PM 5/27/99 +0200, Ralf Baechle wrote:
> >What CPU is being used on that eval board?  If it's one that isn't yet
> >supported in our sources then I suspect you have a problem either with the
> >cacheflushing routines themselfes or the calls to them in the network
> >driver.  What NIC are you using, btw?  We've got patches around for a
> >couple of those which are most often being used with MIPS machines.
> 
> Its a VR5000 (D30500S2),  2.2.1 seems to recognize it as a
> type 24 (0x18).  Presently, I'm using a PCI 3c905 despite the
> fact that the eval board has a 21140 (albeit with a completely
> bogus SROM) built in to it.  I have my own patches to 3c59x.c
> tulip.c and even tlan.c to get them working to varying degrees.
> I'd still be interested in comparing my patches with the ones
> you have...

The R5000 is supported and known to work.  You happen to have a
second level cache on that board?

> How can I make sure that I'm not haveing cacheflushing problems?

Debugging :-)

In particular the ring structures are nasty, allocate them as uncached
memory in KSEG1.  In general the rule is that you should try to handle
as much in uncached memory as possible when debugging such problems.
That's of course very bad for performance but it helps.

> I'm presently using declinuxroot-990518.tgz from ftp.linux.sgi.com,
> so should I assume that it should just work?

Yes, it should.

  Ralf