On Mon, 6 Aug 2018 at 11:27, Kyle Evans wrote:
>
> On Sun, Aug 5, 2018 at 5:43 AM, Konstantin Belousov
> wrote:
> > On Sat, Aug 04, 2018 at 09:46:39PM -0500, Kyle Evans wrote:
> >>
> >> He now gets a little further, but ends up with the same panic due to
> >> efirtc_probe trying to get time to v
On 2018-08-06 23:11, Erich Dollansky wrote:
> Hi,
>
> On Mon, 6 Aug 2018 15:57:53 -0700
> John Baldwin wrote:
>
>> On 8/4/18 4:38 PM, Erich Dollansky wrote:
>>> Hi,
>>>
>>> I compiled me yesterday this system:
>>>
>>> 12.0-CURRENT FreeBSD 12.0-CURRENT #1 r337285:
>>>
>>> When restarting fortune
Hi,
On Mon, 6 Aug 2018 15:57:53 -0700
John Baldwin wrote:
> On 8/4/18 4:38 PM, Erich Dollansky wrote:
> > Hi,
> >
> > I compiled me yesterday this system:
> >
> > 12.0-CURRENT FreeBSD 12.0-CURRENT #1 r337285:
> >
> > When restarting fortune core dumps. When trying to load the core
> > dump, g
On Thu, Jun 21, 2018 at 10:49 PM Mark Millard wrote:
> Has the range r328278 < PROBLEM_START <= r330304 been narrowed down
> some more?
>
> (I'm just curious were the problem started.)
After several rounds of binary search, I found it might have something
todo with r329625.
The only thing I thin
On 8/4/18 4:38 PM, Erich Dollansky wrote:
> Hi,
>
> I compiled me yesterday this system:
>
> 12.0-CURRENT FreeBSD 12.0-CURRENT #1 r337285:
>
> When restarting fortune core dumps. When trying to load the core dump,
> gdb core dumps.
>
> The message is always:
>
> Bad system call (core dumped)
>
OK, so now I verified that it does happen on:
CentOS 7 - NetworkManager with OpenVPN plugin
openSUSE tumbleweed - NetworkManager with OpenVPN plugin
however, I am sure that it also happened at least once with FreeBSD -
FreeBSD bare OpenVPN.
On Mon, 6 Aug 2018 23:06:55 +0200
Lars Schotte wrote:
On 8/6/18 11:41 PM, Konstantin Belousov wrote:
>>> linux_sys_futex(0x33b0fac,0x85,0x1,0x1,0x33b0fa8,0x401)
>>> -- here it stops --
>> Can you fix your mail client ?
Unfortunately, it did all that dumb wraps at send time not at edit. Sorry.
>>> ddb also shows that process is looping somewhere
So, now in fact I was able to make a stable connection between 2
FreeBSD's one of them server running 12-current.
Now I do not know why the problem did not occur, could be just accident
or sth. I am starting to suspect that I ran into some strange case.
I will continue looking into it.
On Mon, 6
On Mon, Aug 06, 2018 at 11:37:38PM +0300, Konstantin Belousov wrote:
> On Mon, Aug 06, 2018 at 06:24:43PM +0300, Vladimir Kondratyev wrote:
> > I've got similar panic right after skype start
> >
> > Disabling of SMAP via loader tunable workarounded the panic for me.
> >
> > Applying of the patch
On Mon, Aug 06, 2018 at 06:24:43PM +0300, Vladimir Kondratyev wrote:
> I've got similar panic right after skype start
>
> Disabling of SMAP via loader tunable workarounded the panic for me.
>
> Applying of the patch make skype eating 100%CPU in unkillable state.
>
> tail of ktrace dump
>
> 12
The struct thread is typesafe. The problem is that the link is no longer
typesafe now that it’s not part of the thread. Thanks for pointing this
out. I’ll commit a fix later today.
-M
On Mon, Aug 6, 2018 at 02:39 Hans Petter Selasky wrote:
> Hi Matthew,
>
> On 08/06/18 10:02, Hans Petter Sela
(replies inline)
On Tue, 31 Jul 2018, R. Tyler Croy wrote:
> On Wed, 25 Jul 2018, R. Tyler Croy wrote:
>
> > On Sun, 15 Jul 2018, Michael Butler wrote:
> >
> > > On 07/05/18 09:54, I wrote:
> > > > On 07/05/18 09:27, tech-lists wrote:
> > > >> On 03/07/2018 19:47, Michael Butler wrote:
> > > >>
On Sun, Aug 5, 2018 at 5:43 AM, Konstantin Belousov wrote:
> On Sat, Aug 04, 2018 at 09:46:39PM -0500, Kyle Evans wrote:
>>
>> He now gets a little further, but ends up with the same panic due to
>> efirtc_probe trying to get time to verify the rtc's actually
>> implemented. What kind of approach
12.0-CURRENT FreeBSD 12.0-CURRENT #10 r337347: Sun Aug 5 14:28:37 CEST
2018 here.
On Mon, 6 Aug 2018 11:30:57 +0300
Gleb Popov wrote:
> On Sun, Aug 5, 2018 at 11:51 PM, Lars Schotte wrote:
>
> > Here a bit of paste:
> > https://paste.fedoraproject.org/paste/Hn4M2JqZ~5xccLWOVD1xUw/raw
> > just
Yes, I also have very recent 12-current without change on what SSL
library it uses.
However, the problem does not seem to be the SSL library, since it
connects and reports no problems at all. The issue here is only that it
does not transfer packages correctly.
And I am not ruling out other proble
Hans Petter Selasky wrote:
> Hi Roman,
>
> Can you try the attached patch?
>
> --HPS
Thanks for the patch, works fine so far.
I'll give it more testing in the next few days.
Roman Bogorodskiy
signature.asc
Description: PGP signature
I've got similar panic right after skype start
Disabling of SMAP via loader tunable workarounded the panic for me.
Applying of the patch make skype eating 100%CPU in unkillable state.
tail of ktrace dump
1238 skype CALL linux_gettid
1238 skype RET linux_gettid 101123/0x18b03
1238
I'm running a very recent 12-current too and latest openvpn from pkgs. No
problems.
I did not change anything in the defaults for the SSL-library it uses.
Ronald.
Van: Gleb Popov
Datum: maandag, 6 augustus 2018 10:30
Aan: Lars Schotte
CC: FreeBSD Ports , FreeBSD current
Onderwerp: Re: OpenV
On Sat, Aug 4, 2018 at 3:22 PM Konstantin Belousov
wrote:
> On Sat, Aug 04, 2018 at 01:12:17PM +0100, Johannes Lundberg wrote:
> > No panic over night with that tunable so it seems you're on the right
> > track.
>
> Please try this, on top of r337316.
>
Been running boinc client now with 4 linux
Hi Matthew,
On 08/06/18 10:02, Hans Petter Selasky wrote:
- if ((tdwait = TAILQ_FIRST(&record->er_tdlist)) != NULL &&
- TD_IS_RUNNING(tdwait->et_td)) {
At least the TD_IS_RUNNING() check is invalid. The "tdwait" structure is
in the control of the other CPU and
On Sun, Aug 5, 2018 at 11:51 PM, Lars Schotte wrote:
> Here a bit of paste:
> https://paste.fedoraproject.org/paste/Hn4M2JqZ~5xccLWOVD1xUw/raw
> just to illustrate how it does not work.
>
> TAP device works good inside OS (FreeBSD current) however, everything
> that comes over OpenVPN is just gar
Hi Roman,
Can you try the attached patch?
--HPS
Index: sys/kern/subr_epoch.c
===
--- sys/kern/subr_epoch.c (revision 336962)
+++ sys/kern/subr_epoch.c (working copy)
@@ -232,33 +232,14 @@
struct epoch_thread *tdwait;
struct turn
Hi,
I think the problem is the thread pointed to by tdwait exited. I would
say it is not allowed to peek into the other records threads, because
they may change under the hood and are not protected by the current context.
if (record->er_cpuid != curcpu) {
This optimisation is inva
23 matches
Mail list logo
