The following reply was made to PR kern/157287; it has been noted by GNATS.
From: Joerg Wunsch
To: freebsd-gnats-sub...@freebsd.org, freebsd-b...@freebsd.org
Cc:
Subject: Re: kern/157287: re0: INVARIANTS panic (Memory modified after free)
Date: Wed, 25 May 2011 21:17:30 +0200
Here's a
The following reply was made to PR kern/157287; it has been noted by GNATS.
From: Joerg Wunsch
To: freebsd-gnats-sub...@freebsd.org, freebsd-b...@freebsd.org
Cc:
Subject: Re: kern/157287: re0: INVARIANTS panic (Memory modified after free)
Date: Wed, 25 May 2011 22:33:13 +0200
Some more
The following reply was made to PR kern/157287; it has been noted by GNATS.
From: Joerg Wunsch
To: freebsd-gnats-sub...@freebsd.org, freebsd-b...@freebsd.org
Cc:
Subject: Re: kern/157287: re0: INVARIANTS panic (Memory modified after free)
Date: Thu, 26 May 2011 17:54:24 +0200
As it turns out
As Roman Kurakin wrote:
> Problem:
> If we have max_failure < MAXALIVECNT*5 we will
> send conf-rej for magic.
> Solution:
> Loopback could be treated as a special case and
> thus we may not count it as a failure.
Can you explain a little more, please? The patch is simple enough,
ye
As Roman Kurakin wrote:
> This is the first patch of set of patches that I plan to make. These
> patches ware send several
> times as a big patch and last one wasn't even discussed. So I will try
> to send them by small
> pieces and will try to comment them.
One problem i've got with all s
As Roman Kurakin wrote:
> This letter was sent last Saturday. When should I expect any
> reaction?
You've already got one from me.
--
cheers, J"org .-.-. --... ...-- -.. . DL8DTL
http://www.sax.de/~joerg/NIC: JW11-RIPE
Never trust an operatin
As Roman Kurakin wrote:
> >You've already got one from me.
> >
> I thought someone else maintains this part of kernel. Was I wrong?
Probably. At least it was me who wrote larger parts of the current
sppp implementation. As mentioned, it's very unfortunate that a
number of offspring implementat
As Roman Kurakin wrote:
> I didn't want to neglect your's part, I just want to say that we (me
> and Serge) also feel responsibility for this code and we keep on
> development of it.
That's nice!
> >What do you think?
> I don't think that they should be broken out completely. Physicaly,
> yes
As Roman Kurakin wrote:
> >>This letter was sent last Saturday. When should I expect any
> >>reaction?
> >>
> >
> >You've already got one from me.
> >
> I thought someone else maintains this part of kernel. Was I wrong?
Btw., i just finished all the work that was in my pipe regarding
the
As Brian Somers wrote:
> The code now avoids adding a host route if the interface address is
> 0.0.0.0, and always treats a failure to add a host route as fatal
> (previously, it masked EEXIST for some reason - I guessed because it
> was trying to handle address re-assignment, but that works o
As Roman Kurakin wrote:
> Sppp still have a quantity of bugs. Here is one of them:
>
> --- if_spppsubr.c.origWed Oct 16 18:41:16 2002
> +++ if_spppsubr.cThu Nov 21 20:13:16 2002
> @@ -1672,12 +1672,12 @@
> case STATE_ACK_SENT:
> break;
> case STATE_CLOSI
11 matches
Mail list logo
