If interrupts are disabled long enough to allow for more than
32 frames to accumulate in the MAC's internal buffers, a buffer
overflow occurs. This patch fixes the problem by making the
driver's frame_head_info buffer bigger enough.
Signed-off-by: Davide Ciminaghi <redacted>
Signed-off-by: Raffaele Recalcati <redacted>
---
drivers/net/ethernet/micrel/ks8851_mll.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
From: Eric Dumazet <hidden> Date: 2012-03-27 14:39:36
Le mardi 27 mars 2012 à 15:01 +0200, Davide Ciminaghi a écrit :
quoted hunk
If interrupts are disabled long enough to allow for more than
32 frames to accumulate in the MAC's internal buffers, a buffer
overflow occurs. This patch fixes the problem by making the
driver's frame_head_info buffer bigger enough.
Signed-off-by: Davide Ciminaghi <redacted>
Signed-off-by: Raffaele Recalcati <redacted>
---
drivers/net/ethernet/micrel/ks8851_mll.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
Hi Eric,
On 07:39 Tue 27 Mar , Eric Dumazet wrote:
Le mardi 27 mars 2012 à 15:01 +0200, Davide Ciminaghi a écrit :
quoted
If interrupts are disabled long enough to allow for more than
32 frames to accumulate in the MAC's internal buffers, a buffer
overflow occurs. This patch fixes the problem by making the
driver's frame_head_info buffer bigger enough.
Signed-off-by: Davide Ciminaghi <redacted>
Signed-off-by: Raffaele Recalcati <redacted>
---
drivers/net/ethernet/micrel/ks8851_mll.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
You can see in ks_rcv function,
ks->frame_cnt = ks_rdreg16(ks, KS_RXFCTR) >> 8;
so "RXFC RX Frame Count" is a byte, maximum 256 total frames.
but we have the threshold ..
As you can see also in ks_setup the
/* Setup Receive Frame Threshold - 1 frame (RXFCTFC) */
ks_wrreg16(ks, KS_RXFCTR, 1 & RXFCTR_THRESHOLD_MASK);
In conclusion what happen is that if we stop system interrupts for a while,
when we are back the ks_rcv function starts reading the frames, and
the
while (ks->frame_cnt--) {
..
frame_hdr++;
}
loop goes out of the malloc'ed area.
We experienced so strange bugs in the last weeks that we are so happy that it seems fixed, but I need
some weeks to confirm it is robust enough.
The 'load setup' is like the following:
- nfs rootfs
- host $ sudo ping -f $TARGET_IP_ADDRESS
- host $ scp -r BIG_DIR user@$TARGET_IP_ADDRESS:
But I'm not sure to create the bug in a mathematical way, it seems to depend on packets on the corporate lan.
Surely if I stop with jtag and restart after some seconds I have buffer overflow, with same errors in ram that I
obtain randomically with 'load setup'.
Hoping it helps,
Raffaele
Ce message, ainsi que tous les fichiers joints à ce message,
peuvent contenir des informations sensibles et/ ou confidentielles
ne devant pas être divulguées. Si vous n'êtes pas le destinataire
de ce message (ou que vous recevez ce message par erreur), nous
vous remercions de le notifier immédiatement à son expéditeur, et
de détruire ce message. Toute copie, divulgation, modification,
utilisation ou diffusion, non autorisée, directe ou indirecte, de
tout ou partie de ce message, est strictement interdite.
This e-mail, and any document attached hereby, may contain
confidential and/or privileged information. If you are not the
intended recipient (or have received this e-mail in error) please
notify the sender immediately and destroy this e-mail. Any
unauthorized, direct or indirect, copying, disclosure, distribution
or other use of the material or parts thereof is strictly
forbidden.
From: Eric Dumazet <hidden> Date: 2012-03-28 07:39:57
On Wed, 2012-03-28 at 09:05 +0200, Raffaele Recalcati wrote:
Hi Eric,
On 07:39 Tue 27 Mar , Eric Dumazet wrote:
quoted
Le mardi 27 mars 2012 à 15:01 +0200, Davide Ciminaghi a écrit :
quoted
If interrupts are disabled long enough to allow for more than
32 frames to accumulate in the MAC's internal buffers, a buffer
overflow occurs. This patch fixes the problem by making the
driver's frame_head_info buffer bigger enough.
Signed-off-by: Davide Ciminaghi <redacted>
Signed-off-by: Raffaele Recalcati <redacted>
---
drivers/net/ethernet/micrel/ks8851_mll.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
You can see in ks_rcv function,
ks->frame_cnt = ks_rdreg16(ks, KS_RXFCTR) >> 8;
so "RXFC RX Frame Count" is a byte, maximum 256 total frames.
but we have the threshold ..
As you can see also in ks_setup the
/* Setup Receive Frame Threshold - 1 frame (RXFCTFC) */
ks_wrreg16(ks, KS_RXFCTR, 1 & RXFCTR_THRESHOLD_MASK);
In conclusion what happen is that if we stop system interrupts for a while,
when we are back the ks_rcv function starts reading the frames, and
the
while (ks->frame_cnt--) {
..
frame_hdr++;
}
loop goes out of the malloc'ed area.
We experienced so strange bugs in the last weeks that we are so happy that it seems fixed, but I need
some weeks to confirm it is robust enough.
The 'load setup' is like the following:
- nfs rootfs
- host $ sudo ping -f $TARGET_IP_ADDRESS
- host $ scp -r BIG_DIR user@$TARGET_IP_ADDRESS:
But I'm not sure to create the bug in a mathematical way, it seems to depend on packets on the corporate lan.
Surely if I stop with jtag and restart after some seconds I have buffer overflow, with same errors in ram that I
obtain randomically with 'load setup'.
Hoping it helps,
Sure it does.
So the limit should be 255, not 256.
(0xFFFF >> 8 -> 0xFF)
ks->frame_cnt = ks_rdreg16(ks, KS_RXFCTR) >> 8;
I cant see how 256 can be stored in a 8bit field ?
You see, explaining things in Changelog can actually help a lot, since
we now understand chip has this 8bit limit for the frame counter.
Thanks
On Wed, Mar 28, 2012 at 09:39:51AM +0200, Eric Dumazet wrote:
On Wed, 2012-03-28 at 09:05 +0200, Raffaele Recalcati wrote:
quoted
Hi Eric,
On 07:39 Tue 27 Mar , Eric Dumazet wrote:
quoted
Le mardi 27 mars 2012 ?? 15:01 +0200, Davide Ciminaghi a ??crit :
...
So the limit should be 255, not 256.
(0xFFFF >> 8 -> 0xFF)
ks->frame_cnt = ks_rdreg16(ks, KS_RXFCTR) >> 8;
I cant see how 256 can be stored in a 8bit field ?
you're right, we'll resend the patch with 255.
Well actually, since the chip appears to have 12K of internal rx buffers
and the shortest ethernet frame should be 64 bytes long, maybe the limit could
be set to 12*1024/64 = 192 frames, but I think 255 is safer.
Thanks and regards
Davide