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 differenc

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

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

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

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"

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:

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...@f

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 co

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_

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-

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/f

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 vect

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: 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_

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,

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.

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

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

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.