Commen=
t # 11
on bug 92858<=
/a>
from Darren D.
(In reply to Christian K=C3=B6nig from comment #10)
There's been several delays and I've mostly made no progress, but I thought=
I
should at the least provide an update. The kernels I was building kept not
booting and I thought it unwise to keep skipping revisions, so I started ov=
er,
thinking perhaps something had corrupted or messed up my source. I built and
booted a 4.2-rc1 kernel to see if the problem had started by then, and after
comfirming acceleration didn't function under it, I re-cloned Linus's git t=
ree
and began my bisect again, using 4.1.0 as my good starting point and 4.2-rc=
1 as
my bad starting point. And no, I didn't actually type all the commit tags b=
elow
out, I simply copied and pasted the output from git bisect log' into the
comment section.
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-dt' 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 module
parameter of send_sigterm
git bisect good 81663016dbfd53e29d1b5c5ddbc9b12ae1d66474
Once again, the next kernel I built after telling git the revision starting
with '8166301dbfd..' was good, and with about 172 commits left to bisect,
failed to boot. It got stuck at 'loading initial ramdisk,' the same problem=
as
I'd been running into during my previous builds. At least by doing it all o=
ver
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? I'm not aware of another method that I can use, but W=
hat
if one of these commits that causes the build process to produce an unboota=
ble
kernel is the bad one, and by skipping it I've made it impossible to identi=
fy
it as the initial bad commit?