On Tue, 2008-09-23 at 07:53 +0200, Erwin Authried wrote: > Am Montag, den 22.09.2008, 17:28 -0600 schrieb Matt Waddel: > > Hello, > > > > I've encountered an interesting problem with ping (both > > busybox and the regular ping) on the Coldfire platforms. > > After typing <control c> to end ping the 1st time, > > running ping the 2nd time only lets one packet get > > through. Ping seems to hang after the first packet. > > > > So the following sequence: > > > > # ping 192.168.1.100 > > PING 192.168.1.100 (192.168.1.100): 56 data bytes > > 64 bytes from 192.168.1.100: icmp_seq=0 ttl=64 time=10.0 ms > > 64 bytes from 192.168.1.100: icmp_seq=1 ttl=64 time=0.0 ms > > 64 bytes from 192.168.1.100: icmp_seq=2 ttl=64 time=0.0 ms > > 64 bytes from 192.168.1.100: icmp_seq=3 ttl=64 time=0.0 ms > > 64 bytes from 192.168.1.100: icmp_seq=4 ttl=64 time=0.0 ms > > 64 bytes from 192.168.1.100: icmp_seq=5 ttl=64 time=0.0 ms > > 64 bytes from 192.168.1.100: icmp_seq=6 ttl=64 time=0.0 ms > > ^C > > --- 192.168.1.100 ping statistics --- > > 7 packets transmitted, 7 packets received, 0% packet loss > > round-trip min/avg/max = 0.0/1.4/10.0 ms > > > > # ping 192.168.1.100 > > PING 192.168.1.100 (192.168.1.100): 56 data bytes > > 64 bytes from 192.168.1.100: icmp_seq=0 ttl=64 time=0.0 ms > > <<<<< wait a long time where nothing happens >>>>> > > ^C > > > > --- 192.168.1.100 ping statistics --- > > 1 packets transmitted, 1 packets received, 0% packet loss > > round-trip min/avg/max = 0.0/0.0/0.0 ms > > --------------------------------------------------------- > > > > If you set a limit to the number of ping packets using the > > command: ping -c 5 <ip addr> everything works fine - every > > time. (As long as you don't type <control c>.) > > > > Obviously the <control c> is leaving the ping/icmp system > > in a bad state somewhere. I'm using the 2.6.26 kernel, but > > I also saw the problem on the 2.6.23 kernel. Do any other > > platforms have this problem? Any ideas where to start > > looking? > > > > TIA, > > Matt > > Hi, > it seems that something is wrong with the signal handling in the ping > application. There should be a SIGALRM that triggers the next ping (at > least in the standalone ping). You should try to figure out if SIGALRM > is is working at all after you interrupt the application with ^C. >
Not sure if it's related but a long time ago there was a patch needed to prevent a problem with register overwrite with some gcc versions. The symptoms were the same: http://mailman.uclinux.org/pipermail/uclinux-dev/2005-November/035683.html If you look at the thread listing, there's some more around this time. Regards, Stuart _______________________________________________ uClinux-dev mailing list [email protected] http://mailman.uclinux.org/mailman/listinfo/uclinux-dev This message was resent by [email protected] To unsubscribe see: http://mailman.uclinux.org/mailman/options/uclinux-dev
