headers
isa_youssouf | 2 Jun 2009 16:54
Picon
Favicon

Good Day

Good Day 

I want to transfer the sum of Twelve Million Dollars (US$12.000,000) to your country and will need your
little cooperation. I will reward you with  reasonable amount. Please inform me as soon as possible if you
are interested. 

Regards  
Isa Youssouf

--
To unsubscribe from this list: send the line "unsubscribe linux-m68k" in
the body of a message to majordomo <at> vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Permalink | Reply | 0 comments |
headers
Jaswinder Singh Rajput | 4 Jun 2009 14:31

[PATCH 3/6] headers_check fix: m68k, swab.h


fix the following 'make headers_check' warnings:

  usr/include/asm-m68k/swab.h:4: include of <linux/types.h> is preferred over <asm/types.h>
  usr/include/asm-m68k/swab.h:10: found __[us]{8,16,32,64} type without #include <linux/types.h>

Signed-off-by: Jaswinder Singh Rajput <jaswinderrajput <at> gmail.com>
---
 arch/m68k/include/asm/swab.h |    2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/arch/m68k/include/asm/swab.h b/arch/m68k/include/asm/swab.h
index 9e3054e..5b754aa 100644
--- a/arch/m68k/include/asm/swab.h
+++ b/arch/m68k/include/asm/swab.h
 <at>  <at>  -1,7 +1,7  <at>  <at> 
 #ifndef _M68K_SWAB_H
 #define _M68K_SWAB_H

-#include <asm/types.h>
+#include <linux/types.h>
 #include <linux/compiler.h>

 #define __SWAB_64_THRU_32__
--

-- 
1.6.0.6

--
To unsubscribe from this list: send the line "unsubscribe linux-m68k" in
the body of a message to majordomo <at> vger.kernel.org
(Continue reading)

Permalink | Reply | 0 comments |
headers
Matthew Lear | 5 Jun 2009 17:15
Picon

2.6.29 & network stack strangeness

Hello all,

I'm running a 2.6.29 kernel on an MMU enabled m68k coldfire mcf54455 platform
and I'm having some throughput problems when running network tests.

The kernel boots and mounts its rootfs from flash (jffs2). udhcpc runs, obtains
a lease from the dhcp server and configures eth0. Network connectivity is ok. I
can ping the target from the host and vice versa.

1/
If I run ping -s 1500 -i 0.0001 <target ip address> on the host pc, after
several mins, the kernel reports 'unexpected interrupt from 24' which is the
vector for a spurious interrupt. This message will repeat randomly (from what I
saw it appeared ~ 20 times when running the ping test above for 40 mins). The
mcf54455 reference manual describes a possible cause for spurious interrupts.
However, this test very rarely reports any packet loss, although the max time to
receive a packet can be very large indeed.

2/
If I reboot, start again and run a ping flood test (ping -f) from host pc ->
target, all icmp requests are acknowledged - for a while. Before the target
begins to fail to respond to the icmp requests, running top shows that the
ksoftirq daemon is running at ~ 5% cpu load. This is normal as it is involved in
processing the deferred tasks of processing data fired up to the network stack.
So when the target beings to stop responding to icmp, if I then stop the ping
flood and try to ping the host from the target, there is no reply indicated by
ping. However, if you do this with a packet sniffer running (eg wireshark) you
can see that data is still being transmitted from the target -> host and you can
see the icmp reply, only the reply from the host appears to be received ok by
the fec driver but is processed by the network stack target.
(Continue reading)

Permalink | Reply | 4 comments |
headers
Finn Thain | 5 Jun 2009 17:49
Picon
Favicon

Re: 2.6.29 & network stack strangeness


Does the problem manifest only when the DHCP lease expires?
Can you reproduce the problem with a static IP?

Finn

On Fri, 5 Jun 2009, Matthew Lear wrote:

