ucc_geth DPRAM alloc error, 2.6.22-rc3

ucc_geth DPRAM alloc error, 2.6.22-rc3

[Joakim Tjernlund]

Trying to bring up a third ethernet i/f(ifconfig eth2 up) on
a Freescale 832x CPU gives me this:
 ifconfig eth2 up
 ucc_geth_startup: Can not allocate DPRAM memory for p_thread_data_tx.
 eth2: Cannot configure net device, aborting.
 SIOCSIFFLAGS: Cannot allocate memory

This worked in 2.6.20

Re: ucc_geth DPRAM alloc error, 2.6.22-rc3

[Timur Tabi]

Joakim Tjernlund wrote:
> Trying to bring up a third ethernet i/f(ifconfig eth2 up) on
> a Freescale 832x CPU gives me this:
>  ifconfig eth2 up
>  ucc_geth_startup: Can not allocate DPRAM memory for p_thread_data_tx.
>  eth2: Cannot configure net device, aborting.
>  SIOCSIFFLAGS: Cannot allocate memory

It's possible that there isn't enough MURAM for three QE ethernet interfaces.

-- 
Timur Tabi
Linux Kernel Developer @ Freescale

RE: ucc_geth DPRAM alloc error, 2.6.22-rc3

[Joakim Tjernlund]

> 
> Joakim Tjernlund wrote:
> > Trying to bring up a third ethernet i/f(ifconfig eth2 up) on
> > a Freescale 832x CPU gives me this:
> >  ifconfig eth2 up
> >  ucc_geth_startup: Can not allocate DPRAM memory for 
> p_thread_data_tx.
> >  eth2: Cannot configure net device, aborting.
> >  SIOCSIFFLAGS: Cannot allocate memory
> 
> It's possible that there isn't enough MURAM for three QE 
> ethernet interfaces.

Well, it was in 2.6.20 and now it isn't so something is wasting MURAM.

 Jocke

Re: ucc_geth DPRAM alloc error, 2.6.22-rc3

[Dave Liu]

On Wed, 2007-06-13 at 16:22 +0200, Joakim Tjernlund wrote:
> Trying to bring up a third ethernet i/f(ifconfig eth2 up) on
> a Freescale 832x CPU gives me this:
>  ifconfig eth2 up
>  ucc_geth_startup: Can not allocate DPRAM memory for p_thread_data_tx.
>  eth2: Cannot configure net device, aborting.
>  SIOCSIFFLAGS: Cannot allocate memory
> 
> This worked in 2.6.20

Could you print the MURAM memory usage for debug?
eg. start address and size.

-d

Re: ucc_geth DPRAM alloc error, 2.6.22-rc3

[Joakim Tjernlund]

On Thu, 2007-06-14 at 10:31 +0800, Dave Liu wrote:
> On Wed, 2007-06-13 at 16:22 +0200, Joakim Tjernlund wrote:
> > Trying to bring up a third ethernet i/f(ifconfig eth2 up) on
> > a Freescale 832x CPU gives me this:
> >  ifconfig eth2 up
> >  ucc_geth_startup: Can not allocate DPRAM memory for p_thread_data_tx.
> >  eth2: Cannot configure net device, aborting.
> >  SIOCSIFFLAGS: Cannot allocate memory
> > 
> > This worked in 2.6.20
> 
> Could you print the MURAM memory usage for debug?
> eg. start address and size.
> 
> -d

Like this?
eth1:
MURAM alloc, start:1400, size:512, align:8
MURAM alloc, start:1608, size:520, align:8
MURAM alloc, start:1880, size:128, align:128
MURAM alloc, start:1a00, size:416, align:256
MURAM alloc, start:1bc0, size:64, align:32
MURAM alloc, start:1d00, size:256, align:256
MURAM alloc, start:1f00, size:160, align:256
MURAM alloc, start:1fc0, size:12, align:64
MURAM alloc, start:2000, size:48, align:8
MURAM alloc, start:2080, size:128, align:128
MURAM alloc, start:2180, size:128, align:128
MURAM alloc, start:2280, size:128, align:128
MURAM alloc, start:2380, size:128, align:128
MURAM alloc, start:2440, size:64, align:64
MURAM alloc, start:24c0, size:64, align:64
MURAM alloc, start:2540, size:64, align:64
MURAM alloc, start:25c0, size:64, align:64
MURAM alloc, start:262c, size:93, align:4

eth0:
MURAM alloc, start:2630, size:512, align:8
MURAM alloc, start:2838, size:520, align:8
MURAM alloc, start:2a80, size:128, align:128
MURAM alloc, start:2c00, size:416, align:256
MURAM alloc, start:2de0, size:64, align:32
MURAM alloc, start:2f00, size:256, align:256
MURAM alloc, start:3100, size:160, align:256
MURAM alloc, start:3200, size:12, align:64
MURAM alloc, start:3228, size:48, align:8
MURAM alloc, start:3280, size:128, align:128
MURAM alloc, start:3380, size:128, align:128
MURAM alloc, start:3480, size:128, align:128
MURAM alloc, start:3580, size:128, align:128
MURAM alloc, start:3680, size:64, align:64
MURAM alloc, start:3700, size:64, align:64
MURAM alloc, start:3780, size:64, align:64
MURAM alloc, start:3800, size:64, align:64
MURAM alloc, start:3858, size:93, align:4

eth2:
MURAM alloc, start:3858, size:512, align:8
MURAM alloc, start:3a60, size:520, align:8
MURAM alloc, start:3c80, size:128, align:128
MURAM alloc, start:fffffff4, size:416, align:256

Jocke

Re: ucc_geth DPRAM alloc error, 2.6.22-rc3

[Joakim Tjernlund]

On Thu, 2007-06-14 at 09:03 +0200, Joakim Tjernlund wrote:
> On Thu, 2007-06-14 at 10:31 +0800, Dave Liu wrote:
> > On Wed, 2007-06-13 at 16:22 +0200, Joakim Tjernlund wrote:
> > > Trying to bring up a third ethernet i/f(ifconfig eth2 up) on
> > > a Freescale 832x CPU gives me this:
> > >  ifconfig eth2 up
> > >  ucc_geth_startup: Can not allocate DPRAM memory for p_thread_data_tx.
> > >  eth2: Cannot configure net device, aborting.
> > >  SIOCSIFFLAGS: Cannot allocate memory
> > > 
> > > This worked in 2.6.20
> > 
> > Could you print the MURAM memory usage for debug?
> > eg. start address and size.
> > 
> > -d
> 
> Like this?

redid with all hex, decimal within()
MURAM alloc, start:1400, size:200(512), align:8(8)
MURAM alloc, start:1608, size:208(520), align:8(8)
MURAM alloc, start:1880, size:80(128), align:80(128)
MURAM alloc, start:1a00, size:1a0(416), align:100(256)
MURAM alloc, start:1bc0, size:40(64), align:20(32)
MURAM alloc, start:1d00, size:100(256), align:100(256)
MURAM alloc, start:1f00, size:a0(160), align:100(256)
MURAM alloc, start:1fc0, size:c(12), align:40(64)
MURAM alloc, start:2000, size:30(48), align:8(8)
MURAM alloc, start:2080, size:80(128), align:80(128)
MURAM alloc, start:2180, size:80(128), align:80(128)
MURAM alloc, start:2280, size:80(128), align:80(128)
MURAM alloc, start:2380, size:80(128), align:80(128)
MURAM alloc, start:2440, size:40(64), align:40(64)
MURAM alloc, start:24c0, size:40(64), align:40(64)
MURAM alloc, start:2540, size:40(64), align:40(64)
MURAM alloc, start:25c0, size:40(64), align:40(64)
MURAM alloc, start:262c, size:5d(93), align:4(4)

