Messages in this thread |  | | | Date | Thu, 15 Dec 2011 16:37:46 +0100 | | From | Clemens Ladisch <> | | Subject | Re: [PATCH] usb: fix number of mapped SG DMA entries |
| |
Sebastian Andrzej Siewior wrote: > * Alan Stern | 2011-12-04 11:59:32 [-0500]: >> On Sat, 3 Dec 2011, Clemens Ladisch wrote: >>> Add a new field num_mapped_sgs to struct urb so that we have a place to >>> store the number of mapped entries and can also retain the original >>> value of entries in num_sgs. Previously, usb_hcd_map_urb_for_dma() >>> would overwrite this with the number of mapped entries, which would >>> break dma_unmap_sg() because it requires the original number of entries. >>> >>> This fixes warnings like the following when using USB storage devices: >>> ------------[ cut here ]------------ >>> WARNING: at lib/dma-debug.c:902 check_unmap+0x4e4/0x695() >>> ehci_hcd 0000:00:12.2: DMA-API: device driver frees DMA sg list with different entry count [map count=4] [unmap count=1] >> >> Interesting. Do you have any idea why this warning didn't show up >> earlier? Is there perhaps a Kconfig option I ought to be using? > > My question here is why don't we map the complete sg list but only > one entry. What happens to the remaining few sg list entries? Don't we > sent too less data?
Documentation/DMA-API.txt says: | Returns: the number of physical segments mapped (this may be shorter | than <nents> passed in if some elements of the scatter/gather list are | physically or virtually adjacent and an IOMMU maps them with a single | entry).
> Is there anything special you do to get into this kind of situation?
It appears that enabling CONFIG_DMA_API_DEBUG is quite special. :o)
> Like 16GiB of memory on 32bit with highmem and a brutal disk/io test > case so?
Plain x86-64; very few file operations done by hand.
Regards, Clemens
|  |