Jenkins build is back to normal : FreeBSD_HEAD-tests2 #905
See https://jenkins.freebsd.org/job/FreeBSD_HEAD-tests2/905/ ___ 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: Panic on current amd64
On Sat, Mar 28, 2015 at 3:02 PM, Manfred Antar n...@pozo.com wrote: I get the following panic on current svn ver r280793: Revert to r280784. This should fix. ___ 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
Panic on current amd64
I get the following panic on current svn ver r280793: Sat Mar 28 14:41:28 PDT 2015 FreeBSD/amd64 (pozo.com) (ttyu0) login: panic: Invalid CPU in callout 16 cpuid = 2 KDB: stack backtrace: db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame 0xfe023705f370 panic() at panic+0x1c1/frame 0xfe023705f430 callout_reset_sbt_on() at callout_reset_sbt_on+0x3cc/frame 0xfe023705f4b0 nv_start_rc_timer() at nv_start_rc_timer+0x5b/frame 0xfe023705f4e0 _nv000780rm() at _nv000780rm+0x52c/frame 0xfe0001e8af88 dmapbase() at 0xf800b78c7000/frame 0xfe0001f18000 uart_sab82532_class() at 0/frame 0xfe0001e7b000 dmapbase() at 0xf800703a6500/frame 0xfe0001f1c000 (null)() at 0xf801f8ed6000/frame 0xfe0001f26000 uart_sab82532_class() at 0/frame 0xf801f8dbd000 uart_sab82532_class() at 0/frame 0xf8000f758800 uart_sab82532_class() at 0/frame 0xf801f8cac000 dmapbase() at 0xf8000f838400/frame 0xf800700b8800 uart_sab82532_class() at 0/frame 0xf8000f838000 uart_sab82532_class() at 0/frame 0xfe0001f3a000 uart_sab82532_class() at 0/frame 0xfe0001f3e000 uart_sab82532_class() at 0/frame 0xfe0001d5b000 dmapbase() at 0xf800703aaa00/frame 0xfe0001f4 uart_sab82532_class() at 0/frame 0xfe0001f42000 uart_sab82532_class() at 0/frame 0xf8000f76 dmapbase() at 0xf8000f867000/frame 0xf801f8cb3000 dmapbase() at 0xf8000d0ce800/frame 0xf800700b7000 dmapbase() at 0xf800052de000/frame 0xfe0001f52000 uart_sab82532_class() at 0/frame 0xfe0001f54000 uart_sab82532_class() at 0/frame 0xf801f8f85000 uart_sab82532_class() at 0/frame 0xfe0001f5c000 uart_sab82532_class() at 0/frame 0xf8000f833c00 uart_sab82532_class() at 0/frame 0xf8000f761800 uart_sab82532_class() at 0/frame 0xf8000f872800 uart_sab82532_class() at 0/frame 0xf8000f833800 uart_sab82532_class() at 0/frame 0xf800703bc000 uart_sab82532_class() at 0/frame 0xf801f8d04000 uart_sab82532_class() at 0/frame 0xfe0001f5e000 uart_sab82532_class() at 0/frame 0xfe0001f6 (null)() at 0xf801f860c200/frame 0xf8000f833400 uart_sab82532_class() at 0/frame 0xf8000f833000 uart_sab82532_class() at 0/frame 0xf8000f73b800 KDB: enter: panic [ thread pid 1732 tid 100222 ] Stopped at kdb_enter+0x3e: movq$0,kdb_why db I just added device uart_sab82532 to kernel config I'll try that Manfred || n...@pozo.com || || || ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Panic on current amd64
At 03:06 PM 3/28/2015, Davide Italiano wrote: On Sat, Mar 28, 2015 at 3:02 PM, Manfred Antar n...@pozo.com wrote: I get the following panic on current svn ver r280793: Revert to r280784. This should fix. That works Thanks || n...@pozo.com || || || ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
T40 bootloop on CAM status: Command timeout on both 10.1 and -CURRENT
Hello guys, since I tried to install FreeBSD 10.1 on my recently purchased T40 I got stuck at this annoying bootloop that says ATAPY_IDENTIFY. ACB: a1 00 00 00 00 40 00 00 00 etc etc.. CAM status: Command timeout. I have also tried latest 11-CURRENT snapshot and it did not make any difference at all, it is affected from the same exact bootloop. I use to boot the kernel and installation image from PXE, however did try from usb and didn't make any difference, the bootloop goes on forever. I did a bunch of researches on Google and somebody suggested to boot with hint.achci.0.msi=0 or with hw.achi.force=1 but again it did not make any difference. It seems like there might be an issue with the CAM ATA stack that is clashing with the PATA controller on my T40. Interestingly enough, I did try to remove the cdrom drive and boot the installation image with no cd drive installed. However in this case the kernel hangs and seat endlessly on the usb controller detection, it does not progress or give out any logs past the usb controller recognition. Unfortunately at the time being it seems like I am stuck with 10 release, hopefully someone will eventually address this issue so that my T40 can see the light again :) . Here's the link to the picture that showcase the bootloop. https://lh4.googleusercontent.com/-XtUvTbUf_pQ/VQy37HOXAwI/HGQ/t8Pjl7oMlls/s512/IMG_20150321_011327.jpg Regards, Pietro Sammarco ___ 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
umass, Verbatim STORE N GO drive, CAM status 0x50
Dear all, on a 11-current system I tried a VERBATIM usb drive which does not produce a /dev/da... entry. My question is whether this can be fixed by adding an entry in some array within the kernel source (header files?) or is this bad hardware for which a workaround implementation is needed. system is FreeBSD 11.0-CURRENT (VENUS) #0 r280370: Mon Mar 23 22:14:14 CET 2015 relevant dmesg entries when inserting the drive: umass0: Verbatim STORE N GO, class 0/0, rev 2.10/1.00, addr 2 on usbus2 umass0: SCSI over Bulk-Only; quirks = 0x8100 umass0:4:0: Attached to scbus4 (probe0:umass-sim0:0:0:0): REPORT LUNS. CDB: a0 00 00 00 00 00 00 00 00 10 00 00 (probe0:umass-sim0:0:0:0): CAM status: Auto-Sense Retrieval Failed (probe0:umass-sim0:0:0:0): Error 5, Unretryable error (da0:umass-sim0:0:0:0): got CAM status 0x50 (da0:umass-sim0:0:0:0): fatal error, failed to attach to device the device gets recognized as ugen2.2 as seen by the timestamp below # ls -ld ug* lrwxr-xr-x 1 root wheel 9 Mar 28 13:41 ugen0.1@ - usb/0.1.0 lrwxr-xr-x 1 root wheel 9 Mar 28 13:41 ugen1.1@ - usb/1.1.0 lrwxr-xr-x 1 root wheel 9 Mar 28 13:41 ugen2.1@ - usb/2.1.0 lrwxr-xr-x 1 root wheel 9 Mar 28 13:44 ugen2.2@ - usb/2.2.0 ... and of course usbconfig writes the ugen2.2 configuration ugen2.2: STORE N GO Verbatim at usbus2, cfg=0 md=HOST spd=HIGH (480Mbps) pwr=ON (2mA) what follows is the full dmesg output, and the complete usbconfig output what do you recommend? Best wishes Damian -- Copyright (c) 1992-2015 The FreeBSD Project. Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 The Regents of the University of California. All rights reserved. FreeBSD is a registered trademark of The FreeBSD Foundation. FreeBSD 11.0-CURRENT #0 r280370: Mon Mar 23 22:14:14 CET 2015 root@venus.local:/usr/obj/usr/src/sys/VENUS amd64 FreeBSD clang version 3.6.0 (tags/RELEASE_360/final 230434) 20150225 WARNING: WITNESS option enabled, expect reduced performance. CPU: Intel(R) Core(TM)2 CPU 6300 @ 1.86GHz (1862.06-MHz K8-class CPU) Origin=GenuineIntel Id=0x6f2 Family=0x6 Model=0xf 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=0xe3bdSSE3,DTES64,MON,DS_CPL,VMX,EST,TM2,SSSE3,CX16,xTPR,PDCM AMD Features=0x20100800SYSCALL,NX,LM AMD Features2=0x1LAHF VT-x: HLT,PAUSE TSC: P-state invariant, performance statistics real memory = 2147483648 (2048 MB) avail memory = 2038140928 (1943 MB) Event timer LAPIC quality 400 ACPI APIC Table: PTLTD APIC FreeBSD/SMP: Multiprocessor System Detected: 2 CPUs FreeBSD/SMP: 1 package(s) x 2 core(s) cpu0 (BSP): APIC ID: 0 cpu1 (AP): APIC ID: 1 ioapic0 Version 2.0 irqs 0-23 on motherboard random: entropy device infrastructure driver random: selecting highest priority adaptor Dummy kbd1 at kbdmux0 netmap: loaded module random: SOFT: yarrow init() random: selecting highest priority adaptor Yarrow acpi0: PTLTD RSDT on motherboard acpi0: Power Button (fixed) cpu0: ACPI CPU on acpi0 cpu1: ACPI CPU on acpi0 atrtc0: AT realtime clock port 0x70-0x71 irq 8 on acpi0 Event timer RTC frequency 32768 Hz quality 0 attimer0: AT timer port 0x40-0x43 irq 0 on acpi0 Timecounter i8254 frequency 1193182 Hz quality 0 Event timer i8254 frequency 1193182 Hz quality 100 hpet0: High Precision Event Timer iomem 0xfed0-0xfed003ff on acpi0 Timecounter HPET frequency 14318180 Hz quality 950 Event timer HPET frequency 14318180 Hz quality 450 Event timer HPET1 frequency 14318180 Hz quality 440 Event timer HPET2 frequency 14318180 Hz quality 440 Timecounter ACPI-fast frequency 3579545 Hz quality 900 acpi_timer0: 24-bit timer at 3.579545MHz port 0x1008-0x100b on acpi0 acpi_button0: Power Button on acpi0 pcib0: ACPI Host-PCI bridge port 0xcf8-0xcff on acpi0 pci0: ACPI PCI bus on pcib0 pcib1: ACPI PCI-PCI bridge irq 16 at device 1.0 on pci0 pci1: ACPI PCI bus on pcib1 vgapci0: VGA-compatible display mem 0xd100-0xd1ff,0xc000-0xcfff,0xd000-0xd0ff irq 16 at device 0.0 on pci1 vgapci0: Boot video device uhci0: Intel 82801H (ICH8) USB controller USB-D port 0x1820-0x183f irq 20 at device 26.0 on pci0 usbus0 on uhci0 uhci1: Intel 82801H (ICH8) USB controller USB-E port 0x1840-0x185f irq 18 at device 26.1 on pci0 usbus1 on uhci1 ehci0: Intel 82801H (ICH8) USB 2.0 controller USB2-B mem 0xd2305000-0xd23053ff irq 18 at device 26.7 on pci0 usbus2: EHCI version 1.0 usbus2 on ehci0 hdac0: Intel 82801H HDA Controller mem 0xd230-0xd2303fff irq 20 at device 27.0 on pci0 pcib2: ACPI PCI-PCI bridge irq 23 at device 28.0 on pci0 pcib2: failed to allocate initial I/O port window: 0-0xfff pcib2: failed to allocate initial memory window: 0-0xf pcib2: failed to allocate initial prefetch window: 0-0xf pci3: ACPI PCI bus on pcib2 pcib3: ACPI PCI-PCI bridge irq 21 at device 28.5 on pci0
Re: umass, Verbatim STORE N GO drive, CAM status 0x50
On 03/28/15 15:06, Damian Weber wrote: what do you recommend? Try adding some quirks: usbconfig dump_quirk_names | grep MSC --HPS ___ 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: SSE in libthr
On 3/28/15 5:44 AM, Konstantin Belousov wrote:
On Fri, Mar 27, 2015 at 01:49:03PM -0700, Rui Paulo wrote:
On Mar 27, 2015, at 12:26, Eric van Gyzen vangy...@freebsd.org wrote:
In a nutshell:
Clang emits SSE instructions on amd64 in the common path of
pthread_mutex_unlock. This reduces performance by a non-trivial amount. I'd
like to disable SSE in libthr.
In more detail:
In libthr/thread/thr_mutex.c, we find the following:
#define MUTEX_INIT_LINK(m) do {\
(m)-m_qe.tqe_prev = NULL; \
(m)-m_qe.tqe_next = NULL; \
} while (0)
In 9.1, clang 3.1 emits two ordinary mov instructions:
movq $0x0,0x8(%rax)
movq $0x0,(%rax)
Since 10.0 and clang 3.3, clang emits these SSE instructions:
xorps %xmm0,%xmm0
movups %xmm0,(%rax)
Although these look harmless enough, using the FPU can reduce performance by
incurring extra overhead due to context-switching the FPU state.
As I mentioned, this code is used in the common path of pthread_mutex_unlock. I
have a simple test program that creates four threads, all contending for a
single mutex, and measures the total number of lock acquisitions over several
seconds. When libthr is built with SSE, as is current, I get around 53 million
locks in 5 seconds. Without SSE, I get around 60 million (13% more). DTrace
shows around 790,000 calls to fpudna versus 10 calls. There could be other
factors involved, but I presume that the FPU context switches account for most
of the change in performance.
Even when I add some SSE usage in the application--incidentally, these same
instructions--building libthr without SSE improves performance from 53.5 million
to 55.8 million (4.3%).
In the real-world application where I first noticed this, performance improves
by 3-5%.
I would appreciate your thoughts and feedback. The proposed patch is below.
Eric
Index: base/head/lib/libthr/arch/amd64/Makefile.inc
===
--- base/head/lib/libthr/arch/amd64/Makefile.inc(revision 280703)
+++ base/head/lib/libthr/arch/amd64/Makefile.inc(working copy)
@@ -1,3 +1,8 @@
#$FreeBSD$
SRCS+= _umtx_op_err.S
+
+# Using SSE incurs extra overhead per context switch,
+# which measurably impacts performance when the application
+# does not otherwise use FP/SSE.
+CFLAGS+=-mno-sse
Good catch!
Regarding your patch, I think we should disable even more, if possible. How
about:
CFLAGS+=-mno-mmx -mno-3dnow -mno-sse -mno-sse2 -mno-sse3
I think so.
Also, this should be done for libc as well, both on i386 and amd64.
I am not sure, should compiler-rt be included into the set ?
the point is that clang will do this anywhere it can, because it isn't
taking into account the
side effects, just the speed of the commands themselves.
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Libreboot X200 and FreeBSD
I want to buy a Libreboot X200 notebook, however, I also want to use it with FreeBSD. I'm not sure if that works, so I asked Gluglug directly and got the following response: I'm given the impression that text-mode graphics initialization used to work on the X200, but was broken by a later commit. A bisect might help. phcoder-screen fchmmr: if it uses vbt or bios calls, it won't phcoder-screen fchmmr: first one should work, but FreeBSD works only in text mode Text-mode is currently broken on the X200. VBT or fake VBT is currently lacking in the coreboot port for X200 (VBT calls), and lacks INT 10H video services (BIOS calls). I'm not sure if FreeBSD will work correctly or not. It should work if you use the Video BIOS extracted from the original firmware (libreboot won't use or recommend this, because it's proprietary; instead, it uses a free but incomplete implementation called native graphics initialization). Can some FreeBSD developers make a statement on this topic? If it doesn't work, then I can test some patches, if someone writes them, but I'm a sysadmin, not a programmer, so I'm not really able to write some code. ___ 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: SSE in libthr
On 28 Mar 2015, at 13:54, Julian Elischer jul...@freebsd.org wrote: the point is that clang will do this anywhere it can, because it isn't taking into account the side effects, just the speed of the commands themselves. This is also something that is not going to decrease. Clang now enables the SLP vectoriser by default and this code is constantly being improved. Current generation vector units are explicitly designed as targets for compiler autovectorisation, not for hand-tuned DSP code (which, increasingly, runs on the GPU anyway). This means that we're increasingly going to see SSE/AVX/NEON usage in CPU-bound code, even without an explicit programmer decision to do so. Optimising for the case when the vector unit is not used is about as sensible as optimising for the single-core case: it will affect some people, but generally not those who care about performance, and a decreasing number of people over time. David ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Libreboot X200 and FreeBSD
On 03/28/15 16:18, Adrian Chadd wrote: Which intel chipset is in that thing? -a It's a modified Thinkpad X200, so it uses the same chipset, i.e. GM45. ___ 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: umass, Verbatim STORE N GO drive, CAM status 0x50
Hi! I did not find where the product ID goes ... is that everything I have to consider? At the end of sys/dev/usb/usbdevs you'll find the product IDs. -- p...@opsec.eu+49 171 3101372 5 years to go ! ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Libreboot X200 and FreeBSD
Which intel chipset is in that thing? -a ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: umass, Verbatim STORE N GO drive, CAM status 0x50
Date: Sat, 28 Mar 2015 15:36:01 From: Hans Petter Selasky h...@selasky.org To: Damian Weber dwe...@htwsaar.de, freebsd-current@freebsd.org Subject: Re: umass, Verbatim STORE N GO drive, CAM status 0x50 On 03/28/15 15:06, Damian Weber wrote: what do you recommend? Try adding some quirks: usbconfig dump_quirk_names | grep MSC --HPS thanks for the hint, dumping device description gives # usbconfig -u 2 -a 2 dump_device_desc ugen2.2: STORE N GO Verbatim at usbus2, cfg=0 md=HOST spd=HIGH (480Mbps) pwr=ON (2mA) bLength = 0x0012 bDescriptorType = 0x0001 bcdUSB = 0x0210 bDeviceClass = 0x Probed by interface class bDeviceSubClass = 0x bDeviceProtocol = 0x bMaxPacketSize0 = 0x0040 idVendor = 0x18a5 idProduct = 0x0243 bcdDevice = 0x0100 iManufacturer = 0x0001 Verbatim iProduct = 0x0002 STORE N GO iSerialNumber = 0x0003 1258013C bNumConfigurations = 0x0001 in order to ensure I understood it correctly [ 0) no umass kernel module here ] 1) new entry for Vendor VERBATIM in sys/dev/usb/usbdevs with vendor id 0x18a5 2) new entry in the sys/dev/usb/quirk/usb_quirk.c below /* Quirks for manufacturers which USB devices does not respond */ USB_QUIRK(VERBATIM, DUMMY, 0x, 0x, UQ_MSC_NO_SYNC_CACHE, UQ_MATC H_VENDOR_ONLY), (the , after the last entry is a bit irritating) most of these entries have UQ_MSC_NO_SYNC_CACHE - if that doesn't work, I'll try UQ_MSC_NO_TEST_UNIT_READY which is the only other option within that does not respond-section 3) make kernel 4) reboot I did not find where the product ID goes ... is that everything I have to consider? Thanks a lot Damian ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Build failed in Jenkins: FreeBSD_HEAD-tests2 #904
See https://jenkins.freebsd.org/job/FreeBSD_HEAD-tests2/904/ -- [...truncated 2881 lines...] local/atf/atf-c++/utils_test:copy_file__some_contents - passed [0.020s] local/atf/atf-c++/utils_test:create_file - passed [0.018s] local/atf/atf-c++/utils_test:file_exists - passed [0.019s] local/atf/atf-c++/utils_test:fork - passed [0.023s] local/atf/atf-c++/utils_test:grep_collection__set - passed [0.019s] local/atf/atf-c++/utils_test:grep_collection__vector - passed [0.019s] local/atf/atf-c++/utils_test:grep_file - passed [0.021s] local/atf/atf-c++/utils_test:grep_string - passed [0.018s] local/atf/atf-c++/utils_test:redirect__other - passed [0.018s] local/atf/atf-c++/utils_test:redirect__stderr - passed [0.019s] local/atf/atf-c++/utils_test:redirect__stdout - passed [0.020s] local/atf/atf-c++/utils_test:wait__invalid_exitstatus - passed [0.025s] local/atf/atf-c++/utils_test:wait__invalid_stderr - passed [0.025s] local/atf/atf-c++/utils_test:wait__invalid_stdout - passed [0.025s] local/atf/atf-c++/utils_test:wait__ok - passed [0.025s] local/atf/atf-c++/utils_test:wait__ok_nested - passed [0.028s] local/atf/atf-c++/utils_test:wait__save_stderr - passed [0.026s] local/atf/atf-c++/utils_test:wait__save_stdout - passed [0.025s] local/atf/atf-c++/detail/application_test:getopt - passed [0.019s] local/atf/atf-c++/detail/auto_array_test:auto_array_access - passed [0.018s] local/atf/atf-c++/detail/auto_array_test:auto_array_assign - passed [0.018s] local/atf/atf-c++/detail/auto_array_test:auto_array_assign_ref - passed [0.021s] local/atf/atf-c++/detail/auto_array_test:auto_array_copy - passed [0.017s] local/atf/atf-c++/detail/auto_array_test:auto_array_copy_ref - passed [0.018s] local/atf/atf-c++/detail/auto_array_test:auto_array_get - passed [0.019s] local/atf/atf-c++/detail/auto_array_test:auto_array_release - passed [0.016s] local/atf/atf-c++/detail/auto_array_test:auto_array_reset - passed [0.054s] local/atf/atf-c++/detail/auto_array_test:auto_array_scope - passed [0.019s] local/atf/atf-c++/detail/env_test:get_with_default - passed [0.018s] local/atf/atf-c++/detail/env_test:has_get - passed [0.018s] local/atf/atf-c++/detail/env_test:set - passed [0.017s] local/atf/atf-c++/detail/env_test:unset - passed [0.017s] local/atf/atf-c++/detail/exceptions_test:throw_atf_error_libc - passed [0.017s] local/atf/atf-c++/detail/exceptions_test:throw_atf_error_no_memory - passed [0.018s] local/atf/atf-c++/detail/exceptions_test:throw_atf_error_unknown - passed [0.018s] local/atf/atf-c++/detail/fs_test:directory_file_info - passed [0.256s] local/atf/atf-c++/detail/fs_test:directory_names - passed [0.032s] local/atf/atf-c++/detail/fs_test:directory_read - passed [0.029s] local/atf/atf-c++/detail/fs_test:exists - passed [0.048s] local/atf/atf-c++/detail/fs_test:file_info_perms - passed [0.020s] local/atf/atf-c++/detail/fs_test:file_info_stat - passed [0.031s] local/atf/atf-c++/detail/fs_test:is_executable - passed [0.039s] local/atf/atf-c++/detail/fs_test:path_branch_path - passed [0.019s] local/atf/atf-c++/detail/fs_test:path_compare_different - passed [0.018s] local/atf/atf-c++/detail/fs_test:path_compare_equal - passed [0.019s] local/atf/atf-c++/detail/fs_test:path_concat - passed [0.019s] local/atf/atf-c++/detail/fs_test:path_is_absolute - passed [0.018s] local/atf/atf-c++/detail/fs_test:path_is_root - passed [0.018s] local/atf/atf-c++/detail/fs_test:path_leaf_name - passed [0.019s] local/atf/atf-c++/detail/fs_test:path_normalize - passed [0.018s] local/atf/atf-c++/detail/fs_test:path_op_less - passed [0.031s] local/atf/atf-c++/detail/fs_test:path_to_absolute - passed [0.031s] local/atf/atf-c++/detail/fs_test:remove - passed [0.030s] local/atf/atf-c++/detail/process_test:argv_array_assign - passed [0.018s] local/atf/atf-c++/detail/process_test:argv_array_copy - passed [0.019s] local/atf/atf-c++/detail/process_test:argv_array_exec_argv - passed [0.018s] local/atf/atf-c++/detail/process_test:argv_array_init_carray - passed [0.018s] local/atf/atf-c++/detail/process_test:argv_array_init_col - passed [0.019s] local/atf/atf-c++/detail/process_test:argv_array_init_empty - passed [0.018s] local/atf/atf-c++/detail/process_test:argv_array_init_varargs - passed [0.018s] local/atf/atf-c++/detail/process_test:argv_array_iter - passed [0.017s] local/atf/atf-c++/detail/process_test:exec_failure - passed [0.019s] local/atf/atf-c++/detail/process_test:exec_success - passed [0.021s] local/atf/atf-c++/detail/text_test:duplicate - passed [0.017s] local/atf/atf-c++/detail/text_test:join - passed [0.018s] local/atf/atf-c++/detail/text_test:match - passed [0.018s] local/atf/atf-c++/detail/text_test:split - passed [0.018s] local/atf/atf-c++/detail/text_test:split_delims - passed [0.018s]
Re: SSE in libthr
Eric van Gyzen wrote this message on Fri, Mar 27, 2015 at 17:43 -0400: On 03/27/2015 16:49, Rui Paulo wrote: Regarding your patch, I think we should disable even more, if possible. How about: CFLAGS+=-mno-mmx -mno-3dnow -mno-sse -mno-sse2 -mno-sse3 Yes, I was considering copying all of the similar flags that we use in the kernel. That seems wise. According to comments in sys/conf/kern.mk, only no-mmx and no-sse would be necessary, as they imply the others. dim@ raised the possibility of CPUTYPE=foo on i386, so I would also apply this change to i386. An updated patch is below. We should probably add a $(CFLAGS_NOFPU) define and use that.. Then it can be properly tweaked per compiler and per arch as necessary instead of hardcoding the selection in each makefile... -- 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: SSE in libthr
Ok, so how do we reduce the amount of FPU save and restores, or make them cheaper? -a ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Libreboot X200 and FreeBSD
Oh, in that case, someone should send me one so I can use it to verify that my frame-buffer bootloader hack will work correctly on it. Then yeah, we won't have to worry about such evil BIOSes. -adrian ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: SSE in libthr
If SIMD instructions are used for string proceccing, and FPU(AVX) contexts are NOT saved/restored properly on process (thread) switching, possibly processed string is destroyed by other process (thread). Can't it be a security risk? (Broken string parameter for syscalls, etc) If so, FPU (AVX) contexts should be saved/restored at least on process (thread) switching. *If SIMD instructions are NOT used in kernel and kernel modules at all, there would be no need for saving/restoring FPU contexts on interrupts. It's not limited in system libraries. As Alan noted, third party applications can use original string processing code using SIMD. On Fri, 27 Mar 2015 17:43:14 -0700 Adrian Chadd adr...@freebsd.org wrote: On 27 March 2015 at 16:03, Alan Somers asom...@freebsd.org wrote: On Fri, Mar 27, 2015 at 4:36 PM, Adrian Chadd adr...@freebsd.org wrote: hi, please don't try to microoptimise crap like strlen(). The TL;DR for performant high-throughput code is: if strlen() or memcpy() is the thing that's costing you the most, you're doing it wrong. -adrian I respectfully disagree. A well-optimized libc will benefit _every_single_program_ that uses strlen. That includes Apache, Samba, Memcached, Quake, and basically every single program that every single FreeBSD user uses. There's no reason that 3rd party software maintainers should have to rewrite basic libc functions in order to get decent performance on FreeBSD. And the downsides are so small! In 2015, we should assume by default that most userland software is using SIMD instructions. As Eric noticed, Clang emits them freely. What's the point to lazily saving the SSE registers on context switches if essentially all programs compiled from Ports will be using those registers anyway? I agree with Jilles; I think we should always save the SSE registers for userland programs. That's fine, but those benchmarks and improvements also have to take into account the environment that these programs are running in, and all of the other things that are going on with it. Fixing strlen() to use SSE2 is great, but if the gains are offset by fpu save/restore when doing fine grain locking that's blocking under real world workloads, what's the benefit? What about if the system is context switching over a million times a second? These are real life things I see servers running all of the above software /do/. One only knows with benchmarking, not microbenchmarking. Microbenchmarks are great. They serve a purpose, which is how the heck is the current silicon I'm running on run some code that I've cleverly crafted to hopefully run well. I'm totally for saving/restoring SSE registers for userland programs. But that's not where that kind of make stuff fast work should stop. If it does, and that's where your benchmarking for the real world stops, then you're doing it wrong. Everything is a toss-up. For this userland based netmap packet pushing app, SEE may be nice for some instructions, but know what else screws things? The fact that the default scheduler policy is terrible and crap gets scheduled /everywhere/ under any appreciable amount of load. That the context switch rate is high, the interrupt rate is also high, and with a little locking going on, I see fpu save/restore occur for a non-insignificant fraction of CPU. Optimising strlen() or memcpy() is great, but when my system context switches a million times a second, we're never going to reach the steady state that these CPUs can really crank out real work at under those conditions. So, cool. Please keep poking at that stuff. But if you stop short of making the system actually /be able to take advantage of them under load/, I respectfully ask for a nice knob I can use to turn them off. :) -adrian (Know where the slowdowns for memcached are? Hint - not strlen or memcpy. Yes, I've been down that rabbit hole recently. Know what /i/ have? 1 million UDP transactions a second working on 16 core sandybridge systems. Know what I didn't optimise? memcpy or strlen. The network stack locking and pthreads overhead is what sucks.) ___ 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 -- 青木 知明 [Tomoaki AOKI] junch...@dec.sakura.ne.jp mxe02...@nifty.com ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: SSE in libthr
On Fri, Mar 27, 2015 at 10:40:57PM +0100, Jilles Tjoelker wrote: On Fri, Mar 27, 2015 at 03:26:17PM -0400, Eric van Gyzen wrote: In a nutshell: Clang emits SSE instructions on amd64 in the common path of pthread_mutex_unlock. This reduces performance by a non-trivial amount. I'd like to disable SSE in libthr. How about saving and restoring the FPU/SSE state eagerly instead of the current CR0.TS-based lazy method? There is overhead associated with #NM exception handling (fpudna) which is not worth it if FPU/SSE are used often. This would apply to userland threads only; kernel threads normally do not use FPU/SSE and handle the FPU/SSE state manually if they do. First, we have no choice but saving the FPU context when a thread is switched from. It is not practical to try to keep the state in the hardware, since fetching it to other core is too troublesome. Second, the biggest overhead of #NM is the reading of FPU context from memory (or cache), not the handler itself. The save area for SSE-capable machines, i.e. all amd64, is ~400 bytes, and XSAVEOPT does not help much for reading of legacy FPU + XMM state. It does help for YMM. That said, your proposal would force all threads to pay higher cost at the context switch time, increasing latency. There is performance improvement potential in using SSE for optimizing string functions, for example. Even a simple SSE2 strlen easily outperforms the already optimized lib/libc/string/strlen.c in a microbenchmark, and many other string functions are slow byte-at-a-time implementations. If the program does a lot of work with FPU between switches, the cost is obviously mitigated. Note that even for the worst case of the reported microbenchmark, the measured overhead is ~10-15%. So if string ops are indeed take significant share of the program time, the FPU #NM handling cost should be very low even with the current scheme. ___ 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