MURAM alloc, start:2630, size:200(512), align:8(8)
MURAM alloc, start:2838, size:208(520), align:8(8)
MURAM alloc, start:2a80, size:80(128), align:80(128)
MURAM alloc, start:2c00, size:1a0(416), align:100(256)
MURAM alloc, start:2de0, size:40(64), align:20(32)
MURAM alloc, start:2f00, size:100(256), align:100(256)
MURAM alloc, start:3100, size:a0(160), align:100(256)
MURAM alloc, start:3200, size:c(12), align:40(64)
MURAM alloc, start:3228, size:30(48), align:8(8)
MURAM alloc, start:3280, size:80(128), align:80(128)
MURAM alloc, start:3380, size:80(128), align:80(128)
MURAM alloc, start:3480, size:80(128), align:80(128)
MURAM alloc, start:3580, size:80(128), align:80(128)
MURAM alloc, start:3680, size:40(64), align:40(64)
MURAM alloc, start:3700, size:40(64), align:40(64)
MURAM alloc, start:3780, size:40(64), align:40(64)
MURAM alloc, start:3800, size:40(64), align:40(64)
MURAM alloc, start:3858, size:5d(93), align:4(4)

MURAM alloc, start:3858, size:200(512), align:8(8)
MURAM alloc, start:3a60, size:208(520), align:8(8)
MURAM alloc, start:3c80, size:80(128), align:80(128)
MURAM alloc, start:fffffff4, size:1a0(416), align:100(256)

some comments:

With these aligments, won't you waste alot of MURAM?

Looking at the 2 first allocs:
  MURAM alloc, start:1400, size:200(512), align:8(8)
  MURAM alloc, start:1608, size:208(520), align:8(8)
shouldn't the second alloc have 0x1600 as start address?

 Jocke

RE: ucc_geth DPRAM alloc error, 2.6.22-rc3

[Li Yang-r58472]

> -----Original Message-----
> From: linuxppc-dev-bounces+leoli=3Dfreescale.com@ozlabs.org
[mailto:linuxppc-dev-bounces+leoli=3Dfreescale.com@ozlabs.org] On Behalf
Of
> Joakim Tjernlund
> Sent: Thursday, June 14, 2007 3:18 PM
> To: Liu Dave-r63238
> Cc: 'linuxppc-dev Development'
> Subject: Re: ucc_geth DPRAM alloc error, 2.6.22-rc3
>=20
> On Thu, 2007-06-14 at 09:03 +0200, Joakim Tjernlund wrote:
> > On Thu, 2007-06-14 at 10:31 +0800, Dave Liu wrote:
> > > On Wed, 2007-06-13 at 16:22 +0200, Joakim Tjernlund wrote:
> > > > Trying to bring up a third ethernet i/f(ifconfig eth2 up) on
> > > > a Freescale 832x CPU gives me this:
> > > >  ifconfig eth2 up
> > > >  ucc_geth_startup: Can not allocate DPRAM memory for
p_thread_data_tx.
> > > >  eth2: Cannot configure net device, aborting.
> > > >  SIOCSIFFLAGS: Cannot allocate memory
> > > >
> > > > This worked in 2.6.20
> > >
> > > Could you print the MURAM memory usage for debug?
> > > eg. start address and size.
> > >
> > > -d
> >
> > Like this?
>=20
> redid with all hex, decimal within()
> MURAM alloc, start:1400, size:200(512), align:8(8)
> MURAM alloc, start:1608, size:208(520), align:8(8)
> MURAM alloc, start:1880, size:80(128), align:80(128)
> MURAM alloc, start:1a00, size:1a0(416), align:100(256)
> MURAM alloc, start:1bc0, size:40(64), align:20(32)
> MURAM alloc, start:1d00, size:100(256), align:100(256)
> MURAM alloc, start:1f00, size:a0(160), align:100(256)
> MURAM alloc, start:1fc0, size:c(12), align:40(64)
> MURAM alloc, start:2000, size:30(48), align:8(8)
> MURAM alloc, start:2080, size:80(128), align:80(128)
> MURAM alloc, start:2180, size:80(128), align:80(128)
> MURAM alloc, start:2280, size:80(128), align:80(128)
> MURAM alloc, start:2380, size:80(128), align:80(128)
> MURAM alloc, start:2440, size:40(64), align:40(64)
> MURAM alloc, start:24c0, size:40(64), align:40(64)
> MURAM alloc, start:2540, size:40(64), align:40(64)
> MURAM alloc, start:25c0, size:40(64), align:40(64)
> MURAM alloc, start:262c, size:5d(93), align:4(4)

Looks like you are using virtual FIFO for 100Mbps.

> some comments:
>=20
> With these aligments, won't you waste alot of MURAM?
>=20
> Looking at the 2 first allocs:
>   MURAM alloc, start:1400, size:200(512), align:8(8)
>   MURAM alloc, start:1608, size:208(520), align:8(8)
> shouldn't the second alloc have 0x1600 as start address?

This looks like a bug of rheap.  The main problem is that at system
startup phase, there is an allocation of size 0x400,align 0x1000.
The rheap starts to allocate next buffer from 0x1400, instead of 0x400.

- Leo

RE: ucc_geth DPRAM alloc error, 2.6.22-rc3

[Joakim Tjernlund]

