[Top] [All Lists]

Re: after the kernel seems to live

To: Robert Keller <>
Subject: Re: after the kernel seems to live
From: Ralf Baechle <>
Date: Fri, 28 May 1999 00:46:32 +0200
In-reply-to: <4.1.19990527124423.00930cd0@mail>; from Robert Keller on Thu, May 27, 1999 at 01:03:32PM -0700
References: <4.1.19990526115716.03f65930@mail> <4.1.19990526115716.03f65930@mail> <> <4.1.19990527124423.00930cd0@mail>
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,
> so should I assume that it should just work?

Yes, it should.


<Prev in Thread] Current Thread [Next in Thread>