On 16-08-2010 18:08, Eric Blake wrote: > On 08/16/2010 03:54 AM, Soren Hansen wrote: >> 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? Annoyingly, no. It doesn't happen in the primary libvirt thread, so I have to pass -f to strace, and uml doesn't let you PTRACE it, so I can't trigger the problem. > Have you reported this regression to the right kernel folks? It doesn't happen in 2.6.35, so I seems isolated to that particular kernel. It's really very, very odd. > 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. No, you're right. Whatever we do to work around this is going to suck somehow. -- Soren Hansen Ubuntu Developer http://www.ubuntu.com/
Attachment:
signature.asc
Description: OpenPGP digital signature
-- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list