On Thu, 2007-06-14 at 15:26 +0800, Li Yang-r58472 wrote:
> > -----Original Message-----
> > From: linuxppc-dev-bounces+leoli=freescale.com@ozlabs.org
> [mailto:linuxppc-dev-bounces+leoli=freescale.com@ozlabs.org] On Behalf
> Of
> > Joakim Tjernlund
> > Sent: Thursday, June 14, 2007 3:18 PM
> > To: Liu Dave-r63238
> > Cc: 'linuxppc-dev Development'
> > Subject: Re: ucc_geth DPRAM alloc error, 2.6.22-rc3
> > 
> > On Thu, 2007-06-14 at 09:03 +0200, Joakim Tjernlund wrote:
> > > On Thu, 2007-06-14 at 10:31 +0800, Dave Liu wrote:
> > > > On Wed, 2007-06-13 at 16:22 +0200, Joakim Tjernlund wrote:
> > > > > Trying to bring up a third ethernet i/f(ifconfig eth2 up) on
> > > > > a Freescale 832x CPU gives me this:
> > > > >  ifconfig eth2 up
> > > > >  ucc_geth_startup: Can not allocate DPRAM memory for
> p_thread_data_tx.
> > > > >  eth2: Cannot configure net device, aborting.
> > > > >  SIOCSIFFLAGS: Cannot allocate memory
> > > > >
> > > > > This worked in 2.6.20
> > > >
> > > > Could you print the MURAM memory usage for debug?
> > > > eg. start address and size.
> > > >
> > > > -d
> > >
> > > Like this?
> > 
> > redid with all hex, decimal within()
> > MURAM alloc, start:1400, size:200(512), align:8(8)
> > MURAM alloc, start:1608, size:208(520), align:8(8)
> > MURAM alloc, start:1880, size:80(128), align:80(128)
> > MURAM alloc, start:1a00, size:1a0(416), align:100(256)
> > MURAM alloc, start:1bc0, size:40(64), align:20(32)
> > MURAM alloc, start:1d00, size:100(256), align:100(256)
> > MURAM alloc, start:1f00, size:a0(160), align:100(256)
> > MURAM alloc, start:1fc0, size:c(12), align:40(64)
> > MURAM alloc, start:2000, size:30(48), align:8(8)
> > MURAM alloc, start:2080, size:80(128), align:80(128)
> > MURAM alloc, start:2180, size:80(128), align:80(128)
> > MURAM alloc, start:2280, size:80(128), align:80(128)
> > MURAM alloc, start:2380, size:80(128), align:80(128)
> > MURAM alloc, start:2440, size:40(64), align:40(64)
> > MURAM alloc, start:24c0, size:40(64), align:40(64)
> > MURAM alloc, start:2540, size:40(64), align:40(64)
> > MURAM alloc, start:25c0, size:40(64), align:40(64)
> > MURAM alloc, start:262c, size:5d(93), align:4(4)
> 
> Looks like you are using virtual FIFO for 100Mbps.
> 
> > some comments:
> > 
> > With these aligments, won't you waste alot of MURAM?
> > 
> > Looking at the 2 first allocs:
> >   MURAM alloc, start:1400, size:200(512), align:8(8)
> >   MURAM alloc, start:1608, size:208(520), align:8(8)
> > shouldn't the second alloc have 0x1600 as start address?
> 
> This looks like a bug of rheap.  The main problem is that at system
> startup phase, there is an allocation of size 0x400,align 0x1000.
> The rheap starts to allocate next buffer from 0x1400, instead of 0x400.

Strangely, that alloc(0x400,align 0x1000) never shows up
in the print out.

For reference I have added the same printout to
my 2.6.20 kernel, here is the initial allocs in that kernel:

MURAM alloc, start:728, size:200(512), align:8(8)
MURAM alloc, start:930, size:208(520), align:8(8)
MURAM alloc, start:b80, size:80(128), align:80(128)
MURAM alloc, start:d00, size:1a0(416), align:100(256)
MURAM alloc, start:ee0, size:40(64), align:20(32)
MURAM alloc, start:1000, size:100(256), align:100(256)
MURAM alloc, start:1200, size:a0(160), align:100(256)
MURAM alloc, start:12d8, size:8(8), align:4(4)
MURAM alloc, start:12e0, size:30(48), align:8(8)
MURAM alloc, start:1380, size:80(128), align:80(128)
MURAM alloc, start:1480, size:80(128), align:80(128)
MURAM alloc, start:1580, size:80(128), align:80(128)
MURAM alloc, start:1680, size:80(128), align:80(128)
MURAM alloc, start:1740, size:40(64), align:40(64)
MURAM alloc, start:17c0, size:40(64), align:40(64)
MURAM alloc, start:1840, size:40(64), align:40(64)
MURAM alloc, start:18c0, size:40(64), align:40(64)
MURAM alloc, start:1910, size:5d(93), align:4(4)

RE: ucc_geth DPRAM alloc error, 2.6.22-rc3

[Li Yang-r58472]

Try remove the following lines in rheap.c

         /* given alignment larger that default rheap alignment */
         if (alignment > info->alignment)
                 size +=3D alignment - 1;

I don't know if this breaks other things, just have a try.

- Leo

> -----Original Message-----
> From: linuxppc-dev-bounces+leoli=3Dfreescale.com@ozlabs.org
[mailto:linuxppc-dev-bounces+leoli=3Dfreescale.com@ozlabs.org] On Behalf
Of
> Joakim Tjernlund
> Sent: Thursday, June 14, 2007 3:18 PM
> To: Liu Dave-r63238
> Cc: 'linuxppc-dev Development'
> Subject: Re: ucc_geth DPRAM alloc error, 2.6.22-rc3
>=20
> On Thu, 2007-06-14 at 09:03 +0200, Joakim Tjernlund wrote:
> > On Thu, 2007-06-14 at 10:31 +0800, Dave Liu wrote:
> > > On Wed, 2007-06-13 at 16:22 +0200, Joakim Tjernlund wrote:
> > > > Trying to bring up a third ethernet i/f(ifconfig eth2 up) on
> > > > a Freescale 832x CPU gives me this:
> > > >  ifconfig eth2 up
> > > >  ucc_geth_startup: Can not allocate DPRAM memory for
p_thread_data_tx.
> > > >  eth2: Cannot configure net device, aborting.
> > > >  SIOCSIFFLAGS: Cannot allocate memory
> > > >
> > > > This worked in 2.6.20
> > >
> > > Could you print the MURAM memory usage for debug?
> > > eg. start address and size.
> > >
> > > -d
> >
> > Like this?
>=20
> redid with all hex, decimal within()
> MURAM alloc, start:1400, size:200(512), align:8(8)
> MURAM alloc, start:1608, size:208(520), align:8(8)
> MURAM alloc, start:1880, size:80(128), align:80(128)
> MURAM alloc, start:1a00, size:1a0(416), align:100(256)
> MURAM alloc, start:1bc0, size:40(64), align:20(32)
> MURAM alloc, start:1d00, size:100(256), align:100(256)
> MURAM alloc, start:1f00, size:a0(160), align:100(256)
> MURAM alloc, start:1fc0, size:c(12), align:40(64)
> MURAM alloc, start:2000, size:30(48), align:8(8)
> MURAM alloc, start:2080, size:80(128), align:80(128)
> MURAM alloc, start:2180, size:80(128), align:80(128)
> MURAM alloc, start:2280, size:80(128), align:80(128)
> MURAM alloc, start:2380, size:80(128), align:80(128)
> MURAM alloc, start:2440, size:40(64), align:40(64)
> MURAM alloc, start:24c0, size:40(64), align:40(64)
> MURAM alloc, start:2540, size:40(64), align:40(64)
> MURAM alloc, start:25c0, size:40(64), align:40(64)
> MURAM alloc, start:262c, size:5d(93), align:4(4)
>=20
> MURAM alloc, start:2630, size:200(512), align:8(8)
> MURAM alloc, start:2838, size:208(520), align:8(8)
> MURAM alloc, start:2a80, size:80(128), align:80(128)
> MURAM alloc, start:2c00, size:1a0(416), align:100(256)
> MURAM alloc, start:2de0, size:40(64), align:20(32)
> MURAM alloc, start:2f00, size:100(256), align:100(256)
> MURAM alloc, start:3100, size:a0(160), align:100(256)
> MURAM alloc, start:3200, size:c(12), align:40(64)
> MURAM alloc, start:3228, size:30(48), align:8(8)
> MURAM alloc, start:3280, size:80(128), align:80(128)
> MURAM alloc, start:3380, size:80(128), align:80(128)
> MURAM alloc, start:3480, size:80(128), align:80(128)
> MURAM alloc, start:3580, size:80(128), align:80(128)
> MURAM alloc, start:3680, size:40(64), align:40(64)
> MURAM alloc, start:3700, size:40(64), align:40(64)
> MURAM alloc, start:3780, size:40(64), align:40(64)
> MURAM alloc, start:3800, size:40(64), align:40(64)
> MURAM alloc, start:3858, size:5d(93), align:4(4)
>=20
> MURAM alloc, start:3858, size:200(512), align:8(8)
> MURAM alloc, start:3a60, size:208(520), align:8(8)
> MURAM alloc, start:3c80, size:80(128), align:80(128)
> MURAM alloc, start:fffffff4, size:1a0(416), align:100(256)
>=20
> some comments:
>=20
> With these aligments, won't you waste alot of MURAM?
>=20
> Looking at the 2 first allocs:
>   MURAM alloc, start:1400, size:200(512), align:8(8)
>   MURAM alloc, start:1608, size:208(520), align:8(8)
> shouldn't the second alloc have 0x1600 as start address?
>=20
>  Jocke
> _______________________________________________
> Linuxppc-dev mailing list
> Linuxppc-dev@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-dev

