Date: Wed, 01 May 2013 21:34:39 -0700 From: Alfred Perlstein <bright@mu.org> To: Richard Sharpe <realrichardsharpe@gmail.com> 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: <5181ECDF.1040905@mu.org> In-Reply-To: <CACyXjPwojx1vBo-7bDmN=Pjc2Qp3mRd3Ek2FUjLR_4DC=aUnWA@mail.gmail.com> References: <CACyXjPwojx1vBo-7bDmN=Pjc2Qp3mRd3Ek2FUjLR_4DC=aUnWA@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
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. -Alfred
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?5181ECDF.1040905>