linux-arm-kernel.lists.infradead.org archive mirror
 help / color / mirror / Atom feed
From: arend.vanspriel@broadcom.com (Arend van Spriel)
To: linux-arm-kernel@lists.infradead.org
Subject: question about arm64 exception handling
Date: Mon, 2 Jul 2018 12:34:00 +0200	[thread overview]
Message-ID: <5B39FF98.7010002@broadcom.com> (raw)
In-Reply-To: <e54b3d4c-dbd0-b39d-28a2-063f34068dfd@arm.com>

On 6/28/2018 6:13 PM, James Morse wrote:
> Hi Arend,
>
> On 28/06/18 12:58, Arend van Spriel wrote:
>> I am looking at some issues we are seeing on a custom arm platform and I had
>> some questions regarding exception handling and hope you can help me with that.
>>
>> The platform has 4 cortex a53 cores running 4.1.51 kernel.
>
> v4.1 is circa 2015, and chance you could try v4.17?

Hi James,

If it were up to me, sure. Unfortunately it is not :-(

>> On the platform upon
>> accessing our wifi devices over PCIe, we observe two issue intermittently.
>>
>> 1) synchronous external abort
>> 2) NMI watchdog
>>
>> With the latter I notice el1_irq in the exception stack trace. Is that due to
>> the NMI watchdog or is this caused by another issue like our crappy hardware ;-) ?
>
>
>> Regarding the SEA I noticed stuff has been added for that in 4.13. Is is worth
>> backporting that to obtain more info about that?
>
> Unlikely. Those changes are related to firmware-first RAS. You would see this on
> server platforms booting with ACPI and have a 'HEST' table.

I see. That is not really what I am working with here.

> Can you share the backtrace for the Synchronous External Abort? It should point
> at the instruction in the (probably) driver that causes the abort.

15:05:24.284  LOG   4908REF2   Unhandled fault: synchronous external 
abort (0x96000210) at 0xffffff80010a4154

So between brackets is the ESR. Looking in the TRM I can only conclude 
it is exception class 0x25 whatever that is. Need to dive in armv8a arch 
doc. So the address 0xffffff80010a4154 is the fault address. It is not 
in the range of my wireless driver, but it is probably in the PCIe host 
driver accessing the device.

Thanks for the pointers. Digging deeper.

Regards,
Arend

  reply	other threads:[~2018-07-02 10:34 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-06-28 11:58 question about arm64 exception handling Arend van Spriel
2018-06-28 16:13 ` James Morse
2018-07-02 10:34   ` Arend van Spriel [this message]
2018-07-02 10:53     ` James Morse

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=5B39FF98.7010002@broadcom.com \
    --to=arend.vanspriel@broadcom.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).