SKB corruption on heavy traffic

Thu May 1 01:07:15 EST 2008

Ok... We will try to enable debug on slab! :)
Ring buffer full occurs on tx in spite of having free bd's in the ring,
it doesn't use them... And it does not recover.
The problems that I refered are from previous kernel versions to ours
(our base of development was 2.4.31) and even on 2.6 kernels.

Filipe

-----Original Message-----
From: ext Scott Wood [mailto:scottwood at freescale.com] 
Sent: quarta-feira, 30 de Abril de 2008 16:01
To: Franca, Jose (NSN - PT/Portugal - MiniMD)
Cc: linuxppc-dev at ozlabs.org; linuxppc-embedded at ozlabs.org
Subject: Re: SKB corruption on heavy traffic

On Wed, Apr 30, 2008 at 09:43:33AM +0100, Franca, Jose (NSN -
PT/Portugal - MiniMD) wrote:
> 	It't quite dificult to say if the problem exists without our
> 	changes, since the all software is dependent on this changes so
> 	to work with the hardware. I can't answer to that right now on
> 	that, but I forgot to add one thing: we have ring buffer full
> 	problems on our fcc_enet driver from time to time. So, I think
> 	the problem could be on linux configurations (related to hw)
> 	because there is a lot of posts on the web related to problems
> 	similar to this (none of them has really solved the bottom
> 	problem).

One thing you could try is to enable slab debugging, rather than your
custom debugging code; this will poison the memory upon free, making it
more likely that whatever is accessing it will crash immediately rather
than just cause corruption.  Or, if you want to mantain the delay, do
the
poisoning yourself.

Of course, this won't help if the access is write-only, or if the
corruption is happening via DMA.

When you say you have a full ring buffer, do you mean tx or rx?  Does it
recover gracefully?  Do you think it's caused by something other than
sending data faster than the line can support (tx) or receiving packets
faster than the cpu can handle (rx)?

Are any of the other problem reports from recent, unmodified kernels
(2.4
is very old)?

-Scott