Bug 86164 - Screen resize causes crash on NV50 (NV98) in nouveau (bisected)
Summary: Screen resize causes crash on NV50 (NV98) in nouveau (bisected)
Status: NEW
Alias: None
Product: xorg
Classification: Unclassified
Component: Driver/nouveau (show other bugs)
Version: git
Hardware: x86-64 (AMD64) Linux (All)
: medium major
Assignee: Nouveau Project
QA Contact: Xorg Project Team
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2014-11-11 18:31 UTC by Maris Nartiss
Modified: 2014-11-12 09:40 UTC (History)
0 users

See Also:
i915 platform:
i915 features:


Attachments
A Xorg log file of failing session (27.48 KB, text/plain)
2014-11-11 18:31 UTC, Maris Nartiss
no flags Details

Note You need to log in before you can comment on or make changes to this bug.
Description Maris Nartiss 2014-11-11 18:31:25 UTC
Created attachment 109296 [details]
A Xorg log file of failing session

Starting with "[86024ceef015ffe31a204cc5bc6c326a19363ff1] glamor: initial support (no dri)" is not possible to configure a secondary monitor while running KDE 4.14.2. 

Steps to reproduce:
Version A:
 * while a KDE session is open, plug in a secondary monitor
 * use KDE display configuration tool to enable second monitor
 * X11 server gets restarted -> KDM window appears

Version B:
 * start system with a secondary monitor attached
 * observe how system is running in a "clone" mode (there is output on secondary monitor)
 * log in in KDM
 * observe how X11 gets restarted -> KDM window appears

Solution - use any revision before 86024ceef0

Unfortunately log files are empty - there are no meaninful messages that could shead a light on the issue. No crash is recorded, xorgsession-errors are just indicating on IO error while connecting to X11;

There is some issue with EDID, although KDE monitor configuration displays correct information. dmesg snip:
[    0.000000] Kernel command line: BOOT_IMAGE=/boot/kernel-3.17.2 root=/dev/sda2 ro nouveau.noaccel=1 resume=/dev/sda6
[   13.310327] nouveau 0000:01:00.0: irq 36 for MSI/MSI-X
[   14.481036] fbcon: nouveaufb (fb0) is primary device
[   14.818215] nouveau 0000:01:00.0: fb0: nouveaufb frame buffer device
[   14.818217] nouveau 0000:01:00.0: registered panic notifier
[   14.832075] [drm] Initialized nouveau 1.2.0 20120801 for 0000:01:00.0 on minor 0
[  103.530600] Raw EDID:
[  103.530603]          00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
[  103.530605]          00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
[  103.530605]          00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
[  103.530606]          00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
[  103.530607]          00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
[  103.530608]          00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
[  103.530609]          00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
[  103.530610]          00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
[  103.530614] nouveau 0000:01:00.0: VGA-1: EDID block 0 invalid.
[  103.530617] nouveau E[     DRM] DDC responded, but no EDID for VGA-1


git bisect start
# bad: [3fb97d78202213c1221a1d3ad8a5cebda78fdf44] fix null pointer deref
git bisect bad 3fb97d78202213c1221a1d3ad8a5cebda78fdf44
# good: [480f0998ffed6d9a5c6656dba75182f00fd88a1b] bump to 1.0.10 for release
git bisect good 480f0998ffed6d9a5c6656dba75182f00fd88a1b
# bad: [f0fa8313714c2a5b16e784b257b5ff79da3a443b] dri2: Enable sync of bufferswaps to Vblank by default.
git bisect bad f0fa8313714c2a5b16e784b257b5ff79da3a443b
# bad: [81148bb1dbc7007c021c59411d56cb31cfc74ef2] glamor: provide dri3 support when enabled
git bisect bad 81148bb1dbc7007c021c59411d56cb31cfc74ef2
# good: [b24cae0bf5db6ece21439d4c6ff3668aed4c78d6] dri2: move "is supported" checks out of nv_driver.c
git bisect good b24cae0bf5db6ece21439d4c6ff3668aed4c78d6
# good: [4b138ab18f58c6d459e21dc319615f536c8e69c8] merge nv_dma.c into nv_accel_common.c
git bisect good 4b138ab18f58c6d459e21dc319615f536c8e69c8
# good: [fd0ce8839f307693d86c7602dd926ce79e6b777d] add support for maxwell, minus Xv/renderaccel
git bisect good fd0ce8839f307693d86c7602dd926ce79e6b777d
# bad: [86024ceef015ffe31a204cc5bc6c326a19363ff1] glamor: initial support (no dri)
git bisect bad 86024ceef015ffe31a204cc5bc6c326a19363ff1
# first bad commit: [86024ceef015ffe31a204cc5bc6c326a19363ff1] glamor: initial support (no dri)
Comment 1 Ilia Mirkin 2014-11-11 19:04:57 UTC
While it shouldn't cause crashes, I suspect that removing

nouveau.noaccel=1

should resolve this issue. Why are you booting with that?
Comment 2 Maris Nartiss 2014-11-12 09:40:10 UTC
(In reply to Ilia Mirkin from comment #1)
> While it shouldn't cause crashes, I suspect that removing
> 
> nouveau.noaccel=1
> 
> should resolve this issue. Why are you booting with that?

Sorry, my analysis was incomplete. Today I tested with bare bones X session (xinit running xterm) without a secondary output - it still fails on screen resize issued with "xrandr -s 1024x768". Attaching a secondary output was just triggering screen size change.

If screen size change is triggered from xinit, it gets stuck with a black, empty screen. Attempts to use get to VT (ctrl+alt+f1) are failing, I never have been able to get killing X server option to work (whoever had that "bright" idea to remove ctrl+alt+backspace option), and simple reboot (ctrl+alt+del) doesn't work. Still system (sometimes) reacts on power button, although it can't finish shutdown - there is a disk activity, but it fails to power off.

Changing nouveau.noaccel=0 with current git master makes this bug to disappear - "xrandr -s" calls are not failing any more. Still some graphical corruption is observable (invisible parts of web page in Firefox are randomly appearing while typing in FF this report) - a different bug and I have no idea how to reproduce it. The original reason for disabling acceleration was (IIRC) inability to suspend system more than once and to play any video after first resume. Don't remember exact bug #, but that's a different story, as "xrandr -s" calls shouldn't crash X also without acceleration enabled.


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.