Red Hat Bugzilla – Bug 146575
xen interferes with X acceleration
Last modified: 2007-11-30 17:10:59 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.
Created attachment 110401 [details] X log from when X acceleration is enabled
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.
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?
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 (); } /*
Does the bug still happen with the current Xen RPMs ?
No, it doesn't. Well, almost... it doesn't happen unless the app is being ptraced by gdb.
oops - resetting component back to xen.
With that typo fix that I emailed you applied, the bug is entirely fixed.