> Hello all,
> 
> I'm running a 2.6.29 kernel on an MMU enabled m68k coldfire mcf54455 platform
> and I'm having some throughput problems when running network tests.
> 
> The kernel boots and mounts its rootfs from flash (jffs2). udhcpc runs, obtains
> a lease from the dhcp server and configures eth0. Network connectivity is ok. I
> can ping the target from the host and vice versa.
> 
> 1/
> If I run ping -s 1500 -i 0.0001 <target ip address> on the host pc, after
> several mins, the kernel reports 'unexpected interrupt from 24' which is the
> vector for a spurious interrupt. This message will repeat randomly (from what I
> saw it appeared ~ 20 times when running the ping test above for 40 mins). The
> mcf54455 reference manual describes a possible cause for spurious interrupts.
> However, this test very rarely reports any packet loss, although the max time to
> receive a packet can be very large indeed.
> 
> 2/
> If I reboot, start again and run a ping flood test (ping -f) from host pc ->
> target, all icmp requests are acknowledged - for a while. Before the target
> begins to fail to respond to the icmp requests, running top shows that the
(Continue reading)

Permalink | Reply | 3 comments |
headers
Matthew Lear | 5 Jun 2009 18:17
Picon

Re: 2.6.29 & network stack strangeness

Hi - thanks for your reply.

The problem doesn't manifest only when the DHCP lease expires and I can still
reproduce the problem with a static IP. With or without DHCP makes no difference.

It seems to effect socket comms quite seriously (and quickly). If I run a simple
server program on the host that listens on a socket and writes a response string
to the socket when it receives data, and on the target I run a simple client
program which writes a string to the socket, reads and prints the response sent
the server, I only have to send data from client to server with a delay of 1ms
between transmissions for a few seconds and the client program hangs on calling
read() on the socket fd.

If I run a simple netcat test, eg

on target: nc -l -p 3333 > /dev/null
on host: dd if=/dev/zero | nc <target-ip> 3333

...strangely, once activity on the ethernet link as a result of the netcat test
ceases, running netstat -a on the target hangs for several seconds, eg:

~ # nc -l -p 3333 > /dev/null &
~ # netstat -a
Active Internet connections (servers and established)
Proto Recv-Q Send-Q Local Address           Foreign Address         State
tcp        0      0 *:login                 *:*                     LISTEN
tcp        0      0 *:shell                 *:*                     LISTEN
tcp        0      0 *:sunrpc                *:*                     LISTEN
tcp        0      0 *:finger                *:*                     LISTEN
tcp        0      0 *:auth                  *:*                     LISTEN
(Continue reading)

Permalink | Reply | 2 comments |
headers
Finn Thain | 5 Jun 2009 18:37
Picon
Favicon

Re: 2.6.29 & network stack strangeness


My only guess would be that the network stack delayed work queues depend 
upon working timer interrupts...

But since I have no knowledge of your hardware, I don't think I'll be a 
lot of help with that.

Finn

On Fri, 5 Jun 2009, Matthew Lear wrote:

> Hi - thanks for your reply.
> 
> The problem doesn't manifest only when the DHCP lease expires and I can still
> reproduce the problem with a static IP. With or without DHCP makes no difference.
> 
> It seems to effect socket comms quite seriously (and quickly). If I run a simple
> server program on the host that listens on a socket and writes a response string
> to the socket when it receives data, and on the target I run a simple client
> program which writes a string to the socket, reads and prints the response sent
> the server, I only have to send data from client to server with a delay of 1ms
> between transmissions for a few seconds and the client program hangs on calling
> read() on the socket fd.
> 
> If I run a simple netcat test, eg
> 
> on target: nc -l -p 3333 > /dev/null
> on host: dd if=/dev/zero | nc <target-ip> 3333
> 
> ...strangely, once activity on the ethernet link as a result of the netcat test
(Continue reading)

Permalink | Reply | 1 comment |
headers
Matthew Lear | 5 Jun 2009 18:44
Picon

Re: 2.6.29 & network stack strangeness

