On 29/07/20 08:04, John Snow wrote: > Somehow we manage to map 1 byte, and then 0x1000 more bytes (!?), > but then we can go no further.
This is 1 byte of memory, and then we reach an MMIO area; further maps are limited to 0x1000 bytes which is the size of the address_space_map bounce buffer. The idea is that the bounce buffer is released by address_space_unmap and DMA proceeds with the next 0x1000 bytes. > What is the "reschedule" functionality here supposed to be doing? I > assume we are waiting to see if a mapping succeeds later, but this > mapping seems like it should never work -- how can we determine the > difference between a remap that *might* work later and one that will > never work? This is the question: what is special about this address_space_map, that makes it never succeed? The usual case where address_space_map fails is simply two or more concurrent users of the bounce buffer, and these solve by themselves when address_space_unmap calls cpu_notify_map_clients. Do we never call address_space_unmap? > How many times should we try to map a certain range? address_space_map > warns that scheduling with cpu_register_map_client is only *likely* to > allow you to succeed. It should still *eventually* succeed (subject to fairness in execution of the MapClient bottom halves). So again the question is why this doesn't. Paolo
