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 :|