Commen=
t # 12
on bug 92858<=
/a>
from Christian K=C3=B6nig
(In reply to Darren D. from comment #11)
> (In reply to Christian K=C3=B6nig from comment #10)
> And no, I didn't actually type
> all the commit tags below out, I simply copied and pasted the output f=
rom
> git bisect log' into the comment section.
Sorry, didn't know that git bisect log was so noisy.
>=20
> git bisect start
> # good: [b953c0d234bc72e8489d3bf51a276c5c4ec85345] Linux 4.1
> git bisect good b953c0d234bc72e8489d3bf51a276c5c4ec85345
> # bad: [d770e558e21961ad6cfdf0ff7df0eb5d7d4f0754] Linux 4.2-rc1
> git bisect bad d770e558e21961ad6cfdf0ff7df0eb5d7d4f0754
> # good: [4570a37169d4b44d316f40b2ccc681dc93fedc7b] Merge tag 'sound-4.=
2-rc1'
> of git://git.kernel.org/pub/scm/linux/kernel/git/tiwai/sound
> git bisect good 4570a37169d4b44d316f40b2ccc681dc93fedc7b
> # bad: [8d7804a2f03dbd34940fcb426450c730adf29dae] Merge tag
> 'driver-core-4.2-rc1' of
> git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/driver-core
> git bisect bad 8d7804a2f03dbd34940fcb426450c730adf29dae
> # good: [3d9f96d850e4bbfae24dc9aee03033dd77c81596] Merge tag 'armsoc-d=
t' of
> git://git.kernel.org/pub/scm/linux/kernel/git/arm/arm-soc
> git bisect good 3d9f96d850e4bbfae24dc9aee03033dd77c81596
> # bad: [692a59e696afe1a4e777d0e4359325336ab0ad89] drm/amdgpu: remove
> AMDGPU_CTX_OP_STATE_RUNNING
> git bisect bad 692a59e696afe1a4e777d0e4359325336ab0ad89
> # good: [81663016dbfd53e29d1b5c5ddbc9b12ae1d66474] drm/amdkfd: Add mod=
ule
> parameter of send_sigterm
> git bisect good 81663016dbfd53e29d1b5c5ddbc9b12ae1d66474
>=20
> Once again, the next kernel I built after telling git the revision sta=
rting
> with '8166301dbfd..' was good, and with about 172 commits left to bise=
ct,
> failed to boot. It got stuck at 'loading initial ramdisk,' the same pr=
oblem
> as I'd been running into during my previous builds. At least by doing =
it all
> over again I've confirmed it's nothing about the source I'm using, but=
I'm
> in the same position still. Is it actually ok to skip revisions until =
the
> kernel I built at least boots?
In this case I would suggest to just say git bisect bad until you find a ke=
rnel
that boots again and then continue till you either have the commit which ca=
uses
the radeon problem or the boot problem.
If it's the radeon problem you find first than we can just continue analyzi=
ng
it.
And if it's the boot lockup problem then please note the commit hash and I =
will
try to figure out what's going wrong here. This way you should be able to
finally dig up what's the issue with radeon.
Thanks for sticking with that.