Re: broken symbolic links in /usr/lib
On Tue, 2015-07-28 at 22:17 +0200, Ian FREISLICH wrote: 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 I suspect that a combination of symlinks (which often use multiple levels of ../ to traverse filesystems) and this caveat from the mount(8) manpage explain what you see... CAVEATS After a successful mount, the permissions on the original mount point determine if .. is accessible from the mounted file system. The minimum permissions for the mount point for traversal across the mount point in both directions to be possible for all users is 0111 (execute for all). It makes a kind of sense when you think about it. To access ../ from the root of a mounted filesystem you have to read the underlying mount point directory to see what its parent is, and that requires access to that directory. -- 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
Re: r285947: broken AESNI support? No aesni0 on Intel XEON E5-1650-v3 on Fujitsu Celsius M740
O. Hartmann wrote this message on Wed, Jul 29, 2015 at 10:20 +0200: On Wed, 29 Jul 2015 00:36:16 -0700 John-Mark Gurney j...@funkthat.com wrote: O. Hartmann wrote this message on Wed, Jul 29, 2015 at 07:39 +0200: 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? Can you send me the output of cpuid-etallen? It's pretty long, so maybe off list would be better... It's from a port of the same name... I'm sorry, since I work in a pretty restricted area, I can not offer webspace-similar download areas, but if it is not offending the list, i could provide a compressed output. Find the output attached xz-compressed ... I cleared intentionally the serial number, just as a notice. Yep, this confirms that AES-NI is off: AES instruction = false Which isn't a surprise from our other data points. Just wanted to make sure... Also, it looks like a microcode update could fix this issue, have you tried to look at that? https://albertveli.wordpress.com/2013/03/05/aes-ni-enabled/ Looks very similar to your issue, though it's a different microarch.. Your's is a Haswell that has the TSX bug in it, and it could be that the bios is disabling too many feature bits... Have you made sure that your machine has the latest BIOS? A newer BIOS could reenable the feature too... I just checked this moment again, but the latest UEFI firmware Fujitsu is offering is version 1.8.0 from April of this year. I would complain to the vendor of your machine... I'd contact them and try to return the machine as defective... It clearly is... [...] 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 There should be an AESNI feature on this line, but clearly not... On another machine, also Fujitsu, but a 19 inch rack server module with a low energy XEON E5-12XXv3, I can clearly see the AESNI feature in Feature2 list and, conclusively, the aesni0 device is present and reported. [...] aesni0: No AESNI support. [...] Which is why you get this... I applied the port sysutils/cpuid to another system, runnin a i5-4200M mobile CPU (Lenovo notebook). The rows indicating family = Intel ... (simple synth) = ... look much more modern for my opinion as the output I provided shows on the CPU in question. It is just a hunch ... Seems, I've bought Intel(ian) crap ;-) with no features and from another mellenium ... Yep... -- John-Mark Gurney Voice: +1 415 225 5579 All that I will do, has been done, All that I have, has not. ___ 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 Quarterly Status Report - Second Quarter 2015
On 29-7-2015 18:01, Jordan Hubbard wrote: On Jul 27, 2015, at 7:32 AM, Willem Jan Withagen w...@digiware.nl wrote: You have any idea what is/was actual the hardware that was in the box? If I remember correctly we gave Jordan a check for like 5000 guilders. Which I guess would be 2500 us$ at that time. Which was not an enormous amount of money, so even more impressive that the system lasted 18 years :) And thank you again for that donation! We should have another conference at that place - I remember it was unusual to have a conference at a location that also supplied tools for hacking our Librettos. :) It was a fun weekend. I think Robert demonstrated a heavy system @work, where he could compile the kernel (or was it world) within 20 minutes We were all amasted that the lines went by faster than we could read. I believe those original funds purchased a Pentium Pro system of fairly reasonable configuration. As Julian says, however, the individual parts were replaced over the years, including the motherboard, and the freefall of today likely bore little resemblance to the one we purchased at the local PC shop in Walnut Creek, California! If it went anything like here in the workshed, only the metal box is more or less still there. But all other parts have gone. Some 4U 19 frames have the fronts cut out, to make room for diskbays. :) Exactly like Julian suggests. I'd like his phrasing thou. --WjW ___ 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 Quarterly Status Report - Second Quarter 2015
On Jul 27, 2015, at 7:32 AM, Willem Jan Withagen w...@digiware.nl wrote: You have any idea what is/was actual the hardware that was in the box? If I remember correctly we gave Jordan a check for like 5000 guilders. Which I guess would be 2500 us$ at that time. Which was not an enormous amount of money, so even more impressive that the system lasted 18 years :) And thank you again for that donation! We should have another conference at that place - I remember it was unusual to have a conference at a location that also supplied tools for hacking our Librettos. :) I believe those original funds purchased a Pentium Pro system of fairly reasonable configuration. As Julian says, however, the individual parts were replaced over the years, including the motherboard, and the freefall of today likely bore little resemblance to the one we purchased at the local PC shop in Walnut Creek, California! - Jordan ___ 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 #1231 - Still Unstable
/execve_test:non_exist_shell - passed [0.114s] [192.168.10.2] out: sys/kern/execve/execve_test:script_arg - passed [0.149s] [192.168.10.2] out: sys/kern/execve/execve_test:script_arg_nospace - passed [0.122s] [192.168.10.2] out: sys/kern/execve/execve_test:sparse_aout - passed [0.120s] [192.168.10.2] out: sys/kern/execve/execve_test:trunc_aout - passed [0.129s] [192.168.10.2] out: sys/kqueue/kqueue_test:main - passed [11.192s] [192.168.10.2] out: sys/mqueue/mqueue_test:mqtest1 - passed [0.095s] [192.168.10.2] out: sys/mqueue/mqueue_test:mqtest2 - passed [0.273s] [192.168.10.2] out: sys/mqueue/mqueue_test:mqtest3 - passed [0.141s] [192.168.10.2] out: sys/mqueue/mqueue_test:mqtest4 - passed [0.260s] [192.168.10.2] out: sys/mqueue/mqueue_test:mqtest5 - passed [0.172s] [192.168.10.2] out: sys/netinet/fibs_test:arpresolve_checks_interface_fib - skipped: Required configuration property 'fibs' not defined [0.000s] [192.168.10.2] out: sys/netinet/fibs_test:default_route_with_multiple_fibs_on_same_subnet - skipped: Required configuration property 'fibs' not defined [0.000s] [192.168.10.2] out: sys/netinet/fibs_test:loopback_and_network_routes_on_nondefault_fib - skipped: Required configuration property 'fibs' not defined [0.000s] [192.168.10.2] out: sys/netinet/fibs_test:same_ip_multiple_ifaces - skipped: Required configuration property 'fibs' not defined [0.000s] [192.168.10.2] out: sys/netinet/fibs_test:same_ip_multiple_ifaces_fib0 - skipped: Required configuration property 'fibs' not defined [0.000s] [192.168.10.2] out: sys/netinet/fibs_test:subnet_route_with_multiple_fibs_on_same_subnet - skipped: Required configuration property 'fibs' not defined [0.000s] [192.168.10.2] out: sys/netinet/fibs_test:udp_dontroute - skipped: Required configuration property 'fibs' not defined [0.000s] [192.168.10.2] out: sys/opencrypto/runtests:main - passed [0.342s] [192.168.10.2] out: sys/vm/mmap_test:main - passed [0.079s] [192.168.10.2] out: sbin/ifconfig/nonexistent_test:nonexistent - passed [0.126s] [192.168.10.2] out: sbin/mdconfig/mdconfig_test:attach_malloc - passed [0.407s] [192.168.10.2] out: sbin/mdconfig/mdconfig_test:attach_swap - passed [0.423s] [192.168.10.2] out: sbin/mdconfig/mdconfig_test:attach_vnode_explicit_type - passed [0.582s] [192.168.10.2] out: sbin/mdconfig/mdconfig_test:attach_vnode_larger_than_file - passed [0.365s] [192.168.10.2] out: sbin/mdconfig/mdconfig_test:attach_vnode_non_explicit_type - passed [0.278s] [192.168.10.2] out: sbin/mdconfig/mdconfig_test:attach_vnode_sector_size - passed [0.447s] [192.168.10.2] out: sbin/mdconfig/mdconfig_test:attach_vnode_smaller_than_file - passed [0.426s] [192.168.10.2] out: sbin/mdconfig/mdconfig_test:attach_with_specific_unit_number - passed [0.292s] [192.168.10.2] out: sbin/growfs/legacy_test:main - passed [13.541s] [192.168.10.2] out: sbin/devd/client_test:seqpacket - passed [0.130s] [192.168.10.2] out: sbin/devd/client_test:stream - passed [0.084s] [192.168.10.2] out: sbin/dhclient/option-domain-search_test:main - passed [0.144s] [192.168.10.2] out: [192.168.10.2] out: Results file id is usr_tests.20150729-152712-507992 [192.168.10.2] out: Results saved to /root/.kyua/store/results.usr_tests.20150729-152712-507992.db [192.168.10.2] out: [192.168.10.2] out: 4337/4340 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 68085] [192.168.10.2] out: 00 broadcast 192.168.10.255 kyuatestprompt # lock order reversal: 1st 0xfe007b2e8ff0 bufwait (bufwait) @ /builds/FreeBSD_HEAD/sys/kern/vfs_bio.c:3191 2nd 0xf80007250c00 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 0xfe0096fcd400 witness_checkorder() at witness_checkorder+0xe7a/frame 0xfe0096fcd480 _sx_xlock() at _sx_xlock+0x75/frame 0xfe0096fcd4c0 ufsdirhash_add() at ufsdirhash_add+0x3d/frame 0xfe0096fcd510 ufs_direnter() at ufs_direnter+0x5da/frame 0xfe0096fcd5e0 ufs_makeinode() at ufs_makeinode+0x5d3/frame 0xfe0096fcd7a0 ufs_create() at ufs_create+0x2d/frame 0xfe0096fcd7c0 VOP_CREATE_APV() at VOP_CREATE_APV+0xf1/frame 0xfe0096fcd7f0 vn_open_cred() at vn_open_cred+0x30e/frame 0xfe0096fcd960 kern_openat() at kern_openat+0x235/frame 0xfe0096fcdae0 amd64_syscall() at amd64_syscall+0x282/frame 0xfe0096fcdbf0 Xfast_syscall() at Xfast_syscall+0xfb/frame 0xfe0096fcdbf0 --- syscall (499, FreeBSD ELF64, sys_openat), rip = 0x8008f3f7a, rsp = 0x7fffdc28, rbp = 0x7fffdd00
Re: [CURRENT]: r285995: BROKEN! buildkernel fails in kern_shutdown.c
Am Wed, 29 Jul 2015 15:24:22 +0300 Alexandr Krivulya shur...@shurik.kiev.ua schrieb: 29.07.2015 08:50, Conrad Meyer пишет: 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' Fixed in r286002 Thank you. pgpxaAB9nO3pp.pgp Description: OpenPGP digital signature
HEADSUP: Removing GNU binutils versions of nm, readelf etc.
We've been using the ELF Tool Chain version of tools such as nm, readelf, size and strings by default for some time. The Binutils versions can currently be installed instead by setting WITHOUT_ELFTOOLCHAIN_TOOLS in src.conf(5). I'm planning to remove the Binutils versions before too long. The patch is in review at https://reviews.freebsd.org/D3238. If anyone is currently using WITHOUT_ELFTOOLCHAIN_TOOLS in order to install the Binutils tools instead, I'd appreciate knowing why. -Ed ___ 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
About virtio-scsi and\or scsi.
I am testing couple VMs under kvm and from my tests it seems that there might not be support for hot-plug of virtio disks or virtio-scsi disks in freebsd? I wanted to make sure I am understand right the situation FreeBSD is right now. If anyone knows please reply. Thanks, Eliezer ___ 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: IPSEC stop works after r285336
Same here, fixed running r286015. Thanks a bunch. On 29 Jul 2015, at 14:56, Alexandr Krivulya shur...@shurik.kiev.ua wrote: 29.07.2015 10:17, John-Mark Gurney пишет: Alexandr Krivulya wrote this message on Thu, Jul 23, 2015 at 10:38 +0300: [...] With r285535 all works fine. Sydney Meyer wrote this message on Mon, Jul 27, 2015 at 23:49 +0200: I'm having the same problem with IPSec, running -current with r285794. Don't know if this helps, but netstat -s -p esp shows packets dropped; bad ilen. It looks like there was an issue w/ that commit... After looking at the code, and working w/ gnn, I have committed r286000 which fixes it in my test cases... Fixed for me. Thank you! ___ 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
Shutdown fails when there is an active kthread pinned to CPU core 0
Hi, When I create a kthread (kthread_add()) and pin it to CPU 0 (sched_bind() in the beginning of its worker function), shutdown (from the command line) is stuck on a message of Waiting (max 60 seconds) for system process `vnlru' to stop..”. If I pin it to CPU 1 there is no problem. I’m using FreeBSD CURRENT whose last commit is bf0aa3510005188e55285fbed43d93a34448e377 (on July 3rd). Do you have any idea to successfully shutdown the system while leaving a kthread pinned on CPU 0? (I have this problem in the process of implementing a polling kthread for VALE.) Cheers, - Michio ___ 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 #1232 - Fixed
FreeBSD_HEAD-tests - Build #1232 - Fixed: Build information: https://jenkins.FreeBSD.org/job/FreeBSD_HEAD-tests/1232/ Full change log: https://jenkins.FreeBSD.org/job/FreeBSD_HEAD-tests/1232/changes Full build log: https://jenkins.FreeBSD.org/job/FreeBSD_HEAD-tests/1232/console Change summaries: No changes ___ 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: MS DNS doesn't answer to CURRENT under Hyper-V
Hi! r285785 still isn't MFCed. RC2 is coming soon. 2015-07-23 10:54 GMT+03:00 Pavel Timofeev tim...@gmail.com: Ok, sorry! 2015-07-23 7:51 GMT+03:00 Wei Hu w...@microsoft.com: The TCP offloading is still working on these platforms. There is no flag to distinguish UDP and TCP offloading, so the RXCSUM and TXCSUM are still set. Let me know if there is any other way to show it properly. Thanks, Wei -Original Message- From: Pavel Timofeev [mailto:tim...@gmail.com] Sent: Wednesday, July 22, 2015 9:04 PM To: Wei Hu w...@microsoft.com Cc: Slawa Olhovchenkov s...@zxy.spb.ru; freebsd-current@freebsd.org; freebsd-virtualizat...@freebsd.org Subject: Re: MS DNS doesn't answer to CURRENT under Hyper-V Hi! I see you have done the code for disabling UDP checksum offloading when running on the Hyper-V on Windows Server 2012 and earlier hosts https://svnweb.freebsd.org/base?view=revisionrevision=285785 I tried new CURRENT and it works. Thank you! A small note here: while it disables and works it still shows RXCSUM and TSCSUM in iface's options: root@proxy:/usr/src # ifconfig hn0 hn0: flags=8843UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST metric 0 mtu 1500 options=31bRXCSUM,TXCSUM,VLAN_MTU,VLAN_HWTAGGING,TSO4,TSO6 ether 00:15:5d:02:9c:09 inet 192.168.25.26 netmask 0xffc0 broadcast 192.168.25.63 nd6 options=29PERFORMNUD,IFDISABLED,AUTO_LINKLOCAL Is it possible to hide it automatically if it's disabled by new code? 2015-07-13 11:06 GMT+03:00 Wei Hu w...@microsoft.com: We have root caused the problem. This issue happens on the Hyper-Vs on Windows Server 2012 (Win 8.0) and earlier releases. On these releases, the UPD checksum offloading on host side does not work properly. The workaround is to disable UPD checksum offloading in the FreeBSD guest through 'ifconfig'. We are also working on a patch to turn off UPD checksum offloading in the netvsc driver when detecting the Hyper-V releases. The UDP checksum offloading works fine on Windows Server 2012R2 and Win 8.1 hosts. Thanks Pavel and Slawa for the support. Wei -Original Message- From: owner-freebsd-virtualizat...@freebsd.org [mailto:owner-freebsd- virtualizat...@freebsd.org] On Behalf Of Pavel Timofeev Sent: Wednesday, July 8, 2015 4:06 PM To: Slawa Olhovchenkov Cc: freebsd-current@freebsd.org; freebsd-virtualizat...@freebsd.org Subject: Re: MS DNS doesn't answer to CURRENT under Hyper-V Ok, r284746 is the root of the problem. MS DNS works under r284745 and doesn't work under r284746. Slawa, what should I look at in wireshark output? 2015-07-07 18:49 GMT+03:00 Slawa Olhovchenkov s...@zxy.spb.ru: On Tue, Jul 07, 2015 at 06:04:46PM +0300, Pavel Timofeev wrote: Well, turning off checksum offloading by `ifconfig hn0 -txcsum -rxcsum` definitely helps. As for tcpdump I'm not completely sure if I did it right, but I see bad udp cksum phrase: # tcpdump -i hn0 -vvv -nn udp dst port 53 tcpdump: listening on hn0, link-type EN10MB (Ethernet), capture size 262144 bytes 18:01:19.139994 IP (tos 0x0, ttl 64, id 61218, offset 0, flags [none], proto UDP (17), length 51) 192.168.25.26.45683 192.168.25.3.53: [bad udp cksum 0xb39e - 0xf210!] 52886+ A? ya.ru. (23) 18:01:24.140544 IP (tos 0x0, ttl 64, id 17293, offset 0, flags [none], proto UDP (17), length 51) 192.168.25.26.12575 192.168.25.3.53: [bad udp cksum 0xb39e - 0x7365!] 52886+ A? ya.ru. (23) tcpdump bad udp cksum is normal on FreeBSD host in case checksum offload (and may be need only for help finding issuse in code). Need wireshark capturing from MS DNS host (or from mirroring port). ___ freebsd-virtualizat...@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-virtualization To unsubscribe, send any mail to freebsd-virtualization- 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: r285947: broken AESNI support? No aesni0 on Intel XEON E5-1650-v3 on Fujitsu Celsius M740
O. Hartmann wrote this message on Wed, Jul 29, 2015 at 07:39 +0200: 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? Can you send me the output of cpuid-etallen? It's pretty long, so maybe off list would be better... It's from a port of the same name... Also, it looks like a microcode update could fix this issue, have you tried to look at that? https://albertveli.wordpress.com/2013/03/05/aes-ni-enabled/ Looks very similar to your issue, though it's a different microarch.. Your's is a Haswell that has the TSX bug in it, and it could be that the bios is disabling too many feature bits... Have you made sure that your machine has the latest BIOS? A newer BIOS could reenable the feature too... [...] 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 There should be an AESNI feature on this line, but clearly not... [...] aesni0: No AESNI support. [...] Which is why you get this... -- John-Mark Gurney Voice: +1 415 225 5579 All that I will do, has been done, All that I have, has not. ___ 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: r285947: broken AESNI support? No aesni0 on Intel XEON E5-1650-v3 on Fujitsu Celsius M740
On Wed, 29 Jul 2015 00:36:16 -0700 John-Mark Gurney j...@funkthat.com wrote: O. Hartmann wrote this message on Wed, Jul 29, 2015 at 07:39 +0200: 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? Can you send me the output of cpuid-etallen? It's pretty long, so maybe off list would be better... It's from a port of the same name... I'm sorry, since I work in a pretty restricted area, I can not offer webspace-similar download areas, but if it is not offending the list, i could provide a compressed output. Find the output attached xz-compressed ... I cleared intentionally the serial number, just as a notice. Also, it looks like a microcode update could fix this issue, have you tried to look at that? https://albertveli.wordpress.com/2013/03/05/aes-ni-enabled/ Looks very similar to your issue, though it's a different microarch.. Your's is a Haswell that has the TSX bug in it, and it could be that the bios is disabling too many feature bits... Have you made sure that your machine has the latest BIOS? A newer BIOS could reenable the feature too... I just checked this moment again, but the latest UEFI firmware Fujitsu is offering is version 1.8.0 from April of this year. [...] 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 There should be an AESNI feature on this line, but clearly not... On another machine, also Fujitsu, but a 19 inch rack server module with a low energy XEON E5-12XXv3, I can clearly see the AESNI feature in Feature2 list and, conclusively, the aesni0 device is present and reported. [...] aesni0: No AESNI support. [...] Which is why you get this... I applied the port sysutils/cpuid to another system, runnin a i5-4200M mobile CPU (Lenovo notebook). The rows indicating family = Intel ... (simple synth) = ... look much more modern for my opinion as the output I provided shows on the CPU in question. It is just a hunch ... Seems, I've bought Intel(ian) crap ;-) with no features and from another mellenium ... 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: broken symbolic links in /usr/lib
On 29/07/2015 05:48, Jamie Landeg-Jones wrote: 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. A long time ago -- before the millenium -- NeXT machines did away with the need for a mount-point directory to exist. So, if you wanted to mount /foo/bar, only the /foo directory needed to exist prior to the mount. Since NeXT was subsumed by Apple, and NeXTStep reborn as MacOSX, the same is presumably true today all Macs. (Although I haven't tested this personally.) I do wonder why the rest of the world didn't do likewise. It would make this sort of problem a non-event. Cheers, Matthew signature.asc Description: OpenPGP digital signature
FreeBSD_HEAD-tests - Build #1229 - Still Unstable
/execve_test:empty - passed [0.160s] [192.168.10.2] out: sys/kern/execve/execve_test:good_aout - passed [0.111s] [192.168.10.2] out: sys/kern/execve/execve_test:good_script - passed [0.123s] [192.168.10.2] out: sys/kern/execve/execve_test:non_exist - passed [0.084s] [192.168.10.2] out: sys/kern/execve/execve_test:non_exist_shell - passed [0.101s] [192.168.10.2] out: sys/kern/execve/execve_test:script_arg - passed [0.148s] [192.168.10.2] out: sys/kern/execve/execve_test:script_arg_nospace - passed [0.309s] [192.168.10.2] out: sys/kern/execve/execve_test:sparse_aout - passed [0.294s] [192.168.10.2] out: sys/kern/execve/execve_test:trunc_aout - passed [0.262s] [192.168.10.2] out: sys/kqueue/kqueue_test:main - passed [11.338s] [192.168.10.2] out: sys/mqueue/mqueue_test:mqtest1 - passed [0.241s] [192.168.10.2] out: sys/mqueue/mqueue_test:mqtest2 - passed [0.149s] [192.168.10.2] out: sys/mqueue/mqueue_test:mqtest3 - passed [0.123s] [192.168.10.2] out: sys/mqueue/mqueue_test:mqtest4 - passed [0.157s] [192.168.10.2] out: sys/mqueue/mqueue_test:mqtest5 - passed [0.209s] [192.168.10.2] out: sys/netinet/fibs_test:arpresolve_checks_interface_fib - skipped: Required configuration property 'fibs' not defined [0.000s] [192.168.10.2] out: sys/netinet/fibs_test:default_route_with_multiple_fibs_on_same_subnet - skipped: Required configuration property 'fibs' not defined [0.000s] [192.168.10.2] out: sys/netinet/fibs_test:loopback_and_network_routes_on_nondefault_fib - skipped: Required configuration property 'fibs' not defined [0.000s] [192.168.10.2] out: sys/netinet/fibs_test:same_ip_multiple_ifaces - skipped: Required configuration property 'fibs' not defined [0.000s] [192.168.10.2] out: sys/netinet/fibs_test:same_ip_multiple_ifaces_fib0 - skipped: Required configuration property 'fibs' not defined [0.000s] [192.168.10.2] out: sys/netinet/fibs_test:subnet_route_with_multiple_fibs_on_same_subnet - skipped: Required configuration property 'fibs' not defined [0.000s] [192.168.10.2] out: sys/netinet/fibs_test:udp_dontroute - skipped: Required configuration property 'fibs' not defined [0.000s] [192.168.10.2] out: sys/opencrypto/runtests:main - passed [0.250s] [192.168.10.2] out: sys/vm/mmap_test:main - passed [0.050s] [192.168.10.2] out: [192.168.10.2] out: Results file id is usr_tests.20150729-050137-224262 [192.168.10.2] out: Results saved to /root/.kyua/store/results.usr_tests.20150729-050137-224262.db [192.168.10.2] out: [192.168.10.2] out: 4338/4340 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 67548] [192.168.10.2] out: 0 broadcast 192.168.10.255 kyuatestprompt # maxproc limit exceeded by uid 977 (pid 8080); see tuning(7) and login.conf(5) Jul 29 05:14:37 h_fgets: stack overflow detected; terminated Jul 29 05:14:47 h_gets: stack overflow detected; terminated Jul 29 05:14:58 h_memcpy: stack overflow detected; terminated ahcich0: Timeout on slot 15 port 0 ahcich0: is cs ss 00078000 rs 00078000 tfd 50 serr cmd 1000d217 (ada0:ahcich0:0:0:0): WRITE_FPDMA_QUEUED. ACB: 61 40 00 93 13 40 00 00 00 00 00 00 (ada0:ahcich0:0:0:0): CAM status: Command timeout (ada0:ahcich0:0:0:0): Retrying command Jul 29 05:15:38 h_memmove: stack overflow detected; terminated Jul 29 05:15:44 h_memset: stack overflow detected; terminated Jul 29 05:15:54 h_read: stack overflow detected; terminated Jul 29 05:16:02 h_readlink: stack overflow detected; terminated Jul 29 05:16:07 h_snprintf: stack overflow detected; terminated Jul 29 05:16:27 h_sprintf: stack overflow detected; terminated Jul 29 05:16:37 h_stpcpy: stack overflow detected; terminated Jul 29 05:16:42 h_stpncpy: stack overflow detected; terminated Jul 29 05:16:48 h_strcat: stack overflow detected; terminated Jul 29 05:16:55 h_strcpy: stack overflow detected; terminated Jul 29 05:17:15 h_strncat: stack overflow detected; terminated Jul 29 05:17:22 h_strncpy: stack overflow detected; terminated Jul 29 05:17:27 h_vsnprintf: stack overflow detected; terminated Jul 29 05:17:35 h_vsprintf: stack overflow detected; terminated Jul 29 05:19:49 t_openpam_readword: in openpam_readword(): unexpected end of file Jul 29 05:19:49 last message repeated 2 times ahcich0: Timeout on slot 19 port 0 ahcich0: is cs ss fff8 rs fff8 tfd 50 serr cmd 1000df17 (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 ahcicStopping cron. Waiting for PIDS: 577. Stopping sshd
Re: IPSEC stop works after r285336
Alexandr Krivulya wrote this message on Thu, Jul 23, 2015 at 10:38 +0300: [...] With r285535 all works fine. Sydney Meyer wrote this message on Mon, Jul 27, 2015 at 23:49 +0200: I'm having the same problem with IPSec, running -current with r285794. Don't know if this helps, but netstat -s -p esp shows packets dropped; bad ilen. It looks like there was an issue w/ that commit... After looking at the code, and working w/ gnn, I have committed r286000 which fixes it in my test cases... -- John-Mark Gurney Voice: +1 415 225 5579 All that I will do, has been done, All that I have, has not. ___ 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 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. I think the cause was when I moved to an SSD in this laptop and created the filesystems on the new disk by hand. So we're clear, '/usr' (unmounted) is 700, but '/usr' (mounted) is 755? Or is this not the case? This is exactly the case. What's confusing is the inconsistent use of the '/usr' (unmounted) and '/usr' (mounted) modes depending on circumstance. ie, non-root can cd and ls to '/usr' (mounted), but not '/usr' (unmounted), but can't resolve a relative symlink in that path. 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: MS DNS doesn't answer to CURRENT under Hyper-V
It is already in stable/10 branch. I am just about to send the request to re@ for releng/10.2 commit approval. Wei -Original Message- From: Pavel Timofeev [mailto:tim...@gmail.com] Sent: Wednesday, July 29, 2015 3:48 PM To: Wei Hu w...@microsoft.com Cc: Slawa Olhovchenkov s...@zxy.spb.ru; freebsd-current@freebsd.org; freebsd-virtualizat...@freebsd.org Subject: Re: MS DNS doesn't answer to CURRENT under Hyper-V Hi! r285785 still isn't MFCed. RC2 is coming soon. 2015-07-23 10:54 GMT+03:00 Pavel Timofeev tim...@gmail.com: Ok, sorry! 2015-07-23 7:51 GMT+03:00 Wei Hu w...@microsoft.com: The TCP offloading is still working on these platforms. There is no flag to distinguish UDP and TCP offloading, so the RXCSUM and TXCSUM are still set. Let me know if there is any other way to show it properly. Thanks, Wei -Original Message- From: Pavel Timofeev [mailto:tim...@gmail.com] Sent: Wednesday, July 22, 2015 9:04 PM To: Wei Hu w...@microsoft.com Cc: Slawa Olhovchenkov s...@zxy.spb.ru; freebsd-current@freebsd.org; freebsd-virtualizat...@freebsd.org Subject: Re: MS DNS doesn't answer to CURRENT under Hyper-V Hi! I see you have done the code for disabling UDP checksum offloading when running on the Hyper-V on Windows Server 2012 and earlier hosts https://svnweb.freebsd.org/base?view=revisionrevision=285785 I tried new CURRENT and it works. Thank you! A small note here: while it disables and works it still shows RXCSUM and TSCSUM in iface's options: root@proxy:/usr/src # ifconfig hn0 hn0: flags=8843UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST metric 0 mtu 1500 options=31bRXCSUM,TXCSUM,VLAN_MTU,VLAN_HWTAGGING,TSO4,TSO6 ether 00:15:5d:02:9c:09 inet 192.168.25.26 netmask 0xffc0 broadcast 192.168.25.63 nd6 options=29PERFORMNUD,IFDISABLED,AUTO_LINKLOCAL Is it possible to hide it automatically if it's disabled by new code? 2015-07-13 11:06 GMT+03:00 Wei Hu w...@microsoft.com: We have root caused the problem. This issue happens on the Hyper-Vs on Windows Server 2012 (Win 8.0) and earlier releases. On these releases, the UPD checksum offloading on host side does not work properly. The workaround is to disable UPD checksum offloading in the FreeBSD guest through 'ifconfig'. We are also working on a patch to turn off UPD checksum offloading in the netvsc driver when detecting the Hyper-V releases. The UDP checksum offloading works fine on Windows Server 2012R2 and Win 8.1 hosts. Thanks Pavel and Slawa for the support. Wei -Original Message- From: owner-freebsd-virtualizat...@freebsd.org [mailto:owner-freebsd- virtualizat...@freebsd.org] On Behalf Of Pavel Timofeev Sent: Wednesday, July 8, 2015 4:06 PM To: Slawa Olhovchenkov Cc: freebsd-current@freebsd.org; freebsd-virtualizat...@freebsd.org Subject: Re: MS DNS doesn't answer to CURRENT under Hyper-V Ok, r284746 is the root of the problem. MS DNS works under r284745 and doesn't work under r284746. Slawa, what should I look at in wireshark output? 2015-07-07 18:49 GMT+03:00 Slawa Olhovchenkov s...@zxy.spb.ru: On Tue, Jul 07, 2015 at 06:04:46PM +0300, Pavel Timofeev wrote: Well, turning off checksum offloading by `ifconfig hn0 -txcsum -rxcsum` definitely helps. As for tcpdump I'm not completely sure if I did it right, but I see bad udp cksum phrase: # tcpdump -i hn0 -vvv -nn udp dst port 53 tcpdump: listening on hn0, link-type EN10MB (Ethernet), capture size 262144 bytes 18:01:19.139994 IP (tos 0x0, ttl 64, id 61218, offset 0, flags [none], proto UDP (17), length 51) 192.168.25.26.45683 192.168.25.3.53: [bad udp cksum 0xb39e - 0xf210!] 52886+ A? ya.ru. (23) 18:01:24.140544 IP (tos 0x0, ttl 64, id 17293, offset 0, flags [none], proto UDP (17), length 51) 192.168.25.26.12575 192.168.25.3.53: [bad udp cksum 0xb39e - 0x7365!] 52886+ A? ya.ru. (23) tcpdump bad udp cksum is normal on FreeBSD host in case checksum offload (and may be need only for help finding issuse in code). Need wireshark capturing from MS DNS host (or from mirroring port). ___ freebsd-virtualizat...@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-virtualization To unsubscribe, send any mail to freebsd-virtualization- 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 #1230 - Still Unstable
/mdconfig_test:attach_swap - passed [0.333s] [192.168.10.2] out: sbin/mdconfig/mdconfig_test:attach_vnode_explicit_type - passed [0.403s] [192.168.10.2] out: sbin/mdconfig/mdconfig_test:attach_vnode_larger_than_file - passed [0.667s] [192.168.10.2] out: sbin/mdconfig/mdconfig_test:attach_vnode_non_explicit_type - passed [0.358s] [192.168.10.2] out: sbin/mdconfig/mdconfig_test:attach_vnode_sector_size - passed [0.333s] [192.168.10.2] out: sbin/mdconfig/mdconfig_test:attach_vnode_smaller_than_file - passed [0.283s] [192.168.10.2] out: sbin/mdconfig/mdconfig_test:attach_with_specific_unit_number - passed [0.291s] [192.168.10.2] out: sbin/ifconfig/nonexistent_test:nonexistent - passed [0.085s] [192.168.10.2] out: [192.168.10.2] out: Results file id is usr_tests.20150729-095456-098210 [192.168.10.2] out: Results saved to /root/.kyua/store/results.usr_tests.20150729-095456-098210.db [192.168.10.2] out: [192.168.10.2] out: 4338/4340 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 68370] [192.168.10.2] out: f00 broadcast 192.168.10.255 kyuatestprompt # lock order reversal: 1st 0xfe007b223d90 bufwait (bufwait) @ /builds/FreeBSD_HEAD/sys/kern/vfs_bio.c:3190 2nd 0xf800077f1000 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 0xfe0096fdd400 witness_checkorder() at witness_checkorder+0xe7a/frame 0xfe0096fdd480 _sx_xlock() at _sx_xlock+0x75/frame 0xfe0096fdd4c0 ufsdirhash_add() at ufsdirhash_add+0x3d/frame 0xfe0096fdd510 ufs_direnter() at ufs_direnter+0x5da/frame 0xfe0096fdd5e0 ufs_makeinode() at ufs_makeinode+0x5d3/frame 0xfe0096fdd7a0 ufs_create() at ufs_create+0x2d/frame 0xfe0096fdd7c0 VOP_CREATE_APV() at VOP_CREATE_APV+0xf1/frame 0xfe0096fdd7f0 vn_open_cred() at vn_open_cred+0x30e/frame 0xfe0096fdd960 kern_openat() at kern_openat+0x235/frame 0xfe0096fddae0 amd64_syscall() at amd64_syscall+0x282/frame 0xfe0096fddbf0 Xfast_syscall() at Xfast_syscall+0xfb/frame 0xfe0096fddbf0 --- syscall (499, FreeBSD ELF64, sys_openat), rip = 0x8008f2f7a, rsp = 0x7fffbb68, rbp = 0x7fffbc40 --- Jul 29 10:04:28 t_openpam_readword: in openpam_readword(): unexpected end of file Jul 29 10:04:28 last message repeated 2 times maxproc limit exceeded by uid 977 (pid 23273); see tuning(7) and login.conf(5) Jul 29 10:08:57 h_fgets: stack overflow detected; terminated Jul 29 10:09:03 h_gets: stack overflow detected; terminated Jul 29 10:09:04 h_memcpy: stack overflow detected; terminated Jul 29 10:09:05 h_memmove: stack overflow detected; terminated Jul 29 10:09:05 h_memset: stack overflow detected; terminated Jul 29 10:09:08 h_read: stack overflow detected; terminated Jul 29 10:09:11 h_readlink: stack overflow detected; terminated Jul 29 10:09:19 h_snprintf: stack overflow detected; terminated Jul 29 10:09:23 h_sprintf: stack overflow detected; terminated Jul 29 *** FINAL System shutdown message from root@ *** System going down IMMEDIATELY Jul 29 10:42:19 shutdown: power-down by root: Stopping cron. Waiting for PIDS: 577. Stopping sshd. Waiting for PIDS: 542. Stopping casperd. Waiting for PIDS: 443. Stopping devd. Waiting for PIDS: 275. Writing entropy file:. Writing early boot entropy file:. . Terminated Jul 29 10:42:20 syslogd: exiting on signal 15 Waiting (max 60 seconds) for system process `vnlru' to stop...done Waiting (max 60 seconds) for system process `bufdaemon' to stop...done Waiting (max 60 seconds) for system process `syncer' to stop... Syncing disks, vnodes remaining...0 0 done All buffers synced. lock order reversal: 1st 0xf800072c97c8 ufs (ufs) @ /builds/FreeBSD_HEAD/sys/kern/vfs_mount.c:1224 2nd 0xf800072ca240 devfs (devfs) @ /builds/FreeBSD_HEAD/sys/kern/vfs_subr.c:2219 KDB: stack backtrace: db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame 0xfe007b995630 witness_checkorder() at witness_checkorder+0xe7a/frame 0xfe007b9956b0 __lockmgr_args() at __lockmgr_args+0xa5c/frame 0xfe007b9957e0 vop_stdlock() at vop_stdlock+0x3c/frame 0xfe007b995800 VOP_LOCK1_APV() at VOP_LOCK1_APV+0xfc/frame 0xfe007b995830 _vn_lock() at _vn_lock+0x9a/frame 0xfe007b9958a0 vget() at vget+0x7e/frame 0xfe007b9958f0 devfs_allocv() at devfs_allocv+0xfd/frame 0xfe007b995940 devfs_root
Re: IPSEC stop works after r285336
29.07.2015 10:17, John-Mark Gurney пишет: Alexandr Krivulya wrote this message on Thu, Jul 23, 2015 at 10:38 +0300: [...] With r285535 all works fine. Sydney Meyer wrote this message on Mon, Jul 27, 2015 at 23:49 +0200: I'm having the same problem with IPSec, running -current with r285794. Don't know if this helps, but netstat -s -p esp shows packets dropped; bad ilen. It looks like there was an issue w/ that commit... After looking at the code, and working w/ gnn, I have committed r286000 which fixes it in my test cases... Fixed for me. Thank you! ___ 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 0728T1419, Luigi Rizzo 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. https://reviews.freebsd.org/D2172 ___ 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
29.07.2015 08:50, Conrad Meyer пишет: 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' Fixed in r286002 ___ 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