RE: ucc_geth DPRAM alloc error, 2.6.22-rc3

[Joakim Tjernlund]

On Thu, 2007-06-14 at 15:37 +0800, Li Yang-r58472 wrote:
> Try remove the following lines in rheap.c
> 
>          /* given alignment larger that default rheap alignment */
>          if (alignment > info->alignment)
>                  size += alignment - 1;
> 
> I don't know if this breaks other things, just have a try.
I did and got this alloc:
MURAM alloc, start:400, size:200(512), align:8(8)
MURAM alloc, start:600, size:208(520), align:8(8)
MURAM alloc, start:880, size:80(128), align:80(128)
MURAM alloc, start:900, size:1a0(416), align:100(256)
MURAM alloc, start:a40, size:40(64), align:20(32)
MURAM alloc, start:b00, size:100(256), align:100(256)
MURAM alloc, start:c00, size:a0(160), align:100(256)
MURAM alloc, start:c40, size:c(12), align:40(64)
MURAM alloc, start:c18, size:30(48), align:8(8)
MURAM alloc, start:c80, size:80(128), align:80(128)
MURAM alloc, start:d00, size:80(128), align:80(128)
MURAM alloc, start:d80, size:80(128), align:80(128)
MURAM alloc, start:e00, size:80(128), align:80(128)
MURAM alloc, start:e80, size:40(64), align:40(64)
MURAM alloc, start:ec0, size:40(64), align:40(64)
MURAM alloc, start:f00, size:40(64), align:40(64)
MURAM alloc, start:f40, size:40(64), align:40(64)
MURAM alloc, start:f44, size:5d(93), align:4(4)

MURAM alloc, start:f48, size:200(512), align:8(8)
MURAM alloc, start:1148, size:208(520), align:8(8)
MURAM alloc, start:1380, size:80(128), align:80(128)
MURAM alloc, start:1400, size:1a0(416), align:100(256)
MURAM alloc, start:1580, size:40(64), align:20(32)
MURAM alloc, start:1600, size:100(256), align:100(256)
MURAM alloc, start:1700, size:a0(160), align:100(256)
MURAM alloc, start:1780, size:c(12), align:40(64)
MURAM alloc, start:1758, size:30(48), align:8(8)
MURAM alloc, start:1800, size:80(128), align:80(128)
MURAM alloc, start:1880, size:80(128), align:80(128)
MURAM alloc, start:1900, size:80(128), align:80(128)
MURAM alloc, start:1980, size:80(128), align:80(128)
MURAM alloc, start:19c0, size:40(64), align:40(64)
MURAM alloc, start:1a00, size:40(64), align:40(64)
MURAM alloc, start:1a40, size:40(64), align:40(64)
MURAM alloc, start:1a80, size:40(64), align:40(64)
MURAM alloc, start:1a88, size:5d(93), align:4(4)

MURAM alloc, start:1a88, size:200(512), align:8(8)
MURAM alloc, start:1c88, size:208(520), align:8(8)
MURAM alloc, start:1f00, size:80(128), align:80(128)
MURAM alloc, start:2000, size:1a0(416), align:100(256)
MURAM alloc, start:20c0, size:40(64), align:20(32)
MURAM alloc, start:2100, size:100(256), align:100(256)
MURAM alloc, start:2200, size:a0(160), align:100(256)
MURAM alloc, start:22c0, size:c(12), align:40(64)
MURAM alloc, start:22a0, size:30(48), align:8(8)
MURAM alloc, start:2300, size:80(128), align:80(128)
MURAM alloc, start:2380, size:80(128), align:80(128)
MURAM alloc, start:2400, size:80(128), align:80(128)
MURAM alloc, start:2480, size:80(128), align:80(128)
MURAM alloc, start:2500, size:40(64), align:40(64)
MURAM alloc, start:2540, size:40(64), align:40(64)
MURAM alloc, start:2580, size:40(64), align:40(64)
MURAM alloc, start:25c0, size:40(64), align:40(64)
MURAM alloc, start:25cc, size:5d(93), align:4(4)

But I can't ping anymore

