public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
* nommu warning message
@ 2011-11-11 18:14 Larry Finger
  2011-11-14 11:42 ` Joerg Roedel
  0 siblings, 1 reply; 3+ messages in thread
From: Larry Finger @ 2011-11-11 18:14 UTC (permalink / raw)
  To: LKML; +Cc: USB list, iommu

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

The only remaining difference between the two drivers is that the vendor version 
uses firmware hard coded into the driver while the kernel version uses a file 
from /lib/firmware.

My cpu info is:

----- /proc/cpuinfo -----
   processor     : 0
   vendor_id     : AuthenticAMD
   cpu family    : 15
   model         : 104
   model name    : AMD Turion(tm) 64 X2 TL-60
   stepping      : 2
   cpu MHz               : 2000.000
   cache size    : 512 KB
   physical id   : 0
   siblings      : 2
   core id               : 0
   cpu cores     : 2
   apicid                : 0
   initial apicid        : 0
   fpu           : yes
   fpu_exception : yes
   cpuid level   : 1
   wp            : yes
   flags         : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov 
pat pse36 clflush mmx fxsr sse sse2 ht syscall nx mmxext fxsr_opt rdtscp lm 
3dnowext 3dnow rep_good nopl extd_apicid pni cx16 lahf_lm cmp_legacy svm extapic 
cr8_legacy 3dnowprefetch lbrv
   bogomips      : 4001.06
   TLB size      : 1024 4K pages
   clflush size  : 64
   cache_alignment       : 64
   address sizes : 40 bits physical, 48 bits virtual
   power management: ts fid vid ttp tm stc 100mhzsteps


Could someone please explain the meaning of the above messages? Even with them 
present, the device works.

Thanks,

Larry

^ permalink raw reply	[flat|nested] 3+ messages in thread

* Re: nommu warning message
  2011-11-11 18:14 nommu warning message Larry Finger
@ 2011-11-14 11:42 ` Joerg Roedel
  2011-11-15  0:03   ` Larry Finger
  0 siblings, 1 reply; 3+ messages in thread
From: Joerg Roedel @ 2011-11-14 11:42 UTC (permalink / raw)
  To: Larry Finger; +Cc: LKML, iommu, USB list

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.


	Joerg

-- 
AMD Operating System Research Center

Advanced Micro Devices GmbH Einsteinring 24 85609 Dornach
General Managers: Alberto Bozzo, Andrew Bowd
Registration: Dornach, Landkr. Muenchen; Registerger. Muenchen, HRB Nr. 43632


^ permalink raw reply	[flat|nested] 3+ messages in thread

* Re: nommu warning message
  2011-11-14 11:42 ` Joerg Roedel
@ 2011-11-15  0:03   ` Larry Finger
  0 siblings, 0 replies; 3+ messages in thread
From: Larry Finger @ 2011-11-15  0:03 UTC (permalink / raw)
  To: Joerg Roedel; +Cc: LKML, iommu, USB list

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

^ permalink raw reply	[flat|nested] 3+ messages in thread

end of thread, other threads:[~2011-11-15  0:03 UTC | newest]

Thread overview: 3+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
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 is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox