Re: USB GPU bugs
Hi, On 11-10-2019 12:13, Pekka Paalanen wrote: On Thu, 10 Oct 2019 09:40:30 +0200 Hans de Goede wrote: Hi, On 09-10-2019 12:23, Pekka Paalanen wrote: On Wed, 9 Oct 2019 09:59:29 +0200 Hans de Goede wrote: I think I might also be seeing some variant of your "not enough hotplug events" bug. With the gm12u320 projector when hotplugged it is listed as "unknown" in gnome's display-settings until I change the settings once and then it becomes "Acer" as it should be. I believe that this issue is actually also present in the 1.20 branch. In my case, I see an "add" and three HOTPLUG events via udev when I hotplug the DisplayLink dock and it creates the DRM device node on the spot. Mutter receives just one RandR event though, which it deems is not a hotplug, and looking at the config timestamps I think the event indeed is reflecting too old state. 'xrandr' will show everything about the new connector just fine though, IIRC. I just realized I should probably respond to this bit. You see that after "xrandr" everything looks ok, but the "xrandr" command causes a round trip to the kernel and even causes the kernel to re-poll all connectors. Have you tried "xrandr --current" ? That will return the current state stored inside the xserver without re-querying the kernel. Not sure of this helps, but I thought I should mention it. Hi Hans, that's a good hint. 'xrandr --current' reports the connector as connected and with a good looking mode list, when Mutter does not autoenable it. Does 'xrandr' call into the kernel with drmModeGetConnectorCurrent(), or does it really return only what Xorg had internally cached? If it calls into kernel, then I'm not surprised it returns the good info, since I believe that Xorg is somehow ignoring a udev hotplug event, or not realizing that something did still change since the last time it sent out RandR events. AFAIK xrandr without --current calls into the kernel. With --current it just returns only what Xorg had internally cached. Regards, Hans ___ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: https://lists.x.org/mailman/listinfo/xorg-devel
Re: USB GPU bugs
On Thu, 10 Oct 2019 09:40:30 +0200 Hans de Goede wrote: > Hi, > > On 09-10-2019 12:23, Pekka Paalanen wrote: > > On Wed, 9 Oct 2019 09:59:29 +0200 > > Hans de Goede wrote: > > > > >> I think I might also be seeing some variant of your "not enough hotplug > >> events" bug. With the gm12u320 projector when hotplugged it is listed > >> as "unknown" in gnome's display-settings until I change the settings > >> once and then it becomes "Acer" as it should be. I believe that this > >> issue is actually also present in the 1.20 branch. > > > > In my case, I see an "add" and three HOTPLUG events via udev when I > > hotplug the DisplayLink dock and it creates the DRM device node on the > > spot. Mutter receives just one RandR event though, which it deems is > > not a hotplug, and looking at the config timestamps I think the event > > indeed is reflecting too old state. 'xrandr' will show everything about > > the new connector just fine though, IIRC. > > I just realized I should probably respond to this bit. You see that > after "xrandr" everything looks ok, but the "xrandr" command causes > a round trip to the kernel and even causes the kernel to re-poll all > connectors. Have you tried "xrandr --current" ? That will return the > current state stored inside the xserver without re-querying the kernel. > > Not sure of this helps, but I thought I should mention it. Hi Hans, that's a good hint. 'xrandr --current' reports the connector as connected and with a good looking mode list, when Mutter does not autoenable it. Does 'xrandr' call into the kernel with drmModeGetConnectorCurrent(), or does it really return only what Xorg had internally cached? If it calls into kernel, then I'm not surprised it returns the good info, since I believe that Xorg is somehow ignoring a udev hotplug event, or not realizing that something did still change since the last time it sent out RandR events. I finally created an upstream issue for this one: https://gitlab.freedesktop.org/xorg/xserver/issues/909 I'll continue staring at it next week. Thanks, pq pgpgI81IODQxD.pgp Description: OpenPGP digital signature ___ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: https://lists.x.org/mailman/listinfo/xorg-devel
Re: USB GPU bugs
Hi, On 09-10-2019 12:23, Pekka Paalanen wrote: On Wed, 9 Oct 2019 09:59:29 +0200 Hans de Goede wrote: I think I might also be seeing some variant of your "not enough hotplug events" bug. With the gm12u320 projector when hotplugged it is listed as "unknown" in gnome's display-settings until I change the settings once and then it becomes "Acer" as it should be. I believe that this issue is actually also present in the 1.20 branch. In my case, I see an "add" and three HOTPLUG events via udev when I hotplug the DisplayLink dock and it creates the DRM device node on the spot. Mutter receives just one RandR event though, which it deems is not a hotplug, and looking at the config timestamps I think the event indeed is reflecting too old state. 'xrandr' will show everything about the new connector just fine though, IIRC. I just realized I should probably respond to this bit. You see that after "xrandr" everything looks ok, but the "xrandr" command causes a round trip to the kernel and even causes the kernel to re-poll all connectors. Have you tried "xrandr --current" ? That will return the current state stored inside the xserver without re-querying the kernel. Not sure of this helps, but I thought I should mention it. Regards, Hans ___ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: https://lists.x.org/mailman/listinfo/xorg-devel
Re: USB GPU bugs
Hi, On 09-10-2019 12:23, Pekka Paalanen wrote: On Wed, 9 Oct 2019 09:59:29 +0200 Hans de Goede wrote: Let's keep each other updated, so we don't do duplicate effort. :-) Ack I will drop you a mail when I find / make time to look into this. Regards, Hans ___ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: https://lists.x.org/mailman/listinfo/xorg-devel
Re: USB GPU bugs
On Wed, 9 Oct 2019 09:59:29 +0200
Hans de Goede wrote:
> Hi Pekka,
>
> On 09-10-2019 09:47, Pekka Paalanen wrote:
> > On Tue, 8 Oct 2019 22:19:45 +0200
> > Hans de Goede wrote:
> >
> >> My main reason for suggesting either one is that I personally am aware
> >> of at least 2 issues (both related to secondary USB GPUs handling) which
> >> are only present in master and not in the 1.20 branch and which I really
> >> would like to see fixed before a new release. I have taking a look at
> >> these on my to do list, but not at the top of it (yet).
> >
> > Hi Hans,
> >
> > it so happens that I am, too, looking at some secondary DRM device
> > hotplug issues. I think I've seen three different things: not enough
> > RandR events to make Mutter take a hotplugged device & output into use,
> > Xorg crash on DRM device hotplug, and failure to start with Xorg USB
> > DRM device plugged in.
> >
> > Do you have any public records of the issues you have on your plate?
>
> No I've not filed issues yet, since I was planning on debugging them
> myself, but if are both seeing these issues then having gitlab
> issues to track them might be a good idea.
>
> I am using a gm12u320 based mini projector (Acer C120) for most of
> my tests, but I believe that this will reproduce with an udl (USB 2 version)
> device too. If necessary I can try to reproduce with an udl device too.
Hi Hans,
I'm working with a Dell DisplayLink dock, USB 3 version, so it's using
the proprietary userspace and the EVDI out-of-tree kernel driver (open
source).
I'd prefer talking about DRM devices or such, because these USB things
do not have a GPU. Having a GPU or not behind a DRM device is sometimes
noteworthy.
> Thinking more about it I'm seeing 3 things:
>
> 1. USB GPU is not seen (not shown in xrandr --list-providers, not usable)
> when present before Xorg is started.
For me, this case seems to stop Xorg from starting:
MESA-LOADER: failed to retrieve device information
MESA-LOADER: failed to open evdi (search paths
/usr/lib/x86_64-linux-gnu/dri:\$${ORIGIN}/dri:/usr/lib/dri)
failed to load driver: evdi
(EE)
Fatal server error:
(EE) AddScreen/ScreenInit failed for gpu driver 0 -1
>
> 2. Hot plugging the USB GPU sometimes causes things to crash shortly
> afterwards.
I've seen this. Looks like a bad pointer, but I couldn't yet figure out
where from. I did get Valgrind to tell me this:
==1843== Invalid free() / delete / delete[] / realloc()
==1843==at 0x483AD4B: realloc (in
/usr/lib/x86_64-linux-gnu/valgrind/vgpreload_memcheck-amd64-linux.so)
==1843==by 0x24BA68: XNFreallocarray (utils.c:1167)
==1843==by 0x26D4F1: xf86SetDepthBpp (xf86Helper.c:558)
==1843==by 0x644DB72: PreInit (driver.c:951)
==1843==by 0x27F3B6: xf86platformAddDevice (xf86platformBus.c:638)
==1843==by 0x29E1F0: NewGPUDeviceRequest (lnx_platform.c:176)
==1843==by 0x2C27FB: device_added (udev.c:140)
==1843==by 0x2C2D9F: socket_handler (udev.c:375)
==1843==by 0x249B40: ospoll_wait (ospoll.c:657)
==1843==by 0x243682: WaitForSomething (WaitFor.c:208)
==1843==by 0x17ADBB: Dispatch (dispatch.c:421)
==1843==by 0x17EFF5: dix_main (main.c:274)
==1843== Address 0x5d982d0 is 0 bytes after an unallocated block of size 0 in
arena "client"
> 3. Hot unplugging the USB GPU always causes a crash shortly
> afterwards.
Unplugging does not happen in my case, because EVDI does not remove the
DRM device. It simply marks the connector as disconnected instead, and
the DRM device is re-used for the next DisplayLink device.
>
> My test environment is xserver master + mutter/gnome-shell 3.34 on
> top of Xorg. Last time I tried downgrading the xserver to 1.20 made all
> 3 issues go away (*)
Good to know. I was debugging a first hotplug issue on
gnome-shell/mutter from git, a revision within the past few weeks.
Xserver was stock Ubuntu 19.04 (1.20.4), but then I wanted to add
prints in it, switched to git master without thinking, and started
seeing these crashes.
> I think I might also be seeing some variant of your "not enough hotplug
> events" bug. With the gm12u320 projector when hotplugged it is listed
> as "unknown" in gnome's display-settings until I change the settings
> once and then it becomes "Acer" as it should be. I believe that this
> issue is actually also present in the 1.20 branch.
In my case, I see an "add" and three HOTPLUG events via udev when I
hotplug the DisplayLink dock and it creates the DRM device node on the
spot. Mutter receives just one RandR event though, which it deems is
not a hotplug, and looking at the config timestamps I think the event
indeed is reflecting too old state. 'xrandr' will show everything about
the new connector just fine though, IIRC.
Knowing that there are regressions in xserver master, I will first
concentrate on my primary issue with the "not enough hotplug events".
Once I have that sorted out, I might be able to help with the other
issues.
Let's keep each other
Re: USB GPU bugs
Hi Pekka, On 09-10-2019 09:47, Pekka Paalanen wrote: On Tue, 8 Oct 2019 22:19:45 +0200 Hans de Goede wrote: My main reason for suggesting either one is that I personally am aware of at least 2 issues (both related to secondary USB GPUs handling) which are only present in master and not in the 1.20 branch and which I really would like to see fixed before a new release. I have taking a look at these on my to do list, but not at the top of it (yet). Hi Hans, it so happens that I am, too, looking at some secondary DRM device hotplug issues. I think I've seen three different things: not enough RandR events to make Mutter take a hotplugged device & output into use, Xorg crash on DRM device hotplug, and failure to start with Xorg USB DRM device plugged in. Do you have any public records of the issues you have on your plate? No I've not filed issues yet, since I was planning on debugging them myself, but if are both seeing these issues then having gitlab issues to track them might be a good idea. I am using a gm12u320 based mini projector (Acer C120) for most of my tests, but I believe that this will reproduce with an udl (USB 2 version) device too. If necessary I can try to reproduce with an udl device too. Thinking more about it I'm seeing 3 things: 1. USB GPU is not seen (not shown in xrandr --list-providers, not usable) when present before Xorg is started. 2. Hot plugging the USB GPU sometimes causes things to crash shortly afterwards. 3. Hot unplugging the USB GPU always causes a crash shortly afterwards. My test environment is xserver master + mutter/gnome-shell 3.34 on top of Xorg. Last time I tried downgrading the xserver to 1.20 made all 3 issues go away (*) I think I might also be seeing some variant of your "not enough hotplug events" bug. With the gm12u320 projector when hotplugged it is listed as "unknown" in gnome's display-settings until I change the settings once and then it becomes "Acer" as it should be. I believe that this issue is actually also present in the 1.20 branch. Regards, Hans *) Which is why I've not given these bugs a high priority so far ___ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: https://lists.x.org/mailman/listinfo/xorg-devel
USB GPU bugs
On Tue, 8 Oct 2019 22:19:45 +0200 Hans de Goede wrote: > My main reason for suggesting either one is that I personally am aware > of at least 2 issues (both related to secondary USB GPUs handling) which > are only present in master and not in the 1.20 branch and which I really > would like to see fixed before a new release. I have taking a look at > these on my to do list, but not at the top of it (yet). Hi Hans, it so happens that I am, too, looking at some secondary DRM device hotplug issues. I think I've seen three different things: not enough RandR events to make Mutter take a hotplugged device & output into use, Xorg crash on DRM device hotplug, and failure to start with Xorg USB DRM device plugged in. Do you have any public records of the issues you have on your plate? I haven't filed any for mine yet, I'm still trying to untangle them. Thanks, pq pgpxmYWnHbGXE.pgp Description: OpenPGP digital signature ___ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: https://lists.x.org/mailman/listinfo/xorg-devel
