Hey David,
That's not quite the scenario we're dealing with, but it is disconcerting
to here that it looks like this path can be triggered from an incoming
frame. We had been seen it frequently when quickly
unconfiguring/configuring interfaces from a host. An application would
receive the conf
Juan Mojica wrote:
>
> We manage to hit the following message with some regularity.
>
> arprequest: cannot find matching address
>
> The code shows a printf:
>
> printf("%s: cannot find matching address\n", __func__);
>
>
> Any reason this is a printf and not a
>
> log(LOG_ERR,
>
> The only
I'll provide my revision shortly.
On Mon, Apr 22, 2013 at 2:48 PM, Juan Mojica wrote:
> Thanks Gleb. I do not believe this path can triggered by an incoming
> frame. I am planning on adding a KASSERT here to get a core when we
> exercise this code in our debug images.
>
> -Juan
>
>
> On Mon,
Thanks Gleb. I do not believe this path can triggered by an incoming
frame. I am planning on adding a KASSERT here to get a core when we
exercise this code in our debug images.
-Juan
On Mon, Apr 22, 2013 at 5:57 AM, Gleb Smirnoff wrote:
> On Wed, Apr 17, 2013 at 08:46:42AM -0400, Juan Mojica
On Wed, Apr 17, 2013 at 08:46:42AM -0400, Juan Mojica wrote:
J> We manage to hit the following message with some regularity.
J>
J> arprequest: cannot find matching address
J>
J> The code shows a printf:
J>
J> printf("%s: cannot find matching address\n", __func__);
J>
J>
J> Any reason this is a
We manage to hit the following message with some regularity.
arprequest: cannot find matching address
The code shows a printf:
printf("%s: cannot find matching address\n", __func__);
Any reason this is a printf and not a
log(LOG_ERR,
The only things I can come up with are:
a) it is a really
