HVM domU with sdl not scheduled after vt-switch

HVM domU with sdl not scheduled after vt-switch

[Dietmar Hahn]

[-- Attachment #1.1: Type: text/plain, Size: 588 bytes --]

Hi,

I tried a Windows domU with sdl switched on and when I switch in dom0 to
another virtual console (the ctrl-alt-f? thing) the Windows domU loses its cpu.

# xm list
Name                                        ID   Mem VCPUs      State   Time(s)
myWindows                                    6  1024     1     ------     73.5

The domU gets scheduled again after switching back to the virtual screen.
This is not the case when using vnc.
What is the cause and where in the source can I find the implementation?
Thanks!

Dietmar.

-- 
Company details: http://ts.fujitsu.com/imprint.html

[-- Attachment #1.2: Type: text/html, Size: 3602 bytes --]

[-- Attachment #2: Type: text/plain, Size: 138 bytes --]

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

Re: HVM domU with sdl not scheduled after vt-switch

[George Dunlap]

Hmm, I bet qemu has crashed -- do a "ps ax | grep qemu" and see if
it's still running.

If you're keen, you could run gdb on the core file and see where it's
crashing. If there's no corefile, do probably need to do "ulimit -c
unlimited" first.

 -George

On Wed, Apr 27, 2011 at 12:27 PM, Dietmar Hahn
<dietmar.hahn@ts.fujitsu.com> wrote:
> Hi,
>
> I tried a Windows domU with sdl switched on and when I switch in dom0 to
>
> another virtual console (the ctrl-alt-f? thing) the Windows domU loses its
> cpu.
>
> # xm list
>
> Name ID Mem VCPUs State Time(s)
>
> myWindows 6 1024 1 ------ 73.5
>
> The domU gets scheduled again after switching back to the virtual screen.
>
> This is not the case when using vnc.
>
> What is the cause and where in the source can I find the implementation?
>
> Thanks!
>
> Dietmar.
>
> --
>
> Company details: http://ts.fujitsu.com/imprint.html
>
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/xen-devel
>
>

Re: HVM domU with sdl not scheduled after vt-switch

[Dietmar Hahn]

[-- Attachment #1.1: Type: text/plain, Size: 1140 bytes --]

Am 27.04.2011 schrieb "George Dunlap <George.Dunlap@eu.citrix.com>":
> Hmm, I bet qemu has crashed -- do a "ps ax | grep qemu" and see if
> it's still running.

Thanks for the hint but qemu is waiting on a select() call and does nothing
when switched away from the virtual screen.

Dietmar.


> If you're keen, you could run gdb on the core file and see where it's
> crashing. If there's no corefile, do probably need to do "ulimit -c
> unlimited" first.
> 
>  -George
> 
> On Wed, Apr 27, 2011 at 12:27 PM, Dietmar Hahn
> <dietmar.hahn@ts.fujitsu.com> wrote:
> > Hi,
> >
> > I tried a Windows domU with sdl switched on and when I switch in dom0 to
> >
> > another virtual console (the ctrl-alt-f? thing) the Windows domU loses its
> > cpu.
> >
> > # xm list
> >
> > Name ID Mem VCPUs State Time(s)
> >
> > myWindows 6 1024 1 ------ 73.5
> >
> > The domU gets scheduled again after switching back to the virtual screen.
> >
> > This is not the case when using vnc.
> >
> > What is the cause and where in the source can I find the implementation?
> >
> > Thanks!
> >
> > Dietmar.
> >

-- 
Company details: http://ts.fujitsu.com/imprint.html

[-- Attachment #1.2: Type: text/html, Size: 8030 bytes --]

[-- Attachment #2: Type: text/plain, Size: 138 bytes --]

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

Re: HVM domU with sdl not scheduled after vt-switch

[Vincent Hanquez]

On 04/27/2011 12:27 PM, Dietmar Hahn wrote:
>
> The domU gets scheduled again after switching back to the virtual screen.
>
> This is not the case when using vnc.
>
> What is the cause and where in the source can I find the implementation?
>
> Thanks!
>
That's a known problem of SDL generally, it's not linked to qemu itself 
(i've seen the same behavior happened on other program using SDL). You 
probably want to look at the SDL source for the reason why.

-- 
Vincent

Re: HVM domU with sdl not scheduled after vt-switch

[Dietmar Hahn]

[-- Attachment #1.1: Type: text/plain, Size: 669 bytes --]

Am 27.04.2011 schrieb "Vincent Hanquez <vincent.hanquez@eu.citrix.com>":
> On 04/27/2011 12:27 PM, Dietmar Hahn wrote:
> >
> > The domU gets scheduled again after switching back to the virtual screen.
> >
> > This is not the case when using vnc.
> >
> > What is the cause and where in the source can I find the implementation?
> >
> > Thanks!
> >
> That's a known problem of SDL generally, it's not linked to qemu itself 
> (i've seen the same behavior happened on other program using SDL). You 
> probably want to look at the SDL source for the reason why.

Great, I will have a look at this.
Thanks!

Dietmar.

-- 
Company details: http://ts.fujitsu.com/imprint.html

[-- Attachment #1.2: Type: text/html, Size: 4267 bytes --]

[-- Attachment #2: Type: text/plain, Size: 138 bytes --]

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

Re: HVM domU with sdl not scheduled after vt-switch

[Dietmar Hahn]

[-- Attachment #1.1: Type: text/plain, Size: 1635 bytes --]

Am 28.04.2011 schrieb "Dietmar Hahn <dietmar.hahn@ts.fujitsu.com>":
> Am 27.04.2011 schrieb "Vincent Hanquez <vincent.hanquez@eu.citrix.com>":
> > On 04/27/2011 12:27 PM, Dietmar Hahn wrote:
> > >
> > > The domU gets scheduled again after switching back to the virtual screen.
> > >
> > > This is not the case when using vnc.
> > >
> > > What is the cause and where in the source can I find the implementation?
> > >
> > > Thanks!
> > >
> > That's a known problem of SDL generally, it's not linked to qemu itself 
> > (i've seen the same behavior happened on other program using SDL). You 
> > probably want to look at the SDL source for the reason why.
> 
> Great, I will have a look at this.

It hangs in qemu in gui_update() -> dpy_refresh() -> sdl_refresh()
Via libSDL, libX11, libxcb the function  xcb_wait_for_reply() gets called.
It never gets an answer from the Xserver, because the Xserver doesn't answer
any requests when switching the vt-console.
Because gui_update() gets called via a qemu timer and never return it stops qemu.

I tried to move the qui_update() into an own thread to get the main qemu loop
running but then the first call of sdl_update() leads to:
X Error of failed request:  BadAccess (attempt to access private resource denied)
  Major opcode of failed request:  154 (GLX)
  Minor opcode of failed request:  26 (X_GLXMakeContextCurrent)
  Serial number of failed request:  31
  Current serial number in output stream:  31
and qemu exits.
I googled a little bit and found XInitThreads() but this doesn't help.
Any hints are welcome ;-) !

Dietmar.

-- 
Company details: http://ts.fujitsu.com/imprint.html

[-- Attachment #1.2: Type: text/html, Size: 7731 bytes --]

[-- Attachment #2: Type: text/plain, Size: 138 bytes --]

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

Re: HVM domU with sdl not scheduled after vt-switch

[Stefano Stabellini]

On Mon, 2 May 2011, Dietmar Hahn wrote:
> It hangs in qemu in gui_update() -> dpy_refresh() -> sdl_refresh()
> 
> Via libSDL, libX11, libxcb the function xcb_wait_for_reply() gets called.
> 
> It never gets an answer from the Xserver, because the Xserver doesn't answer
> 
> any requests when switching the vt-console.
> 
> Because gui_update() gets called via a qemu timer and never return it stops qemu.
> 

Which one is the SDL call that never returns exactly? SDL_UpdateRect?


> I tried to move the qui_update() into an own thread to get the main qemu loop
> 
> running but then the first call of sdl_update() leads to:
> 
> X Error of failed request: BadAccess (attempt to access private resource denied)
> 
> Major opcode of failed request: 154 (GLX)
> 
> Minor opcode of failed request: 26 (X_GLXMakeContextCurrent)
> 
> Serial number of failed request: 31
> 
> Current serial number in output stream: 31
> 
> and qemu exits.
> 
> I googled a little bit and found XInitThreads() but this doesn't help.
> 
> Any hints are welcome ;-) !
> 

Honestly I don't think any of these solutions are good. It might be
worth sending an email to the libsdl devel mailing list, asking about
this problem.