On 03:51-0800, Jan 12, 2003, Kelly Yancey wrote:
[...]
> I'm sorry, I'm afraid I am not familiar with the issue being
> discussed. Is there a PR I can reference for more information?
> Exactly what events aren't being received? Being as the logic for
> when to return a kevent as of uipc_socke
On Sat, 11 Jan 2003, Trish Lynch wrote:
> On Sat, 11 Jan 2003, Daniel C. Sobral wrote:
>
> > Peter, reverting the revisions below *does* fix the problem. Tim has an
> > alternative patch, though. At any rate, it seems kbyanc's solution was
> > overly simplistic. But things are broken either way, a
On Sat, 11 Jan 2003, Daniel C. Sobral wrote:
> Peter, reverting the revisions below *does* fix the problem. Tim has an
> alternative patch, though. At any rate, it seems kbyanc's solution was
> overly simplistic. But things are broken either way, and I'm not sure
> Tim's patch doesn't result in th
Peter, reverting the revisions below *does* fix the problem. Tim has an
alternative patch, though. At any rate, it seems kbyanc's solution was
overly simplistic. But things are broken either way, and I'm not sure
Tim's patch doesn't result in the kind of situation rev 1.134 tried to
fix, nor if his
* De: Peter Wemm <[EMAIL PROTECTED]> [ Data: 2003-01-10 ]
[ Subjecte: Re: Serious issues with kqueue on sockets on CURRENT. ]
> In case anybody wants to play, I seem to recall some changes in uipc_socket.c
> that caused some problems (totally hosed the resolver)
Tim Robbins wrote:
> On Fri, Jan 10, 2003 at 01:30:16AM -0800, Juli Mallett wrote:
>
> > Lately, the data field for sockets, which holds bytes ready (in the EVFILT_
> > READ case) to be read, is computed to be zero. This means that if you have
> > a low watermark which is >0 per the kq, THE EVENT
Terry Lambert wrote:
> "Daniel C. Sobral" wrote:
> > > I can definitely reproduce this here and also fairly angry about it.
> > > In addition to what you mentioned, fstat() gives an incorrect st_size
> > > result now and it's likely that non-NOTE_LOWAT low watermarks are
> > > firing too early as w
Nate Lawson wrote:
> On Fri, 10 Jan 2003, Sam Leffler wrote:
> > What are "non-data characters"?
>
> A very zen question. :) In this case, It probably means bytes carried in
> an mbuf with a type other than MT_DATA.
Characters that won't come back from a read(2).
The point of the EVFILT_READ c
"Daniel C. Sobral" wrote:
> > I can definitely reproduce this here and also fairly angry about it.
> > In addition to what you mentioned, fstat() gives an incorrect st_size
> > result now and it's likely that non-NOTE_LOWAT low watermarks are
> > firing too early as well.
> >
> > Ugly test program
> On Fri, 10 Jan 2003, Sam Leffler wrote:
> > unless the mbufs are specifically tagged as such. I'm not clear on
exactly
> > what sb_ctl is supposed to count; the comment in the cvs log is unclear:
> >
> > "Track the number of non-data chararacters stored in socket buffers so
that
> > the data val
On Fri, 10 Jan 2003, Sam Leffler wrote:
> unless the mbufs are specifically tagged as such. I'm not clear on exactly
> what sb_ctl is supposed to count; the comment in the cvs log is unclear:
>
> "Track the number of non-data chararacters stored in socket buffers so that
> the data value returned
> On Fri, Jan 10, 2003 at 09:57:36PM +1100, Tim Robbins wrote:
>
> > On Fri, Jan 10, 2003 at 01:30:16AM -0800, Juli Mallett wrote:
> >
> > > Lately, the data field for sockets, which holds bytes ready (in the
EVFILT_
> > > READ case) to be read, is computed to be zero. This means that if you
have
On 2003-01-11 00:42, Tim Robbins <[EMAIL PROTECTED]> wrote:
> >From what I can tell, mbufs with m_type == MT_HEADER can store data
> as well as those with m_type == MT_DATA. This patch corrects the
> tests in sbcompress(), sbdrop(), sballoc() and sbfree() so that data
> stored in MT_HEADER mbufs is
On Fri, Jan 10, 2003 at 09:57:36PM +1100, Tim Robbins wrote:
> On Fri, Jan 10, 2003 at 01:30:16AM -0800, Juli Mallett wrote:
>
> > Lately, the data field for sockets, which holds bytes ready (in the EVFILT_
> > READ case) to be read, is computed to be zero. This means that if you have
> > a low
Daniel C. Sobral wrote:
Tim Robbins wrote:
> On Fri, Jan 10, 2003 at 01:30:16AM -0800, Juli Mallett wrote:
>
>
> >Lately, the data field for sockets, which holds bytes ready (in the
> EVFILT_
> >READ case) to be read, is computed to be zero. This means that if
> you have
> >a low watermark whic
Tim Robbins wrote:
On Fri, Jan 10, 2003 at 01:30:16AM -0800, Juli Mallett wrote:
>Lately, the data field for sockets, which holds bytes ready (in the
EVFILT_
>READ case) to be read, is computed to be zero. This means that if
you have
>a low watermark which is >0 per the kq, THE EVENT WILL NE
On Fri, Jan 10, 2003 at 01:30:16AM -0800, Juli Mallett wrote:
> Lately, the data field for sockets, which holds bytes ready (in the EVFILT_
> READ case) to be read, is computed to be zero. This means that if you have
> a low watermark which is >0 per the kq, THE EVENT WILL NEVER HAPPEN. Not to
>
First off, I'm very pissed off about this, but not going to bring out the
big stick of death, because, well, it can't matter enough if I'm the only
poor soul seeing this, despite how many hours I wasted thinking maybe it
was the fault of my code.
In 5.0-CURRENT, since last month or so, I've been h
18 matches
Mail list logo
