search for: 2.19.2

Fix bug ConnectTimeout=N only works on the first ConnectionAttempts https://bugzilla.mindrot.org/show_bug.cgi?id=2918 --- sshconnect.c | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/sshconnect.c b/sshconnect.c index 4862da5e..b837a83a 100644 --- a/sshconnect.c +++ b/sshconnect.c @@ -454,11 +454,12 @@ waitrfd(int fd, int *timeoutp) { struct pollfd pfd; struct timeval

For existing commits, this is almost identical to v1, except that I updated some commit messages and reordered the commits in a somewhat more logical sequence. The main changes are the extra commits: [06/11] plugins: Return NBD_FLAG_CAN_MULTI_CONN from some readonly plugins. - Readonly plugins that can set the flag unconditionally. [09/11] partitioning: Return NBD_FLAG_CAN_MULTI_CONN. [10/11]

On Thu, Dec 13, 2018 at 08:25:35PM -0500, Lyude Paul wrote: > So that the ports stay around until we've destroyed the connectors, in > order to ensure that we don't pass an invalid pointer to any MST helpers > once we introduce the new MST VCPI helpers. > > Signed-off-by: Lyude Paul <lyude at redhat.com> > --- > drivers/gpu/drm/i915/intel_connector.c | 4 ++++

On Thu, Dec 13, 2018 at 08:25:30PM -0500, Lyude Paul wrote: > There's no reason we need this, it's just confusing looking. > > Signed-off-by: Lyude Paul <lyude at redhat.com> > Cc: Juston Li <juston.li at intel.com> > --- > drivers/gpu/drm/drm_dp_mst_topology.c | 4 +--- > 1 file changed, 1 insertion(+), 3 deletions(-) > > diff --git

Apparently it now wants a drawable. Signed-off-by: Ilia Mirkin <imirkin at alum.mit.edu> --- No idea about whether this is correct. Saw the new warnings though. src/drmmode_display.c | 16 ++++++++++++++-- 1 file changed, 14 insertions(+), 2 deletions(-) diff --git a/src/drmmode_display.c b/src/drmmode_display.c index 2480122..f677e24 100644 --- a/src/drmmode_display.c +++

--- man/nouveau.man | 9 ++++++++- src/nv_driver.c | 8 ++++++-- 2 files changed, 14 insertions(+), 3 deletions(-) diff --git a/man/nouveau.man b/man/nouveau.man index 07d53c8..4878f24 100644 --- a/man/nouveau.man +++ b/man/nouveau.man @@ -63,7 +63,14 @@ GF100, GF104, GF106, GF108, GF110, GF114, GF116, GF117, GF119 GK104, GK106, GK107, GK110, GK208 .TP 22 .B GeForce GTX 750 -GM107 +GM107,

First thing to say is that I need to do a *lot* more testing on this, so this is just an early peek. In particular, although it passed ‘make check && make check-valgrind’ I have *not* tested it against a multi-conn-aware client such as the Linux kernel >= 4.9. This implements NBD_FLAG_CAN_MULTI_CONN, described in the protocol doc as: "NBD_FLAG_CAN_MULTI_CONN: Indicates that

This is the series I've been working on for a while now to get all of the atomic DRM drivers in the tree to use the atomic MST helpers, and to make the atomic MST helpers actually idempotent. Turns out it's a lot more difficult to do that without also fixing how port and branch device refcounting works so that it actually makes sense, since the current upstream implementation requires a

v1 was here: https://www.redhat.com/archives/libguestfs/2018-December/thread.html#00123 v2: - Document "-" instead of "script=-" and use it in the test; and verify this also works on FreeBSD; and verify that it doesn't depend on the particular behaviour of our wrapper script and should work with installed nbdkit too. - Fix handling of zero flags parameter. -

On Thu, Dec 13, 2018 at 08:25:31PM -0500, Lyude Paul wrote: > There should be no functional changes here Would be good to explain what you did refactor here, instead of me trying to reconstruct it from the patch. Especially pre-coffee that helps :-) > > Signed-off-by: Lyude Paul <lyude at redhat.com> > Cc: Juston Li <juston.li at intel.com> > --- >

