Date: Thu, 2 May 2013 20:14:12 -0400 From: Eitan Adler <lists@eitanadler.com> To: Richard Sharpe <realrichardsharpe@gmail.com> Cc: freebsd-net@freebsd.org, Eric van Gyzen <eric@vangyzen.net>, Alfred Perlstein <bright@mu.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: <CAF6rxgk9fiyV7NERTRxFaQog0PKMzcAERazsU1FONqJuFT0m_g@mail.gmail.com> In-Reply-To: <CACyXjPzML0b5VyCNnc3vCJDDM5JZaRdeTLc9v29iBAK_-1eYyw@mail.gmail.com> References: <CACyXjPwojx1vBo-7bDmN=Pjc2Qp3mRd3Ek2FUjLR_4DC=aUnWA@mail.gmail.com> <5181ECDF.1040905@mu.org> <CACyXjPy8ctxs1vG0KPLHtaJxrM_YTs6XfLEbhQUBKTkZAjewzA@mail.gmail.com> <51827DAA.2020009@vangyzen.net> <CACyXjPzML0b5VyCNnc3vCJDDM5JZaRdeTLc9v29iBAK_-1eYyw@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On 2 May 2013 20:00, Richard Sharpe <realrichardsharpe@gmail.com> wrote: > On Thu, May 2, 2013 at 7:52 AM, Eric van Gyzen <eric@vangyzen.net> wrote: >> On 05/02/2013 08:48, Richard Sharpe wrote: >>> 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. >>> Can anyone tell me the call graph down to the TCP code? >>> >> >> writev kern/sys_generic.c >> kern_writev >> dofilewrite >> fo_write in sys/file.h >> soo_write in kern/sys_socket.c >> sosend in kern/uipc_socket.c >> sosend_generic >> tcp_usr_send in netinet/tcp_usrreq.c > > Is there a tool that generates call graphs? gprof in base valgrind --callgrind doxygen can also do this. there are probably others. -- Eitan Adler
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CAF6rxgk9fiyV7NERTRxFaQog0PKMzcAERazsU1FONqJuFT0m_g>