Free Trial for CV Sourcing
Hello Team, Hope you are doing well. We at Sapphire take pleasure in introducing ourselves as the Leading in RPO industry and have served many Consulting, Staffing Executive Search Firms. Our main contribution to all the clients is to generate the best candidates and submit them with a predefined TAT (Turn around Time) with a time advantage. Our expertise lies in sourcing candidates from various job portals, search engines and create an impressive online advert campaign with remote staffing methods. We have just the service for you that will solve all your sourcing and recruitment hitches, in half the time, at competitive prices. Why Sapphire: . 100% cost reduction on Job Boards . No worries about infrastructure and in house facility . Create a passive database, which is a gold mine online . No placement fees, no benefit costs, . On the desk results daily . Time utilization for new business Services offering for Search firms / corporate clients: . Active CV Sourcing . Core Passive CV Sourcing . CV Formatting . CV Database/ ATS Management . Data Cleansing . Vacancy Monitoring . Internet Sourcing / Googling / Online Research / LinkedIn Sourcing Our E - Recruiters are all trained and highly experienced in Active, passive candidate search through networking sites like; LinkedIn Facebook, Twitter, Spoke etc. In order to present our services we would like to offer you a one day Non Obligatory Free Trial for our CV Sourcing services Our business development team will be happy to speak with you and discuss the best solution for you. Please do contact us to set up a day and time, or for any further information you may need. Thanks Regards, Sales Team Sapphire Information Systems Pvt. Ltd. http://www.google.com/url?q=http%3A%2F%2Fwww.sapphireinfosystems.comsa=Ds ntz=1usg=AFQjCNFoVZb6rvk0VNjsSGZZZOwEEEIs0w http://www.sapphireinfosystems.com Mobile (India): tel:%2B91-9503128620 +91-9503128620 USA Tel No. tel:%2B1-7163357818 +1-7163357818 ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
runtime linker on 9.x/i386: clang vs. gcc
Hello! I'm seeing a strange problem with clang-compiled binaries on 9.x/i386 system. Here it is: if a shared library A needs a symbol provided by a shared library B, libA will fail to load into a process even if the executable is linked with libB. The only fix (work-around?) is to relink libA to explicitly depend on libB. A temporary work-around is to use LD_PRELOAD to list all of the necessary libBs... One example of this is reported in ports/180473 http://www.freebsd.org/cgi/query-pr.cgi?pr=ports/180473 -- the libprldap6.so refuses to load because of the symbols it needs from libnspr4.so. For some reason, the fact, that -lnspr4 is linked into the executable (seamonkey or thunderbird), is not sufficient... As the ticket suggests, using gcc46 (Mozilla rejects gcc-4.2.x nowadays) instead of clang solves the problem (though an even better solution is in place since this weekend). Another example is xorg-server, which, for me, can not load some of the drivers because they complain of missing symbols: (EE) Failed to load /opt/lib/xorg/modules/drivers/vboxvideo_drv.so: /opt/lib/xorg/modules/drivers/vboxvideo_drv.so: Undefined symbol DRIFinishScreenInit The DRIFinishScreenInit is provided by libdri.so, which the server also loads... But, somehow, that is not sufficient. Rebuilding vboxvideo_drv.so (provided by emulators/virtualbox-ose-additions http://www.freshports.org/emulators/virtualbox-ose-additions) with the stock cc (gcc-4.2.1) resolves the linking problem -- even if Xorg executable and the libdri.so remain clang-compiled. I am not prepared to argue, whether that's a right or wrong behavior -- but it certainly is inconsistent, because it is only manifested on i386 and only when the compiler is clang. Any thoughts? -mi ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
FreeBSD 10.0-BETA1 now available
The first BETA build of the 10.0-RELEASE release cycle is now available on the FTP servers for the amd64, i386, ia64, powerpc, powerpc64 and sparc64 architectures. The image checksums follow at the end of this email. ISO images and, for architectures that support it, the memory stick images are available here: ftp://ftp.freebsd.org/pub/FreeBSD/releases/ISO-IMAGES/10.0/ (or any of the FreeBSD mirror sites). If you notice problems you can report them through the normal GNATS PR system or here on the -current mailing list. If you would like to use SVN to do a source based update of an existing system, use the stable/10 branch. Important note to freebsd-update(8) users: Due to a last minute problem found in the 10.0-BETA1 freebsd-update(8) builds, freebsd-update(8) is NOT supported for 10.0-BETA1 upgrades. Please do not use freebsd-update(8) to upgrade to 10.0-BETA1. Please be aware that cvsup and CVS are not supported methods of updating the src/ tree. Also note, due to the size of the images, the ports.txz distribution is not included in 10.0-BETA1, however is expected to be included with disc1.iso for subsequent builds during the release cycle. The ports tree can be fetched either with the portsnap(8) utility, or using svnlite using any of the mirrors listed here: http://www.freebsd.org/doc/en/books/handbook/svn-mirrors.html Changes between -ALPHA5 and -BETA1 include: o Introduce freebsd-version(1), which is intended to be used as an auditing tool, to determine the userland patch level when it differs from what 'uname -r' reports. o Improve ZFS lzjb decompress performance. o Add two new MIPS CPU families - mips24k and mips74k. o The jail_jname_* rc.conf(5) variables for per-jail configuration are automatically converted to /var/run/jail.jname.conf before the jail(8) utility is invoked, so the new jail.conf(5) syntax is used. o Remove most of the ATF tools and the _atf user. o Updates to random(4). Please note the following: - In 10.0-BETA1, it is not possible for random(4) to be loaded as a kernel module via kldload(8). If not using GENERIC, and the system kernel configuration excludes 'device random', please include random(4) in the kernel configuration file. The fix for this issue is pending review, and is expected to be fixed in 10.0-BETA2. o Updates to bsdinstall(8). Please note the following: - 10.0-BETA1 introduces a number of updates to bsdinstall(8), notably the ability to install to a full ZFS filesystem. Please keep in mind that this is an experimental feature. - If using the ZFS installation option in *and* have enabled full-disk encryption is enabled, a few entries will need to be manually added to loader.conf(5) before the 'bootpool' zpool will be available after the system boots. This manual step is expected to be fixed in 10.0-BETA2. The entries that need to be added are: zpool_cache_load=YES zpool_cache_type=/boot/zfs/zpool.cache zpool_cache_name=/boot/zfs/zpool.cache This can be done at the final menu of bsdinstall(8), when prompted to boot into the newly-installed system; alternatively, this can be done post-install, in which case, the following must be run before appending loader.conf(5): # zpool import -f bootpool Pre-installed virtual machine images for 10.0-BETA1 are also available for amd64 and i386 architectures. The images are located under the 'snapshots' directory on FTP, here: ftp://ftp.freebsd.org/pub/FreeBSD/snapshots/VM-IMAGES/20131012/10.0-BETA1/ The disk images are available in both QCOW2 and VMDK format. The image download size is approximately 136 MB, which decompress to a 20GB sparse image. The partition layout is: - 512k - freebsd-boot GPT partition type (bootfs GPT label) - 1GB - freebsd-swap GPT partition type (swapfs GPT label) - ~17GB - freebsd-ufs GPT partition type (rootfs GPT label) ISO Checksums: amd64 SHA256 (FreeBSD-10.0-BETA1-amd64-bootonly.iso) = d3c28a2b972fb38f6b2981729d72b50fcbb5ca07835e9d4e3cfa014e27527631 SHA256 (FreeBSD-10.0-BETA1-amd64-disc1.iso) = 226b88265e11accd4a873d5fa49e4eaf87f22c00a6580c23879bd18cdb6077b3 SHA256 (FreeBSD-10.0-BETA1-amd64-memstick.img) = 1ff5f2e25a212a213873e8670b88cbbf88e55105844ad44e425f73a99ebfd795 MD5 (FreeBSD-10.0-BETA1-amd64-bootonly.iso) = 13879ecb4dd06a8931c5373db61af4bc MD5 (FreeBSD-10.0-BETA1-amd64-disc1.iso) = 4a6ba36de48ac51a5f1c060b328e01c4 MD5 (FreeBSD-10.0-BETA1-amd64-memstick.img) = 85a2ae840db8b7cf59a002f4bc014d38 i386 SHA256 (FreeBSD-10.0-BETA1-i386-bootonly.iso) = 07c53db7588db0bf350bf374fe11b1973908ddf875cf110a306fb524760385d8 SHA256 (FreeBSD-10.0-BETA1-i386-disc1.iso) =
nvidia-driver problem after upgrade
As the subject says, I finally found the way to upgrade to 9.2 and recent packages using pkg. Now I lost graphics, since nvidia driver fails to handle screen. If I remove xorg.conf, x starts up, but I have no input device available. It is nvidia 520, tried both 319.32 and 304.88 drivers. Error: Failed to initialize the NVIDIA kernel module Failing initialization of X screen 0 Fatal server error: no screens found Anya idea? I made a custom kernel, without 32 bit support and no linux, which might be a problem. I see nvidia.ko in modules directory. Best regards Zoran ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: runtime linker on 9.x/i386: clang vs. gcc
On Oct 14, 2013, at 18:22, Mikhail T. mi+t...@aldan.algebra.com wrote: I'm seeing a strange problem with clang-compiled binaries on 9.x/i386 system. Here it is: if a shared library A needs a symbol provided by a shared library B, libA will fail to load into a process even if the executable is linked with libB. The only fix (work-around?) is to relink libA to explicitly depend on libB. A temporary work-around is to use LD_PRELOAD to list all of the necessary libBs... One example of this is reported in ports/180473 http://www.freebsd.org/cgi/query-pr.cgi?pr=ports/180473 -- the libprldap6.so refuses to load because of the symbols it needs from libnspr4.so. For some reason, the fact, that -lnspr4 is linked into the executable (seamonkey or thunderbird), is not sufficient... As the ticket suggests, using gcc46 (Mozilla rejects gcc-4.2.x nowadays) instead of clang solves the problem (though an even better solution is in place since this weekend). Another example is xorg-server, which, for me, can not load some of the drivers because they complain of missing symbols: (EE) Failed to load /opt/lib/xorg/modules/drivers/vboxvideo_drv.so: /opt/lib/xorg/modules/drivers/vboxvideo_drv.so: Undefined symbol DRIFinishScreenInit The DRIFinishScreenInit is provided by libdri.so, which the server also loads... But, somehow, that is not sufficient. Rebuilding vboxvideo_drv.so (provided by emulators/virtualbox-ose-additions http://www.freshports.org/emulators/virtualbox-ose-additions) with the stock cc (gcc-4.2.1) resolves the linking problem -- even if Xorg executable and the libdri.so remain clang-compiled. I am not prepared to argue, whether that's a right or wrong behavior -- but it certainly is inconsistent, because it is only manifested on i386 and only when the compiler is clang. Any thoughts? There are many possibilities here, and you might be running into multiple different problems, but the X.org failures look familiar to me. There is a problem when clang does tail-call optimization on i386 with PIC in effect, and it emits GOT relocations for the tail-called functions, instead of PLT relocations. In some scenarios, such as with the way X.org does lazy dynamic linking, this can cause problems. See also http://llvm.org/PR15086 (which I unfortunately did not get much response on). For now, a workaround is to recompile the affected .so files with -fno-optimize-sibling-calls (if you are optimizing). This is also the approach taken for the X.org ports, see http://svnweb.freebsd.org/ports?view=revisionrevision=312583 for the diff. -Dimitry signature.asc Description: Message signed with OpenPGP using GPGMail
Re: runtime linker on 9.x/i386: clang vs. gcc
10/14/13 4:31 PM, Dimitry Andric ???(??): There is a problem when clang does tail-call optimization on i386 with PIC in effect, and it emits GOT relocations for the tail-called functions, instead of PLT relocations. In some scenarios, such as with the way X.org does lazy dynamic linking, this can cause problems. See alsohttp://llvm.org/PR15086 (which I unfortunately did not get much response on). Ouch... That seems like a show-stopper for clang-adoption... At least, on i386. For now, a workaround is to recompile the affected .so files with -fno-optimize-sibling-calls (if you are optimizing). Maybe, our clang (both src/ and ports/) should be compiled with that being in effect by default on i386? -mi ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: runtime linker on 9.x/i386: clang vs. gcc
On Oct 14, 2013, at 22:42, Mikhail T. mi+t...@aldan.algebra.com wrote: 10/14/13 4:31 PM, Dimitry Andric написав(ла): There is a problem when clang does tail-call optimization on i386 with PIC in effect, and it emits GOT relocations for the tail-called functions, instead of PLT relocations. In some scenarios, such as with the way X.org does lazy dynamic linking, this can cause problems. See also http://llvm.org/PR15086 (which I unfortunately did not get much response on). Ouch... That seems like a show-stopper for clang-adoption... At least, on i386. Well, the scenario is very difficult to reproduce, at least when I tried it. You must have a very specific way of dynamically loading objects, and you must load them in the wrong order, or the problem will not occur. Normally linked .so's do not have this problem at all. So hardly a showstopper, 10.0 is being released with clang as we speak. :-) For now, a workaround is to recompile the affected .so files with -fno-optimize-sibling-calls (if you are optimizing). Maybe, our clang (both src/ and ports/) should be compiled with that being in effect by default on i386? For the specific cases where it occurs (as far as I knew until know, only certain X.org drivers) it might be enough to just use -fno-optimize-sibling-calls. If this problem occurs more often, I will see if I can make it the default for i386-with-PIC. -Dimitry signature.asc Description: Message signed with OpenPGP using GPGMail
[releng_10 tinderbox] failure on armv6/arm
TB --- 2013-10-14 19:40:42 - tinderbox 2.20 running on worker01.tb.des.no TB --- 2013-10-14 19:40:42 - FreeBSD worker01.tb.des.no 9.1-RELEASE-p4 FreeBSD 9.1-RELEASE-p4 #0: Mon Jun 17 11:42:37 UTC 2013 r...@amd64-builder.daemonology.net:/usr/obj/usr/src/sys/GENERIC amd64 TB --- 2013-10-14 19:40:42 - starting RELENG_10 tinderbox run for armv6/arm TB --- 2013-10-14 19:40:42 - cleaning the object tree TB --- 2013-10-14 19:40:42 - /usr/local/bin/svn stat /src TB --- 2013-10-14 19:41:32 - At svn revision 256450 TB --- 2013-10-14 19:41:33 - building world TB --- 2013-10-14 19:41:33 - CROSS_BUILD_TESTING=YES TB --- 2013-10-14 19:41:33 - MAKEOBJDIRPREFIX=/obj TB --- 2013-10-14 19:41:33 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-10-14 19:41:33 - SRCCONF=/dev/null TB --- 2013-10-14 19:41:33 - TARGET=arm TB --- 2013-10-14 19:41:33 - TARGET_ARCH=armv6 TB --- 2013-10-14 19:41:33 - TZ=UTC TB --- 2013-10-14 19:41:33 - __MAKE_CONF=/dev/null TB --- 2013-10-14 19:41:33 - cd /src TB --- 2013-10-14 19:41:33 - /usr/bin/make -B buildworld Building an up-to-date make(1) World build started on Mon Oct 14 19:41:44 UTC 2013 Rebuilding the temporary build tree stage 1.1: legacy release compatibility shims stage 1.2: bootstrap tools stage 2.1: cleaning up the object tree stage 2.2: rebuilding the object tree stage 2.3: build tools stage 3: cross tools [...] c++ -O2 -pipe -I/src/lib/clang/libllvmselectiondag/../../../contrib/llvm/include -I/src/lib/clang/libllvmselectiondag/../../../contrib/llvm/tools/clang/include -I/src/lib/clang/libllvmselectiondag/../../../contrib/llvm/lib/CodeGen/SelectionDAG -I. -I/src/lib/clang/libllvmselectiondag/../../../contrib/llvm/../../lib/clang/include -DLLVM_ON_UNIX -DLLVM_ON_FREEBSD -D__STDC_LIMIT_MACROS -D__STDC_CONSTANT_MACROS -DNDEBUG -fno-strict-aliasing -DLLVM_DEFAULT_TARGET_TRIPLE=\armv6-gnueabi-freebsd10.0\ -DLLVM_HOST_TRIPLE=\x86_64-unknown-freebsd10.0\ -DDEFAULT_SYSROOT=\/obj/arm.armv6/src/tmp\ -I/obj/arm.armv6/src/tmp/legacy/usr/include -fno-exceptions -fno-rtti -c /src/lib/clang/libllvmselectiondag/../../../contrib/llvm/lib/CodeGen/SelectionDAG/SelectionDAGBuilder.cpp -o SelectionDAGBuilder.o c++ -O2 -pipe -I/src/lib/clang/libllvmselectiondag/../../../contrib/llvm/include -I/src/lib/clang/libllvmselectiondag/../../../contrib/llvm/tools/clang/include -I/src/lib/clang/libllvmselectiondag/../../../contrib/llvm/lib/CodeGen/SelectionDAG -I. -I/src/lib/clang/libllvmselectiondag/../../../contrib/llvm/../../lib/clang/include -DLLVM_ON_UNIX -DLLVM_ON_FREEBSD -D__STDC_LIMIT_MACROS -D__STDC_CONSTANT_MACROS -DNDEBUG -fno-strict-aliasing -DLLVM_DEFAULT_TARGET_TRIPLE=\armv6-gnueabi-freebsd10.0\ -DLLVM_HOST_TRIPLE=\x86_64-unknown-freebsd10.0\ -DDEFAULT_SYSROOT=\/obj/arm.armv6/src/tmp\ -I/obj/arm.armv6/src/tmp/legacy/usr/include -fno-exceptions -fno-rtti -c /src/lib/clang/libllvmselectiondag/../../../contrib/llvm/lib/CodeGen/SelectionDAG/SelectionDAGDumper.cpp -o SelectionDAGDumper.o c++ -O2 -pipe -I/src/lib/clang/libllvmselectiondag/../../../contrib/llvm/include -I/src/lib/clang/libllvmselectiondag/../../../contrib/llvm/tools/clang/include -I/src/lib/clang/libllvmselectiondag/../../../contrib/llvm/lib/CodeGen/SelectionDAG -I. -I/src/lib/clang/libllvmselectiondag/../../../contrib/llvm/../../lib/clang/include -DLLVM_ON_UNIX -DLLVM_ON_FREEBSD -D__STDC_LIMIT_MACROS -D__STDC_CONSTANT_MACROS -DNDEBUG -fno-strict-aliasing -DLLVM_DEFAULT_TARGET_TRIPLE=\armv6-gnueabi-freebsd10.0\ -DLLVM_HOST_TRIPLE=\x86_64-unknown-freebsd10.0\ -DDEFAULT_SYSROOT=\/obj/arm.armv6/src/tmp\ -I/obj/arm.armv6/src/tmp/legacy/usr/include -fno-exceptions -fno-rtti -c /src/lib/clang/libllvmselectiondag/../../../contrib/llvm/lib/CodeGen/SelectionDAG/SelectionDAGISel.cpp -o SelectionDAGISel.o /src/lib/clang/libllvmselectiondag/../../../contrib/llvm/lib/CodeGen/SelectionDAG/SelectionDAGISel.cpp: In member function 'llvm::SDNode* llvm::SelectionDAGISel::SelectCodeCommon(llvm::SDNode*, const unsigned char*, unsigned int)': /src/lib/clang/libllvmselectiondag/../../../contrib/llvm/lib/CodeGen/SelectionDAG/SelectionDAGISel.cpp:2142: internal compiler error: in var_ann, at tree-flow-inline.h:127 Please submit a full bug report, with preprocessed source if appropriate. See URL:http://gcc.gnu.org/bugs.html for instructions. *** Error code 1 Stop. bmake[3]: stopped in /src/lib/clang/libllvmselectiondag *** Error code 1 Stop. bmake[2]: stopped in /src/lib/clang *** Error code 1 Stop. bmake[1]: stopped in /src *** Error code 1 Stop. bmake: stopped in /src *** [buildworld] Error code 1 Stop in /src. TB --- 2013-10-14 20:53:53 - WARNING: /usr/bin/make returned exit code 1 TB --- 2013-10-14 20:53:53 - ERROR: failed to build world TB --- 2013-10-14 20:53:53 - 3614.84 user 789.60 system 4390.95 real http://tinderbox.des.no/tinderbox-freebsd10-build-RELENG_10-armv6-arm.full ___ freebsd-stable@freebsd.org mailing list
How to unstick ZFS resilver?
I have a large (88-drive) zpool in which a drive was recently
replaced. (The pool has a bunch of duff Toshiba MK2001TRKB drives --
never ever pay money for these! -- and I'm trying to replace them one
by one before they fail completely.) The resilver on the first drive
replacement has been taking much much too long, and currently it's
stuck in this state:
pool: export
state: DEGRADED
status: One or more devices is currently being resilvered. The pool will
continue to function, possibly in a degraded state.
action: Wait for the resilver to complete.
scan: resilver in progress since Wed Oct 9 14:54:47 2013
86.5T scanned out of 86.8T at 1/s, (scan is slow, no estimated time)
982G resilvered, 99.62% done
The overall progress hasn't changed in twelve hours, even across a
reboot, and the server is fairly lightly loaded. Searching the Web is
no help; can anyone suggest a remedial action? (This is on
9.1-RELEASE, with our local patches, and all the drives are SAS.)
In exchange, I offer the following DTrace script which I used to
identify the slow SAS drives:
#!/usr/sbin/dtrace -s
#pragma D option quiet
#pragma D option dynvarsize=2m
inline int TOO_SLOW = 1;/* 100 ms */
dtrace:::BEGIN
{
printf(Tracing... Hit Ctrl-C to end.\n);
}
fbt::dastrategy:entry
{
start_time[(struct buf *)arg0] = timestamp;
}
fbt::dadone:entry
/(this-bp = (struct buf *)args[1]-ccb_h.periph_priv.entries[1].ptr)
start_time[this-bp] (timestamp - start_time[this-bp]) TOO_SLOW/
{
@[strjoin(da, lltostr(args[0]-unit_number))] = count();
start_time[this-bp] = 0;
}
-GAWollman
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
