From: Stefan Agner <stefan@agner.ch>
To: Andrey Smirnov <andrew.smirnov@gmail.com>
Cc: Fabio Estevam <festevam@gmail.com>,
Jingoo Han <jingoohan1@gmail.com>,
gustavo.pimentel@synopsys.com,
Lucas Stach <l.stach@pengutronix.de>,
Trent Piepho <tpiepho@impinj.com>,
Bjorn Helgaas <bhelgaas@google.com>,
linux-pci@vger.kernel.org,
linux-kernel <linux-kernel@vger.kernel.org>,
Leonard Crestez <leonard.crestez@nxp.com>
Subject: Re: [PATCH v2 3/3] PCI: imx6: limit DBI register length
Date: Wed, 28 Nov 2018 13:45:15 +0100 [thread overview]
Message-ID: <482dc823b1567c9a933104b02a6bfeac@agner.ch> (raw)
In-Reply-To: <CAHQ1cqFprD4k+aO_x-znEs6sXpx9jxih-moSuNZZ3dAKHuLpPw@mail.gmail.com>
On 28.11.2018 02:28, Andrey Smirnov wrote:
> On Tue, Nov 27, 2018 at 5:12 PM Fabio Estevam <festevam@gmail.com> wrote:
>>
>> Hi Andrey,
>>
>> On Tue, Nov 27, 2018 at 10:57 PM Andrey Smirnov
>> <andrew.smirnov@gmail.com> wrote:
>>
>> > Could this be a regression? Prior to 415b6185c541 ("PCI: imx6: Fix
>> > config read timeout handling") all of the imprecise aborts were caught
>> > and handled via no-op handler. I did an experiment on i.MX6Q board
>> > that I have (ZII RDU2) and adding a simple no-op for imprecise aborts
>> > via
>> >
>> > hook_fault_code(16 + 6, imx6q_pcie_no_op_handler, SIGBUS, 0,
>> > "imprecise external abort");
Unsurprisingly, introducing this handler also "fixes" the issue in my
setup.
FWIW, during my investigation with the Thumb2 issue, I was looking at
the abort handler and its history a bit more closely too. I was about to
suggest readding this handler too, you just beat me by some hours :-)
The current 4.9 downstream BSP still has the old fault handler, and
hence this issue does not happen in the downstream BSP.
>> >
>> > seems to "resolve" this problem:
>>
>> Please check https://patchwork.kernel.org/patch/9720313/
>>
>> This commit fixed a kernel crash on mx6q boards with a PCI switch.
>>
>> So we can't go back to the simple no-op.
>
> It's probably not exactly clear form my message, but I wasn't
> proposing to go back to a no-op. What I had in mind is having a no-op
> handler for imprecise aborts _alongside_ the non-linefetch handlers
> that is already there when running against i.MX6Q type of the IP
> block.
>
Agreed, it should be alongside the "external abort on non-linefetch"
handler.
I actually encountered another issue when I had a Intel e1000e running
yesterday. Unfortunately I wasn't able to reproduce the issue, so maybe
it was just a fluke. It probably would be solved by the additional
"imprecise external abort" too:
[ 37.644300] fec 2188000.ethernet eth0: Link is Down
[ 38.077383] Unhandled fault: imprecise external abort (0x1406) at
0xb64e8000
[ 38.084638] pgd = ac4709d6
[ 38.087434] [b64e8000] *pgd=00000000
[ 38.091129] Internal error: : 1406 [#1] PREEMPT SMP ARM
[ 38.096508] CPU: 0 PID: 468 Comm: kworker/0:2 Not tainted
4.19.4-00044-ged7a0cc2ef01-dirty #479
[ 38.105428] Hardware name: Freescale i.MX6 Quad/DualLite (Device
Tree)
[ 38.112143] Workqueue: events e1000_watchdog_task
[ 38.116993] PC is at e1000e_update_stats+0x68/0xa7c
[ 38.122008] LR is at e1000_watchdog_task+0xe8/0x71c
[ 38.127021] pc : [<c0621238>] lr : [<c0628d0c>] psr: 60010013
[ 38.133449] sp : ed185ea0 ip : 00007374 fp : ec83ece4
[ 38.138814] r10: ec71f700 r9 : ec83c500 r8 : ec83c000
[ 38.144180] r7 : ec83c924 r6 : ec83c000 r5 : c1104cc8 r4 :
ec83c500
[ 38.150875] r3 : f14c4000 r2 : 000003e8 r1 : 00000000 r0 :
ec83c500
[ 38.157573] Flags: nZCv IRQs on FIQs on Mode SVC_32 ISA ARM
Segment none
[ 38.164890] Control: 10c5387d Table: 3d1c004a DAC: 00000051
[ 38.170789] Process kworker/0:2 (pid: 468, stack limit = 0xbc71b316)
[ 38.177306] Stack: (0xed185ea0 to 0xed186000)
[ 38.181794] 5ea0: ef7a9100 c0619ba3 ec0870e0 ec087068 ec0870e0
00000000 60010013 c0619ba3
[ 38.190184] 5ec0: ef7a8d00 ec83c54c c1104cc8 ec83e54c ec83c924
ec83c000 ec83c500 ec71f700
[ 38.198573] 5ee0: ec83ece4 c0628d0c ecbd16c0 c0c0237c ed185f3c
c0b26de0 ec131c04 c0619ba3
[ 38.206966] 5f00: c1153fe4 ec83c54c ecdcc100 ef7a8d00 ef7a9e00
00000000 ec83c550 00000000
[ 38.221770] 5f20: ef7a8d00 c0136aec c1103d00 ef7a8d18 ecdcc100
ef7a8d00 ecdcc114 c1103d00
[ 38.236801] 5f40: ef7a8d18 ffffe000 00000008 c0136d40 ec521c70
c1176068 c0e4213c ed184000
[ 38.251874] 5f60: ecfecfdc ecfecfc0 ed0db1c0 00000000 ed184000
ecdcc100 c0136cfc ec0a3ea4
[ 38.267199] 5f80: ecfecfdc c013c810 00000000 ed0db1c0 c013c6c8
00000000 00000000 00000000
[ 38.282612] 5fa0: 00000000 00000000 00000000 c01010e8 00000000
00000000 00000000 00000000
[ 38.298080] 5fc0: 00000000 00000000 00000000 00000000 00000000
00000000 00000000 00000000
[ 38.313792] 5fe0: 00000000 00000000 00000000 00000000 00000013
00000000 00000000 00000000
[ 38.329716] [<c0621238>] (e1000e_update_stats) from [<c0628d0c>]
(e1000_watchdog_task+0xe8/0x71c)
[ 38.346597] [<c0628d0c>] (e1000_watchdog_task) from [<c0136aec>]
(process_one_work+0x1f0/0x400)
[ 38.363493] [<c0136aec>] (process_one_work) from [<c0136d40>]
(worker_thread+0x44/0x584)
[ 38.379844] [<c0136d40>] (worker_thread) from [<c013c810>]
(kthread+0x148/0x150)
[ 38.395575] [<c013c810>] (kthread) from [<c01010e8>]
(ret_from_fork+0x14/0x2c)
[ 38.411119] Exception stack(0xed185fb0 to 0xed185ff8)
[ 38.420331] 5fa0: 00000000
00000000 00000000 00000000
[ 38.436662] 5fc0: 00000000 00000000 00000000 00000000 00000000
00000000 00000000 00000000
[ 38.452933] 5fe0: 00000000 00000000 00000000 00000000 00000013
00000000
[ 38.463661] Code: e590641c e2833901 e5931000 f57ff04f (e280ad9f)
--
Stefan
next prev parent reply other threads:[~2018-11-28 12:45 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-11-20 13:27 [PATCH v2 1/3] PCI: dwc: allow to limit registers set length Stefan Agner
2018-11-20 13:27 ` [PATCH v2 2/3] PCI: imx6: introduce drvdata Stefan Agner
2018-11-20 14:36 ` Lucas Stach
2018-11-20 13:27 ` [PATCH v2 3/3] PCI: imx6: limit DBI register length Stefan Agner
2018-11-20 14:37 ` Lucas Stach
2018-11-28 0:56 ` Andrey Smirnov
2018-11-28 1:12 ` Fabio Estevam
2018-11-28 1:28 ` Andrey Smirnov
2018-11-28 12:45 ` Stefan Agner [this message]
2018-11-20 14:35 ` [PATCH v2 1/3] PCI: dwc: allow to limit registers set length Lucas Stach
2018-11-20 15:14 ` Lorenzo Pieralisi
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=482dc823b1567c9a933104b02a6bfeac@agner.ch \
--to=stefan@agner.ch \
--cc=andrew.smirnov@gmail.com \
--cc=bhelgaas@google.com \
--cc=festevam@gmail.com \
--cc=gustavo.pimentel@synopsys.com \
--cc=jingoohan1@gmail.com \
--cc=l.stach@pengutronix.de \
--cc=leonard.crestez@nxp.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-pci@vger.kernel.org \
--cc=tpiepho@impinj.com \
/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).