Re: cron/python3: python script acts weird, no debug output
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}
>
^
The line which specifies PATH is wrong in your crontab. See:
https://lists.freebsd.org/pipermail/freebsd-python/2015-June/008384.html
--
Craig
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: freebsd-head: suddenly NMI panics lead to ddb being unable to stop CPUs?
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 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 being > >> the CPU ID) or something > > cpu_spinwait() is defined as ia32_pause() on i386 and amd64. > > > > The problem is that ONLY x86 arches benefit from cpu_spinwait(), it's > > just a nop on other arches, which turn into little radiant heaters for > > long spins (like while waiting for APs to be released). > > remind me again why it cant spin with a 'halt' instruction? Because interrupts are disabled. Even NMI is disabled, because spin happens in the NMI handler. There is no way to wake up CPU from the halted state. ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: freebsd-head: suddenly NMI panics lead to ddb being unable to stop CPUs?
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 when the CPUs are spinning..) make each spin with the pause instruction.. and for N seconds (N being the CPU ID) or something cpu_spinwait() is defined as ia32_pause() on i386 and amd64. The problem is that ONLY x86 arches benefit from cpu_spinwait(), it's just a nop on other arches, which turn into little radiant heaters for long spins (like while waiting for APs to be released). remind me again why it cant spin with a 'halt' instruction? On ARM we have a really nice wait-for-event/signal-event pair of instructions, where WFE would be a natural for cpu_spinwait(), but would require a matching cpu_spinwake() type call to be sprinkled around to do the matching SEV instruction. -- Ian ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
FreeBSD_HEAD-tests - Build #1309 - Fixed
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: No changes ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: freebsd-head: suddenly NMI panics lead to ddb being unable to stop CPUs?
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 spinning..) > > > make each spin with the pause instruction.. and for N seconds (N being > the CPU ID) or something cpu_spinwait() is defined as ia32_pause() on i386 and amd64. The problem is that ONLY x86 arches benefit from cpu_spinwait(), it's just a nop on other arches, which turn into little radiant heaters for long spins (like while waiting for APs to be released). On ARM we have a really nice wait-for-event/signal-event pair of instructions, where WFE would be a natural for cpu_spinwait(), but would require a matching cpu_spinwake() type call to be sprinkled around to do the matching SEV instruction. -- Ian ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: freebsd-head: suddenly NMI panics lead to ddb being unable to stop CPUs?
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 each spin with the pause instruction.. and for N seconds (N being the > CPU ID) or something The patch (at the link below) does use the pause instruction. The CPU has to spin as long as any CPU is in the debugger. >> On 21 August 2015 at 08:19, Eric van Gyzen wrote: >>> 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 >>> ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: freebsd-head: suddenly NMI panics lead to ddb being unable to stop CPUs?
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. 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 months ago. > > It happens for any NMI: entering the debugger, a PCI Parity or System Error, > a hardware watchdog timeout, and probably other sources I'm not remembering. > > Eric > > On 08/21/2015 09:23, Ryan Stone wrote: >> 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 stop properly. >> >> The case that I saw actually had to do with a panic triggered by an NMI, >> not entering the debugger, but I believe that both cases use >> stop_cpus_hard() under the hood and have a similar issue. >> >> (I also recall seeing the exact situation that you describe while >> originally developing SR-IOV on an alpha version of the Fortville hardware >> and firmware with a very buggy SR-IOV implementation. I've never seen it >> on ixgbe before, although I haven't used SR-IOV there very much at all) >> >> >> On Thu, Aug 20, 2015 at 6:15 PM, Adrian Chadd wrote: >> >>> Hi! >>> >>> This has started happening on -HEAD recently. No, I don't have any >>> more details yet than "recently." >>> >>> Whenever I get an NMI panic (and getting an NMI is a separate issue, >>> sigh) I get a slew of "failed to stop cpu" messages, and all CPUs >>> enter ddb. This is .. sub-optimal. Has anyone seen this? Does anyone >>> have any ideas? >>> >>> >>> -adrian > ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: freebsd-head: suddenly NMI panics lead to ddb being unable to stop CPUs?
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 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 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 months ago. >> >> It happens for any NMI: entering the debugger, a PCI Parity or System >> Error, a hardware watchdog timeout, and probably other sources I'm not >> remembering. >> >> Eric >> >> On 08/21/2015 09:23, Ryan Stone wrote: >>> 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 stop properly. >>> >>> The case that I saw actually had to do with a panic triggered by an NMI, >>> not entering the debugger, but I believe that both cases use >>> stop_cpus_hard() under the hood and have a similar issue. >>> >>> (I also recall seeing the exact situation that you describe while >>> originally developing SR-IOV on an alpha version of the Fortville hardware >>> and firmware with a very buggy SR-IOV implementation. I've never seen it >>> on ixgbe before, although I haven't used SR-IOV there very much at all) >>> >>> >>> On Thu, Aug 20, 2015 at 6:15 PM, Adrian Chadd wrote: >>> Hi! This has started happening on -HEAD recently. No, I don't have any more details yet than "recently." Whenever I get an NMI panic (and getting an NMI is a separate issue, sigh) I get a slew of "failed to stop cpu" messages, and all CPUs enter ddb. This is .. sub-optimal. Has anyone seen this? Does anyone have any ideas? -adrian >> > ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: freebsd-head: suddenly NMI panics lead to ddb being unable to stop CPUs?
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 being the CPU ID) or something -a On 21 August 2015 at 08:19, Eric van Gyzen wrote: 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 months ago. It happens for any NMI: entering the debugger, a PCI Parity or System Error, a hardware watchdog timeout, and probably other sources I'm not remembering. Eric On 08/21/2015 09:23, Ryan Stone wrote: 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 stop properly. The case that I saw actually had to do with a panic triggered by an NMI, not entering the debugger, but I believe that both cases use stop_cpus_hard() under the hood and have a similar issue. (I also recall seeing the exact situation that you describe while originally developing SR-IOV on an alpha version of the Fortville hardware and firmware with a very buggy SR-IOV implementation. I've never seen it on ixgbe before, although I haven't used SR-IOV there very much at all) On Thu, Aug 20, 2015 at 6:15 PM, Adrian Chadd wrote: Hi! This has started happening on -HEAD recently. No, I don't have any more details yet than "recently." Whenever I get an NMI panic (and getting an NMI is a separate issue, sigh) I get a slew of "failed to stop cpu" messages, and all CPUs enter ddb. This is .. sub-optimal. Has anyone seen this? Does anyone have any ideas? -adrian ___ freebsd-a...@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-arch To unsubscribe, send any mail to "freebsd-arch-unsubscr...@freebsd.org" ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
cron/python3: python script acts weird, no debug output
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 simple, using NanoBSD built from CURRENT:
11.0-CURRENT FreeBSD 11.0-CURRENT #1 r286948: Thu Aug 20 05:50:45 CEST 2015
amd64
and double-checked setting of the OS running from an USB flash drive, / is r/w,
enough space left et cetera.
I managed to install packe lang/python3 and all of its dependencies as compiled
with the same base system as NanoBSD is built from - so from hereof no problems
should arise.
The python3 script comprises from several files, main.py and some files with
subroutines, all located in the same directory (~/bin) of a certain user's
home. The script looks for files on a memory files system backed folder/drive
and moves them, if any, towards a smbfs share provided by a M$ 2012R2 server,
mounted via autofs. So far, no problem.
Login as the specified user and running the script via "python3 bin/main.py"
works like a charme.
That specific user has an existing /var/cron/allow entry and
the /var/cron/tabs/user_foo file with the cronjob description exists, too. So
far, no irregularity.
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}
*/1 * * * * /usr/local/bin/python3 /home/user_foo/bin/main.py --src /mfs/src \
-dst /mnt/server_slot
I tried also other variants, having in mind that cron has a very limited
inheritage of the environment, like
*/1 * * * * cd /hom,e/user/foo/bin && /usr/local/bin/python3 main.py
--src /mfs/src \ -dst /mnt/server_slot
so the python3 script may find its pieces.
But whenever the cronjob starts, I see the first messages as output from the
script, some jumps into subroutines (I use classes from os, sys), but then,
suddenly, the output dies. Simply dies. this happens then when the job seems to
find files it should move. this is indicated by the fact that I printout
Start (time):
End (time):
but END: (time) then never is seen on console or syslog (I delegate everything
with prio debug to console and a syslog server).
It looks like the python3 job suffers from severe lack in resources and isn't
capable of even send out some agony messages.
I'm floating like a dead man in the water and the rare hairs got more gray
coloured over the past days finding a solution. maybe I'm missing something
with cron/python3?
Hopefully someone finds the simple answer I'm seeking.
regards,
Oliver
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: freebsd-head: suddenly NMI panics lead to ddb being unable to stop CPUs?
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 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 months ago. > > It happens for any NMI: entering the debugger, a PCI Parity or System Error, > a hardware watchdog timeout, and probably other sources I'm not remembering. > > Eric > > On 08/21/2015 09:23, Ryan Stone wrote: >> 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 stop properly. >> >> The case that I saw actually had to do with a panic triggered by an NMI, >> not entering the debugger, but I believe that both cases use >> stop_cpus_hard() under the hood and have a similar issue. >> >> (I also recall seeing the exact situation that you describe while >> originally developing SR-IOV on an alpha version of the Fortville hardware >> and firmware with a very buggy SR-IOV implementation. I've never seen it >> on ixgbe before, although I haven't used SR-IOV there very much at all) >> >> >> On Thu, Aug 20, 2015 at 6:15 PM, Adrian Chadd wrote: >> >>> Hi! >>> >>> This has started happening on -HEAD recently. No, I don't have any >>> more details yet than "recently." >>> >>> Whenever I get an NMI panic (and getting an NMI is a separate issue, >>> sigh) I get a slew of "failed to stop cpu" messages, and all CPUs >>> enter ddb. This is .. sub-optimal. Has anyone seen this? Does anyone >>> have any ideas? >>> >>> >>> -adrian > ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: freebsd-head: suddenly NMI panics lead to ddb being unable to stop CPUs?
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 months ago. It happens for any NMI: entering the debugger, a PCI Parity or System Error, a hardware watchdog timeout, and probably other sources I'm not remembering. Eric On 08/21/2015 09:23, Ryan Stone wrote: > 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 stop properly. > > The case that I saw actually had to do with a panic triggered by an NMI, > not entering the debugger, but I believe that both cases use > stop_cpus_hard() under the hood and have a similar issue. > > (I also recall seeing the exact situation that you describe while > originally developing SR-IOV on an alpha version of the Fortville hardware > and firmware with a very buggy SR-IOV implementation. I've never seen it > on ixgbe before, although I haven't used SR-IOV there very much at all) > > > On Thu, Aug 20, 2015 at 6:15 PM, Adrian Chadd wrote: > >> Hi! >> >> This has started happening on -HEAD recently. No, I don't have any >> more details yet than "recently." >> >> Whenever I get an NMI panic (and getting an NMI is a separate issue, >> sigh) I get a slew of "failed to stop cpu" messages, and all CPUs >> enter ddb. This is .. sub-optimal. Has anyone seen this? Does anyone >> have any ideas? >> >> >> -adrian ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: pw: pw: Invalid min_uid: '2000'; ignoring
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 > > > > which finally and successfully expands to > > > > [...] > > # Range of valid default user ids > > minuid = 2000 > > maxuid = 32767 > > > > # Range of valid default group ids > > mingid = 2000 > > maxgid = 32767 > > [...] > > > > as expected. > > > > Adding or changing now a user within such an environment gives me > > > > pw: Invalid min_uid: '2000'; ignoring > > pw: Invalid max_uid: '32767'; ignoring > > pw: Invalid min_gid: '2000'; ignoring > > pw: Invalid max_gid: '32767'; ignoring > > > > which is obviously not correct. > > > > Since pw has undergone severe maintenance, I consider this a bug. > > This is a bug for sure. > > I'll fix asap. > > Bapt Fixed in r286993 Best regards, Bapt pgpaatl88f7AG.pgp Description: PGP signature
Re: freebsd-head: suddenly NMI panics lead to ddb being unable to stop CPUs?
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 stop properly. The case that I saw actually had to do with a panic triggered by an NMI, not entering the debugger, but I believe that both cases use stop_cpus_hard() under the hood and have a similar issue. (I also recall seeing the exact situation that you describe while originally developing SR-IOV on an alpha version of the Fortville hardware and firmware with a very buggy SR-IOV implementation. I've never seen it on ixgbe before, although I haven't used SR-IOV there very much at all) On Thu, Aug 20, 2015 at 6:15 PM, Adrian Chadd wrote: > Hi! > > This has started happening on -HEAD recently. No, I don't have any > more details yet than "recently." > > Whenever I get an NMI panic (and getting an NMI is a separate issue, > sigh) I get a slew of "failed to stop cpu" messages, and all CPUs > enter ddb. This is .. sub-optimal. Has anyone seen this? Does anyone > have any ideas? > > > -adrian > ___ > freebsd-a...@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-arch > To unsubscribe, send any mail to "freebsd-arch-unsubscr...@freebsd.org" > ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: pw: pw: Invalid min_uid: '2000'; ignoring
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 ids > minuid = 2000 > maxuid = 32767 > > # Range of valid default group ids > mingid = 2000 > maxgid = 32767 > [...] > > as expected. > > Adding or changing now a user within such an environment gives me > > pw: Invalid min_uid: '2000'; ignoring > pw: Invalid max_uid: '32767'; ignoring > pw: Invalid min_gid: '2000'; ignoring > pw: Invalid max_gid: '32767'; ignoring > > which is obviously not correct. > > Since pw has undergone severe maintenance, I consider this a bug. This is a bug for sure. I'll fix asap. Bapt pgplV7HbVt46e.pgp Description: PGP signature
pw: pw: Invalid min_uid: '2000'; ignoring
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 maxgid = 32767 [...] as expected. Adding or changing now a user within such an environment gives me pw: Invalid min_uid: '2000'; ignoring pw: Invalid max_uid: '32767'; ignoring pw: Invalid min_gid: '2000'; ignoring pw: Invalid max_gid: '32767'; ignoring which is obviously not correct. Since pw has undergone severe maintenance, I consider this a bug. Regards, Oliver ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: 11-CURRENT build fail with base gcc
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 two clang specific args I needed to move, not just the one that’s > in this > flag. Maybe things are over-specified? > > Not sure I like bsd.cpu.mk growing more name-space pollution, especially > stuff that > isn’t documented somewhere (bsd.cpu.mk is included from sys.mk, which is > automaticallyed > globally included). I couldn't find any _good_ place for it, so I stuck it in the least bad place. I also didn't know where to document it. I'll gladly move it and document it if someone can suggest good locations. > All these hacks being stashed hither and yon are starting to get > very hard to keep straight for someone who looks at this code every day, let > alone > somebody who invested CFLAGS_NO_SIMD independently for their code and finds > that breaks in an upgrade... ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Jack not working: Bus error
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 ABSOLUTELY NO WARRANTY This is free software, and you are welcome to redistribute it under certain conditions; see the file COPYING for details JACK compiled with System V SHM support. loading driver .. Bus error (End) Can somebody help me? Can I help somebody? Am I missing something? Thanks! ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
FreeBSD_HEAD-tests - Build #1308 - Unstable
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 summaries: No changes The failed test cases: 1 tests failed. FAILED: usr.sbin.pw.pw_useradd.user_add_skel Error Message: File not created ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: CPU Perf & Power Mgt
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://wiki.freebsd.org/201506DevSummit/ClockDomains > > In short, the goal is to add infrastructure to the kernel to support > overall power management of the system, scaling beyond cpufreq/powerd. > Looking for volunteers who could do some of this, due to my lack of > time to work on it. We also had a power management meeting at BSDCam this week. Robin presented some slides (though the download seems to be broken for me at the moment): https://wiki.freebsd.org/201508DevSummit?action=AttachFile&do=get&target=power-management-for-freebsd-bsdcam-2015.pdf This includes the design that ARM is trying to push into Linux, which looks like it would be adaptable to FreeBSD (and, on the plus side, our complete lack of existing power management in the kernel already means we don’t already have the legacy stuff that they are fighting in Linux). The goal is to have the scheduler drive all of the (CPU) power management. Any volunteers to work on this are welcome - ARM people are happy to provide advice. David ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Building world with WITHOUT_SSP set broken?
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: >>> stage 2.3: build tools -- cd /usr/subversion-src; MAKEOBJDIRPREFIX=/usr/obj INSTALL="sh /usr/subversion-src/tools/install.sh" PATH=/usr/obj/usr/subversion-src/tmp/legacy/usr/sbin:/usr/obj/usr/subversion-src/tmp/legacy/usr/bin:/usr/obj/usr/subversion-src/tmp/legacy/bin:/sbin:/bin:/usr/sbin:/usr/bin WORLDTMP=/usr/obj/usr/subversion-src/tmp VERSION="FreeBSD 11.0-CURRENT amd64 1100079" MAKEFLAGS="-m /usr/subversion-src/tools/build/mk -m /usr/subversion-src/share/mk" make -f Makefile.inc1 TARGET=amd64 TARGET_ARCH=amd64 DESTDIR= BOOTSTRAPPING=1100077 SSP_CFLAGS= -DNO_LINT -DNO_CPU_CFLAGS MK_WARNS=no MK_CTF=no MK_CLANG_EXTRAS=no MK_CLANG_FULL=no MK_LLDB=no MK_TESTS=no build-tools ===> bin/csh (obj,build-tools) ===> bin/sh (obj,build-tools) cc -O2 -pipe -DSTRIP_FBSDID -DSHELL -I. -I/usr/subversion-src/bin/sh -std=gnu99 -Qunused-arguments -I/usr/obj/usr/subversion-src/tmp/legacy/usr/include -c /usr/subversion-src/bin/sh/mknodes.c -o mknodes.o cc -O2 -pipe -DSTRIP_FBSDID -DSHELL -I. -I/usr/subversion-src/bin/sh -std=gnu99 -Qunused-arguments -I/usr/obj/usr/subversion-src/tmp/legacy/usr/include -L/usr/obj/usr/subversion-src/tmp/legacy/usr/lib mknodes.o -o mknodes /usr/bin/ld: cannot find libssp_nonshared.a cc: error: linker command failed with exit code 1 (use -v to see invocation) *** Error code 1 Stop. make[3]: stopped in /usr/subversion-src/bin/sh *** Error code 1 Stop. make[2]: stopped in /usr/subversion-src *** Error code 1 Stop. make[1]: stopped in /usr/subversion-src *** Error code 1 Stop. make: stopped in /usr/subversion-src pgpruB25_BDD8.pgp Description: PGP signature
Re: AMD64 disk1.iso dont create /home (/usr/home)
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 might be a corner > case Fixed in r286982 Sorry about the regression. Bapt pgpXawbkaxb84.pgp Description: PGP signature
