On Tue, 2020-08-18 at 10:58 -0700, Zwane Mwaikambo wrote: > On Wed, 12 Aug 2020, Lyude Paul wrote: > > > On Wed, 2020-08-12 at 16:10 +0200, Daniel Vetter wrote: > > > On Wed, Aug 12, 2020 at 12:16 AM Zwane Mwaikambo <zwanem@xxxxxxxxx> > > > wrote: > > > > On Tue, 11 Aug 2020, Daniel Vetter wrote: > > > > > > > > > On Mon, Aug 10, 2020 at 10:11:50AM -0700, Zwane Mwaikambo wrote: > > > > > > Hi Folks, > > > > > > I know this thread eventually dropped off due to not > > > > > > identifying > > > > > > the underlying issue. It's still occuring on 5.8 and in my case it > > > > > > happened because the udev device nodes for the DP aux devices were > > > > > > not > > > > > > cleaned up whereas the kernel had no association with them. I can > > > > > > reproduce the bug just by creating a device node for a non- > > > > > > existent > > > > > > minor > > > > > > device and calling open(). > > > > > > > > > > Hm I don't have that thread anymore, but generally these bugs are > > > > > solved > > > > > by not registering the device before it's ready for use. We do have > > > > > drm_connector->late_register for that stuff. Just a guess since I'm > > > > > not > > > > > seeing full details here. > > > > > > > > In this particular case, the physical device disappeared before the > > > > nodes > > > > were cleaned up. It involves putting a computer to sleep with a > > > > monitor > > > > plugged in and then waking it up with the monitor unplugged. > > > > > > We also have early_unregister for the reverse, but yes this sounds > > > more tricky ... Adding Lyude who's been working on way too much > > > lifetime fun around dp recently. > > > -Daniel > > > > > Hi-I think just checking whether the auxdev is NULL or not is a reasonable > > fix, although I am curious as to how exactly the aux dev's parent is > > getting > > destroyed before it's child, which I would have thought would be the only > > way > > you could hit this? > > Hi, If this is acceptable, would you consider an updated patch against > 5.8? Sure-although the process to getting this into stable is to get the patch into drm-next first, then it can get cherry-picked into the stable kernel branches. See https://www.kernel.org/doc/html/latest/process/stable-kernel-rules.html > > Thanks, > Zwane > -- Cheers, Lyude Paul (she/her) Software Engineer at Red Hat _______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/dri-devel
