TITAN GE driver

TITAN GE driver

[Anoop P.A.]

Hi list,

 

Any body used titan GE device with more than 512MB physical memory?   

 

If buffer is getting allocated above physical address 0x1fff_ffff ( ie.
30 bit buffer address) we may have to consider setting XDMA_BUFFADDRPRE
(0x5018 ) .This is not taken care in original driver.  Any body had luck
in enabling this prefix. I have tried enabling it and I could do flood
ping with out packet loss. However when I do mass data transfer kernel
getting panic. Further investigation showed kenel panics because DMA
copies data to wrong address (which is being used).

 

Any body had luck with this kindly share there experience?

 

Thanks

Anoop

Re: TITAN GE driver

[Ralf Baechle]

On Thu, May 27, 2010 at 10:51:47PM -0700, Anoop P.A. wrote:

> Any body used titan GE device with more than 512MB physical memory?   
> 
>  
> 
> If buffer is getting allocated above physical address 0x1fff_ffff ( ie.
> 30 bit buffer address) we may have to consider setting XDMA_BUFFADDRPRE
> (0x5018 ) .This is not taken care in original driver.  Any body had luck
> in enabling this prefix. I have tried enabling it and I could do flood
> ping with out packet loss. However when I do mass data transfer kernel
> getting panic. Further investigation showed kenel panics because DMA
> copies data to wrong address (which is being used).

The driver has not been used in ages so it's generally in a sad shape,
doesn't even compile.  I think nobody touched this driver seriously in
5 years, probably longer.  So it's sort of expected to eat your cat or
do other nasty stuff.

  Ralf

RE: TITAN GE driver

[Anoop P.A.]

Hi,

>From the datasheets and design discussion it looks like prefix has been
designed to be static i.e they are expecting all buffers to get
allocated with same prefix. In another words all the buffers should be
below < 0x1fff_ffff ( physical address) or between 0x2000_0000 and
0x3fff_ffff like that.

Is there any way to force kmalloc to allocate memory in certain region
or below some region?

Thanks
Anoop

> -----Original Message-----
> From: linux-mips-bounce@linux-mips.org
[mailto:linux-mips-bounce@linux-
> mips.org] On Behalf Of Ralf Baechle
> Sent: Friday, May 28, 2010 9:57 PM
> To: Anoop P.A.
> Cc: linux-mips
> Subject: Re: TITAN GE driver
> 
> On Thu, May 27, 2010 at 10:51:47PM -0700, Anoop P.A. wrote:
> 
> > Any body used titan GE device with more than 512MB physical memory?
> >
> >
> >
> > If buffer is getting allocated above physical address 0x1fff_ffff (
ie.
> > 30 bit buffer address) we may have to consider setting
XDMA_BUFFADDRPRE
> > (0x5018 ) .This is not taken care in original driver.  Any body had
luck
> > in enabling this prefix. I have tried enabling it and I could do
flood
> > ping with out packet loss. However when I do mass data transfer
kernel
> > getting panic. Further investigation showed kenel panics because DMA
> > copies data to wrong address (which is being used).
> 
> The driver has not been used in ages so it's generally in a sad shape,
> doesn't even compile.  I think nobody touched this driver seriously in
> 5 years, probably longer.  So it's sort of expected to eat your cat or
> do other nasty stuff.
> 
>   Ralf

RE: TITAN GE driver

[Anoop P.A.]

Hi,

From the datasheets and design discussion it looks like prefix has been
designed to be static i.e they are expecting all buffers to get
allocated with same prefix. In another words all the buffers should be
below < 0x1fff_ffff ( physical address) or between 0x2000_0000 and
0x3fff_ffff like that.

Is there any way to force kmalloc to allocate memory in certain region
or below some region?

Thanks
Anoop

> -----Original Message-----
> From: linux-mips-bounce@linux-mips.org
[mailto:linux-mips-bounce@linux-
> mips.org] On Behalf Of Ralf Baechle
> Sent: Friday, May 28, 2010 9:57 PM
> To: Anoop P.A.
> Cc: linux-mips
> Subject: Re: TITAN GE driver
> 
> On Thu, May 27, 2010 at 10:51:47PM -0700, Anoop P.A. wrote:
> 
> > Any body used titan GE device with more than 512MB physical memory?
> >
> >
> >
> > If buffer is getting allocated above physical address 0x1fff_ffff (
ie.
> > 30 bit buffer address) we may have to consider setting
XDMA_BUFFADDRPRE
> > (0x5018 ) .This is not taken care in original driver.  Any body had
luck
> > in enabling this prefix. I have tried enabling it and I could do
flood
> > ping with out packet loss. However when I do mass data transfer
kernel
> > getting panic. Further investigation showed kenel panics because DMA
> > copies data to wrong address (which is being used).
> 
> The driver has not been used in ages so it's generally in a sad shape,
> doesn't even compile.  I think nobody touched this driver seriously in
> 5 years, probably longer.  So it's sort of expected to eat your cat or
> do other nasty stuff.
> 
>   Ralf

