Comment # 11
on bug 92858
from Darren D.
(In reply to Christian König 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 over, 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 tree and began my bisect again, using 4.1.0 as my good starting point and 4.2-rc1 as my bad starting point. And no, I didn't actually type all the commit tags below 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 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? I'm not aware of another method that I can use, but What if one of these commits that causes the build process to produce an unbootable kernel is the bad one, and by skipping it I've made it impossible to identify it as the initial bad commit?
You are receiving this mail because:
- You are the assignee for the bug.
_______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx http://lists.freedesktop.org/mailman/listinfo/dri-devel
