From: Bart Van Assche <Bart.VanAssche@sandisk.com>
To: "tglx@linutronix.de" <tglx@linutronix.de>
CC: "torvalds@linux-foundation.org" <torvalds@linux-foundation.org>,
        "mingo@kernel.org" <mingo@kernel.org>,
        "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
        "hpa@zytor.com" <hpa@zytor.com>,
        "akpm@linux-foundation.org" <akpm@linux-foundation.org>
Subject: Re: [GIT pull] CPU hotplug updates for 4.9
Thread-Topic: [GIT pull] CPU hotplug updates for 4.9
Thread-Index: AQHSl5K7G8esg0HmKU2oKft/t9MAAQ==
Date: Tue, 7 Mar 2017 22:32:42 +0000
Message-ID: <1488925949.2739.3.camel@sandisk.com>
References: <alpine.DEB.2.20.1610031929360.5278@nanos>
         <1488851515.6858.2.camel@sandisk.com>
         <alpine.DEB.2.20.1703071027340.3584@nanos>
In-Reply-To: <alpine.DEB.2.20.1703071027340.3584@nanos>
Accept-Language: nl-NL, en-US
Content-Language: en-US
Content-Type: text/plain; charset="iso-8859-1"
Content-ID: <0021DDB08AFE8941B8A8C63DE56092C5@sandisk.com>
MIME-Version: 1.0
WDCIPOUTBOUND: EOP-TRUE
SpamDiagnosticOutput: 1:99
SpamDiagnosticMetadata: NSPM
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 07 Mar 2017 22:32:47.6177
 (UTC)
X-MS-Exchange-CrossTenant-Id: b61c8803-16f3-4c35-9b17-6f65f441df86
X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=b61c8803-16f3-4c35-9b17-6f65f441df86;Ip=[74.221.232.54];Helo=[sacsmgep14.sandisk.com]
X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BLUPR0401MB1491
Sender: linux-kernel-owner@vger.kernel.org
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by mail.home.local id v282HQPG015837
Content-Length: 728
Lines: 17

On Tue, 2017-03-07 at 10:30 +0100, Thomas Gleixner wrote:
> That's odd. There was no change related to the hotplug stuff post 4.10
> neither in the core nor in that particular driver.
> 
> I have no immediate clue what to look for aside of asking you whether you
> could do a bisect between 4.10 and 4.11-rc1.

Hello Thomas,

I will keep trying to find the commit that introduced this behavior. The
bisect I ran this morning yielded a commit that only changes ARM code which
does not make sense since I ran the bisect on an x86 system. I guess that
means that during one of the bisect steps I did not wait long enough to see
whether or not the hang occurs and hence that I provided incorrect input to
the bisect process.

Bart.