I think that what needs to be done is to split the problem in two. First,
allow the mbuf routines to return a failure even with M_WAIT. If M_WAIT
is used, it simply means 'try harder, sleeping a bit if necessary'. This
requires ensuring that all the networking code deal with
:In 4.3, the code was able to deal with cluster allocation failing. We
:have a somewhat different situation now, because many network
:interface devices have less-flexible DMA mechanisms which don't allow
:packet reception into non-contiguous buffers, so we need to have at
:least a certain
On Mon, 13 Sep 1999, Matthew Dillon wrote:
The case that is causing the panics is with the non-interrupt mbuf
allocation mechanism. Specifically, the case where M_WAIT is used.
The second problem under discussion, which really ought to be separated
out from the mbuf panic
:In 4.3, the code was able to deal with cluster allocation failing. We
:have a somewhat different situation now, because many network
:interface devices have less-flexible DMA mechanisms which don't allow
:packet reception into non-contiguous buffers, so we need to have at
:least a certain number
I think that what needs to be done is to split the problem in two. First,
allow the mbuf routines to return a failure even with M_WAIT. If M_WAIT
is used, it simply means 'try harder, sleeping a bit if necessary'. This
requires ensuring that all the networking code deal with
On Mon, 13 Sep 1999, Matthew Dillon wrote:
The case that is causing the panics is with the non-interrupt mbuf
allocation mechanism. Specifically, the case where M_WAIT is used.
The second problem under discussion, which really ought to be separated
out from the mbuf panic
From woll...@khavrinen.lcs.mit.edu Mon Sep 13 22:39:37 1999
I'm also aware of the possiblity of some people not liking the
fact that we tsleep() forever (e.g. tsleep(x,x,x,0)).
I don't have any problem with sleeping forever -- but I am concerned
about the possibility of deadlock,
!I think that what needs to be done is to split the problem in two. First,
!allow the mbuf routines to return a failure even with M_WAIT. If M_WAIT
!is used, it simply means 'try harder, sleeping a bit if necessary'. This
!requires ensuring that all the networking code deal
On Mon, 13 Sep 1999, Garrett Wollman wrote:
!On Sun, 12 Sep 1999 23:19:13 -0400 (EDT), Bosko Milekic [EMAIL PROTECTED] said:
!
! This message is in MIME format. The first part should be readable text,
! while the remaining parts are likely unreadable without MIME-aware tools.
! Send
On Sun, 12 Sep 1999 23:19:13 -0400 (EDT), Bosko Milekic bmile...@dsuper.net
said:
This message is in MIME format. The first part should be readable text,
while the remaining parts are likely unreadable without MIME-aware tools.
Send mail to m...@docserver.cac.washington.edu for more
!I think that what needs to be done is to split the problem in two. First,
!allow the mbuf routines to return a failure even with M_WAIT. If M_WAIT
!is used, it simply means 'try harder, sleeping a bit if necessary'. This
!requires ensuring that all the networking code deal
On Mon, 13 Sep 1999, Garrett Wollman wrote:
!On Sun, 12 Sep 1999 23:19:13 -0400 (EDT), Bosko Milekic
bmile...@dsuper.net said:
!
! This message is in MIME format. The first part should be readable text,
! while the remaining parts are likely unreadable without MIME-aware tools.
! Send
Hello (again),
On Thu, 9 Sep 1999, Stas Kisel wrote:
! From [EMAIL PROTECTED] Thu Sep 9 16:17:27 1999
!
! Probably it is not self-evident why we HAVE to drop this connection.
!
! So what if someone manages to crash a program due to a DOS attack ?
! An easy one that comes to mind is syslogd.
Hello (again),
On Thu, 9 Sep 1999, Stas Kisel wrote:
! From ava...@cheops.anu.edu.au Thu Sep 9 16:17:27 1999
!
! Probably it is not self-evident why we HAVE to drop this connection.
!
! So what if someone manages to crash a program due to a DOS attack ?
! An easy one that comes to mind is
14 matches
Mail list logo
