public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Clemens Ladisch <clemens@ladisch.de>
To: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
Cc: Alan Stern <stern@rowland.harvard.edu>,
	Greg Kroah-Hartman <gregkh@suse.de>,
	linux-usb@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH] usb: fix number of mapped SG DMA entries
Date: Thu, 15 Dec 2011 16:37:46 +0100	[thread overview]
Message-ID: <4EEA144A.4070108@ladisch.de> (raw)
In-Reply-To: <20111215123927.GA19650@linutronix.de>

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

  reply	other threads:[~2011-12-15 15:36 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-12-03 22:41 [PATCH] usb: fix number of mapped SG DMA entries Clemens Ladisch
2011-12-04 16:59 ` Alan Stern
2011-12-04 17:04   ` Clemens Ladisch
2011-12-15 12:39   ` Sebastian Andrzej Siewior
2011-12-15 15:37     ` Clemens Ladisch [this message]
2011-12-15 16:01     ` Alan Stern
2011-12-15 16:22       ` Sebastian Andrzej Siewior

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=4EEA144A.4070108@ladisch.de \
    --to=clemens@ladisch.de \
    --cc=bigeasy@linutronix.de \
    --cc=gregkh@suse.de \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-usb@vger.kernel.org \
    --cc=stern@rowland.harvard.edu \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox