Commen=
t # 16
on bug 54437<=
/a>
from Kelly Doran
(In reply to comment #=
13)
> (In reply to comment #12)
> > This bug is affecting me also, see the last duplicated bug. Any p=
rogress in
> > fixing this? Maybe some help in testing (for ex.) required?
>=20
> It's a bit of a mystery unfortunately. Adding to the annoyance, Ben sa=
id
> that it does work just fine on his NVC8, although he has the less powe=
rful
> versions. Could be something with high ROP/TPC/GPC counts not being ha=
ndled.
> (Or multiple PARTs?)
>=20
> That might actually be an interesting experiment -- before loading nou=
veau,
> mask out a bunch of the units and see if it helps. If it does, find the
> "breaking" point.
>=20
> This is the code that computes that stuff:
>=20
> http://cgit.freedesktop.org/~darktama/nouveau/tree/nvkm/eng=
ine/graph/nvc0.
> c#n1330
>=20
> priv->rop_nr =3D (nv_rd32(priv, 0x409604) & 0x001f0000) >&g=
t; 16;
> priv->gpc_nr =3D nv_rd32(priv, 0x409604) & 0x0000001f;
> for (i =3D 0; i < priv->gpc_nr; i++) {
> priv->tpc_nr[i] =3D nv_rd32(priv, GPC_UNIT(i, 0x2608));
> priv->tpc_total +=3D priv->tpc_nr[i];
> }
>=20
> Step 1: Print out the various values (i.e. number of ROPs, GPCs, and t=
he
> per-GPC TPC counts).
> Step 2: Artificially lower them (to, e.g., 1) and see if it helps. If =
it
> does, figure out which of the values matter and where the breaking poi=
nts
> are.
>=20
> If it doesn't help, perhaps the units need to be disabled a little har=
der,
> e.g. by setting 0x22584/0x22588.
Heres the printed out values:
[ 3.185455] Rop nr: 6
[ 3.185457] Gpc nr: 4
[ 3.185460] Tpc nr for gpc 0: 4
[ 3.185463] Tpc nr for gpc 1: 4
[ 3.185466] Tpc nr for gpc 2: 4
[ 3.185469] Tpc nr for gpc 3: 4
I tried setting them all to 1, the card freezes pretty much immediately aft=
er
logging into kwin (which is when I suspect opengl rendering starts), althou=
gh
oddly enough there was no read fault in the dmesg. I also tried setting th=
em
all to 2, and it froze pretty quickly too, and the machine became completely
unrecoverable. Note that I also tried using the blob firmware with all val=
ues
set to 2, so I think not having them at their natural amounts simply pisses=
the
card off. Didn't try directly disabling stuff with 0x22584/0x22588, not
entirely sure where I would do that even.