On 05/19/16 13:20, Matthijs van Duin wrote:
> On 19 May 2016 at 11:16, Yegor Yefremov <yegorslists@xxxxxxxxxxxxxx> wrote:
>> I've also encountered such an error. Though I've seen it only twice
>> and couldn't reproduce it.
>
> Yep, that's indeed the same one. My system reproduces it fairly easily
> though provided I ensure sufficient noise levels during boot. Since
> I've reenabled "quiet" I haven't triggered it yet even though I've
> rebooted many times (been tinkering with u-boot).
>
> BTW I just came up with a theory on the link with the entropy pool:
> possibly irq timing is being used as entropy source? In that case the
> entropy pool filling up would be merely a side-effect of the irq being
> stuck rather than a cause. It just happens to produce a message first
> because it requires 100000 interrupts before linux calls it a day and
> kills the irq.
>
> That leaves the question of why uart console output causes an edma
> channel controller error, and the much bigger question of why the
> dma_ccerr_handler disagrees and returns IRQ_NONE.
it returns with IRQ_NONE since nothing is pending according to the status
registers:
static inline bool edma_error_pending(struct edma_cc *ecc)
{
if (edma_read_array(ecc, EDMA_EMR, 0) ||
edma_read_array(ecc, EDMA_EMR, 1) ||
edma_read(ecc, EDMA_QEMR) || edma_read(ecc, EDMA_CCERR))
return true;
return false;
}
This started to happen when the UART DMA was enabled, but again I have not
seen it that frequently or even ever...
--
Péter
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
