CODEWITHSUNDEEP
linux-kernelarmembeddedarm64abort
puhitaku
puhitaku

Reputation: 126

Dismiss or Handle Data Abort when AXI transaction replies an error

Background

I have an ZynqMP system which has four Cortex-A53 cores (PS) along with FPGA logic (PL). They transfer data via AXI bus.

I've placed some Xilinx AXI Quad SPI in my design. Linux which runs on PS successfully probes them, and starts a daemons which periodically (333 Hz) ask MCUs on SPIs to reply their data chunk (~ up to around 500 bytes, split in every 64 bytes.)

They works nicely for a while (median 50 minutes) but suddenly the readl_relaxed() in SPI driver causes Synchronous External Abort which leads an Kernel Panic. It seems to be an AXI's error reply according to ARM TRM, and might be recoverable because it's "synchronous" which means the registers are not corrupted (in my understanding.)

After some search I found the do_sea() func that handles SEA and also found that there's no chance to recover from it according to the implementation.

I want the AXI error to be handled like: discard the read, return SIGBUS and lead the process to be killed, etc.

Of course I'm debugging the Abort and finding why it occurs but at present I have no clue.

Question

So my questions are:

  1. Why SEAs are not recoverable in Linux arm64 implementation?
  2. If I can "handle" or "ignore" it, how do I modify Linux kernel code (I know it's stupid but I'd like to know if there's a way.)
  3. What can reply error in Quad SPI IP? The readl_relaxed I mentioned above reads Rx data FIFO.

Upvotes: 1

Views: 876

Answers (1)

mevets
mevets

Reputation: 10445

1) I’ve never ventured down this path, but it looks to me like they are recoverable if the inf->fn returns 0; which means that ghes_notify_sea() must return 0; thus one of the SEA error sources successfully reported an error.

2) I think you need a bit more info. I would start by changing drivers/acpi/apei/ghes.c:732

from:
rc = ghes_read_estatus(ghes, 0);
to:
rc = ghes_read_estatus(ghes, 1);

which should get you a bit more information when the error happens. Armed with that information, you need to find out if you have a malfunctioning handler, or a missing one. Either way, this is the place to address it.

3) You are dealing with an ACPI implementation. There are 155 kloc in the kernel plus unknown quantity in the firmware and hardware. The kernel code doesn’t appear to handle whichever condition you are running into. First you need to determine which of these suspects is involved and what interactions are failing before you can dig out the root cause.

Happy Digging!

Upvotes: 1

Related Questions