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@xxxxxxx> > Sent: 2019年2月11日 17:28 > To: Vinod Koul <vkoul@xxxxxxxxxx> > Cc: Fabio Estevam <festevam@xxxxxxxxx>; Lucas Stach > <l.stach@xxxxxxxxxxxxxx>; Robin Gong <yibin.gong@xxxxxxx>; > dmaengine@xxxxxxxxxxxxxxx; linux-arm-kernel@xxxxxxxxxxxxxxxxxxx > Subject: Re: imx-uart DMA transaction error leading to OOPS on 4.14.95 > > Vinod Koul <vkoul@xxxxxxxxxx> [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
