Re: duration of buildworld
El día Tuesday, July 28, 2015 a las 09:20:38AM +0100, David Chisnall escribió: It sounds as if the swap was working (as the build took a long time, it didn’t run out of memory). My guess would be that, before the reboot, something had wired (or, if not, then touched frequently enough to keep it in core) a large chunk of memory, which forced the swapping. Swap files are expected to be slower than swap partitions (though if you’re swapping to a disk, the seek times are likely to dominate in both cases). I don’t suppose there’s capture of the output of top from before the reboot? No, I did not saved it. When I started the buildworld, I started in parallel already a poudriere jail to build around 1600 ports. Later, when I realized that the buildworld took so long, I stopped (killed) the poudriere jail. IIRC the swapctl -l showed before the boot that the swap files have been used. I could re-create the situation on next buildworld. matthias -- Matthias Apitz, ✉ g...@unixarea.de, http://www.unixarea.de/ ☎ +49-176-38902045 No! Nein! ¡No! Όχι! -- Ευχαριστούμε! ___ 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: duration of buildworld
On 27 Jul 2015, at 20:49, Slawa Olhovchenkov s...@zxy.spb.ru wrote: No idea. May be someone know about current status swap in file on UFS. This is work for me some time ago. It sounds as if the swap was working (as the build took a long time, it didn’t run out of memory). My guess would be that, before the reboot, something had wired (or, if not, then touched frequently enough to keep it in core) a large chunk of memory, which forced the swapping. Swap files are expected to be slower than swap partitions (though if you’re swapping to a disk, the seek times are likely to dominate in both cases). I don’t suppose there’s capture of the output of top from before the reboot? David ___ 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
FreeBSD_HEAD_i386 - Build #693 - Failure
FreeBSD_HEAD_i386 - Build #693 - Failure:
Build information: https://jenkins.FreeBSD.org/job/FreeBSD_HEAD_i386/693/
Full change log: https://jenkins.FreeBSD.org/job/FreeBSD_HEAD_i386/693/changes
Full build log: https://jenkins.FreeBSD.org/job/FreeBSD_HEAD_i386/693/console
Change summaries:
285934 by kib:
Remove full barrier from the amd64 atomic_load_acq_*(). Strong
ordering semantic of x86 CPUs makes only the compiler barrier
neccessary to give the acquire behaviour.
Existing implementation ensured sequentially consistent semantic for
load_acq, making much stronger guarantee than required by standard's
definition of the load acquire. Consumers which depend on the barrier
are believed to be identified and already fixed to use proper
operations.
Noted by: alc (long time ago)
Reviewed by:alc, bde
Tested by: pho
Sponsored by: The FreeBSD Foundation
MFC after: 2 weeks
285933 by kib:
Remove useless acquire semantic from the atomic_add operation before
sosend(). The only release on the xp_snt_cnt is done after sosend(),
with an intent to synchronize with load_acq in svc_vc_ack().
Reviewed by:alc
Tested by: pho
Sponsored by: The FreeBSD Foundation
MFC after: 2 weeks
285932 by kib:
Add bit names for the IA32_MISC_ENABLE msr.
Sponsored by: The FreeBSD Foundation
MFC after: 1 week
285931 by ed:
Implement directory and FIFO creation.
The file_create() system call can be used to create files of a given
type. Right now it can only be used to create directories and FIFOs. As
CloudABI does not expose filesystem permissions, this system call lacks
a mode argument. Simply use 0777 or 0666 depending on the file type.
285930 by ed:
Make fstat() and friends work.
Summary:
CloudABI provides access to two different stat structures:
- fdstat, containing file descriptor level status: oflags, file
descriptor type and Capsicum rights, used by cap_rights_get(),
fcntl(F_GETFL), getsockopt(SO_TYPE).
- filestat, containing your regular file status: timestamps, inode
number, used by fstat().
Unlike FreeBSD's stat::st_mode, CloudABI file descriptor types don't
have overloaded meanings (e.g., returning S_ISCHR() for kqueues). Add a
utility function to extract the type of a file descriptor accurately.
CloudABI does not work with O_ACCMODEs. File descriptors have two sets
of Capsicum-style rights: rights that apply to the file descriptor
itself ('base') and rights that apply to any new file descriptors
yielded through openat() ('inheriting'). Though not perfect, we can
pretty safely decompose Capsicum rights to such a pair. This is done in
convert_capabilities().
Test Plan: Tests for these system calls are fairly extensive in cloudlibc.
Reviewers: jonathan, mjg, #manpages
Reviewed By: mjg
Subscribers: imp
Differential Revision: https://reviews.freebsd.org/D3171
285927 by marcel:
Check the sync operation.
The end of the build log:
Started by an SCM change
Building remotely on kyua6.nyi.freebsd.org (jailer) in workspace
/jenkins/workspace/FreeBSD_HEAD_i386
Updating svn://svnmir.freebsd.org/base/head at revision
'2015-07-28T07:15:08.159 +'
U sys/amd64/include/atomic.h
U sys/rpc/svc_vc.c
U sys/compat/cloudabi/cloudabi_file.c
U sys/compat/cloudabi/cloudabi_util.h
U sys/compat/cloudabi/cloudabi_fd.c
U sys/x86/include/specialreg.h
At revision 285934
No emails were triggered.
[FreeBSD_HEAD_i386] $ /bin/sh -xe /tmp/hudson5691075512931399535.sh
+ export 'PATH=/sbin:/bin:/usr/sbin:/usr/bin:/usr/local/sbin:/usr/local/bin'
+ export 'jname=FreeBSD_HEAD_i386'
+ echo env:
env:
+ /usr/bin/env
BUILD_NUMBER=693
HUDSON_SERVER_COOKIE=0657dbe3541f1b1a
JOB_NAME=FreeBSD_HEAD_i386
LOGNAME=jenkins
JAVA_HOME=/usr/local/openjdk8
SVN_URL=svn://svnmir.freebsd.org/base/head
BUILDER_JAIL_IP=2610:1c1:1:607c::106:1
jname=FreeBSD_HEAD_i386
JENKINS_URL=https://jenkins.FreeBSD.org/
JENKINS_HOME=/usr/local/jenkins
PATH=/sbin:/bin:/usr/sbin:/usr/bin:/usr/local/sbin:/usr/local/bin
HUDSON_HOME=/usr/local/jenkins
OLDPWD=/
BUILD_ID=693
BUILDER_NETIF=igb0
JENKINS_SERVER_COOKIE=0657dbe3541f1b1a
PWD=/jenkins/workspace/FreeBSD_HEAD_i386
BUILD_TAG=jenkins-FreeBSD_HEAD_i386-693
NODE_LABELS=jailer kyua6.nyi.freebsd.org
BUILD_DISPLAY_NAME=#693
HOME=/jenkins
USER=jenkins
BUILD_URL=https://jenkins.FreeBSD.org/job/FreeBSD_HEAD_i386/693/
SVN_URL_1=svn://svnmir.freebsd.org/base/head
SVN_REVISION=285934
SVN_REVISION_1=285934
JOB_URL=https://jenkins.FreeBSD.org/job/FreeBSD_HEAD_i386/
SHELL=/bin/sh
HUDSON_URL=https://jenkins.FreeBSD.org/
HUDSON_COOKIE=458d42c4-9644-4e88-a347-2711345e097d
BUILDER_RESOLV_CONF=nameserver 2610:1c1:1:6002::100\nnameserver
2610:1c1:1:6002::200\n
WORKSPACE=/jenkins/workspace/FreeBSD_HEAD_i386
NODE_NAME=kyua6.nyi.freebsd.org
EXECUTOR_NUMBER=0
+ echo 'setup jail FreeBSD_HEAD_i386'
setup jail FreeBSD_HEAD_i386
+ fetch -m
http://ftp.freebsd.org:/pub/FreeBSD/snapshots/i386/i386/11.0-CURRENT/base.txz
+ mkdir FreeBSD_HEAD_i386
mkdir:
Re: Segmentation fault running ntpd
On Tue, Jul 28, 2015 at 04:05:33PM -0700, Adrian Chadd wrote: Is this still happening for you? g1-245(10.2-P)[4] ls -lT /S4/ntpd.core -rw-r--r-- 1 root wheel 13783040 Jul 28 04:56:28 2015 /S4/ntpd.core Apparently so, yes. (/S4 is where I have the head root file system mounted when I'm not running from slice 4.) Peace, david -- David H. Wolfskill da...@catwhisker.org Those who murder in the name of God or prophet are blasphemous cowards. See http://www.catwhisker.org/~david/publickey.gpg for my public key. pgpDpAhZQ_vQX.pgp Description: PGP signature
Re: Segmentation fault running ntpd
Is this still happening for you? -a On 24 July 2015 at 06:03, David Wolfskill da...@catwhisker.org wrote: On Sun, Jul 19, 2015 at 11:36:00AM -0700, David Wolfskill wrote: On Sun, Jul 19, 2015 at 10:24:11AM -0600, Ian Lepore wrote: ... Was there anything (at all) in /var/log/messages about ntpd? Even the routine messages (such as what interfaces it binds to) might give a bit of a clue about how far it got in its init before it died. Sorry; there might have been something yesterday... If I do get another recurrence, I'll try to gather a bit more information. OK; got another one. This time, I have the complete /var/log/messages for a verbose boot, from that boot to just a bit after the ntpd crash; it's in http://www.catwhisker.org/~david/FreeBSD/head; as of the moment, that contains: [PARENTDIR] Parent Directory - [ ] CANARY 2015-03-22 10:03 15K [ ] CANARY.gz 2015-03-22 10:03 6.3K [ ] ntpd.core 2015-07-24 05:31 13M [ ] ntpd.core.gz2015-07-24 05:31 124K [TXT] ntpd_crash_msgs.txt 2015-07-24 05:40 138K [ ] ntpd_crash_msgs.txt.gz 2015-07-24 05:40 19K This was running: FreeBSD g1-245.catwhisker.org 11.0-CURRENT FreeBSD 11.0-CURRENT #133 r285836M/285836:1100077: Fri Jul 24 05:24:41 PDT 2015 r...@g1-245.catwhisker.org:/common/S4/obj/usr/src/sys/CANARY amd64 Trying gdb /usr/obj/usr/src/usr.sbin/ntp/ntpd/ntpd ntpd.core still doesn't help much: This GDB was configured as amd64-marcel-freebsd...(no debugging symbols found)... Core was generated by `ntpd'. Program terminated with signal 11, Segmentation fault. Reading symbols from /lib/libm.so.5...(no debugging symbols found)...done. ... Loaded symbols for /libexec/ld-elf.so.1 #0 0x0008011cd6a0 in sbrk () from /lib/libc.so.7 [New Thread 801c07400 (LWP 100133/unknown)] [New Thread 801c06400 (LWP 100132/unknown)] (gdb) bt #0 0x0008011cd6a0 in sbrk () from /lib/libc.so.7 #1 0x0008ccbd4f34 in ?? () #2 0x0005 in ?? () #3 0x000801800448 in ?? () #4 0x0008011ca888 in sbrk () from /lib/libc.so.7 #5 0x0008018000c8 in ?? () #6 0x0008018000c0 in ?? () #7 0x0208 in ?? () #8 0x000801c32fb0 in ?? () #9 0x0001 in ?? () #10 0x000801cc20c8 in ?? () #11 0x0030 in ?? () #12 0x000801cc20c8 in ?? () #13 0x7fffe480 in ?? () #14 0x0008011cd240 in sbrk () from /lib/libc.so.7 #15 0x0280 in ?? () #16 0x0008014bbc70 in malloc_message () from /lib/libc.so.7 #17 0x0008018000c0 in ?? () #18 0x000801800448 in ?? () #19 0x0032 in ?? () #20 0x000801800458 in ?? () #21 0x0008014bbc68 in malloc_message () from /lib/libc.so.7 #22 0x000801cc2000 in ?? () #23 0x0008014bba60 in malloc_message () from /lib/libc.so.7 #24 0x000801cc20d8 in ?? () #25 0x00a0 in ?? () #26 0x0208 in ?? () #27 0x7fffe4d0 in ?? () #28 0x0008011bdd7a in _malloc_thread_cleanup () from /lib/libc.so.7 Previous frame inner to this frame (corrupt stack?) (gdb) I am presently suspecting that it's a bit dependent on ... well, timing. I have my ~/.xsession set up so that once I've entered the passphrase(s) for my SSH private key(s), scripts start running to establish connections to other machines -- e.g., open an xterm locally, ssh over to my mailhub and (re-)establish a tmux session on that machine where I run mutt to read write email (such as this message). While that almost always Just Works in stable/10, it's rather ... spottier ... in head -- I'd say it's about a 50% probability that it will work, vs. the ssh connection attempt hanging, and eventually timing out. But if I've waited (say) 30 seconds or so, I can establish such a connection easily. Granted, I am using wireless (802.11), but I get a sense that things are claimed to be ready to go a bit prematurely -- at least sometimes. Peace, david -- David H. Wolfskill da...@catwhisker.org Those who murder in the name of God or prophet are blasphemous cowards. See http://www.catwhisker.org/~david/publickey.gpg for my public key. ___ 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: broken symbolic links in /usr/lib
On Tue, Jul 28, 2015 at 10:17:38PM +0200, Ian FREISLICH wrote: [trim] So, a couple of fscks found some problems, but none causing this. I found the actual problem. The mount point for /usr was mode 700 even though the root of the mounted filesystem on /usr was mode 755. Did I explain that clearly (quite difficult because two things are the same thing, although they're apparently not)? Seems that for some reason, some but not all actions involving the transition between . and .. on the mount point use either the permissions of the mount point or the permissions of the directory mounted on that mount point. In the past, the permissions in the mounted filesystem have always trumped the mount point, but I have no idea what the spec says. Is this a bug? As best that I can recall, the permissions of the directory underneath the mount point has been causing problems like this for as long as I've been using FreeBSD, which is over 20 years at this point. It's certainly bit me in the distant past. Regards, Gary ___ 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: Segmentation fault running ntpd
On Tue, Jul 28, 2015 at 04:25:45PM -0700, Adrian Chadd wrote: ... Hm, is there any way you can get symbols for it? Well, I could CFLAGS+= -g in /etc/make.conf to a clean build, then try to re-create it ( point gdb at the objects in /usr/obj/obj/*) -- would that do? I don't think I can easily get symbols for the crash we have, but my crash is also deep in malloc code.. Coincidence? Inquiring minds want to know :-} Peace, david -- David H. Wolfskill da...@catwhisker.org Those who murder in the name of God or prophet are blasphemous cowards. See http://www.catwhisker.org/~david/publickey.gpg for my public key. pgpe1oC0HgQsj.pgp Description: PGP signature
Re: Segmentation fault running ntpd
WITH_DEBUG_FILES=1 (IIRC) On 7/28/15 6:35 PM, Adrian Chadd wrote: There's some way in stable/10 and -head to get it to install debug symbols for things. Maybe it's only libraries, but you'll at least want that in there so you can get stack traces through libc. -adrian ___ 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 ___ 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
FreeBSD_HEAD-tests - Build #1228 - Still Unstable
/integration_test:missing_script - passed [0.070s] [192.168.10.2] out: libexec/atf/atf-sh/integration_test:no_args - passed [0.081s] [192.168.10.2] out: libexec/atf/atf-sh/integration_test:set_e - passed [0.122s] [192.168.10.2] out: libexec/atf/atf-sh/normalize_test:main - passed [0.113s] [192.168.10.2] out: libexec/atf/atf-sh/tc_test:default_status - passed [0.204s] [192.168.10.2] out: libexec/atf/atf-sh/tc_test:missing_body - passed [0.086s] [192.168.10.2] out: libexec/atf/atf-sh/tp_test:srcdir - passed [0.569s] [192.168.10.2] out: libexec/atf/atf-check/atf-check_test:eflag_empty - passed [0.133s] [192.168.10.2] out: libexec/atf/atf-check/atf-check_test:eflag_file - passed [0.316s] [192.168.10.2] out: libexec/atf/atf-check/atf-check_test:eflag_ignore - passed [0.280s] [192.168.10.2] out: libexec/atf/atf-check/atf-check_test:eflag_inline - passed [0.746s] [192.168.10.2] out: libexec/atf/atf-check/atf-check_test:eflag_match - passed [0.338s] [192.168.10.2] out: libexec/atf/atf-check/atf-check_test:eflag_multiple - passed [0.308s] [192.168.10.2] out: libexec/atf/atf-check/atf-check_test:eflag_negated - passed [0.224s] [192.168.10.2] out: libexec/atf/atf-check/atf-check_test:eflag_save - passed [0.242s] [192.168.10.2] out: libexec/atf/atf-check/atf-check_test:invalid_umask - passed [0.137s] [192.168.10.2] out: libexec/atf/atf-check/atf-check_test:oflag_empty - passed [0.189s] [192.168.10.2] out: libexec/atf/atf-check/atf-check_test:oflag_file - passed [0.259s] [192.168.10.2] out: libexec/atf/atf-check/atf-check_test:oflag_ignore - passed [0.169s] [192.168.10.2] out: libexec/atf/atf-check/atf-check_test:oflag_inline - passed [1.311s] [192.168.10.2] out: libexec/atf/atf-check/atf-check_test:oflag_match - passed [0.431s] [192.168.10.2] out: libexec/atf/atf-check/atf-check_test:oflag_multiple - passed [0.356s] [192.168.10.2] out: libexec/atf/atf-check/atf-check_test:oflag_negated - passed [0.183s] [192.168.10.2] out: libexec/atf/atf-check/atf-check_test:oflag_save - passed [0.154s] [192.168.10.2] out: libexec/atf/atf-check/atf-check_test:sflag_eq_ne - passed [0.290s] [192.168.10.2] out: libexec/atf/atf-check/atf-check_test:sflag_exit - passed [0.228s] [192.168.10.2] out: libexec/atf/atf-check/atf-check_test:sflag_ignore - passed [0.153s] [192.168.10.2] out: libexec/atf/atf-check/atf-check_test:sflag_signal - passed [0.196s] [192.168.10.2] out: libexec/atf/atf-check/atf-check_test:stdin - passed [0.082s] [192.168.10.2] out: libexec/atf/atf-check/atf-check_test:xflag - passed [0.101s] [192.168.10.2] out: [192.168.10.2] out: Results file id is usr_tests.20150728-214137-422996 [192.168.10.2] out: Results saved to /root/.kyua/store/results.usr_tests.20150728-214137-422996.db [192.168.10.2] out: [192.168.10.2] out: 4336/4338 passed (2 failed) [192.168.10.2] out: Warning: run() received nonzero return code 1 while executing 'kyua test'! [192.168.10.2] run: kyua report --verbose --results-filter passed,skipped,xfail,broken,failed --output test-report.txt [192.168.10.2] run: kyua report-junit --output=test-report.xml [192.168.10.2] run: shutdown -p now [192.168.10.2] out: Shutdown NOW! [192.168.10.2] out: shutdown: [pid 67957] [192.168.10.2] out: xff00 broadcast 192.168.10.255 kyuatestprompt # lock order reversal: 1st 0xfe007b223fc0 bufwait (bufwait) @ /builds/FreeBSD_HEAD/sys/kern/vfs_bio.c:3121 2nd 0xf800077a7c00 dirhash (dirhash) @ /builds/FreeBSD_HEAD/sys/ufs/ufs/ufs_dirhash.c:281 KDB: stack backtrace: db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame 0xfe0096f9c400 witness_checkorder() at witness_checkorder+0xe7a/frame 0xfe0096f9c480 _sx_xlock() at _sx_xlock+0x75/frame 0xfe0096f9c4c0 ufsdirhash_add() at ufsdirhash_add+0x3d/frame 0xfe0096f9c510 ufs_direnter() at ufs_direnter+0x5da/frame 0xfe0096f9c5e0 ufs_makeinode() at ufs_makeinode+0x5d3/frame 0xfe0096f9c7a0 ufs_create() at ufs_create+0x2d/frame 0xfe0096f9c7c0 VOP_CREATE_APV() at VOP_CREATE_APV+0xf1/frame 0xfe0096f9c7f0 vn_open_cred() at vn_open_cred+0x30e/frame 0xfe0096f9c960 kern_openat() at kern_openat+0x235/frame 0xfe0096f9cae0 amd64_syscall() at amd64_syscall+0x282/frame 0xfe0096f9cbf0 Xfast_syscall() at Xfast_syscall+0xfb/frame 0xfe0096f9cbf0 --- syscall (499, FreeBSD ELF64, sys_openat), rip = 0x8008f2f7a, rsp = 0x7fffbb68, rbp = 0x7fffbc40 --- ahcich0: Timeout on slot 6 port 0 ahcich0: is cs ss 0040 rs 0040 tfd 50 serr cmd 1000c617 (ada0:ahcich0:0:0:0): WRITE_FPDMA_QUEUED. ACB: 61 08 f0 c2 27 40 00 00 00 00 00 00 (ada0:ahcich0:0:0:0): CAM status: Command timeout (ada0:ahcich0:0:0:0): Retrying command ahcich0: Timeout on slot 10 port 0 ahcich0: is cs ss 0400 rs 0400 tfd 50 serr cmd 1000ca17 (ada0:ahcich0:0:0:0): WRITE_FPDMA_QUEUED. ACB: 61 08 b0 c2 27 40 00 00 00 00 00 00 (ada0
Re: Segmentation fault running ntpd
There's some way in stable/10 and -head to get it to install debug symbols for things. Maybe it's only libraries, but you'll at least want that in there so you can get stack traces through libc. -adrian ___ 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: duration of buildworld
On Mon, Jul 27, 2015 at 08:47:04PM +0200, Matthias Apitz wrote: This pointed in the right direction. I have had 6x 1 GByte additional swap partitions to plain files mounted Swap devices are used in an interleaved fashion. By having multiple file-backed swap devices on (presumably) the same disk, you are multiplying the disk thrashing that happens when you swap. This could slow things down quite a bit. Marcus ___ 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
FreeBSD_HEAD_i386 - Build #694 - Fixed
FreeBSD_HEAD_i386 - Build #694 - Fixed: Build information: https://jenkins.FreeBSD.org/job/FreeBSD_HEAD_i386/694/ Full change log: https://jenkins.FreeBSD.org/job/FreeBSD_HEAD_i386/694/changes Full build log: https://jenkins.FreeBSD.org/job/FreeBSD_HEAD_i386/694/console Change summaries: 285938 by tuexen: Fix a typo reported by Erik Cederstrand. MFC after: 1 week 285935 by hselasky: Optimise the DWC OTG host mode driver's receive path: Remove NAKing limit and pause IN and OUT transactions for 125us in case of NAK response for BULK and CONTROL endpoints. This gets the receive latency down and improves USB network throughput at the cost of some CPU usage. MFC after: 1 month ___ 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
[CURRENT]: r285995: etc/rc.d/tests residual in source tree not caught by make delete-old
Checking the source tree on CURRENT r285995 via svn status reveals that there is a remnant etc/rc.d/tests obviously not caught by make delete-old: ? .snap ? .sujournal ? etc/rc.d/tests ? sys/amd64/conf/KOENIGSBERG Can someone fix this? Regards, oh ___ 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
eventfd lookalike in FreeBSD ?
Hi, for some work we are doing on bhyve, we need some lightweight mechanism that a kernel thread can use to wake up another user thread possibly waiting for some event. If the recipient of the event were a kernel thread it would simply do a tsleep(chan...) and the sender would do a wakeup() or wakeup_one(). Do we have an equally simple option for a recipient that is a userspace thread using something that is already in the kernel ? Do we have some blocking syscall that ends up doing a tsleep in a predictable way ? I suppose I could create a kqueue() descriptor and instruct the kernel thread side to post an event instead of doing the wakeup, but this seems a bit more expensive on both endpoints. cheers luigi ___ 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
[CURRENT]: r285995: BROKEN! buildkernel fails in kern_shutdown.c
Sources as of r285995 fail to build kernel with [...] --- kernel --- linking kernel kern_shutdown.o: In function `kern_reboot': /usr/src/sys/kern/kern_shutdown.c:(.text+0x2e6): undefined reference to `bufshutdown' *** [kernel] Error code 1 Regards, oh ___ 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: [CURRENT]: r285995: BROKEN! buildkernel fails in kern_shutdown.c
On Tue, Jul 28, 2015 at 9:35 PM, O. Hartmann ohart...@zedat.fu-berlin.de wrote: Sources as of r285995 fail to build kernel with [...] --- kernel --- linking kernel kern_shutdown.o: In function `kern_reboot': /usr/src/sys/kern/kern_shutdown.c:(.text+0x2e6): undefined reference to `bufshutdown' *** [kernel] Error code 1 Hi, It appears you've got an old version of vfs_bio.o cached. Try deleting that and building. Best, Conrad ___ 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: [CURRENT]: r285995: BROKEN! buildkernel fails in kern_shutdown.c
On Tue, 28 Jul 2015 21:58:26 -0700 Conrad Meyer cse@gmail.com wrote: On Tue, Jul 28, 2015 at 9:35 PM, O. Hartmann ohart...@zedat.fu-berlin.de wrote: Sources as of r285995 fail to build kernel with [...] --- kernel --- linking kernel kern_shutdown.o: In function `kern_reboot': /usr/src/sys/kern/kern_shutdown.c:(.text+0x2e6): undefined reference to `bufshutdown' *** [kernel] Error code 1 Hi, It appears you've got an old version of vfs_bio.o cached. Try deleting that and building. Best, Conrad I doubt that. When I start building world this morning, I deleted /usr/obj/*. So it should be not as you presumed. I just did a make -j12 kernel in /usr/src again and it failed at the very same position. Again, the source tree has been recently updated, afterwards I started buidlworld on a deleted/fresh /usr/obj. ___ 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
r285947: broken AESNI support? No aesni0 on Intel XEON E5-1650-v3 on Fujitsu Celsius M740
Running a workstation with CURRENT (FreeBSD 11.0-CURRENT #5 r285947: Tue Jul 28 13:39:03 CEST 2015 amd64) equipted with an Intel XEON E5-1650 v3, see the extraction from recent dmesg below. I double checked the UEFI settings (the box is a Fujitsu Celsius M740 with most recent firmware 1.8.0) and I didn't find anything indicating that AES-NI has been deactivated. I checked the data sheet at Intel, the CPU should support AES-NI. I also filed a PR: Bug 201960 I'd like to know whether this is by intention, by bug (feature mask wrong?) or by a faulty firmware? Any hints? Thanks in advance, Oliver [...] FreeBSD clang version 3.6.1 (tags/RELEASE_361/final 237755) 20150525 VT: running with driver efifb. CPU: Intel(R) Xeon(R) CPU E5-1650 v3 @ 3.50GHz (3491.98-MHz K8-class CPU) Origin=GenuineIntel Id=0x306f2 Family=0x6 Model=0x3f Stepping=2 Features=0xbfebfbffFPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CLFLUSH,DTS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE Features2=0x7dfefbffSSE3,PCLMULQDQ,DTES64,MON,DS_CPL,VMX,SMX,EST,TM2,SSSE3,SDBG,FMA,CX16,xTPR,PDCM,PCID,DCA,SSE4.1,SSE4.2,x2APIC,MOVBE,POPCNT,TSCDLT,XSAVE,OSXSAVE,AVX,F16C,RDRAND AMD Features=0x2c100800SYSCALL,NX,Page1GB,RDTSCP,LM AMD Features2=0x21LAHF,ABM Structured Extended Features=0x37abFSGSBASE,TSCADJ,BMI1,AVX2,SMEP,BMI2,ERMS,INVPCID,PQM,NFPUSG XSAVE Features=0x1XSAVEOPT VT-x: (disabled in BIOS) PAT,HLT,MTF,PAUSE,EPT,UG,VPID,VID,PostIntr TSC: P-state invariant, performance statistics real memory = 34359738368 (32768 MB) avail memory = 33136336896 (31601 MB) Event timer LAPIC quality 600 ACPI APIC Table: FUJD3348-A1 FreeBSD/SMP: Multiprocessor System Detected: 12 CPUs FreeBSD/SMP: 1 package(s) x 6 core(s) x 2 SMT threads cpu0 (BSP): APIC ID: 0 cpu1 (AP): APIC ID: 1 cpu2 (AP): APIC ID: 2 cpu3 (AP): APIC ID: 3 cpu4 (AP): APIC ID: 4 cpu5 (AP): APIC ID: 5 cpu6 (AP): APIC ID: 6 cpu7 (AP): APIC ID: 7 cpu8 (AP): APIC ID: 8 cpu9 (AP): APIC ID: 9 cpu10 (AP): APIC ID: 10 cpu11 (AP): APIC ID: 11 random: unblocking device. ioapic0 Version 2.0 irqs 0-23 on motherboard ioapic1 Version 2.0 irqs 24-47 on motherboard random: entropy device external interface kbd0 at kbdmux0 random: registering fast source Intel Secure Key RNG random: fast provider: Intel Secure Key RNG cryptosoft0: software crypto on motherboard aesni0: No AESNI support. [...] ___ 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: broken symbolic links in /usr/lib
Gary Palmer gpal...@freebsd.org wrote: As best that I can recall, the permissions of the directory underneath the mount point has been causing problems like this for as long as I've been using FreeBSD, which is over 20 years at this point. It's certainly bit me in the distant past. I concur. I always make mount point directories 0111,noschg,nodump - it makes them stand out when not mounted, and also stops accidental directory deletion potentially stopping a reboot from working. But yeah, for 20+ years. I've also experienced problems if a mount-point directory doesn't have +x access. Cheers, Jamie ___ 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
r285995: config: Error: device ig4 is unknown
Having in kernel device ig4 makes buildkernel failing in CURRENT r285995: config: Error: device ig4 is unknown Loading the kernel module via kldload ig4 works fine. Regards oh ___ 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: [CURRENT]: r285995: BROKEN! buildkernel fails in kern_shutdown.c
On Tue, Jul 28, 2015 at 10:21 PM, O. Hartmann ohart...@zedat.fu-berlin.de wrote: On Tue, 28 Jul 2015 21:58:26 -0700 Conrad Meyer cse@gmail.com wrote: On Tue, Jul 28, 2015 at 9:35 PM, O. Hartmann ohart...@zedat.fu-berlin.de wrote: Sources as of r285995 fail to build kernel with [...] --- kernel --- linking kernel kern_shutdown.o: In function `kern_reboot': /usr/src/sys/kern/kern_shutdown.c:(.text+0x2e6): undefined reference to `bufshutdown' *** [kernel] Error code 1 Hi, It appears you've got an old version of vfs_bio.o cached. Try deleting that and building. Best, Conrad I doubt that. When I start building world this morning, I deleted /usr/obj/*. So it should be not as you presumed. I just did a make -j12 kernel in /usr/src again and it failed at the very same position. Again, the source tree has been recently updated, afterwards I started buidlworld on a deleted/fresh /usr/obj. Well, r285993 is probably the offending commit. It looks ok to me, though I also hit: kern_shutdown.o: In function `kern_reboot': /usr/home/cmeyer/src/freebsd/sys/kern/kern_shutdown.c:315: undefined reference to `bufshutdown' Best, Conrad ___ 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: eventfd lookalike in FreeBSD ?
On 28 Jul 2015, at 18:23, Adrian Chadd adrian.ch...@gmail.com wrote: (What would be nice is having kqueue know about conditionals, so we can sleep on a cond as well as a kqueue fd+queue, but I can't have everything I want..) I recently came across a need to do something like this. Being able to add condvar / mutex pairs to a kqueue and wait on a set of condition variables, reacquiring the mutexes for any of the signalled ones, as well as waiting for kernel events would be very useful. David ___ 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
FreeBSD_HEAD-tests - Build #1227 - Still Unstable
[0.102s] [192.168.10.2] out: libexec/atf/atf-sh/integration_test:custom_shell__shebang - passed [0.119s] [192.168.10.2] out: libexec/atf/atf-sh/integration_test:missing_script - passed [0.132s] [192.168.10.2] out: libexec/atf/atf-sh/integration_test:no_args - passed [0.631s] [192.168.10.2] out: libexec/atf/atf-sh/integration_test:set_e - passed [0.193s] [192.168.10.2] out: libexec/atf/atf-sh/normalize_test:main - passed [0.422s] [192.168.10.2] out: libexec/atf/atf-sh/tc_test:default_status - passed [0.219s] [192.168.10.2] out: libexec/atf/atf-sh/tc_test:missing_body - passed [0.123s] [192.168.10.2] out: libexec/atf/atf-sh/tp_test:srcdir - passed [0.231s] [192.168.10.2] out: libexec/atf/atf-check/atf-check_test:eflag_empty - passed [0.408s] [192.168.10.2] out: libexec/atf/atf-check/atf-check_test:eflag_file - passed [0.273s] [192.168.10.2] out: libexec/atf/atf-check/atf-check_test:eflag_ignore - passed [0.315s] [192.168.10.2] out: libexec/atf/atf-check/atf-check_test:eflag_inline - passed [0.447s] [192.168.10.2] out: libexec/atf/atf-check/atf-check_test:eflag_match - passed [0.309s] [192.168.10.2] out: libexec/atf/atf-check/atf-check_test:eflag_multiple - passed [0.300s] [192.168.10.2] out: libexec/atf/atf-check/atf-check_test:eflag_negated - passed [0.300s] [192.168.10.2] out: libexec/atf/atf-check/atf-check_test:eflag_save - passed [0.885s] [192.168.10.2] out: libexec/atf/atf-check/atf-check_test:invalid_umask - passed [0.152s] [192.168.10.2] out: libexec/atf/atf-check/atf-check_test:oflag_empty - passed [0.123s] [192.168.10.2] out: libexec/atf/atf-check/atf-check_test:oflag_file - passed [0.220s] [192.168.10.2] out: libexec/atf/atf-check/atf-check_test:oflag_ignore - passed [0.125s] [192.168.10.2] out: libexec/atf/atf-check/atf-check_test:oflag_inline - passed [0.282s] [192.168.10.2] out: libexec/atf/atf-check/atf-check_test:oflag_match - passed [0.291s] [192.168.10.2] out: libexec/atf/atf-check/atf-check_test:oflag_multiple - passed [0.219s] [192.168.10.2] out: libexec/atf/atf-check/atf-check_test:oflag_negated - passed [0.164s] [192.168.10.2] out: libexec/atf/atf-check/atf-check_test:oflag_save - passed [0.280s] [192.168.10.2] out: libexec/atf/atf-check/atf-check_test:sflag_eq_ne - passed [0.566s] [192.168.10.2] out: libexec/atf/atf-check/atf-check_test:sflag_exit - passed [0.368s] [192.168.10.2] out: libexec/atf/atf-check/atf-check_test:sflag_ignore - passed [0.235s] [192.168.10.2] out: libexec/atf/atf-check/atf-check_test:sflag_signal - passed [0.372s] [192.168.10.2] out: libexec/atf/atf-check/atf-check_test:stdin - passed [0.348s] [192.168.10.2] out: libexec/atf/atf-check/atf-check_test:xflag - passed [0.304s] [192.168.10.2] out: libexec/rtld-elf/ld_library_pathfds:bad_library_directories - passed [1.008s] [192.168.10.2] out: libexec/rtld-elf/ld_library_pathfds:first_library_directory - passed [0.242s] [192.168.10.2] out: libexec/rtld-elf/ld_library_pathfds:last_library_directory - passed [0.163s] [192.168.10.2] out: libexec/rtld-elf/ld_library_pathfds:middle_library_directory - passed [0.195s] [192.168.10.2] out: libexec/rtld-elf/ld_library_pathfds:missing_library - passed [0.213s] [192.168.10.2] out: libexec/rtld-elf/ld_library_pathfds:single_library_directory - passed [0.187s] [192.168.10.2] out: libexec/rtld-elf/ld_library_pathfds:wrong_library_directories - passed [0.191s] [192.168.10.2] out: [192.168.10.2] out: Results file id is usr_tests.20150728-153648-237338 [192.168.10.2] out: Results saved to /root/.kyua/store/results.usr_tests.20150728-153648-237338.db [192.168.10.2] out: [192.168.10.2] out: 4334/4337 passed (3 failed) [192.168.10.2] out: Warning: run() received nonzero return code 1 while executing 'kyua test'! [192.168.10.2] run: kyua report --verbose --results-filter passed,skipped,xfail,broken,failed --output test-report.txt [192.168.10.2] run: kyua report-junit --output=test-report.xml [192.168.10.2] run: shutdown -p now [192.168.10.2] out: Shutdown NOW! [192.168.10.2] out: shutdown: [pid 68170] [192.168.10.2] out: ast 192.168.10.255 kyuatestprompt # Jul 28 15:42:12 t_openpam_readword: in openpam_readword(): unexpected end of file Jul 28 15:42:12 last message repeated 2 times maxproc limit exceeded by uid 977 (pid 21074); see tuning(7) and login.conf(5) ahcich0: Timeout on slot 16 port 0 ahcich0: is cs ss 000f rs 000f tfd 50 serr cmd 1000d317 (ada0:ahcich0:0:0:0): WRITE_FPDMA_QUEUED. ACB: 61 08 b0 c2 27 40 00 00 00 00 00 00 (ada0:ahcich0:0:0:0): CAM status: Command timeout (ada0:ahcich0:0:0:0): Retrying command ahcich0: Timeout on slot 21 port 0 ahcich0: is cs ss 0020 rs 0020 tfd 50 serr cmd 1000d517 (ada0:ahcich0:0:0:0): WRITE_FPDMA_QUEUED. ACB: 61 08 f0 c2 27 40 00 00 00 00 00 00 (ada0:ahcich0:0:0:0): CAM status: Command timeout (ada0
Re: eventfd lookalike in FreeBSD ?
On 28 July 2015 at 10:31, David Chisnall thera...@freebsd.org wrote: On 28 Jul 2015, at 18:23, Adrian Chadd adrian.ch...@gmail.com wrote: (What would be nice is having kqueue know about conditionals, so we can sleep on a cond as well as a kqueue fd+queue, but I can't have everything I want..) I recently came across a need to do something like this. Being able to add condvar / mutex pairs to a kqueue and wait on a set of condition variables, reacquiring the mutexes for any of the signalled ones, as well as waiting for kernel events would be very useful. Windows has had this for years. It makes async network programming with thread worker queues significantly less abusive. -adrian ___ 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: eventfd lookalike in FreeBSD ?
There's a kqueue notification mechanism just for this very thing. (What would be nice is having kqueue know about conditionals, so we can sleep on a cond as well as a kqueue fd+queue, but I can't have everything I want..) -adrian On 28 July 2015 at 05:19, Luigi Rizzo ri...@iet.unipi.it wrote: Hi, for some work we are doing on bhyve, we need some lightweight mechanism that a kernel thread can use to wake up another user thread possibly waiting for some event. If the recipient of the event were a kernel thread it would simply do a tsleep(chan...) and the sender would do a wakeup() or wakeup_one(). Do we have an equally simple option for a recipient that is a userspace thread using something that is already in the kernel ? Do we have some blocking syscall that ends up doing a tsleep in a predictable way ? I suppose I could create a kqueue() descriptor and instruct the kernel thread side to post an event instead of doing the wakeup, but this seems a bit more expensive on both endpoints. cheers luigi ___ 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 ___ 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: FreeBSD_HEAD-tests - Build #1226 - Unstable
On 28 July 2015 at 00:23, jenkins-ad...@freebsd.org wrote: FreeBSD_HEAD-tests - Build #1226 - Unstable: [..] [192.168.10.2] out: sys/kern/unix_seqpacket_test:shutdown_send - failed: 2 checks failed; see output for more details [0.371s] [192.168.10.2] out: sys/kern/unix_seqpacket_test:shutdown_send_sigpipe - failed: 2 checks failed; see output for more details [0.553s] I'd fix this if the testing infrastructure was something easily setup'able locally with e.g. a freshly downloaded VM image. Currently it is not so, coz trying to build tests/sys/kern emits some linking errors due missing atf symbols. -- wbr, pluknet ___ 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
broken symbolic links in /usr/lib
Hi I cannot for the life of me figure out why this is so: As non-root: [zen] /usr/lib $ file libgcc_s.so libgcc_s.so: broken symbolic link to ../../lib/libgcc_s.so.1 As root: [zen] /usr/lib # file libgcc_s.so libgcc_s.so: symbolic link to ../../lib/libgcc_s.so.1 Only on one of my machines, all running CURRENT from within a day. The upshot is that I have to be root in order to link code. Any ideas greatly appreciated. Ian -- Ian Freislich ___ 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: eventfd lookalike in FreeBSD ?
On 28 Jul 2015, at 18:33, Adrian Chadd adrian.ch...@gmail.com wrote: Windows has had this for years. It makes async network programming with thread worker queues significantly less abusive. Can you do the same with Solaris completion ports? It might be a good source of inspiration for a good API if so. David ___ 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: eventfd lookalike in FreeBSD ?
On 28 July 2015 at 10:42, David Chisnall thera...@freebsd.org wrote: On 28 Jul 2015, at 18:33, Adrian Chadd adrian.ch...@gmail.com wrote: Windows has had this for years. It makes async network programming with thread worker queues significantly less abusive. Can you do the same with Solaris completion ports? It might be a good source of inspiration for a good API if so. I don't think you can do it with the solaris event ports. I don't know about their more later stuff. -a ___ 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: broken symbolic links in /usr/lib
On Tue, Jul 28, 2015 at 07:31:56PM +, Glen Barber wrote: On Tue, Jul 28, 2015 at 08:16:16PM +0200, Ian FREISLICH wrote: Hi I cannot for the life of me figure out why this is so: As non-root: [zen] /usr/lib $ file libgcc_s.so libgcc_s.so: broken symbolic link to ../../lib/libgcc_s.so.1 As root: [zen] /usr/lib # file libgcc_s.so libgcc_s.so: symbolic link to ../../lib/libgcc_s.so.1 Only on one of my machines, all running CURRENT from within a day. The upshot is that I have to be root in order to link code. Any ideas greatly appreciated. What are the permissions on /lib/libgcc_s.so.1 ? Probably a better question: What are the permissions on /lib ? Glen pgpSXc3KQXxR0.pgp Description: PGP signature
Re: FreeBSD_HEAD-tests - Build #1226 - Unstable
On Tue, Jul 28, 2015 at 21:21:07 +0300, Sergey Kandaurov wrote: On 28 July 2015 at 00:23, jenkins-ad...@freebsd.org wrote: FreeBSD_HEAD-tests - Build #1226 - Unstable: [..] [192.168.10.2] out: sys/kern/unix_seqpacket_test:shutdown_send - failed: 2 checks failed; see output for more details [0.371s] [192.168.10.2] out: sys/kern/unix_seqpacket_test:shutdown_send_sigpipe - failed: 2 checks failed; see output for more details [0.553s] I'd fix this if the testing infrastructure was something easily setup'able locally with e.g. a freshly downloaded VM image. That is a very good suggestion, it is already in the future plan. :) Currently it is not so, coz trying to build tests/sys/kern emits some linking errors due missing atf symbols. Just took a quick look at this job configuration, and I copied the disk image from build #1227 to here: https://people.freebsd.org/~lwhsu/tmp/test.img.xz Here are config and test script: https://github.com/freebsd/freebsd-ci/blob/master/scripts/test/config/config.json https://github.com/freebsd/freebsd-ci/blob/master/scripts/test/run-tests.py Hope these help. Li-Wen -- Li-Wen Hsu lw...@freebsd.org http://lwhsu.org pgptWUEqkvMT1.pgp Description: PGP signature
Re: broken symbolic links in /usr/lib
On Tue, Jul 28, 2015 at 08:16:16PM +0200, Ian FREISLICH wrote: Hi I cannot for the life of me figure out why this is so: As non-root: [zen] /usr/lib $ file libgcc_s.so libgcc_s.so: broken symbolic link to ../../lib/libgcc_s.so.1 As root: [zen] /usr/lib # file libgcc_s.so libgcc_s.so: symbolic link to ../../lib/libgcc_s.so.1 Only on one of my machines, all running CURRENT from within a day. The upshot is that I have to be root in order to link code. Any ideas greatly appreciated. What are the permissions on /lib/libgcc_s.so.1 ? Glen pgpGfBlmv_TIa.pgp Description: PGP signature
pmspcv panic on boot on this box
When I upgraded an approximately 3 month old -CURRENT system to yesterday, I got page not present panics, after a message about pmspcv not supporting my ahd(4) deviceid. I did NOT capture the panic, but adding nodevicepmspcv Allowed me to boot. Dmesg.boot from the WORKING system attached. I *CAN* work with someone if they want. Copyright (c) 1992-2015 The FreeBSD Project. Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 The Regents of the University of California. All rights reserved. FreeBSD is a registered trademark of The FreeBSD Foundation. FreeBSD 11.0-CURRENT #10 r285925: Mon Jul 27 21:00:19 CDT 2015 r...@oldtbh.lerctr.org:/usr/obj/usr/src/sys/VT-LER amd64 FreeBSD clang version 3.6.1 (tags/RELEASE_361/final 237755) 20150525 VT: running with driver vga. CPU: Intel(R) Xeon(TM) CPU 3.00GHz (2992.56-MHz K8-class CPU) Origin=GenuineIntel Id=0xf43 Family=0xf Model=0x4 Stepping=3 Features=0xbfebfbffFPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CLFLUSH,DTS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE Features2=0x641dSSE3,DTES64,MON,DS_CPL,CNXT-ID,CX16,xTPR AMD Features=0x20100800SYSCALL,NX,LM TSC: P-state invariant real memory = 9395240960 (8960 MB) avail memory = 8262250496 (7879 MB) Event timer LAPIC quality 400 ACPI APIC Table: PTLTD APIC FreeBSD/SMP: Multiprocessor System Detected: 4 CPUs FreeBSD/SMP: 2 package(s) x 1 core(s) x 2 HTT threads cpu0 (BSP): APIC ID: 0 cpu1 (AP/HT): APIC ID: 1 cpu2 (AP): APIC ID: 6 cpu3 (AP/HT): APIC ID: 7 random: unblocking device. ioapic0 Version 2.0 irqs 0-23 on motherboard ioapic1 Version 2.0 irqs 24-47 on motherboard ioapic2 Version 2.0 irqs 48-71 on motherboard random: entropy device external interface kbd1 at kbdmux0 netmap: loaded module module_register_init: MOD_LOAD (vesa, 0x80f4d760, 0) error 19 vtvga0: VT VGA driver on motherboard cryptosoft0: software crypto on motherboard acpi0: PTLTD RSDT on motherboard acpi0: Power Button (fixed) cpu0: ACPI CPU on acpi0 cpu1: ACPI CPU on acpi0 cpu2: ACPI CPU on acpi0 cpu3: ACPI CPU on acpi0 hpet0: High Precision Event Timer iomem 0xfed0-0xfed003ff irq 0,8 on acpi0 Timecounter HPET frequency 14318180 Hz quality 950 Event timer HPET frequency 14318180 Hz quality 450 Event timer HPET1 frequency 14318180 Hz quality 440 Event timer HPET2 frequency 14318180 Hz quality 440 atrtc0: AT realtime clock port 0x70-0x77 on acpi0 Event timer RTC frequency 32768 Hz quality 0 attimer0: AT timer port 0x40-0x43 on acpi0 Timecounter i8254 frequency 1193182 Hz quality 0 Event timer i8254 frequency 1193182 Hz quality 100 Timecounter ACPI-fast frequency 3579545 Hz quality 900 acpi_timer0: 24-bit timer at 3.579545MHz port 0x1008-0x100b on acpi0 pcib0: ACPI Host-PCI bridge port 0xcf8-0xcff on acpi0 pci0: ACPI PCI bus on pcib0 pci0: unknown at device 0.1 (no driver attached) pcib1: ACPI PCI-PCI bridge irq 16 at device 2.0 on pci0 pci1: ACPI PCI bus on pcib1 pcib2: ACPI PCI-PCI bridge at device 0.0 on pci1 pci2: ACPI PCI bus on pcib2 ahd0: Adaptec AIC7902 Ultra320 SCSI adapter port 0x2400-0x24ff,0x2000-0x20ff mem 0xdd20-0xdd201fff irq 32 at device 2.0 on pci2 aic7902: Ultra320 Wide Channel A, SCSI Id=7, PCI-X 101-133MHz, 512 SCBs ahd1: Adaptec AIC7902 Ultra320 SCSI adapter port 0x2c00-0x2cff,0x2800-0x28ff mem 0xdd202000-0xdd203fff irq 33 at device 2.1 on pci2 aic7902: Ultra320 Wide Channel B, SCSI Id=7, PCI-X 101-133MHz, 512 SCBs pcib3: ACPI PCI-PCI bridge at device 0.2 on pci1 pci3: ACPI PCI bus on pcib3 em0: Intel(R) PRO/1000 Legacy Network Connection 1.0.6 port 0x3000-0x303f mem 0xdd30-0xdd31 irq 54 at device 2.0 on pci3 em0: Ethernet address: 00:30:48:2e:99:ba em0: netmap queues/slots: TX 1/256, RX 1/256 em1: Intel(R) PRO/1000 Legacy Network Connection 1.0.6 port 0x3040-0x307f mem 0xdd32-0xdd33 irq 55 at device 2.1 on pci3 em1: Ethernet address: 00:30:48:2e:99:bb em1: netmap queues/slots: TX 1/256, RX 1/256 pcib4: ACPI PCI-PCI bridge irq 16 at device 4.0 on pci0 pci4: ACPI PCI bus on pcib4 pcib5: ACPI PCI-PCI bridge irq 16 at device 6.0 on pci0 pci5: ACPI PCI bus on pcib5 uhci0: Intel 82801EB (ICH5) USB controller USB-A port 0x1400-0x141f irq 16 at device 29.0 on pci0 uhci0: LegSup = 0x2f00 usbus0 on uhci0 uhci1: Intel 82801EB (ICH5) USB controller USB-B port 0x1420-0x143f irq 19 at device 29.1 on pci0 uhci1: LegSup = 0x2f00 usbus1 on uhci1 uhci2: Intel 82801EB (ICH5) USB controller USB-C port 0x1440-0x145f irq 18 at device 29.2 on pci0 uhci2: LegSup = 0x2f00 usbus2 on uhci2 uhci3: Intel 82801EB (ICH5) USB controller USB-D port 0x1460-0x147f irq 16 at device 29.3 on pci0 uhci3: LegSup = 0x2f00 usbus3 on uhci3 ehci0: Intel 82801EB/R (ICH5) USB 2.0 controller mem 0xdd001000-0xdd0013ff irq 23 at device 29.7 on pci0 usbus4: EHCI version 1.0 usbus4 on ehci0 pcib6: ACPI PCI-PCI bridge at device 30.0 on pci0 pci6: ACPI PCI bus on pcib6 vgapci0: VGA-compatible display port 0x4000-0x40ff mem
Re: amd64 base/head r284673 fails to build on amd64 base/head r284639, pilot error?
On 6/21/15 2:29 PM, Simon J. Gerraty wrote: Garrett Cooper yaneurab...@gmail.com wrote: Am I the only one who fails to build recent base/head (r284673) on pretty recent base/head (r284639)? This is on amd64 with ZFS and BEs. ... CC=clang CXX=clang++ CPP=clang-cpp You need to remove these lines. They shouldn’t have been set before or after the commits from projects/bmake . Note: both the grn's specified above are than r284598 which put the inlcude of make.conf back to its original spot, so the meta mode related changes should not be relevant. Regarding including /etc/make.conf, something is inconsistent with buildworld vs subdir make. Please see https://lists.freebsd.org/pipermail/svn-src-all/2015-July/107910.html (Also note that the STRIP= rescue build failure has been identified and a fix is being made) -- Regards, Bryan Drewery ___ 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: amd64 base/head r284673 fails to build on amd64 base/head r284639, pilot error?
On 7/28/15 2:58 PM, Bryan Drewery wrote:
On 7/28/15 2:26 PM, Bryan Drewery wrote:
On 6/21/15 2:29 PM, Simon J. Gerraty wrote:
Garrett Cooper yaneurab...@gmail.com wrote:
Am I the only one who fails to build recent base/head (r284673) on
pretty recent base/head (r284639)? This is on amd64 with ZFS and BEs.
...
CC=clang
CXX=clang++
CPP=clang-cpp
You need to remove these lines. They shouldn’t have been set before or
after the commits from projects/bmake .
Note: both the grn's specified above are than r284598 which put the
inlcude of make.conf back to its original spot, so the meta mode related
changes should not be relevant.
Regarding including /etc/make.conf, something is inconsistent with
buildworld vs subdir make.
Correction: I have STRIP= in /etc/src.conf. The inclusion of it seems
inconsistent between buildworld and subdir make. Note that after my fix
in r285986 it is now named STRIPBIN.
When building in rescue/rescue:
OBJDIR/rescue.mk:
STRIP? strip
...
${STRIP} rescue
1: subdir make
src.conf: STRIP=
rescue/rescue% make all
- make -f OBJDIR/rescue.mk
STRIP= is not passed down into rescue.mk, resulting in 'strip rescue'.
2. subdir make STRIP env override
rescue/rescue% make all STRIP=
STRIP= is passed down resulting in ' rescue'.
3: buildworld
STRIP= from src.conf is passed down, resulting in ' rescue'.
Please see
https://lists.freebsd.org/pipermail/svn-src-all/2015-July/107910.html
I think the problem here is the use of -m for SUB_MAKE in /Makefile.
Specifying -m share/mk causes all of the issues I've seen (expected
including of /etc/src.conf), while not using -m does not include
/etc/src.conf even though the build is being done in a src dir.
--
Regards,
Bryan Drewery
___
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: Segmentation fault running ntpd
On 28 July 2015 at 16:09, David Wolfskill da...@catwhisker.org wrote: On Tue, Jul 28, 2015 at 04:05:33PM -0700, Adrian Chadd wrote: Is this still happening for you? g1-245(10.2-P)[4] ls -lT /S4/ntpd.core -rw-r--r-- 1 root wheel 13783040 Jul 28 04:56:28 2015 /S4/ntpd.core Apparently so, yes. (/S4 is where I have the head root file system mounted when I'm not running from slice 4.) Hm, is there any way you can get symbols for it? I don't think I can easily get symbols for the crash we have, but my crash is also deep in malloc code.. -a ___ 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: broken symbolic links in /usr/lib
Glen Barber wrote: On Tue, Jul 28, 2015 at 07:31:56PM +, Glen Barber wrote: On Tue, Jul 28, 2015 at 08:16:16PM +0200, Ian FREISLICH wrote: Hi =20 I cannot for the life of me figure out why this is so: =20 As non-root: [zen] /usr/lib $ file libgcc_s.so libgcc_s.so: broken symbolic link to ../../lib/libgcc_s.so.1 =20 As root: [zen] /usr/lib # file libgcc_s.so=20 libgcc_s.so: symbolic link to ../../lib/libgcc_s.so.1 =20 Only on one of my machines, all running CURRENT from within a day. The upshot is that I have to be root in order to link code. =20 Any ideas greatly appreciated. =20 =20 What are the permissions on /lib/libgcc_s.so.1 ? =20 Probably a better question: What are the permissions on /lib ? Answering both: [zen] /usr/lib # ls -ld /lib drwxr-xr-x 3 root wheel 1536 Jul 28 19:07 /lib [zen] /usr/lib # ls -l /lib/libgcc_s.so.1 -r--r--r-- 1 root wheel 57792 Jul 28 19:07 /lib/libgcc_s.so.1 Ian -- Ian Freislich ___ 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: broken symbolic links in /usr/lib
On Tue, Jul 28, 2015 at 10:17:38PM +0200, Ian FREISLICH wrote: I found the actual problem. The mount point for /usr was mode 700 even though the root of the mounted filesystem on /usr was mode 755. Did I explain that clearly (quite difficult because two things are the same thing, although they're apparently not)? Your explanation makes sense to me. The cause of this, however is unclear - was this something done locally? This is why I asked about the permissions of '/lib', but based on what you've explained, even asking for the permissions of '/usr' would not have led to a clear answer. So we're clear, '/usr' (unmounted) is 700, but '/usr' (mounted) is 755? Or is this not the case? Glen pgpiIBFxPtvK1.pgp Description: PGP signature
Re: broken symbolic links in /usr/lib
David Wolfskill wrote: My experience with SU+J is limited (and negative -- in large part, because I tend heavily on dump | restore pipelines to copy file systems, some of which are live at the time (danger mitigated by -L flag for dump). As an aside, mine has been pretty positive, except for once having / moved entirely to /lost+found and encoded as inode numbers. That might be enough for some. If you can take that system down, I suggest: * Reboot to single-user mode. * Disable SU journaling (tunefs -j disable $special) * fsck -p / (at least; possibly elide the -p) * If you want SU+J, re-enable it (tunefs -j enable $special) * While theory says exit at this point should just continue the transition to multi-user mode, I'd be inclined to just reboot watch it to make sure nothing weird happens that you don't know about. * Re-test. So, a couple of fscks found some problems, but none causing this. I found the actual problem. The mount point for /usr was mode 700 even though the root of the mounted filesystem on /usr was mode 755. Did I explain that clearly (quite difficult because two things are the same thing, although they're apparently not)? Seems that for some reason, some but not all actions involving the transition between . and .. on the mount point use either the permissions of the mount point or the permissions of the directory mounted on that mount point. In the past, the permissions in the mounted filesystem have always trumped the mount point, but I have no idea what the spec says. Is this a bug? Ian -- Ian Freislich ___ 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: amd64 base/head r284673 fails to build on amd64 base/head r284639, pilot error?
On 7/28/15 2:26 PM, Bryan Drewery wrote:
On 6/21/15 2:29 PM, Simon J. Gerraty wrote:
Garrett Cooper yaneurab...@gmail.com wrote:
Am I the only one who fails to build recent base/head (r284673) on
pretty recent base/head (r284639)? This is on amd64 with ZFS and BEs.
...
CC=clang
CXX=clang++
CPP=clang-cpp
You need to remove these lines. They shouldn’t have been set before or
after the commits from projects/bmake .
Note: both the grn's specified above are than r284598 which put the
inlcude of make.conf back to its original spot, so the meta mode related
changes should not be relevant.
Regarding including /etc/make.conf, something is inconsistent with
buildworld vs subdir make.
Correction: I have STRIP= in /etc/src.conf. The inclusion of it seems
inconsistent between buildworld and subdir make. Note that after my fix
in r285986 it is now named STRIPBIN.
When building in rescue/rescue:
OBJDIR/rescue.mk:
STRIP? strip
...
${STRIP} rescue
1: subdir make
src.conf: STRIP=
rescue/rescue% make all
- make -f OBJDIR/rescue.mk
STRIP= is not passed down into rescue.mk, resulting in 'strip rescue'.
2. subdir make STRIP env override
rescue/rescue% make all STRIP=
STRIP= is passed down resulting in ' rescue'.
3: buildworld
STRIP= from src.conf is passed down, resulting in ' rescue'.
Please see
https://lists.freebsd.org/pipermail/svn-src-all/2015-July/107910.html
(Also note that the STRIP= rescue build failure has been identified and
a fix is being made)
--
Regards,
Bryan Drewery
___
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
