From mboxrd@z Thu Jan 1 00:00:00 1970 From: Thomas Gleixner 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 17:18:28 +0100 (CET) Message-ID: 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" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <20170227160750.GM21809-4v6yS6AI5VpBDgjK7y7TUQ@public.gmane.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: "Linux-mediatek" Errors-To: linux-mediatek-bounces+glpam-linux-mediatek=m.gmane.org-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org To: Tony Lindgren Cc: "devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org" , Ruslan Ruslichenko , kernel test robot , kernel-F5mvAk5X5gdBDgjK7y7TUQ@public.gmane.org, Sean Young , Peter Zijlstra , LKP , LKML , Mauro Carvalho Chehab , wfg-VuQAYsv1563Yd54FQh9/CA@public.gmane.org, "linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org" , "linux-input-u79uwXL29TY76Z2rM5mHXA@public.gmane.org" , linux-mediatek-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org, linux-amlogic-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org, "linux-omap-u79uwXL29TY76Z2rM5mHXA@public.gmane.org" , Linus Torvalds , Ingo Molnar , Linux LED Subsystem , Linux Media Mailing List List-Id: linux-mediatek@lists.infradead.org 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. Wonderful crap that, isn't it? Thanks, tglx