Hide Forgot
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 problem. Reassigning to gnome-core.
This appears to be due to a bug in the kernel FP exception code for EV4 architecture.
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.