search for: msg00226

...working was quite flaky, e.g. samba access from dom0 to a server in domU was impossible, ssh connections froze, and dmesg contained lots of lines like "Received packet needs 8 bytes more headroom". A short explanation is found in http://lists.xensource.com/archives/html/xen-devel/2005-12/msg00226.html and is apparently due to some bug in the networking code. The suggested workaround fixed this problem for me: set the mtu to 1400 for all network interfaces in dom0 and domU. I''m actually suprised that this is not a FAQ. 2) Scheduling issue The system was unusable with high CPU l...

I'm observing a difference in timing on nbdkit shutdown that is dependent on client behavior, and I wonder if that's a bug, but I can't figure out where to patch it. When there is no connection present, sending SIGINT to nbdkit terminates immediately. If, on the other hand, there is a single client currently connected, the termination behavior on SIGINT depends on what the client has

...n-phase transactions, nbdkit hangs for 5 seconds, then > forcibly tears down the connection: I'm guessing it's because of commit 63f0eb0889c8f8a82ba06a02a8a92d695902baad which I added to fix a race in plugin_cleanup(). See also: https://www.redhat.com/archives/libguestfs/2017-September/msg00226.html [...] > Why does current traffic from the client cause the plugin to be torn > down faster? Does it matter? I believe because the main loop checks the !quit flag if there is traffic on the connection. There is most likely to be a better fix for the race than 63f0eb0889. I added that...

On 11/14/2017 11:30 AM, Richard W.M. Jones wrote: > This fixes the race conditions for me, using the test described here: > > https://www.redhat.com/archives/libguestfs/2017-September/msg00226.html Running test-socket-activation in a loop, I've hit other races (some provoked a bit more easily with the code I'm working on), and will be posting some patches where I know the solution: Right now, our use of threadlocal_set_name (plugin_name ()) makes our thread-local storage point...

This fixes the race conditions for me, using the test described here: https://www.redhat.com/archives/libguestfs/2017-September/msg00226.html Rich.

...dkit hangs for 5 seconds, then >> forcibly tears down the connection: > > I'm guessing it's because of commit 63f0eb0889c8f8a82ba06a02a8a92d695902baad > which I added to fix a race in plugin_cleanup(). See also: > https://www.redhat.com/archives/libguestfs/2017-September/msg00226.html > > [...] >> Why does current traffic from the client cause the plugin to be torn >> down faster? Does it matter? > > I believe because the main loop checks the !quit flag if there > is traffic on the connection. > > There is most likely to be a better fix...