On Fri, Aug 21, 2015 at 03:59:28PM +1000, Outback Dingo wrote:
> On Fri, Aug 21, 2015 at 3:57 PM, Kevin Lo wrote:
>
> > I hit this and poked bapt@ two weeks ago, he said he couldn't reproduce
> > this problem...
> >
> > Kevin
> >
>
>
> Well seems three people just confirmed it exists...
Hi there,
I just tried to do a buildworld with a current svn checkout (r286978). However
it appears that world fails with WITHOUT_SSP set.
I'm currently running r284582, so the SSP issue must have been introduced
somewhere between those two revision.
Cheers
Alexander
Here's the error log:
>>
On 20 Aug 2015, at 17:44, Justin Hibbits wrote:
>
> There was a working group at BSDCan this year on power management, and
> what we need to / can do to bring it up to par with the modern world.
> Unfortunately, I haven't had any time lately to work on it, but you
> can read the notes at
> https:
FreeBSD_HEAD-tests - Build #1308 - Unstable:
Build information: https://jenkins.FreeBSD.org/job/FreeBSD_HEAD-tests/1308/
Full change log: https://jenkins.FreeBSD.org/job/FreeBSD_HEAD-tests/1308/changes
Full build log: https://jenkins.FreeBSD.org/job/FreeBSD_HEAD-tests/1308/console
Change summarie
I tried ports and packages. I get the same on both. Tried as normal user and
superuser. Same results.
Console sample:
(Start)
/usr/local/bin/jackd -r -doss -r48000 -p1024 -n2 -w16
jackd 0.124.1
Copyright 2001-2009 Paul Davis, Stephane Letz, Jack O'Quinn, Torben Hohn and
others.
jackd comes with
On 08/20/2015 14:21, Warner Losh wrote:
>
>> On Aug 20, 2015, at 10:32 AM, Dimitry Andric wrote:
>>
>> Ah, this should be replaced with the recently introduced CFLAGS_NO_SIMD
>> variable, then?
>
> Perhaps. Didn’t know this was a thing. That could use useful many places,
> though
> there were t
Setting up on NanoBSD vi pw command an initial /etc/pw.conf (usermod -D), I use
amongst other options also:
-u 2000,32767 -i 2000,32767
which finally and successfully expands to
[...]
# Range of valid default user ids
minuid = 2000
maxuid = 32767
# Range of valid default group ids
mingid = 2000
On Fri, Aug 21, 2015 at 03:48:13PM +0200, O. Hartmann wrote:
> Setting up on NanoBSD vi pw command an initial /etc/pw.conf (usermod -D), I
> use
> amongst other options also:
>
> -u 2000,32767 -i 2000,32767
>
> which finally and successfully expands to
>
> [...]
> # Range of valid default user
I have seen similar behaviour before. The problem is that every CPU
receives an NMI concurrently. As I recall, one of them gets some kind of
pseudo-spinlock and tries to stop the other CPUs with an NMI. However,
because they are already in an NMI handler, they don't get the second NMI
and don't
On Fri, Aug 21, 2015 at 04:13:00PM +0200, Baptiste Daroussin wrote:
> On Fri, Aug 21, 2015 at 03:48:13PM +0200, O. Hartmann wrote:
> > Setting up on NanoBSD vi pw command an initial /etc/pw.conf (usermod -D), I
> > use
> > amongst other options also:
> >
> > -u 2000,32767 -i 2000,32767
> >
> > w
I mentioned this to Adrian, but I'll mention here for everyone else's benefit.
Ryan is exactly right. There was a thread a while ago, with a proposed patch
from Kostik:
https://lists.freebsd.org/pipermail/freebsd-arch/2014-July/015584.html
As I recall, Scott Long also ran into this a few month
Ah, cool. I'll give it a whirl.
I'm a little worried about having all of the other cores spinning in
this case (mostly thermal; the machines get VERY LOUD when the CPUs
are spinning..)
-a
On 21 August 2015 at 08:19, Eric van Gyzen wrote:
> I mentioned this to Adrian, but I'll mention here for
I put this in this list, hopefully to find an answer.
Using a setup of NanoBSD as the platform for a small application written in
Python 3.4, which is supposed to run via cron and with UID of a special user, I
run into very nasty "non responsivnes" behaviour of the cron application.
The setup is
On 8/21/15 11:25 PM, Adrian Chadd wrote:
Ah, cool. I'll give it a whirl.
I'm a little worried about having all of the other cores spinning in
this case (mostly thermal; the machines get VERY LOUD when the CPUs
are spinning..)
make each spin with the pause instruction.. and for N seconds (N bein
Spinning is probably the only safe option in NMI context, since the NMI could
have arrived at literally any time in any context (e.g. holding a spin lock,
interrupts disabled). :-/
Eric
On 08/21/2015 10:25, Adrian Chadd wrote:
> Ah, cool. I'll give it a whirl.
>
> I'm a little worried about h
I might have a fix for this, I’ll check the netflix repo and see if it’s
something that is ready to go upstream to freebsd.
Scott
> On Aug 21, 2015, at 4:19 PM, Eric van Gyzen wrote:
>
> I mentioned this to Adrian, but I'll mention here for everyone else's benefit.
>
> Ryan is exactly right.
On 08/21/2015 10:30, Julian Elischer wrote:
> On 8/21/15 11:25 PM, Adrian Chadd wrote:
>> Ah, cool. I'll give it a whirl.
>>
>> I'm a little worried about having all of the other cores spinning in
>> this case (mostly thermal; the machines get VERY LOUD when the CPUs
>> are spinning..)
>>
> make ea
On Fri, 2015-08-21 at 23:30 +0800, Julian Elischer wrote:
> On 8/21/15 11:25 PM, Adrian Chadd wrote:
> > Ah, cool. I'll give it a whirl.
> >
> > I'm a little worried about having all of the other cores spinning in
> > this case (mostly thermal; the machines get VERY LOUD when the CPUs
> > are spinn
FreeBSD_HEAD-tests - Build #1309 - Fixed:
Build information: https://jenkins.FreeBSD.org/job/FreeBSD_HEAD-tests/1309/
Full change log: https://jenkins.FreeBSD.org/job/FreeBSD_HEAD-tests/1309/changes
Full build log: https://jenkins.FreeBSD.org/job/FreeBSD_HEAD-tests/1309/console
Change summaries:
On 8/22/15 12:23 AM, Ian Lepore wrote:
On Fri, 2015-08-21 at 23:30 +0800, Julian Elischer wrote:
On 8/21/15 11:25 PM, Adrian Chadd wrote:
Ah, cool. I'll give it a whirl.
I'm a little worried about having all of the other cores spinning in
this case (mostly thermal; the machines get VERY LOUD w
On Sat, Aug 22, 2015 at 12:53:15AM +0800, Julian Elischer wrote:
> On 8/22/15 12:23 AM, Ian Lepore wrote:
> > On Fri, 2015-08-21 at 23:30 +0800, Julian Elischer wrote:
> >> On 8/21/15 11:25 PM, Adrian Chadd wrote:
> >>> Ah, cool. I'll give it a whirl.
> >>>
> >>> I'm a little worried about having a
On Fri, Aug 21, 2015 at 8:20 AM, O. Hartmann
wrote:
> When the job is run from cron, the situation changes dramatically. The
> setup is
> like this:
>
> SHELL=/bin/sh
> TZ=Europe/Berlin
> MAILTO=""
> PATH=/usr/local/bin:/usr/local/sbin:${PATH}
>
22 matches
Mail list logo
