search for: scheduled_work

I had this exact same problem with 2.0.7. I had done a little investigation and found scheduled_work gets called to schedule the shutdown in the user domain kernel, but the shutdown work that gets scheduled never actually gets called. I''m glad someone else is seeing this same problem now :-) Like you, it worked a number of times in a row, then would fail, and it didn''t seem to...

...for the fact that this > problem isn't 100% reproducible in the first place). It's not 100% reproducible, but it's at least 90% so it's not difficult for me to test at all. Also, reverting this commit makes no difference either. Note that while that commit only changed nouveau, scheduled_work() is exactly how a number of other drivers (i915 for instance) handle reprobing like this as well. The reason being that we can't do full connector reprobing in our runtime resume thread because we could deadlock if someone else is holding a modesetting lock we need and waiting on us to resume...

On Mon, Apr 15, 2019 at 02:07:18PM -0400, Lyude Paul wrote: > On Thu, 2019-04-04 at 09:17 -0500, Bjorn Helgaas wrote: > > [+cc Hans, author of 0b2fe6594fa2 ("drm/nouveau: Queue hpd_work on (runtime) > > resume")] > > > > On Fri, Mar 22, 2019 at 06:30:15AM -0500, Bjorn Helgaas wrote: > > > On Thu, Mar 21, 2019 at 05:48:19PM -0500, Bjorn Helgaas wrote:

...it's not > difficult for me to test at all. > > Also, reverting this commit makes no difference either. OK, great, that makes it crystal clear. I didn't know you had specifically tested that revert. Thanks for doing that. > Note that while that commit only changed nouveau, scheduled_work() > is exactly how a number of other drivers (i915 for instance) handle > reprobing like this as well. OK. The GPU code would be a lot more approachable if similar things were done in similar ways. I spent an hour or so looking for this similar code in i915, but gave up. > The reason b...