linux-kernel - Re: [PATCH 0/4] serial: omap: robustify for high speed transfers

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <874md0yd81.fsf@linutronix.de>
Date:	Mon, 22 Feb 2016 16:30:22 +0100
From:	John Ogness <john.ogness@...utronix.de>
To:	Tony Lindgren <tony@...mide.com>
Cc:	Peter Hurley <peter@...leysoftware.com>,
	gregkh@...uxfoundation.org, vinod.koul@...el.com,
	dan.j.williams@...el.com, bigeasy@...utronix.de, nsekhar@...com,
	peter.ujfalusi@...com, dmaengine@...r.kernel.org,
	linux-serial@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH 0/4] serial: omap: robustify for high speed transfers

Hi Tony,

On 2016-02-11, Tony Lindgren <tony@...mide.com> wrote:
>> At these speeds, nearly every DMA interrupt is accompanied by a
>> spurious UART interrupt. So, sadly, the interrupts are doubled.
>> 
>> It is on my TODO list to verify if the spurious UART interrupts
>> exactly match the recently added [0] spurious interrupt detection in
>> omap-intc.
>
> If you're seeing spurious interrupts you may want try adding
> a flush of posted write at the end of the 8250_omap interrupt
> handler. Basically read back some register from the 8250. This
> has fixed so far pretty much all the spurious IRQ issues for
> omaps using the drivers/irqchip/irq-omap-intc.c, meaning omap3
> and am335x and ti81xx variants too most likely.

I have done significant testing with this using linux-next-20160219. The
only changes I made were to disable the "rx_dma_broken" feature so that
DMA would definately be used. I created a simple test where I send 48000
bytes at 230400bps over UART from one device to another. Several
different target devices and configurations were used to test the RX-DMA
feature of the 8250_omap. The expected result is 1000 DMA interrupts and
0 UART interrupts.

With the am335x (Beaglebone Black, eDMA engine) I see 1000 DMA
interrupts and 1000 spurious UART interrupts. The spurious UART
interrupts arrive 30-50us _before_ the DMA interrupts. Always.

If I disable UART timeout interrupts (RDI), the same test generates no
spurious UART interrupts. Only 1000 DMA interrupts.

I ran the same test using a dra7 board (sDMA engine) as the target
device. RDI was enabled. Here I see no spurious interrupts.

I modified the dra7 device tree to use the eDMA engine with the
UART. RDI was enabled. Here I also see no spurious interrupts.

The dra7 uses a different interrupt controller (irq-gic instead of
irq-omap-intc), which probably explains why dra7+edma+rdi works
correctly.

I tried adding various and multiple register reads at the end of the
interrupt handlers, but this made no difference. What is interesting is
the fact that the spurious UART interrupt always _preceeds_ the DMA
interrupt and by a significant yet relatively consistent amount
(30-50us). Even the very first DMA interrupt is preceeded by the
spurious interrupt. It is as if the UART timeout logic is triggering
because it does not notice that the eDMA is pulling the data from the
FIFO. But only when the irq-omap-intc in involved.

Tony, if you have any futher ideas, I'd be happy to try them out.

Summary: If DMA is ever going to be re-enabled for am335x/8250_omap,
then it will be necessary to return IRQ_HANDLED for the spurious UART
interrupts that will preceed each DMA-RX completion interrupt.

John Ogness