+++ This bug was initially created as a clone of Bug #370341 +++ +++ 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): How reproducible: 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 Actual results: 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. Expected results: The SDL window should remain present every time a paravirt guest is started. Additional info: Looks similar to bz# 217635 -- Additional comment from berrange 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 pm-rhel 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 release. -- Additional comment from armbru on 2007-11-07 16:22 EST -- Created an attachment (id=250871) 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. ------------------------------------------------------------------------------ Since the RHEL-4 fbfront stuff is based on the RHEL-5 stuff, I'm pretty sure it has the same bug. Cloning.
Created attachment 250951 [details] Copy of dirty patch from the RHEL-5.1 BZ
Set dev ack for Chris Lalancette.
Duh. I should have looked at the RHEL-4 code before I opened this bug. It seems that I based RHEL-4 on a slightly newer version of the xenfb stuff than what was in RHEL-5, and it already has this fix. Closing this as NOTABUG. Chris Lalancette
Clearing out bogus flag for reporting purposes. Chris Lalancette