This is a WIP version of the series I've been working on for a while now to get all of the atomic DRM drivers in the tree to use the atomic MST helpers, and to make the atomic MST helpers actually idempotent. Turns out it's a lot more difficult to do that without also fixing how port and branch device refcounting works so that it actually makes sense, since the current upstream

On Thu, Dec 13, 2018 at 08:25:34PM -0500, Lyude Paul wrote: > Up until now, freeing payloads on remote MST hubs that just had ports > removed has almost never worked because we've been relying on port > validation in order to stop us from accessing ports that have already > been freed from memory, but ports which need their payloads released due > to being removed will never be

GF117 appears to use the same register as GK104 (but still with the general Fermi readout mechanism). Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=108980 Signed-off-by: Ilia Mirkin <imirkin at alum.mit.edu> --- v1 -> v2: split out different regid into separate file. .../drm/nouveau/include/nvkm/subdev/volt.h | 1 + .../gpu/drm/nouveau/nvkm/engine/device/base.c | 2 +-

Noticed this while working on redoing the reference counting scheme in the DP MST helpers. Nouveau doesn't attempt to call drm_dp_mst_topology_mgr_destroy() at all, which leaves it leaking all of the resources for drm_dp_mst_topology_mgr and it's children mstbs+ports. Fixes: f479c0ba4a17 ("drm/nouveau/kms/nv50: initial support for DP 1.2 multi-stream") Signed-off-by: Lyude Paul

There's no reason we need this, it's just confusing looking. Signed-off-by: Lyude Paul <lyude at redhat.com> Cc: Juston Li <juston.li at intel.com> --- drivers/gpu/drm/drm_dp_mst_topology.c | 4 +--- 1 file changed, 1 insertion(+), 3 deletions(-) diff --git a/drivers/gpu/drm/drm_dp_mst_topology.c b/drivers/gpu/drm/drm_dp_mst_topology.c index ad0fb6d003be..9b1b5c9b1fa0 100644

This has never actually worked, and isn't needed anyway: the driver's always going to try to deallocate VCPI when it tears down the display that the VCPI belongs to. Signed-off-by: Lyude Paul <lyude at redhat.com> --- drivers/gpu/drm/drm_dp_mst_topology.c | 8 -------- 1 file changed, 8 deletions(-) diff --git a/drivers/gpu/drm/drm_dp_mst_topology.c

So that the ports stay around until we've destroyed the connectors, in order to ensure that we don't pass an invalid pointer to any MST helpers once we introduce the new MST VCPI helpers. Signed-off-by: Lyude Paul <lyude at redhat.com> --- drivers/gpu/drm/i915/intel_connector.c | 4 ++++ drivers/gpu/drm/i915/intel_dp_mst.c | 2 ++ 2 files changed, 6 insertions(+) diff --git

Trying to destroy the connector using mstc->connector.funcs->destroy() if connector initialization fails is wrong: there is no possible codepath in nv50_mstc_new where nv50_mstm_add_connector() would return <0 and mstc would be non-NULL. Signed-off-by: Lyude Paul <lyude at redhat.com> --- drivers/gpu/drm/nouveau/dispnv50/disp.c | 5 +---- 1 file changed, 1 insertion(+), 4

There is no need to look at the port's VCPI allocation before calling drm_dp_mst_deallocate_vcpi(), as we already have msto->disabled to let us avoid cleaning up an msto more then once. The DP MST core will never call drm_dp_mst_deallocate_vcpi() on it's own, which is presumably what these checks are meant to protect against. More importantly though, we're about to stop clearing

Now that we finally have a sane way to keep port allocations around, use it to fix the potential unchecked ->port accesses that nouveau makes by making sure we keep the mst port allocated for as long as it's drm_connector is accessible. Additionally, now that we've guaranteed that mstc->port is allocated for as long as we keep mstc around we can remove the connector registration