Bug 568 - XFree86-3DLabs-3.3.3-1.i386 is slow, affects system clock.
XFree86-3DLabs-3.3.3-1.i386 is slow, affects system clock.
Status: CLOSED CURRENTRELEASE
Product: Red Hat Linux
Classification: Retired
Component: XFree86 (Show other bugs)
5.2
i386 Linux
medium Severity medium
: ---
: ---
Assigned To: Preston Brown
:
: 713 (view as bug list)
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 1998-12-22 21:19 EST by youngej
Modified: 2015-10-20 15:22 EDT (History)
0 users

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 1999-01-18 17:03:28 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description youngej 1998-12-22 21:19:48 EST
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-3.3.2.3-18 and XSuSE's
xglint driver:
  XSuSE_Elsa_GLoria
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:
xc/programs/Xserver/hw/xfree86/accel/glint/glint_regs.h

There's a macro there which looks like this:

#define GLINT_SLOW_READ_REG(r) \
        ( outb(80,0),*(unsigned int
*)((char*)GLINTMMIOBase+r))


This is wrong. It should be:

#define GLINT_SLOW_READ_REG(r) \
        ( outb(0x80,0),*(unsigned int
*)((char*)GLINTMMIOBase+r))


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?

 -Bill"
Comment 1 David Lawrence 1998-12-29 18:10:59 EST
This report has been assigned to a developer for further review.
Comment 2 Bert de Bruijn 1999-01-04 16:16:59 EST
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
takes).
Comment 3 Cord Kielhorn 1999-01-11 09:50:59 EST
In the description of this bug youngej@magpage.com 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
bugzilla@redhat.com).
2. In rawhides XFree86-3.3.3-10 rpm the patch is missing completely.
Comment 4 Preston Brown 1999-01-11 14:02:59 EST
*** 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
SCSI-Adapter


------- Additional Comments From dkl@redhat.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 ayn2@cornell.edu  01/07/99 02:39 -------
This is a duplicate of #568
Comment 5 Preston Brown 1999-01-18 17:03:59 EST
This is fixed in a forthcoming errata release of XFree86 3.3.3.1.
Comment 6 openshift-github-bot 2015-10-20 15:22:10 EDT
Commit pushed to master at https://github.com/openshift/openshift-docs

https://github.com/openshift/openshift-docs/commit/1c5ffcedfacaf800eae37f1b6674f5d19263a58f
Merge pull request #1069 from tpoitras/github-issue-568-sticky

added note re: sticky sessions [issue 568]

Note You need to log in before you can comment on or make changes to this bug.