similar to: A bug in Xenbus driver

Hello, This patch allows userspace tools on a domU to setup a watch on the xenstore. It does this by intercepting XS_WATCH requests written to /proc/xen/xenbus and then re-submitting the request to the in-kernel xenstore interface, in linux-2.6-xen-sparse/drivers/xen/xenbus/xenbus_xs.c. When a callback occurs, an in-kernel function is invoked, which then reconstructs a response in the format

A pair of patches to the xenstore library that: 1) blocks signal delivery before creating the watch wakeup thread 2) reduces the stack size of the watch wakeup thread.

Hi ----------------ursprüngliche Nachricht----------------- Von: "Michal Privoznik" mprivozn@redhat.com An: "web2" ustermann78@web.de , "libvirt-users redhat.com" , "libvirt-list redhat.com" Datum: Wed, 01 Oct 2014 18:12:45 +0200 ------------------------------------------------- > On 01.10.2014 10:31, web2 wrote: >> Hello, >> >>

On Wed, 2014-10-29 at 17:36 -0400, Gedalya wrote: > When booting domU's running amd64 jessie, I notice some memory problems > with xl. I ran it (actually, upstream staging-4.4) under valgrind and it reported after a reboot: ==5722== 24 bytes in 1 blocks are definitely lost in loss record 35 of 72 ==5722== at 0x4026B2D: malloc (vg_replace_malloc.c:299) ==5722== by 0x41739FF:

Hello, sorry for my later answer. so, after i started libvirtd (no vm´s running) and attach gdb i get the following threads (gdb) info thread Id Target Id Frame 11 Thread 0x7f18fef4e700 (LWP 20695) "libvirtd" pthread_cond_wait@@GLIBC_2.3.2 () at ../nptl/sysdeps/unix/sysv/linux/x86_64/pthread_cond_wait.S:185 10 Thread 0x7f18fe74d700 (LWP 20696) "libvirtd"

Hi Michal, thank you for your answer. so if i understand that correctly, no matter if i shutdown or destroy the domain and no matter if it is a transient or an persistent vm, the thread should disappear, right? in my case they still exist, also an hour after i destroy the domain (and don´t start any new one). i use libvirt-1.1.35 on fedora core 20, for information. all the best max    

Coverity generates false positives when read_atomic() and write_atomic() are called with pointers to objects smaller than 64 bits (because it can''t see that the 64-bit access in the switych statement is dead code). I don''t want to automatically suppress all ofthose, because read_atomic() and write_atomic() could still be called with mis-cast pointers, but for atomic_t accessors

Package: xen-utils-4.4 Version: 4.4.1-3 When booting domU's running amd64 jessie, I notice some memory problems with xl. root at xen:~# pmap -x 4121 4121: /usr/lib/xen-4.4/bin/xl create --quiet --defconfig /etc/xen/auto/mail_deb80.cfg Address Kbytes RSS Dirty Mode Mapping 0000000000400000 144 128 0 r-x-- xl 0000000000623000 4 4 4 r---- xl

Hello I have a lot of problem using the xenbus api (in xen-3.0-testing). I had to modify the network backend driver (file netback.c), and each call to a xenbus function in a virtual machine make my machine reboot (not the virtual, the real machine). for example, I ''ve add this line of code (wich is useless):

i did the debugging as you said. Kindly refer the following logs: (gdb) c Continuing. thread apply all bt [New Thread 0x7fc337c6b700 (LWP 29520)] Program received signal SIGSEGV, Segmentation fault. 0x0000000000000000 in ?? () (gdb) thread apply all bt Thread 12 (Thread 0x7fc337c6b700 (LWP 29520)): #0 0x00007fc33509f18d in read () from /lib/x86_64-linux-gnu/libpthread.so.0 #1

I am newbie to this gdb debugging. now i did the bt in the debugging. In my side still it showing the error. Following are the stacktrace which i got. Kindly refer the following logs for full information: **** [New Thread 0x7f8503695700 (LWP 20012)] Program received signal SIGSEGV, Segmentation fault. 0x0000000000000000 in ?? () (gdb) bt #0 0x0000000000000000 in ?? () #1 0x00007f84f671281e in

I have tried to define a domain or using virt-install both failed. Could some one give me the correct command to do this? I used: virt-install --nographics --paravirt --os-type=solaris --os-variant=opensolaris --ram 1024 --name cam-host --disk path=/dev/dsk/c0t600A0B800049E902000008EB4A9CE744d0p0,driver=phy -l /export/media_images/sol-nv-b121-x86-dvd.iso thx, florian

Hello, I have a remote win2k machine and local NT4 machine running rsync over ssh, by way of cygwin. I have a cron script that grabs a directory from remote and puts it on local. It' very simple #!/bin/bash echo "-------------------------------------" >> /home/rsync/job.log echo "Running rsync job" >> /home/rsync/job.log gnudate >> /home/rsync/job.log

Dear xen-devel, There''s a race condition in xenfs (xenstore driver) that causes userspace utility xenstore-watch to crash. Normally, the userspace process gets an "OK" from xenfs and then the watch fires immediately after. Occasionally, this happens the other way around: the watch fires before the driver sends "OK", which confuses the xenstore-watch client. It seems

XenStore puts in queued watch events via a thread and notifies the user. Sometimes xs_unwatch is called before all related message is read. The use case is non-threaded libevent, we have two event A and B: - Event A will destroy something and call xs_unwatch; - Event B is used to notify that a node has changed in XenStore. As the event is called one by one, event A can be handled before

Hi, there. I am running CentOS 4.4 on HVM Domain. And I tried Para-virtual driver for HVM Domain. Hunged up then "modprobe xenbus". My Domain-0 information: OS: CentOS 4.4 xen: 3.0.4.1 kernel: 2.6.16.33-xen_3.0.4.1 My HVM Domain information: OS: CentOS 4.4 Kernel: 2.6.9-42.0.10.EL PV Drv: xen-unstable.hg I traced the source code. I think problem at line:132 in xenbus_xs.c. It stopped

Hi experts I use xen-4.0.0 and dom0 is 2.6.33 and domU is 2.6.34 #lspci ............... 01:00.0 Ethernet controller: Intel Corporation Unknown device 10a7 (rev 02) 01:00.1 Ethernet controller: Intel Corporation Unknown device 10a7 (rev 02) 05:00.0 Ethernet controller: Intel Corporation 82571EB Gigabit Ethernet Controller (rev 06) 05:00.1 Ethernet controller: Intel Corporation 82571EB Gigabit

On 01.10.2014 10:31, web2 wrote: > Hello, > > sorry for my later answer. > > so, after i started libvirtd (no vm´s running) and attach gdb i get the following threads > > (gdb) info thread > Id Target Id Frame > 11 Thread 0x7f18fef4e700 (LWP 20695) "libvirtd" pthread_cond_wait@@GLIBC_2.3.2 () at

web2 wrote: > Hi > > ----------------ursprüngliche Nachricht----------------- > Von: "Michal Privoznik" mprivozn@redhat.com > An: "web2" ustermann78@web.de , "libvirt-users redhat.com" > , "libvirt-list redhat.com" > Datum: Wed, 01 Oct 2014 18:12:45 +0200 > ------------------------------------------------- > > >

From: Jeremy Fitzhardinge <jeremy.fitzhardinge@citrix.com> Hi all, This series adds a new microcode driver for Xen. The Xen hypervisor can deal with all the low-level details of doing a microcode update (Intel vs AMD, doing all the physical CPUs present on the system, current and future, etc), so all the driver has to do is make a hypercall to upload the microcode into Xen. This only