From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id 5F734C433FE for ; Wed, 1 Jun 2022 08:08:20 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1350518AbiFAIIR (ORCPT ); Wed, 1 Jun 2022 04:08:17 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:52460 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1350524AbiFAIIP (ORCPT ); Wed, 1 Jun 2022 04:08:15 -0400 Received: from dfw.source.kernel.org (dfw.source.kernel.org [IPv6:2604:1380:4641:c500::1]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id F3A3E1C106; Wed, 1 Jun 2022 01:08:13 -0700 (PDT) Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by dfw.source.kernel.org (Postfix) with ESMTPS id 825306145B; Wed, 1 Jun 2022 08:08:13 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id E9AB8C34119; Wed, 1 Jun 2022 08:08:12 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1654070893; bh=G8ea8D+q6mHk8aHCvfAHmYO+5MM08v7Btb2LL8ppXE8=; h=References:In-Reply-To:From:Date:Subject:To:Cc:From; b=gyOC1Ah3rW/OJqC8//m6qnWPCemrJbT0qQqKOOZzbMhVSiAFDI2E9sUfqJEZr0YHL ds7WLtGL6peOZmEhvwKwF4Xcz1RMIpFLlGQgAjg1zgIdL+ewZ+0qmpIQ9k/uWarP7p QDAGh4OfyHD1vsBdQjH3rjA99/EIBux9MmxRARQZTpNrlDJtrB5c+KFSpmZrID2TiZ XqQkhlrC13X4yxhNv4Z98673Jsa5zCgk4JZquoQ8j2c5koBifCTEntwecO47aSKkhQ 1arFUNf1HM3K6mtAHOeS1cWRj/L8v23dt+IHeCEd8MkJ3+7EO16d5ejED412WojWkv R1fvNq29p2FzQ== Received: by mail-oi1-f174.google.com with SMTP id v9so1688321oie.5; Wed, 01 Jun 2022 01:08:12 -0700 (PDT) X-Gm-Message-State: AOAM532I+51OemQTfgeP47W3Un5Z9C9conO2yFxw4hxKnfMakMg29uyR 5cmOo7qsRBf1Un5m6HYPof/MkcuCFpFJ5rTbmcA= X-Google-Smtp-Source: ABdhPJwUyfIxbpgUAGZfZsManIFjVvJyso46XAOwsCT8OY8IF2ENvO9U0cj+3Yfiu3Y5TYsl5gt2MRG2K4OXRiXREtY= X-Received: by 2002:a05:6808:f88:b0:32b:d10f:cc6b with SMTP id o8-20020a0568080f8800b0032bd10fcc6bmr12876264oiw.228.1654070892117; Wed, 01 Jun 2022 01:08:12 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Ard Biesheuvel Date: Wed, 1 Jun 2022 10:08:00 +0200 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: am335x: 5.18.x: system stalling To: Arnd Bergmann Cc: Yegor Yefremov , Tony Lindgren , Linux-OMAP , linux-clk , Stephen Boyd , Linux ARM Content-Type: text/plain; charset="UTF-8" Precedence: bulk List-ID: X-Mailing-List: linux-clk@vger.kernel.org On Wed, 1 Jun 2022 at 09:59, Arnd Bergmann wrote: > > On Wed, Jun 1, 2022 at 9:36 AM Yegor Yefremov > wrote: > > On Tue, May 31, 2022 at 5:23 PM Arnd Bergmann wrote: > > > I've pushed a modified branch now, with that fix on the broken commit, > > > and another change to make CONFIG_IRQSTACKS user-selectable rather > > > than always enabled. That should tell us if the problem is in the SMP > > > patching or in the irqstacks. > > > > > > Can you test the top of this branch with CONFIG_IRQSTACKS disabled, > > > and (if that still stalls) retest the fixed commit f0191ea5c2e5 ("[PART 1] > > > ARM: implement THREAD_INFO_IN_TASK for uniprocessor systems")? > > > > 1. the top of this branch with CONFIG_IRQSTACKS disabled stalls > > 2. f0191ea5c2e5 with the same config - not > > Ok, perfect, that does narrow down the problem quite a bit: The final > patch has seven changes, all of which can be done individually because > in each case the simplified version in f0191ea5c2e5 is meant to run > the exact same instructions as the version after the change, when running > on a uniprocessor machine such as your am335x. > > You have already shown earlier that the get_current() and > __my_cpu_offset() functions are not to blame here, as reverting > only those does not change the behavior. > > This leaves the is_smp() check in set_current(), and the > four macros in . I don't see anything obviously > wrong with any of those five, but I would bet on the macros > here. Can you try bisecting into this commit, maybe reverting > the changes to set_current and get_current first, and then > narrowing it down to (hopefully) a single macro that causes the > problem? > set_current() is never called by the primary CPU, which is why the is_smp() check was removed from there in 57a420435edcb0b94 ("ARM: drop pointless SMP check on secondary startup path"). So that leaves only the four macros in asm/assembler.h, but I don't see anything obviously wrong with those either. From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from bombadil.infradead.org (bombadil.infradead.org [198.137.202.133]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id 69B99C433F5 for ; Wed, 1 Jun 2022 08:09:31 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20210309; h=Sender: Content-Transfer-Encoding:Content-Type:List-Subscribe:List-Help:List-Post: List-Archive:List-Unsubscribe:List-Id:Cc:To:Subject:Message-ID:Date:From: In-Reply-To:References:MIME-Version:Reply-To:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: List-Owner; bh=fCSQ8wZRqd5ZEVUDKUvBzGH9KJ8xcj3D+kYBTFeE584=; b=l6hYtgMqmw/HVH d/K9S8BGvP8iO3+DbKUeIuyJoOLqvw5EpnDQO06k3C2PlydAVh9vxffv1JZlzNo8G+gUVLahOHuIs w16KfsfGzoPPPATXVuFivStG7KZlpwjpOBkuC70GxTvKBkANd5O/KFfK0Nz1dTQt/Pzl4VArQTnwY Dr1cpNbGT2LVHi+ZBTb9s/XfAqQF0EhW3SJ0XoCcXOgeSb30i6kY+d5ckCRSY+bODPDaRid6aRdw3 p/IIAYH689cBJxhI/Ph5Zfm0kT1MSGfF5GJ3q07KEUR1NDbF4l5IFwC5QH7xfA4dPuJYkVZ3iyKkj yanxOgwMC2AhRO2Ar4MQ==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.94.2 #2 (Red Hat Linux)) id 1nwJOt-00EX4p-1O; Wed, 01 Jun 2022 08:08:19 +0000 Received: from dfw.source.kernel.org ([139.178.84.217]) by bombadil.infradead.org with esmtps (Exim 4.94.2 #2 (Red Hat Linux)) id 1nwJOp-00EX3N-6N for linux-arm-kernel@lists.infradead.org; Wed, 01 Jun 2022 08:08:16 +0000 Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by dfw.source.kernel.org (Postfix) with ESMTPS id 825066144C for ; Wed, 1 Jun 2022 08:08:13 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id EC73AC3411A for ; Wed, 1 Jun 2022 08:08:12 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1654070893; bh=G8ea8D+q6mHk8aHCvfAHmYO+5MM08v7Btb2LL8ppXE8=; h=References:In-Reply-To:From:Date:Subject:To:Cc:From; b=gyOC1Ah3rW/OJqC8//m6qnWPCemrJbT0qQqKOOZzbMhVSiAFDI2E9sUfqJEZr0YHL ds7WLtGL6peOZmEhvwKwF4Xcz1RMIpFLlGQgAjg1zgIdL+ewZ+0qmpIQ9k/uWarP7p QDAGh4OfyHD1vsBdQjH3rjA99/EIBux9MmxRARQZTpNrlDJtrB5c+KFSpmZrID2TiZ XqQkhlrC13X4yxhNv4Z98673Jsa5zCgk4JZquoQ8j2c5koBifCTEntwecO47aSKkhQ 1arFUNf1HM3K6mtAHOeS1cWRj/L8v23dt+IHeCEd8MkJ3+7EO16d5ejED412WojWkv R1fvNq29p2FzQ== Received: by mail-oi1-f180.google.com with SMTP id m82so1639486oif.13 for ; Wed, 01 Jun 2022 01:08:12 -0700 (PDT) X-Gm-Message-State: AOAM533av4mSH3IU+jRQR0E81b7FSN7fhkz3YJFdhWzJQierdLbJyId7 KbR1pZFs3L2q28m071Oi+O/tqyNjPiUWAyuZoGk= X-Google-Smtp-Source: ABdhPJwUyfIxbpgUAGZfZsManIFjVvJyso46XAOwsCT8OY8IF2ENvO9U0cj+3Yfiu3Y5TYsl5gt2MRG2K4OXRiXREtY= X-Received: by 2002:a05:6808:f88:b0:32b:d10f:cc6b with SMTP id o8-20020a0568080f8800b0032bd10fcc6bmr12876264oiw.228.1654070892117; Wed, 01 Jun 2022 01:08:12 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Ard Biesheuvel Date: Wed, 1 Jun 2022 10:08:00 +0200 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: am335x: 5.18.x: system stalling To: Arnd Bergmann Cc: Yegor Yefremov , Tony Lindgren , Linux-OMAP , linux-clk , Stephen Boyd , Linux ARM X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20220601_010815_357035_6E522D6F X-CRM114-Status: GOOD ( 29.32 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org On Wed, 1 Jun 2022 at 09:59, Arnd Bergmann wrote: > > On Wed, Jun 1, 2022 at 9:36 AM Yegor Yefremov > wrote: > > On Tue, May 31, 2022 at 5:23 PM Arnd Bergmann wrote: > > > I've pushed a modified branch now, with that fix on the broken commit, > > > and another change to make CONFIG_IRQSTACKS user-selectable rather > > > than always enabled. That should tell us if the problem is in the SMP > > > patching or in the irqstacks. > > > > > > Can you test the top of this branch with CONFIG_IRQSTACKS disabled, > > > and (if that still stalls) retest the fixed commit f0191ea5c2e5 ("[PART 1] > > > ARM: implement THREAD_INFO_IN_TASK for uniprocessor systems")? > > > > 1. the top of this branch with CONFIG_IRQSTACKS disabled stalls > > 2. f0191ea5c2e5 with the same config - not > > Ok, perfect, that does narrow down the problem quite a bit: The final > patch has seven changes, all of which can be done individually because > in each case the simplified version in f0191ea5c2e5 is meant to run > the exact same instructions as the version after the change, when running > on a uniprocessor machine such as your am335x. > > You have already shown earlier that the get_current() and > __my_cpu_offset() functions are not to blame here, as reverting > only those does not change the behavior. > > This leaves the is_smp() check in set_current(), and the > four macros in . I don't see anything obviously > wrong with any of those five, but I would bet on the macros > here. Can you try bisecting into this commit, maybe reverting > the changes to set_current and get_current first, and then > narrowing it down to (hopefully) a single macro that causes the > problem? > set_current() is never called by the primary CPU, which is why the is_smp() check was removed from there in 57a420435edcb0b94 ("ARM: drop pointless SMP check on secondary startup path"). So that leaves only the four macros in asm/assembler.h, but I don't see anything obviously wrong with those either. _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel