Re: Virtualbox 4.3.20 crashes FreeBSD 11.0-CURRENT

[Ranjan1018 .]

Hi Hans,

the bug is network related: in VirtualBox per VM Settings - Network -
Attach to -  changing from "NAT" to "Bridged Adapter" it works. Probably I
will open a new PR for this bug.

I am testing your patch and I will report the result in the above PR (id
194196).

Maurizio


2014-11-29 17:49 GMT+01:00 Hans Petter Selasky :

> On 11/29/14 16:00, Ranjan1018 . wrote:
>
>> *Just upgrade  emulators/virtualbox-ose-4.3.20 via pkg upgrade. Starting
>> a
>>
>> VM, Windows XP or Ubuntu x86, after few seconds the laptop freezes.The
>> system responds only to power off, pressing the power button for few
>> seconds. The only things I can do is a photo of the screen:
>> https://plus.google.com/112995826906094353410/posts/6amoaitgP8e
>> *
>>
>> *Maurizio*
>>
>
> Hi,
>
> Can you try to apply the patch in the following PR:
>
> https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=194196
>
> Not sure if it helps.
>
> --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: External toolchain support

[Florian Smeets]

On 29/11/14 16:04, Baptiste Daroussin wrote:
> Hi all,
> 
> It is now possible to use an external toolchain to build the kernel and base
> (tested with gcc 4.9.1 and latest binutils)
> 

> make CROSS_TOOLCHAIN=sparc64-gcc -j8 buildkernel
> 

I built a sparc64 kernel on amd64 using sparc64-xtoolchain-gcc
 and was able to boot it successfully.

$ uname -a
FreeBSD v240 11.0-CURRENT FreeBSD 11.0-CURRENT #0 r275267M: Sat Nov 29
22:23:38 CET root@storage:/usr/obj/sparc64.sparc64/usr/src/sys/GENERIC
sparc64
$ sysctl kern.ostype kern.osrelease kern.osrevision kern.compiler_version
kern.ostype: FreeBSD
kern.osrelease: 11.0-CURRENT
kern.osrevision: 199506
kern.compiler_version: gcc version 4.9.1 (FreeBSD Ports Collection for
sparc64)

Florian



signature.asc
Description: OpenPGP digital signature

Re: Possible bug in softfloat

[Julian Elischer]

On 11/29/14, 4:59 AM, Adrian Chadd wrote:

You can easily fire up a mips32 / mips64 emulator build - cross-build
a world+kernel, build an image, then run qemu-devel to boot it.

https://wiki.freebsd.org/FreeBSD/MipsEmulation

You should be able to get a 32 bit soft-float mips environment inside
there which you can use to trigger it.
(And also run whatever other floating point validation suite you may hvae.)


I suspect this is one for bde to look at.





-adrian


On 28 November 2014 at 11:07, Steve Kargl
 wrote:

On Fri, Nov 28, 2014 at 10:54:25AM -0800, Adrian Chadd wrote:

On 28 November 2014 at 10:34, Steve Kargl
 wrote:

In a thread on comp.lang.c, it was pointed out that softfloat
has a bug and in checking src/lib/libc/softfloat I confimed
the issue is present in FreeBSD.  What I hae not confirmed
is whether or not it is possible to hit this bug.  In fact,
it may only hit arm and mips.  Anyway, here's the patch

So we should just commit this?


I suspect the answer is yes, but I have no idea on how
to trigger this code path.  I also have no access to
arm or mips hardware where the problem may manifest only.

It may also be appropriate to have someone else confirm
that the patch is indeed correct.

--
steve

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

Re: External toolchain support

[Alfred Perlstein]

On 11/29/14, 7:04 AM, Baptiste Daroussin wrote:

Hi all,

It is now possible to use an external toolchain to build the kernel and base
(tested with gcc 4.9.1 and latest binutils)

Of course a lot of work is needed to make it build cleanly (aka lots of warning
to fix).

What have been tested so far:
- sparc64 kernel + world
- amd64 kernel + world
- powerpc64 kernel + world

mips cannot be tested because upstream gcc never heard of FreeBSD running on
mips, and I did not receive any patches for mips.

for amd64, in the kernel two things had to be removed from the build:
- aesni: (it request a header which is compiler specific and on recent gcc
will end up including stdlib.h which gives errors because kernel version of free
and malloc are not compatible with the version defined in stdlib.h)
- hptmv: I had to remove it from GENERIC and kernel building.

The result is:

$ sysctl kern.ostype kern.osrelease kern.osrevision kern.compiler_version

kern.ostype: FreeBSD
kern.osrelease: 11.0-CURRENT
kern.osrevision: 199506
kern.compiler_version: gcc version 4.9.1 (FreeBSD Ports Collection for amd64)

so yes it boots and runs

How to do you own testing:
in the ports tree/packages (the amd64 version will appear in packages next week)
install:
amd64-xtoolchain-gcc or powerpc64-xtoolchain-gcc or sparc64-xtoolchain-gcc

if your source tree:
make CROSS_TOOLCHAIN=amd64-gcc -j8 buildkernel
or
make CROSS_TOOLCHAIN=powerpc64-gcc -j8 buildkernel
or
make CROSS_TOOLCHAIN=sparc64-gcc -j8 buildkernel

To build world:
same operation with buildworld. Please note that for world you will need to add
define NO_WERROR (world will also require a change in share/mk/bsd.lib.mk:
s/--fatal-warnings/--no-fatal-warnings/)

also notes that for the kernel a lots of warnings are disabled in
share/sys/kern.mk so do not hesitate to remove yourself those -Wno-error= and
fix the issue they are hidding!

Best regards,
Bapt

This is amazing work, thank you Bapt!

-Alfred
___
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: RFT: Please help testing the llvm/clang 3.5.0 import

[Dmitry Marakasov]

* Dimitry Andric (d...@freebsd.org) wrote:

> We're working on updating llvm, clang and lldb to 3.5.0 in head.
> This is quite a big update again, and any help with testing is
> appreciated.

Well, of 4 error logs from exp-run I've checked (one my port and 3
unmaintained ports) two had basically the same problem and it seems
to be libc++ related, so I ask: was new version of libc++ imported
along with clang/llvm? Past experience show that libc++ should be
updated along with clang, as it may have bugs new clang versions
are not tolerable to.

I've prepared the minimal test program to demonstrate the problem:

--- test.cc begins here ---
#include 
#include 

class Foo {
public:
void Const() const { std::cerr << "OK" << std::endl; }
};

int main() {
Foo foo;
auto f = std::bind(&Foo::Const, foo);
f();

return 0;
}
--- test.cc ends here ---

Note that the method std::bind is used on is const (non-const methods
produce no problems). 

Here's how it works:

--- test.log begins here ---
% for CC in c++ g++48 g++49 g++5 clang++33 clang++34 clang++35; do echo "===> 
${CC}"; ${CC} -std=c++11 test.cc && ./a.out; done
===> c++
OK
===> g++48
OK
===> g++49
OK
===> g++5
OK
===> clang++33
OK
===> clang++34
OK
===> clang++35
In file included from test.cc:1:
In file included from /usr/include/c++/v1/functional:474:
/usr/include/c++/v1/type_traits:433:76: error: no matching function for call to 
'__source'
: public integral_constant(__is_function_imp::__source<_Tp>())) == 1>
   
^~~~
/usr/include/c++/v1/type_traits:438:14: note: in instantiation of template 
class 'std::__1::__libcpp_is_function' requested here
: public __libcpp_is_function<_Tp> {};
 ^
/usr/include/c++/v1/type_traits:443:97: note: in instantiation of template 
class 'std::__1::is_function' requested here
template  struct __libcpp_is_member_function_pointer<_Tp 
_Up::*> : public is_function<_Tp> {};

^
/usr/include/c++/v1/type_traits:446:14: note: in instantiation of template 
class 'std::__1::__libcpp_is_member_function_pointer' 
requested here
: public __libcpp_is_member_function_pointer::type> 
{};
 ^
/usr/include/c++/v1/type_traits:460:38: note: in instantiation of template 
class 'std::__1::is_member_function_pointer' requested 
here
!is_member_function_pointer<_Tp>::value> {};
 ^
/usr/include/c++/v1/type_traits:3093:17: note: in instantiation of template 
class 'std::__1::is_member_object_pointer' requested here
is_member_object_pointer::type>::value &&
^
/usr/include/c++/v1/type_traits:3100:1: note: (skipping 2 contexts in 
backtrace; use -ftemplate-backtrace-limit=0 to see all)
__invoke(_Fp&& __f, _A0&& __a0)
^
/usr/include/c++/v1/type_traits:3126:11: note: in instantiation of template 
class 'std::__1::__invokable_imp' requested here
  __invokable_imp<_Fp, _Args...>::value>
  ^
/usr/include/c++/v1/functional:1973:31: note: in instantiation of template 
class 'std::__1::__invokable' requested here
static const bool value = __invokable<_Fp,
  ^
/usr/include/c++/v1/functional:1985:18: note: in instantiation of template 
class 'std::__1::_is_valid_bind_return, std::__1::tuple<> >' requested here
  bool = _is_valid_bind_return<_Fp, _BoundArgs, _TupleUj>::value>
 ^
/usr/include/c++/v1/functional:2082:18: note: in instantiation of default 
argument for '__bind_return, 
std::__1::tuple<> >' required here
typename __bind_return<_Fd, _Td, tuple<_Args&&...> >::type
 ^~~
test.cc:12:3: note: while substituting deduced template arguments into function 
template 'operator()' [with _Args = <>]
f();
 ^
/usr/include/c++/v1/type_traits:424:28: note: candidate template ignored: 
substitution failure [with _Tp = void () const]: reference to function type 
'void () const' cannot have 'const' qualifier
template  _Tp&  __source();
 ~~~   ^
test.cc:12:2: error: no matching function for call to object of type 
'std::__1::__bind'
f();
^
/usr/include/c++/v1/functional:2083:9: note: candidate template ignored: 
substitution failure [with _Args = <>]: implicit instantiation of undefined 
template 'std::__1::__bind_return, 
std::__1::tuple<>, false>'
operator()(_Args&& ...__args)
^
/usr/include/c++/v1/functional:2092:9: note: candidate template ignored: 
substitution failure [with _Args = <>]: implicit instantiation of undefined 
template 'std::__1::__bind_return, std::__1::tuple<>, false>'
operator()(_Args&& ...__args) const
^
2 errors generated.
--- test.log ends here ---

I think this should be

Call for Help: Setting up Saltstack for devops of jenkins.freebsd.org cluster

[Craig Rodrigues]

FYI,

https://lists.freebsd.org/pipermail/freebsd-testing/2014-December/000693.html

Please send follow-ups to freebsd-test...@freebsd.org .  Thanks.

--
Craig

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