Re: linux-next: Tree for Aug 26 (git-bisect: [0856a30] Scm: Removeunnecessary pid & credential references in Unix socket's send and receive path)

[Sedat Dilek]

 On Fri, Aug 26, 2011 at 7:00 AM, Stephen Rothwell <sfr@xxxxxxxxxxxxxxxx> wrote:
> Hi all,
>
> The powerpc allyesconfig build still fails today.
>
> Changes since 20110825:
>
> The slave-dma tree gained a conflict against Linus' tree.
>
> I have reverted the x86/spinlocks branch from the tip tree for today.
>
> The ptrace tree lost its build failure.
>
> The xen tree lost its conflict since I reveretd the version of the same
> patches in the tip tree..
>
> The tty tree still has its build failure but I applied a supplied test
> patch for it.
>
> The staging tree lost its build failures and gained a conflict against
> the net tree.
>
> The moduleh tree lost a conflict.
>
> The akpm tree lost its build failure.
>
> ----------------------------------------------------------------------------
>

Hi,

I saw diverse strange kernel-panics letting my notebook blink and
scream a high-frequency tone, really ugly.

My last good linux-next (l-n) kernel was next-20110818 and the next
l-n kernel in series which I built and was broken: next-20110826.
( BTW, 29/31 Aug are broken too. )

For the correctness I built 22/23/24/25 Aug which were all good.
As usual when I do once a year a git-bisect... its the last step of 12
steps in total (see git-bisect_visualize.txt and
git-bisect_view-stat.txt).

I was irritated by using next-20110825 and next-20110826 as git-bisect
good and bad, as the first offered commit-id pointed me to
3.1-rc1-665-gec5efe7, but I was sure the culprit is definitely
v3.1-rc3+ and furthermore I got no info how many revisions have to be
walked through. So, I cancelled this run.

Next thought was to do a git format-patch using above mentionned
commit-ids (of the tags): 819 single patches.
I took the commit-ids of 0001 (good) and 0818 (bad) - 0819 was
linux-specific mumbo-jumbo.

Jiri has reported a similiar breakage in [2] and returning CULPRIT
commit [1] helped him.
( This git-bisect steal a whole Friday. Anyway, it's good to see we
isolated the "bad" patch. )

As a personal conclusion, trust more git-bisect...
It does not hurt to NOT turn off brain my looking over the single
patches, there were lots of staging, arm, powerpc which could be
surely ignored, but in the end you are wiser - 12 steps are faster
than reverting xxx single commits on spec.

- Sedat -

[1] http://git.us.kernel.org/?p=linux/kernel/git/next/linux-next.git;a=commit;h=0856a304091b33a8e8f9f9c98e776f425af2b625
[2] http://lkml.org/lkml/2011/9/1/332
[3] http://www.kernel.org/pub/software/scm/git/docs/git-bisect.html
[4] http://www.kernel.org/pub/software/scm/git/docs/user-manual.html#using-bisect

P.S.: Used 0001 (good) and 0818 (bad) for git-bisect

$ head -5 0001-target-Change-TCM_NON_EXISTENT_LUN-response-to-ASC-L.patch
0818-Fixes-the-deadlock-when-inserting-and-removing-the-d.patch
==> 0001-target-Change-TCM_NON_EXISTENT_LUN-response-to-ASC-L.patch <==