search for: futex

xend crashes at startup with following stack trace: ... File "/usr/lib64/python/xen/xend/XendPIF.py", line 68, in linux_get_phy_ifaces phy_ifaces.append((name, int(mtu), bridged_mac)) UnboundLocalError: local variable ''bridged_mac'' referenced before assignment The simple patch attached below prevent the crash, and allow xend to start normally. It seems the crash

Hi, i just want to ask whether somebody else has this problem of mine and if it can be solved. Many of my ( 30+ ) puppet installation freeze up after some time. The process is waiting for some private futex, but it stays like that forever. This is what strace looks like when the problem occures: [pid 29173] futex(0x3d35ce7a84, FUTEX_WAIT_BITSET_PRIVATE|FUTEX_CLOCK_REALTIME, 43406739, {1340611695, 739433265}, ffffffff) = -1 ETIMEDOUT (Connection timed out) [pid 29173] clock_gettime(CLOCK_REALTIME,...

...LL, {0, 1000}) = 0 (Timeout) select(0, NULL, NULL, NULL, {0, 2000}) = 0 (Timeout) select(0, NULL, NULL, NULL, {0, 4000}) = 0 (Timeout) select(0, NULL, NULL, NULL, {0, 8000}) = 0 (Timeout) select(0, NULL, NULL, NULL, {0, 16000}) = 0 (Timeout) select(0, NULL, NULL, NULL, {0, 32000}) = 0 (Timeout) futex(0x3bcc8c0, FUTEX_WAKE_PRIVATE, 1) = 1 futex(0x3bcc8c0, FUTEX_WAIT_BITSET_PRIVATE|FUTEX_CLOCK_REALTIME, 0, NULL, ffffffff) = 0 futex(0x3bcc8c0, FUTEX_WAIT_BITSET_PRIVATE|FUTEX_CLOCK_REALTIME, 0, NULL, ffffffff) = -1 EAGAIN (Resourc e temporarily unavailable)...

Vhost log dirty pages directly to a userspace bitmap through GUP and kmap_atomic() since kernel doesn't have a set_bit_to_user() helper. This will cause issues for the arch that has virtually tagged caches. The way to fix is to keep using userspace virtual address. Fortunately, futex has a cmpxchg to userspace memory helper futex_atomic_cmpxchg_inatomic(). So switch to use it to exchange the userspace bitmap with zero, set the bit and then write it back through put_user(). Note: there're archs (few non popular ones) that don't implement futex helper, we can't log d...

Vhost log dirty pages directly to a userspace bitmap through GUP and kmap_atomic() since kernel doesn't have a set_bit_to_user() helper. This will cause issues for the arch that has virtually tagged caches. The way to fix is to keep using userspace virtual address. Fortunately, futex has a cmpxchg to userspace memory helper futex_atomic_cmpxchg_inatomic(). So switch to use it to exchange the userspace bitmap with zero, set the bit and then write it back through put_user(). Note: there're archs (few non popular ones) that don't implement futex helper, we can't log d...

...NULL, NULL, {0, 2000}) = 0 (Timeout) >> select(0, NULL, NULL, NULL, {0, 4000}) = 0 (Timeout) >> select(0, NULL, NULL, NULL, {0, 8000}) = 0 (Timeout) >> select(0, NULL, NULL, NULL, {0, 16000}) = 0 (Timeout) >> select(0, NULL, NULL, NULL, {0, 32000}) = 0 (Timeout) >> futex(0x3bcc8c0, FUTEX_WAKE_PRIVATE, 1) = 1 >> futex(0x3bcc8c0, FUTEX_WAIT_BITSET_PRIVATE|FUTEX_CLOCK_REALTIME, 0, NULL, >> ffffffff) = 0 >> futex(0x3bcc8c0, FUTEX_WAIT_BITSET_PRIVATE|FUTEX_CLOCK_REALTIME, 0, NULL, >> ffffffff) = -1 EAGAIN (Resourc >> e temporarily unavailab...

..., F_OK) = -1 ENOENT (No such file or directory) access("/var/run/libvirt/libvirt-sock", F_OK) = 0 socket(AF_UNIX, SOCK_STREAM, 0) = 5 connect(5, {sa_family=AF_UNIX, sun_path="/var/run/libvirt/libvirt-sock"}, 110) = 0 getsockname(5, {sa_family=AF_UNIX}, [128 => 2]) = 0 futex(0x7fa716a672f0, FUTEX_WAKE_PRIVATE, 2147483647) = 0 fcntl(5, F_GETFD) = 0 fcntl(5, F_SETFD, FD_CLOEXEC) = 0 fcntl(5, F_GETFL) = 0x2 (flags O_RDWR) fcntl(5, F_SETFL, O_RDWR|O_NONBLOCK) = 0 futex(0x7fa716a67348, FUTEX_WAKE_PRIVATE, 2147483647)...

