Re: SSE in libthr

2015-03-28 Thread Konstantin Belousov 
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"

Libreboot X200 and FreeBSD

2015-03-28 Thread Piotr Kubaj 
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.
>
> fchmmr: if it uses vbt or bios calls, it won't
> 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

2015-03-28 Thread Julian Elischer 

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  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"

umass, Verbatim STORE N GO drive, CAM status 0x50

2015-03-28 Thread Damian Weber 



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:  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:  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=0xbfebfbff
  Features2=0xe3bd
  AMD Features=0x20100800
  AMD Features2=0x1
  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: 
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  irqs 0-23 on motherboard
random: entropy device infrastructure driver
random: selecting highest priority adaptor 
kbd1 at kbdmux0
netmap: loaded module
random: SOFT: yarrow init()
random: selecting highest priority adaptor 
acpi0:  on motherboard
acpi0: Power Button (fixed)
cpu0:  on acpi0
cpu1:  on acpi0
atrtc0:  port 0x70-0x71 irq 8 on acpi0
Event timer "RTC" frequency 32768 Hz quality 0
attimer0:  port 0x40-0x43 irq 0 on acpi0
Timecounter "i8254" frequency 1193182 Hz quality 0
Event timer "i8254" frequency 1193182 Hz quality 100
hpet0:  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:  on acpi0
pcib0:  port 0xcf8-0xcff on acpi0
pci0:  on pcib0
pcib1:  irq 16 at device 1.0 on pci0
pci1:  on pcib1
vgapci0:  mem 
0xd100-0xd1ff,0xc000-0xcfff,0xd000-0xd0ff irq 16 at 
device 0.0 on pci1
vgapci0: Boot video device
uhci0:  port 0x1820-0x183f irq 20 at 
device 26.0 on pci0
usbus0 on uhci0
uhci1:  port 0x1840-0x185f irq 18 at 
device 26.1 on pci0
usbus1 on uhci1
ehci0:  mem 
0xd2305000-0xd23053ff irq 18 at device 26.7 on pci0
usbus2: EHCI version 1.0
usbus2 on ehci0
hdac0:  mem 0xd230-0xd2303fff irq 20 at device 
27.0 on pci0
pcib2:  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:  on pcib2
pcib3:  irq 21 at device 28.5 on pci0
pci9:  on pcib3
bge0:  mem 
0xd200-0xd200 irq 17 at device 0.0 on pci9
bge0: CHIP ID 0xa002; ASIC REV 0x0a; CHIP REV 0xa0; PCI-E
miibus0:  on bge0
brgphy0:  PHY 1 on miibus0
brgphy0:  10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseT, 
1000baseT-master, 1000baseT-FDX, 1000baseT-FDX-master, auto, auto-flow
bge0: Using defaults for TSO: 65518/35/2048
bge0: Ethernet address: 00:30:05:c2:d9:9e
uhci2:  port 0x1860-0x187f irq 23 at 
device 29.0 on pci0
usbus3 on uhci2
uhci3:  port 0x1880-0x189f irq 22 at 
device 29.1 on pci0
usbus4 on uhci3
uhci4:  port 0x18a0-0x18bf irq 21 at 
device 29.2 on pci0
usbus5 on uhci4
ehci1:  mem 
0xd2305400-0xd

Re: umass, Verbatim STORE N GO drive, CAM status 0x50

2015-03-28 Thread Hans Petter Selasky 

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: umass, Verbatim STORE N GO drive, CAM status 0x50

2015-03-28 Thread Damian Weber 


> Date: Sat, 28 Mar 2015 15:36:01
> From: Hans Petter Selasky 
> To: Damian Weber , 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:  at usbus2, cfg=0 md=HOST spd=HIGH (480Mbps) 
pwr=ON (2mA)

  bLength = 0x0012
  bDescriptorType = 0x0001
  bcdUSB = 0x0210 
  bDeviceClass = 0x  
  bDeviceSubClass = 0x
  bDeviceProtocol = 0x   
  bMaxPacketSize0 = 0x0040 
  idVendor = 0x18a5 
  idProduct = 0x0243  
  bcdDevice = 0x0100 
  iManufacturer = 0x0001  
  iProduct = 0x0002  
  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"

Re: Libreboot X200 and FreeBSD

2015-03-28 Thread Adrian Chadd 
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: SSE in libthr

2015-03-28 Thread David Chisnall 
On 28 Mar 2015, at 13:54, Julian Elischer  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

2015-03-28 Thread Piotr Kubaj 
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

2015-03-28 Thread Kurt Jaeger 
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"

Build failed in Jenkins: FreeBSD_HEAD-tests2 #904

2015-03-28 Thread jenkins-admin 
See 

--
[...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+

Re: SSE in libthr

2015-03-28 Thread John-Mark Gurney 
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

2015-03-28 Thread Adrian Chadd 
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

2015-03-28 Thread Adrian Chadd 
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"

Jenkins build is back to normal : FreeBSD_HEAD-tests2 #905

2015-03-28 Thread jenkins-admin 
See 

___
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

2015-03-28 Thread Manfred Antar 
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

2015-03-28 Thread Davide Italiano 
On Sat, Mar 28, 2015 at 3:02 PM, Manfred Antar  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"

Re: Panic on current amd64

2015-03-28 Thread Manfred Antar 
At 03:06 PM 3/28/2015, Davide Italiano wrote:
>On Sat, Mar 28, 2015 at 3:02 PM, Manfred Antar  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

2015-03-28 Thread bsdml 

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"