similar to: [Bug 108873] New: nouveau/Quadro P2000 Mobile: runpm causing ACPI errors, lockups

On Tue, Nov 27, 2018 at 09:49:44PM -0500, Michael S. Tsirkin wrote: > On Tue, Nov 27, 2018 at 11:36:50AM +0200, Mika Westerberg wrote: > > +linux-acpi > > > > Hi Michael, > > > > On Mon, Nov 26, 2018 at 10:53:26PM -0500, Michael S. Tsirkin wrote: > > > So a new thinkpad: > > > 01:00.0 VGA compatible controller: NVIDIA Corporation GP107GLM

+linux-acpi Hi Michael, On Mon, Nov 26, 2018 at 10:53:26PM -0500, Michael S. Tsirkin wrote: > So a new thinkpad: > 01:00.0 VGA compatible controller: NVIDIA Corporation GP107GLM [Quadro P2000 Mobile] (rev a1) > > Hangs whenever I try to poke at the card. It starts happily enough with > > [ 3.971515] ACPI Warning: \_SB.PCI0.GFX0._DSM: Argument #4 type mismatch - Found

On Wed, Nov 28, 2018 at 01:08:57PM +0200, Mika Westerberg wrote: > On Tue, Nov 27, 2018 at 09:49:44PM -0500, Michael S. Tsirkin wrote: > > On Tue, Nov 27, 2018 at 11:36:50AM +0200, Mika Westerberg wrote: > > > +linux-acpi > > > > > > Hi Michael, > > > > > > On Mon, Nov 26, 2018 at 10:53:26PM -0500, Michael S. Tsirkin wrote: > > >

So a new thinkpad: 01:00.0 VGA compatible controller: NVIDIA Corporation GP107GLM [Quadro P2000 Mobile] (rev a1) Hangs whenever I try to poke at the card. It starts happily enough with [ 3.971515] ACPI Warning: \_SB.PCI0.GFX0._DSM: Argument #4 type mismatch - Found [Buffer], ACPI requires [Package] (20181003/nsarguments-66) [ 3.971553] ACPI Warning: \_SB.PCI0.PEG0.PEGP._DSM: Argument #4

On Tue, Nov 27, 2018 at 11:36:50AM +0200, Mika Westerberg wrote: > +linux-acpi > > Hi Michael, > > On Mon, Nov 26, 2018 at 10:53:26PM -0500, Michael S. Tsirkin wrote: > > So a new thinkpad: > > 01:00.0 VGA compatible controller: NVIDIA Corporation GP107GLM [Quadro P2000 Mobile] (rev a1) > > > > Hangs whenever I try to poke at the card. It starts happily

On Wed, Nov 28, 2018 at 10:09:22AM -0500, Michael S. Tsirkin wrote: > Yea all this is weird, in particular I wonder why does everyone > using dsm insists on saying Arg4 > when they actually mean Arg3. ACPI numbers arguments from 0. > > So it's a bit ugly, and maybe worth fixing but unlikely to be > an actual issue simply because we end up not using DSM in the end. I agree.

this was already debugged and there is no point in searching inside the Firmware. It's not a firmware bug or anything. The proper fix is to do something inside Nouveau so that we don't upset the device and being able to runtime resume it again. The initial thing we do inside Nouveau to cause those issues is to run that so called "DEVINIT" script inside the vbios to initialize

On Wed, Nov 28, 2018 at 05:55:44PM +0200, Mika Westerberg wrote: > On Wed, Nov 28, 2018 at 10:09:22AM -0500, Michael S. Tsirkin wrote: > > Yea all this is weird, in particular I wonder why does everyone > > using dsm insists on saying Arg4 > > when they actually mean Arg3. ACPI numbers arguments from 0. > > > > So it's a bit ugly, and maybe worth fixing but

On Tue, Nov 26, 2019 at 06:10:36PM -0500, Lyude Paul wrote: > Hey-this is almost certainly not the right place in this thread to respond, > but this thread has gotten so deep evolution can't push the subject further to > the right, heh. So I'll just respond here. :) > I've been following this and helping out Karol with testing here and there. > They had me test

