Bug 146575

Summary: xen interferes with X acceleration
Product: [Fedora] Fedora Reporter: Robin Green <greenrd>
Component: xenAssignee: Rik van Riel <riel>
Status: CLOSED RAWHIDE QA Contact:
Severity: medium Docs Contact:
Priority: medium    
Version: 3   
Target Milestone: ---   
Target Release: ---   
Hardware: i686   
OS: Linux   
Fixed In Version: 2.6.11-1.1174_FC4 Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2005-03-07 07:50:32 EST Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---
Description Flags
X log from when X acceleration is enabled none

Description Robin Green 2005-01-29 17:30:10 EST
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.5)
Gecko/20050128 Firefox/1.0

Description of problem:
When running fc3 under Xen, the X display became corrupted, so I had
to put Option "NoAccel" in my xorg.conf file. (Even *with* NoAccel,
some of the display occassionally gets displayed in inverse colours
temporarily, but I don't know if that's a firefox bug, an X server
bug, or something caused by xen.) X logfile attached.

I had had no X display problems (apart from some snow) before running Xen.

Version-Release number of selected component (if applicable):

How reproducible:

Steps to Reproduce:
1. Boot fc3 under Xen
2. Start firefox and scroll around a bit

Actual Results:  Display corruption

Expected Results:  No display corruption

Additional info:
I keep getting
mtrr: reg: 2 has count=0
in dmesg, which I did not used to get before.
Comment 1 Robin Green 2005-01-29 17:31:38 EST
Created attachment 110401 [details]
X log from when X acceleration is enabled
Comment 2 Robin Green 2005-01-30 06:50:32 EST
I now believe this is a more general memory corruption bug, not
specific to X.


1. Frequent crashes and hangs, contrary to before running Xen. Kate,
the KDE text editor, hanged once while typing, and when I restarted it
and reopened the same (tiny, plain text) file, it immediately hanged

2. Diverse types of rendering corruption occur *very* frequently, even
when X acceleration is disabled (and confirmed as disabled in the Xorg
log file). When _not_ running Xen, no rendering corruption is seen no
matter whether NoAccel is on or off.

I ran the test at http://www.greenrd.org/sw/memtest.html for an hour
or so, but it didn't find any errors. Perhaps because it uses tar, it
is not exercising memory allocation in a very "interesting" way -
perhaps I need a test with more dynamic memory allocation, or shared
memory allocation. I will try building a kernel and see if I get any
bogus errors.
Comment 3 Robin Green 2005-01-30 06:55:02 EST
Oh and also, different parts of the UI frequently stop working
temporarily. Firefox widgets like the URL bar, the bookmarks toolbar,
even the page rendering area, sometimes temporarily stop rendering
and/or accepting input.

Also the KDE taskbar frequently becomes empty and then reappears,
sometimes mis-rendered.

More evidence of memory corruption?
Comment 4 Robin Green 2005-02-17 14:50:30 EST
I posted a workaround to a floating-point bug to the xen-devel list; that
workaround turns out to solve this problem. The workaround patch (against the
xen-patched kernel) can be shortened to the patch below. (Note that
queue_multicall0(__HYPERVISOR_fpu_taskswitch) is supposed to have exactly the
same effect as stts(), so it should be simplifiable even further.)

--- arch/xen/i386/kernel/process.c.orig 2005-02-12 03:39:44.000000000 +0000
+++ arch/xen/i386/kernel/process.c      2005-02-13 02:46:03.000000000 +0000
@@ -563,6 +563,8 @@
        if (prev_p->thread_info->status & TS_USEDFPU) {
+       } else {
+               stts ();

Comment 5 Rik van Riel 2005-02-23 16:53:25 EST
Does the bug still happen with the current Xen RPMs ?
Comment 6 Robin Green 2005-03-05 15:32:39 EST
No, it doesn't. Well, almost... it doesn't happen unless the app is being
ptraced by gdb.
Comment 7 Robin Green 2005-03-05 16:21:12 EST
oops - resetting component back to xen.
Comment 8 Robin Green 2005-03-07 07:50:32 EST
With that typo fix that I emailed you applied, the bug is entirely fixed.