Seeing EINVAL from writev on 8.0 to a non-blocking socket even though the data seems to hit the wire

[Richard Sharpe]

On Wed, May 1, 2013 at 9:34 PM, Alfred Perlstein <bright at mu.org> wrote:
> On 5/1/13 8:03 PM, Richard Sharpe wrote:
>> Hi folks,
>>
>> I am checking to see if there are any known bugs with respect to this
>> in FreeBSD 8.0.
>>
>> Situation is that Samba 3.6.6 uses writev to a non-blocking socket to
>> get the SMB2 requests on the wire.
>>
>> Intermittently, we see the writev return EINVAL even though the data
>> has gotten on the wire. This I have verified by grabbing a capture and
>> comparing the SMB Sequence number in the last outgoing packet on the
>> wire vs the in-memory contents when we get EINVAL.
>>
>> Sometimes it occurs on a four-element IOVEC, sometimes we get EAGAIN
>> on the four-element IOVEC and then we get EINVAL when retrying on a
>> smaller IOVEC.
>>
>> Where should I look to check if there is some path where this might be
>> happening? Is this even the correct mailing list?
>>
> What does the iovec look like when you get EINVAL? Can you sanity check
> it? Is there anything special about it? (zero length vecs?)
>
> I think there are a few "maxvals" that if overrun cause EINVAL to be
> returned. example is if your iovec is somehow huge or has many, many
> elements.

Can anyone tell me the call graph down to the TCP code?

-- 
Regards,
Richard Sharpe
(何以解憂？唯有杜康。--曹操)