Yes. I was suspecting that all may not be well in that area... Current set up is
a 10ms tick with CONFIG_HZ set to 100. Further investigation is required I think.
--  Matt

Finn Thain wrote:
> My only guess would be that the network stack delayed work queues depend 
> upon working timer interrupts...
> 
> But since I have no knowledge of your hardware, I don't think I'll be a 
> lot of help with that.
> 
> Finn
> 
> 
> On Fri, 5 Jun 2009, Matthew Lear wrote:
> 
>> Hi - thanks for your reply.
>>
>> The problem doesn't manifest only when the DHCP lease expires and I can still
>> reproduce the problem with a static IP. With or without DHCP makes no difference.
>>
>> It seems to effect socket comms quite seriously (and quickly). If I run a simple
>> server program on the host that listens on a socket and writes a response string
>> to the socket when it receives data, and on the target I run a simple client
>> program which writes a string to the socket, reads and prints the response sent
>> the server, I only have to send data from client to server with a delay of 1ms
>> between transmissions for a few seconds and the client program hangs on calling
>> read() on the socket fd.
>>
>> If I run a simple netcat test, eg
(Continue reading)

Permalink | Reply | 0 comments |
headers
NTNU.EDU.TW邮局Uprade队 | 5 Jun 2009 21:00
Picon

&#35242;&#24859;&#30340;NTNU.EDU.TW Webmail&#24115;&#25142;&#30340; &#29992;&#25142;


&#35242;&#24859;&#30340;NTNU.EDU.TW
Webmail&#24115;&#25142;&#30340;&#29992;&#25142;,
 &#27492;&#28040;&#24687;&#26159;&#24418;&#24335;NTNU.EDU.TW&#38651;&#37109;&#36890;&#35338;&#20013;&#24515;&#21521;&#25152;&#26377;NTNU.EDU.TW
Webmail&#24115;&#25142;&#30340;&#29992;&#25142;,&#25105;&#20497;&#24456;&#25265;&#27465;&#36896;&#25104;&#24744;&#30340;&#19981;&#20415;,&#25105;&#20497;&#35731;&#20320;&#36890;&#36942;,&#25105;&#20497;&#26377;&#21839;&#38988;,&#25105;&#20497;&#30340;&#25976;&#25818;&#24235;&#20013;,&#30001;&#26044;&#25105;&#20497;&#26368;&#36817;&#30340;&#21319;&#32026;&#21644;&#25105;&#20497;&#28961;&#27861;&#25214;&#21040;&#24744;&#30340;&#25976;&#25818;&#12290;
   &#35531;&#24744;&#29702;&#35299;,&#25105;&#20497;&#24517;&#38920;&#31435;&#21363;&#31998;&#27491;&#36889;&#19968;&#21839;&#38988;,&#20854;&#20182;&#19968;&#20999;,&#24744;&#21487;&#33021;&#28961;&#27861;&#30332;&#36865;&#25110;&#25509;&#25910;&#38651;&#23376;&#37109;&#20214;&#33287;&#24744;&#30340;NTNU.EDU.TW
Webmail&#24115;&#25142;E - mail&#22320;&#22336;&#12290;
  &#35531;&#25552;&#20379;&#24744;&#30340;&#24115;&#25142;,&#19979;&#38754;&#35443;&#32048;&#35498;&#26126;,&#20197;&#20415;&#25105;&#20497;&#33021;&#22816;&#31998;&#27491;&#36889;&#19968;&#21839;&#38988;&#30433;&#24555;:
&#29992;&#25142;&#21517;: (*********)
&#23494;&#30908;: *********)
&#20986;&#29983;&#26085;&#26399;(&#20986;&#29983;&#26085;&#26399;)*********)
&#22283;&#23478;*********)
  **&#27880;**
