xsrc/53888: X server segfault with supertuxkart (radeon, drm2)

[dholland%NetBSD.org@localhost]

	Note: There was a bad value `' for the field `Confidential'.
	It was set to the default value of `yes'.

>Number:         53888
>Category:       xsrc
>Synopsis:       X server segfault with supertuxkart (radeon, drm2)
>Confidential:   yes
>Severity:       critical
>Priority:       medium
>Responsible:    xsrc-manager
>State:          open
>Class:          sw-bug
>Submitter-Id:   net
>Arrival-Date:   Fri Jan 18 02:50:00 +0000 2019
>Originator:     David A. Holland
>Release:        NetBSD 8.99.25 (20181104) (but see note below)
>Organization:
>Environment:
System: NetBSD valkyrie 8.99.25 NetBSD 8.99.25 (VALKYRIE) #28: Thu Jan 17 20:46:50 EST 2019  dholland@valkyrie:/usr/src/sys/arch/amd64/compile/VALKYRIE amd64
Architecture: x86_64
Machine: amd64
>Description:

With sys/external/bsd/drm2/pci/drm_pci.c -r1.32 (from 20181115), the
former behavior of supertuxkart wedging the system is fixed. I've
pushed it pretty hard and it is no longer repeatable, whereas it used
to happen rapidly.

However, actually playing supertuxkart causes the X server to
segfault, not always right away but eventually, and it appears to
happen faster on maps with more complex graphics.

supertuxkart itself segfaults as well; there is a loose pattern where
you can start it and play for a while, then it segfaults, restart it
and it segfaults almost immediately, restart it a third time and the X
server segfaults; then restarting the X server and running
supertuxkart again will segfault and/or segfault the X server almost
immediately a few times, then repeat.

This is supertuxkart 0.8.1nb13 from pkgsrc of 20190112. Native X.

Supersedes PR 51656 and PR 51675.

>How-To-Repeat:

As above.

>Fix:

Don't know, but since it seems to not kill the system any more I can
maybe try debugging the X server if someone tells me where to start.