* imx-uart DMA transaction error leading to OOPS on 4.14.95 @ 2019-02-06 8:13 Petr Štetiar 2019-02-11 12:06 ` Vinod Koul 0 siblings, 1 reply; 5+ messages in thread From: Petr Štetiar @ 2019-02-06 8:13 UTC (permalink / raw) To: dmaengine; +Cc: linux-arm-kernel Hi, I've just encountered following OOPS on 4.14.95: imx-uart 21f0000.serial: DMA transaction error. 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 Modules linked in: ath9k ath9k_htc ath9k_common qcserial ath9k_hw ath usb_wwan ti_usb_3410_5052 qmi_wwan pl2303 mac80211 keyspan iptable_nat iptable_mangle iptable_filter ipt_REJECT ipt_MASQUERADE ip_tables ftdi_sio cypress_m8 cp210x ch341 cfg80211 xt_time xt_tcpudp xt_state xt_nat xt_multiport xt_mark xt_mac xt_limit xt_conntrack xt_comment xt_TCPMSS xt_REDIRECT xt_LOG xt_FLOWOFFLOAD x_tables usbserial usbnet usblp spidev nf_reject_ipv4 nf_nat_redirect nf_nat_masquerade_ipv4 nf_conntrack_ipv4 nf_nat_ipv4 nf_nat_ftp nf_nat nf_log_ipv4 nf_log_common nf_flow_table_hw nf_flow_table nf_defrag_ipv4 nf_conntrack_rtcache nf_conntrack_ftp nf_conntrack lm75 lib80211_crypt_wep lib80211_crypt_tkip lib80211_crypt_ccmp lib80211 ezusb crc_itu_t crc_ccitt compat cdc_wdm cdc_acm evdev usb_f_acm u_serial libcomposite ledtrig_oneshot ledtrig_heartbeat pinctrl_mcp23s08 tun vfat fat configfs nls_utf8 nls_iso8859_2 nls_iso8859_1 nls_cp852 nls_cp850 nls_cp1250 eeprom_93cx6 gpio_keys usb_storage input_core leds_gpio sd_mod mii 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 LR is at console_unlock+0x480/0x4ec pc : [<803e2690>] lr : [<80158054>] psr: 60000193 sp : 9b643e70 ip : 00000003 fp : 9b643eac r10: 00000001 r9 : 9f56e010 r8 : 0000000c r7 : 00000000 r6 : 9f56e2ec r5 : 00000003 r4 : 9f56e2e0 r3 : a0ee5018 r2 : 00000018 r1 : 1f35f000 r0 : a0ee5000 Flags: nZCv IRQs off FIQs on Mode SVC_32 ISA ARM Segment none Control: 10c5387d Table: 2d7d404a DAC: 00000051 Process sh (pid: 2536, stack limit = 0x9b642210) Stack: (0x9b643e70 to 0x9b644000) 3e60: 00080040 00000008 00000000 00000000 3e80: 9b643eac 9f6bfe80 9f61e200 00000000 9b643efc 0000003d 9f61e200 8090babc 3ea0: 9b643ef4 9b643eb0 8015a4f0 803e2620 00008124 9b643f00 00000000 80746dc4 3ec0: 80746db0 80746d88 00000000 9f61e200 9f61e200 00000000 00000001 9f408000 3ee0: f4001100 00000000 9b643f14 9b643ef8 8015a5e0 8015a498 00000000 00000000 3f00: 9f61e200 9f61e264 9b643f34 9b643f18 8015a668 8015a5c8 9f61e200 80907fc0 3f20: 00000000 00000001 9b643f4c 9b643f38 8015df40 8015a628 8085bad4 00000000 3f40: 9b643f5c 9b643f50 80159774 8015de6c 9b643f84 9b643f60 80159d3c 80159754 3f60: 80903e28 80912da8 f400010c f4000100 9b643fb0 f4001100 9b643fac 9b643f88 3f80: 80101454 80159ca8 00054574 40000010 ffffffff 10c5387d 10c5387d 00087bb0 3fa0: 00000000 9b643fb0 8010c654 801013fc 0085eba4 0000000a 00000000 00000000 3fc0: 0000000a 0085eba4 76f9b200 00000000 00087c44 00087bb0 00000000 0085f398 3fe0: 0085f384 7ece9608 00054b28 00054574 40000010 ffffffff 00000000 00000000 Backtrace: [<803e2614>] (sdma_int_handler) from [<8015a4f0>] (__handle_irq_event_percpu+0x64/0x130) r10:8090babc r9:9f61e200 r8:0000003d r7:9b643efc r6:00000000 r5:9f61e200 r4:9f6bfe80 [<8015a48c>] (__handle_irq_event_percpu) from [<8015a5e0>] (handle_irq_event_percpu+0x24/0x60) r10:00000000 r9:f4001100 r8:9f408000 r7:00000001 r6:00000000 r5:9f61e200 r4:9f61e200 [<8015a5bc>] (handle_irq_event_percpu) from [<8015a668>] (handle_irq_event+0x4c/0x70) r5:9f61e264 r4:9f61e200 [<8015a61c>] (handle_irq_event) from [<8015df40>] (handle_fasteoi_irq+0xe0/0x17c) r7:00000001 r6:00000000 r5:80907fc0 r4:9f61e200 [<8015de60>] (handle_fasteoi_irq) from [<80159774>] (generic_handle_irq+0x2c/0x3c) r5:00000000 r4:8085bad4 [<80159748>] (generic_handle_irq) from [<80159d3c>] (__handle_domain_irq+0xa0/0xb4) [<80159c9c>] (__handle_domain_irq) from [<80101454>] (gic_handle_irq+0x64/0x98) r9:f4001100 r8:9b643fb0 r7:f4000100 r6:f400010c r5:80912da8 r4:80903e28 [<801013f0>] (gic_handle_irq) from [<8010c654>] (__irq_usr+0x54/0x80) Exception stack(0x9b643fb0 to 0x9b643ff8) 3fa0: 0085eba4 0000000a 00000000 00000000 3fc0: 0000000a 0085eba4 76f9b200 00000000 00087c44 00087bb0 00000000 0085f398 3fe0: 0085f384 7ece9608 00054b28 00054574 40000010 ffffffff r9:00087bb0 r8:10c5387d r7:10c5387d r6:ffffffff r5:40000010 r4:00054574 Code: e3a0c003 e5940038 e0020298 e0803002 (e5d31002) ---[ end trace 3895211c674c9887 ]--- Kernel panic - not syncing: Fatal exception in interrupt CPU1: stopping CPU: 1 PID: 0 Comm: swapper/1 Tainted: G D 4.14.95 #0 Hardware name: Freescale i.MX6 Quad/DualLite (Device Tree) Backtrace: [<8010b3e8>] (dump_backtrace) from [<8010b6c0>] (show_stack+0x18/0x1c) r7:00000001 r6:60000193 r5:00000000 r4:80930c5c [<8010b6a8>] (show_stack) from [<8064e290>] (dump_stack+0x90/0xa4) [<8064e200>] (dump_stack) from [<8010e528>] (handle_IPI+0xec/0x194) r7:00000001 r6:00000000 r5:9f475f38 r4:80931738 [<8010e43c>] (handle_IPI) from [<80101484>] (gic_handle_irq+0x94/0x98) r7:f4000100 r6:f400010c r5:80912da8 r4:80903e28 [<801013f0>] (gic_handle_irq) from [<8010c28c>] (__irq_svc+0x6c/0x90) Exception stack(0x9f475f38 to 0x9f475f80) 5f20: 00000000 00eadc48 5f40: 1f36e000 80114780 ffffe000 80903c30 80903be4 8090b6ba 807461e4 412fc09a 5f60: 00000000 9f475f94 9f475f98 9f475f88 80108668 8010866c 60000013 ffffffff r9:9f474000 r8:807461e4 r7:9f475f6c r6:ffffffff r5:60000013 r4:8010866c [<80108630>] (arch_cpu_idle) from [<80667750>] (default_idle_call+0x30/0x34) [<80667720>] (default_idle_call) from [<8014f5e4>] (do_idle+0xc0/0x124) [<8014f524>] (do_idle) from [<8014f8b0>] (cpu_startup_entry+0x20/0x24) r9:412fc09a r8:1000406a r7:80931748 r6:10c0387d r5:00000001 r4:00000084 [<8014f890>] (cpu_startup_entry) from [<8010e1b8>] (secondary_start_kernel+0x154/0x160) [<8010e064>] (secondary_start_kernel) from [<1010178c>] (0x1010178c) r5:00000051 r4:2f46806a Rebooting in 3 seconds.. It has happened during the system shutdown phase (after OpenWrt system upgrade), and I've tried to trigger it for few more times with the same steps, but I wasn't able to reproduce it anymore. Please keep me in the Cc loop as I'm not subscribed to the mailing lists. Thanks. -- ynezz _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel ^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: imx-uart DMA transaction error leading to OOPS on 4.14.95 2019-02-06 8:13 imx-uart DMA transaction error leading to OOPS on 4.14.95 Petr Štetiar @ 2019-02-11 12:06 ` Vinod Koul 2019-02-11 9:28 ` Petr Štetiar 0 siblings, 1 reply; 5+ messages in thread From: Vinod Koul @ 2019-02-11 12:06 UTC (permalink / raw) To: Petr Štetiar, Fabio Estevam, Lucas Stach, Robin Gong Cc: dmaengine, linux-arm-kernel On 06-02-19, 09:13, Petr Štetiar wrote: > Hi, Added few ppl who might care about this > > 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... > 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 > Modules linked in: ath9k ath9k_htc ath9k_common qcserial ath9k_hw ath usb_wwan ti_usb_3410_5052 qmi_wwan pl2303 mac80211 keyspan iptable_nat iptable_mangle iptable_filter ipt_REJECT ipt_MASQUERADE ip_tables ftdi_sio cypress_m8 cp210x ch341 cfg80211 xt_time xt_tcpudp xt_state xt_nat xt_multiport xt_mark xt_mac xt_limit xt_conntrack xt_comment xt_TCPMSS xt_REDIRECT xt_LOG xt_FLOWOFFLOAD x_tables usbserial usbnet usblp spidev nf_reject_ipv4 nf_nat_redirect nf_nat_masquerade_ipv4 nf_conntrack_ipv4 nf_nat_ipv4 nf_nat_ftp nf_nat nf_log_ipv4 nf_log_common nf_flow_table_hw nf_flow_table nf_defrag_ipv4 nf_conntrack_rtcache nf_conntrack_ftp nf_conntrack lm75 lib80211_crypt_wep lib80211_crypt_tkip lib80211_crypt_ccmp lib80211 ezusb crc_itu_t crc_ccitt compat cdc_wdm cdc_acm evdev usb_f_acm u_serial > libcomposite ledtrig_oneshot ledtrig_heartbeat pinctrl_mcp23s08 tun vfat fat configfs nls_utf8 nls_iso8859_2 nls_iso8859_1 nls_cp852 nls_cp850 nls_cp1250 eeprom_93cx6 gpio_keys usb_storage input_core leds_gpio sd_mod mii > 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.. > LR is at console_unlock+0x480/0x4ec > pc : [<803e2690>] lr : [<80158054>] psr: 60000193 > sp : 9b643e70 ip : 00000003 fp : 9b643eac > r10: 00000001 r9 : 9f56e010 r8 : 0000000c > r7 : 00000000 r6 : 9f56e2ec r5 : 00000003 r4 : 9f56e2e0 > r3 : a0ee5018 r2 : 00000018 r1 : 1f35f000 r0 : a0ee5000 > Flags: nZCv IRQs off FIQs on Mode SVC_32 ISA ARM Segment none > Control: 10c5387d Table: 2d7d404a DAC: 00000051 > Process sh (pid: 2536, stack limit = 0x9b642210) > Stack: (0x9b643e70 to 0x9b644000) > 3e60: 00080040 00000008 00000000 00000000 > 3e80: 9b643eac 9f6bfe80 9f61e200 00000000 9b643efc 0000003d 9f61e200 8090babc > 3ea0: 9b643ef4 9b643eb0 8015a4f0 803e2620 00008124 9b643f00 00000000 80746dc4 > 3ec0: 80746db0 80746d88 00000000 9f61e200 9f61e200 00000000 00000001 9f408000 > 3ee0: f4001100 00000000 9b643f14 9b643ef8 8015a5e0 8015a498 00000000 00000000 > 3f00: 9f61e200 9f61e264 9b643f34 9b643f18 8015a668 8015a5c8 9f61e200 80907fc0 > 3f20: 00000000 00000001 9b643f4c 9b643f38 8015df40 8015a628 8085bad4 00000000 > 3f40: 9b643f5c 9b643f50 80159774 8015de6c 9b643f84 9b643f60 80159d3c 80159754 > 3f60: 80903e28 80912da8 f400010c f4000100 9b643fb0 f4001100 9b643fac 9b643f88 > 3f80: 80101454 80159ca8 00054574 40000010 ffffffff 10c5387d 10c5387d 00087bb0 > 3fa0: 00000000 9b643fb0 8010c654 801013fc 0085eba4 0000000a 00000000 00000000 > 3fc0: 0000000a 0085eba4 76f9b200 00000000 00087c44 00087bb0 00000000 0085f398 > 3fe0: 0085f384 7ece9608 00054b28 00054574 40000010 ffffffff 00000000 00000000 > Backtrace: > [<803e2614>] (sdma_int_handler) from [<8015a4f0>] (__handle_irq_event_percpu+0x64/0x130) > r10:8090babc r9:9f61e200 r8:0000003d r7:9b643efc r6:00000000 r5:9f61e200 > r4:9f6bfe80 > [<8015a48c>] (__handle_irq_event_percpu) from [<8015a5e0>] (handle_irq_event_percpu+0x24/0x60) > r10:00000000 r9:f4001100 r8:9f408000 r7:00000001 r6:00000000 r5:9f61e200 > r4:9f61e200 > [<8015a5bc>] (handle_irq_event_percpu) from [<8015a668>] (handle_irq_event+0x4c/0x70) > r5:9f61e264 r4:9f61e200 > [<8015a61c>] (handle_irq_event) from [<8015df40>] (handle_fasteoi_irq+0xe0/0x17c) > r7:00000001 r6:00000000 r5:80907fc0 r4:9f61e200 > [<8015de60>] (handle_fasteoi_irq) from [<80159774>] (generic_handle_irq+0x2c/0x3c) > r5:00000000 r4:8085bad4 > [<80159748>] (generic_handle_irq) from [<80159d3c>] (__handle_domain_irq+0xa0/0xb4) > [<80159c9c>] (__handle_domain_irq) from [<80101454>] (gic_handle_irq+0x64/0x98) > r9:f4001100 r8:9b643fb0 r7:f4000100 r6:f400010c r5:80912da8 r4:80903e28 > [<801013f0>] (gic_handle_irq) from [<8010c654>] (__irq_usr+0x54/0x80) > Exception stack(0x9b643fb0 to 0x9b643ff8) > 3fa0: 0085eba4 0000000a 00000000 00000000 > 3fc0: 0000000a 0085eba4 76f9b200 00000000 00087c44 00087bb0 00000000 0085f398 > 3fe0: 0085f384 7ece9608 00054b28 00054574 40000010 ffffffff > r9:00087bb0 r8:10c5387d r7:10c5387d r6:ffffffff r5:40000010 r4:00054574 > Code: e3a0c003 e5940038 e0020298 e0803002 (e5d31002) > ---[ end trace 3895211c674c9887 ]--- > Kernel panic - not syncing: Fatal exception in interrupt > CPU1: stopping > CPU: 1 PID: 0 Comm: swapper/1 Tainted: G D 4.14.95 #0 > Hardware name: Freescale i.MX6 Quad/DualLite (Device Tree) > Backtrace: > [<8010b3e8>] (dump_backtrace) from [<8010b6c0>] (show_stack+0x18/0x1c) > r7:00000001 r6:60000193 r5:00000000 r4:80930c5c > [<8010b6a8>] (show_stack) from [<8064e290>] (dump_stack+0x90/0xa4) > [<8064e200>] (dump_stack) from [<8010e528>] (handle_IPI+0xec/0x194) > r7:00000001 r6:00000000 r5:9f475f38 r4:80931738 > [<8010e43c>] (handle_IPI) from [<80101484>] (gic_handle_irq+0x94/0x98) > r7:f4000100 r6:f400010c r5:80912da8 r4:80903e28 > [<801013f0>] (gic_handle_irq) from [<8010c28c>] (__irq_svc+0x6c/0x90) > Exception stack(0x9f475f38 to 0x9f475f80) > 5f20: 00000000 00eadc48 > 5f40: 1f36e000 80114780 ffffe000 80903c30 80903be4 8090b6ba 807461e4 412fc09a > 5f60: 00000000 9f475f94 9f475f98 9f475f88 80108668 8010866c 60000013 ffffffff > r9:9f474000 r8:807461e4 r7:9f475f6c r6:ffffffff r5:60000013 r4:8010866c > [<80108630>] (arch_cpu_idle) from [<80667750>] (default_idle_call+0x30/0x34) > [<80667720>] (default_idle_call) from [<8014f5e4>] (do_idle+0xc0/0x124) > [<8014f524>] (do_idle) from [<8014f8b0>] (cpu_startup_entry+0x20/0x24) > r9:412fc09a r8:1000406a r7:80931748 r6:10c0387d r5:00000001 r4:00000084 > [<8014f890>] (cpu_startup_entry) from [<8010e1b8>] (secondary_start_kernel+0x154/0x160) > [<8010e064>] (secondary_start_kernel) from [<1010178c>] (0x1010178c) > r5:00000051 r4:2f46806a > Rebooting in 3 seconds.. > > It has happened during the system shutdown phase (after OpenWrt system > upgrade), and I've tried to trigger it for few more times with the same steps, > but I wasn't able to reproduce it anymore. > > Please keep me in the Cc loop as I'm not subscribed to the mailing lists. > > Thanks. > > -- ynezz -- ~Vinod _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel ^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: imx-uart DMA transaction error leading to OOPS on 4.14.95 2019-02-11 12:06 ` Vinod Koul @ 2019-02-11 9:28 ` Petr Štetiar 2019-02-12 3:42 ` Robin Gong 0 siblings, 1 reply; 5+ messages in thread From: Petr Štetiar @ 2019-02-11 9:28 UTC (permalink / raw) To: Vinod Koul Cc: dmaengine, Robin Gong, Fabio Estevam, linux-arm-kernel, Lucas Stach 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 ^ permalink raw reply [flat|nested] 5+ messages in thread
* RE: imx-uart DMA transaction error leading to OOPS on 4.14.95 2019-02-11 9:28 ` Petr Štetiar @ 2019-02-12 3:42 ` Robin Gong 2019-02-12 6:39 ` Robin Gong 0 siblings, 1 reply; 5+ messages in thread From: Robin Gong @ 2019-02-12 3:42 UTC (permalink / raw) To: Petr Štetiar, Vinod Koul Cc: dmaengine, Fabio Estevam, linux-arm-kernel, Lucas Stach 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 ^ permalink raw reply [flat|nested] 5+ messages in thread
* RE: imx-uart DMA transaction error leading to OOPS on 4.14.95 2019-02-12 3:42 ` Robin Gong @ 2019-02-12 6:39 ` Robin Gong 0 siblings, 0 replies; 5+ messages in thread From: Robin Gong @ 2019-02-12 6:39 UTC (permalink / raw) To: Petr Štetiar, Vinod Koul Cc: dmaengine, Fabio Estevam, linux-arm-kernel, Lucas Stach Sorry, please ignore my information, sdma didn't use virt-dma on 4.14.... > -----Original Message----- > From: Robin Gong > Sent: 2019年2月12日 11:42 > To: 'Petr Štetiar' <ynezz@true.cz>; Vinod Koul <vkoul@kernel.org> > Cc: Fabio Estevam <festevam@gmail.com>; Lucas Stach > <l.stach@pengutronix.de>; dmaengine@vger.kernel.org; > linux-arm-kernel@lists.infradead.org > Subject: RE: imx-uart DMA transaction error leading to OOPS on 4.14.95 > > 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 ^ permalink raw reply [flat|nested] 5+ messages in thread
end of thread, other threads:[~2019-02-12 6:39 UTC | newest] Thread overview: 5+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2019-02-06 8:13 imx-uart DMA transaction error leading to OOPS on 4.14.95 Petr Štetiar 2019-02-11 12:06 ` Vinod Koul 2019-02-11 9:28 ` Petr Štetiar 2019-02-12 3:42 ` Robin Gong 2019-02-12 6:39 ` Robin Gong
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).