* ucc_geth DPRAM alloc error, 2.6.22-rc3
@ 2007-06-13 14:22 Joakim Tjernlund
2007-06-13 22:00 ` Timur Tabi
` (2 more replies)
0 siblings, 3 replies; 22+ messages in thread
From: Joakim Tjernlund @ 2007-06-13 14:22 UTC (permalink / raw)
To: 'linuxppc-dev Development', Li Yang-r58472
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
^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: ucc_geth DPRAM alloc error, 2.6.22-rc3
2007-06-13 14:22 ucc_geth DPRAM alloc error, 2.6.22-rc3 Joakim Tjernlund
@ 2007-06-13 22:00 ` Timur Tabi
2007-06-13 22:47 ` Joakim Tjernlund
2007-06-14 2:31 ` Dave Liu
2007-06-14 3:14 ` Li Yang-r58472
2 siblings, 1 reply; 22+ messages in thread
From: Timur Tabi @ 2007-06-13 22:00 UTC (permalink / raw)
To: joakim.tjernlund; +Cc: 'linuxppc-dev Development'
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
^ permalink raw reply [flat|nested] 22+ messages in thread
* RE: ucc_geth DPRAM alloc error, 2.6.22-rc3
2007-06-13 22:00 ` Timur Tabi
@ 2007-06-13 22:47 ` Joakim Tjernlund
0 siblings, 0 replies; 22+ messages in thread
From: Joakim Tjernlund @ 2007-06-13 22:47 UTC (permalink / raw)
To: 'Timur Tabi'; +Cc: 'linuxppc-dev Development'
>
> 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
^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: ucc_geth DPRAM alloc error, 2.6.22-rc3
2007-06-13 14:22 ucc_geth DPRAM alloc error, 2.6.22-rc3 Joakim Tjernlund
2007-06-13 22:00 ` Timur Tabi
@ 2007-06-14 2:31 ` Dave Liu
2007-06-14 7:03 ` Joakim Tjernlund
2007-06-14 3:14 ` Li Yang-r58472
2 siblings, 1 reply; 22+ messages in thread
From: Dave Liu @ 2007-06-14 2:31 UTC (permalink / raw)
To: joakim.tjernlund; +Cc: 'linuxppc-dev Development'
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
^ permalink raw reply [flat|nested] 22+ messages in thread
* RE: ucc_geth DPRAM alloc error, 2.6.22-rc3
2007-06-13 14:22 ucc_geth DPRAM alloc error, 2.6.22-rc3 Joakim Tjernlund
2007-06-13 22:00 ` Timur Tabi
2007-06-14 2:31 ` Dave Liu
@ 2007-06-14 3:14 ` Li Yang-r58472
2 siblings, 0 replies; 22+ messages in thread
From: Li Yang-r58472 @ 2007-06-14 3:14 UTC (permalink / raw)
To: joakim.tjernlund, linuxppc-dev Development
> -----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
^ permalink raw reply [flat|nested] 22+ messages in thread
* RE: ucc_geth DPRAM alloc error, 2.6.22-rc3
@ 2007-06-14 3:37 Li Yang-r58472
2007-06-14 7:04 ` Joakim Tjernlund
0 siblings, 1 reply; 22+ messages in thread
From: Li Yang-r58472 @ 2007-06-14 3:37 UTC (permalink / raw)
To: joakim.tjernlund, linuxppc-dev Development
> -----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
^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: ucc_geth DPRAM alloc error, 2.6.22-rc3
2007-06-14 2:31 ` Dave Liu
@ 2007-06-14 7:03 ` Joakim Tjernlund
2007-06-14 7:17 ` Joakim Tjernlund
0 siblings, 1 reply; 22+ messages in thread
From: Joakim Tjernlund @ 2007-06-14 7:03 UTC (permalink / raw)
To: Dave Liu; +Cc: 'linuxppc-dev Development'
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
^ permalink raw reply [flat|nested] 22+ messages in thread
* RE: ucc_geth DPRAM alloc error, 2.6.22-rc3
2007-06-14 3:37 Li Yang-r58472
@ 2007-06-14 7:04 ` Joakim Tjernlund
0 siblings, 0 replies; 22+ messages in thread
From: Joakim Tjernlund @ 2007-06-14 7:04 UTC (permalink / raw)
To: Li Yang-r58472; +Cc: linuxppc-dev Development
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
^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: ucc_geth DPRAM alloc error, 2.6.22-rc3
2007-06-14 7:03 ` Joakim Tjernlund
@ 2007-06-14 7:17 ` Joakim Tjernlund
2007-06-14 7:26 ` Li Yang-r58472
` (2 more replies)
0 siblings, 3 replies; 22+ messages in thread
From: Joakim Tjernlund @ 2007-06-14 7:17 UTC (permalink / raw)
To: Dave Liu; +Cc: 'linuxppc-dev Development'
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
^ permalink raw reply [flat|nested] 22+ messages in thread
* RE: ucc_geth DPRAM alloc error, 2.6.22-rc3
2007-06-14 7:17 ` Joakim Tjernlund
@ 2007-06-14 7:26 ` Li Yang-r58472
2007-06-14 7:57 ` Joakim Tjernlund
2007-06-14 7:37 ` Li Yang-r58472
2007-06-14 22:46 ` Rune Torgersen
2 siblings, 1 reply; 22+ messages in thread
From: Li Yang-r58472 @ 2007-06-14 7:26 UTC (permalink / raw)
To: joakim.tjernlund, Liu Dave-r63238; +Cc: linuxppc-dev Development
> -----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
^ permalink raw reply [flat|nested] 22+ messages in thread
* RE: ucc_geth DPRAM alloc error, 2.6.22-rc3
2007-06-14 7:17 ` Joakim Tjernlund
2007-06-14 7:26 ` Li Yang-r58472
@ 2007-06-14 7:37 ` Li Yang-r58472
2007-06-14 7:54 ` Joakim Tjernlund
2007-06-14 22:46 ` Rune Torgersen
2 siblings, 1 reply; 22+ messages in thread
From: Li Yang-r58472 @ 2007-06-14 7:37 UTC (permalink / raw)
To: joakim.tjernlund, Liu Dave-r63238; +Cc: linuxppc-dev Development
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
^ permalink raw reply [flat|nested] 22+ messages in thread
* RE: ucc_geth DPRAM alloc error, 2.6.22-rc3
2007-06-14 7:37 ` Li Yang-r58472
@ 2007-06-14 7:54 ` Joakim Tjernlund
2007-06-14 12:18 ` Chuck Meade
2007-06-14 22:50 ` Rune Torgersen
0 siblings, 2 replies; 22+ messages in thread
From: Joakim Tjernlund @ 2007-06-14 7:54 UTC (permalink / raw)
To: Li Yang-r58472; +Cc: linuxppc-dev Development, Liu Dave-r63238
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
>
>
^ permalink raw reply [flat|nested] 22+ messages in thread
* RE: ucc_geth DPRAM alloc error, 2.6.22-rc3
2007-06-14 7:26 ` Li Yang-r58472
@ 2007-06-14 7:57 ` Joakim Tjernlund
0 siblings, 0 replies; 22+ messages in thread
From: Joakim Tjernlund @ 2007-06-14 7:57 UTC (permalink / raw)
To: Li Yang-r58472; +Cc: linuxppc-dev Development, Liu Dave-r63238
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)
^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: ucc_geth DPRAM alloc error, 2.6.22-rc3
2007-06-14 7:54 ` Joakim Tjernlund
@ 2007-06-14 12:18 ` Chuck Meade
2007-06-14 12:48 ` Li Yang-r58472
2007-06-14 13:42 ` Li Yang
2007-06-14 22:50 ` Rune Torgersen
1 sibling, 2 replies; 22+ messages in thread
From: Chuck Meade @ 2007-06-14 12:18 UTC (permalink / raw)
To: joakim.tjernlund; +Cc: linuxppc-dev Development, Liu Dave-r63238
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
^ permalink raw reply [flat|nested] 22+ messages in thread
* RE: ucc_geth DPRAM alloc error, 2.6.22-rc3
2007-06-14 12:18 ` Chuck Meade
@ 2007-06-14 12:48 ` Li Yang-r58472
2007-06-14 13:42 ` Li Yang
1 sibling, 0 replies; 22+ messages in thread
From: Li Yang-r58472 @ 2007-06-14 12:48 UTC (permalink / raw)
To: Chuck Meade, joakim.tjernlund; +Cc: linuxppc-dev Development, Liu Dave-r63238
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
^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: ucc_geth DPRAM alloc error, 2.6.22-rc3
2007-06-14 12:18 ` Chuck Meade
2007-06-14 12:48 ` Li Yang-r58472
@ 2007-06-14 13:42 ` Li Yang
2007-06-15 13:03 ` Joakim Tjernlund
1 sibling, 1 reply; 22+ messages in thread
From: Li Yang @ 2007-06-14 13:42 UTC (permalink / raw)
To: Chuck Meade; +Cc: linuxppc-dev Development, Liu Dave-r63238
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;
}
^ permalink raw reply related [flat|nested] 22+ messages in thread
* RE: ucc_geth DPRAM alloc error, 2.6.22-rc3
2007-06-14 7:17 ` Joakim Tjernlund
2007-06-14 7:26 ` Li Yang-r58472
2007-06-14 7:37 ` Li Yang-r58472
@ 2007-06-14 22:46 ` Rune Torgersen
2 siblings, 0 replies; 22+ messages in thread
From: Rune Torgersen @ 2007-06-14 22:46 UTC (permalink / raw)
To: joakim.tjernlund, Dave Liu; +Cc: linuxppc-dev Development
> -----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
^ permalink raw reply [flat|nested] 22+ messages in thread
* RE: ucc_geth DPRAM alloc error, 2.6.22-rc3
2007-06-14 7:54 ` Joakim Tjernlund
2007-06-14 12:18 ` Chuck Meade
@ 2007-06-14 22:50 ` Rune Torgersen
2007-06-15 2:44 ` Li Yang-r58472
1 sibling, 1 reply; 22+ messages in thread
From: Rune Torgersen @ 2007-06-14 22:50 UTC (permalink / raw)
To: joakim.tjernlund, Li Yang-r58472
Cc: linuxppc-dev Development, Liu Dave-r63238
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;
}
^ permalink raw reply [flat|nested] 22+ messages in thread
* RE: ucc_geth DPRAM alloc error, 2.6.22-rc3
2007-06-14 22:50 ` Rune Torgersen
@ 2007-06-15 2:44 ` Li Yang-r58472
2007-06-15 3:47 ` Rune Torgersen
0 siblings, 1 reply; 22+ messages in thread
From: Li Yang-r58472 @ 2007-06-15 2:44 UTC (permalink / raw)
To: Rune Torgersen, joakim.tjernlund
Cc: linuxppc-dev Development, Liu Dave-r63238
> -----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
^ permalink raw reply [flat|nested] 22+ messages in thread
* RE: ucc_geth DPRAM alloc error, 2.6.22-rc3
2007-06-15 2:44 ` Li Yang-r58472
@ 2007-06-15 3:47 ` Rune Torgersen
0 siblings, 0 replies; 22+ messages in thread
From: Rune Torgersen @ 2007-06-15 3:47 UTC (permalink / raw)
To: Li Yang-r58472, joakim.tjernlund
Cc: linuxppc-dev Development, Liu Dave-r63238
[-- 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 --]
^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: ucc_geth DPRAM alloc error, 2.6.22-rc3
2007-06-14 13:42 ` Li Yang
@ 2007-06-15 13:03 ` Joakim Tjernlund
2007-06-15 14:35 ` Joakim Tjernlund
0 siblings, 1 reply; 22+ messages in thread
From: Joakim Tjernlund @ 2007-06-15 13:03 UTC (permalink / raw)
To: Li Yang; +Cc: linuxppc-dev Development, Chuck Meade, Liu Dave-r63238
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
^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: ucc_geth DPRAM alloc error, 2.6.22-rc3
2007-06-15 13:03 ` Joakim Tjernlund
@ 2007-06-15 14:35 ` Joakim Tjernlund
0 siblings, 0 replies; 22+ messages in thread
From: Joakim Tjernlund @ 2007-06-15 14:35 UTC (permalink / raw)
To: Li Yang; +Cc: linuxppc-dev Development, Chuck Meade, Liu Dave-r63238
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
^ permalink raw reply [flat|nested] 22+ messages in thread
end of thread, other threads:[~2007-06-15 14:35 UTC | newest]
Thread overview: 22+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2007-06-13 14:22 ucc_geth DPRAM alloc error, 2.6.22-rc3 Joakim Tjernlund
2007-06-13 22:00 ` Timur Tabi
2007-06-13 22:47 ` Joakim Tjernlund
2007-06-14 2:31 ` Dave Liu
2007-06-14 7:03 ` Joakim Tjernlund
2007-06-14 7:17 ` Joakim Tjernlund
2007-06-14 7:26 ` Li Yang-r58472
2007-06-14 7:57 ` Joakim Tjernlund
2007-06-14 7:37 ` Li Yang-r58472
2007-06-14 7:54 ` Joakim Tjernlund
2007-06-14 12:18 ` Chuck Meade
2007-06-14 12:48 ` Li Yang-r58472
2007-06-14 13:42 ` Li Yang
2007-06-15 13:03 ` Joakim Tjernlund
2007-06-15 14:35 ` Joakim Tjernlund
2007-06-14 22:50 ` Rune Torgersen
2007-06-15 2:44 ` Li Yang-r58472
2007-06-15 3:47 ` Rune Torgersen
2007-06-14 22:46 ` Rune Torgersen
2007-06-14 3:14 ` Li Yang-r58472
-- strict thread matches above, loose matches on Subject: below --
2007-06-14 3:37 Li Yang-r58472
2007-06-14 7:04 ` Joakim Tjernlund
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox