Red Hat Bugzilla – Bug 568
XFree86-3DLabs-3.3.3-1.i386 is slow, affects system clock.
Last modified: 2015-10-20 15:22:10 EDT
I recently upgraded to XFree86-3.3.3-1.i386 and used the new
3DLabs driver. There seems to be a delay of several seconds
with every X action (except rendering text which was fast).
Also X took a long time to start and stop. And my system
clock was changed! I had to reset it several hours. It
changed very slowly over the time X was used (minutes were
several minutes long). The picture worked, it was stable
but slightly "jaggy".
I experimented with many of the XF86Config settings without
positive affect. I had also completely deinstalled (rpm
-e) the XSuSE driver. There was no chance of conflict.
My conclusions are that there is a bug in the 3DLabs driver.
I have a Gateway 2000, 300MHz Pentium II computer:
video card: AccelStar Permedia II 2 AGP
monitor: 17" Vivitron
I had to revert back to XFree86-18.104.22.168-18 and XSuSE's
this combination works extremely well.
I looked up the problem on www.dejanews.com - got one lead
quoted below. I am not in a position to test this solution:
"I have since learned the cause of the problem with the
3DLabs X server, though I don't understand exactly what the
problem is. Luckily for us, XFree86 3.3.3 just came out, and
it has the source code for the 3DLabs server. The bug
responsible for the system slowdown has since been found.
Somebody made a mind-o in:
There's a macro there which looks like this:
#define GLINT_SLOW_READ_REG(r) \
( outb(80,0),*(unsigned int
This is wrong. It should be:
#define GLINT_SLOW_READ_REG(r) \
( outb(0x80,0),*(unsigned int
Notice the difference: the wrong macro does an outb to port
80 instead of 0x80. However, I don't know what's supposed to
be at I/O port 80 (0x50). Whatever it is, this is
definitely the cause of the problem: I just built a complete
XFree86 3.3.3 kit with this bug patched and the 3DLabs
serverworks perfectly now.
Any idea what this I/O port does and why it would cause the
system to slow down like it did?
This report has been assigned to a developer for further review.
still a problem in XFree86-3DLabs-3.3.3-10.i386 (from rawhide).
I ended up running a
while (exit 0); do sleep 1; ntpdate -s ntpserver; done
To set the correct time every 5.5 seconds (that's how long the sleep 1
In the description of this bug firstname.lastname@example.org mentioned a patch
to the XFree86-3.3.3 glint server. This patch works for me, the server
now works as expected.
I have some comments on the Redhat XFree86-3.3.3 rpms:
1. The XFree86-3.3.3-1 rpm already contained the patch, but it was not
correctly applied owing to a bug in the spec file (I mailed a patch to
2. In rawhides XFree86-3.3.3-10 rpm the patch is missing completely.
*** Bug 568 has been marked as a duplicate of this bug. ***
After starting XF86_3DLabs (XFree86-3DLabs-3.3.3-1) the
system clock is slowed down by a factor of approx. 5.
Terminating the X-Server doesn't stop this behaviour.
My System: Intel Pentium MMX 200, Asus TXP4, 64MB SDRAM,
Dataexpert DPM6020 graphics device (PCI), Asus SC875
------- Additional Comments From email@example.com 01/06/99 17:42 -------
I have verified this bug in the test lab to be true. After starting
the X server and loading and moving apps around the screen, the date
command reports incorrect times. It seems to cause the clock to run
slow. I have assigned this to a developer for review.
------- Additional Comments From firstname.lastname@example.org 01/07/99 02:39 -------
This is a duplicate of #568
This is fixed in a forthcoming errata release of XFree86 22.214.171.124.
Commit pushed to master at https://github.com/openshift/openshift-docs
Merge pull request #1069 from tpoitras/github-issue-568-sticky
added note re: sticky sessions [issue 568]