...igure out where the delay occurs using strace and ltrace, but that didn't help much. When running ltrace, the process I'm trying to trace (host, nslookup) just dies. And the output of strace does show a 3+ second delay, but I can't figure out what it's telling me: 10:46:25.317517 futex(0xd1ba94, FUTEX_WAKE_PRIVATE, 2147483647) = 0 10:46:25.317586 open("/usr/lib/locale/locale-archive", O_RDONLY|O_LARGEFILE) = 6 10:46:25.317635 fstat64(6, {st_mode=S_IFREG|0644, st_size=99158720, ...}) = 0 10:46:25.317702 mmap2(NULL, 2097152, PROT_READ, MAP_PRIVATE, 6, 0) = 0xb569d000 10:4...

...LL) = 0 stat64("/etc/localtime", {st_mode=S_IFREG|0644, st_size=1267, ...}) = 0 stat64("/etc/localtime", {st_mode=S_IFREG|0644, st_size=1267, ...}) = 0 stat64("/etc/localtime", {st_mode=S_IFREG|0644, st_size=1267, ...}) = 0 gettid() = 921 futex(0x81abca4, 0x5 /* FUTEX_??? */, 1) = 1 futex(0x8195988, FUTEX_WAKE, 1) = 1 futex(0x81abca4, 0x5 /* FUTEX_??? */, 1) = 1 futex(0x8195988, FUTEX_WAKE, 1) = 1 .open("/usr/lib/asterisk/modules/app_talkdetect.so", O_RDONLY) = 12 read(12, "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\...

The previously noted upgrade-to-4.4 recipe: yum update yum sqlite python-sqlite ; yum update worked more consistently than running "yum upgrade," but it too fell victim to the futex hang. In my limited testing, a reboot of the machine before starting the upgrade gave me a 100% success rate. Given two identical machines, one that had been used for a few days and one that was freshly rebooted, the former would exhibit a futex hang, while the latter updated just fine. Cheers...

...vent in start) passthrough_start ;; *) echo "qemu hook called with unexpected options $*" >&2 ;; esac ### starce libvirt: [root@localhost ~]# strace -f -p 14630 Process 14630 attached with 11 threads - interrupt to quit [pid 14640] futex(0xc34ebc, FUTEX_WAIT_PRIVATE, 2303, NULL <unfinished ...> [pid 14638] futex(0xc34ebc, FUTEX_WAIT_PRIVATE, 2303, NULL <unfinished ...> [pid 14637] futex(0xc34ebc, FUTEX_WAIT_PRIVATE, 2303, NULL <unfinished ...> [pid 14636] futex(0xc34ebc, FUTEX_WAIT_PRIVATE, 2303, NULL <unfinish...

On Mon, May 06, 2019 at 10:23:29PM -0400, Jason Wang wrote: > Note: there're archs (few non popular ones) that don't implement > futex helper, we can't log dirty pages. We can fix them on top or > simply disable LOG_ALL features of vhost. That means vhost now has to depend on HAVE_FUTEX_CMPXCHG to make sure we have a working implementation. > #include <linux/sched/signal.h> > #include <linux/interval_tre...

