Description of problem: switch from X11(VT7) to VT1 -> all corrupted screen ( font is probably corrupted). Log in blindly, it's fixed. Probably by the font setting in the login script. Does not happen always. On some boots it never happens. On other boots, it happens on every switch. It started corrupting once after I did ctrl-alt-backspace on the X login screen ( it had no corruption s before that ). So in case when it happens, the text is corrupted each time I switch from X to text mode. All the textual VTs are corrupted. Switching back to X is OK ( X has no picture corruptions ) switch back to text : corruption. After fixed by logging in on text VT and going to X and back to text , it is again corrupted. I captured the XFree86.0.log file to see differences between corrupting and non-corrupting mode, and discovered : corruption ( the same log contents on two differetn occasions ) : [ point X in the log , text until here deleted , the following lines are the end of the log file ] (II) XINPUT: Adding extended input device "DevInputMice" (type: MOUSE) (II) XINPUT: Adding extended input device "Mouse0" (type: MOUSE) (II) Mouse0: ps2EnableDataReporting: succeeded (II) DevInputMice: ps2EnableDataReporting: succeeded (II) Open APM successful (II) DevInputMice: ps2EnableDataReporting: succeeded (II) Mouse0: ps2EnableDataReporting: succeeded AUDIT: Thu Mar 27 20:18:38 2003: 3399 X: client 5 rejected from local host no corruption : [ point X - until here , the same contents as in corruption case log above ] [ here are the same (II) lines as shown above, minus the AUDIT line, followed by these additional lines ] (II) Open APM successful (II) DevInputMice: ps2EnableDataReporting: succeeded (II) Mouse0: ps2EnableDataReporting: succeeded AUDIT: Thu Mar 27 20:55:09 2003: 3398 X: client 5 rejected from local host (II) Open APM successful (II) DevInputMice: ps2EnableDataReporting: succeeded (II) Mouse0: ps2EnableDataReporting: succeeded another case of no corruption ( different boot ) : [ point X - until here , the same contents as in corruption case log above ] (II) XINPUT: Adding extended input device "DevInputMice" (type: MOUSE) (II) XINPUT: Adding extended input device "Mouse0" (type: MOUSE) (II) Mouse0: ps2EnableDataReporting: succeeded (II) DevInputMice: ps2EnableDataReporting: succeeded (II) DevInputMice: ps2EnableDataReporting: succeeded (II) Open APM successful (II) Mouse0: ps2EnableDataReporting: succeeded AUDIT: Thu Mar 27 20:33:28 2003: 3399 X: client 5 rejected from local host (II) Open APM successful (II) DevInputMice: ps2EnableDataReporting: succeeded (II) Mouse0: ps2EnableDataReporting: succeeded So the only difference are the additional "ps2EnableDataReporting" lines. Hardware info : Gigabyte GA-7VAXP Ultra mainboard ( VIA KT400, VIA 8235 ) Hercules 3D Prophet 4500 AGP 32 MB gfx card ( PowerVR Kyro II chipset ) See attached XF86Config and 4 complete log files. The log files are from different boots, 2 in case with no corruption occuring and 2 with corruption. Version-Release number of selected component (if applicable): RHL9 ( Shrike ) XFree86-4.3.0-2.i386.rpm How reproducible: On some boots it happens, on some not. I didn't discover yet what causes the difference. Steps to Reproduce: 1. boot ( default init level is 5 ) 2. switch to VT1 3. Actual results: Corrupted textual screen Expected results: no corruption Additional info:
Created attachment 90759 [details] My XF86Config file
Created attachment 90760 [details] XFree86.0.log file , when the corruption happened
Created attachment 90761 [details] another XFree86.0.log file ( another boot ), when the corruption happened again
Created attachment 90762 [details] XFree86.0.log file , when the corruption did not happen
Created attachment 90763 [details] another XFree86.0.log file , when the corruption did not happen
The PowerVR Kyro hardware is unsupported by Red Hat as there is no open source native driver for it. The "vesa" driver which you are using, uses the video card BIOS VBE routines to set up video modes and control the display. Problems with VT switching when using the "vesa" driver, are almost certainly due to bugs in the video card BIOS itself, or in the kernel console locking code. In the case of the kernel, it would generally occur with all video hardware and be a commonly reported problem. Whereas in the BIOS case it would likely due to the BIOS not saving and/or restoring video registers properly. This would thus not be an XFree86 bug, and not fixable. If it were a vesa driver bug, which is very unlikely, it should be easily reproduceable on any video card using the "vesa" driver, however I can't reproduce it on several cards I just tested locally, including a Kyro II made by VideoLogic. That is probably indicative more of a bug in your card's BIOS which is not present in BIOS of the card I have. Here are 2 suggestions to work around this problem: 1) Try using kernel framebuffer support or 2) Try using PowerVR's binary only driver (unsupported) Hope this helps.