> 
> - Leo
> 
> > -----Original Message-----
> > From: linuxppc-dev-bounces+leoli=freescale.com@ozlabs.org
> [mailto:linuxppc-dev-bounces+leoli=freescale.com@ozlabs.org] On Behalf
> Of
> > Joakim Tjernlund
> > Sent: Thursday, June 14, 2007 3:18 PM
> > To: Liu Dave-r63238
> > Cc: 'linuxppc-dev Development'
> > Subject: Re: ucc_geth DPRAM alloc error, 2.6.22-rc3
> > 
> > On Thu, 2007-06-14 at 09:03 +0200, Joakim Tjernlund wrote:
> > > On Thu, 2007-06-14 at 10:31 +0800, Dave Liu wrote:
> > > > On Wed, 2007-06-13 at 16:22 +0200, Joakim Tjernlund wrote:
> > > > > Trying to bring up a third ethernet i/f(ifconfig eth2 up) on
> > > > > a Freescale 832x CPU gives me this:
> > > > >  ifconfig eth2 up
> > > > >  ucc_geth_startup: Can not allocate DPRAM memory for
> p_thread_data_tx.
> > > > >  eth2: Cannot configure net device, aborting.
> > > > >  SIOCSIFFLAGS: Cannot allocate memory
> > > > >
> > > > > This worked in 2.6.20
> > > >
> > > > Could you print the MURAM memory usage for debug?
> > > > eg. start address and size.
> > > >
> > > > -d
> > >
> > > Like this?
> > 
> > redid with all hex, decimal within()
> > MURAM alloc, start:1400, size:200(512), align:8(8)
> > MURAM alloc, start:1608, size:208(520), align:8(8)
> > MURAM alloc, start:1880, size:80(128), align:80(128)
> > MURAM alloc, start:1a00, size:1a0(416), align:100(256)
> > MURAM alloc, start:1bc0, size:40(64), align:20(32)
> > MURAM alloc, start:1d00, size:100(256), align:100(256)
> > MURAM alloc, start:1f00, size:a0(160), align:100(256)
> > MURAM alloc, start:1fc0, size:c(12), align:40(64)
> > MURAM alloc, start:2000, size:30(48), align:8(8)
> > MURAM alloc, start:2080, size:80(128), align:80(128)
> > MURAM alloc, start:2180, size:80(128), align:80(128)
> > MURAM alloc, start:2280, size:80(128), align:80(128)
> > MURAM alloc, start:2380, size:80(128), align:80(128)
> > MURAM alloc, start:2440, size:40(64), align:40(64)
> > MURAM alloc, start:24c0, size:40(64), align:40(64)
> > MURAM alloc, start:2540, size:40(64), align:40(64)
> > MURAM alloc, start:25c0, size:40(64), align:40(64)
> > MURAM alloc, start:262c, size:5d(93), align:4(4)
> > 
> > MURAM alloc, start:2630, size:200(512), align:8(8)
> > MURAM alloc, start:2838, size:208(520), align:8(8)
> > MURAM alloc, start:2a80, size:80(128), align:80(128)
> > MURAM alloc, start:2c00, size:1a0(416), align:100(256)
> > MURAM alloc, start:2de0, size:40(64), align:20(32)
> > MURAM alloc, start:2f00, size:100(256), align:100(256)
> > MURAM alloc, start:3100, size:a0(160), align:100(256)
> > MURAM alloc, start:3200, size:c(12), align:40(64)
> > MURAM alloc, start:3228, size:30(48), align:8(8)
> > MURAM alloc, start:3280, size:80(128), align:80(128)
> > MURAM alloc, start:3380, size:80(128), align:80(128)
> > MURAM alloc, start:3480, size:80(128), align:80(128)
> > MURAM alloc, start:3580, size:80(128), align:80(128)
> > MURAM alloc, start:3680, size:40(64), align:40(64)
> > MURAM alloc, start:3700, size:40(64), align:40(64)
> > MURAM alloc, start:3780, size:40(64), align:40(64)
> > MURAM alloc, start:3800, size:40(64), align:40(64)
> > MURAM alloc, start:3858, size:5d(93), align:4(4)
> > 
> > MURAM alloc, start:3858, size:200(512), align:8(8)
> > MURAM alloc, start:3a60, size:208(520), align:8(8)
> > MURAM alloc, start:3c80, size:80(128), align:80(128)
> > MURAM alloc, start:fffffff4, size:1a0(416), align:100(256)
> > 
> > some comments:
> > 
> > With these aligments, won't you waste alot of MURAM?
> > 
> > Looking at the 2 first allocs:
> >   MURAM alloc, start:1400, size:200(512), align:8(8)
> >   MURAM alloc, start:1608, size:208(520), align:8(8)
> > shouldn't the second alloc have 0x1600 as start address?
> > 
> >  Jocke
> > _______________________________________________
> > Linuxppc-dev mailing list
> > Linuxppc-dev@ozlabs.org
> > https://ozlabs.org/mailman/listinfo/linuxppc-dev
> 
> 

Re: ucc_geth DPRAM alloc error, 2.6.22-rc3

[Chuck Meade]

This output looks buggy:

Joakim Tjernlund wrote:
> On Thu, 2007-06-14 at 15:37 +0800, Li Yang-r58472 wrote:
>> Try remove the following lines in rheap.c
>>
>>          /* given alignment larger that default rheap alignment */
>>          if (alignment > info->alignment)
>>                  size += alignment - 1;
>>
>> I don't know if this breaks other things, just have a try.
> I did and got this alloc:
> MURAM alloc, start:400, size:200(512), align:8(8)
> MURAM alloc, start:600, size:208(520), align:8(8)
> MURAM alloc, start:880, size:80(128), align:80(128)

Bogus -- note the overlap below
> MURAM alloc, start:900, size:1a0(416), align:100(256)
> MURAM alloc, start:a40, size:40(64), align:20(32)

> MURAM alloc, start:b00, size:100(256), align:100(256)

Another overlap(s) below-- all of these overlap
> MURAM alloc, start:c00, size:a0(160), align:100(256)
> MURAM alloc, start:c40, size:c(12), align:40(64)
> MURAM alloc, start:c18, size:30(48), align:8(8)
> MURAM alloc, start:c80, size:80(128), align:80(128)

> MURAM alloc, start:d00, size:80(128), align:80(128)
> MURAM alloc, start:d80, size:80(128), align:80(128)
> MURAM alloc, start:e00, size:80(128), align:80(128)
> MURAM alloc, start:e80, size:40(64), align:40(64)
> MURAM alloc, start:ec0, size:40(64), align:40(64)
> MURAM alloc, start:f00, size:40(64), align:40(64)

Another overlap--
> MURAM alloc, start:f40, size:40(64), align:40(64)
> MURAM alloc, start:f44, size:5d(93), align:4(4)

> MURAM alloc, start:f48, size:200(512), align:8(8)
> MURAM alloc, start:1148, size:208(520), align:8(8)
> MURAM alloc, start:1380, size:80(128), align:80(128)

And here-
> MURAM alloc, start:1400, size:1a0(416), align:100(256)
> MURAM alloc, start:1580, size:40(64), align:20(32)

> MURAM alloc, start:1600, size:100(256), align:100(256)

Here- note the start address moving backward.  All overlap.
> MURAM alloc, start:1700, size:a0(160), align:100(256)
> MURAM alloc, start:1780, size:c(12), align:40(64)
> MURAM alloc, start:1758, size:30(48), align:8(8)

> MURAM alloc, start:1800, size:80(128), align:80(128)
> MURAM alloc, start:1880, size:80(128), align:80(128)
> MURAM alloc, start:1900, size:80(128), align:80(128)

And-
> MURAM alloc, start:1980, size:80(128), align:80(128)
> MURAM alloc, start:19c0, size:40(64), align:40(64)

> MURAM alloc, start:1a00, size:40(64), align:40(64)
> MURAM alloc, start:1a40, size:40(64), align:40(64)

And-
> MURAM alloc, start:1a80, size:40(64), align:40(64)
> MURAM alloc, start:1a88, size:5d(93), align:4(4)
> MURAM alloc, start:1a88, size:200(512), align:8(8)

> MURAM alloc, start:1c88, size:208(520), align:8(8)
> MURAM alloc, start:1f00, size:80(128), align:80(128)

And-
> MURAM alloc, start:2000, size:1a0(416), align:100(256)
> MURAM alloc, start:20c0, size:40(64), align:20(32)

> MURAM alloc, start:2100, size:100(256), align:100(256)
> MURAM alloc, start:2200, size:a0(160), align:100(256)

An overlap exists here too-
> MURAM alloc, start:22c0, size:c(12), align:40(64)
> MURAM alloc, start:22a0, size:30(48), align:8(8)

> MURAM alloc, start:2300, size:80(128), align:80(128)
> MURAM alloc, start:2380, size:80(128), align:80(128)
> MURAM alloc, start:2400, size:80(128), align:80(128)
> MURAM alloc, start:2480, size:80(128), align:80(128)
> MURAM alloc, start:2500, size:40(64), align:40(64)
> MURAM alloc, start:2540, size:40(64), align:40(64)
> MURAM alloc, start:2580, size:40(64), align:40(64)

And-
> MURAM alloc, start:25c0, size:40(64), align:40(64)
> MURAM alloc, start:25cc, size:5d(93), align:4(4)
> 
> But I can't ping anymore

