Re: KS8695: possible NAPI issue

[Yegor Yefremov <yegorslists@googlemail.com>]

On Tue, Mar 9, 2010 at 2:50 AM, figo zhang <figo1802@gmail.com> wrote:
> 2010/3/8 Yegor Yefremov <yegorslists@googlemail.com>:
>> This is ping afterwards:
>>
>> debian:~# ping -c 1 192.168.1.38
>>
>> PING 192.168.1.38 (192.168.1.38) 56(84) bytes of data.
>>
>>
>>  tx   ram addr = c371c202 , data len = 62
>>
>>  dst:00:18:f3:fe:84:84 src:00:04:d9:80:94:cd type: 0x0800
>
> => the print info is not clear, it had better just keep "print_mem()",
> and remove other printk.
>
>>
>>  0xc371c20e : 45 00
>>
>>  0xc371c212 : 00 54 00 00 40 00 40 01 b6 f0 c0 a8 01 42 c0 a8
>>
>>  0xc371c222 : 01 26 08 00 65 51 1a 07 00 01 92 00 95 4b 5f 57
>>
>>  0xc371c232 : 07 00 08 09 0a 0b 0c 0d 0e 0f 10 11 12 13 14 15
>>
>>  0xc371c242 : 16 17 18 19 1a 1b 1c 1d 1e 1f 20 21 22 23 24 25
>>
>>  0xc371c252 : 26 27 28 29 2a 2b 2c 2d 2e 2f 30 31 32 33 34 35
>>
>>  0xc371c262 : 36 37
>>
>>
>>
>>  tx   ram addr = c371c202 , data len = 2a
>>
>>  dst:00:18:f3:fe:84:84 src:00:04:d9:80:94:cd type: 0x0806
>>
>>  0xc371c20e : 00 01
>>
>>  0xc371c212 : 08 00 06 04 00 01 00 04 d9 80 94 cd c0 a8 01 42
> => it is a send arp packet, "c0 a8 01 42" is your curr ip addr
> 192.168.1.66, tell the other side it's ip addr.
>>
>>  0xc371c222 : 00 00 00 00 00 00 c0 a8 01 26
>>
>>
>>
>>  rx   ram addr = c35d2020 , data len = 3c
>>
>>  dst:00:04:d9:80:94:cd src:00:18:f3:fe:84:84 type: 0x0806
>>
>>  0xc35d202c : 00 01
>>
>>  0xc35d2030 : 08 00 06 04 00 02 00 18 f3 fe 84 84 c0 a8 01 26
>
> => it is a reply arp packet, "c0 a8 01 26" (192.168.1.38 ) is other
> side ip addr. so the arp
> request is finished.
>
>>
>>  0xc35d2040 : 00 04 d9 80 94 cd c0 a8 01 42 00 00 00 00 00 00
>>
>>  0xc35d2050 : 00 00 00 00 00 00 00 00 00 00 00 00
>>
> => so , it should still send  "IMCP" packet, you using "ping -c 1", it
> send one IMCP packet , and wait for reply.  at this point, it have not
> send packet?

I made some tests on Fr with a Netbook connected directly to our
ks8695 based device and not to the companies network. During the test
I couldn't encounter any problem. Than I connected ks8695 again to the
companies network and the issue was there right away. So I decided to
check how many broadcast I get and it turned out that I have one
device on the network that is sending broadcast almost every second if
not more frequent. It turned out that the network on ks8695 was not
completely down, but very slow and many packets got lost. As soon as I
removed the broadcast sending device I could ping ks8695. The
consequences:

1. as long as I make no netcat transfer, the network responses are as
usual regardless of many broadcasts
2. if during netcat a broadcast occurs, than the network is getting
slow, so that if during a constant ping you get a broadcast that ping
response gets lost

Any idea how broadcast during transfer could affect NAPI in that way?

Regards,
Yeor