On 10/03/16 14:46, Emil Velikov wrote: > On 3 October 2016 at 13:14, Laszlo Ersek <lersek@xxxxxxxxxx> wrote: >> On 10/03/16 13:34, Emil Velikov wrote: >>> On 30 September 2016 at 18:26, Laszlo Ersek <lersek@xxxxxxxxxx> 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@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/dri-devel
