Bug 146575 - xen interferes with X acceleration
xen interferes with X acceleration
Status: CLOSED RAWHIDE
Product: Fedora
Classification: Fedora
Component: xen (Show other bugs)
3
i686 Linux
medium Severity medium
: ---
: ---
Assigned To: Rik van Riel
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2005-01-29 17:30 EST by Robin Green
Modified: 2007-11-30 17:10 EST (History)
0 users

See Also:
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: ---


Attachments (Terms of Use)
X log from when X acceleration is enabled (36.96 KB, text/plain)
2005-01-29 17:31 EST, Robin Green
no flags Details

  None (edit)
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):
xen-2-20050124

How reproducible:
Always

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.

Evidence:

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
again!

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) {
                save_init_fpu(prev_p);
                queue_multicall0(__HYPERVISOR_fpu_taskswitch);
+       } 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.

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