On 10/02/2013 01:07 PM, Daniel Mack wrote:
> No, as stated, the line numbers in the kernel message are somewhat off
> due to added debugging code. What kicks in here is this one:
>
> if (!c->td_desc_seen) {
> desc_phys = cppi41_pop_desc(cdd, c->q_comp_num);
> if (desc_phys) {
> __iormb();
> WARN_ON(c->desc_phys != desc_phys);
> c->td_desc_seen = 1;
> }
> }
Ach okay. So something completed but it wasn't the expected descriptor.
>> So you get the warning because
>> you tried to stop a channel which was not busy. But then you should not
>> be called at all because cppi41_dma_channel_abort() shouldn't call dma
>> driver on idle channels.
>
> However, I see nothing that forbids you from calling
> dmaengine_terminate_all() on idle channels. If that's not handled
> properly by the cppi driver, I'd say it needs fixing.
No argue about that.
>> How does your suspend & resume thingy work? Is it completly shutdown
>> i.e. powered off? According to you earlier patches I would assume so. In
>> that case the request is not enqueued and there is nothing to be removed
>> from the engine, right?
>
> No, my debugging showed that the channel has actually been prepared and
> submitted before. It's just being torn down shortly after that. That's
> what makes be believe in a race condition here.
I see.
> Thanks,
> Daniel
Sebastian
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