I'm occasionally seeing processes on my CentOS 4.3 system get hung up, which strace reveals to be waiting on a call to futex(). Previously I'd only ever seen this in mysql on RH9, and google searches for explanations haven't turned up anything useful. Any pointers to where I should look? Is this another one of those things where using the default SMP kernel with a hyperthreaded processor is just a Bad Idea?

Everyone, I have two x86_64 servers with CentOS 6.3 that seem to have some difficulty with the last version of bind : 32:bind-9.8.2-0.10.rc1.el6_3.2.x86_64 When I run htop I am getting a CPU usage of 70 to 80% all of the time. I am not seeing problems identified in the log files on either machine. This may have been present before the update of 9.8.2.0, but I certainly did not notice it. Has

Vhost log dirty pages directly to a userspace bitmap through GUP and kmap_atomic() since kernel doesn't have a set_bit_to_user() helper. This will cause issues for the arch that has virtually tagged caches. The way to fix is to keep using userspace virtual address. Fortunately, futex has arch_futex_atomic_op_inuser() which could be used for setting a bit to user. Note there're several cases that futex helper can fail e.g a page fault or the arch that doesn't have the support. For those cases, a simplified get_user()/put_user() pair protected by a global mutex is provid...

Vhost log dirty pages directly to a userspace bitmap through GUP and kmap_atomic() since kernel doesn't have a set_bit_to_user() helper. This will cause issues for the arch that has virtually tagged caches. The way to fix is to keep using userspace virtual address. Fortunately, futex has arch_futex_atomic_op_inuser() which could be used for setting a bit to user. Note there're several cases that futex helper can fail e.g a page fault or the arch that doesn't have the support. For those cases, a simplified get_user()/put_user() pair protected by a global mutex is provid...

...does not seem to be available in my build (1.7 release-asserts). Another question: does lli actually run the program ? I've cooked up a main function that would probably segfault it. And what i'm seeing (with strace) is that something does segfault (a child thread?) and lli is waiting on a futex: access("dump.bc", F_OK) = 0 open("dump.bc", O_RDONLY) = 3 fstat64(3, {st_mode=S_IFREG|0600, st_size=22744, ...}) = 0 mmap2(NULL, 24576, PROT_READ, MAP_PRIVATE, 3, 0) = 0xb7fe3000 mmap2(NULL, 16777216, PROT_READ|PROT_WRITE|PROT_EXEC, MAP_PRIVATE|MA...

On Tue, 20 Jun 2006, Chris Lattner wrote: > On Wed, 21 Jun 2006, Simon Burton wrote: >> This from the output: >> >> 24620 x86-emitter - Number of machine instructions emitted >> >> (i had to write a dummy main function to get this to work) >> >> Is this really the number of bytes of machine code ? > Yes. To be specific, this is the

Hello, I have found, that ocfs2 is very slow when doing I/O operation without cache. See a simple test: ng-vvv1:~# dd if=/data/verejna/dd-1G bs=1k | dd of=/dev/null 1048576+0 records in 1048576+0 records out 1073741824 bytes (1.1 GB) copied, 395.183 s, 2.7 MB/s 2097152+0 records in 2097152+0 records out 1073741824 bytes (1.1 GB) copied, 395.184 s, 2.7 MB/s The underlying block device is quite

...latest patch before 4.6) when I try to use it. "clean metadata" didn't help. The output of -d5 shows it gets to the point of "Reading Local RPMDB" and then sits there. The process doesn't die, but doesn't seem to do anything from that point on. strace shows this: futex(0xb76dcae8, FUTEX_WAIT, 2, NULL I remember that futex hangs have been mentioned in the past when doing "big" updates from 4.x to 4.y, but this wasn't the case here. python-2.3.4-14.4 python-sqlite-1.1.7-1.2.1 sqlite-3.3.6-2 yum-2.4.3-3.el4.centos Kernel in use is not the latest 4.5...