Andi Kleen wrote:
I would recommend to merge this patch ASAP if possible still into 2.6.15.
Please also consider the forcedeth TSO fix for large buffers posted by
Ayaz Aabdulla the 2005-12-10 for inclusion in 2.5.15.
Thanks,
-Andi
Regards
Anders Fugmann
-
To unsubscribe from this list: se
> For me, there are 64 bytes left. Could you send me your .config, then I
> can check it.
I tested your pci_map_single patch now and it indeed fixes the problem.
Looks like your theory was right. I redid my math and i really was a bit
off and the "crosses into 4k slab" theory makes a lot of sens
Andi Kleen wrote:
On Fri, Dec 23, 2005 at 03:15:24PM +0100, Manfred Spraul wrote:
Andi Kleen wrote:
It's more than 82 bytes but less than 86. I didn't run the binary
search further.
My guess: with 86 byte additional padding, you end up doing
kmalloc(2049), and thus with a 4
On Fri, Dec 23, 2005 at 03:15:24PM +0100, Manfred Spraul wrote:
> Andi Kleen wrote:
>
> >It's more than 82 bytes but less than 86. I didn't run the binary
> >search further.
> >
> >
> >
> My guess: with 86 byte additional padding, you end up doing
> kmalloc(2049), and thus with a 4 kB allocation
Andi Kleen wrote:
It's more than 82 bytes but less than 86. I didn't run the binary
search further.
My guess: with 86 byte additional padding, you end up doing
kmalloc(2049), and thus with a 4 kB allocation.
On my setup, padding 64 results in a 1984 byte kmalloc call:
dev_kfree_skb for 162
On Fri, Dec 23, 2005 at 01:42:52PM +0100, Manfred Spraul wrote:
> Hi,
>
> Andi Kleen wrote:
>
> >It shouldn't make any difference on !SLAB_DEBUG kernels because kmalloc
> >will pad typical mtus (1.5k, 9k) to 2k or 16k. But at least the
> >network driver is usable now again with slab debugging e
Hi,
Andi Kleen wrote:
It shouldn't make any difference on !SLAB_DEBUG kernels because kmalloc
will pad typical mtus (1.5k, 9k) to 2k or 16k. But at least the
network driver is usable now again with slab debugging enabled.
Very odd. slab debugging doesn't affect the padding. Even with sla
I finally tracked down what caused the red zone failures with forcedeth
on my test system. It's only related to me starting to use CONFIG_SLAB_DEBUG
instead of any driver changes and probably was always broken.
I have not done too heavy testing with this yet, but the simple
tests where it failed
