>
> 3.0's lockups could be very well due to a number of low-memory interlock
> situations that typically occur when heavy paging is going on, if that is
> how you are running 3.0. I suspect it is too late to get my getpbuf()
> changes into 3.1, which might mitigate that somewhat.
Matthew Dillon wrote:
>
> :
> :I've been seeng lockups in 3.0 where as is in piperd,
> :but the stack trace has always looked as if the problem was in soft
> :updates or the syncer daemon..
> :
>
> It's quite possible for as to be in 'piperd' when some other unassociated
> crash occurs, s
:
:I've been seeng lockups in 3.0 where as is in piperd,
:but the stack trace has always looked as if the problem was in soft
:updates or the syncer daemon..
:
It's quite possible for as to be in 'piperd' when some other unassociated
crash occurs, since it is typically waiting for input f
I've been seeng lockups in 3.0 where as is in piperd,
but the stack trace has always looked as if the problem was in soft
updates or the syncer daemon..
Matthew Dillon wrote:
>
> Ha. I've been slowly reducing MAXMEM on my test box to force it to
> swap more heavily running buildworld a
Updated patch - one must also check to see if any new data has
entered the pipe after locking it in case the lock blocked.
( this patch FYI only, the problem occurs unoften enough that
you can afford to wait until I commit it ).
-M
