Jenkins build is back to stable : FreeBSD_HEAD-tests2 #639
See https://jenkins.freebsd.org/job/FreeBSD_HEAD-tests2/639/ ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: libc.so dependency on libssp_nonshared.a
On Feb 2, 2015, at 23:47, Gleb Kurtsou g...@freebsd.org wrote: On (02/02/2015 17:06), Jeremie Le Hen wrote: Hi Gleb, On Sun, Feb 1, 2015 at 9:24 PM, Gleb Kurtsou g...@freebsd.org wrote: I came across some build issues in libc.so and SSP. libc.ldscript (aka libc.so) unconditionally includes @@LIBDIR@@/libssp_nonshared.a libssp* are not built if WITHOUT_SSP defined. ObsoleteFiles.inc doesn't mention libssp*. Consider WITHOUT_SSP=yes case. As soon as one does clean installworld and/or removes stale libssp_nonshared.a ld fails to link anything because of missing libssp_nonshared.a I think nowadays it would make sense to get it of WITHOUT_SSP altogether. This will turn this into a non-issue. Do you mean building libssp_nonshared unconditionally? It makes perfect sense. The library is a single stub function. By building libssp* conditionally we may expect that -fstack-protector complier option won't work. I wasn't able to reproduce this potential problem. libc provides __stack_chk_fail and __stack_chk_guard. And I failed to create a test case that would generate code using anything like __memcpy_chk. Perhaps we should change MK_SSP to operate as documented (add -fstack-protector to CFLAGS) and consider adding MK_SSP_SUPPORT option for libraries. Although there is no reason to have MK_SSP_SUPPORT if that would imply failure to run binaries or compile with -fstack-protector. Silly question: shouldn’t libc.ldscript be built, conditionally with libssp_nonshared.a? Doing that would be trivial… Are there any concerns with doing this? signature.asc Description: Message signed with OpenPGP using GPGMail
Re: tzsetup chroot
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
On 02/03/15 17:05, Nick Frampton wrote:
We have our own FreeBSD 10.1 installation script in which we call
tzsetup.
I'm seeing different behaviour in tzsetup between these two
invocations:
tzsetup -C /mnt chroot /mnt /usr/sbin/tzsetup
With the -C option, no matter which time zone I select, it asks:
Does the abbreviation 'UTC' look reasonable?
Using chroot, I get the expected behaviour, e.g. selecting
America/New_York:
Does the abbreviation 'EST' look reasonable?
/mnt contains the contents of base.txz, so it looks like all the
zoneinfo files are there.
Could you please submit a bug ticket for this?
It looks like what happens is that tzsetup does not really do a
chroot(2) system call. Instead, it simulated the effect by prefixing
all paths with the chroot environment.
The problem is that when tzsetup is going to verify your
configuration, it would use tzset(3), which does not respect the
simulated chroot effect. When no zoneinfo data is present, everything
would be considered as UTC.
Attached is an dirty hack (ugly enough that I don't wish to commit)
that changes tzsetup to use chroot instead, which should fix the
problem. I'm not very satisfied with it as it does chroot() before
doing init_dialog, which may well fail as the devfs is not necessarily
mounted in the chroot, and on the other hand all termcap related data
would be sourced from the chroot, which is probably an undesirable
side effect.
Cheers,
- --
Xin LI delp...@delphij.nethttps://www.delphij.net/
FreeBSD - The Power to Serve! Live free or die
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.1.1 (FreeBSD)
iQIcBAEBCgAGBQJU0X+zAAoJEJW2GBstM+nsfpwQAIwPBj11lzJS662RPBPQR6dB
vb3gCGJjqRANCD+Sr8EqxzPlKOcC4UiBB5Khy39lidC+d4qgGQ3Mz3qIwjCdl3Aw
KUzkFfhvspGzE25tIwsPJ3A00NjXNJGqGqcDMitfls4SdYZWzCgs+gwa3zGq+yO3
/pPMQVVhhBz2pgkqxCtznFqY9paN5lzwaOqp9HepNz1g99Q4u+KpIUI93BMcMdMD
9HtY7YQYzDCnhi4OskdIB2BrLm1NSFPMkALASTMuCplFwtyI+emYD/GzOwUF5zay
Vk4QQ33Z9G1pw6jU730kFl/FU5tps35leUYUMcgiz2CG9DTz/wFRJ4SjwD4b1NYx
35nwbrhnp5TV4g94zFfY1NejSwmCpdzq5fvSYwu73yQ+pzwqA2xjXGMwICEo95Tj
Zop/T9gU3g2Hglmz6zTe7m4EXdruFZrADlI6K6cPg/52HosSi7iLnkebwX0nClbQ
HQeCdved38nzRBDZGaJmrDebHD3Uy+qrP5dxTaDe49JZZ+lnkceqy5s+OLQb78S3
Wt9q6GgdKLwa157K74ci/T3rSnty+dJlOXlaq2Bhbru8O7GGmIcmMtsAYzI7+C0z
0cuqsI2sXvT6i/XSjt2VK0D/aQfJ0NfpWDJ6rtlAnFc0g5UBncd8MrAfWo/KOPdH
nIdamgVfmtHcglu07fBq
=0pwZ
-END PGP SIGNATURE-
Index: tzsetup.c
===
--- tzsetup.c (revision 278173)
+++ tzsetup.c (working copy)
@@ -40,6 +40,7 @@ __FBSDID($FreeBSD$);
#include stdio.h
#include stdlib.h
#include string.h
+#include sysexits.h
#include time.h
#include unistd.h
@@ -944,24 +945,19 @@ main(int argc, char **argv)
if (argc - optind 1)
usage();
- if (chrootenv == NULL) {
- strcpy(path_zonetab, _PATH_ZONETAB);
- strcpy(path_iso3166, _PATH_ISO3166);
- strcpy(path_zoneinfo, _PATH_ZONEINFO);
- strcpy(path_localtime, _PATH_LOCALTIME);
- strcpy(path_db, _PATH_DB);
- strcpy(path_wall_cmos_clock, _PATH_WALL_CMOS_CLOCK);
- } else {
- sprintf(path_zonetab, %s/%s, chrootenv, _PATH_ZONETAB);
- sprintf(path_iso3166, %s/%s, chrootenv, _PATH_ISO3166);
- sprintf(path_zoneinfo, %s/%s, chrootenv, _PATH_ZONEINFO);
- sprintf(path_localtime, %s/%s, chrootenv, _PATH_LOCALTIME);
- sprintf(path_db, %s/%s, chrootenv, _PATH_DB);
- sprintf(path_wall_cmos_clock, %s/%s, chrootenv,
- _PATH_WALL_CMOS_CLOCK);
+ strcpy(path_zonetab, _PATH_ZONETAB);
+ strcpy(path_iso3166, _PATH_ISO3166);
+ strcpy(path_zoneinfo, _PATH_ZONEINFO);
+ strcpy(path_localtime, _PATH_LOCALTIME);
+ strcpy(path_db, _PATH_DB);
+ strcpy(path_wall_cmos_clock, _PATH_WALL_CMOS_CLOCK);
+
+ if (chrootenv != NULL) {
+ rv = chroot(chrootenv);
+ if (rv != 0)
+ err(EX_OSERR, chroot to %s, chrootenv);
}
-
/* Override the user-supplied umask. */
(void)umask(S_IWGRP | S_IWOTH);
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: tzsetup - UTC user question
On Tue, Feb 03, 2015 at 03:08:38PM +1000, Paul Koch wrote: Since the default option for Select local or UTC clock changed from No to Yes, we are seeing many customers who incorrectly answer this question! This screws up things in our app because we store all data in UTC. A few observations... Most people don't know what CMOS clock is. Maybe change the wording to BIOS clock or Hardware Clock ?? The person doing the install may not know what the clock is currently set to, especially when installing in a VM. Perhaps the screen should display the current machine time so they can correctly answer the question. Why was the default changed from No to Yes ? or change ntpd_sync_on_start=YES to force correct time. in most case for hardware platform CMOS time contains garbage. ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: tzsetup - UTC user question
On 03.02.2015 13:25, Kurt Jaeger wrote: Hi! The person doing the install may not know what the clock is currently set to, especially when installing in a VM. Perhaps the screen should display the current machine time so they can correctly answer the question. Yes, this would help tremendously! Showing both would help a lot e.g. You selected %Z as local time zone. Local time is: %T %Z UTC time is: %T UTC Is this what you expected? Please bypass this screen if the user selected UTC as local time. I prefer to run my systems with UTC and a login group with :setenv=TZ=Foo/Bar,...: This avoids trouble with daylight saving and servers spread over multiple timezones. ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Build failed in Jenkins: Build-UFS-image #1024
See https://jenkins.freebsd.org/job/Build-UFS-image/1024/
--
Started by build flow Build_Image_and_Run_Tests_in_Bhyve_HEAD#673
Building remotely on jenkins-10.freebsd.org (FreeBSD-10) in workspace
https://jenkins.freebsd.org/job/Build-UFS-image/ws/
git rev-parse --is-inside-work-tree # timeout=10
Fetching changes from the remote Git repository
git config remote.origin.url https://github.com/freebsd/freebsd-ci #
timeout=10
Fetching upstream changes from https://github.com/freebsd/freebsd-ci
git --version # timeout=10
git fetch --tags --progress https://github.com/freebsd/freebsd-ci
+refs/heads/*:refs/remotes/origin/*
git rev-parse refs/remotes/origin/master^{commit} # timeout=10
git rev-parse refs/remotes/origin/origin/master^{commit} # timeout=10
Checking out Revision c4076363048e3727a9772acffc651bb19bebdb4f
(refs/remotes/origin/master)
git config core.sparsecheckout # timeout=10
git checkout -f c4076363048e3727a9772acffc651bb19bebdb4f
git rev-list c4076363048e3727a9772acffc651bb19bebdb4f # timeout=10
[Build-UFS-image] $ /bin/sh -xe /tmp/hudson7937943411931952350.sh
+ freebsd-ci/scripts/build/build-ufs-image.sh
+ [ -z https://jenkins.freebsd.org/job/Build-UFS-image/ws/ ]
+ [ -z /builds/FreeBSD_HEAD ]
+ [ -z '' ]
+ export MAKEOBJDIRPREFIX=/builds/FreeBSD_HEAD/obj
+ [ -z '' ]
+ basename /builds/FreeBSD_HEAD
+
PACKAGE_ROOT=https://jenkins.freebsd.org/job/Build-UFS-image/ws/package/FreeBSD_HEAD
+ [ -z '' ]
+ basename /builds/FreeBSD_HEAD
+
IMAGE_ROOT=https://jenkins.freebsd.org/job/Build-UFS-image/ws/image/FreeBSD_HEAD
+ [ -n '' ]
+ [ -z /builds/FreeBSD_HEAD/obj ]
+ cd /builds/FreeBSD_HEAD
+ [ -z '' ]
+ [ -f /builds/FreeBSD_HEAD/make.conf ]
+ __MAKE_CONF=/builds/FreeBSD_HEAD/make.conf
+ sudo rm -fr
https://jenkins.freebsd.org/job/Build-UFS-image/ws/package/FreeBSD_HEAD
+ mkdir -p
https://jenkins.freebsd.org/job/Build-UFS-image/ws/package/FreeBSD_HEAD
+ sudo env MAKEOBJDIRPREFIX=/builds/FreeBSD_HEAD/obj make installworld
NO_FSCHG=yes
DESTDIR=https://jenkins.freebsd.org/job/Build-UFS-image/ws/package/FreeBSD_HEAD
__MAKE_CONF=/builds/FreeBSD_HEAD/make.conf
mkdir -p /tmp/install.tyXk6tEX
progs=$(for prog in [ awk cap_mkdb cat chflags chmod chown date echo egrep
find grep id install ln lockf make mkdir mtree mv pwd_mkdb rm sed
services_mkdb sh strip sysctl test true uname wc zic tzsetup makewhatis; do
if progpath=`which $prog`; then echo $progpath; else echo Required tool
$prog not found in PATH. 2; exit 1; fi; done); libs=$(ldd -f %o %p\n
-f %o %p\n $progs 2/dev/null | sort -u | while read line; do set -- $line;
if [ $2 $3 != not found ]; then echo $2; else echo Required library $1
not found. 2; exit 1; fi; done); cp $libs $progs /tmp/install.tyXk6tEX
cp -R ${PATH_LOCALE:-/usr/share/locale} /tmp/install.tyXk6tEX/locale
cd /builds/FreeBSD_HEAD; MAKEOBJDIRPREFIX=/builds/FreeBSD_HEAD/obj
MACHINE_ARCH=amd64 MACHINE=amd64 CPUTYPE=
GROFF_BIN_PATH=/builds/FreeBSD_HEAD/obj/builds/FreeBSD_HEAD/tmp/legacy/usr/bin
GROFF_FONT_PATH=/builds/FreeBSD_HEAD/obj/builds/FreeBSD_HEAD/tmp/legacy/usr/share/groff_font
GROFF_TMAC_PATH=/builds/FreeBSD_HEAD/obj/builds/FreeBSD_HEAD/tmp/legacy/usr/share/tmac
PATH=/builds/FreeBSD_HEAD/obj/builds/FreeBSD_HEAD/tmp/legacy/usr/sbin:/builds/FreeBSD_HEAD/obj/builds/FreeBSD_HEAD/tmp/legacy/usr/bin:/builds/FreeBSD_HEAD/obj/builds/FreeBSD_HEAD/tmp/legacy/usr/games:/builds/FreeBSD_HEAD/obj/builds/FreeBSD_HEAD/tmp/legacy/bin:/builds/FreeBSD_HEAD/obj/builds/FreeBSD_HEAD/tmp/usr/sbin:/builds/FreeBSD_HEAD/obj/builds/FreeBSD_HEAD/tmp/usr/bin:/builds/FreeBSD_HEAD/obj/builds/FreeBSD_HEAD/tmp/usr/games:/tmp/install.tyXk6tEX
LD_LIBRARY_PATH=/tmp/install.tyXk6tEX
PATH_LOCALE=/tmp/install.tyXk6tEX/locale make -f Makefile.inc1
__MAKE_SHELL=/tmp/install.tyXk6tEX/sh reinstall; MAKEOBJDIRPREFIX=/
builds/FreeBSD_HEAD/obj MACHINE_ARCH=amd64 MACHINE=amd64 CPUTYPE=
GROFF_BIN_PATH=/builds/FreeBSD_HEAD/obj/builds/FreeBSD_HEAD/tmp/legacy/usr/bin
GROFF_FONT_PATH=/builds/FreeBSD_HEAD/obj/builds/FreeBSD_HEAD/tmp/legacy/usr/share/groff_font
GROFF_TMAC_PATH=/builds/FreeBSD_HEAD/obj/builds/FreeBSD_HEAD/tmp/legacy/usr/share/tmac
PATH=/builds/FreeBSD_HEAD/obj/builds/FreeBSD_HEAD/tmp/legacy/usr/sbin:/builds/FreeBSD_HEAD/obj/builds/FreeBSD_HEAD/tmp/legacy/usr/bin:/builds/FreeBSD_HEAD/obj/builds/FreeBSD_HEAD/tmp/legacy/usr/games:/builds/FreeBSD_HEAD/obj/builds/FreeBSD_HEAD/tmp/legacy/bin:/builds/FreeBSD_HEAD/obj/builds/FreeBSD_HEAD/tmp/usr/sbin:/builds/FreeBSD_HEAD/obj/builds/FreeBSD_HEAD/tmp/usr/bin:/builds/FreeBSD_HEAD/obj/builds/FreeBSD_HEAD/tmp/usr/games:/tmp/install.tyXk6tEX
LD_LIBRARY_PATH=/tmp/install.tyXk6tEX
PATH_LOCALE=/tmp/install.tyXk6tEX/locale rm -rf /tmp/install.tyXk6tEX
make[2]: /builds/FreeBSD_HEAD/share/mk/bsd.compiler.mk line 42: Unable to
determine compiler type for cc. Consider setting COMPILER_TYPE.
*** Error code 1
Stop.
make[1]: stopped in /builds/FreeBSD_HEAD
*** Error code 1
Build failed in Jenkins: Build-UFS-image #1023
See https://jenkins.freebsd.org/job/Build-UFS-image/1023/
--
Started by build flow Build_Image_and_Run_Tests_in_Bhyve_HEAD#672
Building remotely on jenkins-10.freebsd.org (FreeBSD-10) in workspace
https://jenkins.freebsd.org/job/Build-UFS-image/ws/
git rev-parse --is-inside-work-tree # timeout=10
Fetching changes from the remote Git repository
git config remote.origin.url https://github.com/freebsd/freebsd-ci #
timeout=10
Fetching upstream changes from https://github.com/freebsd/freebsd-ci
git --version # timeout=10
git fetch --tags --progress https://github.com/freebsd/freebsd-ci
+refs/heads/*:refs/remotes/origin/*
git rev-parse refs/remotes/origin/master^{commit} # timeout=10
git rev-parse refs/remotes/origin/origin/master^{commit} # timeout=10
Checking out Revision c4076363048e3727a9772acffc651bb19bebdb4f
(refs/remotes/origin/master)
git config core.sparsecheckout # timeout=10
git checkout -f c4076363048e3727a9772acffc651bb19bebdb4f
git rev-list c4076363048e3727a9772acffc651bb19bebdb4f # timeout=10
[Build-UFS-image] $ /bin/sh -xe /tmp/hudson1789453341986571460.sh
+ freebsd-ci/scripts/build/build-ufs-image.sh
+ [ -z https://jenkins.freebsd.org/job/Build-UFS-image/ws/ ]
+ [ -z /builds/FreeBSD_HEAD ]
+ [ -z '' ]
+ export MAKEOBJDIRPREFIX=/builds/FreeBSD_HEAD/obj
+ [ -z '' ]
+ basename /builds/FreeBSD_HEAD
+
PACKAGE_ROOT=https://jenkins.freebsd.org/job/Build-UFS-image/ws/package/FreeBSD_HEAD
+ [ -z '' ]
+ basename /builds/FreeBSD_HEAD
+
IMAGE_ROOT=https://jenkins.freebsd.org/job/Build-UFS-image/ws/image/FreeBSD_HEAD
+ [ -n '' ]
+ [ -z /builds/FreeBSD_HEAD/obj ]
+ cd /builds/FreeBSD_HEAD
+ [ -z '' ]
+ [ -f /builds/FreeBSD_HEAD/make.conf ]
+ __MAKE_CONF=/builds/FreeBSD_HEAD/make.conf
+ sudo rm -fr
https://jenkins.freebsd.org/job/Build-UFS-image/ws/package/FreeBSD_HEAD
+ mkdir -p
https://jenkins.freebsd.org/job/Build-UFS-image/ws/package/FreeBSD_HEAD
+ sudo env MAKEOBJDIRPREFIX=/builds/FreeBSD_HEAD/obj make installworld
NO_FSCHG=yes
DESTDIR=https://jenkins.freebsd.org/job/Build-UFS-image/ws/package/FreeBSD_HEAD
__MAKE_CONF=/builds/FreeBSD_HEAD/make.conf
mkdir -p /tmp/install.x4bdyHst
progs=$(for prog in [ awk cap_mkdb cat chflags chmod chown date echo egrep
find grep id install ln lockf make mkdir mtree mv pwd_mkdb rm sed
services_mkdb sh strip sysctl test true uname wc zic tzsetup makewhatis; do
if progpath=`which $prog`; then echo $progpath; else echo Required tool
$prog not found in PATH. 2; exit 1; fi; done); libs=$(ldd -f %o %p\n
-f %o %p\n $progs 2/dev/null | sort -u | while read line; do set -- $line;
if [ $2 $3 != not found ]; then echo $2; else echo Required library $1
not found. 2; exit 1; fi; done); cp $libs $progs /tmp/install.x4bdyHst
cp -R ${PATH_LOCALE:-/usr/share/locale} /tmp/install.x4bdyHst/locale
cd /builds/FreeBSD_HEAD; MAKEOBJDIRPREFIX=/builds/FreeBSD_HEAD/obj
MACHINE_ARCH=amd64 MACHINE=amd64 CPUTYPE=
GROFF_BIN_PATH=/builds/FreeBSD_HEAD/obj/builds/FreeBSD_HEAD/tmp/legacy/usr/bin
GROFF_FONT_PATH=/builds/FreeBSD_HEAD/obj/builds/FreeBSD_HEAD/tmp/legacy/usr/share/groff_font
GROFF_TMAC_PATH=/builds/FreeBSD_HEAD/obj/builds/FreeBSD_HEAD/tmp/legacy/usr/share/tmac
PATH=/builds/FreeBSD_HEAD/obj/builds/FreeBSD_HEAD/tmp/legacy/usr/sbin:/builds/FreeBSD_HEAD/obj/builds/FreeBSD_HEAD/tmp/legacy/usr/bin:/builds/FreeBSD_HEAD/obj/builds/FreeBSD_HEAD/tmp/legacy/usr/games:/builds/FreeBSD_HEAD/obj/builds/FreeBSD_HEAD/tmp/legacy/bin:/builds/FreeBSD_HEAD/obj/builds/FreeBSD_HEAD/tmp/usr/sbin:/builds/FreeBSD_HEAD/obj/builds/FreeBSD_HEAD/tmp/usr/bin:/builds/FreeBSD_HEAD/obj/builds/FreeBSD_HEAD/tmp/usr/games:/tmp/install.x4bdyHst
LD_LIBRARY_PATH=/tmp/install.x4bdyHst
PATH_LOCALE=/tmp/install.x4bdyHst/locale make -f Makefile.inc1
__MAKE_SHELL=/tmp/install.x4bdyHst/sh reinstall; MAKEOBJDIRPREFIX=/
builds/FreeBSD_HEAD/obj MACHINE_ARCH=amd64 MACHINE=amd64 CPUTYPE=
GROFF_BIN_PATH=/builds/FreeBSD_HEAD/obj/builds/FreeBSD_HEAD/tmp/legacy/usr/bin
GROFF_FONT_PATH=/builds/FreeBSD_HEAD/obj/builds/FreeBSD_HEAD/tmp/legacy/usr/share/groff_font
GROFF_TMAC_PATH=/builds/FreeBSD_HEAD/obj/builds/FreeBSD_HEAD/tmp/legacy/usr/share/tmac
PATH=/builds/FreeBSD_HEAD/obj/builds/FreeBSD_HEAD/tmp/legacy/usr/sbin:/builds/FreeBSD_HEAD/obj/builds/FreeBSD_HEAD/tmp/legacy/usr/bin:/builds/FreeBSD_HEAD/obj/builds/FreeBSD_HEAD/tmp/legacy/usr/games:/builds/FreeBSD_HEAD/obj/builds/FreeBSD_HEAD/tmp/legacy/bin:/builds/FreeBSD_HEAD/obj/builds/FreeBSD_HEAD/tmp/usr/sbin:/builds/FreeBSD_HEAD/obj/builds/FreeBSD_HEAD/tmp/usr/bin:/builds/FreeBSD_HEAD/obj/builds/FreeBSD_HEAD/tmp/usr/games:/tmp/install.x4bdyHst
LD_LIBRARY_PATH=/tmp/install.x4bdyHst
PATH_LOCALE=/tmp/install.x4bdyHst/locale rm -rf /tmp/install.x4bdyHst
make[2]: /builds/FreeBSD_HEAD/share/mk/bsd.compiler.mk line 42: Unable to
determine compiler type for cc. Consider setting COMPILER_TYPE.
*** Error code 1
Stop.
make[1]: stopped in /builds/FreeBSD_HEAD
*** Error code 1
Jenkins build is back to normal : Build-UFS-image #1025
See https://jenkins.freebsd.org/job/Build-UFS-image/1025/ ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: PSA: If you run -current, beware!
On Tuesday, February 3, 2015, Peter Wemm pe...@wemm.org wrote: Sometime in the Dec 10th through Jan 7th timeframe a timing bug has been introduced to 11.x/head/-current.With HZ=1000 (the default for bare metal, not for a vm); the clocks stop just after 24 days of uptime. This means Signed 32 bit overflow it seems from the numbers ? Wasn't that a windows feature in the old days ? :) Cheers Luigi -- -+--- Prof. Luigi RIZZO, ri...@iet.unipi.it . Dip. di Ing. dell'Informazione http://www.iet.unipi.it/~luigi/. Universita` di Pisa TEL +39-050-2211611 . via Diotisalvi 2 Mobile +39-338-6809875 . 56122 PISA (Italy) -+--- ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: PSA: If you run -current, beware!
On Tue, 2015-02-03 at 13:33 -0800, Peter Wemm wrote: Sometime in the Dec 10th through Jan 7th timeframe a timing bug has been introduced to 11.x/head/-current.With HZ=1000 (the default for bare metal, not for a vm); the clocks stop just after 24 days of uptime. This means things like cron, sleep, timeouts etc stop working. TCP/IP won't time out or retransmit, etc etc. It can get ugly. The problem is NOT in 10.x/-stable. We hit this in the freebsd.org cluster, the builds that we used are: FreeBSD 11.0-CURRENT #0 r275684: Wed Dec 10 20:38:43 UTC 2014 - fine FreeBSD 11.0-CURRENT #0 r276779: Wed Jan 7 18:47:09 UTC 2015 - broken If you are running -current in a situation where it'll accumulate uptime, you may want to take precautions. A reboot prior to 24 days uptime (as horrible a workaround as that is) will avoid it. Yes, this is being worked on. FWIW, 24.8 days is the point at which an int32_t variable counting ticks at 1khz rolls over from positive to negative numbers. -- Ian ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
tzsetup - UTC user question
Since the default option for Select local or UTC clock changed from No to Yes, we are seeing many customers who incorrectly answer this question! This screws up things in our app because we store all data in UTC. A few observations... Most people don't know what CMOS clock is. Maybe change the wording to BIOS clock or Hardware Clock ?? The person doing the install may not know what the clock is currently set to, especially when installing in a VM. Perhaps the screen should display the current machine time so they can correctly answer the question. Why was the default changed from No to Yes ? Paul. -- Paul Koch | Founder, CEO AKIPS Network Monitor http://www.akips.com Brisbane, Australia ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: tzsetup - UTC user question
Hi! The person doing the install may not know what the clock is currently set to, especially when installing in a VM. Perhaps the screen should display the current machine time so they can correctly answer the question. Yes, this would help tremendously! -- p...@opsec.eu+49 171 3101372 5 years to go ! ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Filepaths in VM map for tmpfs files
On Mon, Feb 02, 2015 at 09:50:22PM -0600, Eric Badger wrote: On 02/02/2015 03:30 AM, Konstantin Belousov wrote: On Sun, Feb 01, 2015 at 08:38:29PM -0600, Eric Badger wrote: On 01/31/2015 09:36 AM, Konstantin Belousov wrote: First, shouldn't the kve_type changed to KVME_TYPE_VNODE as well ? My thinking is no, because KVME_TYPE_SWAP is in fact the correct type; I'd opine that it is better to be transparent than make it look like there is an OBJT_VNODE object there. It may be that some programs would be confused by VNODE info returned on a SWAP type mapping, though I know that dtrace handles it OK. kve_vn_* and kve_path fields are defined only for KVME_TYPE_VNODE kve_type. So this is in fact a bug in whatever used the API to access kve_path for KVE_TYPE_SWAP. Hmm, is that documented anywhere? I think it's fair to assume that kve_vn* applies only to the VNODE type, but I know there are several in-tree users that reference kve_path regardless of type (ostensibly relying on the default of an empty string). Maybe one could determine the validity of the kve_vn* fields by inspecting the kve_vn_type (not sure of all the consequences of that)? Or change it to KVME_TYPE_VNODE and deal with the below problem... There is no useful documentation for the kern.proc. sysctls. My word (and statements from other involved developers) could be considered as close to the truth as it can be. Somebody taking the efforts to document the stuff would make very valuable contribution. Second, note that it is possible that the vnode is recycled, so OBJ_TMPFS flag is cleared for tmpfs swap object. The OBJ_TMPFS_NODE flag is still set then. I am not sure what to do in this case, should the type changed to KVME_TYPE_VNODE still, but kve_vn_* fields left invalid ? I think if we changed to KVME_TYPE_VNODE in some cases, it should be done in all cases, even if the vnode has been recycled (but leave vp == NULL in that case). Though if it is left as KVME_TYPE_SWAP, then that concern goes away on its own. Concern is not vp == NULL, but the fact that kve_vn* cannot be filled, there is simply no (easy) way to fetch this information. Right; by leaving vp == NULL, I meant don't populate the kve_vn* fields, which admittedly isn't a great solution. But as you say, the information is not really available once the vnode has been reclaimed. There is some inherent difficultly in the duality of the vm object here; it would be nice if it could be treated uniformly with other vnodes, but I think I lack the expertise to approach a more involved solution that would achieve this. ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: HP 2B19WM PCI-E SD Reader
On Mon, 2 Feb 2015, R0B_ROD wrote: Thank you for the time you took to help. According to: http://lists.freebsd.org/pipermail/ \ \ freebsd-current/2013-July/042788.html \ freebsd-questions/2014-August/259843.html Is the Realtek RTS5229 PCI-E SD Card Reader supported yet??? Unfortunately, we don't have a driver for this card reader yet. It is worth checking to make sure that you do indeed have this drvice though. Can you give the output of both pciconf -lv and usbconfig list please? Thanks, Gavin ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Jenkins build became unstable: FreeBSD_HEAD-tests2 #638
See https://jenkins.freebsd.org/job/FreeBSD_HEAD-tests2/638/ ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
tzsetup chroot
We have our own FreeBSD 10.1 installation script in which we call tzsetup. I'm seeing different behaviour in tzsetup between these two invocations: tzsetup -C /mnt chroot /mnt /usr/sbin/tzsetup With the -C option, no matter which time zone I select, it asks: Does the abbreviation 'UTC' look reasonable? Using chroot, I get the expected behaviour, e.g. selecting America/New_York: Does the abbreviation 'EST' look reasonable? /mnt contains the contents of base.txz, so it looks like all the zoneinfo files are there. -Nick -- Founder, CTO www.akips.com ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
PSA: If you run -current, beware!
Sometime in the Dec 10th through Jan 7th timeframe a timing bug has been introduced to 11.x/head/-current.With HZ=1000 (the default for bare metal, not for a vm); the clocks stop just after 24 days of uptime. This means things like cron, sleep, timeouts etc stop working. TCP/IP won't time out or retransmit, etc etc. It can get ugly. The problem is NOT in 10.x/-stable. We hit this in the freebsd.org cluster, the builds that we used are: FreeBSD 11.0-CURRENT #0 r275684: Wed Dec 10 20:38:43 UTC 2014 - fine FreeBSD 11.0-CURRENT #0 r276779: Wed Jan 7 18:47:09 UTC 2015 - broken If you are running -current in a situation where it'll accumulate uptime, you may want to take precautions. A reboot prior to 24 days uptime (as horrible a workaround as that is) will avoid it. Yes, this is being worked on. -- Peter Wemm - pe...@wemm.org; pe...@freebsd.org; pe...@yahoo-inc.com; KI6FJV UTF-8: for when a ' or ... just won\342\200\231t do\342\200\246 signature.asc Description: This is a digitally signed message part.
