ucc_geth DPRAM alloc error, 2.6.22-rc3

20 messages, 6 authors, 2007-06-15 · open the first message on its own page

ucc_geth DPRAM alloc error, 2.6.22-rc3

From: Joakim Tjernlund <hidden>
Date: 2007-06-13 14:22:15 

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

From: Timur Tabi <hidden>
Date: 2007-06-13 22:00:08 

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

From: Joakim Tjernlund <hidden>
Date: 2007-06-13 22:47:17 

Joakim Tjernlund wrote:
quoted
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.
quoted
 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

From: Dave Liu <hidden>
Date: 2007-06-14 02:31:24 

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

From: Li Yang-r58472 <hidden>
Date: 2007-06-14 03:12:44 

-----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

From: Joakim Tjernlund <hidden>
Date: 2007-06-14 07:03:12 

On Thu, 2007-06-14 at 10:31 +0800, Dave Liu wrote:
On Wed, 2007-06-13 at 16:22 +0200, Joakim Tjernlund wrote:
quoted
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

From: Joakim Tjernlund <hidden>
Date: 2007-06-14 07:17:52 

On Thu, 2007-06-14 at 09:03 +0200, Joakim Tjernlund wrote:
On Thu, 2007-06-14 at 10:31 +0800, Dave Liu wrote:
quoted
On Wed, 2007-06-13 at 16:22 +0200, Joakim Tjernlund wrote:
quoted
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

From: Li Yang-r58472 <hidden>
Date: 2007-06-14 07:24:21 

-----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:
quoted
On Thu, 2007-06-14 at 10:31 +0800, Dave Liu wrote:
quoted
On Wed, 2007-06-13 at 16:22 +0200, Joakim Tjernlund wrote:
quoted
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.
quoted
quoted
quoted
 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

    

      From: Li Yang-r58472 <hidden>

      Date: 2007-06-14 07:35:39 
    

  

  
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:
quoted
On Thu, 2007-06-14 at 10:31 +0800, Dave Liu wrote:
quoted
On Wed, 2007-06-13 at 16:22 +0200, Joakim Tjernlund wrote:
quoted
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.
quoted
quoted
quoted
 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

    

      From: Joakim Tjernlund <hidden>

      Date: 2007-06-14 07:54:34 
    

  

  
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

quoted
-----Original Message-----
From: linuxppc-dev-bounces+leoli=freescale.com@ozlabs.org
[mailto:linuxppc-dev-bounces+leoli=freescale.com@ozlabs.org] On Behalf
Of
quoted
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:
quoted
On Thu, 2007-06-14 at 10:31 +0800, Dave Liu wrote:
quoted
On Wed, 2007-06-13 at 16:22 +0200, Joakim Tjernlund wrote:
quoted
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.
quoted
quoted
quoted
quoted
 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

    

      From: Joakim Tjernlund <hidden>

      Date: 2007-06-14 07:58:04 
    

  

  
On Thu, 2007-06-14 at 15:26 +0800, Li Yang-r58472 wrote:
quoted
-----Original Message-----
From: linuxppc-dev-bounces+leoli=freescale.com@ozlabs.org
[mailto:linuxppc-dev-bounces+leoli=freescale.com@ozlabs.org] On Behalf
Of
quoted
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:
quoted
On Thu, 2007-06-14 at 10:31 +0800, Dave Liu wrote:
quoted
On Wed, 2007-06-13 at 16:22 +0200, Joakim Tjernlund wrote:
quoted
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.
quoted
quoted
quoted
quoted
 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.

quoted
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

    

      From: Chuck Meade <hidden>

      Date: 2007-06-14 12:39:18 
    

  

  
This output looks buggy:

Joakim Tjernlund wrote:
On Thu, 2007-06-14 at 15:37 +0800, Li Yang-r58472 wrote:
quoted
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

    

      From: Li Yang-r58472 <hidden>

      Date: 2007-06-14 12:46:26 
    

  

  
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

    

      From: Li Yang <hidden>

      Date: 2007-06-14 13:40:37 
    

  

  
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

    

      From: Rune Torgersen <hidden>

      Date: 2007-06-14 22:58:09 
    

  

  
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

    

      From: Rune Torgersen <hidden>

      Date: 2007-06-14 22:58:10 
    

  

  
-----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

    

      From: Li Yang-r58472 <hidden>

      Date: 2007-06-15 02:43:04 
    

  

  
quoted hunk
-----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

    

      From: Rune Torgersen <hidden>

      Date: 2007-06-15 03:49:33 
    

  

  
From: Li Yang-r58472 [mailto:LeoLi@freescale.com]
quoted
 	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.





  

    
Re: ucc_geth DPRAM alloc error, 2.6.22-rc3

    

      From: Joakim Tjernlund <hidden>

      Date: 2007-06-15 13:03:19 
    

  

  
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

    

      From: Joakim Tjernlund <hidden>

      Date: 2007-06-15 14:35:18 
    

  

  
On Fri, 2007-06-15 at 15:03 +0200, Joakim Tjernlund wrote:
On Thu, 2007-06-14 at 21:42 +0800, Li Yang wrote:
quoted
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




    
  

  
    

      

        Keyboard shortcuts
      

      

        
          
hback out one level

          
jnext message in thread

          
kprevious message in thread

          
ldrill in

          
Escclose help / fold thread tree

          
?toggle this help