4.20.0-rc3 nouveau/Quadro P2000 Mobile: runpm causing ACPI errors, lockups
Michael S. Tsirkin
mst at redhat.com
Wed Nov 28 20:30:21 UTC 2018
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 unlikely to be
> > an actual issue simply because we end up not using DSM in the end.
>
> I agree.
>
> > Poking at the probing code in nouveau_pr3_present, I started to wonder:
> > should I try to hack it to disable d3cold and pr3 and see what
> > happens?
>
> I guess it is worth a try. You can do it from sysfs for the graphics
> PCI device there is an attribute d3cold_allowed that controls this.
>
> [snip]
But probably too late by time nouveau is up at boot?
> > > > 00:14.3 Network controller: Intel Corporation Wireless-AC 9560 [Jefferson Peak] (rev 10)
> > > >
> > > > so really shouldn't be affected, but go figure. If driver really is getting
> > > > all-ones from the device, it just might try to poke at a wrong b:d.f by mistake
> > > > maybe ...
> > >
> > > Or it the power resource is shared by wifi as well.
> >
> > Is there a way to find out through e.g. sysfs?
>
> It is not shared, I checked from the acpidump you provided. Possibly the
> infinite loop in AML when executing NVPO method have some effect on
> this.
>
> [snip]
>
> > > No need to send, I can read it from the bugzilla just fine. Can you attach
> > > acpidump there as well?
> >
> > Done. lspci -x too just in case.
>
> Looking at the dmesg:
>
> [ 52.917009] No Local Variables are initialized for Method [NVPO]
> [ 52.917011] No Arguments are initialized for method [NVPO]
> [ 52.917012] ACPI Error: Method parse/execution failed \_SB.PCI0.PEG0.PEGP.NVPO, AE_AML_LOOP_TIMEOUT (20181003/psparse-516)
> [ 52.917063] ACPI Error: Method parse/execution failed \_SB.PCI0.PGON, AE_AML_LOOP_TIMEOUT (20181003/psparse-516)
> [ 52.917084] ACPI Error: Method parse/execution failed \_SB.PCI0.PEG0.PG00._ON, AE_AML_LOOP_TIMEOUT (20181003/psparse-516)
>
> So what happens here is that Linux turns off power resource
> \_SB.PCI0.PEG0.PG00 by calling its _OFF method (happens when the root
> port is runtime suspended). This ends up calling \_SB.PCI0.PGON which
> calls \_SB.PCI0.PEG0.PEGP.NVPO.
>
> The last method looks like this:
>
> Method (NVPO, 0, NotSerialized)
> {
> While ((\_SB.PCI0.P0LS < 0x03))
> {
> Sleep (One)
> }
>
> So basically it polls P0LS register infinitely if the returned value is
> less than 3. I suspect this is the issue and it then makes the other
> like wifi to fail to execute its methods.
>
> P0LS comes from this operation region:
>
> OperationRegion (OPG0, SystemMemory, (XBAS + 0x8000), 0x1000)
> Field (OPG0, AnyAcc, NoLock, Preserve)
> {
> ...
> Offset (0x216),
> P0LS, 4,
>
> This is some host bridge register but not sure which because XBAS value
> cannot be determined from the acpidump.
Oh I think XBAS is in SSDT4:
OperationRegion (SANV, SystemMemory, 0x4FBF7018, 0x01F4)
Field (SANV, AnyAcc, Lock, Preserve)
{
ASLB, 32,
IMON, 8,
IGDS, 8,
IBTT, 8,
IPAT, 8,
IPSC, 8,
IBIA, 8,
ISSC, 8,
IDMS, 8,
IF1E, 8,
HVCO, 8,
GSMI, 8,
PAVP, 8,
CADL, 8,
CSTE, 16,
NSTE, 16,
NDID, 8,
DID1, 32,
DID2, 32,
DID3, 32,
DID4, 32,
DID5, 32,
DID6, 32,
DID7, 32,
DID8, 32,
DID9, 32,
DIDA, 32,
DIDB, 32,
DIDC, 32,
DIDD, 32,
DIDE, 32,
DIDF, 32,
DIDX, 32,
NXD1, 32,
NXD2, 32,
NXD3, 32,
NXD4, 32,
NXD5, 32,
NXD6, 32,
NXD7, 32,
NXD8, 32,
NXDX, 32,
LIDS, 8,
KSV0, 32,
KSV1, 8,
BRTL, 8,
ALSE, 8,
ALAF, 8,
LLOW, 8,
LHIH, 8,
ALFP, 8,
IPTP, 8,
EDPV, 8,
SGMD, 8,
SGFL, 8,
SGGP, 8,
HRE0, 8,
HRG0, 32,
HRA0, 8,
PWE0, 8,
PWG0, 32,
PWA0, 8,
P1GP, 8,
HRE1, 8,
HRG1, 32,
HRA1, 8,
PWE1, 8,
PWG1, 32,
PWA1, 8,
P2GP, 8,
HRE2, 8,
HRG2, 32,
HRA2, 8,
PWE2, 8,
PWG2, 32,
PWA2, 8,
DLPW, 16,
DLHR, 16,
EECP, 8,
XBAS, 32,
GBAS, 16,
NVGA, 32,
NVHA, 32,
AMDA, 32,
LTRX, 8,
OBFX, 8,
LTRY, 8,
OBFY, 8,
LTRZ, 8,
OBFZ, 8,
LTRW, 8,
OBFA, 8,
SMSL, 16,
SNSL, 16,
P0UB, 8,
P1UB, 8,
P2UB, 8,
P3UB, 8,
PCSL, 8,
PBGE, 8,
M64B, 64,
M64L, 64,
CPEX, 32,
EEC1, 8,
EEC2, 8,
SBN0, 8,
SBN1, 8,
SBN2, 8,
M32B, 32,
M32L, 32,
P0WK, 32,
P1WK, 32,
P2WK, 32,
VTDS, 8,
VTB1, 32,
VTB2, 32,
VTB3, 32,
VE1V, 16,
VE2V, 16,
SBN3, 8,
P3GP, 8,
HRE3, 8,
HRG3, 32,
HRA3, 8,
PWE3, 8,
PWG3, 32,
PWA3, 8,
P3WK, 32,
EEC3, 8,
RPIN, 8,
RPBA, 32,
Offset (0x1F4)
}
If my math is correct, this is offset 1456 bits, ie 0xb6
bytes, and so 0x4fbf70ce
XBAS + 0x8000 is 0x4fbff0ce ?
cat /proc/iomem shows that this is
4ee5f000-4fca0fff : ACPI Non-volatile Storage
--
MST
More information about the dri-devel
mailing list