From: Tony Lindgren <tony@atomide.com>
To: Thomas Gleixner <tglx@linutronix.de>
Cc: Ingo Molnar <mingo@kernel.org>,
"devicetree@vger.kernel.org" <devicetree@vger.kernel.org>,
Ruslan Ruslichenko <rruslich@cisco.com>,
"linux-omap@vger.kernel.org" <linux-omap@vger.kernel.org>,
kernel@stlinux.com, Sean Young <sean@mess.org>,
wfg@linux.intel.com, Peter Zijlstra <peterz@infradead.org>,
Linus Torvalds <torvalds@linux-foundation.org>,
LKML <linux-kernel@vger.kernel.org>,
Mauro Carvalho Chehab <mchehab@infradead.org>,
linux-mediatek@lists.infradead.org,
Linux LED Subsystem <linux-leds@vger.kernel.org>,
"linux-input@vger.kernel.org" <linux-input@vger.kernel.org>,
linux-amlogic@lists.infradead.org,
kernel test robot <fengguang.wu@intel.com>, LKP <lkp@01.org>,
"linux-arm-kernel@lists.infradead.org"
<linux-arm-kernel@lists.infradead.org>Linux
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 [thread overview]
Message-ID: <20170227162639.GN21809@atomide.com> (raw)
In-Reply-To: <alpine.DEB.2.20.1702271712470.4732@nanos>
* Thomas Gleixner <tglx@linutronix.de> [170227 08:20]:
> On Mon, 27 Feb 2017, Tony Lindgren wrote:
> > * Ingo Molnar <mingo@kernel.org> [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
next prev parent reply other threads:[~2017-02-27 16:26 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-02-24 18:28 [WARNING: A/V UNSCANNABLE][Merge tag 'media/v4.11-1' of git] ff58d005cd: BUG: unable to handle kernel NULL pointer dereference at 0000039c kernel test robot
2017-02-24 19:15 ` Linus Torvalds
2017-02-25 9:07 ` Ingo Molnar
2017-02-25 18:02 ` Linus Torvalds
[not found] ` <CA+55aFy+ER8cYV02eZsKAOLnZBWY96zNWqUFWSWT1+3sZD4XnQ-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2017-02-27 10:09 ` Thomas Gleixner
2017-02-27 12:32 ` Thomas Gleixner
2017-02-27 15:41 ` Ingo Molnar
2017-02-27 16:07 ` Tony Lindgren
[not found] ` <20170227160750.GM21809-4v6yS6AI5VpBDgjK7y7TUQ@public.gmane.org>
2017-02-27 16:18 ` Thomas Gleixner
2017-02-27 16:26 ` Tony Lindgren [this message]
[not found] ` <20170227154124.GA20569-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
2017-02-27 16:12 ` Thomas Gleixner
2017-02-27 19:23 ` Linus Torvalds
[not found] ` <CA+55aFxwtkOs95R-v7z8yjguvp91oDTxRKs-x3uN_=sM_33Gvg-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2017-02-28 7:25 ` Ingo Molnar
2017-02-28 10:51 ` Thomas Gleixner
2017-02-25 11:14 ` Sean Young
2017-02-25 11:28 ` [PATCH] [media] serial_ir: ensure we're ready to receive interrupts Sean Young
[not found] ` <20170225112816.GA7981-3XSxi2G4b3iXFJAUJl40Xg@public.gmane.org>
2017-02-25 13:34 ` Mauro Carvalho Chehab
[not found] ` <20170225103437.58c5a199-ch4gOOMV7nf/PtFMR13I2A@public.gmane.org>
2017-02-25 13:54 ` Mauro Carvalho Chehab
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20170227162639.GN21809@atomide.com \
--to=tony@atomide.com \
--cc=devicetree@vger.kernel.org \
--cc=fengguang.wu@intel.com \
--cc=kernel@stlinux.com \
--cc=linux-amlogic@lists.infradead.org \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-input@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-leds@vger.kernel.org \
--cc=linux-mediatek@lists.infradead.org \
--cc=linux-omap@vger.kernel.org \
--cc=lkp@01.org \
--cc=mchehab@infradead.org \
--cc=mingo@kernel.org \
--cc=peterz@infradead.org \
--cc=rruslich@cisco.com \
--cc=sean@mess.org \
--cc=tglx@linutronix.de \
--cc=torvalds@linux-foundation.org \
--cc=wfg@linux.intel.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).