Re: XFree 4.1
On Wed, Jan 08, 2003 at 08:53:21 +0100, Kars de Jong wrote:
> On Wed, 2003-01-08 at 13:45, Alan Hourihane wrote:
> > On Tue, Jan 07, 2003 at 11:31:45 +0100, Richard Zidlicky wrote:
> > > On Tue, Jan 07, 2003 at 09:04:35PM +0100, Gerhard Tubl wrote:
> > > > Hi!
> > > >
> > > > Well I read much stuff about xfree and it helps me a lot to get it run, but
> > > > not really.
> > > > When it starts it works fine (yes I have really installed KDE2 wow, real
> > > > slow, but it works..)
> > > >
> > > > I also read bout the problems on the xfree server 4.0 with the "Caught
> > > > signal 11. Server aborting" problem. And there is my problem:
> > > >
> > > > I have an A4000 with Cyberstorm MKII 68060 50MHz about 50MByte RAM and the
> > > > scsi module. The graphic card I used is the Retina Z3.
> > > > I also installed woody, and set up xfree from woody (config file see
> > > > attachment)
> > >
> > > module loading is still broken on 68060, missing cacheflush somewhere.
> > > Untill this can be fixed use the statically linked version of the
> > > X server which should be in the debuggibg package.
> >
> > If somecan can provide a user level mechanism of flushing the cache
> > on 060 then I'll add it to the XFree86 CVS.
>
> > It's already done on Alpha and PPC machines, so the place at which this
> > should be done is already in place.
>
> You have to use the cacheflush() syscall on m68k because the
> cacheflushing instructions are priviliged.
It's only the instruction cache we need to flush. Not the whole cache.
I notice in asm-m68k/pgalloc.h there's a specific flush_icache() macro
to do just that.
> Unfortunately it is not advisable to use the same method of cache
> flushing as is done for Alpha and PPC, because these flush the cache
> every time a relocation is done, which is extremely inefficient (several
> hundred if not more syscalls() for a single module, believe me, I tried
> and it's no fun).
There are only two relocations used in the loader for m68k at the moment,
and I doubt it's going to be a massive performance hit. But having a
working loader is a step in the right direction even if it is slower.
We can work out how to speed it up later.
Alan.
Reply to: