[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <20210619085535.rpqitskpptgj7dwk@pali>
Date: Sat, 19 Jun 2021 10:55:35 +0200
From: Pali Rohár <pali@...nel.org>
To: Lukas Wunner <lukas@...ner.de>
Cc: David Laight <David.Laight@...LAB.COM>,
Greg KH <gregkh@...uxfoundation.org>,
"linux-usb@...r.kernel.org" <linux-usb@...r.kernel.org>,
"linux-pci@...r.kernel.org" <linux-pci@...r.kernel.org>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
Marek Behún <kabel@...nel.org>
Subject: Re: xhci_pci & PCIe hotplug crash
On Saturday 19 June 2021 09:53:58 Lukas Wunner wrote:
> On Wed, May 05, 2021 at 05:39:42PM +0200, Pali Rohár wrote:
> > On Wednesday 05 May 2021 15:20:11 David Laight wrote:
> > > From: Pali Rohár
> > > Sent: 05 May 2021 14:03
> > > > So seems that PCIe controller HW triggers these external aborts when
> > > > device on PCIe bus is not accessible anymore.
> > > >
> > > > If this issue is really caused by MMIO access from xhci driver when
> > > > device is not accessible on the bus anymore, can we do something to
> > > > prevent this kernel crash? Somehow mask that external abort in kernel
> > > > for a time during MMIO access?
> > >
> > > If it is a cycle abort then the interrupted address is probably
> > > that of the MMIO instruction.
> > > So you need to catch the abort, emulate the instruction and
> > > then return to the next one.
> >
> > Has kernel API & infrastructure for catching these aborts and executing
> > own driver handler when abort happens?
>
> Yes, see here for an example:
>
> https://lore.kernel.org/linux-pci/20210615191405.21878-4-jim2101024@gmail.com/
What I do not see here how to catch and recover from error. It looks
like that in above patch is just implemented catching error, printing
more verbose output and let kernel continue in rebooting / crashing.
At least I do not see how to "catch the abort, emulate the instruction
and then return to the next one" as David wrote.
Powered by blists - more mailing lists