Re: Regression: drm: Lobotomize set_busid nonsense for !pci drivers (a325725633c2)

From: Laszlo Ersek <lersek@redhat.com>
To: Emil Velikov <emil.l.velikov@gmail.com>
Cc: Daniel Vetter <daniel.vetter@ffwll.ch>,
	ML dri-devel <dri-devel@lists.freedesktop.org>,
	Hans de Goede <hdegoede@redhat.com>,
	"Thorsten Leemhuis (regressions address)"
	<regressions@leemhuis.info>, Gerd Hoffmann <kraxel@redhat.com>,
	David Airlie <airlied@redhat.com>,
	Daniel Vetter <daniel.vetter@intel.com>,
	Joachim Frieben <jfrieben@hotmail.com>,
	Gustavo Padovan <gustavo.padovan@collabora.co.uk>
Subject: Re: Regression: drm: Lobotomize set_busid nonsense for !pci drivers (a325725633c2)
Date: Mon, 3 Oct 2016 15:03:52 +0200	[thread overview]
Message-ID: <43560c04-897b-dcdc-43a3-983bd2fd4daa@redhat.com> (raw)
In-Reply-To: <CACvgo50TqFaZ_WJ1aSX3FzgDO=cgiHv-6psSwDczOoNxKWB3jg@mail.gmail.com>

On 10/03/16 14:46, Emil Velikov wrote:
> On 3 October 2016 at 13:14, Laszlo Ersek <lersek@redhat.com> wrote:
>> On 10/03/16 13:34, Emil Velikov wrote:
>>> On 30 September 2016 at 18:26, Laszlo Ersek <lersek@redhat.com> wrote:
>>
>>>> This setup (modulo the kernel of course) was known to work, but now the
>>>> X server actually segfaults (apparently in the
>>>> xf86PlatformDeviceCheckBusID() function). Please find the logfile attached.
>>>>
>>>> (NB: this is unrelated to upstream commit de9ce6757c2e -- which the
>>>> pristine FC24 build lacks -- because I don't set AutoAddGPU to "off" --
>>>> it is left at its default "on" value.)
>>>>
>>> Where is this upstream commit again - it shows as unknown for the
>>> kernel, xserver and libdrm ?
>>
>> Apologies, that commit hash belongs to a cherry-picked patch on one of
>> my private branches; the original is
>>
>>   ea91db4b8331 config: fix GPUDevice fail when AutoAddGPU off + BusID
>>
>>
>>> So my theory was a bit off - SetVersion is the one responsible to set
>>> the "BusID", as retrieved by drmGetBusID, regardless if drmOpen or
>>> open is used.
>>>
>>> Here's a bit of a brain dump from the other day:
>>>
>>>  - The commit mentioned
>>
>> (Here I assume you mean kernel commit
>>
>>   a325725633c2 drm: Lobotomize set_busid nonsense for !pci drivers
>>
>> again.)
>>
> Correct.
> 
>>> 'affects' the drmSetBusid/DRM_IOCTL_SET_UNIQUE
>>> userspace codepaths.
>>>  - The latter itself is dri1/legacy (xserver hw/xfree86/dri/) which is
>>> not functional for platform devices.
>>> The latter of which seems to be the case for virt-gpu based on the
>>> kernel module.
>>>  - The modesetting driver should/cannot reach the above xserver codepath
>>>
>>> That said, it seems that (at least some) userspace expects a PCI
>>> device despite the kernel module 'advertising' itself as platform one
>>> :-\
>>>
>>> Going through the xserver layers is a bit inspiring I'm wondering if
>>> we can not get a strace before/after the xserver commit
>>> ca8d88e50310a0d440a127c22a0a383cc149f408 ? It will help us track
>>> things a lot quicker/easier.
>>
>> This commit:
>>
>>   ca8d88e50310 xfree86: recognize primary BUS_PCI device in
>>                xf86IsPrimaryPlatform()
>>
>> is not relevant when running Xorg on QEMU's "virtio-vga" device, it is
>> only relevant when the "virtio-gpu-pci" device is used. Aarch64 guests
>> can't have "virtio-vga", only "virgio-gpu-pci", so that commit was
>> needed for Aarch64 guests primarily.
>>
>> In this case however, kernel commit a325725633c2 breaks "virtio-vga" in
>> x86_64 guests, both with and without xserver commit ca8d88e50310.
>>
>> Anyway I'll look into capturing a strace and/or following Xorg with gdb.
>>
> If the overall case/issue is irrelevant of the xserver commit we can
> ignore if for the time being.
> In that case can you please get a xserver strace before/after the
> offending kernel commit.

Please find them at <http://people.redhat.com/~lersek/set_busid/>.

Thanks!
Laszlo

_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel