Bug 92858

(In reply to Darren from comment #0)
> The section pasted above of the dmesg from kernel 4.3-rc-7 indicates the
> driver is failing on the "drm:r600_ringtest"...however, this is not a r600
> card but a Southern Islands.

Yeah, indeed the very basic test if the command process is up and running didn't worked. Because of this the driver pretty much disables itself, except for bringing up a picture to the screen.

That r600_ringtest is used for a Verde is perfectly normal, we only got r100_ringtest, r300_ringtest and r600_ringtest for the different hardware generations.

> Steps taken while attempting to resolve the issue: I'd initiallly thought it
> could be a firmware issue, with the linux-firmware package in the distro
> perhaps not having been updated to support the latest kernels, but even when
> I installed linux-firmware-git from the AUR to replace the standard
> linux-firmware package and then booted linux 4.3-rc7, mesa was still using
> llvmpipe instead of radeonsi, due to no GPU accel. I've also compiled the
> 4.3.0 kernel using the tarball directly from kernel.org, and a default
> kernel configuration file from ubuntu. When I booted into the 4.3.0 upstream
> kernel, GPU acceleration was still disabled. As neither the source nor the
> kernel config were from Manjaro, doesn't this rule out a distro bug and
> indicate the issue is upstream?

Yes that sounds like somewhere between 4.1 and 4.2 a patch broke the support for Verde.

As far as I know we didn't changed anything related to Verde between 4.1 and 4.2.

Can you get the kernel source using git and then run "git bisect start v4.2 v4.1" to figure out which patch exactly caused the regression?

(In reply to Christian König from comment #1)
> (In reply to Darren from comment #0)
> > The section pasted above of the dmesg from kernel 4.3-rc-7 indicates the
> > driver is failing on the "drm:r600_ringtest"...however, this is not a r600
> > card but a Southern Islands.
> 
> Yeah, indeed the very basic test if the command process is up and running
> didn't worked. Because of this the driver pretty much disables itself,
> except for bringing up a picture to the screen.
> 
> That r600_ringtest is used for a Verde is perfectly normal, we only got
> r100_ringtest, r300_ringtest and r600_ringtest for the different hardware
> generations.
> 
> > Steps taken while attempting to resolve the issue: I'd initiallly thought it
> > could be a firmware issue, with the linux-firmware package in the distro
> > perhaps not having been updated to support the latest kernels, but even when
> > I installed linux-firmware-git from the AUR to replace the standard
> > linux-firmware package and then booted linux 4.3-rc7, mesa was still using
> > llvmpipe instead of radeonsi, due to no GPU accel. I've also compiled the
> > 4.3.0 kernel using the tarball directly from kernel.org, and a default
> > kernel configuration file from ubuntu. When I booted into the 4.3.0 upstream
> > kernel, GPU acceleration was still disabled. As neither the source nor the
> > kernel config were from Manjaro, doesn't this rule out a distro bug and
> > indicate the issue is upstream?
> 
> Yes that sounds like somewhere between 4.1 and 4.2 a patch broke the support
> for Verde.
> 
> As far as I know we didn't changed anything related to Verde between 4.1 and
> 4.2.
> 
> Can you get the kernel source using git and then run "git bisect start v4.2
> v4.1" to figure out which patch exactly caused the regression?

I downloaded the kernel source via git, using "git clone https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git," then I changed directory into the folder it created, called "linux."

I then ran "git bisect start v4.2 v4.1" and the output was:

"Bisecting: 7353 revisions left to test after this (roughly 13 steps)
[c11d716218910c3aa2bac1bb641e6086ad649555] Merge tag 'armsoc-cleanup' of git://git.kernel.org/pub/scm/linux/kernel/git/arm/arm-soc"

I'm not to up to speed on git bisect, but don't I need to declare a good revision first so bisect has somewhere to start? Also, in order to declare a good revision, I'd need to compile the whole kernel again starting with the initial git commit during the 4.2 merge window, wouldn't I?

The above "git clone" command checks out the source for the latest kernel (not sure about which if any kernel history it downloads,) no? And if I compile using it, wouldn't it build 4.3.0 instead of an earlier revision?

To summarize, I'm very much a newcomer to git--if I needed to install a kernel before, I would use AUR packages, or in the case of beginner friendly distributions like Ubuntu, would simply grab the latest kernel from a PPA. I can copy and paste commands, learned what "--depth=X" does-in the event I needed to download without history-while building the nouveau kernel tree back when I had a nVidia GPU, but I'm not otherwise too experienced. Can you point me to the best resource/s on learning git and how to identify what those long strings of text like "c11d716218910c3aa2bac1bb641e6086ad649555" indicate and what to do to isolate a good revsion so bisect can start at it?

Thanks!

Well you are already doing quite fine and as far as I understand you are capable to build your own kernel from source and that's everything you need.

I will try to explain the rest step by step in detail and what the commands do.

First of all the long strings of text like "c11d716218910c3aa2bac1bb641e6086ad649555" are hash code, which identify a patch or change in the history of the kernel development.

Each change the developers did between 4.1 and 4.2 has such a hash code which is basically just a fingerprint of the whole source code at that moment.

When you initially clone a source repository using "git clone" it indeed checks out the latest version by default.

Now you already did "git bisect start v4.2 v4.1" in the newly created source directory which tells git that version 4.2 is bad and version 4.1 is good.

This command than takes a look at all the changes between version 4.1 and 4.2 and then jumps into the middle of this list. In your case that is commit "[c11d716218910c3aa2bac1bb641e6086ad649555] Merge tag 'armsoc-cleanup' of...".

This commit is now checked out and you can build, install and test the kernel.

Then you go into the directory again and do "git bisect good" if the newly build kernel works and if it doesn't work you do "git bisect bad".

Git will then look at the list of changes again and jumps either toward the direction of version 4.1 or 4.2 (depends on if you said good or bad) and then checks out the next change to test.

This repeats roughly 13 times until git found the change which caused your problems.

All you need to do is making sure you always boot the latest installed kernel. By default grub for example will boot the kernel with the highest version number.

Thanks you again for the guide--it was simple and human-readable and I understood the directions, I think. Sadly, as of thus far, every kernel I've compiled panics at bootup, with a message like this, or similar: "kernel panic. vfs unable to mount root on unknown block (0,0)". I'd take a screencapture but there's no way to do so until X is up, and this is before X is started. I've used a config file I built myself via make menuconfig, the default ubuntu 4.3 kernel config file, and the distro's current running kernel (4.1.12) config, obtaining by "zcat /proc/config.gz > .config. The same message occurred under all three of the kernels I built.

I'll keep on compiling in the meantime until I isolate the problem, but I did have one question: Let's assume the first kernel I compile boots and acceleration works. After I get the kernel to compile and boot, do I need to run "make clean" in the source tree directory after "git bisect good," or is that going to strip away files that git bisect needs in order to keep a record of good and bad commits?

(In reply to Darren from comment #5)
> Sadly, as of thus far, every kernel I've compiled panics at bootup, with a
> message like this, or similar: "kernel panic. vfs unable to mount root on
> unknown block (0,0)".

Sounds like there's a problem with the .config or maybe the root=[...] parameter on the kernel command line. For .config, I'd recommend starting with the original .config from 4.3-rc7 and then just running "make oldconfig".


> After I get the kernel to compile and boot, do I need to run "make clean" in
> the source tree directory after "git bisect good," or is that going to strip
> away files that git bisect needs in order to keep a record of good and bad
> commits?

make clean is neither necessary nor does it hurt (other than potentially increasing the build time of the next kernel to test).

(In reply to Michel Dänzer from comment #6)
> (In reply to Darren from comment #5)
> > Sadly, as of thus far, every kernel I've compiled panics at bootup, with a
> > message like this, or similar: "kernel panic. vfs unable to mount root on
> > unknown block (0,0)".
> 
> Sounds like there's a problem with the .config or maybe the root=[...]
> parameter on the kernel command line. For .config, I'd recommend starting
> with the original .config from 4.3-rc7 and then just running "make
> oldconfig".
> 
> 

And that helped--in a sense. It produced a kernel that would at least boot partially instead of a kernel panic, but the boot froze on the distro splash screen. It's progress, though! I edited grub.cfg (I've read not to do this, but it was a temporary modification to test a theory) to use "nosplash" instead of "splash" on the kernel command lin grub entry for the kernel I'd compiled, and once I booted that kernal again, I noticied a 'could not locate modules: template  usr/lib/modules/$KERNELVERSION" type of error. Again, no way to screenshot it as it was early in the boot process.

I'm guessing now I've discovered the problem: Renaming the /usr/lib/modules/$KERNELVERSION directory to something different than what the "make modules_install" command named it when it built the directory--and prior to running the mkinitcpio command to build the initial ramdisk--is a bad idea. Live and learn.

I'm back on track now, and with any luck and free time between day job and sleep, eventually I'll have a bootable kernel compiled soon so I can actually start bisecting to locate the bad commit.

(In reply to Darren D. from comment #7)
> I'm back on track now, and with any luck and free time between day job and
> sleep, eventually I'll have a bootable kernel compiled soon so I can
> actually start bisecting to locate the bad commit.

Well, don't give up. That sounds like a rather normal learning curve to me.

Just let us know when you have any result or are stuck at some point.

(In reply to Christian König from comment #8)

> 
> Well, don't give up. That sounds like a rather normal learning curve to me.
> 
> Just let us know when you have any result or are stuck at some point.

I've made some slow but sure progress, but now I'm stuck--I'm reporting as per your request, but it sounds like a config bug perhaps and not bad code?

[myusername@computer myusername] cd kernel/linux/

[myusername@computer linux]$ git bisect log
# bad: [64291f7db5bd8150a74ad2036f1037e6a0428df2] Linux 4.2
# good: [b953c0d234bc72e8489d3bf51a276c5c4ec85345] Linux 4.1
git bisect start 'v4.2' 'v4.1'
# good: [c11d716218910c3aa2bac1bb641e6086ad649555] Merge tag 'armsoc-cleanup' of git://git.kernel.org/pub/scm/linux/kernel/git/arm/arm-soc
git bisect good c11d716218910c3aa2bac1bb641e6086ad649555
# bad: [e44ac588cd61c960226d61c379e2873a95544a51] drivers/block/nvme-core.c: fix build with gcc-4.4.4
git bisect bad e44ac588cd61c960226d61c379e2873a95544a51
# bad: [e382608254e06c8109f40044f5e693f2e04f3899] Merge tag 'trace-v4.2' of git://git.kernel.org/pub/scm/linux/kernel/git/rostedt/linux-trace
git bisect bad e382608254e06c8109f40044f5e693f2e04f3899
# bad: [c5fd936e992dd2829167d2adc63e151675ca6898] drm/nouveau: Pause between setting gpu to D3hot and cutting the power
git bisect bad c5fd936e992dd2829167d2adc63e151675ca6898
[myusername@dcomputer linux]$ 

The kernel I build after I tell git bisect the above revision is bad freezes on "loading initial ramdisk." I've attempted to rebuild the kernel after cleaning the source tree, and in the event my CPU needs the intel microcode, I've verified the intel-ucode package is installed and that the following are enabled in my .config file:

CONFIG_MICROCODE=y, CONFIG_MICROCODE_INTEL=y, CONFIG_MICROCODE_INTEL_EARLY=y, CONFIG_MICROCODE_EARLY=y, and CONFIG_MICROCODE_OLD_INTERFACE=y

Neither of the above resolved the freezeup. Should I simply build everything into the kernel I can instead of as modules, so the kernel ideally won't need whatever should be in the initramfs but isn't, and can boot up successully? If this isn't the correct place to ask I'll be happy to report it elsewhere, but if you have any suggestions that could help me along, I'll implement those and make another attempt.

That looks promising. Here are a few hints how to proceed.

> git bisect good c11d716218910c3aa2bac1bb641e6086ad649555
First of all you don't need to always specify the commit, git knows that by itself. E.g. "git bisect good" without the commit hash should be sufficient.

(In reply to Darren D. from comment #9)
> git bisect bad c5fd936e992dd2829167d2adc63e151675ca6898
> 
> The kernel I build after I tell git bisect the above revision is bad freezes
> on "loading initial ramdisk."

That's unfortunate but happens sometimes. Since c5fd936e992dd2829167d2adc63e151675ca6898 is bad the problem must be somewhere between v4.1 and c5fd936e992dd2829167d2adc63e151675ca6898.

Since it is a radeon driver problem I suggest you limit bisect to only test the changes made to radeon.

Please try the command "git bisect start c5fd936e992dd2829167d2adc63e151675ca6898 v4.1 drivers/gpu/drm/radeon/".

If that still doesn't work try "git bisect skip" if you have a commit that won't work at all.

If that also doesn't work just go on with "git bisect good/bad" and try to figure out when the issue with the ramdisk started.

(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?

(In reply to Darren D. from comment #11)
> (In reply to Christian König from comment #10)
> 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.

Sorry, didn't know that git bisect log was so noisy.

> 
> 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?

In this case I would suggest to just say git bisect bad until you find a kernel that boots again and then continue till you either have the commit which causes the radeon problem or the boot problem.

If it's the radeon problem you find first than we can just continue analyzing 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.

(In reply to Christian König from comment #12)

> 
> In this case I would suggest to just say git bisect bad until you find a
> kernel that boots again and then continue till you either have the commit
> which causes the radeon problem or the boot problem.
> 
> If it's the radeon problem you find first than we can just continue
> analyzing 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.

Another update: I think I'm either finished or close to finished--shouldn't bisect say which of the revisions is bad once i get down to 0, though?

Bisecting: 0 revisions left to test after this (roughly 0 steps)
[bdcddf95e82b1c4e370fc1196b1f4f50f775dab4] Backmerge v4.1-rc4 into into drm-next

Please see below for output of "git bisect log' listing the commits bisected, following your advice about telling git the non-bootable revisions were bad and moving on until I found one that compiled a bootable kernel. Any bisects that say bad after 81663016dbfd53e29d1b5c5ddbc9b12ae1d66474 are marked bad not because of lack of accel, but because they didn't boot up. I was able to locate, however, the next bootable kernel after the 'initial ramdisk" boot failures started. Commit ID 744b058827b3db9a4f6027522dd9c73a208c2d31, and it both booted and had functional accelerated OpenGL on the videocard.

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
# bad: [992839ad64f21ff4e5ed0a71691098ab7cfcb9dc] drm/amdkfd: Add static user-mode queues support
git bisect bad 992839ad64f21ff4e5ed0a71691098ab7cfcb9dc
# bad: [ff0b187f92f61503c8af67d3dc5e6e91fbe2f9cc] drm/i915: Add a space after ', ' and don't capitalize mid-sentence
git bisect bad ff0b187f92f61503c8af67d3dc5e6e91fbe2f9cc
# bad: [f3e06f1156f1adf17dc44144ad3b774c2d414e47] drm/i915/gtt: Fix the boundary check for vm area
git bisect bad f3e06f1156f1adf17dc44144ad3b774c2d414e47
# good: [744b058827b3db9a4f6027522dd9c73a208c2d31] drm/atomic: remove duplicated assignment of old_plane_state
git bisect good 744b058827b3db9a4f6027522dd9c73a208c2d31
# bad: [b6e742f652791919ce5c8e05a1d664bcbc5111a6] drm/i915: Be optimistic about future display engines having 7 WM levels
git bisect bad b6e742f652791919ce5c8e05a1d664bcbc5111a6
# good: [91d9f9856f91c82ac6289a0fff65dd12cfa07e34] Merge tag 'drm-amdkfd-next-2015-05-19' of git://people.freedesktop.org/~gabbayo/linux into drm-next
git bisect good 91d9f9856f91c82ac6289a0fff65dd12cfa07e34
# bad: [7e35ab88d8ec652803eb2965c00e3ed9967c4f9d] drm/i915: Fix typo in intel_runtime_pm.c
git bisect bad 7e35ab88d8ec652803eb2965c00e3ed9967c4f9d
# bad: [5e024f31be3734aed0a5ead7002de16029ec3bc1] drm/i915: Remove unused variable from i915_gem_mmap_gtt
git bisect bad 5e024f31be3734aed0a5ead7002de16029ec3bc1

(In reply to Darren D. from comment #13)
> Another update: I think I'm either finished or close to finished--shouldn't
> bisect say which of the revisions is bad once i get down to 0, though?
> 
> Bisecting: 0 revisions left to test after this (roughly 0 steps)
> [bdcddf95e82b1c4e370fc1196b1f4f50f775dab4] Backmerge v4.1-rc4 into into
> drm-next

That refers to the number of commits that need to be tested after the current one (bdcddf95). You'd still need to mark the current commit as good or bad to get the result. However...


> Any bisects that say bad after 81663016dbfd53e29d1b5c5ddbc9b12ae1d66474 are
> marked bad not because of lack of accel, but because they didn't boot up. I
> was able to locate, however, the next bootable kernel after the 'initial
> ramdisk" boot failures started. Commit ID
> 744b058827b3db9a4f6027522dd9c73a208c2d31, and it both booted and had
> functional accelerated OpenGL on the videocard.

... I think you'll need to restart the bisection process with 744b058827b3db9a4f6027522dd9c73a208c2d31 as the initial good commit and the nearest bad one you've found so far. Otherwise the result will likely be inconsistent, because you marked different commits bad according to different criteria.

(In reply to Michel Dänzer from comment #14)
> ... I think you'll need to restart the bisection process with
> 744b058827b3db9a4f6027522dd9c73a208c2d31 as the initial good commit [...]

Actually, you can start with 91d9f9856f91c82ac6289a0fff65dd12cfa07e34 as the initial good commit.

(In reply to Michel Dänzer from comment #15)
> (In reply to Michel Dänzer from comment #14)
> > ... I think you'll need to restart the bisection process with
> > 744b058827b3db9a4f6027522dd9c73a208c2d31 as the initial good commit [...]
> 
> Actually, you can start with 91d9f9856f91c82ac6289a0fff65dd12cfa07e34 as the
> initial good commit.

I can restart it yet again, and at least this time it'll be a narrower range of commits.
 
And this is the sequence of commands I should use to do that, correct?

git bisect start

git bisect good 91d9f9856f91c82ac6289a0fff65dd12cfa07e34

git bisect bad 692a59e696afe1a4e777d0e4359325336ab0ad89

And if I start running into unbootable kernels again, I should start a new bisect with a different copy of the source tree and identify at which commit the compiled kernel started failing to boot, shouldn't I?

If a commit doesn't work, or won't build you can skip it with git bisect skip so it'll find another commit in the same range

Darren, why did you resolve this report as invalid?

(In reply to Michel Dänzer from comment #18)
> Darren, why did you resolve this report as invalid?

I didn't see you response earlier. My email I used to make the account expired so I had to make a new one and log back in. Anyhow, I thus far have still been unable to locate the commit that broke acceleration due to unbootable kernels. It's time consuming and got to be frustrating. At this point, I'll buy a replacement video card or switch to the built-in and sell the discrete card instead.

I think WONTFIX is more appropriate then.