From patchwork Fri Nov 14 17:01:05 2014 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Jens Axboe X-Patchwork-Id: 410941 X-Patchwork-Delegate: davem@davemloft.net Return-Path: X-Original-To: patchwork-incoming@ozlabs.org Delivered-To: patchwork-incoming@ozlabs.org Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by ozlabs.org (Postfix) with ESMTP id 2C0D3140082 for ; Sat, 15 Nov 2014 04:01:10 +1100 (AEDT) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S935305AbaKNRBI (ORCPT ); Fri, 14 Nov 2014 12:01:08 -0500 Received: from mail-pa0-f48.google.com ([209.85.220.48]:65027 "EHLO mail-pa0-f48.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S935219AbaKNRBH (ORCPT ); Fri, 14 Nov 2014 12:01:07 -0500 Received: by mail-pa0-f48.google.com with SMTP id rd3so4282843pab.21 for ; Fri, 14 Nov 2014 09:01:06 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :cc:subject:references:in-reply-to:content-type; bh=v6F3oOQdZ6iYIXB0ECJVYFNWcktl1jeVF7vqeiM3vlk=; b=kLAvhwPB6uT9vfcrpbbOk5Q/BqxBFDY9NQKuaPCfdLxm9leyz8P9T5c+k0iY6mipS4 CLma3+KVQV+U68fmK1DS25BL20w/jax0weW0B/66VaEFBG6J/XDltf+Y+cFJqz1E7weQ 73n3OZZ+xGtiDfmJqbDIVRSQRC5kHsyJi3ybcF8thYpP/C0PpSvf6kLbTUpAGM761KFT fVaz6P48/lHL+u/spLgoBLZpklnFC8fz3m11M5QJoLUHO1iL1WFy0+l6b76fd+NuiTGJ vPnixoYlhrMJQzAzwOS1Eg2YY4LdW83DVOcmCTCmjhQBAEWYGmJjrXObfVuTChnuvhQP uHLg== X-Gm-Message-State: ALoCoQlJyf4QVu5ugPsP3lJiNX6UqlDrMwWTUd0OyEbBWo/noCxQ6wWW3A5BTu8CnAzcxX0J2S6h X-Received: by 10.66.150.164 with SMTP id uj4mr11462874pab.14.1415984466398; Fri, 14 Nov 2014 09:01:06 -0800 (PST) Received: from [192.168.3.12] (66.29.187.51.static.utbb.net. [66.29.187.51]) by mx.google.com with ESMTPSA id l6sm28054807pdr.39.2014.11.14.09.01.04 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 14 Nov 2014 09:01:05 -0800 (PST) Message-ID: <54663551.8080500@kernel.dk> Date: Fri, 14 Nov 2014 10:01:05 -0700 From: Jens Axboe User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.2.0 MIME-Version: 1.0 To: Christoph Hellwig , Meelis Roos CC: linux-scsi@vger.kernel.org, sparclinux@vger.kernel.org, David Miller , "Paul E. McKenney" Subject: Re: Another (ESP?) scsi blk-mq problem on sparc64 References: <20141114165804.GA14631@infradead.org> In-Reply-To: <20141114165804.GA14631@infradead.org> Sender: sparclinux-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: sparclinux@vger.kernel.org On 11/14/2014 09:58 AM, Christoph Hellwig wrote: > Paul, what's the best way to figure out these CPU stalls? > > The second oops is in blk_mq_map_queue() which is a trivial > two level cpu lookup. I wonder if there's something odd about > cpu numbers on these big old sparc systems? > > Something like the debug patch below might shed some light on where the > index goes wrong, but it'll be horribly verbose. > > > diff --git a/block/blk-mq.c b/block/blk-mq.c > index b5896d4..ef4b35b 100644 > --- a/block/blk-mq.c > +++ b/block/blk-mq.c > @@ -1270,7 +1270,12 @@ run_queue: > */ > struct blk_mq_hw_ctx *blk_mq_map_queue(struct request_queue *q, const int cpu) > { > - return q->queue_hw_ctx[q->mq_map[cpu]]; > + int idx; > + > + printk("cpu: %d\n", cpu); > + idx = q->mq_map[cpu]; > + printk("queue: %d\n", idx); > + return q->queue_hw_ctx[idx]; > } > EXPORT_SYMBOL(blk_mq_map_queue); It'd probably be better to shove this debug stuff into the map building code instead, ala attached. diff --git a/block/blk-mq-cpumap.c b/block/blk-mq-cpumap.c index 1065d7c65fa1..9200e2aee746 100644 --- a/block/blk-mq-cpumap.c +++ b/block/blk-mq-cpumap.c @@ -81,6 +81,9 @@ int blk_mq_update_queue_map(unsigned int *map, unsigned int nr_queues) map[i] = map[first_sibling]; } + for (i = 0; i < queue; i++) + printk(KERN_ERR "cpumap %d -> %d\n", i, map[i]); + free_cpumask_var(cpus); return 0; }