[uClinux-dev] SCSI problem for USB mass storage devices

David McCullough davidm at snapgear.com
Tue Oct 18 19:27:49 EDT 2005


Jivin Erwin Authried lays it down ...
> On Wed, 2005-10-19 at 00:32, David McCullough wrote:
> > Jivin Erwin Authried lays it down ...
> > > Am Die, den 18.10.2005 schrieb Abhijith K S um 12:08:
> > > > Hi,
> > > > 
> > > > While trying to interface a USB host controller driver with our custom target (MCF5270) running on  uClinux 2.4.27-uc1, on enabling SCSI support for the USB mass storage driver, it used to give the foll.  error:
> > > > 
> > > > ----------------------------------------------------------------
> > > > SCSI subsystem driver Revision: 1.00
> > > > __alloc_pages: 0-order allocation failed (gfp=0x21/0)
> > > > scsi::init_module: failed, out of memory
> > > > ----------------------------------------------------------------
> > > > 
> > > > We traced this error to __get_free_pages(...) with GFP_DMA option or kmalloc(...) with GFP_DMA option.  We found that if we don't specify GFP_DMA option in the function calls, the error is not generated and  the module seems to be initialized properly (changes made in scsi_dma.c).
> > > > 
> > > > Is the GFP_DMA option supported in 527X architecture? And if yes, is there anything that has to be done to properly enable this option?
> > > > 
> > > > Any help is appreciated.
> > > > 
> > > > Regards,
> > > > Abhijith
> > > Hi,
> > > 
> > > there's no dma zone in uClinux. I think that can be solved quite easy by
> > > forcing the DMA flag to 0 in include/linux/mm.h. There may still be
> > > other problems with cache coherency if you are using DMA.
> > 
> > I am pretty sure that uClinux is able to handle DMA zones,  obviously
> > the platform is not setting any up.  The only case that doesn't handle
> > DMA zones IIRC is kmalloc2/page_alloc2/whatever you want to call it :-)
>
> ok, I didn't check all platforms, but at least armnommu doesn't seem to
> support a dma zone. If you are right, then my patch that is in the
> latest CVS for 2.4 is wrong. 

I haven't looked at the patch,  but all the slab/kmalloc code handle
DMA, so it's purely and arch setup thing as far as I am aware.

> > If a platform supports DMA, then it should setup the DMA zone
> > appropriately.
>
> I'd rather say, if all available memory is DMA-able, then there's no
> reason to have a seperate DMA zone.

I sort of agree here.

1) Make a big DMA zone and no normal zone,  possibly risk slowing down
   normal allocations as they will switch to DMA if there is nothing else
   to use.

2) Not have a DMA zone

I think for "in kernel" use you actually want DMA to be the fastest
allocation,  since net drivers and most HW will normally want DMA
memory.  The only problem with 1 then would be most people would feel a
little uncomfortable with only having DMA memory available :-)
Also most !MMU systems don't use DMA.

So your solution below is ok,  but maybe a little too generic.  Some
uClinux systems (who know what other processors do) may actually have a
limited memory they can DMA from.  Or you may want to limit it to some
faster memory ?

Either way I am not to concerned about it,

Cheers,
Davidm


> > > #ifdef CONFIG_UCLINUX
> > > #define  __GFP_DMA 0
> > > #else
> > > #define __GFP_DMA       0x01
> > > #endif
> > > 
> > > Regards,
> > > Erwin

-- 
David McCullough, davidm at cyberguard.com.au, Custom Embedded Solutions + Security
Ph:+61 734352815 Fx:+61 738913630 http://www.uCdot.org http://www.cyberguard.com



More information about the uClinux-dev mailing list