In message <1489782793.40576.185.ca...@freebsd.org>, Ian Lepore writes:
> On Fri, 2017-03-17 at 13:26 -0700, Don Lewis wrote:
> > On 17 Mar, O. Hartmann wrote:
> >
> > >
> > > Just some strange news:
> > >
> > > I left the server the whole day with ntpd disabled and I didn't
> > > watch
> > > a
- Start Forwarded Message -
Sent: Fri, 17 Mar 2017 12:47:30 -0700
From: John Baldwin
To: jbt...@iherebuywisely.com
Subject: Re: info.0 dump good
On Thursday, March 16, 2017 05:32:13 AM Jeffrey Bouquet wrote:
>
> On Wed, 15 Mar 2017 16:10:43 -0700, John Baldwin wrote:
>
> > On Monday,
On Fri, Mar 17, 2017 at 09:23:00PM +, Rick Macklem wrote:
> Dimitry Andric wrote:
> >On 17 Mar 2017, at 15:19, Konstantin Belousov wrote:
> >>
> >> On Fri, Mar 17, 2017 at 01:53:46PM +, Rick Macklem wrote:
> >>> Well, I don't mind adding ncl_flush(), but it shouldn't be
> >>> necessary. I
Oops, yea I see that now. In the krpc it is very hard to tell when the data
structures
(that hold the mutexes) can be safely free'd. Code like xprt_unregister() get
called
asynchronously and lock a mutex as soon as called.
(The crash fixed by r313735 was a prematurely free'd mutex that
xprt_unre
Dimitry Andric wrote:
>On 17 Mar 2017, at 15:19, Konstantin Belousov wrote:
>>
>> On Fri, Mar 17, 2017 at 01:53:46PM +, Rick Macklem wrote:
>>> Well, I don't mind adding ncl_flush(), but it shouldn't be
>>> necessary. I actually had it in the first
>>> rendition of the patch, but took it out b
On 2017-03-17 16:30, Patrick Kelsey wrote:
> On Fri, Mar 17, 2017 at 1:31 PM, O. Hartmann wrote:
>
>> Am Fri, 17 Mar 2017 20:07:35 +0300
>> Slawa Olhovchenkov schrieb:
>>
>>> On Fri, Mar 17, 2017 at 05:53:24PM +0100, O. Hartmann wrote:
>>>
Am Fri, 17 Mar 2017 15:04:29 +0300
Slawa Olhov
On Fri, 2017-03-17 at 13:26 -0700, Don Lewis wrote:
> On 17 Mar, O. Hartmann wrote:
>
> >
> > Just some strange news:
> >
> > I left the server the whole day with ntpd disabled and I didn't
> > watch
> > a gain of the RTC by one second, even stressing the machine.
> >
> > But soon after restart
On Fri, Mar 17, 2017 at 1:31 PM, O. Hartmann wrote:
> Am Fri, 17 Mar 2017 20:07:35 +0300
> Slawa Olhovchenkov schrieb:
>
> > On Fri, Mar 17, 2017 at 05:53:24PM +0100, O. Hartmann wrote:
> >
> > > Am Fri, 17 Mar 2017 15:04:29 +0300
> > > Slawa Olhovchenkov schrieb:
> > >
> > > > On Fri, Mar 17,
On 17 Mar, O. Hartmann wrote:
> Just some strange news:
>
> I left the server the whole day with ntpd disabled and I didn't watch
> a gain of the RTC by one second, even stressing the machine.
>
> But soon after restarting ntpd, I realised immediately a 30 minutes
> off! This morning, the discra
On Fri, Mar 17, 2017 at 06:31:11PM +0100, O. Hartmann wrote:
> Am Fri, 17 Mar 2017 20:07:35 +0300
> Slawa Olhovchenkov schrieb:
>
> > On Fri, Mar 17, 2017 at 05:53:24PM +0100, O. Hartmann wrote:
> >
> > > Am Fri, 17 Mar 2017 15:04:29 +0300
> > > Slawa Olhovchenkov schrieb:
> > >
> > > > On
On 17 Mar 2017, at 15:19, Konstantin Belousov wrote:
>
> On Fri, Mar 17, 2017 at 01:53:46PM +, Rick Macklem wrote:
>> Well, I don't mind adding ncl_flush(), but it shouldn't be
>> necessary. I actually had it in the first
>> rendition of the patch, but took it out because it should happen
>>
On Fri, Mar 17, 2017 at 11:26:43AM -0700, Bryan Drewery wrote:
> On 3/10/2017 2:44 AM, Konstantin Belousov wrote:
> > On Fri, Mar 10, 2017 at 12:11:51AM +0100, Jilles Tjoelker wrote:
> >> This patch introduces a subtle correctness bug. A real SIGCHLD ksiginfo
> >> should always be the zombie's p_ks
On Fri, 17 Mar 2017 18:31:11 +0100 "O. Hartmann" wrote
> Am Fri, 17 Mar 2017 20:07:35 +0300
> Slawa Olhovchenkov schrieb:
>
> > On Fri, Mar 17, 2017 at 05:53:24PM +0100, O. Hartmann wrote:
> >
> > > Am Fri, 17 Mar 2017 15:04:29 +0300
> > > Slawa Olhovchenkov schrieb:
> > >
> > > > On Fri,
On 3/10/2017 2:44 AM, Konstantin Belousov wrote:
> On Fri, Mar 10, 2017 at 12:11:51AM +0100, Jilles Tjoelker wrote:
>> This patch introduces a subtle correctness bug. A real SIGCHLD ksiginfo
>> should always be the zombie's p_ksi; otherwise, the siginfo may be lost
>> if there are too many signals
Apologies for top posting (I generally HATE that too),
and also, if someone already shared this link.
BUT; I performed a search at my favorite CPU spec site,
and it appears that your CPU *does* have AES-NI ( AESNI ):
http://www.cpu-world.com/CPUs/Xeon/Intel-Xeon%20E5-1650%20v3.html
TL,DR:
MMX
On Fri, 2017-03-17 at 18:05 +0100, O. Hartmann wrote:
> Am Wed, 15 Mar 2017 13:12:37 -0700
> Cy Schubert schrieb:
>
> >
> > Hi O.Hartmann,
> >
> > I'll try to answer as much as I can in the noon hour I have left.
> >
> > In message <20170315071724.78bb0...@freyja.zeit4.iv.bundesimmobilie
> > n
Am Fri, 17 Mar 2017 20:07:35 +0300
Slawa Olhovchenkov schrieb:
> On Fri, Mar 17, 2017 at 05:53:24PM +0100, O. Hartmann wrote:
>
> > Am Fri, 17 Mar 2017 15:04:29 +0300
> > Slawa Olhovchenkov schrieb:
> >
> > > On Fri, Mar 17, 2017 at 12:36:25PM +0100, O. Hartmann wrote:
> > >
> > > > Runni
On Fri, Mar 17, 2017 at 05:53:24PM +0100, O. Hartmann wrote:
> Am Fri, 17 Mar 2017 15:04:29 +0300
> Slawa Olhovchenkov schrieb:
>
> > On Fri, Mar 17, 2017 at 12:36:25PM +0100, O. Hartmann wrote:
> >
> > > Running recent CURRENT on a Fujitsu Celsius M740 equipted with an Intel(R)
> > > Xeon(R) C
Am Wed, 15 Mar 2017 13:12:37 -0700
Cy Schubert schrieb:
> Hi O.Hartmann,
>
> I'll try to answer as much as I can in the noon hour I have left.
>
> In message <20170315071724.78bb0...@freyja.zeit4.iv.bundesimmobilien.de>,
> "O. H
> artmann" writes:
> > Running a host with several jails on recen
On 2017-03-17 12:53, O. Hartmann wrote:
> Am Fri, 17 Mar 2017 15:04:29 +0300
> Slawa Olhovchenkov schrieb:
>
>> On Fri, Mar 17, 2017 at 12:36:25PM +0100, O. Hartmann wrote:
>>
>>> Running recent CURRENT on a Fujitsu Celsius M740 equipted with an Intel(R)
>>> Xeon(R) CPU E5-1650 v3 @ 3.50GHz CPU m
Am Fri, 17 Mar 2017 15:04:29 +0300
Slawa Olhovchenkov schrieb:
> On Fri, Mar 17, 2017 at 12:36:25PM +0100, O. Hartmann wrote:
>
> > Running recent CURRENT on a Fujitsu Celsius M740 equipted with an Intel(R)
> > Xeon(R) CPU E5-1650 v3 @ 3.50GHz CPU makes me some trouble.
> >
> > FreeBSD does not
Am Fri, 17 Mar 2017 14:15:01 +0100
Alexander Leidinger schrieb:
> Quoting "O. Hartmann" (from Fri, 17 Mar 2017
> 12:20:18 +0100):
>
> > Since the introduction of the IFLIB changes, I realise severe problems on
> > CURRENT.
>
> I already reported something like this to sbruno@ and M. Macy (
On Fri, Mar 17, 2017 at 01:53:46PM +, Rick Macklem wrote:
> Well, I don't mind adding ncl_flush(), but it shouldn't be
> necessary. I actually had it in the first
> rendition of the patch, but took it out because it should happen
> on the VOP_CLOSE() if any writing to the buffer cache happened
Well, I don't mind adding ncl_flush(), but it shouldn't be
necessary. I actually had it in the first
rendition of the patch, but took it out because it should happen
on the VOP_CLOSE() if any writing to the buffer cache happened
and that code hasn't changed in many years.
What the patch was missin
Quoting "O. Hartmann" (from Fri, 17 Mar 2017
12:20:18 +0100):
Since the introduction of the IFLIB changes, I realise severe problems on
CURRENT.
I already reported something like this to sbruno@ and M. Macy (in copy).
Running the most recent CURRENT (FreeBSD 12.0-CURRENT #27 r315442: Fri
On Fri, Mar 17, 2017 at 12:36:25PM +0100, O. Hartmann wrote:
> Running recent CURRENT on a Fujitsu Celsius M740 equipted with an Intel(R)
> Xeon(R) CPU E5-1650 v3 @ 3.50GHz CPU makes me some trouble.
>
> FreeBSD does not report the existence or availability of AES-NI feature, which
> is supposed
Running recent CURRENT on a Fujitsu Celsius M740 equipted with an Intel(R)
Xeon(R) CPU E5-1650 v3 @ 3.50GHz CPU makes me some trouble.
FreeBSD does not report the existence or availability of AES-NI feature, which
is supposed to be a feature of this type of CPU:
dmesg
[...]
FreeBSD clang version
from /var/log/messages OR the periodic run OR both
Still daily lockups in Xorg when browsers open, sometimes when not.
+ __stack_chk_init(0)... random: unblocking device.
+done.
+#3 0xb752ad7e at os_acquire_mutex+0x3e
+#4 0xb7434583 at _nv019165rm+0xb
+Expensive timeout(9) function: 0xb55a7b4
Since the introduction of the IFLIB changes, I realise severe problems on
CURRENT.
Running the most recent CURRENT (FreeBSD 12.0-CURRENT #27 r315442: Fri Mar 17
10:46:04 CET 2017 amd64), the problems on a workstation got severe within the
past two days:
since a couple of weeks the em0 NIC (Intel
On Fri, Mar 17, 2017 at 03:10:57AM +, Rick Macklem wrote:
> Hope you don't mind a top post...
> Attached is a little patch you could test maybe?
>
> rick
>
> From: owner-freebsd-curr...@freebsd.org
> on behalf of Rick Macklem
> Sent: Thursday, March
30 matches
Mail list logo
