linux-mips-fnet
[Top] [All Lists]

Re: One good and some bad news

To: Thomas Bogendoerfer <tsbogend@alpha.franken.de>
Subject: Re: One good and some bad news
From: ralf@uni-koblenz.de
Date: Mon, 13 Jul 1998 02:36:06 +0200
Cc: linux-mips@fnet.fr, linux@cthulhu.engr.sgi.com
In-reply-to: <19980712235319.65470@alpha.franken.de>; from Thomas Bogendoerfer on Sun, Jul 12, 1998 at 11:53:19PM +0200
References: <19980712112949.25350@alpha.franken.de> <19980712190135.R10756@uni-koblenz.de> <19980712235319.65470@alpha.franken.de>
On Sun, Jul 12, 1998 at 11:53:19PM +0200, Thomas Bogendoerfer wrote:

> no, that's the one I've built:-) But it's made with your XFree patch
> and an updated .spec file for the latest RH5.1 package (XFree86-3.3.2-13).
> A couple of hours ago, I had X with window manager and application running
> (PS/2 mouse works, too). There is only one small problem left, when scrolling
> the X screen down. Looks like my "hardware" scrolling has some problems
> with graphics.

Cool.

> > DBE has a nasty property, it can be delayed until some write access
> > is written back from cache to memory.  The EPC then often points to
> > completly useless addresses.
> 
> good to know, as the address was really bogus. Is there a chance to
> print out the faulting physical address for a bus error ? This would
> give us some chances to find the real culprit. But it still hasn't happen
> again.

Basically what to do would be to modify the kernel such that it will work
with caches disabled.  Then you get (almost) precise exceptions again.
Alternative and with less impact on the performance you could try to
writeback the caches in strategic positions for debugging.  That makes a
kind of a barrier for DBE exceptions.

> hmm, I've checked the MAP_NR() in the kernel, and couldn't find such
> cases. In fact my changed kernel works perfect.

Good.  Long time ago we had such cases in the kernel; it's why MAP_NR
does things the way it does.  But I admit, when I wrote my last posting
I could recall what I needed that stuff for.

You patch looks good, could you commit it?  Thanks.

> > These type of warning messae often indicate serious trouble.
> 
> hmm, the produced binaries are working without problem.

Hmmm ...  Modify write(2) to not print these messages ;-)

  Ralf

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