From mboxrd@z Thu Jan 1 00:00:00 1970 From: Tony Lindgren Subject: Re: [WARNING: A/V UNSCANNABLE][Merge tag 'media/v4.11-1' of git] ff58d005cd: BUG: unable to handle kernel NULL pointer dereference at 0000039c Date: Mon, 27 Feb 2017 08:26:39 -0800 Message-ID: <20170227162639.GN21809@atomide.com> References: <58b07b30.9XFLj9Hhl7F6HMc2%fengguang.wu@intel.com> <20170225090741.GA20463@gmail.com> <20170227154124.GA20569@gmail.com> <20170227160750.GM21809@atomide.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Return-path: Received: from muru.com ([72.249.23.125]:36586 "EHLO muru.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751461AbdB0Q0p (ORCPT ); Mon, 27 Feb 2017 11:26:45 -0500 Content-Disposition: inline In-Reply-To: Sender: linux-leds-owner@vger.kernel.org List-Id: linux-leds@vger.kernel.org To: Thomas Gleixner Cc: Ingo Molnar , "devicetree@vger.kernel.org" , Ruslan Ruslichenko , "linux-omap@vger.kernel.org" , kernel@stlinux.com, Sean Young , wfg@linux.intel.com, Peter Zijlstra , Linus Torvalds , LKML , Mauro Carvalho Chehab , linux-mediatek@lists.infradead.org, Linux LED Subsystem , "linux-input@vger.kernel.org" , linux-amlogic@lists.infradead.org, kernel test robot , LKP , "linux-arm-kernel@lists.infradead.org" Linux * Thomas Gleixner [170227 08:20]: > On Mon, 27 Feb 2017, Tony Lindgren wrote: > > * Ingo Molnar [170227 07:44]: > > > Because it's not the requirement that hurts primarily, but the resulting > > > non-determinism and the sporadic crashes. Which can be solved by making the race > > > deterministic via the debug facility. > > > > > > If the IRQ handler crashed the moment it was first written by the driver author > > > we'd never see these problems. > > > > Just in case this is PM related.. Maybe the spurious interrupt is pending > > from earlier? This could be caused by glitches on the lines with runtime PM, > > or a pending interrupt during suspend/resume. In that case IRQ_DISABLE_UNLAZY > > might provide more clues if the problem goes away. > > It's not PM related. That's just silly hardware. At the moment when you > enable some magic bit in the control register, which is required to probe > the version, the fricking thing spits out a spurious interrupt despite the > interrupt enable bit in the same control register being still disabled. Of > course we cannot install an interrupt handler before having probed the > version and setup other stuff, except we add magic 'if (!initialized)' > crappola into the handler and lose the ability to install version dependent > handlers afterwards. OK and presumably no -EPROBE_DEFER happening either. > Wonderful crap that, isn't it? Sounds broken.. Regards, Tony