Re: X-Gene: Unhandled fault: synchronous external abort in pci_generic_config_read32

[Bjorn Helgaas]

On Tue, Jul 28, 2015 at 12:39 PM, Duc Dang <dhdang@xxxxxxx> wrote:
> On Mon, Jul 27, 2015 at 4:36 AM, Catalin Marinas
> <catalin.marinas@xxxxxxx> wrote:
>> On Fri, Jul 24, 2015 at 05:05:19PM -0700, Duc Dang wrote:
>>> On Fri, Jul 24, 2015 at 3:42 PM, Bjorn Helgaas <bhelgaas@xxxxxxxxxx> wrote:
>>> > I regularly see faults like this on an APM X-Gene:
>>> >
>>> >   U-Boot 2013.04-mustang_sw_1.14.14 (Dec 16 2014 - 15:59:33)
>>> >   CPU0: APM ARM 64-bit Potenza Rev B0 2400MHz PCP 2400MHz
>>> >        32 KB ICACHE, 32 KB DCACHE
>>> >        SOC 2000MHz IOBAXI 400MHz AXI 250MHz AHB 200MHz GFC 125MHz
>>> >   ...
>>> >   Unhandled fault: synchronous external abort (0x96000010) at 0xffffff8000110034
>>
>> That's generated by an external device (PCIe root complex, card etc.)
>> and some mis-configured CPU setting.
>>
>>> >   Internal error: : 96000010 [#1] SMP
>>> >   Modules linked in:
>>> >   CPU: 0 PID: 3723 Comm: ... 4.1.0-smp-DEV #3
>>> >   Hardware name: APM X-Gene Mustang board (DT)
>>> >   task: ffffffc7dc1a4140 ti: ffffffc7dc118000 task.ti: ffffffc7dc118000
>>> >   PC is at pci_generic_config_read32+0x4c/0xb8
>>> >   LR is at pci_generic_config_read32+0x40/0xb8
>>> >   pc : [<ffffffc00033b90c>] lr : [<ffffffc00033b900>] pstate: 600001c5
>>> >   ...
>>> >   Call trace:
>>> >   [<ffffffc00033b90c>] pci_generic_config_read32+0x4c/0xb8
>>> >   [<ffffffc00033bf58>] pci_user_read_config_byte+0x60/0xc4
>>> >   [<ffffffc0003496a8>] pci_read_config+0x15c/0x238
>>> >   [<ffffffc0002393b4>] sysfs_kf_bin_read+0x68/0xa0
>>> >   [<ffffffc00023896c>] kernfs_fop_read+0x9c/0x1ac
>>> >   [<ffffffc0001c361c>] __vfs_read+0x44/0x128
>>> >   [<ffffffc0001c3e28>] vfs_read+0x84/0x144
>>> >   [<ffffffc0001c4764>] SyS_read+0x50/0xb0
>>>
>>> The log shows kernel gets an exception when trying to access Mellanox
>>> card configuration space. This is usually due to suboptimal PCIe
>>> SerDes parameters are using in your board, which will cause bad link
>>> quality.
>>
>> I would have hoped that "suboptimal" means that it still works, albeit
>> not fully optimal ;).
>
> Yes, it should still work, but you may see crashes occasionally due to
> link quality.

A crash seems like a too-severe response to a link quality issue.
Isn't there some way to retry the access or return an error, so we
don't have to crash the whole system?
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/