RE: imx-uart DMA transaction error leading to OOPS on 4.14.95

[Robin Gong <yibin.gong@nxp.com>]

Hi Petr,
	Could you check the below patch set which is not in v4.14.98?
https://patchwork.kernel.org/patch/10057791/

> -----Original Message-----
> From: Petr Štetiar <ynezz@true.cz>
> Sent: 2019年2月11日 17:28
> To: Vinod Koul <vkoul@kernel.org>
> Cc: Fabio Estevam <festevam@gmail.com>; Lucas Stach
> <l.stach@pengutronix.de>; Robin Gong <yibin.gong@nxp.com>;
> dmaengine@vger.kernel.org; linux-arm-kernel@lists.infradead.org
> Subject: Re: imx-uart DMA transaction error leading to OOPS on 4.14.95
> 
> Vinod Koul <vkoul@kernel.org> [2019-02-11 17:36:16]:
> 
> Hi,
> 
> > > I've just encountered following OOPS on 4.14.95:
> > >
> > >   imx-uart 21f0000.serial: DMA transaction error.
> >
> > Do you see this on mainline as well, bit of fixes went into this
> > driver recently...
> 
> I've hit it only once on 4.14 so far, it's quite hard to reproduce it, so no big deal,
> but I've just thought, that someone might be interested. Once I find some way
> to reproduce it, I'll try to test it on some recent kernel.
> 
> BTW, any idea which of those fixes might be related to this Oops and might be
> worth backporting to 4.14?
> 
> > >   Unable to handle kernel paging request at virtual address a0ee501a
> > >   pgd = 9d7d4000
> > >   [a0ee501a] *pgd=2d8d1811, *pte=00000000, *ppte=00000000
> > >   Internal error: Oops: 7 [#1] SMP ARM
> ...
> > >   CPU: 0 PID: 2536 Comm: sh Not tainted 4.14.95 #0
> > >   Hardware name: Freescale i.MX6 Quad/DualLite (Device Tree)
> > >   task: 9f67ca00 task.stack: 9b642000
> > >   PC is at sdma_int_handler+0x7c/0x17c
> >
> > So we get an interrupt while doing shutdown.. That is interesting..
> 
> I'm using serial console on ttymxc0 (115200,8n1) and UHF RFID reader on
> ttymxc3(921600,8n1) which is sending reports asynchronously and it was active
> during the shutdown as I was testing new hardware revision during that time.
> 
> > >   PC is at sdma_int_handler+0x7c/0x17c
> > >   LR is at console_unlock+0x480/0x4ec
> 
> I'm not sure how to interpret this, but is it possible, that there might be some
> race while sdma_int_handler could be processing interrupt on ttymxc3 while
> the system is doing some console output on ttymxc0? I just use the console for
> observation, so I wasn't typing or otherwise utilizing it, so probably no reason
> for interrupt from ttymxc0.
> 
> -- ynezz
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel