linux-kernel - Re: [GIT pull] CPU hotplug updates for 4.9

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <1489167438.2548.3.camel@sandisk.com>
Date:   Fri, 10 Mar 2017 17:37:32 +0000
From:   Bart Van Assche <Bart.VanAssche@...disk.com>
To:     "mingo@...nel.org" <mingo@...nel.org>
CC:     "tglx@...utronix.de" <tglx@...utronix.de>,
        "torvalds@...ux-foundation.org" <torvalds@...ux-foundation.org>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        "hpa@...or.com" <hpa@...or.com>,
        "akpm@...ux-foundation.org" <akpm@...ux-foundation.org>
Subject: Re: [GIT pull] CPU hotplug updates for 4.9

On Fri, 2017-03-10 at 08:23 +0100, Ingo Molnar wrote:
> * Bart Van Assche <Bart.VanAssche@...disk.com> wrote:
> > Anyway, the result of a new bisect I ran is as follows:
> > * good: 631ddaba5905 ("Merge branches 'pm-sleep' and 'powercap'").
> > * good: 80f1b3dea9d4 ("Merge branch 'device-properties'").
> > * bad:  a67485d4bf97 ("Merge tag 'acpi-4.10-rc1' of
> >   git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm").
> > 
> > Does this make sense to you?
> 
> The bisection information is really useful, if the failure mode is deterministic.
> 
> It would be nice to have more bisection points, the above range is about 5,000 
> commits.

Hello Ingo,

Sorry that I had mentioned such a big range of commits. The bisect process
actually pointed out a single commit as the first bad commit. I had not
mentioned that information because I did not trust it. Anyway, when I tried
to reproduce the hang this morning with the commit marked as "bad" the hang
did not occur. I think this means the hang is reproducible most of the time
but not always. That probably explains why none of my two bisect attempts so
far pointed at a commit that introduced the hang. I'll try to find a way to
reproduce the hang reliably.

Bart.