From: Henry Worth <hidden> Date: 2002-07-08 21:53:21
Since rsyncing to Ben's 2.4.19-rc1-benh yesterday (and today), I have not
been able to build an SMP kernel with working XV. System is AGP dual
PowerMac
with 450MHz 7400's, Rage 128, XFree85 4.2.0 and YDL 2.2. Kernels built with
Ben's config and and minimal change for SMP (I've tried distributed and
non-distribured rupts). I had SMP and XV working with Xine from a Saturday
rsync, but not since rsync'ing yesterday or today (and I saved and tried
the same config that had worked). All builds are mrproper. It looks like
there have been some changes in some DRM and FB header files, but I didn't
save the previous version to diff against
XV will work with Xine when built as a non-SMP kernel, but an SMP kernel
will lock-up almost instantly after hitting the Xine play button with dual
processors and after a couple of seconds with a single CPU (maxcpus=1).
After lockup I can usually telnet in to reboot, but not always (usually
the screen blanks or loses sync in these cases). Haven't had any success
trying to kill and restart the X server as can usual be done with X server
hangs.
** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/
From: Michel Dänzer <hidden> Date: 2002-07-08 21:57:52
On Mon, 2002-07-08 at 23:53, Henry Worth wrote:
Since rsyncing to Ben's 2.4.19-rc1-benh yesterday (and today), I have not
been able to build an SMP kernel with working XV. System is AGP dual
PowerMac
with 450MHz 7400's, Rage 128, XFree85 4.2.0 and YDL 2.2. Kernels built with
Ben's config and and minimal change for SMP (I've tried distributed and
non-distribured rupts). I had SMP and XV working with Xine from a Saturday
rsync, but not since rsync'ing yesterday or today (and I saved and tried
the same config that had worked). All builds are mrproper. It looks like
there have been some changes in some DRM and FB header files, but I didn't
save the previous version to diff against
XV will work with Xine when built as a non-SMP kernel, but an SMP kernel
will lock-up almost instantly after hitting the Xine play button with dual
processors and after a couple of seconds with a single CPU (maxcpus=1).
After lockup I can usually telnet in to reboot, but not always (usually
the screen blanks or loses sync in these cases). Haven't had any success
trying to kill and restart the X server as can usual be done with X server
hangs.
Thanks for the quick response, disabling DRI works. I'll have to try
updating X, is that patch in the current CVS snapshot?
But now I get to drive myself nuts as to why it did work repeatedly with
Saturday's rsync. The X configuration hadn't changed and I'm pretty sure
the DRM modules were getting loaded... oh well.
** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/
I've had a chance to try 4.2.99 and this patch against 4_2-branch, both
synced to
CVS today, a few observations:
4_2-branch with patch:
_Xine plays fine with dri enabled with both 4.2.99 and patched 4_2-branch.
_With both server versions, glxgears will run concurrently with xine, with
great performance, for about 30 secs, and then will hang the X server.
_With 4.2.99 and dri enabled, glxgears does display correctly. Instead of
the gears, the window is filled with fragments of very large polygons
of the correct colors, moving in a vaguely circular, but still scrambled
pattern with many appearing to be the tips of the gear teeth.
Perhaps an endian problem? Works fine with dri disabled. Are there
any test programs available that exercise dri directly to isolate the
problem to libGL or DRI.
_Both the YDL installed 4.2 binaries and the patched 4_2-branch with DRI
enabled, the kdm login window is nearly unreadable. The subwindow
background has a cross-hatch, same as startup stipple, that blends with
the prompt and input field. Will sometimes clearup after a few VT
switches
or X restarts. Does not occur with DRI disabled or at all with 4.2.99.
This is on a dual 450MHz G4 AGP PMAC with YDL 2.2 and Rage 128 PF
in 24bpp mode:
** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/
From: Henry Worth <hidden> Date: 2002-07-11 18:27:14
Henry Worth wrote:
_With 4.2.99 and dri enabled, glxgears does display correctly. Instead of
the gears, the window is filled with fragments of very large polygons
of the correct colors, moving in a vaguely circular, but still
scrambled
pattern with many appearing to be the tips of the gear teeth.
Opps, that should be that glxgears does >not< display correclty.
** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/
I've had a chance to try 4.2.99 and this patch against 4_2-branch, both
synced to CVS today, a few observations:
4_2-branch with patch:
_Xine plays fine with dri enabled with both 4.2.99 and patched 4_2-branch.
I think the patch has been applied on the trunk.
_With both server versions, glxgears will run concurrently with xine, with
great performance, for about 30 secs, and then will hang the X server.
If this is with agpgart, try without.
_With 4.2.99 and dri enabled, glxgears does display correctly. Instead of
the gears, the window is filled with fragments of very large polygons
of the correct colors, moving in a vaguely circular, but still scrambled
pattern with many appearing to be the tips of the gear teeth.
Perhaps an endian problem? Works fine with dri disabled. Are there
any test programs available that exercise dri directly to isolate the
problem to libGL or DRI.
If you want to work on DRI, you should get the DRI CVS, which is broken
differently and will be merged into XFree86 for 4.3.0. The driver is
broken since it's been updated for Mesa 4.0.x, and I don't have hardware
to test and fix it anymore.
_Both the YDL installed 4.2 binaries and the patched 4_2-branch with DRI
enabled, the kdm login window is nearly unreadable. The subwindow
background has a cross-hatch, same as startup stipple, that blends with
the prompt and input field. Will sometimes clearup after a few VT
switches or X restarts. Does not occur with DRI disabled or at all with 4.2.99.
If this only happens on server reset,
http://www.penguinppc.org/~daenzer/XFree86-4.2/patches/r128-indirectBuffer.diff should help. This is also on the CVS trunk already, and the radeon driver has been fixed even better in DRI CVS.
--
Earthling Michel Dänzer (MrCooper)/ Debian GNU/Linux (powerpc) developer
XFree86 and DRI project member / CS student, Free Software enthusiast
** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/
From: Henry Worth <hidden> Date: 2002-07-11 23:13:22
Michel Dänzer wrote:
quoted
_Both the YDL installed 4.2 binaries and the patched 4_2-branch with DRI
enabled, the kdm login window is nearly unreadable. The subwindow
background has a cross-hatch, same as startup stipple, that blends with
the prompt and input field. Will sometimes clearup after a few VT
switches or X restarts. Does not occur with DRI disabled or at all with 4.2.99.
Thanks, that patch fixes the problem.
And, forcing PCI mode allows concurrent DRI and Xv. I've had my system
loaded up continuusly to 99+% with makes, ping floods, Xv xine, and
DRI enabled glxgears for an hour, and could still startup Mozilla and
compose this.
** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/
From: Michel Dänzer <hidden> Date: 2002-07-13 09:26:41
On Fri, 2002-07-12 at 01:13, Henry Worth wrote:
Michel Dänzer wrote:
quoted
quoted
_Both the YDL installed 4.2 binaries and the patched 4_2-branch with DRI
enabled, the kdm login window is nearly unreadable. The subwindow
background has a cross-hatch, same as startup stipple, that blends with
the prompt and input field. Will sometimes clearup after a few VT
switches or X restarts. Does not occur with DRI disabled or at all with 4.2.99.
Thanks, that patch fixes the problem.
And, forcing PCI mode allows concurrent DRI and Xv. I've had my system
loaded up continuusly to 99+% with makes, ping floods, Xv xine, and
DRI enabled glxgears for an hour, and could still startup Mozilla and
compose this.
Great, I assume that's with the optiondmaforxv patch though. Without it
or with Option "DMAForXv" you will likely be able to provole lockups
with this combination.
--
Earthling Michel Dänzer (MrCooper)/ Debian GNU/Linux (powerpc) developer
XFree86 and DRI project member / CS student, Free Software enthusiast
** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/