Bug 27758 - with a kVM switch, xf86-video-intel and wine will crash xorg
Summary: with a kVM switch, xf86-video-intel and wine will crash xorg
Status: RESOLVED DUPLICATE of bug 17431
Alias: None
Product: xorg
Classification: Unclassified
Component: Server/General (show other bugs)
Version: unspecified
Hardware: x86 (IA32) Linux (All)
: medium normal
Assignee: Xorg Project Team
QA Contact: Xorg Project Team
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2010-04-20 12:03 UTC by Rene de Zwart
Modified: 2011-01-24 03:18 UTC (History)
0 users

See Also:
i915 platform:
i915 features:


Attachments
Xorg log (20.21 KB, text/plain)
2010-04-20 12:03 UTC, Rene de Zwart
no flags Details
gdb stackframe fro bug (1.95 KB, text/plain)
2010-04-23 07:47 UTC, Rene de Zwart
no flags Details

Description Rene de Zwart 2010-04-20 12:03:13 UTC
Created attachment 35182 [details]
Xorg log

On arch linux with a KVM switch i have 3 computers with 3 different graphics drivers (nouveau, radeon and intel). Only the intel driver is given me grief.
Al 3 machines run the latest version of Arch. (X.Org X Server 1.7.6, xf86-video-intel 2.10.0)
I'm using lxde but have tested it with twm, fluxbox and strait openbox.

if I start up the window manager and a terminal (lxtermial, aterm, xterm) and from that terminal start winecfg (Or any other wine program) crash see attached Xorg.1.log.

if I do run (ALT+F2) and no terminal then wine starts up ok but crashes if i use a few more wine commands and or normal commands.
Under root it takes a bit longer.

I don't experience this behaviour under nouveau or radeon. or if i connect directly (without KVM) to the display.

I wonder why xf86-video-intel is sensitive to the KVM
Comment 1 Rene de Zwart 2010-04-23 07:47:30 UTC
Created attachment 35258 [details]
gdb stackframe fro bug

I compiled Xorg with debug and saved the output from gdb commmand "bt f". 
If there is more i can do let me know!
Comment 2 Chris Wilson 2010-07-02 10:02:12 UTC
It looks like a race with mode detection where ProcXF86VidModeGetAllModeLines is running before any modes have been detected for the screen. (Intel may be more susceptible due to a longer probe time or similar).

From the looks of it a simple fix would be:

diff --git a/hw/xfree86/common/xf86VidMode.c b/hw/xfree86/common/xf86VidMode.c
index 1788fa1..c22243a 100644
--- a/hw/xfree86/common/xf86VidMode.c
+++ b/hw/xfree86/common/xf86VidMode.c
@@ -221,6 +221,9 @@ VidModeGetFirstModeline(int scrnIndex, pointer *mode, int *dotClock)
        return FALSE;
 
     pScrn = xf86Screens[scrnIndex];
+    if (pScrn->modes == NULL)
+           return FALSE;
+
     pVidMode = VMPTR(pScrn->pScreen);
     pVidMode->First = pScrn->modes;
     pVidMode->Next =  pVidMode->First->next;
Comment 3 Julien Cristau 2010-07-02 11:55:56 UTC
> --- Comment #2 from Chris Wilson <chris@chris-wilson.co.uk> 2010-07-02 10:02:12 PDT ---
> It looks like a race with mode detection where ProcXF86VidModeGetAllModeLines
> is running before any modes have been detected for the screen. (Intel may be
> more susceptible due to a longer probe time or similar).
> 
See also 17431 for something similar.
Comment 4 Julien Cristau 2010-07-02 12:09:00 UTC
(In reply to comment #3)
> > --- Comment #2 from Chris Wilson <chris@chris-wilson.co.uk> 2010-07-02 10:02:12 PDT ---
> > It looks like a race with mode detection where ProcXF86VidModeGetAllModeLines
> > is running before any modes have been detected for the screen. (Intel may be
> > more susceptible due to a longer probe time or similar).
> > 
> See also 17431 for something similar.

Also 19643, which was never actually fixed as far as I can tell...
Comment 5 Rene de Zwart 2010-11-20 01:51:06 UTC
I did some additional tests because this is irritating me.
startup lxde close all windows
start wineconsole cmd and do some compilation 
finished compilation window still open
open firefox do some  searching lookup pages.
close firefox
go back to wineconsole do some more compilation
finish compilation window stil open
open firefox do some  searching lookup pages.
With firefox(But it could be any other program!) still open!!
go back to wineconsole do some more compilation  BOOOOOOOOOOMMMMMMMMM
Switching from any open window to wine application and activating that application causes the crash. As long as the wine application isn't activated
there is no problem.

Hope this is helpfull
Comment 6 Chris Wilson 2011-01-24 03:18:42 UTC

*** This bug has been marked as a duplicate of bug 17431 ***


Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.