Red Hat Bugzilla – Bug 370341
PVFB frontend can send bogus screen updates
Last modified: 2009-04-17 05:10:17 EDT
+++ This bug was initially created as a clone of Bug #368931 +++
Description of problem:
When using 'xm create' to start a paravirt guest, the SDL window often
disappears part way through the boot.
Version-Release number of selected component (if applicable):
Steps to Reproduce:
1. Configure a pv guest to use SDL graphics
2. xm create <pv guest>
3. wait for the guest to boot all the way up
I've seen the SDL window disappear on both i386 and ia64 about 20% of the time.
I see nothing suspicious in xend.log. There is no output to xend-debug.log.
The SDL window should remain present every time a paravirt guest is started.
Looks similar to bz# 217635
-- Additional comment from firstname.lastname@example.org on 2007-11-07 10:52 EST --
Co-incidentally yesterday i discovered a potential bug in the guest kernel PVFB
driver. It occassionally sends a framebuffer update event to the Dom0 with a x,y
of MAX_INT, MAX_INT, and a width+height of -MAX_INT, -MAX_INT. When SDL then
tries to process this update event it gets an BadValue error from Xorg and
quits. In my tests against xen-unstable this happened on as many as 30% of all
bootup attempts with SDL, so I think its reasonably likely this is the same
problem you're describing. The VNC display doesn't seem to be affected, since
its update routine does region clipping.
-- Additional comment from email@example.com on 2007-11-07 10:54 EST --
This request was evaluated by Red Hat Product Management for inclusion in a Red
Hat Enterprise Linux maintenance release. Product Management has requested
further review of this request by Red Hat Engineering, for potential
inclusion in a Red Hat Enterprise Linux Update release for currently deployed
products. This request is not yet committed for inclusion in an Update
Created attachment 250871 [details]
Fix tracking of screen dirtiness
The PVFB front end can get confused and send a bogus screen update to the back
end when the screen is clean.
Proposed fix is now upstram, cset 311:ca05cf1a9bdc.
You can download this test kernel from http://people.redhat.com/dzickus/el5
An advisory has been issued which should help the problem
described in this bug report. This report is therefore being
closed with a resolution of ERRATA. For more information
on the solution and/or where to find the updated files,
please follow the link below. You may reopen this bug report
if the solution does not work for you.