Hello all,
I've submitted bug report accidentally in the wrong category:
http://www.freebsd.org/cgi/query-pr.cgi?pr=173235
So I was adviced to send a note here. Basically I had 2 Fatal trap 12: page
fault in kernel mode last week:
1st) current process = 1192 (smbiod1)
2nd) current proc
On 05.11.2012 00:25, Fabian Keil wrote:
Andre Oppermann wrote:
On 04.11.2012 22:52, Fabian Keil wrote:
Andre Oppermann wrote:
The patch I sent was not correct. Please try this new attached patch
instead.
This seems to fix the issue for connections between curl and gatling,
That's goo
Andre Oppermann wrote:
> I've backed out the change with r242601 as it exhibits still too
> many problems. I'll fix these problems in the next days but in
> the mean time HEAD should be in a working state.
>
> I'll be grateful if I could send you the fixed change for testing
> before it goes in
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 05.11.2012 11:09, Fabian Keil wrote:
Andre Oppermann wrote:
I've backed out the change with r242601 as it exhibits still too
many problems. I'll fix these problems in the next days but in
the mean time HEAD should be in a working state.
I'll be grateful if I could send you the fixed chang
Andre Oppermann wrote:
> On 05.11.2012 11:09, Fabian Keil wrote:
> > Andre Oppermann wrote:
> >
> >> I've backed out the change with r242601 as it exhibits still too
> >> many problems. I'll fix these problems in the next days but in
> >> the mean time HEAD should be in a working state.
> >>
>
Synopsis: [netinet] [patch] Incorrect IP checksums when forwarding results in
fragmentation
State-Changed-From-To: open->patched
State-Changed-By: glebius
State-Changed-When: Mon Nov 5 20:44:43 UTC 2012
State-Changed-Why:
Committed to head.
Responsible-Changed-From-To: freebsd-net->glebius
Res
Still working this problem I've previously mentioned on the list, and my
working theory now is a race between catchpacket() and this code in bpfread():
/*
* At this point, we know we have something in the hold slot.
*/
BPFD_UNLOCK(d);
/*
* Move