:&#24744;&#30340;&#25976;&#25818;&#21644;&#20449;&#24687;&#23559;&#19981;&#26371;&#34987;&#31713;&#25913;&#25110;&#24178;&#25854;,&#25105;&#20497;&#23601;&#26371;&#35352;&#37636;&#24744;&#30340;&#25976;&#25818;&#20633;&#20221;&#21040;&#25105;&#20497;&#30340;&#25976;&#25818;&#24235;,&#20006;&#23492;&#32102;&#24744;&#19968;&#20491;&#26032;&#30340;&#30906;&#35469;&#23383;&#27597;&#25976;&#23383;&#28151;&#21512;&#23494;&#30908;,&#21482;&#26371;&#26377;&#25928;,&#22312;&#27492;&#26399;&#38291;,&#21487;&#25913;&#35722;&#24744;&#30340;&#21839;&#38988;&#24460;,&#24050;&#24471;&#21040;&#31998;&#27491;&#12290;
&#27880;&#24847;&#20107;&#38917;:
  &#27794;&#26377;&#21521;&#25105;&#20497;&#25552;&#20379;&#19978;&#36848;&#24517;&#35201;&#26781;&#20214;&#30433;&#21487;&#33021;&#30701;&#30340;&#26178;&#38291;&#20839;&#37117;&#23559;&#23566;&#33268;&#22833;&#25943;&#30340;&#20837;&#31449;&#21644;&#20986;&#31449;&#30340;email.This&#23559;&#38459;&#27490;&#24744;&#30332;&#36865;&#25110;&#25509;&#25910;&#38651;&#23376;&#37109;&#20214;&#12290;
 &#35531;&#24171;&#21161;&#20659;&#25773;&#36889;&#20491;&#37325;&#35201;&#30340;&#20449;&#24687;&#36681;&#30332;&#32102;&#20854;&#20182;&#29992;&#25142;&#12290;
&#24863;&#35613;&#24744;&#29702;&#35299;&#25105;&#20497;&#30340;&#22256;&#22659;&#12290;
® NTNU.EDU.TW&#37109;&#23616;&#23458;&#25142;&#38364;&#20418;&#12290;
                      &#29256;&#27402;&#25152;&#26377;©
2009&#24180;&#12290;&#20445;&#30041;&#25152;&#26377;&#27402;&#21033;&#12290;
=====================================================================
&#20146;&#29233;&#30340;NTNU.EDU.TW
Webmail&#24080;&#25143;&#30340;&#29992;&#25143;,
 &#27492;&#28040;&#24687;&#26159;&#24418;&#24335;NTNU.EDU.TW&#30005;&#37038;&#36890;&#35759;&#20013;&#24515;&#21521;&#25152;&#26377;NTNU.EDU.TW
Webmail&#24080;&#25143;&#30340;&#29992;&#25143;,&#25105;&#20204;&#24456;&#25265;&#27465;&#36896;&#25104;&#24744;&#30340;&#19981;&#20415;,&#25105;&#20204;&#35753;&#20320;&#36890;&#36807;,&#25105;&#20204;&#26377;&#38382;&#39064;,&#25105;&#20204;&#30340;&#25968;&#25454;&#24211;&#20013;,&#30001;&#20110;&#25105;&#20204;&#26368;&#36817;&#30340;&#21319;&#32423;&#21644;&#25105;&#20204;&#26080;&#27861;&#25214;&#21040;&#24744;&#30340;&#25968;&#25454;&#12290;
   &#35831;&#24744;&#29702;&#35299;,&#25105;&#20204;&#24517;&#39035;&#31435;&#21363;&#32416;&#27491;&#36825;&#19968;&#38382;&#39064;,&#20854;&#20182;&#19968;&#20999;,&#24744;&#21487;&#33021;&#26080;&#27861;&#21457;&#36865;&#25110;&#25509;&#25910;&#30005;&#23376;&#37038;&#20214;&#19982;&#24744;&#30340;NTNU.EDU.TW