These buffer overlaps probably have a lot to do with your pings stopping.
I would say first order of business would be to investigate what could
be generating all these overlapped allocations.  Some of these make me think
the allocator code could be racy, like allocations are not aware of other
"recent" or ongoing allocations.  But in any case the allocator is broken.

Chuck

RE: ucc_geth DPRAM alloc error, 2.6.22-rc3

[Li Yang-r58472]

You are right.  The proposed change is just an unwise suggestion.

I later overhauled and reworked the aligned allocation of rheap to
prevent it from generating internal fragment.  Patch coming soon.

- Leo

> -----Original Message-----
> From: Chuck Meade [mailto:chuck@ThePTRGroup.com]
> Sent: Thursday, June 14, 2007 8:19 PM
> To: joakim.tjernlund@transmode.se
> Cc: Li Yang-r58472; linuxppc-dev Development; Liu Dave-r63238
> Subject: Re: ucc_geth DPRAM alloc error, 2.6.22-rc3
>=20
> This output looks buggy:
>=20
{snip}

>=20
> These buffer overlaps probably have a lot to do with your pings
stopping.
> I would say first order of business would be to investigate what could
> be generating all these overlapped allocations.  Some of these make me
think
> the allocator code could be racy, like allocations are not aware of
other
> "recent" or ongoing allocations.  But in any case the allocator is
broken.
>=20
> Chuck

Re: ucc_geth DPRAM alloc error, 2.6.22-rc3

[Li Yang]

Here is the patch to remove internal fragment when doing
aligned allocation.

The patch change to add the fragments back into the free list,
instead of allocate the whole trunk of space with internal
fragment.
---

 arch/powerpc/lib/rheap.c |   45 +++++++++++++++++++++++++++------------------
 1 files changed, 27 insertions(+), 18 deletions(-)

