> Now I understand why people don't read unsubscription info on mailing list.
> They don't read their own signatures ;-)
Yep. You need some company lawyers to send two lines to a certain western
country; but then they start focussing on stuff like this :-(
--
greetz, marc
Xerox does it again a
> They seem like worm virus. or
> The linuxppc-dev really doesn't have love?
> https://ozlabs.org/mailman/listinfo/linuxppc-dev
Doesn't anyone know how to read e-mails these days? I'll put it in caps,
maybe it will stand out more:
HTTPS://OZLABS.ORG/MAILMAN/LISTINFO/LINUXPPC-DEV
--
greetz,
>We are using PPC8248 provided by freescale and the kernel 2.6.10. I
> believe we have cache problem.
> We are allocating DMA buffers in our driver. If we increase the DMA buffer
> size the board hangs/halts(when try to load more applications).
> If we reduce the DMA buffer size, then we
With the release of the 2.6.22, our boards didn't boot anymore. I traced
the change back to 2.6.21-git10/2.6.21-git11.
The reason they didn't boot was that the kernel didn't detect the flash
where the root filesystem is stored on. The boards boot without an
initrd, directly from flash.
A file w
> > I was expecting a lower DMM performance but wasn't expecting such a
> > drain on kernel/network load.
>
> OK, to be clear: you seem to be saying that using the SLOB instead
> of the SLAB allocator results in such terrible memory fragmentation
> that network performance is degraded by large fac
> More platforms and higher bitrate tests (I've left the previous post in
> comment):
I finally was able to figure out the culprid:
CONFIG_SLOB=y
instead of
CONFIG_SLAB=y
CONFIG_SLAB:
Disabling this replaces the advanced SLAB allocator and
kmalloc support with the drastically simple
More platforms and higher bitrate tests (I've left the previous post in
comment):
> a) 8245/2.4.34/e100: 2.3.43-k1, @400 MHz
> b) 8245/2.6.17/e100: 2.3.43-k1 [2] @350 MHz
> c) 8347e/2.6.21.1/gianfar @400 Mhz
> d) XScale-IXP42x/2.6.18-4/ixp4xx @266 MHz (NSLU2)
e) 8245/2.6.17/e100: 3.5.10-k2-NAPI @3
a small update:
> 8245: 2.4.34
> 8237e: 2.6.21.1
I've tried the following setup:
multicast stream @8192 kbps, one process taking in and dumping the data
on each board [1].
a) 8245/2.4.34/e100: 2.3.43-k1, @400 MHz
b) 8245/2.6.17/e100: 2.3.43-k1 [2] @350 MHz
c) 8347e/2.6.21.1/gianfar @400 Mhz
c) X
