similar to: [Bug 100035] New: nouveau runtime pm causes soft lockups and hangs during boot

On 21.03.19 18:12, Jerome Glisse wrote: > On Thu, Mar 21, 2019 at 04:59:14PM +0100, Tobias Klausmann wrote: >> Hi, >> >> just for your information and maybe for some help: with 5.1rc1 and SVM >> enabled i see the following backtrace [1] when the nouveau card (reverse >> prime) goes to sleep, for now i have papered over with [2] which leaves me >> with

On Tue, Jul 12, 2016 at 06:49:34PM +0200, Peter Wu wrote: > The FBIOPUT_CON2FBMAP ioctl takes a console_lock(). When this is called > while nouveau was runtime suspended, a deadlock would occur due to > nouveau_fbcon_set_suspend also trying to obtain console_lock(). > > Fix this by delaying the drm_fb_helper_set_suspend call. Based on the > i915 code (which was done for

On Wed, Jul 13, 2016 at 06:17:47PM +0100, Chris Wilson wrote: > On Tue, Jul 12, 2016 at 06:49:34PM +0200, Peter Wu wrote: > > The FBIOPUT_CON2FBMAP ioctl takes a console_lock(). When this is called > > while nouveau was runtime suspended, a deadlock would occur due to > > nouveau_fbcon_set_suspend also trying to obtain console_lock(). > > > > Fix this by delaying

When MST and atomic were introduced to nouveau, another structure that could contain a drm_connector embedded within it was introduced; struct nv50_mstc. This meant that we no longer would be able to simply loop through our connector list and assume that nouveau_connector() would return a proper pointer for each connector, since the assertion that all connectors coming from nouveau have a full

On Wed, Feb 21, 2018 at 01:39:34PM +0100, Rafael J. Wysocki wrote: > On Wednesday, February 21, 2018 10:57:14 AM CET Rafael J. Wysocki wrote: > > So if pci_pm_runtime_suspend() is modified to call pci_save_state() > > before returning 0 in the !dev->driver case, we can just move the > > pci_restore_standard_config() invocation in pci_pm_runtime_resume() up > > to the

On Wednesday, February 21, 2018 10:57:14 AM CET Rafael J. Wysocki wrote: > On Tue, Feb 20, 2018 at 10:29 PM, Bjorn Helgaas <helgaas at kernel.org> wrote: > > On Sun, Feb 18, 2018 at 09:38:32AM +0100, Lukas Wunner wrote: > >> PCI devices not bound to a driver are supposed to stay in D0 during > >> runtime suspend. > > > > Doesn't "runtime

https://bugs.freedesktop.org/show_bug.cgi?id=101553 Bug ID: 101553 Summary: [ 8.944203] nouveau 0000:01:00.0: DRM: failed to create kernel channel, -22 Product: xorg Version: unspecified Hardware: Other OS: All Status: NEW Severity: normal Priority: medium

From: Rafael J. Wysocki <rjw at rjwysocki.net> We leave PCI devices not bound to a driver in D0 during runtime suspend. But they may have a parent which is bound and can be transitioned to D3cold at runtime. Once the parent goes to D3cold, the unbound child may go to D3cold as well. When the child comes out of D3cold, its BARs are uninitialized and thus inaccessible when a driver tries to

On Sun, Sep 8, 2013 at 12:53 PM, Tobias Klausmann <tobias.johannes.klausmann at mni.thm.de> wrote: > Hi there, > with the latest snapshot of linus tree, i see a stack trace and my system > does not start X! Maybe someone finds this useful! (3.11 is working like a > charm) Looks like you have Optimus (intel + nvidia), and the backtrace has runtime pm in it, which is something new

On Tue, Feb 20, 2018 at 10:29 PM, Bjorn Helgaas <helgaas at kernel.org> wrote: > On Sun, Feb 18, 2018 at 09:38:32AM +0100, Lukas Wunner wrote: >> PCI devices not bound to a driver are supposed to stay in D0 during >> runtime suspend. > > Doesn't "runtime suspend" mean an individual device is suspended while > the rest of the system remains active? >

Hi Does anyone uses 2.6.25-3 kernel and xen-3.2? I have a problem with kernel 2.6.24. I find some patch for this kernel? Regards, Albert _______________________________________________ Xen-users mailing list Xen-users@lists.xensource.com http://lists.xensource.com/xen-users

This fixes some nasty issues I found in nouveau that were being caused looping through connectors using racy legacy methods, along with some caused by making incorrect assumptions about the drm_connector structs in nouveau's connector list. Most of these memory corruption issues could be reproduced by using an MST hub with nouveau. Cc: Karol Herbst <karolherbst at gmail.com> Cc: stable

When resuming from ACPI S3, memory leak happens in nvkm_ram_get(). This is because *pmemory points to newly allocated memory without checking and freeing the old memory. Here is the log showing this issue. unreferenced object 0xffffa3b608c6d5c0 (size 64): comm "kworker/u32:30", pid 934, jiffies 4294823520 (age 5000.217s) hex dump (first 32 bytes): 00 fc 4a c0 ff ff ff ff 00 00

This fixes some nasty issues I found in nouveau that were being caused looping through connectors using racy legacy methods, along with some caused by making incorrect assumptions about the drm_connector structs in nouveau's connector list. Most of these memory corruption issues could be reproduced by using an MST hub with nouveau. Next version of

On Sun, Feb 18, 2018 at 09:38:32AM +0100, Lukas Wunner wrote: > PCI devices not bound to a driver are supposed to stay in D0 during > runtime suspend. Doesn't "runtime suspend" mean an individual device is suspended while the rest of the system remains active? If so, maybe it would be more direct to say "PCI devices not bound to a driver cannot be runtime

Hi guys! I'm getting the following warn on 4.15-rc1, on GTX 560 Ti: [ 9.430433] nouveau 0000:01:00.0: NVIDIA GF114 (0ce000a1) ... [ 9.585172] nouveau 0000:01:00.0: bios: version 70.24.2e.00.02 ... [ 9.772204] nouveau 0000:01:00.0: fb: 1024 MiB GDDR5 [ 9.777342] ------------[ cut here ]------------ [ 9.782106] refcount_t: increment on 0; use-after-free. [ 9.787522] WARNING:

On Wed, Nov 09, 2016 at 06:17:44PM +0100, Hans de Goede wrote: > Various notebooks with nvidia GPUs generate an ACPI_VIDEO_NOTIFY_PROBE > acpi-video event when an external device gets plugged in (and again on > modesets on that connector), the default behavior in the acpi-video > driver for this is to send a KEY_SWITCHVIDEOMODE evdev event, which > causes e.g. gnome-settings-daemon

This is 4.16-rc1+todays git ona lowly P4 with NV5, worked fine in 4.15: [ 7.361155] nouveau 0000:01:00.0: NVIDIA NV05 (20154000) [ 7.386601] nouveau 0000:01:00.0: bios: version 02.05.19.03.00 [ 7.386715] nouveau 0000:01:00.0: bios: DCB table not found [ 7.386983] nouveau 0000:01:00.0: bios: DCB table not found [ 7.387166] nouveau 0000:01:00.0: bios: DCB table not found [

Hi, just for your information and maybe for some help: with 5.1rc1 and SVM enabled i see the following backtrace [1] when the nouveau card (reverse prime) goes to sleep, for now i have papered over with [2] which leaves me with userspace hangs. Any pointers where to look for the actual culprit? PS: Card is: nouveau 0000:01:00.0: NVIDIA GP106 (136000a1) Greetings, Tobias [1]: BUG: unable

The FBIOPUT_CON2FBMAP ioctl takes a console_lock(). When this is called while nouveau was runtime suspended, a deadlock would occur due to nouveau_fbcon_set_suspend also trying to obtain console_lock(). Fix this by delaying the drm_fb_helper_set_suspend call. Based on the i915 code (which was done for performance reasons though). Cc: Chris Wilson <chris at chris-wilson.co.uk> Cc: Daniel