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=-2.6 required=3.0 tests=DKIMWL_WL_HIGH,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS, USER_AGENT_SANE_1 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 2C53CC433E1 for ; Mon, 18 May 2020 17:09:41 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 0CE0720709 for ; Mon, 18 May 2020 17:09:40 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1589821781; bh=SDcAHs3RP/NJTR0fHxDeNTKL5pEWcy11bmIGRZ8XA4I=; h=Date:From:To:Cc:Subject:References:In-Reply-To:List-ID:From; b=Dihra5OSs7FNGEXS0WtH2ZJayLz8cfJ0rummf/UhwF+sk2O4JJ/zrcuPcu6+Hzvre JrLnJTjIhqr3LzRrpHj8igtraDZDw8DvX9YwGnYy72KpaXwUKfsxNpZJfbZmNIGZ1L uVvC4j08sUkAuObXW5JD9NcGc0uOA834bVPFxMf0= Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1728357AbgERRJh (ORCPT ); Mon, 18 May 2020 13:09:37 -0400 Received: from mail-pj1-f68.google.com ([209.85.216.68]:54600 "EHLO mail-pj1-f68.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1727006AbgERRJh (ORCPT ); Mon, 18 May 2020 13:09:37 -0400 Received: by mail-pj1-f68.google.com with SMTP id s69so113222pjb.4; Mon, 18 May 2020 10:09:36 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to:user-agent; bh=BpdZFKBxjPy5g9XACLYMs2Py89NvcD1b96UVdrU1huk=; b=HCmPyiD5Axpm3EtzAktC9koUaqP2TxLMd8CW25vWjEsX86kUSjUUcVw4mtX+7GK9qp 7fDhZYpy2+o+Ces1qabEXeH5XOdUWTsf2OQIJhtNBBuWi/mANCamqDP45SlkeWWldMb4 NfdcAYlCAJox1Wt7FXqxN0peRarsNVcB34NqTF937OphOk3UtLR+pND8yvxo8OSnZpCt OH4rQIM9ZcBXtiYsuFhGc6EDcCWte8/ecOCmpOy8KO1FbMQjjlhDIj4wDwMXFjNO965b BTvtSn9a88lv1dTIWclLTT4eszSo4WeCeook6PQbUE85piQHiAbVsGMLA6siOMZAY/XW BZOg== X-Gm-Message-State: AOAM531FYBxHDwk8lK9Jitt1g4aaw4gwwjDA3XaSZWwhaLgKwj094xex 6mBYhx9bS/XhGeQKgZyYGPQ= X-Google-Smtp-Source: ABdhPJw35pB+pM+AMb3AfYK730hICV8dwuHZ+BlWJw6Xe+cZu5OTn9VjdyZ0zAS4Kzq+3W/z+TyFsQ== X-Received: by 2002:a17:902:8a8d:: with SMTP id p13mr16933969plo.32.1589821776222; Mon, 18 May 2020 10:09:36 -0700 (PDT) Received: from 42.do-not-panic.com (42.do-not-panic.com. [157.230.128.187]) by smtp.gmail.com with ESMTPSA id q4sm4572021pfu.42.2020.05.18.10.09.34 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 18 May 2020 10:09:35 -0700 (PDT) Received: by 42.do-not-panic.com (Postfix, from userid 1000) id 73E02404B0; Mon, 18 May 2020 17:09:34 +0000 (UTC) Date: Mon, 18 May 2020 17:09:34 +0000 From: Luis Chamberlain To: Ben Greear Cc: Johannes Berg , jeyu@kernel.org, akpm@linux-foundation.org, arnd@arndb.de, rostedt@goodmis.org, mingo@redhat.com, aquini@redhat.com, cai@lca.pw, dyoung@redhat.com, bhe@redhat.com, peterz@infradead.org, tglx@linutronix.de, gpiccoli@canonical.com, pmladek@suse.com, tiwai@suse.de, schlad@suse.de, andriy.shevchenko@linux.intel.com, keescook@chromium.org, daniel.vetter@ffwll.ch, will@kernel.org, mchehab+samsung@kernel.org, kvalo@codeaurora.org, davem@davemloft.net, netdev@vger.kernel.org, linux-kernel@vger.kernel.org, linux-wireless@vger.kernel.org, ath10k@lists.infradead.org Subject: Re: [PATCH v2 12/15] ath10k: use new module_firmware_crashed() Message-ID: <20200518170934.GJ11244@42.do-not-panic.com> References: <20200515212846.1347-1-mcgrof@kernel.org> <20200515212846.1347-13-mcgrof@kernel.org> <2b74a35c726e451b2fab2b5d0d301e80d1f4cdc7.camel@sipsolutions.net> <20200518165154.GH11244@42.do-not-panic.com> <4ad0668d-2de9-11d7-c3a1-ad2aedd0c02d@candelatech.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4ad0668d-2de9-11d7-c3a1-ad2aedd0c02d@candelatech.com> User-Agent: Mutt/1.10.1 (2018-07-13) Sender: linux-wireless-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-wireless@vger.kernel.org On Mon, May 18, 2020 at 09:58:53AM -0700, Ben Greear wrote: > > > On 05/18/2020 09:51 AM, Luis Chamberlain wrote: > > On Sat, May 16, 2020 at 03:24:01PM +0200, Johannes Berg wrote: > > > On Fri, 2020-05-15 at 21:28 +0000, Luis Chamberlain wrote:> module_firmware_crashed > > > > > > You didn't CC me or the wireless list on the rest of the patches, so I'm > > > replying to a random one, but ... > > > > > > What is the point here? > > > > > > This should in no way affect the integrity of the system/kernel, for > > > most devices anyway. > > > > Keyword you used here is "most device". And in the worst case, *who* > > knows what other odd things may happen afterwards. > > > > > So what if ath10k's firmware crashes? If there's a driver bug it will > > > not handle it right (and probably crash, WARN_ON, or something else), > > > but if the driver is working right then that will not affect the kernel > > > at all. > > > > Sometimes the device can go into a state which requires driver removal > > and addition to get things back up. > > It would be lovely to be able to detect this case in the driver/system > somehow! I haven't seen any such cases recently, I assure you that I have run into it. Once it does again I'll report the crash, but the problem with some of this is that unless you scrape the log you won't know. Eventually, a uevent would indeed tell inform me. > but in case there is > some common case you see, maybe we can think of a way to detect it? ath10k is just one case, this patch series addresses a simple way to annotate this tree-wide. > > > So maybe I can understand that maybe you want an easy way to discover - > > > per device - that the firmware crashed, but that still doesn't warrant a > > > complete kernel taint. > > > > That is one reason, another is that a taint helps support cases *fast* > > easily detect if the issue was a firmware crash, instead of scraping > > logs for driver specific ways to say the firmware has crashed. > > You can listen for udev events (I think that is the right term), > and find crashes that way. You get the actual crash info as well. My follow up to this was to add uevent to add_taint() as well, this way these could generically be processed by userspace. Luis From mboxrd@z Thu Jan 1 00:00:00 1970 Return-path: Received: from mail-pj1-f65.google.com ([209.85.216.65]) by bombadil.infradead.org with esmtps (Exim 4.92.3 #3 (Red Hat Linux)) id 1jajGj-00058u-Hy for ath10k@lists.infradead.org; Mon, 18 May 2020 17:09:38 +0000 Received: by mail-pj1-f65.google.com with SMTP id ci23so104303pjb.5 for ; Mon, 18 May 2020 10:09:36 -0700 (PDT) Date: Mon, 18 May 2020 17:09:34 +0000 From: Luis Chamberlain Subject: Re: [PATCH v2 12/15] ath10k: use new module_firmware_crashed() Message-ID: <20200518170934.GJ11244@42.do-not-panic.com> References: <20200515212846.1347-1-mcgrof@kernel.org> <20200515212846.1347-13-mcgrof@kernel.org> <2b74a35c726e451b2fab2b5d0d301e80d1f4cdc7.camel@sipsolutions.net> <20200518165154.GH11244@42.do-not-panic.com> <4ad0668d-2de9-11d7-c3a1-ad2aedd0c02d@candelatech.com> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <4ad0668d-2de9-11d7-c3a1-ad2aedd0c02d@candelatech.com> List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: "ath10k" Errors-To: ath10k-bounces+kvalo=adurom.com@lists.infradead.org To: Ben Greear Cc: linux-wireless@vger.kernel.org, aquini@redhat.com, peterz@infradead.org, daniel.vetter@ffwll.ch, mchehab+samsung@kernel.org, will@kernel.org, bhe@redhat.com, ath10k@lists.infradead.org, tiwai@suse.de, mingo@redhat.com, dyoung@redhat.com, pmladek@suse.com, keescook@chromium.org, arnd@arndb.de, gpiccoli@canonical.com, rostedt@goodmis.org, cai@lca.pw, tglx@linutronix.de, andriy.shevchenko@linux.intel.com, akpm@linux-foundation.org, kvalo@codeaurora.org, netdev@vger.kernel.org, schlad@suse.de, linux-kernel@vger.kernel.org, jeyu@kernel.org, Johannes Berg , davem@davemloft.net On Mon, May 18, 2020 at 09:58:53AM -0700, Ben Greear wrote: > > > On 05/18/2020 09:51 AM, Luis Chamberlain wrote: > > On Sat, May 16, 2020 at 03:24:01PM +0200, Johannes Berg wrote: > > > On Fri, 2020-05-15 at 21:28 +0000, Luis Chamberlain wrote:> module_firmware_crashed > > > > > > You didn't CC me or the wireless list on the rest of the patches, so I'm > > > replying to a random one, but ... > > > > > > What is the point here? > > > > > > This should in no way affect the integrity of the system/kernel, for > > > most devices anyway. > > > > Keyword you used here is "most device". And in the worst case, *who* > > knows what other odd things may happen afterwards. > > > > > So what if ath10k's firmware crashes? If there's a driver bug it will > > > not handle it right (and probably crash, WARN_ON, or something else), > > > but if the driver is working right then that will not affect the kernel > > > at all. > > > > Sometimes the device can go into a state which requires driver removal > > and addition to get things back up. > > It would be lovely to be able to detect this case in the driver/system > somehow! I haven't seen any such cases recently, I assure you that I have run into it. Once it does again I'll report the crash, but the problem with some of this is that unless you scrape the log you won't know. Eventually, a uevent would indeed tell inform me. > but in case there is > some common case you see, maybe we can think of a way to detect it? ath10k is just one case, this patch series addresses a simple way to annotate this tree-wide. > > > So maybe I can understand that maybe you want an easy way to discover - > > > per device - that the firmware crashed, but that still doesn't warrant a > > > complete kernel taint. > > > > That is one reason, another is that a taint helps support cases *fast* > > easily detect if the issue was a firmware crash, instead of scraping > > logs for driver specific ways to say the firmware has crashed. > > You can listen for udev events (I think that is the right term), > and find crashes that way. You get the actual crash info as well. My follow up to this was to add uevent to add_taint() as well, this way these could generically be processed by userspace. Luis _______________________________________________ ath10k mailing list ath10k@lists.infradead.org http://lists.infradead.org/mailman/listinfo/ath10k