Summary: | with a kVM switch, xf86-video-intel and wine will crash xorg | ||||||||
---|---|---|---|---|---|---|---|---|---|
Product: | xorg | Reporter: | Rene de Zwart <renework> | ||||||
Component: | Server/General | Assignee: | Xorg Project Team <xorg-team> | ||||||
Status: | RESOLVED DUPLICATE | QA Contact: | Xorg Project Team <xorg-team> | ||||||
Severity: | normal | ||||||||
Priority: | medium | ||||||||
Version: | unspecified | ||||||||
Hardware: | x86 (IA32) | ||||||||
OS: | Linux (All) | ||||||||
Whiteboard: | |||||||||
i915 platform: | i915 features: | ||||||||
Attachments: |
|
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!
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 #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.
(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... 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 |
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.
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