Comment=
# 6
on bug 66425<=
/a>
from Christian K=C3=B6nig
(In reply to comment #5=
)
> Pretty sure the instability has nothing to do wi=
th this.
Good to know, well at least this bug loses a bit priority then.
> As far as I can tell, this would happen whenever=
the system suspend fails
> after deactivating the drivers and the PM system restarts everything w=
hen
> the system hasn't actually suspended. The "pm_test" file ju=
st seems to
> cause an error return value at an appropriate point in the suspend cod=
e.
> When the system actually sleeps the uvd suspend code seems fine, but i=
f it
> doesn't sleep then there is this delay.
Oh! Do I get this right that it only happens when you try to suspend the sy=
stem
but then doesn't really do the power cycle (for whatever reason)?
Well that would explain it, cause thise case isn't really supported by the
hardware. A complete manual reset of the UVD block (without an external pow=
er
cycle) is somewhere between very very tricky and impossible.
> I'm not sure if this would help in making a work=
-around.
At least it explains the behavior. We could try to get it working by playing
around with the different soft reset methods, but I have my doubts that this
will ever work correctly.