(In reply to comment #18)
> Linux commit 992956189de58cae9f2be40585bc25105cd7c5ad is bad.
That seems thoroughly unlikely.
commit 992956189de58cae9f2be40585bc25105cd7c5ad
Author: Eric W. Biederman <email address hidden>
Date: Mon Dec 17 17:19:36 2012 -0800
efi: Fix the build with user namespaces enabled.
This doesn't apply to your situation on many levels... this is a build fix... to efi vars...
I bet if you checkout to 992956189de58cae9f2be40585bc25105cd7c5ad^ then you will still have a bad kernel. You should probably redo the bisect, but look at the bisect log (git bisect log) and keep all your "bad" commits, since they are likely indeed bad. But you may have been a bit too eager in calling out the "good" kernels. (See git help bisect for how to start with a bunch of bad commits.) While you're at it, you may want to re-test whether 3.7 really is good.
(In reply to comment #18) e9f2be40585bc25 105cd7c5ad is bad.
> Linux commit 992956189de58ca
That seems thoroughly unlikely.
commit 992956189de58ca e9f2be40585bc25 105cd7c5ad
Author: Eric W. Biederman <email address hidden>
Date: Mon Dec 17 17:19:36 2012 -0800
efi: Fix the build with user namespaces enabled.
This doesn't apply to your situation on many levels... this is a build fix... to efi vars...
I bet if you checkout to 992956189de58ca e9f2be40585bc25 105cd7c5ad^ then you will still have a bad kernel. You should probably redo the bisect, but look at the bisect log (git bisect log) and keep all your "bad" commits, since they are likely indeed bad. But you may have been a bit too eager in calling out the "good" kernels. (See git help bisect for how to start with a bunch of bad commits.) While you're at it, you may want to re-test whether 3.7 really is good.