search for: 999ms

i am hoping this attachment gets through. It deals with bug in ping that made it very difficult to set up a system with two gateways. -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.centos.org/pipermail/centos/attachments/20091009/ddfc8176/attachment-0004.html> -------------- next part -------------- An HTML attachment was scrubbed... URL:

...ng # ping localhost PING localhost (127.0.0.1) 56(84) bytes of data. 64 bytes from localhost (127.0.0.1): icmp_seq=1 ttl=64 time=0.077 ms 64 bytes from localhost (127.0.0.1): icmp_seq=2 ttl=64 time=0.066 ms ^C --- localhost ping statistics --- 2 packets transmitted, 2 received, 0% packet loss, time 999ms rtt min/avg/max/mdev = 0.066/0.071/0.077/0.010 ms Yes you are right, chown removed capabilities, but ping still works properly. -- Dariusz Michaluk Samsung R&D Institute Poland Samsung Electronics d.michaluk@samsung.com

...BOVE THIS LINE -- DO NOT REMOVE Ping results: [root@xstone ~]# ping -c 2 10.0.0.2 PING 10.0.0.2 (10.0.0.2) 56(84) bytes of data. ping: sendmsg: Operation not permitted ping: sendmsg: Operation not permitted --- 10.0.0.2 ping statistics --- 2 packets transmitted, 0 received, 100% packet loss, time 999ms [root@xstone ~]# /etc/init.d/shorewall stop Shutting down shorewall: [ OK ] [root@xstone ~]# ping -c 2 10.0.0.2 PING 10.0.0.2 (10.0.0.2) 56(84) bytes of data. 64 bytes from 10.0.0.2: icmp_seq=0 ttl=255 time=1.74 ms 64 bytes from 10.0.0.2: icmp_seq=1 ttl=255 time=...

...an ping itself: # ping 68.15.6.136 PING 68.15.6.136 (68.15.6.136) 56(84) bytes of data. 64 bytes from 68.15.6.136: icmp_seq=0 ttl=64 time=0.056 ms 64 bytes from 68.15.6.136: icmp_seq=1 ttl=64 time=0.021 ms --- 68.15.6.136 ping statistics --- 2 packets transmitted, 2 received, 0% packet loss, time 999ms rtt min/avg/max/mdev = 0.021/0.038/0.056/0.018 ms, pipe 2 can't ping the gateway: # ping 68.15.6.129 PING 68.15.6.129 (68.15.6.129) 56(84) bytes of data. From 68.15.6.136 icmp_seq=0 Destination Host Unreachable bounce the interface: # ifconfig eth2 down # ifconfig eth2 up now it works: #...

...P phones with g.711) -Digium TE110p (has it's own interrupt) -echocancel = yes (have also tried 32, 64, 128, 256; 128 works best so far) -echotraining = 400 (have also tried 200, 400, 800; seems to have no effect, the wiki says the max is higher but asterisk does not like anything higher than 999ms) -Asterisk Ver. 1.0.7 running on P4 3.0Ghz with 2Gb ram and Asus p4p800 mb E&M takes some time for call setup, is Asterisk's echo canceller training during this time? If so would switching to PRI alleviate the problem? Thanks for any help you can offer, -Bill Lattner

...61 ~]# ping 192.168.0.160 PING 192.168.0.160 (192.168.0.160) 56(84) bytes of data. 64 bytes from 192.168.0.160: icmp_seq=1 ttl=64 time=0.298 ms 64 bytes from 192.168.0.160: icmp_seq=2 ttl=64 time=0.278 ms --- 192.168.0.160 ping statistics --- 2 packets transmitted, 2 received, 0% packet loss, time 999ms rtt min/avg/max/mdev = 0.278/0.288/0.298/0.010 ms [root@192-168-0-161 ~]# telnet 192.168.0.160 5038 Trying 192.168.0.160... telnet: connect to address 192.168.0.160: No route to host telnet: Unable to connect to remote host: No route to host [root@192-168-0-161 ~]# Thanks, David Ruggles CCNA MCSE...