anybody any other ideas? It seems that both patches don't really fix the issue and I have no idea left on my side to try out. The only thing left I could do to further investigate would be to reverse engineer the Nvidia driver as they support runpm on Turing+ GPUs now, but I've heard users having similar issues to the one Lyude told us about... and I couldn't verify that the patches

On Wed, Nov 27, 2019 at 12:49 PM Mika Westerberg <mika.westerberg at intel.com> wrote: > > On Tue, Nov 26, 2019 at 06:10:36PM -0500, Lyude Paul wrote: > > Hey-this is almost certainly not the right place in this thread to respond, > > but this thread has gotten so deep evolution can't push the subject further to > > the right, heh. So I'll just respond here.

On Wed, 2019-11-27 at 12:51 +0100, Karol Herbst wrote: > On Wed, Nov 27, 2019 at 12:49 PM Mika Westerberg > <mika.westerberg at intel.com> wrote: > > On Tue, Nov 26, 2019 at 06:10:36PM -0500, Lyude Paul wrote: > > > Hey-this is almost certainly not the right place in this thread to > > > respond, > > > but this thread has gotten so deep evolution

On Mon, Dec 9, 2019 at 12:17 PM Karol Herbst <kherbst at redhat.com> wrote: > > anybody any other ideas? Not yet, but I'm trying to collect some more information. > It seems that both patches don't really fix > the issue and I have no idea left on my side to try out. The only > thing left I could do to further investigate would be to reverse > engineer the Nvidia

On Thu, Nov 29, 2018 at 2:29 AM Michael S. Tsirkin <mst at redhat.com> wrote: > > On Thu, Nov 29, 2018 at 12:21:31AM +0100, Karol Herbst wrote: > > this was already debugged and there is no point in searching inside > > the Firmware. It's not a firmware bug or anything. > > > > The proper fix is to do something inside Nouveau so that we don't > >

[big snip] > There is a sysfs attribute called "d3cold_allowed" which can be used > for "blocking" D3cold, so can you please retest using that? > Hey-this is almost certainly not the right place in this thread to respond, but this thread has gotten so deep evolution can't push the subject further to the right, heh. So I'll just respond here. I've been

On Thu, Nov 29, 2018 at 11:53:53AM +0100, Karol Herbst wrote: > On Thu, Nov 29, 2018 at 2:29 AM Michael S. Tsirkin <mst at redhat.com> wrote: > > > > On Thu, Nov 29, 2018 at 12:21:31AM +0100, Karol Herbst wrote: > > > this was already debugged and there is no point in searching inside > > > the Firmware. It's not a firmware bug or anything. > > >

On Thu, Nov 29, 2018 at 12:21:31AM +0100, Karol Herbst wrote: > this was already debugged and there is no point in searching inside > the Firmware. It's not a firmware bug or anything. > > The proper fix is to do something inside Nouveau so that we don't > upset the device and being able to runtime resume it again. > > The initial thing we do inside Nouveau to cause

Hello. Minimal testcase for my problem: No X running, just a TTY. Use of the nouveau kernel module as of today (or any older) with an up to date vanilla kernel. Hardware: DELL Vostro 3500 with Geforce 310M. To suspend to ram I use this script, as suggested in Documentation/power/s2ram.txt: #!/bin/sh sync echo 1 > /sys/power/pm_trace echo mem > /sys/power/state When I try to suspend to

Hello All, ?I have a Dell Vostro 1550 laptop. i3 core, 64 bit, 8gb ram etc etc. I had a nic interface, but some how the wired nic is not working. So I am trying to use the BCM 4313 wireless chip, of this system, to connect to the internet. ?I have Cent os 6.5 (64 bit) installed with the required libraries and kernel sources, headers etc. I got the source code of the driver,

Hi guys, I have a problem with my Centos 6.4. I am experiencing a Wireless Disconnects, some time ago I had them constantly each 2-3minutes. After upgrading to new kernel (and other software from "Software Update" I am still exepriencing disconnects but every 10-15 minutes. It makes me angry because I am doing a lot of work with ftp servers. Card: *Atheros Communications Inc. AR9285