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
The following reply was made to PR kern/178017; it has been noted by GNATS.
From: Gleb Smirnoff
To: Nate Denning
Cc: bug-follo...@freebsd.org
Subject: Re: kern/178017: [tcp] [panic] Kernel panic: general protection
fault in tcp_do_segment
Date: Mon, 22 Apr 2013 14:19:30 +0400
Nate,
it
Synopsis: [tcp] [panic] Kernel panic: general protection fault in tcp_do_segment
State-Changed-From-To: open->closed
State-Changed-By: glebius
State-Changed-When: Mon Apr 22 10:54:18 UTC 2013
State-Changed-Why:
Email to submitters address bounces.
http://www.freebsd.org/cgi/query-pr.cgi?pr=17801
Note: to view an individual PR, use:
http://www.freebsd.org/cgi/query-pr.cgi?pr=(number).
The following is a listing of current problems submitted by FreeBSD users.
These represent problem reports covering all versions including
experimental development code and obsolete releases.
S Tracker
On Saturday, April 20, 2013 9:18:24 pm Laurie Jennings wrote:
> That does help. Is there a way for the kernel to access the memory map
directlyby segment name?
There is not, no. It wouldn't be hard to add, but the issue there is that
the existing shm_map/unmap API assumes you have an open file d
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
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,
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
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
