From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S933802AbbDQPpL (ORCPT ); Fri, 17 Apr 2015 11:45:11 -0400 Received: from mx0a-00082601.pphosted.com ([67.231.145.42]:43856 "EHLO mx0a-00082601.pphosted.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S932274AbbDQPpJ (ORCPT ); Fri, 17 Apr 2015 11:45:09 -0400 Message-ID: <55312A7C.70602@fb.com> Date: Fri, 17 Apr 2015 09:45:00 -0600 From: Jens Axboe User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.6.0 MIME-Version: 1.0 To: Dave Jones , , Subject: Re: [GIT PULL] Followup single fix for block IO core pull References: <20150417151201.GA9330@kernel.dk> <20150417154148.GA8885@codemonkey.org.uk> In-Reply-To: <20150417154148.GA8885@codemonkey.org.uk> Content-Type: text/plain; charset="windows-1252"; format=flowed Content-Transfer-Encoding: 7bit X-Originating-IP: [192.168.54.13] X-Proofpoint-Spam-Reason: safe X-FB-Internal: Safe X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.13.68,1.0.33,0.0.0000 definitions=2015-04-17_06:2015-04-17,2015-04-17,1970-01-01 signatures=0 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 04/17/2015 09:41 AM, Dave Jones wrote: > On Fri, Apr 17, 2015 at 09:12:01AM -0600, Jens Axboe wrote: > > Hi Linus, > > > > A commit in the previous pull request introduce a regression. So far > > only observed on qemu-sparc64, but it's a general bug. Please pull this > > single fix to rectify that, thanks. > > I hit the same bug on two x86 boxes, bare-metal. > Reverting the commit Guenter pointed out made them boot again, > so definitely not sparc/qemu specific in any way. > > I suspect the only reason more people didn't see it is that not > everyone is running with the mq-by-default config option yet ? It is puzzling. I ran it on several boxes, both multi queue and not, and both single mq queues and multiple. But the code is clearly wrong. So yeah, it's not sparc64 specific in any way. My initial thought was that this was another issue related to sparse CPU ids, but that's not the case. It's a plain bug, unfortunately. -- Jens Axboe