similar to: 3.8-rc6: nouveau lockdep recursive lock acquisition

Add a flag NVOBJ_FLAG_CREAT_EXCL, which will make sure that only 1 engctx will be created. This removes the need of having multiple Fixes the following lockdep splat: ============================================= [ INFO: possible recursive locking detected ] 3.8.0-rc6-ninja+ #1 Not tainted --------------------------------------------- modprobe/585 is trying to acquire lock:

Testing airlied's current drm-fixes branch gives me this, with lockdep enabled: [ 40.864179] ============================================= [ 40.864179] [ INFO: possible recursive locking detected ] [ 40.864179] 3.8.0-rc3-patser+ #915 Tainted: G W [ 40.864179] --------------------------------------------- [ 40.864179] modprobe/524 is trying to acquire lock: [ 40.864179]

On my MacbookPro Retina, when disabling the discrete Nvidia GPU via the switcheroo [1], the disablement is correctly executed [2], I restart X etc. After some time, upowerd reads from the noveau's sysfs files, causing (expected) displayport I2C timeouts, as the hardware is in D3 [3] (I added a call to dump_stack to see the context). Does it make sense we deregister the sysfs files when the

Hi, here comes the next version of OCFS2 lockdep support. I've dropped patches with fixes from the series since they were already merged. As Joel suggested, I've simplified the main patch a bit so that we don't have ifdefs around lock declarations and there are also a few other minor improvements. Honza

Hi Jasmin, On Sun, Mar 1, 2020 at 11:32 AM Jasmin <jasmin.pm at protonmail.com> wrote: > > Hi, > > for quite some time now I would like to switch from the proprietary driver to nouveau, using a GK107 (Quadro) in a thinkpad. > Unfortunately the monitors connected to the lenovo "ultra dock" are not properly recognized when using nouveau. DP-MST support was first

https://bugs.freedesktop.org/show_bug.cgi?id=54646 Bug #: 54646 Summary: i2c failure on Quadro NVS 4200M (GF119 (NVD9)) Classification: Unclassified Product: xorg Version: unspecified Platform: Other OS/Version: All Status: NEW Severity: normal Priority: medium Component: Driver/nouveau

On Mon, May 5, 2014 at 4:48 AM, Sergei Antonov <saproj at gmail.com> wrote: > The following commit from about a year ago removed nouveau_dp_dpms() which > did steps required to suspend and resume a monitor connected via DisplayPort. > > commit 0a0afd282fd715dd63d64b243299a64da14f8e8d > Author: Ben Skeggs <bskeggs at redhat.com> > Date: Mon Feb 18

Hi, for quite some time now I would like to switch from the proprietary driver to nouveau, using a GK107 (Quadro) in a thinkpad. Unfortunately the monitors connected to the lenovo "ultra dock" are not properly recognized when using nouveau. The laptop contains a multiplexer: so in the bios it can be selected, whether the docking station's DP/HDMI/VGA-Ports are "directly"

On 5 May 2014 01:43, Ben Skeggs <skeggsb at gmail.com> wrote: > On Mon, May 5, 2014 at 4:48 AM, Sergei Antonov <saproj at gmail.com> wrote: >> The following commit from about a year ago removed nouveau_dp_dpms() which >> did steps required to suspend and resume a monitor connected via DisplayPort. >> >> commit 0a0afd282fd715dd63d64b243299a64da14f8e8d

Hi, the first four patches in this series fix locking problems in OCFS2 quota code (three of them can lead to potential deadlocks). The fifth patch reorders ip_alloc_sem for directories to be acquired before localalloc locks. Mark would you please merge these? The last two patches implement lockdep annotations for OCFS2 cluster locks. We annotate all the cluster locks except for special ones

The following commit from about a year ago removed nouveau_dp_dpms() which did steps required to suspend and resume a monitor connected via DisplayPort. commit 0a0afd282fd715dd63d64b243299a64da14f8e8d Author: Ben Skeggs <bskeggs at redhat.com> Date: Mon Feb 18 23:17:53 2013 -0500 drm/nv50-/disp: move DP link training to core and train from supervisor My computer with

Hi, I'm resending this patch series. It's rediffed against linux-next branch of Joel's git tree. The first four patches are obvious fixes of deadlocks in quota code and should go in as soon as possible. The other three patches implement lockdep support for OCFS2 cluster locks. So you can have a look whether the code make sence to you and possibly merge them. They should be NOP when

On 3.8-rc2 with lockdep enabled and dual-GPU setup (Macbook Pro Retina), I see two releated lock inversion issues with the EFI framebuffer, leading to possible deadlock: when X takes over from the EFI framebuffer [1] and when nouveau releases the framebuffer when being vgaswitcherood [2]. Let me know if you'd like any testing or analysis when I can get the time. Many thanks, Daniel ---

From: Dave Airlie <airlied at redhat.com> These can happen in normal operations esp with auxch transactions. Gets rid of nouveau 0000:01:00.0: gsp: cli:0xc1d00002 obj:0x00730000 ctrl cmd:0x00731341 failed: 0x0000ffff in logs. Cc: Lyude <lyude at redhat.com> Signed-off-by: Dave Airlie <airlied at redhat.com> --- drivers/gpu/drm/nouveau/nvkm/subdev/gsp/r535.c | 2 +- 1 file

https://bugs.freedesktop.org/show_bug.cgi?id=34429 Summary: Failure during resume on NV50: INIT_AUXCH: rd auxch fail -121 Product: xorg Version: git Platform: x86-64 (AMD64) OS/Version: Linux (All) Status: NEW Severity: major Priority: medium Component: Driver/nouveau

https://bugs.freedesktop.org/show_bug.cgi?id=51971 Bug #: 51971 Summary: MacBook Pro 10,1 Retina - Display Resets, No Connectors Classification: Unclassified Product: xorg Version: git Platform: x86-64 (AMD64) OS/Version: Linux (All) Status: NEW Severity: normal Priority: medium

- Use driver level (0x2) for NV_DEBUG instead of all levels - Create a NV_DEBUG_KMS for KMS level (04) and use them in modesetting code - Remove a few odd NV_TRACE calls and replace with NV_DEBUG_KMS Signed-off-by: Maarten Maathuis <madman2003 at gmail.com> --- drivers/gpu/drm/nouveau/nouveau_bios.c | 12 +++++----- drivers/gpu/drm/nouveau/nouveau_connector.c | 8 +++---

On Tue, May 01, 2018 at 10:07:38PM -0400, Vladislav Yasevich wrote: > Since we now have support for software CRC32c offload, turn it on > for macvlan and macvtap devices so that guests can take advantage > of offload SCTP checksums to the host or host hardware. > > Signed-off-by: Vladislav Yasevich <vyasevic at redhat.com> > --- > drivers/net/macvlan.c | 5 +++-- >

On Tue, May 01, 2018 at 10:07:38PM -0400, Vladislav Yasevich wrote: > Since we now have support for software CRC32c offload, turn it on > for macvlan and macvtap devices so that guests can take advantage > of offload SCTP checksums to the host or host hardware. > > Signed-off-by: Vladislav Yasevich <vyasevic at redhat.com> > --- > drivers/net/macvlan.c | 5 +++-- >

These are based on 5.8.0-rc2 and intended for Ben Skeggs' nouveau tree. I believe the changes can be queued for 5.8-rcX after being reviewed. These were part of a larger series but I'm resending them separately as suggested by Jason Gunthorpe. https://lore.kernel.org/linux-mm/20200619215649.32297-1-rcampbell at nvidia.com/ Note that in order to exercise/test patch 2 here, you will need a