From: Russell King - ARM Linux <linux@arm.linux.org.uk>
To: "Woodruff, Richard" <r-woodruff2@ti.com>
Cc: "Menon, Nishanth" <nm@ti.com>, Tony Lindgren <tony@atomide.com>,
"Dr. H. Nikolaus Schaller" <hns@goldelico.com>,
Grazvydas Ignotas <notasas@gmail.com>,
Marek Belisko <marek@goldelico.com>,
"linux-omap@vger.kernel.org" <linux-omap@vger.kernel.org>,
"linux-arm-kernel@lists.infradead.org"
<linux-arm-kernel@lists.infradead.org>
Subject: Re: mysterious crashes on OMAP5 uevm
Date: Fri, 11 Sep 2015 18:48:37 +0100 [thread overview]
Message-ID: <20150911174837.GC21098@n2100.arm.linux.org.uk> (raw)
In-Reply-To: <EF62F09C0797D947AD4180A1043C0DF740C23E8D@DLEE11.ent.ti.com>
On Fri, Sep 11, 2015 at 04:12:21PM +0000, Woodruff, Richard wrote:
> > From: linux-omap-owner@vger.kernel.org [mailto:linux-omap-
> > owner@vger.kernel.org] On Behalf Of Russell King - ARM Linux
> > Sent: Friday, September 11, 2015 9:03 AM
> > To: Grazvydas Ignotas
>
> > However, even the idea that it's ARMv7 or later is wrong. According to
> > the ARM ARM, the IT instruction is present in ARMv6T2 as well, which
> > means it's ARMv6 too (which would have __LINUX_ARM_ARCH__ = 6).
>
> I recall seeing ARMv6T2 first implemented in the ARM1156 which is a
> v6 CPU with T2 option added.
Exactly, which is why we need to be dealing with the IT bits in signal
handling for >= ARMv6, not >= ARMv7.
> > Looking at the ARM ARM, these bits are "reserved" in previous non-T2
> > architectures, have an undefined value at reset, and are probably zero
> > anyway.
> >
> > Merely changing __LINUX_ARM_ARCH__ >= 7 to >= 6 should fix the
> > problem,
> > and I doubt there's any ARMv6 non-T2 systems out there that would be
> > affected by clearing the IT state bits.
>
> Probably you already looked, but cpsr.it usage is not restricted to this
> one spot.
Other places:
arch/arm/mm/extable.c-#ifdef CONFIG_THUMB2_KERNEL
arch/arm/mm/extable.c- /* Clear the IT state to avoid nasty surprises in the fixup */
arch/arm/mm/extable.c: regs->ARM_cpsr &= ~PSR_IT_MASK;
arch/arm/mm/extable.c-#endif
which is irrelevant here. This code only deals with kernel mode, and
the only time that this makes sense is when the kernel is built using
Thumb2 instructions. CONFIG_THUMB2_KERNEL covers the case properly.
arch/arm/probes/kprobes/test-core.c- regs->ARM_lr = val ^ (14 << 8);
arch/arm/probes/kprobes/test-core.c: regs->ARM_cpsr &= ~(APSR_MASK | PSR_IT_MASK);
arch/arm/probes/kprobes/test-core.c- regs->ARM_cpsr |= test_context_cpsr(scenario);
>From what I can see, this happens unconditionally.
KVM and Xen code... that requires virtualisation support, which is ARMv7.
arch/arm/probes/kprobes/actions-thumb.c... emulating an IT instruction.
arch/arm/probes/decode.h::it_advance... emulating Thumb2.
So really there's no other places that need fixing.
> Looking back at old notes I think both debug and signal handler code
> keyed on bit usage. I see from LXR kernel KVM code also uses in some
> capacity.
Frankly, Richard, you're getting on my nerves in this thread - you
seem to know all about this problem, yet you never reported the problem
upstream, so people are effectively having to waste time re-doing the
work that you've already done.
Nothing annoys me more than having people say "oh yes, I found that
problem and worked on it" and nothing coming of it (no report, no
patch, no nothing.)
As you have "old notes" you've already investigated this issue, and
presumably you came up with a patch. Where is it?
--
FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
according to speedtest.net.
next prev parent reply other threads:[~2015-09-11 17:48 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-09-08 12:46 mysterious crashes on OMAP5 uevm Grazvydas Ignotas
2015-09-08 14:38 ` Tony Lindgren
2015-09-08 20:41 ` Grazvydas Ignotas
2015-09-08 21:07 ` Tony Lindgren
2015-09-10 6:42 ` Dr. H. Nikolaus Schaller
2015-09-10 8:30 ` Russell King - ARM Linux
2015-09-10 8:57 ` Dr. H. Nikolaus Schaller
2015-09-10 23:33 ` Woodruff, Richard
2015-09-11 13:27 ` Grazvydas Ignotas
2015-09-11 14:03 ` Russell King - ARM Linux
2015-09-11 16:12 ` Woodruff, Richard
2015-09-11 17:48 ` Russell King - ARM Linux [this message]
2015-09-11 18:34 ` Woodruff, Richard
2015-09-14 12:12 ` Russell King - ARM Linux
2015-09-14 19:02 ` Tony Lindgren
2015-09-14 19:35 ` Dr. H. Nikolaus Schaller
2015-09-15 17:31 ` Grazvydas Ignotas
2015-09-16 10:07 ` Russell King - ARM Linux
2015-09-18 17:48 ` Tony Lindgren
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=20150911174837.GC21098@n2100.arm.linux.org.uk \
--to=linux@arm.linux.org.uk \
--cc=hns@goldelico.com \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-omap@vger.kernel.org \
--cc=marek@goldelico.com \
--cc=nm@ti.com \
--cc=notasas@gmail.com \
--cc=r-woodruff2@ti.com \
--cc=tony@atomide.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).