[19:05] <slangasek> jsalisbury: so since a straight cherrypick didn't do it on LP: #1724911, I guess the next step would be another reverse-bisect of v4.13 to fc5e9d63a8db^ with a cherry-pick of fc5e9d63a8db at each step?
[19:08] <jsalisbury> slangasek, yes, that would work if there are multiple commits needed for the fix.  Did you now get any bad results during your last bisect?
[19:19] <slangasek> jsalisbury: no; but I'm not sure why the git bisect stopped at fc5e9d63a8db either
[19:22] <jsalisbury> slangasek, yeah, it should have stopped on a much newer commit if the reverse bisect was done with 4.13 as good and 4.14-rc1 as bad.
[19:26] <slangasek> jsalisbury: 'git bisect start --term-old=old --term-new=new fc5e9d63a8db v4.13' wants me to test a merge base; I wonder if that's sensible?
[19:30] <jsalisbury> slangasek, if the bisect is suggesting it, its usually correct. 
[19:32] <jsalisbury> slangasek, do you happen to have the bisect log from the last bisect that said fc5e9d63a8db was good?  I suppose I could look at the bug 
[19:32] <slangasek> jsalisbury: whoops, I just trashed it in my tree, sorry.  should be possible to reconstruct from the bug log, let me know if you want me to
[19:33] <jsalisbury> slangasek, you don't need to.  I can.  Just curious to look at it.
[19:37] <jsalisbury> slangasek, I started the reverse bisect between 4.13 and 4.14-rc1 and got a differant starting SHA1 than you. Let me post it in a pastebin:
[19:37] <slangasek> oh cool ;)
[19:38] <jsalisbury> slangasek, https://paste.ubuntu.com/25867410/  
[19:38] <jsalisbury> slangasek, It looks like you got edc2988c548db05e33b921fed15821010bc74895 per comment #59
[19:39] <slangasek> jsalisbury: I don't think that's different though; the bisect started in comment #12, comment #59 is just me picking up where I went astray in the bisect the previous time through
[19:40] <jsalisbury> slangasek, ahh, ok.  sorry 
[19:42] <jsalisbury> slangasek, were you intalling -extra back for those earlier tests?
[19:42] <jsalisbury> oh wait, nevermide there is no -extra in mainline
[19:44] <jsalisbury> slangasek, I'll run through the bisect results you posted to the bug and see if I come up with the same result as you.
[19:46] <jsalisbury> slangasek, one other option we have to to perform a regular bisect since this is a regression.  Finding the commit that introduced the bug -might- help is pick out the commit that fixes it easier.  I guess that would be a last resort.
[20:05] <jsalisbury> slangasek, I re-entered all the bisect results posted to the bug and got commit fc5e9d63a8 again.  I wonder if we went astray somewhere in the bisect?  If not, then we should perform the bisect again, but each time pick fc5e9d63a8db before building the test kernel.   
[20:05] <jsalisbury> slangasek, what do you think?  I can restart the bisect and built the first kernel with fc5e9d63a8db ontop?
[20:36] <slangasek> jsalisbury: I'm unclear why that would help; it seems to me that if there are no more commits given by the bisect between v4.13 and v4.14-rc1, and cherry-picking fc5e9d63a8db on top of v4.13 doesn't work, then the missing commits must be something else that git bisect isn't showing us between v4.13 and fc5e9d63a8db rather than between fc5e9d63a8db and v4.14-rc1
[20:44] <jsalisbury> slangasek, yes you are correct and I shouldn't have suggested bisecting up to 4.14-rc1 again.  It would be best to do what your first IRC message said: "another reverse-bisect of v4.13 to fc5e9d63a8db^ with a cherry-pick of fc5e9d63a8db at each step".  All a visulize of that is showing a merge base like you said, so I'm not sure and need to think about it and review the email from apw again.
[20:45] <slangasek> ok
[20:45] <jsalisbury> slangasek, this is a tricky one