Webmail&#24080;&#25143;E - mail&#22320;&#22336;&#12290;
  &#35831;&#25552;&#20379;&#24744;&#30340;&#24080;&#25143;,&#19979;&#38754;&#35814;&#32454;&#35828;&#26126;,&#20197;&#20415;&#25105;&#20204;&#33021;&#22815;&#32416;&#27491;&#36825;&#19968;&#38382;&#39064;&#23613;&#24555;:
&#29992;&#25143;&#21517;: (*********)
(Continue reading)

Permalink | Reply | 0 comments |
headers
Matthew Lear | 9 Jun 2009 12:04
Picon

Re: 2.6.29 & network stack strangeness


> Could you run "top" command and print out its information?
> "cat /proc/stat" && "cat /proc/interrupts" information are also
> appreciated.

Sure. Info below.

Before running netcat test:

top - 00:02:37 up 2 min,  1 user,  load average: 0.07, 0.07, 0.02
Tasks:  24 total,   1 running,  23 sleeping,   0 stopped,   0 zombie
Cpu(s):  0.7%us,  0.0%sy,  0.0%ni, 98.7%id,  0.0%wa,  0.7%hi,  0.0%si, 
0.0%st
Mem:    254912k total,     6680k used,   248232k free,        0k buffers
Swap:        0k total,        0k used,        0k free,     3008k cached

  PID USER      PR  NI  VIRT  RES  SHR S %CPU %MEM    TIME+  COMMAND
  359 root      20   0  2856 1160  944 R  1.0  0.5   0:01.49 top
    3 root      15  -5     0    0    0 S  0.3  0.0   0:00.11 ksoftirqd/0
    1 root      20   0  3280  776  656 S  0.0  0.3   0:01.46 init
    2 root      15  -5     0    0    0 S  0.0  0.0   0:00.00 kthreadd
    4 root      RT  -5     0    0    0 S  0.0  0.0   0:00.00 watchdog/0
    5 root      15  -5     0    0    0 S  0.0  0.0   0:00.00 events/0
    6 root      15  -5     0    0    0 S  0.0  0.0   0:00.06 khelper
   56 root      15  -5     0    0    0 S  0.0  0.0   0:00.00 kblockd/0
   62 root      15  -5     0    0    0 S  0.0  0.0   0:00.00 kseriod
   80 root      20   0     0    0    0 S  0.0  0.0   0:00.00 pdflush
   81 root      20   0     0    0    0 S  0.0  0.0   0:00.00 pdflush
   82 root      15  -5     0    0    0 S  0.0  0.0   0:00.00 kswapd0
   83 root      15  -5     0    0    0 S  0.0  0.0   0:00.00 aio/0
(Continue reading)

Permalink | Reply | 0 comments |
headers
Matthew Lear | 10 Jun 2009 11:36
Picon

Re: 2.6.29 & network stack strangeness

Lanttor wrote:
> I met the interrupt issue before on mcf5445x platform, following is my fixed patch, but I am not sure it
could help resolve your problem, just have a try  :-) 

Thanks but this makes no difference. From what I can tell, the patch to entry.S
is essentially benign because ret_from_interrupt() is not invoked anywhere.

Also, the patch to ints.c adds invocations of irq_enter() and irq_exit()
to process_int(). These macros really just force entry/exit to/from hard
interrupt context and increment/decrement a count (used for tracking
nested interrupts). Given that process_int() is called by inthandler() in
entry.S, I think this is always going to be in interrupt context anyway, so I
can't see the advantage of this. Maybe I'm missing something?

> 
> For your mcf54455 platform, if you use one ether net port, try to disable second ether net port (FEC2) on the
menuconfig to see whether it would affect the net working. 

Yes. I've already got the second net port disabled.

I have had some level of success by calling flush_cache_all() immediately after
calling netif_rx() in the rx part of the fec interrupt handler - fec_enet_rx()
in fec.c.

This plus a hack to netif_rx() seems to vastly improve things in that I can wget
large files, run netcat tests although in the cast of netcat there is still a
high number of rx overruns in the fec driver.

Hack:
(Continue reading)

Permalink | Reply | 0 comments |

Gmane