fsl_lpuart/VF610: Division by zero.

Stefan Agner stefan at agner.ch
Sat Jul 26 05:08:38 PDT 2014

Hi Bill,

Am 2014-07-26 00:36, schrieb Bill Pringlemeir:
> On 25 Jul 2014, bpringlemeir at nbsps.com wrote:
>> I have this 'dmesg' with ttyLP1,
>> Division by zero in kernel.  CPU: 0 PID: 187 Comm: getty Not tainted
>> 3.15.0-rc8-04600-ge74a685-dirty #465 [<80013b18>] (unwind_backtrace)
>> from [<80011e3c>] (show_stack+0x10/0x14) [<80011e3c>] (show_stack)
>> from [<8019a11c>] (Ldiv0+0x8/0x10) [<8019a11c>] (Ldiv0) from
>> [<801f0ad4>] (lpuart_startup+0x1e4/0x398) [<801f0ad4>]
>> (lpuart_startup) from [<801ef2e8>] (uart_startup.part.18+0x84/0x1e8)
>> [<801ef2e8>] (uart_startup.part.18) from [<801efd40>]
>> (uart_open+0xe4/0x14c) [<801efd40>] (uart_open) from [<801d586c>]
>> (tty_open+0x1a0/0x5d0) [<801d586c>] (tty_open) from [<800a1008>]
>> (chrdev_open+0x9c/0x160) [<800a1008>] (chrdev_open) from [<8009bd0c>]
>> (do_dentry_open.isra.15+0x1b4/0x270) [<8009bd0c>]
>> (do_dentry_open.isra.15) from [<8009be98>] (finish_open+0x20/0x3c)
>> [<8009be98>] (finish_open) from [<800a8bfc>]
>> (do_last.isra.66+0x404/0xc60) [<800a8bfc>] (do_last.isra.66) from
>> [<800a950c>] (path_openat+0xb4/0x5b0) [<800a950c>] (path_openat) from
>> [<800aa900>] (do_filp_open+0x2c/0x80) [<800aa900>] (do_filp_open) from
>> [<8009ce50>] (do_sys_open+0x120/0x1e0) [<8009ce50>] (do_sys_open) from
>> [<8000ed80>] (ret_fast_syscall+0x0/0x30) random: nonblocking pool is
>> initialized
>> I looked at the vmlinux objdump and it is here,
>> static int lpuart_dma_rx_request(struct uart_port *port)
>> {
>> ...
>> 	sport->dma_rx_timeout = (sport->port.timeout - HZ / 50) *
>> 				sport->rxfifo_size / 2;
>> The variable 'sport->rxfifo_size' is set in lpuart_setup_watermark()
>> and this is called after lpuart_dma_rx_request() in lpuart_startup().

I observed this division by zero too, I recently sent a patch for that.

Greg already added that to his tty-next tree:

I also observed that DMA did not work yet, hence I a created a second

But eDMA in general was broken too,  this patch solved that, hence you
might want apply that patch too:

All patches are lined up for 3.17, so things should be smooth from that
release on.

In my last tests the driver worked more or less reliable, as is, however
I think the RX path still has some problems regarding DMA: The function
lpuart_dma_rx_complete never gets called, 
lpuart_timer_func receives the data later on. When setting
FSL_UART_RX_DMA_BUFFER_SIZE to 16 bytes (for UART0),
lpuart_dma_rx_complete was called, but then receive did not work
reliable anymore. I had not yet the time to investigate this further.


More information about the linux-arm-kernel mailing list