...OMAIN nikola var # ping nikola PING nikola (127.0.1.1) 56(84) bytes of data. 64 bytes from nikola (127.0.1.1): icmp_seq=1 ttl=64 time=0.033 ms 64 bytes from nikola (127.0.1.1): icmp_seq=2 ttl=64 time=0.032 ms ^C --- nikola ping statistics --- 2 packets transmitted, 2 received, 0% packet loss, time 999ms rtt min/avg/max/mdev = 0.032/0.032/0.033/0.005 ms nikola var # ping nikola.ozco.home ping: unknown host nikola.ozco.home nikola var # dig --help Invalid option: --help Usage: dig [@global-server] [domain] [q-type] [q-class] {q-opt} {global-d-opt} host [@local-server] {local-d-opt}...

...localhost (127.0.0.1) 56(84) bytes of data. > 64 bytes from localhost (127.0.0.1): icmp_seq=1 ttl=64 time=0.077 ms > 64 bytes from localhost (127.0.0.1): icmp_seq=2 ttl=64 time=0.066 ms > ^C > --- localhost ping statistics --- > 2 packets transmitted, 2 received, 0% packet loss, time 999ms > rtt min/avg/max/mdev = 0.066/0.071/0.077/0.010 ms > > Yes you are right, chown removed capabilities, but ping still works > properly. try it as user and not as root # su -s/bin/bash nobody -c 'ping localhost' ping: icmp open socket: Operation not permitted fix this from out...

...bservices# ping 192.168.98.1 PING 192.168.98.1 (192.168.98.1) 56(84) bytes of data. 64 bytes from 192.168.98.1: icmp_req=1 ttl=64 time=0.058 ms 64 bytes from 192.168.98.1: icmp_req=2 ttl=64 time=0.038 ms ^C --- 192.168.98.1 ping statistics --- 2 packets transmitted, 2 received, 0% packet loss, time 999ms rtt min/avg/max/mdev = 0.038/0.048/0.058/0.010 ms root at web-services:/etc/tinc/webservices# ping 192.168.98.2 PING 192.168.98.2 (192.168.98.2) 56(84) bytes of data. ^C --- 192.168.98.2 ping statistics --- 4 packets transmitted, 0 received, 100% packet loss, time 2999ms What am I missing here? T...

...15 PING 83.111.196.59 (83.111.196.59) from 85.234.115.115 : 56(84) bytes of data. 64 bytes from 83.111.196.59: icmp_seq=1 ttl=57 time=149 ms 64 bytes from 83.111.196.59: icmp_seq=2 ttl=57 time=158 ms --- 83.111.196.59 ping statistics --- 2 packets transmitted, 2 received, 0% packet loss, time 999ms rtt min/avg/max/mdev = 149.200/153.985/158.771/4.801 ms [root@stripe ~]# ping 83.111.196.60 -I 85.234.115.115 PING 83.111.196.60 (83.111.196.60) from 85.234.115.115 : 56(84) bytes of data. --- 83.111.196.60 ping statistics --- 4 packets transmitted, 0 received, 100% packet loss, time 2999ms...

Hi! I with my colleagues from Samsung trying to run systemd in Linux container. I saw that the others are experimenting in this topic, so I would like to present the results of my work and tests, perhaps it will be helpful to others. As the prototype I used a manual written by Daniel: https://www.berrange.com/posts/2013/08/12/running-a-full-fedora-os-inside-a-libvirt-lxc-guest/ After many

caching_thread()s do all their work under read access to extent_commit_sem. They give up on this read access only when need_resched() tells them, or when they exit. As a result, somebody that wants a WRITE access to this sem, might wait for a long time. Especially this is problematic in cache_block_group(), which can be called on critical paths like find_free_extent() and in commit path via