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 X-Spam-Level: X-Spam-Status: No, score=-1.0 required=3.0 tests=HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 919A0C433E0 for ; Thu, 2 Jul 2020 12:52:53 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 78A292088E for ; Thu, 2 Jul 2020 12:52:53 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1729074AbgGBMwt (ORCPT ); Thu, 2 Jul 2020 08:52:49 -0400 Received: from mail-ot1-f67.google.com ([209.85.210.67]:35497 "EHLO mail-ot1-f67.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1729067AbgGBMwt (ORCPT ); Thu, 2 Jul 2020 08:52:49 -0400 Received: by mail-ot1-f67.google.com with SMTP id d4so24054175otk.2; Thu, 02 Jul 2020 05:52:48 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=SZcFT+xrBItiIPkKnb7dnrTd+DXFeYO91uQhHRwP1Jw=; b=eUx0i9/7Y2t2PDv6eK9e0D7yoIFhqljF7sD0cCC3UUjtxXW0b4c5cHa0OaBUKp4GW6 NeEUsNp8t1+yxUsMqhMKjuPhaXSrunXoSm+/DCOHUFstUQe5ilS2YG2Vd1ntLs1YvnYF VDD6CUvIwl+wLAz6m0Xio0XjhTt/STUSE9b8mK3jkQrihR3anvqSCFlixjHoMIsrX1u5 mUkBjg2gMSJWvCw7pcllb+EVQ+LUHrbqKK5Q5BYlNCqvJ5dfm1EroDBcApD905VCEsKq YDkC9cbndYtEDxH5/vu53dcTsQIpiH0eUmBDXo490lFhMuM3B9qX3k7IXhS1zv4Wcm+r 5kkQ== X-Gm-Message-State: AOAM531IRvSERzHp2yfjJ6jvsmJr6ocgTl98+R71BYkqJK+BUhFuIld5 BdIPaPnFlaA77aQDJgpfBhHHI7AYu1sxxU+Xj7Q= X-Google-Smtp-Source: ABdhPJyi7OURyoN9oCT4BLoa9GXI8+tdTqqJqwuKVc2/6NcfJjjYgaD7YNbeBgdEGyjwGnsDViFnDuX2Z+6M0NBwD+s= X-Received: by 2002:a9d:2646:: with SMTP id a64mr25065171otb.107.1593694368048; Thu, 02 Jul 2020 05:52:48 -0700 (PDT) MIME-Version: 1.0 References: <1593618100-2151-1-git-send-email-prabhakar.mahadev-lad.rj@bp.renesas.com> In-Reply-To: From: Geert Uytterhoeven Date: Thu, 2 Jul 2020 14:52:36 +0200 Message-ID: Subject: Re: [PATCH] serial: sh-sci: Initialize spinlock for uart console To: "Lad, Prabhakar" Cc: Greg Kroah-Hartman , Jiri Slaby , Linux-Renesas , "open list:SERIAL DRIVERS" , Linux Kernel Mailing List , Biju Das Content-Type: text/plain; charset="UTF-8" Sender: linux-serial-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-serial@vger.kernel.org Hi Prabhakar, On Thu, Jul 2, 2020 at 1:42 PM Lad, Prabhakar wrote: > On Thu, Jul 2, 2020 at 11:49 AM Lad, Prabhakar > wrote: > > On Thu, Jul 2, 2020 at 10:23 AM Geert Uytterhoeven wrote: > > > On Wed, Jul 1, 2020 at 7:28 PM Lad, Prabhakar > > > wrote: > > > > On Wed, Jul 1, 2020 at 6:17 PM Geert Uytterhoeven wrote: > > > > > On Wed, Jul 1, 2020 at 5:42 PM Lad Prabhakar > > > > > wrote: > > > > > > serial core expects the spinlock to be initialized by the controller > > > > > > driver for serial console, this patch makes sure the spinlock is > > > > > > initialized, fixing the below issue: > > > > > > > > > > > > [ 0.865928] BUG: spinlock bad magic on CPU#0, swapper/0/1 > > > > > > [ 0.865945] lock: sci_ports+0x0/0x4c80, .magic: 00000000, .owner: /-1, .owner_cpu: 0 > > > > > > [ 0.865955] CPU: 0 PID: 1 Comm: swapper/0 Not tainted 5.8.0-rc1+ #112 > > > > > > [ 0.865961] Hardware name: HopeRun HiHope RZ/G2H with sub board (DT) > > > > > > [ 0.865968] Call trace: > > > > > > [ 0.865979] dump_backtrace+0x0/0x1d8 > > > > > > [ 0.865985] show_stack+0x14/0x20 > > > > > > [ 0.865996] dump_stack+0xe8/0x130 > > > > > > [ 0.866006] spin_dump+0x6c/0x88 > > > > > > [ 0.866012] do_raw_spin_lock+0xb0/0xf8 > > > > > > [ 0.866023] _raw_spin_lock_irqsave+0x80/0xa0 > > > > > > [ 0.866032] uart_add_one_port+0x3a4/0x4e0 > > > > > > [ 0.866039] sci_probe+0x504/0x7c8 > > > > > > [ 0.866048] platform_drv_probe+0x50/0xa0 > > > > > > [ 0.866059] really_probe+0xdc/0x330 > > > > > > [ 0.866066] driver_probe_device+0x58/0xb8 > > > > > > [ 0.866072] device_driver_attach+0x6c/0x90 > > > > > > [ 0.866078] __driver_attach+0x88/0xd0 > > > > > > [ 0.866085] bus_for_each_dev+0x74/0xc8 > > > > > > [ 0.866091] driver_attach+0x20/0x28 > > > > > > [ 0.866098] bus_add_driver+0x14c/0x1f8 > > > > > > [ 0.866104] driver_register+0x60/0x110 > > > > > > [ 0.866109] __platform_driver_register+0x40/0x48 > > > > > > [ 0.866119] sci_init+0x2c/0x34 > > > > > > [ 0.866127] do_one_initcall+0x88/0x428 > > > > > > [ 0.866137] kernel_init_freeable+0x2c0/0x328 > > > > > > [ 0.866143] kernel_init+0x10/0x108 > > > > > > [ 0.866150] ret_from_fork+0x10/0x18 > > > > > > > > > > Interesting... > > > > > > > > > > How can I reproduce that? I do have CONFIG_DEBUG_SPINLOCK=y. > > > > > I'm wondering why haven't we seen this before... > > > > > > > > > I have attached .config for your reference. > > > > > > Thank you! > > > > > > I gave it a try with v5.8-rc1 on Salvator-XS with R-Car H3 ES2.0. > > > However, I couldn't reproduce the issue. > > > Does it happen on that specific board only? Is this serdev-related? > > > Note that I had to disable CONFIG_EXTRA_FIRMWARE, as I don't have the > > > firmware blobs it referenced. Do I need them to trigger the issue? > > > As the .config has a few non-upstream options, do you have any patches > > > applied that might impact the issue? > > > > > Can't think of any patches that might cause an issue, most of it are > > just the DT's and config additions. Nor do firmware blobs should > > affect it. I'll try and reproduce it on M3N and get back to you. > > > I did manage to replicate this issue on M3N (v5.8-rc3 tag with no > modifications), I have attached the config file and also the boot log > without this patch for your reference, after applying this patch I no > more see this issue. Thanks, the boot log finally gave me a clue, and allowed me to reproduce. The issue happens only when adding: console=ttySC0,115200n8 to the kernel command line. Which is something we never did on R-Car Gen3, as the console= parameter had been deprecated by chosen/stdout-path on DT systems long before. As we did use console= before on arm32, and drivers/tty/serial/sh-sci.c never called spinlock_init(), I'm wondering if this spinlock bug is actually a regression in serial_core.c? Gr{oetje,eeting}s, Geert -- Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org In personal conversations with technical people, I call myself a hacker. But when I'm talking to journalists I just say "programmer" or something like that. -- Linus Torvalds