From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1759771AbcBYKaX (ORCPT ); Thu, 25 Feb 2016 05:30:23 -0500 Received: from mail-pa0-f50.google.com ([209.85.220.50]:34952 "EHLO mail-pa0-f50.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1758068AbcBYKaU (ORCPT ); Thu, 25 Feb 2016 05:30:20 -0500 Date: Thu, 25 Feb 2016 19:31:37 +0900 From: Sergey Senozhatsky To: Sergey Senozhatsky Cc: Petr Mladek , Jan Kara , Peter Zijlstra , Steven Rostedt , Andrew Morton , Ingo Molnar , linux-kernel@vger.kernel.org, Sergey Senozhatsky Subject: Re: [linux-next, x86_64] no backtrace after "printk/nmi: generic solution for safe printk in NMI" Message-ID: <20160225103137.GA495@swordfish> References: <20160225094621.GA505@swordfish> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20160225094621.GA505@swordfish> User-Agent: Mutt/1.5.24 (2015-08-30) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On (02/25/16 18:46), Sergey Senozhatsky wrote: > Hello Petr, > > seem that commit b927968830676373caf4241e80d8b447133f84b2 > Author: Petr Mladek > Date: Thu Feb 25 13:00:35 2016 +1100 > > printk/nmi: generic solution for safe printk in NMI > > printk() takes some locks and could not be used a safe way in NMI context. > > The chance of a deadlock is real especially when printing stacks from all > CPUs. This particular problem has been addressed on x86 by the commit > a9edc8809328 ("x86/nmi: Perform a safe NMI stack trace on all CPUs"). > > The patchset brings two big advantages. First, it makes the NMI > backtraces safe on all architectures for free. Second, it makes all NMI > messages almost safe on all architectures (the temporary buffer is > limited. We still should keep the number of messages in NMI context at > minimum). > [..] > > > makes my x86_64 boxen unhappy, I see no CPU backtraces and no panic messages > on HARDLOCKUPs (CONFIG_BOOTPARAM_HARDLOCKUP_PANIC_VALUE=1). > > does it work for you? just for note, I reverted (next-20160225) the following commits: bdcdb76696402e1a0821db6bcccb2b4de4049f27 7ad17383fa428d1c89d2be95d00806f33df69dfd 054a26c149a5add6d27d154f2025ee2605d9f25d c2dbc8fd415835a71b0dee0f3f3a353d116f8731 3fd57f62ac2a8de6b402bf5f6aeb3a7d1e3f11a3 3ff0033c1e878b8bd8fce6efcd1b432b24f1d321 -- still no HARDLOCKUP panic backtraces on a console. reverting of b927968830676373caf4241e80d8b447133f84b2 (plus MIPS config conflict resolution) -- fixed the problem for me. I've tested several times. the sample code that I use for testing is very simple (well.. but it does the job): --- u64 s, e; unsigned long flags; local_irq_save(flags); s = local_clock() >> 31UL; pr_err(">>>>>>>>>>>>>>>>>START_THE_TEST\n"); while (1) { e = local_clock() >> 31UL; if (e - s > %%YOUR_WATCHDOG_THRESHOLD%%) goto out; } out: pr_err(">>>>>>>>>>>>>>>>>END_THE_TEST\n"); local_irq_restore(flags); --- most likely I'll be able to reply only tomorrow (in case if there will be any questions). -ss