[Top] [All Lists]

Re: kmalloc/pci_alloc and skbuff's

To: James Simmons <>
Subject: Re: kmalloc/pci_alloc and skbuff's
From: Geoffrey Espin <>
Date: Wed, 19 Dec 2001 10:56:33 -0800
Cc: "Gleb O. Raiko" <>,
In-reply-to: <>; from James Simmons on Wed, Dec 19, 2001 at 09:09:11AM -0800
References: <> <>
> > What's wrong with GFP_DMA ? Doesn't it solve exactly this problem ?
> Personally I don't like the hack but you have to ask what he needs.
> kmalloc grabs memory from the CPU cache. GFP_DMA insures that cache memory
> is continues. I think Geoffrey needs to use a specific memory address in 
> PCI space. Tho I like Geoffrey to try using GFP_DMA. The reason I don't
> like the hack is that skbuff's is bus independent. Not all ethernet cards
> are PCI based. Please try using GFP_DMA and let us know if it worked. 

Yes, I originally thought this was what addressed it.
Is "setting dma_mask" what is meant by "using GFP_DMA"?

The problem is drivers call dev_alloc_skb() which can allocate
memory anywhere in (my 32M) memory.

The PCI host controller part of the uPD98052 with its VR4120a core
(doc at
allows you to program a 4M window onto DRAM.  I use top 4M of 32M,
but it's arbitrary.  Then only this area can be transferred to
by/from the PCI devices.  So its not the PCI devices that is the
problem, but access to the host-side DRAM.

Currently, my private pci_alloc/free_consistent() routines manage
the 4M at top of memory (its not added to kernel with
add_memory_region() in prom.c).

With these hacks (including net/core/skbuff.c:alloc_skb->pci_alloc_consistent)
I've been successfully using the Tulip Ethernet (LinkSys) card (with no
changes to the driver).

Geoffrey Espin

<Prev in Thread] Current Thread [Next in Thread>