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>]
next prev parent 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