Message-ID: <AANLkTimiTiF4mbV-aeOymHEn4BhY743UcHfCcVYim3Ec@mail.gmail.com>
Date:	Wed, 4 Aug 2010 16:40:09 +0200
From:	Yegor Yefremov <yegorslists@...glemail.com>
To:	figo zhang <figo1802@...il.com>
Cc:	Dick Hollenbeck <dick@...tplc.com>, netdev@...r.kernel.org,
	zealcook@...il.com
Subject: Re: KS8695: possible NAPI issue

On Mon, Mar 15, 2010 at 11:19 AM, Yegor Yefremov
<yegorslists@...glemail.com> wrote:
> On Tue, Mar 9, 2010 at 2:50 AM, figo zhang <figo1802@...il.com> wrote:
>> 2010/3/8 Yegor Yefremov <yegorslists@...glemail.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?

Tried 2.6.35. Have still the same problems. Another observation:

if I add eth0 to a bridge (br0), then I have no problems. So ks8695
network driver is still involved, but the upper level seems to make
the difference.

Any idea?

Regards,
Yegor
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Powered by blists - more mailing lists