Skip site navigation (1)Skip section navigation (2)
Date:      Wed, 1 May 2013 21:47:23 -0700
From:      Richard Sharpe <realrichardsharpe@gmail.com>
To:        Alfred Perlstein <bright@mu.org>
Cc:        freebsd-net@freebsd.org
Subject:   Re: Seeing EINVAL from writev on 8.0 to a non-blocking socket even though the data seems to hit the wire
Message-ID:  <CACyXjPxgy7425EEj=ESF3-vQYCe17g2LXHgc%2B4EY3Zbiqxp9bQ@mail.gmail.com>
In-Reply-To: <5181ECDF.1040905@mu.org>
References:  <CACyXjPwojx1vBo-7bDmN=Pjc2Qp3mRd3Ek2FUjLR_4DC=aUnWA@mail.gmail.com> <5181ECDF.1040905@mu.org>

next in thread | previous in thread | raw e-mail | index | archive | help
On Wed, May 1, 2013 at 9:34 PM, Alfred Perlstein <bright@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.

It usually consists of four elements. All of the elements are
accessible because I checked some of the data. Well, actually, I did
not check the 65536 bytes of the last element, but they seemed to go
out on the wire, although I should check the last offset.

The lengths were usually: 4, 64, 8 or 16, 65536.

So, I do need to check the last element. I think it all went out on
the wire. With 4,64,16 and 65536 byte segments that is 65620 bytes and
they were all accounted for and the SMB2 sequence number matched what
was in memory.

--=20
Regards,
Richard Sharpe
(=A6=F3=A5H=B8=D1=BC~=A1H=B0=DF=A6=B3=A7=F9=B1d=A1C--=B1=E4=BE=DE)



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CACyXjPxgy7425EEj=ESF3-vQYCe17g2LXHgc%2B4EY3Zbiqxp9bQ>