Bug 101324 - Crash using xf86-video-intel with I-V-O sna_dri2_schedule_swap:3321
Summary: Crash using xf86-video-intel with I-V-O sna_dri2_schedule_swap:3321
Status: NEW
Alias: None
Product: xorg
Classification: Unclassified
Component: Driver/intel (show other bugs)
Version: unspecified
Hardware: Other All
: medium major
Assignee: Chris Wilson
QA Contact: Intel GFX Bugs mailing list
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2017-06-06 23:32 UTC by Pablo Cholaky
Modified: 2017-06-07 09:02 UTC (History)
0 users

See Also:
i915 platform:
i915 features:


Attachments
Initial crash X log. (1.14 KB, text/plain)
2017-06-06 23:32 UTC, Pablo Cholaky
no flags Details
Crash with DRI3 and disconnecting IVO (31.48 KB, text/plain)
2017-06-06 23:56 UTC, Pablo Cholaky
no flags Details

Note You need to log in before you can comment on or make changes to this bug.
Description Pablo Cholaky 2017-06-06 23:32:27 UTC
Created attachment 131756 [details]
Initial crash X log.

Hi,

I'm getting the following crash, this is very random using I-V-O. I'm currently using DRI2 to avoid crashes, but still with problems.

There is some extra info needed? I'm sorry how poorly info I'm giving, but I don't really know which extra info may be useful.

Distro: Gentoo
xf86-video-intel: 2.99.917_p20170313
xorg-server: 1.19.3
mesa: 17.1.1

IGP: Intel 530 (Skylake)
DGP: Nvidia 980m (Maxwell2) with 381.22

Thanks.
Comment 1 Pablo Cholaky 2017-06-06 23:56:44 UTC
Created attachment 131757 [details]
Crash with DRI3 and disconnecting IVO

As additional, this is why I'm using DRI2, currently, it always crash when I disconnect the monitor using DRI3. This is the log of the crash under that.
Comment 2 Chris Wilson 2017-06-07 08:14:43 UTC
(In reply to Pablo Cholaky from comment #1)
> Created attachment 131757 [details]
> Crash with DRI3 and disconnecting IVO
> 
> As additional, this is why I'm using DRI2, currently, it always crash when I
> disconnect the monitor using DRI3. This is the log of the crash under that.

Present is cancelling its take over of the screen *after* we have changed the screen. --enable-debug is alerting you to the problem, raising a potential graphical glitch to a fatal error. Don't enable debug unless you are debugging.

The problem as it stands is that the resize+mode-change changes the configuration and creates new framebuffers. It copies the contents of the current frontbuffer, which under Present is not the same as the current scanout!, into those new framebuffers. Then Present tries to unflip back to its old Screen (after the event!), but since it is no longer compatible that refresh is lost.

In practice, it should be harmless.
Comment 3 Chris Wilson 2017-06-07 09:02:18 UTC
(In reply to Pablo Cholaky from comment #0)
> Created attachment 131756 [details]
> Initial crash X log.

That one is a bit more insiduous. It means the client ended up rendering directly into the frontbuffer. Whilst any client has a bo as their frontbuffer, or whilst a bo is on a scanout, it raises its active count, and while the active count is non-zero it is not allowed to be given to a client to use as a back buffer. The tracking is on the bo, so it should hold true as we interchange the frontbuffer for TearFree. However, that screwed up somewhere and has so far evaded all the asserts meant to try and catch the screw up much earlier.

How big is the window being swapped in comparison to the multiple monitors? Do it match the full screen size, a single monitor, or none?


Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct.