UPDATE.

Looks like we found a regression.

We used to have /etc/sysctl.conf:
vm.min_free_kbytes = 12288


We used to set this in our build script, but it might not have transitioned to the new image creation tools.

So I take everything back, leave the turbo_mode alone, and put back the minimum free memory.

Also, systemD ate my sysctl.conf  :(

Sorry for the noise.

-Jon Disnard


On Mon, Dec 10, 2012 at 1:30 PM, Jon <jdisnard@gmail.com> wrote:
Hello team :)

Panda-es, f18 beta 

Sometimes the board spews out lots and lots of these kevent 2 lines:

[root@panda-f18-v7hl ~]# dmesg | tail
[ 4325.019653] smsc95xx 1-1.1:1.0: eth0: kevent 2 may have been dropped
[ 4325.026367] smsc95xx 1-1.1:1.0: eth0: kevent 2 may have been dropped
[ 4325.033081] smsc95xx 1-1.1:1.0: eth0: kevent 2 may have been dropped
[ 4325.039764] smsc95xx 1-1.1:1.0: eth0: kevent 2 may have been dropped
...


Problem statement:
Those kernel logs look unhappy.

Impact statement:
AFAIK this might result in some dropped packets.

Steps to reproduce:
Every time, just use wget to fetch a large file. 
I grab an f17 iso from my local file server.
The console will start flooding the kevent, and the wget gets very unhappy.




Supposedly disabling turbo mode on the cmdline (uEnv.txt) would help:

smsc95xx.turbo_mode=N


I suppose turbo mode is some kind of interrupt throttling scheme? 
It might reduce throughput while increasing resiliency?


Tested with turbo disabled, and I did not see a significant reduction in throughput, or increased latency, but a dramatic increase in resiliency.
aka disabling turbo_mod stopped the kevent 2 problem.

I propose we make this default for panda and beagle.

Your thoughts?


--

-Jon Disnard
irc: masta
fas: parasense



--

-Jon