diff --git a/arch/powerpc/lib/rheap.c b/arch/powerpc/lib/rheap.c
index 180ee29..f8b3f1a 100644
--- a/arch/powerpc/lib/rheap.c
+++ b/arch/powerpc/lib/rheap.c
@@ -437,16 +437,12 @@ unsigned long rh_alloc_align(rh_info_t * info, int size, int alignment, const ch
 	struct list_head *l;
 	rh_block_t *blk;
 	rh_block_t *newblk;
-	unsigned long start;
+	unsigned long start, sp_size;
 
 	/* Validate size, and alignment must be power of two */
 	if (size <= 0 || (alignment & (alignment - 1)) != 0)
 		return (unsigned long) -EINVAL;
 
-	/* given alignment larger that default rheap alignment */
-	if (alignment > info->alignment)
-		size += alignment - 1;
-
 	/* Align to configured alignment */
 	size = (size + (info->alignment - 1)) & ~(info->alignment - 1);
 
@@ -456,8 +452,11 @@ unsigned long rh_alloc_align(rh_info_t * info, int size, int alignment, const ch
 	blk = NULL;
 	list_for_each(l, &info->free_list) {
 		blk = list_entry(l, rh_block_t, list);
-		if (size <= blk->size)
-			break;
+		if (size <= blk->size) {
+			start = (blk->start + alignment - 1) & ~(alignment - 1);
+			if (start + size <= blk->start + blk->size)
+				break;
+		}
 		blk = NULL;
 	}
 
@@ -470,25 +469,35 @@ unsigned long rh_alloc_align(rh_info_t * info, int size, int alignment, const ch
 		list_del(&blk->list);
 		newblk = blk;
 	} else {
+		/* Fragment caused, split if needed */
+		/* Create block for fragment in the beginning, insert to free list */
+		sp_size = start - blk->start;
+		if (sp_size) {
+			rh_block_t *spblk;
+
+			spblk = get_slot(info);
+			spblk->start = blk->start;
+			spblk->size = sp_size;
+			list_add(&spblk->list, &blk->list);
+		}
 		newblk = get_slot(info);
-		newblk->start = blk->start;
+		newblk->start = start;
 		newblk->size = size;
 
-		/* blk still in free list, with updated start, size */
-		blk->start += size;
-		blk->size -= size;
+		/* blk still in free list, with updated start, size
+		 * for fragment in the end */
+		blk->start = start + size;
+		blk->size -= sp_size + size;
+		/* No fragment in the end, remove blk */
+		if (blk->size == 0) {
+			list_del(&blk->list);
+			release_slot(info, blk);
+		}
 	}
 
 	newblk->owner = owner;
-	start = newblk->start;
 	attach_taken_block(info, newblk);
 
-	/* for larger alignment return fixed up pointer  */
-	/* this is no problem with the deallocator since */
-	/* we scan for pointers that lie in the blocks   */
-	if (alignment > info->alignment)
-		start = (start + alignment - 1) & ~(alignment - 1);
-
 	return start;
 }

Re: ucc_geth DPRAM alloc error, 2.6.22-rc3

[Joakim Tjernlund]

On Thu, 2007-06-14 at 21:42 +0800, Li Yang wrote:
> Here is the patch to remove internal fragment when doing
> aligned allocation.
> 
> The patch change to add the fragments back into the free list,
> instead of allocate the whole trunk of space with internal
> fragment.
> ---

This gives me:
MURAM alloc, start:400, size:200(512), align:8(8)
MURAM alloc, start:600, size:208(520), align:8(8)
MURAM alloc, start:880, size:80(128), align:80(128)
MURAM alloc, start:900, size:1a0(416), align:100(256)
MURAM alloc, start:aa0, size:40(64), align:20(32)
MURAM alloc, start:b00, size:100(256), align:100(256)
MURAM alloc, start:c00, size:a0(160), align:100(256)
MURAM alloc, start:cc0, size:c(12), align:40(64)
MURAM alloc, start:cd0, size:30(48), align:8(8)
MURAM alloc, start:d00, size:80(128), align:80(128)
MURAM alloc, start:d80, size:80(128), align:80(128)
MURAM alloc, start:e00, size:80(128), align:80(128)
MURAM alloc, start:e80, size:80(128), align:80(128)
MURAM alloc, start:f00, size:40(64), align:40(64)
MURAM alloc, start:f40, size:40(64), align:40(64)
MURAM alloc, start:f80, size:40(64), align:40(64)
MURAM alloc, start:fc0, size:40(64), align:40(64)
MURAM alloc, start:1000, size:5d(93), align:4(4)

MURAM alloc, start:1000, size:200(512), align:8(8)
MURAM alloc, start:1200, size:208(520), align:8(8)
MURAM alloc, start:1480, size:80(128), align:80(128)
MURAM alloc, start:1500, size:1a0(416), align:100(256)
MURAM alloc, start:16a0, size:40(64), align:20(32)
MURAM alloc, start:1700, size:100(256), align:100(256)
MURAM alloc, start:1800, size:a0(160), align:100(256)
MURAM alloc, start:18c0, size:c(12), align:40(64)
MURAM alloc, start:18d0, size:30(48), align:8(8)
MURAM alloc, start:1900, size:80(128), align:80(128)
MURAM alloc, start:1980, size:80(128), align:80(128)
MURAM alloc, start:1a00, size:80(128), align:80(128)
MURAM alloc, start:1a80, size:80(128), align:80(128)
MURAM alloc, start:1b00, size:40(64), align:40(64)
MURAM alloc, start:1b40, size:40(64), align:40(64)
MURAM alloc, start:1b80, size:40(64), align:40(64)
MURAM alloc, start:1bc0, size:40(64), align:40(64)
MURAM alloc, start:1c00, size:5d(93), align:4(4)

MURAM alloc, start:1c00, size:200(512), align:8(8)
MURAM alloc, start:1e00, size:208(520), align:8(8)
MURAM alloc, start:2080, size:80(128), align:80(128)
MURAM alloc, start:2100, size:1a0(416), align:100(256)
MURAM alloc, start:22a0, size:40(64), align:20(32)
MURAM alloc, start:2300, size:100(256), align:100(256)
MURAM alloc, start:2400, size:a0(160), align:100(256)
MURAM alloc, start:24c0, size:c(12), align:40(64)
MURAM alloc, start:24d0, size:30(48), align:8(8)
MURAM alloc, start:2500, size:80(128), align:80(128)
MURAM alloc, start:2580, size:80(128), align:80(128)
MURAM alloc, start:2600, size:80(128), align:80(128)
MURAM alloc, start:2680, size:80(128), align:80(128)
MURAM alloc, start:2700, size:40(64), align:40(64)
MURAM alloc, start:2740, size:40(64), align:40(64)
MURAM alloc, start:2780, size:40(64), align:40(64)
MURAM alloc, start:27c0, size:40(64), align:40(64)
MURAM alloc, start:2800, size:5d(93), align:4(4)

Looks much better now and my ethernet i/f works now, thanks.
Would be great if this could be included in linus tree before 2.6.22

 Jocke

Re: ucc_geth DPRAM alloc error, 2.6.22-rc3

[Joakim Tjernlund]

On Fri, 2007-06-15 at 15:03 +0200, Joakim Tjernlund wrote:
> On Thu, 2007-06-14 at 21:42 +0800, Li Yang wrote:
> > Here is the patch to remove internal fragment when doing
> > aligned allocation.
> > 
> > The patch change to add the fragments back into the free list,
> > instead of allocate the whole trunk of space with internal
> > fragment.
> > ---
> 
> This gives me:
> MURAM alloc, start:400, size:200(512), align:8(8)
> MURAM alloc, start:600, size:208(520), align:8(8)
> MURAM alloc, start:880, size:80(128), align:80(128)
> MURAM alloc, start:900, size:1a0(416), align:100(256)
> MURAM alloc, start:aa0, size:40(64), align:20(32)
> MURAM alloc, start:b00, size:100(256), align:100(256)
> MURAM alloc, start:c00, size:a0(160), align:100(256)
> MURAM alloc, start:cc0, size:c(12), align:40(64)
> MURAM alloc, start:cd0, size:30(48), align:8(8)
> MURAM alloc, start:d00, size:80(128), align:80(128)
> MURAM alloc, start:d80, size:80(128), align:80(128)
> MURAM alloc, start:e00, size:80(128), align:80(128)
> MURAM alloc, start:e80, size:80(128), align:80(128)
> MURAM alloc, start:f00, size:40(64), align:40(64)
> MURAM alloc, start:f40, size:40(64), align:40(64)
> MURAM alloc, start:f80, size:40(64), align:40(64)
> MURAM alloc, start:fc0, size:40(64), align:40(64)
> MURAM alloc, start:1000, size:5d(93), align:4(4)

BTW, this last alloc looks a bit off, size if 93 bytes.

 Jocke

RE: ucc_geth DPRAM alloc error, 2.6.22-rc3

[Rune Torgersen]

Here is what I had to do to get best-fit + not allocating too much:
(against 2.6.18)
--- linux-innsys/arch/ppc/lib/rheap.c	2006/10/10 22:54:41	175
+++ linux-innsys/arch/ppc/lib/rheap.c	2006/12/03 18:04:42	205
@@ -428,19 +428,22 @@
 {
 	struct list_head *l;
 	rh_block_t *blk;
-	rh_block_t *newblk;
+	rh_block_t *newblk1, *newblk2;
 	void *start;
-
+	int align_mask =3D alignment - 1;
+    int off;
+	unsigned long s, e, m, bs, be;
+   =20
 	/* Validate size, (must be power of two) */
 	if (size <=3D 0 || (alignment & (alignment - 1)) !=3D 0)
 		return ERR_PTR(-EINVAL);
=20
 	/* given alignment larger that default rheap alignment */
-	if (alignment > info->alignment)
-		size +=3D alignment - 1;
+	//if (alignment > info->alignment)
+	//	size +=3D alignment - 1;
=20
 	/* Align to configured alignment */
-	size =3D (size + (info->alignment - 1)) & ~(info->alignment - 1);
+	//size =3D (size + (info->alignment - 1)) & ~(info->alignment -
1);
=20
 	if (assure_empty(info, 1) < 0)
 		return ERR_PTR(-ENOMEM);
@@ -448,8 +451,18 @@
 	blk =3D NULL;
 	list_for_each(l, &info->free_list) {
 		blk =3D list_entry(l, rh_block_t, list);
-		if (size <=3D blk->size)
+	=09
+		if ((blk->size =3D=3D size) && (((int)blk->start &
align_mask) =3D=3D 0))
+		    break;
+	=09
+		if (((int)blk->start & align_mask) !=3D 0)
+			off =3D align_mask - ((int)blk->start &
align_mask) + 1;
+		else
+			off =3D 0;
+		   =20
+		if (blk->size - off >=3D size)
 			break;
+	=09
 		blk =3D NULL;
 	}
=20
@@ -468,25 +481,35 @@
 		return start;
 	}
=20
-	newblk =3D get_slot(info);
-	newblk->start =3D blk->start;
-	newblk->size =3D size;
-	newblk->owner =3D owner;
-
-	/* blk still in free list, with updated start, size */
-	blk->start =3D (int8_t *)blk->start + size;
-	blk->size -=3D size;
+	bs =3D (int)blk->start;
+	be =3D (int)blk->start + blk->size;
+	s =3D (int)blk->start + off;
+	e =3D s + size;
+=09
+	if (bs =3D=3D s || be =3D=3D e) {
+		if (bs =3D=3D s)
+			blk->start =3D (int8_t *)blk->start + size;
+		blk->size -=3D size;
=20
-	start =3D newblk->start;
+	} else {
+		/* The front free fragment */
+		blk->size =3D s - bs;
=20
-	attach_taken_block(info, newblk);
-=09
-	/* for larger alignment return fixed up pointer  */
-	/* this is no problem with the deallocator since */
-	/* we scan for pointers that lie in the blocks   */
-	if (alignment > info->alignment)
-		start =3D (void *)(((unsigned long)start + alignment - 1)
&
-				~(alignment - 1));
+		/* The back free fragment */
+		newblk2 =3D get_slot(info);
+		newblk2->start =3D (void *)e;
+		newblk2->size =3D be - e;
+
+		list_add(&newblk2->list, &blk->list);
+	}
+
+	newblk1 =3D get_slot(info);
+	newblk1->start =3D (void *)s;
+	newblk1->size =3D e - s;
+	newblk1->owner =3D owner;
+
+	start =3D newblk1->start;
+	attach_taken_block(info, newblk1);
=20
 	return start;
 }

