Bug 90622 - Segfault in xf86-video-intel-2.99.917 (sna) with gcc-5.1, linux-4.0 headers, linux-4.0 kernels
Summary: Segfault in xf86-video-intel-2.99.917 (sna) with gcc-5.1, linux-4.0 headers, ...
Status: RESOLVED FIXED
Alias: None
Product: xorg
Classification: Unclassified
Component: Driver/intel (show other bugs)
Version: unspecified
Hardware: Other All
: medium normal
Assignee: Chris Wilson
QA Contact: Intel GFX Bugs mailing list
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2015-05-24 21:22 UTC by ken moffat
Modified: 2015-05-25 07:16 UTC (History)
0 users

See Also:
i915 platform:
i915 features:


Attachments
Xorg log after segfault (6.49 KB, text/plain)
2015-05-24 21:22 UTC, ken moffat
no flags Details
full backtrace from gdb (5.40 KB, text/plain)
2015-05-24 21:23 UTC, ken moffat
no flags Details
dmesg with drm.debug=0x06, from boot until the segfault (176.17 KB, text/plain)
2015-05-24 21:24 UTC, ken moffat
no flags Details

Description ken moffat 2015-05-24 21:22:04 UTC
Created attachment 116015 [details]
Xorg log after segfault

Summary: on x86_64 linuxfromscratch, with current released versions of everything, if I use the default sna acceleration with a 4.0 kernel (tested with 4.0.3 and 4.0.4) Xorg segfaults while trying to start. Oddly, if I build a 3.19.0 kernel (still using gcc-5) on the same sytem, it is fine.

With 4.0 kernels, if I enable uxa and force that in a conf file Xorg works fine.

This is a SandyBridge running as x86_64 :
processor       : 0
vendor_id       : GenuineIntel
cpu family      : 6
model           : 42
model name      : Intel(R) Core(TM) i3-2120 CPU @ 3.30GHz
stepping        : 7

lspci says:
00:02.0 VGA compatible controller: Intel Corporation 2nd Generation Core Processor Family Integrated Graphics Controller (rev 09) (prog-if 00 [VGA controller])
        Subsystem: Gigabyte Technology Co., Ltd 2nd Generation Core Processor Family Integrated Graphics Controller
        Flags: bus master, fast devsel, latency 0, IRQ 24
        Memory at f7800000 (64-bit, non-prefetchable) [size=4M]
        Memory at e0000000 (64-bit, prefetchable) [size=256M]
        I/O ports at f000 [size=64]
        Expansion ROM at <unassigned> [disabled]
        Capabilities: [90] MSI: Enable+ Count=1/1 Maskable- 64bit-
        Capabilities: [d0] Power Management version 2
        Capabilities: [a4] PCI Advanced Features
        Kernel driver in use: i915

Main package versions
xf86-video-intel-2.99.917
xorg-server-1.17.1
mesa-10.5.5
libdrm-2.4.61

This is using the VGA connector


Steps to reproduce: run 'startx'
Comment 1 ken moffat 2015-05-24 21:23:05 UTC
Created attachment 116016 [details]
full backtrace from gdb
Comment 2 ken moffat 2015-05-24 21:24:32 UTC
Created attachment 116017 [details]
dmesg with drm.debug=0x06, from boot until the segfault
Comment 3 Chris Wilson 2015-05-24 21:31:51 UTC
It's libdrm fallout, already fixed though I want to look at that bt more.
Comment 4 Chris Wilson 2015-05-25 07:16:39 UTC
To get past the mmap failure, needs a libdrm fix or the ddx w/a. However, that crash should not happen, so:

commit 8b7bdff750a98fc7644fc9ab17bedc79b03198b4
Author: Chris Wilson <chris@chris-wilson.co.uk>
Date:   Mon May 25 08:02:46 2015 +0100

    sna: Initialise no-op callbacks early
    
    In case of error, we try to free up memory before trying again. This
    involves callbacks into higher level code - but if we fail early, we
    will not have those hooks installed. Set no-ops stubs early to prevent
    untimely crashes.
    
    References: https://bugs.freedesktop.org/show_bug.cgi?id=90622#c1
    Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>


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.