Bug 87523 - text corruption when switching from X11 to VT1
text corruption when switching from X11 to VT1
Status: CLOSED NOTABUG
Product: Red Hat Linux
Classification: Retired
Component: XFree86 (Show other bugs)
9
All Linux
medium Severity medium
: ---
: ---
Assigned To: Mike A. Harris
David Lawrence
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2003-03-28 06:48 EST by David Balažic
Modified: 2007-04-18 12:52 EDT (History)
1 user (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2003-04-12 13:29:41 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
My XF86Config file (3.12 KB, text/plain)
2003-03-28 06:52 EST, David Balažic
no flags Details
XFree86.0.log file , when the corruption happened (61.61 KB, text/plain)
2003-03-28 06:53 EST, David Balažic
no flags Details
another XFree86.0.log file ( another boot ), when the corruption happened again (61.61 KB, text/plain)
2003-03-28 06:54 EST, David Balažic
no flags Details
XFree86.0.log file , when the corruption did not happen (61.85 KB, text/plain)
2003-03-28 06:55 EST, David Balažic
no flags Details
another XFree86.0.log file , when the corruption did not happen (61.73 KB, text/plain)
2003-03-28 06:55 EST, David Balažic
no flags Details

  None (edit)
Description David Balažic 2003-03-28 06:48:57 EST
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:
Comment 1 David Balažic 2003-03-28 06:52:31 EST
Created attachment 90759 [details]
My XF86Config file
Comment 2 David Balažic 2003-03-28 06:53:43 EST
Created attachment 90760 [details]
XFree86.0.log file , when the corruption happened
Comment 3 David Balažic 2003-03-28 06:54:39 EST
Created attachment 90761 [details]
another XFree86.0.log file ( another boot ), when the corruption happened again
Comment 4 David Balažic 2003-03-28 06:55:09 EST
Created attachment 90762 [details]
XFree86.0.log file , when the corruption did not happen
Comment 5 David Balažic 2003-03-28 06:55:31 EST
Created attachment 90763 [details]
another XFree86.0.log file , when the corruption did not happen
Comment 6 Mike A. Harris 2003-04-12 13:29:41 EDT
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.


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