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"
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 takes).
In the description of this bug youngej 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). 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 SCSI-Adapter ------- Additional Comments From dkl 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 01/07/99 02:39 ------- This is a duplicate of #568
This is fixed in a forthcoming errata release of XFree86 3.3.3.1.
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]