After a clean install of RH6.2 on an alpha, there is a X problem of some
sort. When running Xconfigurator at the point where it tests the
configuration, X comes up, and the dialog box which normally ask if the
display is satisfactory comes up, but it is completely blank! There are no
buttons and no text. It does produce an XF86Config file, but starting X has
the same problem - Gnome comes up, but there is no text, all the windows
are blank. I am not sure whether the problem is with the generated
XF86Config, or with xfs. However, if I transfer a working XF86Config file
from an identical machine running 6.1, the same problem occurs.
This is a seriously weird bug. Since I have a working 6.1 system with same mobo
and video (UDB/TGA), I downgraded all the XFree86 rpms to the versions on the
6.1 CD. Found and fixed all the .rpmnew files, and restarted xfs. Tryed
Xconfigurator, but it wouldn't produce a valid configuration (this happened also
on 6.1 IIRC). Grabbed XF86Config off the working 6.1 system. This works, but
once again X/Gnome comes up with blank dialog boxes and file manager windows.
I think the problem must be in whatever widget library Gnome and XTest use, or
in a font (I have them all installed, but didn't back them off to the 6.1
versions). Interestingly enough, the little enlightenment popup help boxes DO
come up and DO have text in them.
I will keep this bug updated as I discover more.
This appears to be a Gnome bug, not an X bug. I tried running Gnome apps on the
working 6.1 systems display. Gnorpm did not come up at all. Gcalc came up, but
was blank. I tried KDE apps, and they worked just fine. So I went back to the
original system and set /etc/sysconfig/desktop to KDE and did a telinit 5. KDM
came up just fine. I had tried this previously with GDM, but had the blank panel
Reassigning to gnome-core.
This appears to be due to a bug in the kernel FP exception code for EV4
I have also discovered this bug, and have tracked it to something even wierder.
If you boot from the SRM, the problem shows itself. However, if you boot from
MILO, the problem goes away.
I am currently compiling the FP kernel exception patch to see if that helps.
But in the mean time, it is an interesting note to find that booting from MILO
will cause this problem to go away.
I don't have access to an ev4 box, can't help on this.