From: fabrice.gasnier@st.com (Fabrice Gasnier)
To: linux-arm-kernel@lists.infradead.org
Subject: Why are imprecise external aborts masked on recent kernel while booting ?
Date: Fri, 31 Jan 2014 16:59:41 +0100 [thread overview]
Message-ID: <52EBC86D.1010509@st.com> (raw)
Hi all,
I'm working on a PCIe driver that uses an "imprecise external abort"
handler to detect when a port is behind a switch.
This mechanism is used when enumerating PCIe bus upon kernel boot.
In prior kernel (3.4), I noticed it's possible to use an abort handler
registered by using hook_fault_code(16+6, ...);
These aborts are detected and the relevant handler is called as long as
it is registered, when probing the bus.
In more recent kernel (3.10), abort handler is no longer triggered
during kernel boot. At PCIe bus enumeration, imprecise aborts are not
enabled. It seems unmasked later when starting userland init process
(e.g. when CPSR.A bit on arm is cleared). Aborts are deferred until then.
I found another thread that looks like similar :
http://lists.infradead.org/pipermail/linux-arm-kernel/2013-October/208641.html
I looked for where imprecise aborts were enabled on 3.4. I found out
that it was enabled when the first schedule() happens. More precisely in
kernel_thread_helper() when doing: "msr cpsr_c, r7".
There has been changes beetween 3.6 or 3.7, like in commit
9e14f828ee4a7a4a98703e380d180717a579fb35 (and others) that i believe
changes the behavior of unmasking CPSR.A bit. kernel_thread_helper has
been removed in that patch.
Is it a desired change in recent kernels ?
Is it possible to unmask imprecise data aborts earlier in the boot
process (e.g. before PCIe bus enumeration, when drivers are being probed) ?
Best regards,
Fabrice
next reply other threads:[~2014-01-31 15:59 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-01-31 15:59 Fabrice Gasnier [this message]
2014-01-31 17:08 ` Why are imprecise external aborts masked on recent kernel while booting ? Russell King - ARM Linux
2014-02-03 9:12 ` Fabrice Gasnier
2014-02-03 16:43 ` Fabrice Gasnier
2014-02-07 16:20 ` Fabrice Gasnier
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=52EBC86D.1010509@st.com \
--to=fabrice.gasnier@st.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 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).