On Mon, Aug 16, 2010 at 10:08:37AM -0600, Eric Blake wrote: > On 08/16/2010 03:54 AM, Soren Hansen wrote: > > On Mon, Aug 16, 2010 at 11:37:07AM +0200, Soren Hansen wrote: > >> I'm running this on another kernel right now and I'm not seeing the > >> problem. I'll try again with the kernel I used a couple of days ago. > > > > Ok, found the other kernel. Same diff as in my previous e-mail, same > > action. These are my results: > > 09:41:01.134: debug : umlMonitorCommand:698 : Run command 'config con0' > > 09:41:01.134: debug : umlMonitorCommand:733 : res.error: 6, res.extra: 0, res.length: 4096, res.data: > > 09:41:01.134: debug : umlMonitorCommand:736 : nbytes: 0 > > 09:41:01.134: debug : umlMonitorCommand:738 : res.error: 0, res.extra: 0, res.length: 4, res.data: pts > > > > > This one's a 2.6.34.1 kernel. The one where I didn't see the problem is > > a 2.6.32.something-or-the-other kernel. Mindboggling. > > Oh my. This really does look like a kernel bug. Can you confirm it > with an strace? Have you reported this regression to the right kernel > folks? > > I guess it would help if we could write a simpler test program to > isolate whether this recvfrom bug exists in a bare minimum number of > syscalls. Meanwhile, I have no idea how to work around a buggy recvfrom > that doesn't return the correct number of bytes. If there is an identifiable kernel bug then that should be reported and fixed ASAP. IMHO we shouldn't try to workaround such serious brokenness as this is showing. Regards, Daniel -- |: Red Hat, Engineering, London -o- http://people.redhat.com/berrange/ :| |: http://libvirt.org -o- http://virt-manager.org -o- http://deltacloud.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: GnuPG: 7D3B9505 -o- F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 :| -- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list