From: Dave.Martin@arm.com (Dave Martin)
To: linux-arm-kernel@lists.infradead.org
Subject: undefined instruction d5380001
Date: Mon, 2 Oct 2017 12:24:33 +0100 [thread overview]
Message-ID: <20171002112433.GM3611@e103592.cambridge.arm.com> (raw)
In-Reply-To: <CAJs94EZqdWJRTF+tLgGU=pcRoU5HvuV959Qq8nFB5yQ-sQyxzg@mail.gmail.com>
On Fri, Sep 29, 2017 at 10:23:54PM +0300, Matwey V. Kornilov wrote:
> Hello,
>
> I am running 4.13.3 on rockchip 3328 platform(aarch64) with glibc 2.26
> and see the following at booting:
>
> [ 11.152061] modprobe[93]: undefined instruction: pc=0000ffff8ca48ff4
> [ 11.152707] Code: d503201f 8a180320 92750001 365ffc20 (d5380001)
> [ 11.154347] modprobe[94]: undefined instruction: pc=0000ffff94243ff4
> [ 11.154991] Code: d503201f 8a180320 92750001 365ffc20 (d5380001)
> [ 11.157070] modprobe[97]: undefined instruction: pc=0000ffff839a0ff4
> [ 11.157715] Code: d503201f 8a180320 92750001 365ffc20 (d5380001)
> [ 11.159265] modprobe[98]: undefined instruction: pc=0000ffffb0591ff4
> [ 11.159908] Code: d503201f 8a180320 92750001 365ffc20 (d5380001)
>
> As far as I understand d5380001 should be emulated in cpufeature.c but
> it is not. What could be wrong here?
The whole sequence is
0: d503201f nop
4: 8a180320 and x0, x25, x24
8: 92750001 and x1, x0, #0x800
c: 365ffc20 tbz w0, #11, 0xffffffffffffff90
10:* d5380001 mrs x1, midr_el1 <-- trapping instruction
I'm _guessing_ this is the glibc startup code, or otherwise something
similar:
http://www.sourceware.org/git/?p=glibc.git;a=blob;f=sysdeps/unix/sysv/linux/aarch64/cpu-features.c;h=0275d11c7fa5cba02f3173db25a8a02993e92b7e;hb=1c9a5c270d8b66f30dcfaf1cb2d6cf39d3e18369#l46
The emulation is not guaranteed to work if HWCAP_CPUID (1 << 11) is not
set, but this code does seem to be checking correctly, and v4.13 should
unconditionally set this hwcap and emulate MRS.
So no, I don't know what's going wrong here.
What should happen here is that the do_undefinstr() in
arch/arm64/kernel/traps.c should call registered undef hooks until it
finds one that accepts the faulting instruction.
So, either the cpufeatures undef hook is not getting called, or it is
failing the instruction somewhere, possibly in
cpufeatures.c:emulate_id_reg() or emulate_sys_reg().
Can you add some trace to those functions to see what's happening?
Cc'ing Suzuki, who knows this code better than me and may have some
ideas.
Cheers
---Dave
next prev parent reply other threads:[~2017-10-02 11:24 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-09-29 19:23 undefined instruction d5380001 Matwey V. Kornilov
2017-10-02 11:24 ` Dave Martin [this message]
2017-10-02 14:11 ` undefined instruction d5380001 (arm64 mrs emulation) James Morse
2017-10-02 15:56 ` Suzuki K Poulose
2017-10-04 9:11 ` Matwey V. Kornilov
2017-10-05 14:54 ` Matthias Brugger
2017-10-05 14:59 ` Mark Rutland
2017-10-05 16:16 ` Catalin Marinas
2017-10-06 12:05 ` Matthias Brugger
2017-10-06 13:13 ` Catalin Marinas
2017-10-06 13:57 ` Matthias Brugger
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=20171002112433.GM3611@e103592.cambridge.arm.com \
--to=dave.martin@arm.com \
--cc=linux-arm-kernel@lists.infradead.org \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.