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.
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.
(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.
(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?
-- GitLab Migration Automatic Message -- This bug has been migrated to freedesktop.org's GitLab instance and has been closed from further activity. You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.freedesktop.org/xorg/driver/xf86-video-intel/issues/142.
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.