From: Kevin B. Hendricks <hidden> Date: 2000-03-10 15:33:24
Hi,
So Xfree 4.0 final is out but without the very last minute cache flushing
changes Kostas made.
So we should probably get some official patch out there that includes a few
elements:
1. Either:
- user defined cache line size during compile
or:
- flush a cache range in address increments of 8
to handle the variable line cache size
2. And something to figure out if we are on a 601 machine in the
NuBus X100 machines to properly do a "sync or eieio" so that XFree86 4.0
cache flushing and synchronization for io has some chance of working under
MkLinux R1.
David can you tell me how the 601 problems with sync and eieio are
detected and handled in user space apps under MkLinux?
Thanks,
Kevin
** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/
Hi,
So Xfree 4.0 final is out but without the very last minute cache flushing
changes Kostas made.
So we should probably get some official patch out there that includes a few
elements:
What do you mean by official ? The next xfree86 update will have
this fix what more official do you suggest ?
1. Either:
- user defined cache line size during compile
or:
- flush a cache range in address increments of 8
to handle the variable line cache size
Glibc assumes a line size of 16 so that will be ok, in any
case the cache flush will be used only in the startup of the
xserver not need to worry about a few extra instructions there
so we can live even with 4byte increments, definitely better than
a compile time option.
2. And something to figure out if we are on a 601 machine in the
NuBus X100 machines to properly do a "sync or eieio" so that XFree86 4.0
cache flushing and synchronization for io has some chance of working under
MkLinux R1.
David can you tell me how the 601 problems with sync and eieio are
detected and handled in user space apps under MkLinux?
Hmm i don't think that xfree86 4.0 will work under mklinux, there
aren't any drivers that will work under mk anymore (xpmac is gone and
the vgahw/fbdev based ones won't work).
From: Kevin B. Hendricks <hidden> Date: 2000-03-10 18:17:30
Hi Kostas,
quoted
So we should probably get some official patch out there that includes a few
elements:
What do you mean by official ? The next xfree86 update will have
this fix what more official do you suggest ?
quoted
1. Either:
- user defined cache line size during compile
or:
- flush a cache range in address increments of 8
to handle the variable line cache size
I am confused. Now that XF 4.0 is out, will quick snapshots continue to be
released?
I just assumed that we would start getting incremental releases 4.0.1,
4.0.2 that would be long in coming (months or more...just like the 3.3.X
series). If snapshots will continue coming fast, then you are right. If
snapshots will not be coming (or minor updates will take a few months to
get working), then perhaps an official patch put on the www.linuxppc.org
site or something for Robert Shaw's page so that others who build XF 4.0
from source will have something to fix the cache problems with.
How about just a patch that fixes cache flushing for XFree 4.0 which
assumes cacke line sizes of 16 and ignores 601 problems then that we just
send to the linuxppc-dev mailing list so that it gets archived.
Glibc assumes a line size of 16 so that will be ok, in any
case the cache flush will be used only in the startup of the
xserver not need to worry about a few extra instructions there
so we can live even with 4byte increments, definitely better than
a compile time option.
Hmm i don't think that xfree86 4.0 will work under mklinux, there
aren't any drivers that will work under mk anymore (xpmac is gone and
the vgahw/fbdev based ones won't work).
Is this true? So we don't have to worry about 601 processors at all?
Thanks,
Kevin
** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/
From: Michael Schmitz <hidden> Date: 2000-03-10 19:21:26
Hi Kostas,
quoted
quoted
So we should probably get some official patch out there that includes a few
elements:
What do you mean by official ? The next xfree86 update will have
this fix what more official do you suggest ?
quoted
1. Either:
- user defined cache line size during compile
or:
- flush a cache range in address increments of 8
to handle the variable line cache size
I am confused. Now that XF 4.0 is out, will quick snapshots continue to be
released?
One would sure hope so. The 4.0 X server dies horribly during device
configuration on my Lombard. After feeding it a hand-crafted XF86Config,
it just hangs the machine.
Michael
** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/
From: Michel D�nzer <hidden> Date: 2000-03-10 23:54:37
Michael Schmitz wrote:
quoted
I am confused. Now that XF 4.0 is out, will quick snapshots continue to
be released?
One would sure hope so. The 4.0 X server dies horribly during device
configuration on my Lombard. After feeding it a hand-crafted XF86Config,
it just hangs the machine.
Which driver?
With the fbdev driver, you have to specify the bus ID of the graphics chip,
e.g.
BusID "0:1:0"
Michel
** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/
From: Michael Schmitz <hidden> Date: 2000-03-11 14:50:16
quoted
One would sure hope so. The 4.0 X server dies horribly during device
configuration on my Lombard. After feeding it a hand-crafted XF86Config,
it just hangs the machine.
Which driver?
With the fbdev driver, you have to specify the bus ID of the graphics chip,
e.g.
BusID "0:1:0"
I'll try that. But the results I get with X -probeonly are more than
confusing. After I tosses out most of the driver modules, the probe runs
once or twice, and gets sporadic SIGILL the rest of the time. To the
extent of not succeeding at all for the rest of the day. Or succeeding
only from the console but not from a slogin session (signal 4 in the
slogin session consistently). The signal happens apparently at different
times during X startup - while loading the dbe module, after loading the
fbdevhw module.
The chip was detected on the PCI bus - what's the BusID supposed to do in
this situation? Keep X from probing the other PCI devices?
OK, tried to feed it the BusID (0:17:0 as reported by the probe). Results:
a beep, and the warnings 'invalid mem allocation' and 'invalid IO
allocation'. The IO range smells like a port address range, is that
remapped by the PCI bridge? lspci reports the IO range as disabled. I'll
look into Geerts description of the Mach64 memory layout to figure out
what aperture X tries to use here.
Trying a 'startx' with this config leaves me with the bell on and the
machine hung.
I haven't patched or configured anything in the X source.
Michael
** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/
From: Michel D�nzer <hidden> Date: 2000-03-12 14:52:51
Michael Schmitz wrote:
I'll try that. But the results I get with X -probeonly are more than
confusing. After I tosses out most of the driver modules,
Which drivers? Only r128, fbdev and glint are known to be working on PPC
AFAIK.
the probe runs once or twice, and gets sporadic SIGILL the rest of the time.
To the extent of not succeeding at all for the rest of the day. Or
succeeding only from the console but not from a slogin session (signal 4 in
the slogin session consistently). The signal happens apparently at different
times during X startup - while loading the dbe module, after loading the
fbdevhw module.
This is a known bug in the server's cache flush code. There is a fix worked
out by Kostas Gewrgiou and Kevin Hendricks which unfortunately hasn't made it
into 4.0.
The chip was detected on the PCI bus - what's the BusID supposed to do in
this situation? Keep X from probing the other PCI devices?
OK, tried to feed it the BusID (0:17:0 as reported by the probe). Results:
a beep, and the warnings 'invalid mem allocation' and 'invalid IO
allocation'. The IO range smells like a port address range, is that
remapped by the PCI bridge? lspci reports the IO range as disabled. I'll
look into Geerts description of the Mach64 memory layout to figure out
what aperture X tries to use here.
Are you trying to use the driver for Mach64?
Try the fbdev driver with the BusID. (Mach is only minimally accelerated ATM
anyway)
Michel
** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/
From: David A. Gatwood <hidden> Date: 2000-03-10 19:43:59
On Fri, 10 Mar 2000, Kevin B. Hendricks wrote:
Hi,
So Xfree 4.0 final is out but without the very last minute cache flushing
changes Kostas made.
So we should probably get some official patch out there that includes a few
elements:
1. Either:
- user defined cache line size during compile
or:
- flush a cache range in address increments of 8
to handle the variable line cache size
2. And something to figure out if we are on a 601 machine in the
NuBus X100 machines to properly do a "sync or eieio" so that XFree86 4.0
cache flushing and synchronization for io has some chance of working under
MkLinux R1.
David can you tell me how the 601 problems with sync and eieio are
detected and handled in user space apps under MkLinux?
They aren't. User space apps don't ever flush the cache currently. In
kernel space, it does this:
#define eieio() __asm__ volatile("li 0,0; cmpwi 0,0; bne+ 0f;
eieio; 0:" : : : "0")
#define sync() __asm__ volatile("li 0,0; cmpwi 0,0; bne+ 0f;
sync; 0:" : : : "0")
David
** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/