Comme=
nt # 20
on bug 10913=
5
from iive@yahoo.com
(In reply to Alex Deucher from comment #12)
> (In reply to iive from comment #10)
[...]
> > Most of the new changes are done before RC1=
and it is quite common that
> > there are major breakages there, in systems we do not want to bot=
her with.
> > These breakages are usually fixed (or reverted) in later Release =
Candidates.
>=20
> This is not always the case; in most cases bisects are pretty smooth. =
If
> you run into unrelated problems with a particular commit, you can alwa=
ys
> skip it during the bisect (git bisect skip).
Let's say that they merge a change that breaks booting on my motherboard and
then they merge the radeon repo. Then they fix booting at rc2.
I will have to `git bisect skip` all commits between the boot-breaking merge
and rc2, as they all will produce broken kernels. Since all/most suspected
radeon commits are in this range, you can't bisect them.
One tick to avoid such problem is to do mass revert. Starting from the final
release (e.g. 4.19.0) and then reverting all commits in a given subsystem (=
e.g.
amdgpu) up to the previous release. Then doing the bisect in the reverted
commits.
If there are no interlinked changes, this method mostly works. But even sma=
ll
cosmetic changes or simple API modification outside the subsystem can
complicate things.
Anyway, bisect was done successfully.
I just still kind of don't understand why it landed on that commit.
It doesn't look like this is the commit that changes the default amdgpu.dpm
method.
Also, why not use dpm=3D1 for DPM and dpm=3D2 for PowerPlay?