Linux MIPS Architecture development
 help / color / mirror / Atom feed
From: Thomas Bogendoerfer <tsbogend@alpha.franken.de>
To: ralf@uni-koblenz.de
Cc: linux-mips@fnet.fr, linux@cthulhu.engr.sgi.com
Subject: Re: One good and some bad news
Date: Sun, 12 Jul 1998 23:53:19 +0200	[thread overview]
Message-ID: <19980712235319.65470@alpha.franken.de> (raw)
In-Reply-To: <19980712190135.R10756@uni-koblenz.de>; from ralf@uni-koblenz.de on Sun, Jul 12, 1998 at 07:01:35PM +0200

On Sun, Jul 12, 1998 at 07:01:35PM +0200, ralf@uni-koblenz.de wrote:
> On Sun, Jul 12, 1998 at 11:29:49AM +0200, Thomas Bogendoerfer wrote:
> 
> > first the good news: 
> > 
> > Yesterday XF68_FBDev showed the first ugly gray X11 screen on my 
> > Olivetti M700. Yeah !
> 
> Does this mean the X Server which I've built is running without
> changes?

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.

> 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.

> Some places in the kernel also pass uncached addresses to MAP_NR().  In
> order to make that work right I decieded back in '94 to mask out everything
> but the bits that might be set in the physical address corrosponding to a
> KSEG0 address.

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

> The Olli case is somewhat special because the designers had the gorgeuous
> idea of placing some peripherals outside the lowest 4gb therefore more
> fun with EISA mappings for example ahead ...

I know. 

> These type of warning messae often indicate serious trouble.

hmm, the produced binaries are working without problem.

Thomas.

-- 
See, you not only have to be a good coder to create a system like Linux,
you have to be a sneaky bastard too ;-)
                   [Linus Torvalds in <4rikft$7g5@linux.cs.Helsinki.FI>]

  reply	other threads:[~1998-07-12 21:57 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
1998-07-12  9:29 One good and some bad news Thomas Bogendoerfer
1998-07-12 17:01 ` ralf
1998-07-12 21:53   ` Thomas Bogendoerfer [this message]
1998-07-13  0:36     ` ralf
1998-07-13 22:08       ` Thomas Bogendoerfer
1998-07-12 18:55 ` Thomas Bogendoerfer

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=19980712235319.65470@alpha.franken.de \
    --to=tsbogend@alpha.franken.de \
    --cc=linux-mips@fnet.fr \
    --cc=linux@cthulhu.engr.sgi.com \
    --cc=ralf@uni-koblenz.de \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox