Re: ssh None cipher
Freddie Cash wrote this message on Sat, Oct 18, 2014 at 10:21 -0700: On Oct 18, 2014 3:54 AM, Mark Martinec mark.martinec+free...@ijs.si wrote: If the purpose of having a none cipher is to have a fast file transfer, then one should be using sysutils/bbcp for that purposes. Uses ssd for authentication, and opens unencrypted channel(s) for the actual data transfer. It's also very fast, can use multiple TCP streams. That's an interesting alternative to rsync, scp, and ftp, but doesn't help with zfs send/recv which is where the none cipher really shines. Without the none cipher, SSH becomes the bottleneck limiting transfers to around 400 Mbps on a gigabit LAN. With the none cipher, the network becomes the bottleneck limiting transfers to around 920 Mbps on the same gigabit LAN. This is between two 8-core AMD Opteron 6200 systems using igb(4) NICs. Are you running on HEAD or possibly 10.x (I believe we have OpenSSL 1.0.x on 10.x)? w/ modern processors w/ AES-NI and a modern version of OpenSSL, you should be able to get much faster speeds than that... I'm able to get ~200MB/s over lo0 on my HEAD box on a: CPU: AMD A10-5700 APU with Radeon(tm) HD Graphics(3393.89-MHz K8-class CPU) $ netstat -w 1 -I lo0 inputlo0 output packets errs idrops bytespackets errs bytes colls 39162 0 0 207823548 39162 0 207823548 0 26327 0 0 158674156 26327 0 158674156 0 38254 0 0 221313096 38254 0 221313096 0 41362 0 0 219740344 41362 0 219740344 0 40271 0 0 213565272 40271 0 213565272 0 37698 0 0 225447008 37698 0 225447008 0 while running: $ ssh 0 dd if=/dev/zero /dev/null This is w/ no special patches to OpenSSL or ssh... It could go twice as fast if ssh could use multiple threads to do the encryption (the processor has 4 cores, 2 would be used for sending, 2 for receiving)... -- 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: kernel page fault with nfs
both are at 1100038. On Sunday 19 October 2014 11.12:36 Marcelo Araujo wrote: It is still strange, could you do what Allan said and send us the result in case you are not sure you have world and kernel in the same revision! On Oct 19, 2014 6:48 AM, Tobias C. Berner tcber...@gmail.com wrote: Hi World ist from october 16, installed world and kernel then. Kernel was later rebuilt with debug-options. Is the following more sensible? ## # kgdb NOXON/kernel.debug vmcore.1 Fatal trap 12: page fault while in kernel mode cpuid = 5; apic id = 05 fault virtual address = 0xfe07d1744000 fault code = supervisor write data, page not present instruction pointer = 0x20:0x80d4d58a stack pointer = 0x28:0xfe086057f240 frame pointer = 0x28:0xfe086057f2f0 code segment = base 0x0, limit 0xf, type 0x1b = DPL 0, pres 1, long 1, def32 0, gran 1 processor eflags = interrupt enabled, resume, IOPL = 0 current process = 6524 (python2.7) (kgdb) bt #0 doadump (textdump=1) at pcpu.h:219 #1 0x80926b6d in kern_reboot (howto=260) at /usr/src/sys/kern/kern_shutdown.c:447 #2 0x809270c0 in panic (fmt=value optimized out) at /usr/src/sys/kern/kern_shutdown.c:746 #3 0x8035f167 in db_panic (addr=value optimized out, have_addr=2, count=0, modif=0x0) at /usr/src/sys/ddb/db_command.c:473 #4 0x8035ed7d in db_command (cmd_table=0x0) at /usr/src/sys/ddb/db_command.c:440 #5 0x8035eaf4 in db_command_loop () at /usr/src/sys/ddb/db_command.c:493 #6 0x80361600 in db_trap (type=value optimized out, code=0) at /usr/src/sys/ddb/db_main.c:251 #7 0x80966f01 in kdb_trap (type=12, code=0, tf=value optimized out) at /usr/src/sys/kern/subr_kdb.c:654 #8 0x80d4fa7c in trap_fatal (frame=0xfe086057f190, eva=value optimized out) at /usr/src/sys/amd64/amd64/trap.c:861 #9 0x80d4fe0c in trap_pfault (frame=0xfe086057f190, usermode=value optimized out) at /usr/src/sys/amd64/amd64/trap.c:677 #10 0x80d4f42e in trap (frame=0xfe086057f190) at /usr/src/sys/amd64/amd64/trap.c:426 #11 0x80d33972 in calltrap () at /usr/src/sys/amd64/amd64/exception.S:231 #12 0x80d4d58a in bzero () at /usr/src/sys/amd64/amd64/support.S:53 #13 0x80830463 in ncl_doio (vp=0xf801e7f99938, bp=0xfe07c5a168e8, cr=value optimized out, td=value optimized out, called_from_strategy=value optimized out) at /usr/src/sys/fs/nfsclient/nfs_clbio.c:1648 #14 0x80831acf in ncl_write (ap=value optimized out) at /usr/src/sys/fs/nfsclient/nfs_clbio.c:1124 #15 0x80e646a5 in VOP_WRITE_APV (vop=value optimized out, a=value optimized out) at vnode_if.c:997 #16 0x809f52f9 in vn_write (fp=0xf80101c62780, uio=0xfe086057f970, active_cred=value optimized out, flags=320, td=0x0) at vnode_if.h:413 #17 0x809f5602 in vn_io_fault_doio (args=value optimized out, uio=0xa00, td=0x0) at /usr/src/sys/kern/vfs_vnops.c:991 #18 0x809f2aec in vn_io_fault1 () at /usr/src/sys/kern/vfs_vnops.c:1047 #19 0x809f0e3b in vn_io_fault (fp=0xf80101c62780, uio=0xfe086057f970, active_cred=value optimized out, flags=0, td=0xf80171d79920) at /usr/src/sys/kern/vfs_vnops.c:1152 #20 0x80982357 in dofilewrite (td=0xf80171d79920, fd=19, fp=0xf80101c62780, auio=0xfe086057f970, offset=value optimized out, flags=0) at file.h:306 #21 0x80982088 in kern_writev (td=0xf80171d79920, fd=19, auio=0xfe086057f970) at /usr/src/sys/kern/sys_generic.c:467 #22 0x80982013 in sys_write (td=value optimized out, uap=value optimized out) at /usr/src/sys/kern/sys_generic.c:382 #23 0x80d5051b in amd64_syscall (td=0xf80171d79920, traced=0) at subr_syscall.c:133 #24 0x80d33c5b in Xfast_syscall () at /usr/src/sys/amd64/amd64/exception.S:390 #25 0x00080137de4a in ?? () ## Thanks in advance, Tobias Berner On Saturday 18 October 2014 20.43:12 Marcelo Araujo wrote: When you rebuild your system, did you rebuild and install all kernel and world? Best Regards, On Oct 18, 2014 7:57 PM, John Baldwin j...@freebsd.org wrote: On Friday, October 17, 2014 11:11:26 PM Tobias C. Berner wrote: Hi For some days now I've had problems with my current (last test with r273178M). Sometimes when accessing a nfs-share there is a pagefault: ### Fatal trap 12: page fault while in kernel mode
Re: HEADS UP: Merging projects/bhyve_svm to HEAD
On 16-10-2014 5:00, Anish Gupta wrote: Hi all, The projects/bhyve_svm branch is ready to be merged to HEAD. This branch contains patches to bhyve to enable it to work on AMD processors with SVM/AMD-V hardware extensions[1]. Pretty much any AMD processor since 2010 will have the features required by bhyve. bhyve on AMD supports (almost) all the features available with Intel [2]. All guest OSes supported on Intel are supported on AMD. All the bhyve-related utilities function similarly on both Intel and AMD platforms [3]. The patch against HEAD revision 273066 is available for review and testing: https://people.freebsd.org/~neel/bhyve/bhyve_svm.diff [Neel’s web directory] [1]: http://en.wikipedia.org/wiki/X86_virtualization [2]: bhyve doesn't support PCI passthru on AMD at this time [3]: bhyvectl has grown some processor-specific options Fetched the patch and compiled. Now running: HEAD r273066M and I was able to throw at it all the tests and images that in the past works. And perhaps even better. Great work. --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: WiFi 802.11/ac PCIe supported adaptor
Am Sun, 28 Sep 2014 14:50:02 -0600 (MDT) Warren Block wbl...@wonkity.com schrieb: On Sun, 28 Sep 2014, Gavin Atkinson wrote: On Sun, 28 Sep 2014, O. Hartmann wrote: Networking wasn't an issue for me for years, but now, sitting on a pile of neat new hardware of which FreeBSD can not make any serious use, let me rethink. Luckily, The Lenovo laptops have a mini PCIe WiFi NIC - if I'm willing to follow FreeBSDs agony I'm able to swap the NIC with a piece of hardware that is supported. But it is additional Unfortunately, many Lenovo laptops lock the BIOS down in such a way that they won't boot without the NIC they were shipped with :( Yes, I realized this very sadly today. Intel 6300 WiFi adapter isn't recognized, the crap of Laptop rejects starting firmware and I get a message telling me using uncertified hardware. Last time I bought a Laptop from Lenovo! Well, or a short list of approved Lenovo-branded cards. In the past, Lenovo (or IBM) has supplied Atheros cards. The trick will be finding that list and identifying the chipsets on each. There are also unofficial BIOS modifications to remove the limits. There are lists, but they are outdated and newer chipsets aren't listed. There are also some bad hacks changing the PCI ID of the new mini PCIe card to be recognized by the EFI, but this seems to be very, very difficult to me. The notebook is now running Ubuntu 14.04. WiFi is recognized by the Linux natively as well as I can use the nVidia graphics of the notebook. Also the built-in Realtek NIC, which doesn't work properly even under FreeBSD 11.0-CURRENT as of Friday last week (the NIC is down until it is switched off and on manually), is working as expected. signature.asc Description: PGP signature
Re: zfs recv hangs in kmem arena
Removing kern.maxfiles from loader.conf still hangs in kmem arena. I tried using a memstick image of -CURRENT made from the release/ process and this also hangs in kmem arena An uninvolved server of mine hung Friday night in statekmem arena during periodic's zpool history. After a reboot it did not hang Saturday night. On 10/16/2014 11:37 PM, James R. Van Artsdalen wrote: On 10/16/2014 11:10 PM, Xin Li wrote: On 10/16/14 8:43 PM, James R. Van Artsdalen wrote: On 10/16/2014 11:12 AM, Xin Li wrote: On 9/26/2014 1:42 AM, James R. Van Artsdalen wrote: FreeBSD BLACKIE.housenet.jrv 10.1-BETA2 FreeBSD 10.1-BETA2 #2 r272070M: Wed Sep 24 17:36:56 CDT 2014 ja...@blackie.housenet.jrv:/usr/obj/usr/src/sys/GENERIC amd64 With current STABLE10 I am unable to replicate a ZFS pool using zfs send/recv without zfs hanging in state kmem arena, within the first 4TB or so (of a 23TB Pool). What does procstat -kk 1176 (or the PID of your 'zfs' process that stuck in that state) say? Cheers, SUPERTEX:/root# ps -lp 866 UID PID PPID CPU PRI NI VSZ RSS MWCHAN STAT TT TIME COMMAND 0 866 863 0 52 0 66800 29716 kmem are D+1 57:40.82 zfs recv -duvF BIGTOX SUPERTEX:/root# procstat -kk 866 PIDTID COMM TDNAME KSTACK 866 101573 zfs -mi_switch+0xe1 sleepq_wait+0x3a _cv_wait+0x16d vmem_xalloc+0x568 vmem_alloc+0x3d kmem_malloc+0x33 keg_alloc_slab+0xcd keg_fetch_slab+0x151 zone_fetch_slab+0x7e zone_import+0x40 uma_zalloc_arg+0x34e arc_get_data_buf+0x31a arc_buf_alloc+0xaa dmu_buf_will_fill+0x169 dmu_write+0xfc dmu_recv_stream+0xd40 zfs_ioc_recv+0x94e zfsdev_ioctl+0x5ca Do you have any special tuning in your /boot/loader.conf? Cheers, Below. I had forgotten some of this was there. After sending the previous message I ran kgdb to see if I could get a backtrace with function args. I didn't see how to do it for this proc, but during all this the process un-blocked and started running again. The process blocked again in kmem arena after a few minutes. SUPERTEX:/root# cat /boot/loader.conf zfs_load=YES # ZFS vfs.root.mountfrom=zfs:SUPERTEX/UNIX# Specify root partition in a way the # kernel understands kern.maxfiles=32K# Set the sys. wide open files limit kern.ktrace.request_pool=512 #vfs.zfs.debug=1 vfs.zfs.check_hostid=0 loader_logo=beastie# Desired logo: fbsdbw, beastiebw, beastie, none boot_verbose=YES# -v: Causes extra debugging information to be printed geom_mirror_load=YES# RAID1 disk driver (see gmirror(8)) geom_label_load=YES# File system labels (see glabel(8)) ahci_load=YES siis_load=YES mvs_load=YES coretemp_load=YES# Intel Core CPU temperature monitor #console=comconsole kern.msgbufsize=131072# Set size of kernel message buffer kern.geom.label.gpt.enable=0 kern.geom.label.gptid.enable=0 kern.geom.label.disk_ident.enable=0 SUPERTEX:/root# ___ 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 virtualbox-ose-kmod build
Hello,
after updating to -current r273266 I have problem with building any port
with portmaster like this:
=== libdrm-2.4.58_1,1 depends on file: /usr/local/sbin/pkg - found
usage: mkdir [-pv] [-m mode] directory_name ...
make:: not found
*** Error code 127
And another, not related issue, is virtualbox-ose-kmod. If I try to
build it with make install clean I got this:
*** Building 'vboxdrv' module ***
make[3]: /usr/src/sys/conf/kmod.mk line 199: Malformed conditional
(${MK_CTF} != no)
make[3]: Fatal errors encountered -- cannot continue
make[3]: stopped in
/mnt/media/d1/ports/emulators/virtualbox-ose-kmod/work/VirtualBox-4.3.16/out/freebsd.amd64/release/bin/src/vboxdrv
*** [all] Error code 1
make[2]: stopped in
/mnt/media/d1/ports/emulators/virtualbox-ose-kmod/work/VirtualBox-4.3.16/out/freebsd.amd64/release/bin/src
1 error
make[2]: stopped in
/mnt/media/d1/ports/emulators/virtualbox-ose-kmod/work/VirtualBox-4.3.16/out/freebsd.amd64/release/bin/src
=== Compilation failed unexpectedly.
Does anybody aware of this issue?
--
Regards,
Ruslan
T.O.S. Of Reality
___
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
Compiling Xen on FreeBSD using clang ...
All, As most of you are probably aware, Roger at Citrix RD has been doing some incredible work to bring PVH domU/dom0 support to FreeBSD. There has also been an effort by other Xen developers to get the software to compile using clang. While most of these attempts appear to be on Linux platforms targeting arm processors, the FreeBSD version of binutils is quite a bit older. Clang still can't parse all of the assembly that Xen requires, so unfortunately the -no-integrated-as option has to be used in several cases. Which brings me to my question, is there a way to ask clang to use the ports version of binutils when -no-integrated-as is passed to clang? The version of 'as' in base fails to compile such as ... /tmp/misc-bf1339.s: Assembler messages: /tmp/misc-bf1339.s:375: Error: unknown pseudo-op: `.cfi_sections' If /usr/local/bin/as is symlinked to /usr/bin/as, the compile completes but I assume there is a better way to tell clang where the external as binary is when -no-integrated-as is invoked. I've googled a bunch but came up empty handed so far. I thought it would be worth asking here in case someone has already run across this problem and had more insight. Thanks, -Matthew ___ 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: WiFi 802.11/ac PCIe supported adaptor
:( We are working on the 7260 driver support in our spare time. But, it's a spare time thing. It'll happen when it happens. If this is important to you (and it sounds like it is!) then please: * write a nicely worded email to the freebsd foundation, telling them how much you like freebsd and how much you'd like to use it on laptops, except for the missing hardware support, and that is really important to you; * please consider donating something to the freebsd foundation so they can sponsor projects like this. Thanks! -adrian (sleep? What's that.) On 19 October 2014 07:30, O. Hartmann ohart...@zedat.fu-berlin.de wrote: Am Sun, 28 Sep 2014 14:50:02 -0600 (MDT) Warren Block wbl...@wonkity.com schrieb: On Sun, 28 Sep 2014, Gavin Atkinson wrote: On Sun, 28 Sep 2014, O. Hartmann wrote: Networking wasn't an issue for me for years, but now, sitting on a pile of neat new hardware of which FreeBSD can not make any serious use, let me rethink. Luckily, The Lenovo laptops have a mini PCIe WiFi NIC - if I'm willing to follow FreeBSDs agony I'm able to swap the NIC with a piece of hardware that is supported. But it is additional Unfortunately, many Lenovo laptops lock the BIOS down in such a way that they won't boot without the NIC they were shipped with :( Yes, I realized this very sadly today. Intel 6300 WiFi adapter isn't recognized, the crap of Laptop rejects starting firmware and I get a message telling me using uncertified hardware. Last time I bought a Laptop from Lenovo! Well, or a short list of approved Lenovo-branded cards. In the past, Lenovo (or IBM) has supplied Atheros cards. The trick will be finding that list and identifying the chipsets on each. There are also unofficial BIOS modifications to remove the limits. There are lists, but they are outdated and newer chipsets aren't listed. There are also some bad hacks changing the PCI ID of the new mini PCIe card to be recognized by the EFI, but this seems to be very, very difficult to me. The notebook is now running Ubuntu 14.04. WiFi is recognized by the Linux natively as well as I can use the nVidia graphics of the notebook. Also the built-in Realtek NIC, which doesn't work properly even under FreeBSD 11.0-CURRENT as of Friday last week (the NIC is down until it is switched off and on manually), is working as expected. ___ 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: ssh None cipher
On Oct 19, 2014 12:46 AM, John-Mark Gurney j...@funkthat.com wrote: Freddie Cash wrote this message on Sat, Oct 18, 2014 at 10:21 -0700: On Oct 18, 2014 3:54 AM, Mark Martinec mark.martinec+free...@ijs.si wrote: If the purpose of having a none cipher is to have a fast file transfer, then one should be using sysutils/bbcp for that purposes. Uses ssd for authentication, and opens unencrypted channel(s) for the actual data transfer. It's also very fast, can use multiple TCP streams. That's an interesting alternative to rsync, scp, and ftp, but doesn't help with zfs send/recv which is where the none cipher really shines. Without the none cipher, SSH becomes the bottleneck limiting transfers to around 400 Mbps on a gigabit LAN. With the none cipher, the network becomes the bottleneck limiting transfers to around 920 Mbps on the same gigabit LAN. This is between two 8-core AMD Opteron 6200 systems using igb(4) NICs. Are you running on HEAD or possibly 10.x (I believe we have OpenSSL 1.0.x on 10.x)? Nope, 9.2. And I don't think the 6200 series Opterons have AES-NI. ___ 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: ssh None cipher
On 2014-10-19 03:46, John-Mark Gurney wrote: Freddie Cash wrote this message on Sat, Oct 18, 2014 at 10:21 -0700: On Oct 18, 2014 3:54 AM, Mark Martinec mark.martinec+free...@ijs.si wrote: If the purpose of having a none cipher is to have a fast file transfer, then one should be using sysutils/bbcp for that purposes. Uses ssd for authentication, and opens unencrypted channel(s) for the actual data transfer. It's also very fast, can use multiple TCP streams. That's an interesting alternative to rsync, scp, and ftp, but doesn't help with zfs send/recv which is where the none cipher really shines. Without the none cipher, SSH becomes the bottleneck limiting transfers to around 400 Mbps on a gigabit LAN. With the none cipher, the network becomes the bottleneck limiting transfers to around 920 Mbps on the same gigabit LAN. This is between two 8-core AMD Opteron 6200 systems using igb(4) NICs. Are you running on HEAD or possibly 10.x (I believe we have OpenSSL 1.0.x on 10.x)? w/ modern processors w/ AES-NI and a modern version of OpenSSL, you should be able to get much faster speeds than that... I'm able to get ~200MB/s over lo0 on my HEAD box on a: CPU: AMD A10-5700 APU with Radeon(tm) HD Graphics(3393.89-MHz K8-class CPU) $ netstat -w 1 -I lo0 inputlo0 output packets errs idrops bytespackets errs bytes colls 39162 0 0 207823548 39162 0 207823548 0 26327 0 0 158674156 26327 0 158674156 0 38254 0 0 221313096 38254 0 221313096 0 41362 0 0 219740344 41362 0 219740344 0 40271 0 0 213565272 40271 0 213565272 0 37698 0 0 225447008 37698 0 225447008 0 while running: $ ssh 0 dd if=/dev/zero /dev/null This is w/ no special patches to OpenSSL or ssh... It could go twice as fast if ssh could use multiple threads to do the encryption (the processor has 4 cores, 2 would be used for sending, 2 for receiving)... There is a patch for threaded AES-CTR in the openssh-portable port. Might be worth benchmarking that. -- Allan Jude signature.asc Description: OpenPGP digital signature
Re: Compiling Xen on FreeBSD using clang ...
On 19 Oct 2014, at 18:34, Matthew Grooms mgro...@shrew.net wrote: As most of you are probably aware, Roger at Citrix RD has been doing some incredible work to bring PVH domU/dom0 support to FreeBSD. There has also been an effort by other Xen developers to get the software to compile using clang. While most of these attempts appear to be on Linux platforms targeting arm processors, the FreeBSD version of binutils is quite a bit older. Clang still can't parse all of the assembly that Xen requires, so unfortunately the -no-integrated-as option has to be used in several cases. What kind of assembly is that? And are you using clang 3.4.1 from base? Which brings me to my question, is there a way to ask clang to use the ports version of binutils when -no-integrated-as is passed to clang? The version of 'as' in base fails to compile such as ... /tmp/misc-bf1339.s: Assembler messages: /tmp/misc-bf1339.s:375: Error: unknown pseudo-op: `.cfi_sections' Yes, binutils in base is forever stuck at version 2.17.50, which is ancient by by now. If /usr/local/bin/as is symlinked to /usr/bin/as, the compile completes but I assume there is a better way to tell clang where the external as binary is when -no-integrated-as is invoked. I've googled a bunch but came up empty handed so far. I thought it would be worth asking here in case someone has already run across this problem and had more insight. Yes, just pass -B/usr/local/bin on the command line. Note that this will make it search for *all* external tools in /usr/local/bin, e.g. ld will also be run from there. For example: $ clang -v -no-integrated-as -B/usr/local/bin hello-world.c -o hello-world FreeBSD clang version 3.4.1 (tags/RELEASE_34/dot1-final 208032) 20140512 Target: i386-unknown-freebsd11.0 Thread model: posix Selected GCC installation: /usr/bin/clang -cc1 -triple i386-unknown-freebsd11.0 -S -disable-free -main-file-name hello-world.c -mrelocation-model static -mdisable-fp-elim -masm-verbose -mconstructor-aliases -target-cpu i486 -v -resource-dir /usr/bin/../lib/clang/3.4.1 -fno-dwarf-directory-asm -fdebug-compilation-dir /share/dim/src/misc -ferror-limit 19 -fmessage-length 297 -mstackrealign -fobjc-runtime=gnustep -fdiagnostics-show-option -fcolor-diagnostics -vectorize-slp -o /home/dim/tmp/hello-world-410124.s -x c hello-world.c clang -cc1 version 3.4.1 based upon LLVM 3.4.1 default target i386-unknown-freebsd11.0 ignoring nonexistent directory /usr/bin/../lib/clang/3.4.1/include #include ... search starts here: #include ... search starts here: /usr/include/clang/3.4.1 /usr/include End of search list. /usr/local/bin/as --32 -o /home/dim/tmp/hello-world-288694.o /home/dim/tmp/hello-world-410124.s /usr/local/bin/ld --eh-frame-hdr -dynamic-linker /libexec/ld-elf.so.1 --hash-style=both --enable-new-dtags -m elf_i386_fbsd -o hello-world /usr/lib/crt1.o /usr/lib/crti.o /usr/lib/crtbegin.o -L/usr/lib /home/dim/tmp/hello-world-288694.o -lgcc --as-needed -lgcc_s --no-as-needed -lc -lgcc --as-needed -lgcc_s --no-as-needed /usr/lib/crtend.o /usr/lib/crtn.o -Dimitry ___ 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: Compiling Xen on FreeBSD using clang ...
On Sun, 19 Oct 2014, Matthew Grooms wrote: All, As most of you are probably aware, Roger at Citrix RD has been doing some incredible work to bring PVH domU/dom0 support to FreeBSD. There has also been an effort by other Xen developers to get the software to compile using clang. While most of these attempts appear to be on Linux platforms targeting arm processors, the FreeBSD version of binutils is quite a bit older. Clang still can't parse all of the assembly that Xen requires, so unfortunately the -no-integrated-as option has to be used in several cases. Which brings me to my question, is there a way to ask clang to use the ports version of binutils when -no-integrated-as is passed to clang? The version of 'as' in base fails to compile such as ... /tmp/misc-bf1339.s: Assembler messages: /tmp/misc-bf1339.s:375: Error: unknown pseudo-op: `.cfi_sections' I have recently managed to compile Xen (4.5 unstable from git master) using few patches in the source code (I posted them to xen-devel@, most of them are almost the same as some earlier work by Julien Grall). I have used clang version 3.5.0 (trunk) from ports just for the .code16 support, other than that clang 3.4.1 was fine. Xen kernel compiled this way even boots successfully and starts Debian dom0. This command was used to compile with 3.4.1 (without hvmloader): env CFLAGS=-I/usr/local/include LDFLAGS=-L/usr/local/lib gmake clang=y CC=clang-devel HOSTCC=clang-devel CONFIG_SEABIOS=y CONFIG_HVMLOADER=n SEABIOS_PATH=$HOME/qemu/bios.bin-1.7.5 CONFIG_QEMU=n $@ //Marcin ___ 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: HEADS UP: Merging projects/bhyve_svm to HEAD
After a few days of extensive testing and abuse, i’ve run into no new issues or unknowns what so ever. Everything that worked before still works now ( and a few bugs from fixed from HEAD ). Thus, I have gone ahead and pushed r273182 w/ Neel’s patch out to about 80 of the assorted AMD boxes in the production and dev pods that I care for. If end users see something, I’ll let you know, but I have a feeling they won’t. Again - Excellent work. cheers, -bp On Oct 19, 2014, at 5:03 AM, Willem Jan Withagen w...@digiware.nl wrote: On 16-10-2014 5:00, Anish Gupta wrote: Hi all, The projects/bhyve_svm branch is ready to be merged to HEAD. This branch contains patches to bhyve to enable it to work on AMD processors with SVM/AMD-V hardware extensions[1]. Pretty much any AMD processor since 2010 will have the features required by bhyve. bhyve on AMD supports (almost) all the features available with Intel [2]. All guest OSes supported on Intel are supported on AMD. All the bhyve-related utilities function similarly on both Intel and AMD platforms [3]. The patch against HEAD revision 273066 is available for review and testing: https://people.freebsd.org/~neel/bhyve/bhyve_svm.diff [Neel’s web directory] [1]: http://en.wikipedia.org/wiki/X86_virtualization [2]: bhyve doesn't support PCI passthru on AMD at this time [3]: bhyvectl has grown some processor-specific options Fetched the patch and compiled. Now running: HEAD r273066M and I was able to throw at it all the tests and images that in the past works. And perhaps even better. Great work. --WjW ___ 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
Voxer using FreeBSD, BSDNow.tv interview
Hi, If you don't watch BSDNow.tv ( http://bsdnow.tv ), I encourage you to do so. Allan Jude and Kris Moore do a great job of doing a weekly video podcast of news in the BSD world. It is great stuff. In episode 58 ( http://www.bsdnow.tv/episodes/2014_10_08-behind_the_masq ) BSDNow interviewed the CTO of Voxer ( http://voxer.com ), a mobile messaging startup based in San Francisco. Voxer mentioned how they transitioned from SmartOS (an Illumos/Solaris distribution) to FreeBSD. What Voxer liked: (1) DTrace worked for their node.js apps (2) ZFS worked nicely (3) jails work nicely (4) Easy to transition away from SmartOS/Illumos because of (1) and (2) (5) Better support for 3rd party applications (ports) than SmartOS/Illumos (6) Better hardware support than SmartOS/Illumos (7) Good documentation, professional/technical discussions on mailing lists (8) For people who use MacOS X, the FreeBSD command-line utilities were familiar What Voxer didn't like: Voxer was super positive about FreeBSD in the interview, and didn't really mention many downsides to their transition. The only things I could pick up on: (1) Support for FreeBSD in Chef was not as good as they would have liked. They actually have patches to Chef for FreeBSD which they want to upstream. (2) Most devops engineers in web/mobile companies are familiar with Linux. Any differences between Linux and FreeBSD in command-line utilities are not show-stoppers, but they are annoyances. Anything FreeBSD could do to help people used to Linux would be a big help. Allan Jude even brought up my request to symlink /bin/bash ( https://lists.freebsd.org/pipermail/freebsd-ports/2014-September/095483.html ) :) The interview was really good, and I encourage everyone to watch it. It's nice to see a modern web/mobile company migrating *to* FreeBSD. -- Craig ___ 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: Compiling Xen on FreeBSD using clang ...
On 10/19/2014 2:27 PM, Dimitry Andric wrote: On 19 Oct 2014, at 18:34, Matthew Grooms mgro...@shrew.net wrote: As most of you are probably aware, Roger at Citrix RD has been doing some incredible work to bring PVH domU/dom0 support to FreeBSD. There has also been an effort by other Xen developers to get the software to compile using clang. While most of these attempts appear to be on Linux platforms targeting arm processors, the FreeBSD version of binutils is quite a bit older. Clang still can't parse all of the assembly that Xen requires, so unfortunately the -no-integrated-as option has to be used in several cases. What kind of assembly is that? And are you using clang 3.4.1 from base? There wasn't much of Xen proper that had issues compiling the assembly. Most of the headache came when compiling seabios which is wrapped up in the Xen source code. One problem was the .code16 sections as mentioned by Marcin Cieslak later in this email thread. Maybe related to this? http://lists.cs.uiuc.edu/pipermail/llvmdev/2014-January/069375.html I tried passing the -m16 flag to clang 3.4.1, but it complained about not being a recognized option ( or I wasn't using it properly ). Maybe support for this was first included in the 3.4.2 or the 3.5 release. Which brings me to my question, is there a way to ask clang to use the ports version of binutils when -no-integrated-as is passed to clang? The version of 'as' in base fails to compile such as ... /tmp/misc-bf1339.s: Assembler messages: /tmp/misc-bf1339.s:375: Error: unknown pseudo-op: `.cfi_sections' Yes, binutils in base is forever stuck at version 2.17.50, which is ancient by by now. If /usr/local/bin/as is symlinked to /usr/bin/as, the compile completes but I assume there is a better way to tell clang where the external as binary is when -no-integrated-as is invoked. I've googled a bunch but came up empty handed so far. I thought it would be worth asking here in case someone has already run across this problem and had more insight. Yes, just pass -B/usr/local/bin on the command line. Note that this will make it search for *all* external tools in /usr/local/bin, e.g. ld will also be run from there. For example: Thanks for the feedback. I'll try this out. My goal was to get a set of patches that could be used to pull Xen into the ports tree. With that in mind I was trying to rely on the system compiler as much as possible. If an LLVM 3.5 import is imminent, then it may solve all of the issues, at least for CURRENT ( the only dom0 relevant branch ). $ clang -v -no-integrated-as -B/usr/local/bin hello-world.c -o hello-world FreeBSD clang version 3.4.1 (tags/RELEASE_34/dot1-final 208032) 20140512 Target: i386-unknown-freebsd11.0 Thread model: posix Selected GCC installation: /usr/bin/clang -cc1 -triple i386-unknown-freebsd11.0 -S -disable-free -main-file-name hello-world.c -mrelocation-model static -mdisable-fp-elim -masm-verbose -mconstructor-aliases -target-cpu i486 -v -resource-dir /usr/bin/../lib/clang/3.4.1 -fno-dwarf-directory-asm -fdebug-compilation-dir /share/dim/src/misc -ferror-limit 19 -fmessage-length 297 -mstackrealign -fobjc-runtime=gnustep -fdiagnostics-show-option -fcolor-diagnostics -vectorize-slp -o /home/dim/tmp/hello-world-410124.s -x c hello-world.c clang -cc1 version 3.4.1 based upon LLVM 3.4.1 default target i386-unknown-freebsd11.0 ignoring nonexistent directory /usr/bin/../lib/clang/3.4.1/include #include ... search starts here: #include ... search starts here: /usr/include/clang/3.4.1 /usr/include End of search list. /usr/local/bin/as --32 -o /home/dim/tmp/hello-world-288694.o /home/dim/tmp/hello-world-410124.s /usr/local/bin/ld --eh-frame-hdr -dynamic-linker /libexec/ld-elf.so.1 --hash-style=both --enable-new-dtags -m elf_i386_fbsd -o hello-world /usr/lib/crt1.o /usr/lib/crti.o /usr/lib/crtbegin.o -L/usr/lib /home/dim/tmp/hello-world-288694.o -lgcc --as-needed -lgcc_s --no-as-needed -lc -lgcc --as-needed -lgcc_s --no-as-needed /usr/lib/crtend.o /usr/lib/crtn.o -Dimitry Thanks again, -Matthew ___ 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: WiFi 802.11/ac PCIe supported adaptor
On Sun, 19 Oct 2014, O. Hartmann wrote: Am Sun, 28 Sep 2014 14:50:02 -0600 (MDT) Warren Block wbl...@wonkity.com schrieb: On Sun, 28 Sep 2014, Gavin Atkinson wrote: On Sun, 28 Sep 2014, O. Hartmann wrote: Networking wasn't an issue for me for years, but now, sitting on a pile of neat new hardware of which FreeBSD can not make any serious use, let me rethink. Luckily, The Lenovo laptops have a mini PCIe WiFi NIC - if I'm willing to follow FreeBSDs agony I'm able to swap the NIC with a piece of hardware that is supported. But it is additional Unfortunately, many Lenovo laptops lock the BIOS down in such a way that they won't boot without the NIC they were shipped with :( Yes, I realized this very sadly today. Intel 6300 WiFi adapter isn't recognized, the crap of Laptop rejects starting firmware and I get a message telling me using uncertified hardware. Last time I bought a Laptop from Lenovo! Well, or a short list of approved Lenovo-branded cards. In the past, Lenovo (or IBM) has supplied Atheros cards. The trick will be finding that list and identifying the chipsets on each. There are also unofficial BIOS modifications to remove the limits. There are lists, but they are outdated and newer chipsets aren't listed. No, I mean each particular Thinkpad notebook has a list of allowed cards in the BIOS. However, it is not the same list for each model. So the trick is to find the list of approved cards for your particular model, and then figure out which of those is Atheros-based. ___ 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: Compiling Xen on FreeBSD using clang ...
On 10/19/2014 3:03 PM, Marcin Cieslak wrote: On Sun, 19 Oct 2014, Matthew Grooms wrote: [...] I have recently managed to compile Xen (4.5 unstable from git master) using few patches in the source code (I posted them to xen-devel@, most of them are almost the same as some earlier work by Julien Grall). Hi Marcin, I pulled in a few patches that were posted on the xen-devel list to get things to compile. Attached was the subset that I needed to get Xen 4.5 to build with the clang 3.4.1 ( with seabios disabled ). I have used clang version 3.5.0 (trunk) from ports just for the .code16 support, other than that clang 3.4.1 was fine. Do you have a link to your patch set? I sifted through the ones posted by Julien and I probably saw most of yours as well. My goal was to get as much as possible to compile with the existing system compiler so I didn't try 3.5.0. Maybe that's a better bet. Xen kernel compiled this way even boots successfully and starts Debian dom0. I was able to boot a FreeBSD PVH dom0 based on Rogers instructions. Pretty amazing that it all works with a GENERIC kernel. Was mostly focusing on getting the compile clean enough for a port/pkg of the final 4.5 release. [mgrooms@xen2 ~]$ uname -a FreeBSD xen2.shrew.lab 11.0-CURRENT FreeBSD 11.0-CURRENT #0 a50212f(pvh_dom0_v7): Sun Oct 19 09:57:23 CDT 2014 r...@xen2.shrew.lab:/usr/obj/usr/src/sys/GENERIC amd64 [root@xen2 ~]# xl list NameID Mem VCPUs State Time(s) Domain-0 0 1024 2 r- 7.1 This command was used to compile with 3.4.1 (without hvmloader): env CFLAGS=-I/usr/local/include LDFLAGS=-L/usr/local/lib gmake clang=y CC=clang-devel HOSTCC=clang-devel CONFIG_SEABIOS=y CONFIG_HVMLOADER=n SEABIOS_PATH=$HOME/qemu/bios.bin-1.7.5 CONFIG_QEMU=n $@ Thanks for that. I hope the Xen devs can get the yajl and signed int patches committed. Those were the only C level code changes I ran into and would clean up the build significantly for clang users. Tho only other knit was the ... register unsigned long sp asm(rsp); ... assembly but maybe that compiles with 3.5 as well? http://llvm.org/bugs/show_bug.cgi?id=11255 Everything else was build level compiler flag fiddling. -Matthew diff --git a/Config.mk b/Config.mk index 6324237..0cd3553 100644 --- a/Config.mk +++ b/Config.mk @@ -36,10 +36,13 @@ CONFIG_$(XEN_OS) := y SHELL ?= /bin/sh # Tools to run on system hosting the build -HOSTCC = gcc +HOSTCC = cc HOSTCFLAGS = -Wall -Werror -Wstrict-prototypes -O2 -fomit-frame-pointer HOSTCFLAGS += -fno-strict-aliasing +# Clang specific +HOSTCFLAGS += -Wno-ignored-attributes + DISTDIR ?= $(XEN_ROOT)/dist DESTDIR ?= / @@ -54,7 +57,6 @@ else gcc := n endif - include $(XEN_ROOT)/config/$(XEN_OS).mk include $(XEN_ROOT)/config/$(XEN_TARGET_ARCH).mk @@ -193,6 +195,7 @@ CFLAGS += -Wall -Wstrict-prototypes # and is over-zealous with the printf format lint # and is a bit too fierce about unused return values CFLAGS-$(clang) += -Wno-parentheses -Wno-format -Wno-unused-value +CFLAGS-$(clang) += -Wno-ignored-attributes -Qunused-arguments $(call cc-option-add,HOSTCFLAGS,HOSTCC,-Wdeclaration-after-statement) $(call cc-option-add,CFLAGS,CC,-Wdeclaration-after-statement) diff --git a/tools/Rules.mk b/tools/Rules.mk index 87a56dc..ab47f54 100644 --- a/tools/Rules.mk +++ b/tools/Rules.mk @@ -17,6 +17,10 @@ XEN_LIBXENSTAT = $(XEN_ROOT)/tools/xenstat/libxenstat/src XEN_BLKTAP2= $(XEN_ROOT)/tools/blktap2 XEN_LIBVCHAN = $(XEN_ROOT)/tools/libvchan +CFLAGS-$(clang) += -Wno-ignored-attributes -Wno-header-guard +CFLAGS-$(clang) += -no-integrated-as +CFLAGS-$(clang) += -DYAJL_MAJOR=2 + CFLAGS_xeninclude = -I$(XEN_INCLUDE) XENSTORE_XENSTORED ?= y @@ -70,6 +74,10 @@ CFLAGS_libxenlight = -I$(XEN_XENLIGHT) $(CFLAGS_libxenctrl) $(CFLAGS_xeninclude) LDLIBS_libxenlight = $(XEN_XENLIGHT)/libxenlight$(libextension) $(SHLIB_libxenctrl) $(SHLIB_libxenstore) $(SHLIB_libblktapctl) SHLIB_libxenlight = -Wl,-rpath-link=$(XEN_XENLIGHT) +CFLAGS_libxenlight += -I/usr/local/include +CFLAGS_libxenlight += -Wno-format-nonliteral +LDFLAGS_libxenlight += -L/usr/local/lib + CFLAGS += -D__XEN_TOOLS__ # Get gcc to generate the dependencies for us. diff --git a/tools/libxl/Makefile b/tools/libxl/Makefile index df08c8a..a68f15a 100644 --- a/tools/libxl/Makefile +++ b/tools/libxl/Makefile @@ -12,7 +12,7 @@ XLUMAJOR = 4.3 XLUMINOR = 0 CFLAGS += -Werror -Wno-format-zero-length -Wmissing-declarations \ - -Wno-declaration-after-statement -Wformat-nonliteral + -Wno-declaration-after-statement CFLAGS += -I. -fPIC ifeq ($(CONFIG_Linux),y) @@ -25,6 +25,7 @@ ifeq ($(CONFIG_REMUS_NETBUF),y) LIBXL_LIBS += $(LIBNL3_LIBS) endif +CFLAGS_LIBXL = $(CFLAGS_libxenlight) CFLAGS_LIBXL += $(CFLAGS_libxenctrl) CFLAGS_LIBXL += $(CFLAGS_libxenguest) CFLAGS_LIBXL += $(CFLAGS_libxenstore) @@ -37,7
Re: Compiling Xen on FreeBSD using clang ...
On Sun, 19 Oct 2014, Matthew Grooms wrote:
Thanks for that. I hope the Xen devs can get the yajl and signed int patches
committed. Those were the only C level code changes I ran into and would
clean up the build significantly for clang users. Tho only other knit was the
...
register unsigned long sp asm(rsp);
... assembly but maybe that compiles with 3.5 as well?
I am still getting this:
/home/saper/sw/xen/xen/include/asm/current.h:30:33: error: variable
'sp' is uninitialized when used here [-Werror,-Wuninitialized]
return (struct cpu_info *)((sp ~(STACK_SIZE-1)) + STACK_...
^~
/home/saper/sw/xen/xen/include/asm/current.h:28:30: note: initialize
the variable 'sp' to silence this warning
register unsigned long sp asm(rsp);
^
= 0
1 error generated.
Do you have a link to your patch set? I sifted through the ones posted by
Julien and I probably saw most of yours as well. My goal was to get as much
as possible to compile with the existing system compiler so I didn't try
3.5.0. Maybe that's a better bet.
It would be also really good to integrate with qemu from ports
and not compile our own version again.
My patches are attached, hopefully the mailing list
will accept them.
//MarcinFrom a2253431f4df4dc09e8817467996ec6c6fc47614 Mon Sep 17 00:00:00 2001
From: Marcin Cieslak sa...@saper.info
Date: Wed, 24 Sep 2014 12:00:54 +
Subject: [PATCH 10/10] No QEMU for now
---
tools/Makefile | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/tools/Makefile b/tools/Makefile
index b6476c9..833b8fa 100644
--- a/tools/Makefile
+++ b/tools/Makefile
@@ -24,8 +24,8 @@ SUBDIRS-$(CONFIG_Linux) += libvchan
# do not recurse in to a dir we are about to delete
ifneq $(MAKECMDGOALS) distclean
-SUBDIRS-$(CONFIG_QEMU_TRAD) += qemu-xen-traditional-dir
-SUBDIRS-$(CONFIG_QEMU_XEN) += qemu-xen-dir
+# SUBDIRS-$(CONFIG_QEMU_TRAD) += qemu-xen-traditional-dir
+# SUBDIRS-$(CONFIG_QEMU_XEN) += qemu-xen-dir
endif
SUBDIRS-y += xenpmd
--
2.0.2
From e37a8a1070b77c44f66507d5f49e332787325609 Mon Sep 17 00:00:00 2001
From: Marcin Cieslak sa...@saper.info
Date: Wed, 24 Sep 2014 12:49:17 +
Subject: [PATCH 09/10] Add -Wno-initializer-overrides for clang
Signed-off-by: Marcin Cieslak sa...@saper.info
---
Config.mk | 1 +
1 file changed, 1 insertion(+)
diff --git a/Config.mk b/Config.mk
index 015b90b..aa0ca73 100644
--- a/Config.mk
+++ b/Config.mk
@@ -194,6 +194,7 @@ CFLAGS += -Wall -Wstrict-prototypes
# and is over-zealous with the printf format lint
# and is a bit too fierce about unused return values
CFLAGS-$(clang) += -Wno-parentheses -Wno-format -Wno-unused-value
+CFLAGS-$(clang) += -Wno-initializer-overrides
$(call cc-option-add,HOSTCFLAGS,HOSTCC,-Wdeclaration-after-statement)
$(call cc-option-add,CFLAGS,CC,-Wdeclaration-after-statement)
--
2.0.2
From c84cc99dcf9365b713031f0135c56b477df5824b Mon Sep 17 00:00:00 2001
From: Marcin Cieslak sa...@saper.info
Date: Wed, 24 Sep 2014 12:06:25 +
Subject: [PATCH 08/10] variable 'rc' is used uninitialized whenever 'if'
condition is false
Signed-off-by: Marcin Cieslak sa...@saper.info
---
tools/libxl/libxl_dom.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/tools/libxl/libxl_dom.c b/tools/libxl/libxl_dom.c
index ce0c4ac..d98838a 100644
--- a/tools/libxl/libxl_dom.c
+++ b/tools/libxl/libxl_dom.c
@@ -2020,7 +2020,7 @@ int libxl_userdata_unlink(libxl_ctx *ctx, uint32_t domid,
const char *userdata_userid)
{
GC_INIT(ctx);
-int rc;
+int rc = 0;
libxl__domain_userdata_lock *lock;
const char *filename;
--
2.0.2
From c468fd7e6228f2820ef8f4ede7432313354730f0 Mon Sep 17 00:00:00 2001
From: Marcin Cieslak sa...@saper.info
Date: Sat, 13 Sep 2014 18:35:52 +
Subject: [PATCH 07/10] clang: sizeof(type) must not have
__attribute__(aligned)
Signed-off-by: Marcin Cieslak sa...@saper.info
---
tools/include/xen-foreign/mkheader.py | 41 ++-
1 file changed, 26 insertions(+), 15 deletions(-)
diff --git a/tools/include/xen-foreign/mkheader.py
b/tools/include/xen-foreign/mkheader.py
index 0504cb8..80a8404 100644
--- a/tools/include/xen-foreign/mkheader.py
+++ b/tools/include/xen-foreign/mkheader.py
@@ -16,13 +16,23 @@ inttypes = {};
header = {};
footer = {};
+def convertint(arch, t, aligned=False):
+ nt = inttypes[arch][t]
+ attr =
+ if type(nt) is type(()):
+ (attr, nt) = nt
+ if not aligned:
+ attr =
+ print sys.stderr, %s(%d) - %s %s % (t, aligned, attr, nt)
+ return %s %s % (nt, attr) # Order is important due to re.sub done
twice
+
#arm
inttypes[arm32] = {
unsigned long : __danger_unsigned_long_on_arm32,
long : __danger_long_on_arm32,
-xen_pfn_t : __align8__ uint64_t,
-xen_ulong_t : __align8__ uint64_t,
-uint64_t :
Re: Voxer using FreeBSD, BSDNow.tv interview
On 2014-10-19 18:09, Craig Rodrigues wrote: Hi, If you don't watch BSDNow.tv ( http://bsdnow.tv ), I encourage you to do so. Allan Jude and Kris Moore do a great job of doing a weekly video podcast of news in the BSD world. It is great stuff. In episode 58 ( http://www.bsdnow.tv/episodes/2014_10_08-behind_the_masq ) BSDNow interviewed the CTO of Voxer ( http://voxer.com ), a mobile messaging startup based in San Francisco. Voxer mentioned how they transitioned from SmartOS (an Illumos/Solaris distribution) to FreeBSD. What Voxer liked: (1) DTrace worked for their node.js apps (2) ZFS worked nicely (3) jails work nicely (4) Easy to transition away from SmartOS/Illumos because of (1) and (2) (5) Better support for 3rd party applications (ports) than SmartOS/Illumos (6) Better hardware support than SmartOS/Illumos (7) Good documentation, professional/technical discussions on mailing lists (8) For people who use MacOS X, the FreeBSD command-line utilities were familiar What Voxer didn't like: Voxer was super positive about FreeBSD in the interview, and didn't really mention many downsides to their transition. The only things I could pick up on: (1) Support for FreeBSD in Chef was not as good as they would have liked. They actually have patches to Chef for FreeBSD which they want to upstream. (2) Most devops engineers in web/mobile companies are familiar with Linux. Any differences between Linux and FreeBSD in command-line utilities are not show-stoppers, but they are annoyances. Anything FreeBSD could do to help people used to Linux would be a big help. Allan Jude even brought up my request to symlink /bin/bash ( https://lists.freebsd.org/pipermail/freebsd-ports/2014-September/095483.html ) :) The interview was really good, and I encourage everyone to watch it. It's nice to see a modern web/mobile company migrating *to* FreeBSD. -- Craig ___ 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 They said one of the biggest draws for them are TRIM support for ZFS on SSDs, which IllumOS does not have. Although I think that is something that Linux has now. If anyone else knows of companies like this, that can tell us why they use FreeBSD, what they'd like FreeBSD to do better, etc, we'd love to feature them on the show. It is important to foster the communications between end users and developers so that the itches get scratched. -- Allan Jude signature.asc Description: OpenPGP digital signature
libxml2 upgrade breaks building /usr/doc/ on current amd64
The upgrade of libxml2 broke building /usr/doc/ : (en_US.ISO8859-1)5056}make === articles (all) === articles/bsdl-gpl (all) install /usr/doc/share/xml/catalog-cwd.xml /usr/doc/en_US.ISO8859-1/articles/bsdl-gpl/catalog-cwd.xml echo '!ENTITY base ..' /usr/doc/en_US.ISO8859-1/articles/bsdl-gpl/autogen.ent env XML_CATALOG_FILES=file:///usr/doc/en_US.ISO8859-1/articles/bsdl-gpl/catalog-cwd.xml file:///usr/doc/en_US.ISO8859-1/share/xml/catalog.xml file:///usr/doc/share/xml/catalog.xml file:///usr/doc/share/xml/catalog-common.xml file:///usr/local/share/xml/catalog /usr/local/bin/xmllint --nonet --noent --valid --dropdtd --xinclude /usr/doc/en_US.ISO8859-1/articles/bsdl-gpl/article.xml article.parsed.xml.tmp file:/usr/doc/share/xml/freebsd50.dtd:12: warning: failed to load external entity http://www.FreeBSD.org/XML/share/xml/iso8879.ent; %iso8879.ent; ^ Entity: line 1: %iso8879.ent; ^ Entity: line 5: parser error : Entity 'trade' not defined designations have been followed by the quotetrade;/quote or the ^ Entity: line 6: parser error : Entity 'reg' not defined quotereg;/quote symbol./para ^ Entity: line 6: parser error : chunk is not well balanced quotereg;/quote symbol./para ^ /usr/doc/en_US.ISO8859-1/articles/bsdl-gpl/article.xml:18: parser error : Entity 'tm-attrib.general' failed to parse tm-attrib.general; ^ *** Error code 1 Stop. make[2]: stopped in /usr/doc/en_US.ISO8859-1/articles/bsdl-gpl *** Error code 1 Stop. make[1]: stopped in /usr/doc/en_US.ISO8859-1/articles *** Error code 1 Stop. make: stopped in /usr/doc/en_US.ISO8859-1 If I revert to the previous version -- no problem: Writing keeping-up.html for chapter(keeping-up) Writing uses.html for chapter(uses) Writing versions.html for chapter(versions) Writing index.html for book Writing HTML.manifest (en_US.ISO8859-1)5059} Not sure where the problem is. || n...@pozo.com || || || -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. ___ 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: kernel page fault with nfs
Hello Tobias, Could you show how you are mount the NFS share? Are you using 'readahead' option? Best Regards, 2014-10-19 17:40 GMT+08:00 Tobias C. Berner tcber...@gmail.com: both are at 1100038. On Sunday 19 October 2014 11.12:36 Marcelo Araujo wrote: It is still strange, could you do what Allan said and send us the result in case you are not sure you have world and kernel in the same revision! On Oct 19, 2014 6:48 AM, Tobias C. Berner tcber...@gmail.com wrote: Hi World ist from october 16, installed world and kernel then. Kernel was later rebuilt with debug-options. Is the following more sensible? ## # kgdb NOXON/kernel.debug vmcore.1 Fatal trap 12: page fault while in kernel mode cpuid = 5; apic id = 05 fault virtual address = 0xfe07d1744000 fault code = supervisor write data, page not present instruction pointer = 0x20:0x80d4d58a stack pointer = 0x28:0xfe086057f240 frame pointer = 0x28:0xfe086057f2f0 code segment = base 0x0, limit 0xf, type 0x1b = DPL 0, pres 1, long 1, def32 0, gran 1 processor eflags = interrupt enabled, resume, IOPL = 0 current process = 6524 (python2.7) (kgdb) bt #0 doadump (textdump=1) at pcpu.h:219 #1 0x80926b6d in kern_reboot (howto=260) at /usr/src/sys/kern/kern_shutdown.c:447 #2 0x809270c0 in panic (fmt=value optimized out) at /usr/src/sys/kern/kern_shutdown.c:746 #3 0x8035f167 in db_panic (addr=value optimized out, have_addr=2, count=0, modif=0x0) at /usr/src/sys/ddb/db_command.c:473 #4 0x8035ed7d in db_command (cmd_table=0x0) at /usr/src/sys/ddb/db_command.c:440 #5 0x8035eaf4 in db_command_loop () at /usr/src/sys/ddb/db_command.c:493 #6 0x80361600 in db_trap (type=value optimized out, code=0) at /usr/src/sys/ddb/db_main.c:251 #7 0x80966f01 in kdb_trap (type=12, code=0, tf=value optimized out) at /usr/src/sys/kern/subr_kdb.c:654 #8 0x80d4fa7c in trap_fatal (frame=0xfe086057f190, eva=value optimized out) at /usr/src/sys/amd64/amd64/trap.c:861 #9 0x80d4fe0c in trap_pfault (frame=0xfe086057f190, usermode=value optimized out) at /usr/src/sys/amd64/amd64/trap.c:677 #10 0x80d4f42e in trap (frame=0xfe086057f190) at /usr/src/sys/amd64/amd64/trap.c:426 #11 0x80d33972 in calltrap () at /usr/src/sys/amd64/amd64/exception.S:231 #12 0x80d4d58a in bzero () at /usr/src/sys/amd64/amd64/support.S:53 #13 0x80830463 in ncl_doio (vp=0xf801e7f99938, bp=0xfe07c5a168e8, cr=value optimized out, td=value optimized out, called_from_strategy=value optimized out) at /usr/src/sys/fs/nfsclient/nfs_clbio.c:1648 #14 0x80831acf in ncl_write (ap=value optimized out) at /usr/src/sys/fs/nfsclient/nfs_clbio.c:1124 #15 0x80e646a5 in VOP_WRITE_APV (vop=value optimized out, a=value optimized out) at vnode_if.c:997 #16 0x809f52f9 in vn_write (fp=0xf80101c62780, uio=0xfe086057f970, active_cred=value optimized out, flags=320, td=0x0) at vnode_if.h:413 #17 0x809f5602 in vn_io_fault_doio (args=value optimized out, uio=0xa00, td=0x0) at /usr/src/sys/kern/vfs_vnops.c:991 #18 0x809f2aec in vn_io_fault1 () at /usr/src/sys/kern/vfs_vnops.c:1047 #19 0x809f0e3b in vn_io_fault (fp=0xf80101c62780, uio=0xfe086057f970, active_cred=value optimized out, flags=0, td=0xf80171d79920) at /usr/src/sys/kern/vfs_vnops.c:1152 #20 0x80982357 in dofilewrite (td=0xf80171d79920, fd=19, fp=0xf80101c62780, auio=0xfe086057f970, offset=value optimized out, flags=0) at file.h:306 #21 0x80982088 in kern_writev (td=0xf80171d79920, fd=19, auio=0xfe086057f970) at /usr/src/sys/kern/sys_generic.c:467 #22 0x80982013 in sys_write (td=value optimized out, uap=value optimized out) at /usr/src/sys/kern/sys_generic.c:382 #23 0x80d5051b in amd64_syscall (td=0xf80171d79920, traced=0) at subr_syscall.c:133 #24 0x80d33c5b in Xfast_syscall () at /usr/src/sys/amd64/amd64/exception.S:390 #25 0x00080137de4a in ?? () ## Thanks in advance, Tobias Berner On Saturday 18 October 2014 20.43:12 Marcelo Araujo wrote: When you rebuild your system, did you rebuild and install all kernel and world? Best Regards, On Oct 18, 2014 7:57 PM, John Baldwin j...@freebsd.org wrote: On Friday, October 17, 2014 11:11:26 PM Tobias C. Berner wrote: Hi For some days now I've had problems with my
projects/ipfw: Consider using tcp/31982 in firewall_myservices.
Having simply a number (the port) in rc.conf: firewall_myservices defined, I receive during startup the message Consider using tcp/31982 in firewall_myservices. Doing so, ends up in a misconfiguration, because the rc.firewall script in /etc/ is looking for 31982/tcp instead of the recommended tcp/31982. This is a typo. oh signature.asc Description: PGP signature
Re: projects/ipfw: Consider using tcp/31982 in firewall_myservices.
O. Hartmann ohart...@zedat.fu-berlin.de wrote in 20141020052804.7a5e1d50.ohart...@zedat.fu-berlin.de: oh Having simply a number (the port) in rc.conf: firewall_myservices defined, I receive oh during startup the message oh oh Consider using tcp/31982 in firewall_myservices. oh oh Doing so, ends up in a misconfiguration, because the rc.firewall script in /etc/ is oh looking for 31982/tcp instead of the recommended tcp/31982. oh oh This is a typo. Oh, sorry. Fixed in r273301. -- Hiroki pgpJuRzh_Cx4Q.pgp Description: PGP signature