RE: ucc_geth DPRAM alloc error, 2.6.22-rc3

[Li Yang-r58472]

> -----Original Message-----
> From: Rune Torgersen [mailto:runet@innovsys.com]
> Sent: Friday, June 15, 2007 6:50 AM
> To: joakim.tjernlund@transmode.se; Li Yang-r58472
> Cc: linuxppc-dev Development; Liu Dave-r63238
> Subject: RE: ucc_geth DPRAM alloc error, 2.6.22-rc3
>=20
> Here is what I had to do to get best-fit + not allocating too much:
> (against 2.6.18)
> --- linux-innsys/arch/ppc/lib/rheap.c	2006/10/10 22:54:41	175
> +++ linux-innsys/arch/ppc/lib/rheap.c	2006/12/03 18:04:42	205
{snip}
>  	if (assure_empty(info, 1) < 0)
>  		return ERR_PTR(-ENOMEM);

You also need to change this to assure_empty(info, 2), as you are very
likely to need 2 slots afterward.  You need to assure there are enough
slots or grow the block number.

- Leo

RE: ucc_geth DPRAM alloc error, 2.6.22-rc3

[Rune Torgersen]

[-- Attachment #1: Type: text/plain, Size: 434 bytes --]

>From: Li Yang-r58472 [mailto:LeoLi@freescale.com]
>>  	if (assure_empty(info, 1) < 0)
>>  		return ERR_PTR(-ENOMEM);

>You also need to change this to assure_empty(info, 2), as you are very
>likely to need 2 slots afterward.  You need to assure there are enough
>slots or grow the block number.

Ahh. I'll fix that in my code.
It was a quick&dirty hack to get the allocator to work wen we used most of the available DPRAM.

[-- Attachment #2: Type: text/html, Size: 1024 bytes --]

RE: ucc_geth DPRAM alloc error, 2.6.22-rc3

[Rune Torgersen]

> -----Original Message-----
> From: Joakim Tjernlund
> Sent: Thursday, June 14, 2007 2:18 AM

> some comments:
>=20
> With these aligments, won't you waste alot of MURAM?
>=20
> Looking at the 2 first allocs:
>   MURAM alloc, start:1400, size:200(512), align:8(8)
>   MURAM alloc, start:1608, size:208(520), align:8(8)
> shouldn't the second alloc have 0x1600 as start address?

I've noticed (on a internal project that uses a LOT of DPRAM on a 82xx,
uses same allocator), that the current allignment stuff allocates bytes
requested + allignment and never frees the unused space.

So if you want 8 bytes with 64 bytes allignment, the allocator
allocatesd (8+64) 72 bytes. It should then return the unused 64 bytes at
the beginning and end to the pool, but doesn't.

I have an internal version of the allocator that does it correct (for us
atleast), and also does a best fit instead of first fit.

If anybody is interested, I can post it. Mine is the rheap from arch/ppc
not arch/powerpc

RE: ucc_geth DPRAM alloc error, 2.6.22-rc3

[Li Yang-r58472]

> -----Original Message-----
> From: Joakim Tjernlund [mailto:joakim.tjernlund@transmode.se]
> Sent: Wednesday, June 13, 2007 10:22 PM
> To: 'linuxppc-dev Development'; Li Yang-r58472
> Subject: ucc_geth DPRAM alloc error, 2.6.22-rc3
>=20
> Trying to bring up a third ethernet i/f(ifconfig eth2 up) on
> a Freescale 832x CPU gives me this:
>  ifconfig eth2 up
>  ucc_geth_startup: Can not allocate DPRAM memory for p_thread_data_tx.
>  eth2: Cannot configure net device, aborting.
>  SIOCSIFFLAGS: Cannot allocate memory
>=20
> This worked in 2.6.20
Hi Joakim,

Thanks for the bug report.  The cause of this problem is that ucc_geth
is set to work in 1000Mbps mode.  However, 8323 only supports 100Mbps.
1000Mbps mode consumes much more MURAM for virtual FIFO.

I will investigate this problem further, and see if a patch is needed.

- Leo

RE: ucc_geth DPRAM alloc error, 2.6.22-rc3

[Li Yang-r58472]

> -----Original Message-----
> From: Li Yang-r58472
> Sent: Thursday, June 14, 2007 11:15 AM
> To: 'joakim.tjernlund@transmode.se'; 'linuxppc-dev Development'
> Subject: RE: ucc_geth DPRAM alloc error, 2.6.22-rc3
>=20
> > -----Original Message-----
> > From: Joakim Tjernlund [mailto:joakim.tjernlund@transmode.se]
> > Sent: Wednesday, June 13, 2007 10:22 PM
> > To: 'linuxppc-dev Development'; Li Yang-r58472
> > Subject: ucc_geth DPRAM alloc error, 2.6.22-rc3
> >
> > Trying to bring up a third ethernet i/f(ifconfig eth2 up) on
> > a Freescale 832x CPU gives me this:
> >  ifconfig eth2 up
> >  ucc_geth_startup: Can not allocate DPRAM memory for
p_thread_data_tx.
> >  eth2: Cannot configure net device, aborting.
> >  SIOCSIFFLAGS: Cannot allocate memory
> >
> > This worked in 2.6.20
> Hi Joakim,
>=20
> Thanks for the bug report.  The cause of this problem is that ucc_geth
is set to work in 1000Mbps mode.  However, 8323 only supports
> 100Mbps.  1000Mbps mode consumes much more MURAM for virtual FIFO.


You can try adding the following property in your ucc node.
	phy-connection-type =3D "mii"

- Leo

RE: ucc_geth DPRAM alloc error, 2.6.22-rc3

[Joakim Tjernlund]

On Thu, 2007-06-14 at 11:37 +0800, Li Yang-r58472 wrote:
> > -----Original Message-----
> > From: Li Yang-r58472
> > Sent: Thursday, June 14, 2007 11:15 AM
> > To: 'joakim.tjernlund@transmode.se'; 'linuxppc-dev Development'
> > Subject: RE: ucc_geth DPRAM alloc error, 2.6.22-rc3
> > 
> > > -----Original Message-----
> > > From: Joakim Tjernlund [mailto:joakim.tjernlund@transmode.se]
> > > Sent: Wednesday, June 13, 2007 10:22 PM
> > > To: 'linuxppc-dev Development'; Li Yang-r58472
> > > Subject: ucc_geth DPRAM alloc error, 2.6.22-rc3
> > >
> > > Trying to bring up a third ethernet i/f(ifconfig eth2 up) on
> > > a Freescale 832x CPU gives me this:
> > >  ifconfig eth2 up
> > >  ucc_geth_startup: Can not allocate DPRAM memory for
> p_thread_data_tx.
> > >  eth2: Cannot configure net device, aborting.
> > >  SIOCSIFFLAGS: Cannot allocate memory
> > >
> > > This worked in 2.6.20
> > Hi Joakim,
> > 
> > Thanks for the bug report.  The cause of this problem is that ucc_geth
> is set to work in 1000Mbps mode.  However, 8323 only supports
> > 100Mbps.  1000Mbps mode consumes much more MURAM for virtual FIFO.
> 
> 
> You can try adding the following property in your ucc node.
> 	phy-connection-type = "mii"

Tried that and it failed too.

   Jocke