From patchwork Thu Oct 22 00:48:23 2015 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Marc Herbert X-Patchwork-Id: 7461621 Return-Path: X-Original-To: patchwork-intel-gfx@patchwork.kernel.org Delivered-To: patchwork-parsemail@patchwork2.web.kernel.org Received: from mail.kernel.org (mail.kernel.org [198.145.29.136]) by patchwork2.web.kernel.org (Postfix) with ESMTP id BFF36BEEA4 for ; Thu, 22 Oct 2015 00:48:47 +0000 (UTC) Received: from mail.kernel.org (localhost [127.0.0.1]) by mail.kernel.org (Postfix) with ESMTP id 432F6207BA for ; Thu, 22 Oct 2015 00:48:45 +0000 (UTC) Received: from gabe.freedesktop.org (gabe.freedesktop.org [131.252.210.177]) by mail.kernel.org (Postfix) with ESMTP id D3DA920790 for ; Thu, 22 Oct 2015 00:48:43 +0000 (UTC) Received: from gabe.freedesktop.org (localhost [127.0.0.1]) by gabe.freedesktop.org (Postfix) with ESMTP id 3EA646E392; Wed, 21 Oct 2015 17:48:42 -0700 (PDT) X-Original-To: intel-gfx@lists.freedesktop.org Delivered-To: intel-gfx@lists.freedesktop.org Received: from plane.gmane.org (plane.gmane.org [80.91.229.3]) by gabe.freedesktop.org (Postfix) with ESMTPS id 3E9E66E392 for ; Wed, 21 Oct 2015 17:48:41 -0700 (PDT) Received: from list by plane.gmane.org with local (Exim 4.69) (envelope-from ) id 1Zp43X-0005Jv-OL for intel-gfx@lists.freedesktop.org; Thu, 22 Oct 2015 02:48:36 +0200 Received: from jfdmzpr03-ext.jf.intel.com ([134.134.137.72]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Thu, 22 Oct 2015 02:48:35 +0200 Received: from Marc.Herbert by jfdmzpr03-ext.jf.intel.com with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Thu, 22 Oct 2015 02:48:35 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: intel-gfx@lists.freedesktop.org From: Marc Herbert Date: Wed, 21 Oct 2015 17:48:23 -0700 Lines: 67 Message-ID: References: <1442589429-27813-1-git-send-email-mika.kuoppala@intel.com> <1442589429-27813-2-git-send-email-mika.kuoppala@intel.com> <87twqo9qmc.fsf@intel.com> <876134w4wj.fsf@gaia.fi.intel.com> <56163A31.2040602@intel.com> <87r3l5tupw.fsf@gaia.fi.intel.com> Mime-Version: 1.0 X-Complaints-To: usenet@ger.gmane.org X-Gmane-NNTP-Posting-Host: jfdmzpr03-ext.jf.intel.com X-Mozilla-News-Host: news://news.gmane.org User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.1.0 In-Reply-To: <87r3l5tupw.fsf@gaia.fi.intel.com> Subject: Re: [Intel-gfx] [PATCH 2/5] drm/i915: Notify user about outdated dmc firmware X-BeenThere: intel-gfx@lists.freedesktop.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: Intel graphics driver community testing & development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: intel-gfx-bounces@lists.freedesktop.org Sender: "Intel-gfx" X-Spam-Status: No, score=-4.2 required=5.0 tests=BAYES_00, RCVD_IN_DNSWL_MED, RP_MATCHES_RCVD, UNPARSEABLE_RELAY autolearn=unavailable version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on mail.kernel.org X-Virus-Scanned: ClamAV using ClamSMTP > On machines that had 1.19 symlinked, in filesystem, execlist submission > sometimes broke due to interrupt delivery problem. To reach a conclusion > that it was csr firmware, before 1.21 was out, took quite amount of work. > > I bet there are still machines with 1.19 only, and we get to > wade through error states trying to connect the dots. > > [...] > So we are left with triaging. Which is true detective work as there are > no traces of firmware versions nor loading success/fails on > logs/error states. > I think this "Finished loading" log statement below should not just include the version numbers, its level should also be increased to something like "INFO" so the DMC version always makes it to the logs. Collecting the error state is less obvious and less usual than collecting logs; some users don't even know about it. >>>>> @@ -387,6 +390,12 @@ static void finish_csr_load(const struct firmware *fw, void *context) >>>>> >>>>> DRM_DEBUG_KMS("Finished loading %s v%u.%u\n", dev_priv->csr.fw_path, >>>>> csr->dmc_ver_major, csr->dmc_ver_minor); --------- To be honest (and likely off-topic), I even think request_firmware() should log the resolved symlink by default. Quick & dirty proof of concept below to illustrate. The kernel is normally quick enough to squeal "TAINTED!". On the other hand request_firmware() loads random binaries without even saying anywhere it did. Rationale? Marc --- a/drivers/base/firmware_class.c +++ b/drivers/base/firmware_class.c @@ -344,17 +345,24 @@ static int fw_get_filesystem_firmware(struct device *device, else break; } - __putname(path); if (!rc) { - dev_dbg(device, "firmware: direct-loading firmware %s\n", - buf->fw_id); + // fallback on symlink in case lookup goes wrong + const char *resolved_sym = path; + + struct path dp; + if (!kern_path(path, LOOKUP_FOLLOW, &dp)) + resolved_sym = dp.dentry->d_name.name; + + dev_info(device, "firmware: direct-loading firmware %s\n", + resolved_sym); mutex_lock(&fw_lock); set_bit(FW_STATUS_DONE, &buf->status); complete_all(&buf->completion); mutex_unlock(&fw_lock); } + __putname(path); return rc; }