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 pan
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 pa
: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
: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 the
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 th
> 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 deadloc
On Mon, 13 Sep 1999, Garrett Wollman wrote:
!>< 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 [EMAIL PROTECTED] for more info.
!>
!>It would be preferable
On Mon, 13 Sep 1999, Garrett Wollman wrote:
!>< 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 info.
!>
!>It woul
!>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 de
!>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 dea
< 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 [EMAIL PROTECTED] for more info.
It would be preferable if text were sent as text, since MIME-encoded
patches requir
<
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 info.
It would be preferable if text were sent as text, since MIME-encode
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 i
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
15 matches
Mail list logo
