similar to: nouveau regression [bisected] hotplug broken on gf108 since 4.1

uhhhhhhhhhhhhh didn't we fix this weeks ago? with "drm/nouveau: tegra: Call nouveau_drm_device_init()" On Fri, 2018-12-07 at 23:31 +0000, Guillaume Tucker wrote: > Please find below an automated bisection report for a kernel Oops > seen during the initialisation of the nouveau GPU driver on > jetson-tk1. > > > All the LAVA test jobs for this bisection can be

On 08/12/2018 00:08, Lyude Paul wrote: > uhhhhhhhhhhhhh > didn't we fix this weeks ago? with "drm/nouveau: tegra: Call > nouveau_drm_device_init()" Yes here's the fix from Thierry: https://patchwork.freedesktop.org/patch/263587/ and I can confirm that it does fix the Oops when applied on top of next-20181206 (what I used for the bisection last week):

Please find below an automated bisection report for a kernel Oops seen during the initialisation of the nouveau GPU driver on jetson-tk1. All the LAVA test jobs for this bisection can be found here: http://lava.baylibre.com:10080/scheduler/alljobs?length=25&search=lava-bisect-staging-7366#table Here's the beginning of the Oops stack trace: [ 7.485361] [00000064] *pgd=f9e7b835 [

Make use of the devm_drm_dev_alloc() API to bind the lifetime of nouveau_drm structure to the drm_device. This is important because a reference to nouveau_drm is accessible from drm_device, which is provided to a number of DRM layer callbacks that can run after the deallocation of nouveau_drm currently occurs. Signed-off-by: Jeremy Cline <jcline at redhat.com> ---

On Fri, Nov 6, 2020 at 3:17 AM Jeremy Cline <jcline at redhat.com> wrote: > > Make use of the devm_drm_dev_alloc() API to bind the lifetime of > nouveau_drm structure to the drm_device. This is important because a > reference to nouveau_drm is accessible from drm_device, which is > provided to a number of DRM layer callbacks that can run after the > deallocation of

From: Thierry Reding <treding at nvidia.com> As part of commit cfea88a4d866 ("drm/nouveau: Start using new drm_dev initialization helpers"), the initialization of the Nouveau DRM device was reworked and along the way the platform driver initialization was left incomplete. Add a call to nouveau_drm_device_init() to make sure all of the structures are properly initialized.

This series is intended to add support for shutting down the GPU on kernel shutdown/reboot using the ->shutdown() hook, similar to what amdgpu does. This is mainly intended to workaround a bios issue on the P50 that was preventing nouveau from initializing the dedicated GM107 GPU on that system properly. You can find more details on this issue in the patch labeled "Shut down GPU on kernel

v2: rework detection of if Nouveau calling a DSM method or not Signed-off-by: Karol Herbst <kherbst at redhat.com> --- drm/nouveau/nouveau_acpi.c | 7 ++++++- drm/nouveau/nouveau_acpi.h | 2 ++ drm/nouveau/nouveau_drm.c | 14 +++++++++++--- drm/nouveau/nouveau_drv.h | 2 ++ 4 files changed, 21 insertions(+), 4 deletions(-) diff --git a/drm/nouveau/nouveau_acpi.c

When looking into the runpm issues, the first workaround I came up with was setting the PCIe link speed to whatever it was before running devinit on the GPU. As I was playing around with my patches today, it seems like that just reworking the runpm bits itself fixed it on my machine as well. Hopefully this will be enough for other laptops as well. Anyhow, it's a nice rework and if it's

When looking into the runpm issues, the first workaround I came up with was setting the PCIe link speed to whatever it was before running devinit on the GPU. As I was playing around with my patches today, it seems like that just reworking the runpm bits itself fixed it on my machine as well. Hopefully this will be enough for other laptops as well. Anyhow, it's a nice rework and if it's

https://bugs.freedesktop.org/show_bug.cgi?id=64772 Priority: medium Bug ID: 64772 Assignee: nouveau at lists.freedesktop.org Summary: nouveau GF108 kernel errors and graphics corruption when enabling second output QA Contact: xorg-team at lists.x.org Severity: normal Classification: Unclassified

Hello, I have installed git-kernel (3.2-rc3) with git-drm libs on debian. nvidiafb on terminals works fine, but loading of nouveau for Xorg fails. Maybe someone can help me or give me hints (what do I have to change?). The kernel produces the attached output. Best regards, Lars Callenbach ----- [ 6.971517] [drm] Initialized drm 1.1.0 20060810 [ 7.036085] [drm:drm_pci_init], [

https://bugs.freedesktop.org/show_bug.cgi?id=39330 Summary: nVidia GF108 [Quadro 1000M] gives: "PGRAPH: unsupported chipset, please report!" Product: xorg Version: git Platform: x86-64 (AMD64) OS/Version: Linux (All) Status: NEW Severity: normal Priority: medium Component:

https://bugs.freedesktop.org/show_bug.cgi?id=86794 Bug ID: 86794 Summary: Several nouveau related errors with xf86-video-nouveau with NVIDIA G92 [GeForce 9800 GT] and GF108 [GeForce GT 620] (rev a1). Product: xorg Version: unspecified Hardware: Other OS: All Status: NEW

https://bugs.freedesktop.org/show_bug.cgi?id=103467 Bug ID: 103467 Summary: [NVC0/GF108] fifo: read fault at cd90f4d000 engine 07 [PFIFO] client 07 [BAR_READ] reason 00 [PT_NOT_PRESENT] on channel 1 [003fe11000 DRM] Product: xorg Version: 7.7 (2012.06) Hardware: PowerPC OS: All

On Mon, Dec 10, 2018 at 10:00:08AM +0000, Guillaume Tucker wrote: > On 08/12/2018 00:08, Lyude Paul wrote: > > uhhhhhhhhhhhhh > > didn't we fix this weeks ago? with "drm/nouveau: tegra: Call > > nouveau_drm_device_init()" > > Yes here's the fix from Thierry: > > https://patchwork.freedesktop.org/patch/263587/ > > > and I can confirm

On Mon, Dec 10, 2018 at 02:25:59PM +0000, Mark Brown wrote: > On Mon, Dec 10, 2018 at 10:00:08AM +0000, Guillaume Tucker wrote: > > On 08/12/2018 00:08, Lyude Paul wrote: > > > uhhhhhhhhhhhhh > > > didn't we fix this weeks ago? with "drm/nouveau: tegra: Call > > > nouveau_drm_device_init()" > > > > Yes here's the fix from Thierry:

https://bugs.freedesktop.org/show_bug.cgi?id=79266 Priority: medium Bug ID: 79266 Assignee: nouveau at lists.freedesktop.org Summary: (two) GT 430 / GF108 sluggish, unstable performance and blue tint with vdpau QA Contact: xorg-team at lists.x.org Severity: major Classification: Unclassified OS:

hey, I'm seeing an Oops when nouveau loads (see below). I've verified that this is because both device->chip and device->name are NULL prior to the strncpy()s at the end of nvkm_udevice_info(). Bisect shows that this started happening after: commit 24d5ff40a732633dceab68c6559ba723784f4a68 Author: Karol Herbst <kherbst at redhat.com> Date: Tue Apr 28 18:54:02 2020 +0200

Using the kernel global workqueue to signal fences can lead to unexpected deadlocks. Some other work (e.g. from a different driver) could directly or indirectly depend on this fence to be signaled. However, if the WQ_MAX_ACTIVE limit is reached by waiters, this can prevent the work signaling the fence from running. While this seems fairly unlikely, it's potentially exploitable. Fixes: