Hi Kubilay,
Yes, i think all issues are related with this one. I already attached many
info about these crashes there, but looks like nobody cares about it.
This PR is assigned to Ermal, but he's not working on it because his last
PR change was in January.
If you or someone else is interested t
On 19/10/2016 3:23 AM, Cassiano Peixoto wrote:
> Hi guys,
>
> I have some update about this issue. After my last email i had 3 crashes.
> Two of them had the same message on kernel debug:
>
> (kgdb) list *0x8228c918
> 0x8228c918 is in trim_map_seg_compare
> (/usr/src/sys/cddl/cont
Hi guys,
I have some update about this issue. After my last email i had 3 crashes.
Two of them had the same message on kernel debug:
(kgdb) list *0x8228c918
0x8228c918 is in trim_map_seg_compare
(/usr/src/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/trim_map.c:108).
103trim_
Hi guys,
First of all, thanks to share your thoughts about this issue. I think it’s
really important to find out a solution for this issue together.
I can see two behaviors related, but for me the root cause is the same:
1- mpd5 process stuck with umtxn flag
2- system crash
I’ve tested recently
On 10/12/16 3:24 PM, Zaphod Beeblebrox wrote:
While my mp5 servers are possibly less busy (I havn't had common
crashes), I have noticed a "group" of problems.
1. The carrier dropping communication (ie: fiber cut or l2 switch
breakage) of the L2TP streams can leave mpd5 in a state where it wil
While my mp5 servers are possibly less busy (I havn't had common crashes),
I have noticed a "group" of problems.
1. The carrier dropping communication (ie: fiber cut or l2 switch breakage)
of the L2TP streams can leave mpd5 in a state where it will not die and
will not destroy interfaces (requires
On 10/12/16 1:13 AM, Julian Elischer wrote:
On 11/10/2016 8:56 PM, Donald Baud via freebsd-net wrote:
I've been plagued with these =daily= panics until I tried the
following recipes and the server has been up for 30 days so far:
Normally I should expermient more to see which one of the receip
On 11/10/2016 8:56 PM, Donald Baud via freebsd-net wrote:
I've been plagued with these =daily= panics until I tried the following recipes
and the server has been up for 30 days so far:
Normally I should expermient more to see which one of the receipes is really
the fix, but I'm just glad that
I've been plagued with these =daily= panics until I tried the following recipes
and the server has been up for 30 days so far:
Normally I should expermient more to see which one of the receipes is really
the fix, but I'm just glad that the server is stable for now.
recipe-1: Don't let mpd5 st
1400 l2tp sessions generating 700Mbit/s.
_
From: Cassiano Peixoto
Sent: Tuesday, October 11, 2016 07:30
Subject: Re: FreeBSD10.3-RELEASE. Kernel panic.
To: Eugene Grosbein
Cc: , Андрей Леушкин
Hi,
There are many users complaining about
Hi,
There are many users complaining about this:
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=186114
I've been dealing with this issue for one year with no solution. mpd5 as
pppoe server on FreeBSD is useless with this bug.
I really would like to see it working again, i think it's quite im
11.10.2016 11:02, Андрей Леушкин пишет:
Hello. I have problem with "FreeBSD nas 10.3-RELEASE FreeBSD 10.3-RELEASE
#0: Fri Oct 7 21:12:56 YEKT 2016 nas@nas:/usr/obj/usr/src/sys/nasv3
amd64"
Kernel panic is repeated at intervals of 2-3 days. At first I thought that
the problem is in the har
Hello. I have problem with "FreeBSD nas 10.3-RELEASE FreeBSD 10.3-RELEASE
#0: Fri Oct 7 21:12:56 YEKT 2016 nas@nas:/usr/obj/usr/src/sys/nasv3
amd64"
Kernel panic is repeated at intervals of 2-3 days. At first I thought that
the problem is in the hardware, but the problem did not go away afte
13 matches
Mail list logo
