On 11/21/2016 10:32 AM, Joerg Roedel wrote: > On Fri, Nov 18, 2016 at 09:04:05AM -0500, Mark Hounschell wrote: >> OK. It's attached. > >> [ 45.033715] WARNING: CPU: 0 PID: 0 at lib/dma-debug.c:1158 >> check_unmap+0x4ef/0x990 >> [ 45.037651] 3c59x 0000:04:04.0: DMA-API: device driver failed to check >> map error[device address=0x00000000ffedf840] [size=1536 bytes] [mapped as >> single] > > Okay, there is a dma-debug warning from the 3c59x driver. Can you please > blacklist this driver (or compile it out) and re-try? The dma-debug code > will only show the first warning and stop then. So any possible warnings > from your out-of-tree driver will not be shown as long as the 3c59x > driver is loaded. > > Alternativly you can write 1 to dma-api/all_errors in debug-fs so that > it will show all errors. But I suggest to unload the 3com driver first > and then load your driver. >
OK, I did get this message before the reported BUG message. gpiohsd gpiohsd: DMA-API: device driver tries to free DMA memory it has not allocated [device address=0xffffffffffee8000] [size=8192 bytes] But I've verified that the dma_addr_t that I get for the alloc, and also use for the free is 0x00000000ffee8000 in this case? Is device "address=0xffffffffffee8000" in that message a bug in the message or do we have a sign extended address problem? It seems strange to me, I've never seen a dma_addr_t given, when using the iommu, that high. In the past I've seen them as usually 0x00xxxxxx? I have also verified that simply changing from pci_alloc/free_consistent to the newer DMA API fixes my issue and I get no such messages. Mark
