From patchwork Wed Oct 1 02:29:00 2014 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: David Miller X-Patchwork-Id: 395384 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 9B2CA140218 for ; Wed, 1 Oct 2014 12:29:07 +1000 (EST) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751413AbaJAC3G (ORCPT ); Tue, 30 Sep 2014 22:29:06 -0400 Received: from shards.monkeyblade.net ([149.20.54.216]:53097 "EHLO shards.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750954AbaJAC3F (ORCPT ); Tue, 30 Sep 2014 22:29:05 -0400 Received: from localhost (cpe-67-247-12-89.nyc.res.rr.com [67.247.12.89]) (Authenticated sender: davem-davemloft) by shards.monkeyblade.net (Postfix) with ESMTPSA id 1C23358110B; Tue, 30 Sep 2014 19:29:04 -0700 (PDT) Date: Tue, 30 Sep 2014 22:29:00 -0400 (EDT) Message-Id: <20140930.222900.1514307861753222790.davem@davemloft.net> To: bpicco@meloft.net Cc: bob.picco@oracle.com, sparclinux@vger.kernel.org Subject: Re: [PATCH v2 0/8] sparc64: MM/IRQ patch queue. From: David Miller In-Reply-To: <20140930222841.GB22365@zareason> References: <20140930.145532.593702860481010417.davem@davemloft.net> <20140930205807.GA22365@zareason> <20140930222841.GB22365@zareason> X-Mailer: Mew version 6.6 on Emacs 24.3 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.5.7 (shards.monkeyblade.net [149.20.54.216]); Tue, 30 Sep 2014 19:29:04 -0700 (PDT) Sender: sparclinux-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: sparclinux@vger.kernel.org From: Bob Picco Date: Tue, 30 Sep 2014 18:28:41 -0400 > Okay, I lied partially. Let me examine this in the morning. You can > go first :) Thanks :) The boot mostly looks successful no? There are a couple blips, let's take a look: > Performance events: No support for PMU type 'niagara5' Hmmm, this was patched into an older tree I guess, as supported_pmu() accepts 'niagara5' as far as I can tell. Oh I see, you patched against vanilla 3.17-rc7 instead of my 'sparc' GIT tree. > SELinux: Registering netfilter hooks > Kernel unaligned access at TPC[675f74] sha256_transform+0x14/0x2840 > Kernel unaligned access at TPC[675f88] sha256_transform+0x28/0x2840 > Kernel unaligned access at TPC[675f88] sha256_transform+0x28/0x2840 > Kernel unaligned access at TPC[675f88] sha256_transform+0x28/0x2840 > Kernel unaligned access at TPC[675f88] sha256_transform+0x28/0x2840 > alg: No test for stdrng (krng) Interesting. sha256_transform() depends upon the input data being at least 32-bit aligned. Let's get a stack backtrace to see how this happens: ==================== > f0290d30: ttyS0 at I/O 0x0 (irq = 1, base_baud = 115200) is a SUN4V HCONS > NMI watchdog: BUG: soft lockup - CPU#527 stuck for 22s! [swapper/0:1] > Modules linked in: I think this is triggered because in console_unlock() all buffered console output is emitted all at once. And with all of those vmemmap log messages it gets huge. I guess this is another reason to trim down those messages, so I'll work on that now. :) > aes_sparc64: Using sparc64 aes opcodes optimized AES implementation > alg: skcipher-ddst: Test 5 failed on encryption for ctr-aes-sparc64 > 00000000: da 4e 3f bc e8 b6 3a a2 d5 4d 84 4a a9 0c e1 a5 Hmmm, interesting. I just noticed that I haven't enabled the sparc64 crypto drivers in my current test .config, but I turned them on and I don't get this test failure. I'll try to reproduce with the 'tcrypt' module or similar. > sd 5:0:2:0: attempting task abort! scmd(fff8183f401d97a0) > sd 5:0:2:0: [sde] CDB: > Read(10): 28 20 0a 20 2b 23 00 00 08 00 > scsi target5:0:2: handle(0x000b), sas_address(0x5000cca016322f71), phy(2) > scsi target5:0:2: enclosure_logical_id(0x508002000159c0d1), slot(2) > sd 5:0:2:0: task abort: SUCCESS scmd(fff8183f401d97a0) I get these every once in a while, the block I/O always recovers. I assume this booted all the way to a login prompt or similar? Thanks! --- To unsubscribe from this list: send the line "unsubscribe sparclinux" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html ==================== diff --git a/arch/sparc/kernel/unaligned_64.c b/arch/sparc/kernel/unaligned_64.c index 62098a8..59ea98a 100644 --- a/arch/sparc/kernel/unaligned_64.c +++ b/arch/sparc/kernel/unaligned_64.c @@ -299,6 +299,7 @@ static void log_unaligned(struct pt_regs *regs) if (__ratelimit(&ratelimit)) { printk("Kernel unaligned access at TPC[%lx] %pS\n", regs->tpc, (void *) regs->tpc); + dump_stack(); } }