linux-kernel - Re: nommu warning message

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <4EC1AC5B.6000001@lwfinger.net>
Date:	Mon, 14 Nov 2011 18:03:39 -0600
From:	Larry Finger <Larry.Finger@...inger.net>
To:	Joerg Roedel <joerg.roedel@....com>
CC:	LKML <linux-kernel@...r.kernel.org>,
	iommu@...ts.linux-foundation.org,
	USB list <linux-usb@...r.kernel.org>
Subject: Re: nommu warning message

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
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/