public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Larry Finger <Larry.Finger@lwfinger.net>
To: Joerg Roedel <joerg.roedel@amd.com>
Cc: LKML <linux-kernel@vger.kernel.org>,
	iommu@lists.linux-foundation.org,
	USB list <linux-usb@vger.kernel.org>
Subject: Re: nommu warning message
Date: Mon, 14 Nov 2011 18:03:39 -0600	[thread overview]
Message-ID: <4EC1AC5B.6000001@lwfinger.net> (raw)
In-Reply-To: <20111114114213.GC14704@amd.com>

On 11/14/2011 05:42 AM, Joerg Roedel wrote:
> On Fri, Nov 11, 2011 at 12:14:13PM -0600, Larry Finger wrote:
>> For the driver rtl8192cu (a USB wireless device), the current
>> version loads the 15KB firmware asynchronously one 32-bit quantity
>> at a time. Although inefficient. this method works with USB 1.1 and
>> USB 2.0 adapters; however, it fails on at least one USB 3.0 adapter
>> with "xhci_hcd 0000:05:00.0: ERROR no room on ep ring" errors.
>>
>> These errors are believed to arise from small, fixed-size ep rings.
>> There is a vendor driver that works with that same hardware. The
>> major difference is that it uses synchronous block writes of 254
>> bytes. When I tried this with the in-kernel driver, each block write
>> yields a warning as shown below:
>>
>> nommu_map_single: overflow 41000340d020+254 of device mask ffffffff
>
> Strange. This means that your system uses the nommu DMA driver. But for
> your hardware the GART or SWIOTLB should be used.
>
> Even more strange is the address used for the device. I don't believe is
> is correct, otherwise your Laptop would have a very huge amount of RAM
> :)
>
> The I think there are two issues here: Why is your system using nommu
> and not GART? Can you check that GART and SWIOTLB are enabled in your
> kernel config? Second, why is your system using the wrong address? This
> looks like some kind of driver bug to mee.

My system has 3 GB of RAM installed, and it has both GART and SWIOTLB enabled.

Your comment about the strange address made me wonder if my driver was somehow 
overrunning a buffer. Keeping the buffer size constant while reducing the 
maximum block size by 10 bytes cleared the problem. Obviously, I there is some 
buffer overhead that I had not considered.

Thanks for pointing me in the right direction.

Larry

      reply	other threads:[~2011-11-15  0:03 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-11-11 18:14 nommu warning message Larry Finger
2011-11-14 11:42 ` Joerg Roedel
2011-11-15  0:03   ` Larry Finger [this message]

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=4EC1AC5B.6000001@lwfinger.net \
    --to=larry.finger@lwfinger.net \
    --cc=iommu@lists.linux-foundation.org \
    --cc=joerg.roedel@amd.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-usb@vger.kernel.org \
    /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