Re: TITAN GE driver

[Ralf Baechle]

On Wed, Jun 02, 2010 at 01:10:17AM -0700, Anoop P.A. wrote:

> >From the datasheets and design discussion it looks like prefix has been
> designed to be static i.e they are expecting all buffers to get
> allocated with same prefix. In another words all the buffers should be
> below < 0x1fff_ffff ( physical address) or between 0x2000_0000 and
> 0x3fff_ffff like that.
> 
> Is there any way to force kmalloc to allocate memory in certain region
> or below some region?

Nothing that would uniformly work for 32-bit and 64-bit kernels and also
Linux only has flags that allocate below certain addresses; nothing that
tells the allocator "give me something between 0x20000000 and 0x3fffffff".

  Ralf

RE: TITAN GE driver

[Anoop P.A.]

Ralf,

Thanks for the reply. 

> > allocated with same prefix. In another words all the buffers should
be
> > below < 0x1fff_ffff ( physical address) or between 0x2000_0000 and
> > 0x3fff_ffff like that.
> >
> > Is there any way to force kmalloc to allocate memory in certain
region
> > or below some region?
> 
> Nothing that would uniformly work for 32-bit and 64-bit kernels and
also
> Linux only has flags that allocate below certain addresses; nothing
that
> tells the allocator "give me something between 0x20000000 and
0x3fffffff".
> 
>   Ralf
[Anoop P.A.] You mean there are some flags available to force kmalloc to
allocate memory below some address? I couldn't find one in kmalloc man
pages.

BTW I am using 64 bit kernel.

Thanks
Anoop

Re: TITAN GE driver

[Guenter Roeck]

On Wed, Jun 02, 2010 at 04:58:06AM -0400, Anoop P.A. wrote:
> Ralf,
> 
> Thanks for the reply. 
> 
> > > allocated with same prefix. In another words all the buffers should
> be
> > > below < 0x1fff_ffff ( physical address) or between 0x2000_0000 and
> > > 0x3fff_ffff like that.
> > >
> > > Is there any way to force kmalloc to allocate memory in certain
> region
> > > or below some region?
> > 
> > Nothing that would uniformly work for 32-bit and 64-bit kernels and
> also
> > Linux only has flags that allocate below certain addresses; nothing
> that
> > tells the allocator "give me something between 0x20000000 and
> 0x3fffffff".
> > 
> >   Ralf
> [Anoop P.A.] You mean there are some flags available to force kmalloc to
> allocate memory below some address? I couldn't find one in kmalloc man
> pages.
> 
Ralf said "nothing". My reading is that such a flag is _not_ available.

Guenter

RE: TITAN GE driver

[Anoop P.A.]

> > > Linux only has flags that allocate below certain addresses;

I am probably confused by this line ( BTW I know there is a flag
GFP_DMA32 which will force kmalloc to allocate below 4GB) I was just
wondering if there is a flag to allocate memory below 512MB . 

> >
> Ralf said "nothing". My reading is that such a flag is _not_
available.
> 
> Guenter

Re: TITAN GE driver

[Ralf Baechle]

On Wed, Jun 02, 2010 at 01:58:06AM -0700, Anoop P.A. wrote:

> [Anoop P.A.] You mean there are some flags available to force kmalloc to
> allocate memory below some address? I couldn't find one in kmalloc man
> pages.
> 
> BTW I am using 64 bit kernel.

There are:

 o GFP_DMA which usually means to allocate memory accessible to ISA DMA
   devices.
 o GFP_DMA32 which means memory in the low physical 4GB, that is memory
   accessible by 32-bit DMA devices.
 o GFP_HIGHMEM means any type of memory, even highmem.

All need to be explicitly supported by platform code which the existing
code doesn't.

Passing none of these flags would mean to allocate any non-highmem.  On
32-bit kernels that would be below 512MB physical but on 64-bit kernels
where there never is highmem it would just mean to allocate any memory.

I just hope the NIC isn't as braindead as you were describing but I got
no time to read up the docs again.

  Ralf