Re: DigitalOcean offers VMs with FreeBSD!

[Bernhard Fröhlich]

On Thu, Jan 15, 2015 at 12:29 PM, Lev Serebryakov  wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA512
>
>
>
https://www.digitalocean.com/company/blog/presenting-freebsd-how-we-made-it-happen/
>
> I didn't see this news on mailing lists :)

I had a quick look at it and the result is
quite poor considering the time it took them to get it done.

They had to install quite a few packages (perl, python27, libX11, avahi
...) and modified the stock FreeBSD image quite a bit. At startup they send
an arping otherwise you do not even have network access in their network.
This looks all a bit hackish and error prone. I am really wondering how
long it will take that a regular update breaks their scripts and let's you
back with a non accessible box.

-- 
Bernhard Froehlich
http://www.bluelife.at/
___
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: Official FreeBSD Binary Packages now available for pkgng

[Bernhard Fröhlich]

Am 02.11.2013 11:51 schrieb "Matthew Seaman" :
>
> On 02/11/2013 10:15, Matthias Andree wrote:
> > I understand from Eric's pist that the issue is that through his
> > limiting proxies, the SRV are not available at all so he does not even
> > get to the point where he could get the pkgN.nyi.freebsd.org
> >  name back.
>
> That doesn't make sense.  All the DNS SRV lookups on pkg.freebsd.org are
> done internally to pkg(8), which then issues an HTTP GET to the specific
> mirror selected by its internal algorithms.  The web cache won't see
> literal 'pkg.freebsd.org' anywhere in the HTTP traffic -- as far as it
> is concerned, it's a simple HTTP request to a specific mirror
> 'pkg1.nyi.freebsd.org', and can be cached using the usual processes.
>
> What makes it cache unfriendly is that as far as the web cache is
> concerned each of the different mirrors appears to be completely
> independent of the others.  So at the moment the chance of getting a
> cache hit is reduced by a factor of three because of the traffic
> distribution across the three mirrors.

Just to add another viewpoint. The redports backendmachines are put into an
IPv6 private address space without default router and without a dns server.
The only internet connection that they have is via an squid proxy.
This setup works fine now that libfetch supports http proxies also for
https urls. This all works based on the assumption that no direct dns
lookups are required on the machines itself but all dns stuff is done on
the proxy.

Your description makes me believe that this won't work for pkgng. So it's
not that people in the real world break their network setups but we also
use that in our own FreeBSD infrastructure.
___
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: mysql-client-5.6.14 build failed

[Bernhard Fröhlich]

On Sun, Oct 13, 2013 at 6:23 PM, Sun Renjie  wrote:
> Hi Alexander:
>
>> Date: Wed, 02 Oct 2013 02:04:02 +0300
>> From: Alexander Panyushkin 
>> To: freebsd-current@freebsd.org
>> Subject: mysql-client-5.6.14 build failed
>> Message-ID: <524b54e2.1040...@gmail.com>
>> Content-Type: text/plain; charset=UTF-8; format=flowed
>>
>> Hi all.
>>
>> mysql-client-5.6.14 not build with clang
>
>>
>> /usr/ports/databases/mysql56-client/work/mysql-5.6.14/sql/net_serv.cc:48:
>> In file included from /usr/include/c++/v1/algorithm:627:
>> /usr/include/c++/v1/memory:968:39: error: expected unqualified-id
>>  template  static __two test(...);
>
> The build fails because the 'test' macro is defined in include/my_global.h:
> #define test(a) ((a) ? 1 : 0)
> yet libc++ standard header  defines 'test' as the name of a
> function:
> template  static char test(typename _Up::pointer* = 0);
>
> MySQL C++ source code files like sql/net_serv.cc #include 
> before
> including . This ordering will result in the 'test' function in
> 
> macro-expanded into nonsense.
>
> After a casual scan, more C++ source code files might be affacted:
>
> client/mysql.cc:45:#include 
> client/mysqlbinlog.cc:58:#include 
> client/mysqltest.cc:51:#include 
> client/sql_string.cc:28:#include 
> ...
>
> I've prepared an ad hoc patch that modifies include/my_global.h to include
>  before defining the 'test' macro, so that further including of
> 
> will be uneffective and hence unharmful. I believe this likely to be useful
> before there is a fix from upstream mysql or libc++. Now this package
> (mysql56-client) and the server counterpart (mysql56-server) build fine.
> I'm new
> to FreeBSD so I hope someone else could produce a better solution. Any
> comments
> will be highly appreciated! Thanks.
>
> Here comes the patch (see also the attachment):
>
> root@r:/svn/ports/databases/mysql56-client # cat
> files/patch-include_my_global.h
> --- include/my_global.h.orig2013-10-13 22:22:33.0 +0800
> +++ include/my_global.h 2013-10-13 22:26:57.0 +0800
> @@ -460,6 +460,13 @@
>  typedef unsigned short ushort;
>  #endif
>
> +/* the macro test() below will break libc++ standard header  which
> +   defines function named 'test'; fix it in an ad hoc manner by including
> the
> +   header before definition of the macro. */
> +#ifdef  __cplusplus
> +#include 
> +#endif
> +
>  #define swap_variables(t, a, b) { t dummy; dummy= a; a= b; b= dummy; }
>  #define test(a)((a) ? 1 : 0)
>  #define set_if_bigger(a,b)  do { if ((a) < (b)) (a)=(b); } while(0)

Please update to latest HEAD (about mid last week) and to latest portstree
because the issues are already fixed in libc++ and the mysql 5.6 port.

Btw your analysis is correct but I have chosen a less intrusive fix in libc++
memory to rename that internal test function and another patch to mysql 5.6.

-- 
Bernhard Froehlich
http://www.bluelife.at/
___
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: patch to add AES intrinsics to gcc

[Bernhard Fröhlich]

On Fri, Aug 23, 2013 at 2:12 PM, Volodymyr Kostyrko  wrote:
> 23.08.2013 12:58, Bernhard Fröhlich wrote:
>>
>> I don't know if you are aware that IF you really do that we will have
>> serious
>> problems to ship packages for 10. USE_GCC=any is the fallback in the
>> portstree for all ports that are unable to build with clang which was
>> introduced
>> when HEAD switched to clang as default cc. Right now there are 150 ports
>> in
>> the tree that use this fallback and quite a few of them are high profile
>> ports:
>>
>> the highlights:
>> audio/nas devel/mingw32-binutils emulators/qemu emulators/virtualbox-ose
>> emulators/wine lang/go lang/v8 mail/courier math/fftw3 multimedia/libxine
>> multimedia/gstreamer multimedia/gstreamer-plugins multimedia/x264
>> security/clamav
>>
>> the full list:
>> http://dpaste.com/1354075/
>>
>> A possible hack could be to add a check for USE_GCC=any to behave like
>> a USE_GCC=yes on HEAD on the affected platforms. This pulls in lang/gcc
>> from ports for a lot of people on HEAD I suppose.
>
>
> I object. Many ports that compiles perfectly on gcc 4.2.1 can't be compiled
> with lang/gcc. I checked this once and the number of ports that require
> strictly gcc 4.2.1 was bigger for me then number of ports that can't be
> compiled with clang but fill fine on lang/gcc.
>
> I'll gonna recheck whether lang/gcc42 is sufficient for them. But I have
> that bad feeling...

lang/gcc42 is on the list of ports that have USE_GCC=any. So you would need
to fix it first to be able to compile it with clang 3.3 from base.

We are not trying to build everything with lang/gcc but just the ports that have
USE_GCC=any in their Makefile. Per default all ports are still build with cc
from base so clang 3.3 on HEAD.

-- 
Bernhard Froehlich
http://www.bluelife.at/
___
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: patch to add AES intrinsics to gcc

[Bernhard Fröhlich]

On Fri, Aug 23, 2013 at 12:35 PM, David Chisnall  wrote:
> On 23 Aug 2013, at 10:58, Bernhard Fröhlich  wrote:
>
>> I don't know if you are aware that IF you really do that we will have serious
>> problems to ship packages for 10. USE_GCC=any is the fallback in the
>> portstree for all ports that are unable to build with clang which was 
>> introduced
>> when HEAD switched to clang as default cc. Right now there are 150 ports in
>> the tree that use this fallback and quite a few of them are high profile 
>> ports:
>>
>> the highlights:
>> audio/nas devel/mingw32-binutils emulators/qemu emulators/virtualbox-ose
>> emulators/wine lang/go lang/v8 mail/courier math/fftw3 multimedia/libxine
>> multimedia/gstreamer multimedia/gstreamer-plugins multimedia/x264
>> security/clamav
>>
>> the full list:
>> http://dpaste.com/1354075/
>>
>> A possible hack could be to add a check for USE_GCC=any to behave like
>> a USE_GCC=yes on HEAD on the affected platforms. This pulls in lang/gcc
>> from ports for a lot of people on HEAD I suppose.
>>
>> We certainly need to do that switch to remove the ancient gcc from base
>> some time but with my portmgr hat on I can only say we don't plan to do that
>> before 10.0 especially not if we are only talking about a few weeks time 
>> window.
>
> That is unfortunate.  We have said for over a year that 10.0 should not ship 
> with gcc.  I can delay committing the patch to flip the switch until later in 
> the code slush, if re approves, but ports that require gcc should be building 
> with gcc from ports (which will also improve code quality, as gcc 4.6/7 
> produce significantly better code than 4.2.1).

I have asked the question of "when will gcc be removed from base" multiple
times over the last year and I got varying results back with the majority saying
"after 10". I'm just trying to say that It looks like some people in
src also don't
expect it to be removed in 10.

Anyway bapt already did some testing without gcc in base on HEAD and the
results were bad but not totally awful. We will see if we can fix the
most important
ones in time before 10 but we can't promise anything.

If someone wants to have a look at the failures with no gcc in base on HEAD:

http://pb2.nyi.freebsd.org/bulk/nogcc-default/2013-08-04_01h01m20s/
(this also includes HEAD failures caused by clang)

-- 
Bernhard Froehlich
http://www.bluelife.at/
___
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: patch to add AES intrinsics to gcc

[Bernhard Fröhlich]

I don't know if you are aware that IF you really do that we will have serious
problems to ship packages for 10. USE_GCC=any is the fallback in the
portstree for all ports that are unable to build with clang which was introduced
when HEAD switched to clang as default cc. Right now there are 150 ports in
the tree that use this fallback and quite a few of them are high profile ports:

the highlights:
audio/nas devel/mingw32-binutils emulators/qemu emulators/virtualbox-ose
emulators/wine lang/go lang/v8 mail/courier math/fftw3 multimedia/libxine
multimedia/gstreamer multimedia/gstreamer-plugins multimedia/x264
security/clamav

the full list:
http://dpaste.com/1354075/

A possible hack could be to add a check for USE_GCC=any to behave like
a USE_GCC=yes on HEAD on the affected platforms. This pulls in lang/gcc
from ports for a lot of people on HEAD I suppose.

We certainly need to do that switch to remove the ancient gcc from base
some time but with my portmgr hat on I can only say we don't plan to do that
before 10.0 especially not if we are only talking about a few weeks time window.

-- 
Bernhard Froehlich
http://www.bluelife.at/


On Fri, Aug 23, 2013 at 11:16 AM, David Chisnall  wrote:
> I have a patch that I intend to commit before the 10.0 code slush that 
> removes GCC and libstdc++ from the default build on platforms where clang is 
> the system compiler.  We definitely don't want to be supporting our 
> 6-year-old versions of these for the lifetime of the 10.x branch.
>
> David
>
> On 22 Aug 2013, at 21:09, John-Mark Gurney  wrote:
>
>> In my work to get AES-NI performance in a better state and the fact
>> that we haven't deprecated gcc yet, I have developed another patch to
>> add the appropriate AES intrinstic headers to gcc.
>>
>> The patch is available at:
>> https://people.freebsd.org/~jmg/gcc.aes.intrin.patch
>>
>> I did have to change the opth-gen.awk script, since it wouldn't let
>> me use bit 31, and recent changes to gcc used up all the remaining
>> bits.  I also was unable to add the -mpclmul option because of running
>> out of these bits.
>>
>> Thanks.
>>
>> --
>>  John-Mark Gurney Voice: +1 415 225 5579
>>
>> "All that I will do, has been done, All that I have, has not."
>> ___
>> freebsd-toolch...@freebsd.org mailing list
>> http://lists.freebsd.org/mailman/listinfo/freebsd-toolchain
>> To unsubscribe, send any mail to "freebsd-toolchain-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: Virtualbox addition in FreeBSD -current guest OS?

[Bernhard Fröhlich]

This should be fixed together with the update to 4.2.12 now.

On Fri, Apr 26, 2013 at 7:43 PM, Mark Johnston  wrote:
> On Fri, Apr 26, 2013 at 11:07:35AM -0400, Glen Barber wrote:
>> On Fri, Apr 26, 2013 at 11:02:10AM -0400, Mark Johnston wrote:
>> > On Fri, Apr 26, 2013 at 10:49:55AM -0400, Glen Barber wrote:
>> > > On Fri, Apr 26, 2013 at 10:45:19AM -0400, Viren Shah wrote:
>> > > > I was having problems compiling the virtualbox guest additions  on a 
>> > > > FBSD
>> > > > -current  (Apr 23 20:30 EDT) system. I changed all the VM_OBJECT_LOCKs 
>> > > > to
>> > > > VM_OBJECT_WLOCKs (and same for the UNLOCKS) and added rwlock.h to the
>> > > > includes. That enabled it to compile but I'm having problems getting X
>> > > > started (it just hangs) using those vbox modules for xorg. Log msg (see
>> > > > attached) says "failed to initialize VirtualBox device (rc=-102)"
>> > > >
>> > > > Anyone having recently compiled the vbox ose-additions on a -current 
>> > > > system
>> > > > and had it work? I'm just trying to figure out if this is a
>> > > > -current-related issue or a vbox related one.
>> > > >
>> > >
>> > > This was fixed months ago, I think.  Is your ports tree updated?
>> >
>> > As far as the compilation issue goes, the virtualbox-ose-kmod port is
>> > indeed fixed but virtualbox-ose-additions is still broken on current
>> > with the latest ports tree.
>>
>> *sigh*...  Is this broken "again" or broken "still" ?
>
> Looks like the latter based on the port's revision history. It was just
> never fixed when the lock changed to a rwlock.
> ___
> 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"



-- 
Bernhard Froehlich
http://www.bluelife.at/
___
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: Kernel panic CURRENT r248596 at virtualbox-ose-kmod module load

[Bernhard Fröhlich]

On Mon, Mar 25, 2013 at 1:03 AM, Ivan Klymenko  wrote:
> В Sun, 24 Mar 2013 14:05:07 +0200
> Konstantin Belousov  пишет:
>
>> On Sat, Mar 23, 2013 at 01:26:27PM +0200, Ivan Klymenko wrote:
>> > I have
>> > uname -a
>> > FreeBSD nonamehost 10.0-CURRENT FreeBSD 10.0-CURRENT #0 r248596: Fri
>> > Mar 22 01:17:08 EET 2013
>> > ivan@nonamehost:/usr/obj/usr/src/sys/GENERIC  amd64
>> >
>> > I updated the ports tree to r314921 and recompiled
>> > virtualbox-ose-kmod
>> >
>> > After load the module a have kernel panic.
>> >
>> > Panic  String:  Lock  vm  object  not  exclusively   locked   @
>> > /usr/src/sys/vm/vm_page.c:1396
>> >
>> > http://pkgupdate.nevosoft.ru/backtrace.txt
>>
>> This looks like a vbox issue, the driver did not properly locked
>> the object passed to the vm_page_alloc_contig().
>>
>> If you want this fixed, you probably need to look up the code
>> yourself, compiling the vbox kld with debugging, finding the
>> offending call to vm_page_alloc_contig() and looking around it to see
>> which object is passed and why it is not locked.
>
> The problem is that port commiter did not listen your advice:
> http://docs.freebsd.org/cgi/mid.cgi?20130312151751.GJ3794
>
> and used in the patch is not the functions that need
> http://svnweb.freebsd.org/ports/head/emulators/virtualbox-ose-kmod/files/patch-src-VBox-Runtime-r0drv-freebsd-memobj-r0drv-freebsd_VM_OBJECT_RENAME.c?r1=314794&r2=314796
>
> I replaced the all function "VM_OBJECT_RLOCK" on "VM_OBJECT_WLOCK"
> and
> "VM_OBJECT_RUNLOCK" on "VM_OBJECT_WUNLOCK"
>
> and the kernel panic ceased.
>
> Thanks. This problem is solved.

Thanks a lot! I've fixed it in the port now. Would be great if you could verify
that it's correct now.

-- 
Bernhard Froehlich
http://www.bluelife.at/
___
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: FreeBSD Testing Facility

[Bernhard Fröhlich]

On Thu, Feb 21, 2013 at 4:43 PM, Mehmet Erol Sanliturk
 wrote:
> On Thu, Feb 21, 2013 at 7:32 AM, Alexander Yerenkow wrote:
>
>> Decent testing system is a pretty complex system to be.
>> I spent some time in this area, and gave it up, at least till better times
>> :)
>>
>> But anyway, at least booting/working network stack/firewall could be
>> easily tested with VMs.
>> There just need to be a person dedicated to this, which is lacking now.
>>
>>
>> --
>> Regards,
>> Alexander Yerenkow
>
>
>
> With "BOINC" , people are trying to solve very complex problems by
> contributing as much as what they can do to solve its parts .
>
> A similar structure may be established for FreeBSD .
>
> As an example , booting in virtual machine may be possible , but in a real
> machine may not work .
> Some main boards may work , but others may not work .
>
> The FreeBSD project can not establish a very large testing farm .
>
> People wanting to participate may contribute very much .
>
> Every one will not test every thing .

We certainly want to have a system that allows to perform tests in an
automated fashion. Both compile and runtime tests but I don't see us
running a huge lab of desktop or even worse laptop class hardware to
verify that everything works. So the only way to go is limited testing
if a new snapshot runs at all and then perform a few runtime tests and
probably some benchmarks to find major regressions.

Running a BOINC kind of system sounds like out of reach and not worth
the work. BOINC works because it's cool to find aliens or prove that
Einstein was wrong but testing software is not cool.

In your special case it looks like you hit some bug so please file a PR
and provide as much details as possible to track down what is causing
this.

-- 
Bernhard Froehlich
http://www.bluelife.at/
___
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: sluggish X.org/Xfce behavior

[Bernhard Fröhlich]

On Tue, Nov 20, 2012 at 11:18 AM, René Ladan  wrote:
> Hi,
>
> since last weekend (November 17th) I have been noticing a sluggish
> behavior of X.org/Xfce. Typical symptoms are:
> - Alt-Tab not reacting all of the time
> - pulldown/popup menus not allowing selections with mouse (typically in
> Terminal/pidgin), or moving the mouse (touchpad) results in an automatic
> click
> - typing something in a Terminal requires mouse (touchpad) movements for
> the text to show up
> - sometimes moving the mouse (touchpad) is required for the laptop to
> "wake up"; this is noticeable when Thunderbird downloads all messages
> from the period when the laptop was "frozen".
>
> I am running 10-amd64 r243234 (so with clang as cc) and ports 307851
> without any local modifications. Since November 5 (when clang became cc)
> I noticed x11/nvidia-driver and x11-drivers/xf86-input-mouse were
> updated but rebuilding those with gcc did not make any difference. Maybe
> I missed a related port? All ports last updated before November 5th are
> still built with gcc.
>
> My /etc/make.conf and /etc/rc.conf are attached.
>
> Has anyone else been noticing this?

Very interesting symptoms. I had the same until xf86-input-mouse was fixed
with the last update. The symptoms were reproducible when attaching an
USB mouse which caused all kind of weird X11 (re)drawing issues.

-- 
Bernhard Froehlich
http://www.bluelife.at/
___
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: make package fails in chroot: tar: getvfsbyname failed: No such file or directory

[Bernhard Fröhlich]

On Thu, Aug 30, 2012 at 4:34 PM, Konstantin Belousov
 wrote:
> On Thu, Aug 30, 2012 at 04:07:48PM +0200, Bernhard Fr?hlich wrote:
>> On Mon, Aug 20, 2012 at 2:31 PM, Konstantin Belousov
>>  wrote:
>> > On Mon, Aug 20, 2012 at 01:42:31PM +0200, Bernhard Fr?hlich wrote:
>> >> On Sun, Aug 19, 2012 at 10:01 PM, Tim Kientzle  wrote:
>> >> >
>> >> > On Aug 19, 2012, at 12:17 PM, Garrett Cooper wrote:
>> >> >
>> >> >> On Sun, Aug 19, 2012 at 9:45 AM, Tim Kientzle  
>> >> >> wrote:
>> >> >>>
>> >> >>> On Aug 12, 2012, at 6:20 AM, Paul Schenkeveld wrote:
>> >> >>>
>> >>  Hi,
>> >> 
>> >>  I have a wrapper script that builds packages in a chroot environment
>> >>  which happily runs on release 6 thru 9 and earlier 10 but fails with:
>> >> 
>> >>  tar: getvfsbyname failed: No such file or directory
>> >> 
>> >>  on a recent -CURRENT.
>> >> >>>
>> >> >>> libarchive does do an initial getvfsbyname() when you ask it
>> >> >>> to traverse a directory tree so that it can accurately handle later
>> >> >>> requests about mountpoints and filesystem types.  This code
>> >> >>> is admittedly a little intricate.
>> >> >>
>> >> >>The problem most likely is the fact that all mountpoints are
>> >> >> exposed via chroot, thus, if it's checking to see if a mountpoint
>> >> >> exists, it may exist outside of the chroot.
>> >> >>
>> >> >
>> >> > I reviewed the code to refresh my memory.   Some
>> >> > of what I said before was not quite right.
>> >> >
>> >> > Libarchive's directory traversal tracks information about
>> >> > the filesystem type so that clients such as bsdtar can
>> >> > efficiently skip synthetic filesystems (/dev or /proc) or
>> >> > network filesystems (NFS or SMB mounts).
>> >> >
>> >> > The net effect is something like this:
>> >> >
>> >> >For each file:
>> >> >stat() or lstat() or fstat() the file
>> >> >look up dev number in an internal cache
>> >> >if the dev number is new:
>> >> > fstatfs() the open fd to get the FS name
>> >> > getvfsbyname() to identify the FS type
>> >> >
>> >> > Unless there's a logic error in libarchive itself, this
>> >> > would suggest that somehow fstatfs() is returning
>> >> > a filesystem type that getvfsbyname() can't
>> >> > identify.
>> >> >
>> >> > Paul:
>> >> > What filesystem are you using?
>> >> >
>> >> > What does "mount" show?
>> >> >
>> >> > Does it work outside the chroot?
>> >>
>> >> I also see the same on the redports.org build machines.
>> >> It builds within a jail there which is completely on a tmpfs.
>> >> Interestinly everything is fine with a 10-CURRENT/amd64
>> >> jail but it breaks in a 10-CURRENT/i386 jail. Both are
>> >> running on the same 10-CURRENT/amd64 which is
>> >> around 2 months old.
>> >>
>> >> https://redports.org/buildarchive/20120814130205-56327/
>> >
>> > Try this.
>>
>> Is it possible that this requires the host system to be quite
>> new? The commit in HEAD seems to doesn't help in my
>> case. Host is 9-stable from Jun 27 and jail is 10-current from
>> a few days ago.
> Doh, the fix was in kernel, and I merged the change back to stable only
> on August 27.
>
> Running HEAD world on stable is not supported anyway.

I've updated the host to a recent 9-stable and it works like a charm now.
Thanks for fixing it!

-- 
Bernhard Froehlich
http://www.bluelife.at/
___
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: make package fails in chroot: tar: getvfsbyname failed: No such file or directory

[Bernhard Fröhlich]

On Mon, Aug 20, 2012 at 2:31 PM, Konstantin Belousov
 wrote:
> On Mon, Aug 20, 2012 at 01:42:31PM +0200, Bernhard Fr?hlich wrote:
>> On Sun, Aug 19, 2012 at 10:01 PM, Tim Kientzle  wrote:
>> >
>> > On Aug 19, 2012, at 12:17 PM, Garrett Cooper wrote:
>> >
>> >> On Sun, Aug 19, 2012 at 9:45 AM, Tim Kientzle  wrote:
>> >>>
>> >>> On Aug 12, 2012, at 6:20 AM, Paul Schenkeveld wrote:
>> >>>
>>  Hi,
>> 
>>  I have a wrapper script that builds packages in a chroot environment
>>  which happily runs on release 6 thru 9 and earlier 10 but fails with:
>> 
>>  tar: getvfsbyname failed: No such file or directory
>> 
>>  on a recent -CURRENT.
>> >>>
>> >>> libarchive does do an initial getvfsbyname() when you ask it
>> >>> to traverse a directory tree so that it can accurately handle later
>> >>> requests about mountpoints and filesystem types.  This code
>> >>> is admittedly a little intricate.
>> >>
>> >>The problem most likely is the fact that all mountpoints are
>> >> exposed via chroot, thus, if it's checking to see if a mountpoint
>> >> exists, it may exist outside of the chroot.
>> >>
>> >
>> > I reviewed the code to refresh my memory.   Some
>> > of what I said before was not quite right.
>> >
>> > Libarchive's directory traversal tracks information about
>> > the filesystem type so that clients such as bsdtar can
>> > efficiently skip synthetic filesystems (/dev or /proc) or
>> > network filesystems (NFS or SMB mounts).
>> >
>> > The net effect is something like this:
>> >
>> >For each file:
>> >stat() or lstat() or fstat() the file
>> >look up dev number in an internal cache
>> >if the dev number is new:
>> > fstatfs() the open fd to get the FS name
>> > getvfsbyname() to identify the FS type
>> >
>> > Unless there's a logic error in libarchive itself, this
>> > would suggest that somehow fstatfs() is returning
>> > a filesystem type that getvfsbyname() can't
>> > identify.
>> >
>> > Paul:
>> > What filesystem are you using?
>> >
>> > What does "mount" show?
>> >
>> > Does it work outside the chroot?
>>
>> I also see the same on the redports.org build machines.
>> It builds within a jail there which is completely on a tmpfs.
>> Interestinly everything is fine with a 10-CURRENT/amd64
>> jail but it breaks in a 10-CURRENT/i386 jail. Both are
>> running on the same 10-CURRENT/amd64 which is
>> around 2 months old.
>>
>> https://redports.org/buildarchive/20120814130205-56327/
>
> Try this.

Is it possible that this requires the host system to be quite
new? The commit in HEAD seems to doesn't help in my
case. Host is 9-stable from Jun 27 and jail is 10-current from
a few days ago.

-- 
Bernhard Froehlich
http://www.bluelife.at/
___
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: make package fails in chroot: tar: getvfsbyname failed: No such file or directory

[Bernhard Fröhlich]

On Mon, Aug 20, 2012 at 2:31 PM, Konstantin Belousov
 wrote:
> On Mon, Aug 20, 2012 at 01:42:31PM +0200, Bernhard Fr?hlich wrote:
>> On Sun, Aug 19, 2012 at 10:01 PM, Tim Kientzle  wrote:
>> >
>> > On Aug 19, 2012, at 12:17 PM, Garrett Cooper wrote:
>> >
>> >> On Sun, Aug 19, 2012 at 9:45 AM, Tim Kientzle  wrote:
>> >>>
>> >>> On Aug 12, 2012, at 6:20 AM, Paul Schenkeveld wrote:
>> >>>
>>  Hi,
>> 
>>  I have a wrapper script that builds packages in a chroot environment
>>  which happily runs on release 6 thru 9 and earlier 10 but fails with:
>> 
>>  tar: getvfsbyname failed: No such file or directory
>> 
>>  on a recent -CURRENT.
>> >>>
>> >>> libarchive does do an initial getvfsbyname() when you ask it
>> >>> to traverse a directory tree so that it can accurately handle later
>> >>> requests about mountpoints and filesystem types.  This code
>> >>> is admittedly a little intricate.
>> >>
>> >>The problem most likely is the fact that all mountpoints are
>> >> exposed via chroot, thus, if it's checking to see if a mountpoint
>> >> exists, it may exist outside of the chroot.
>> >>
>> >
>> > I reviewed the code to refresh my memory.   Some
>> > of what I said before was not quite right.
>> >
>> > Libarchive's directory traversal tracks information about
>> > the filesystem type so that clients such as bsdtar can
>> > efficiently skip synthetic filesystems (/dev or /proc) or
>> > network filesystems (NFS or SMB mounts).
>> >
>> > The net effect is something like this:
>> >
>> >For each file:
>> >stat() or lstat() or fstat() the file
>> >look up dev number in an internal cache
>> >if the dev number is new:
>> > fstatfs() the open fd to get the FS name
>> > getvfsbyname() to identify the FS type
>> >
>> > Unless there's a logic error in libarchive itself, this
>> > would suggest that somehow fstatfs() is returning
>> > a filesystem type that getvfsbyname() can't
>> > identify.
>> >
>> > Paul:
>> > What filesystem are you using?
>> >
>> > What does "mount" show?
>> >
>> > Does it work outside the chroot?
>>
>> I also see the same on the redports.org build machines.
>> It builds within a jail there which is completely on a tmpfs.
>> Interestinly everything is fine with a 10-CURRENT/amd64
>> jail but it breaks in a 10-CURRENT/i386 jail. Both are
>> running on the same 10-CURRENT/amd64 which is
>> around 2 months old.
>>
>> https://redports.org/buildarchive/20120814130205-56327/
>
> Try this.

I've seen that it was committed to head in the meantime so
I gave that a try. The problem still persists.

https://redports.org/~decke/20120827152217-19891-54992/expat-2.0.1_2.log

-- 
Bernhard Froehlich
http://www.bluelife.at/
___
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: make package fails in chroot: tar: getvfsbyname failed: No such file or directory

[Bernhard Fröhlich]

On Mon, Aug 20, 2012 at 2:31 PM, Konstantin Belousov
 wrote:
> On Mon, Aug 20, 2012 at 01:42:31PM +0200, Bernhard Fr?hlich wrote:
>> On Sun, Aug 19, 2012 at 10:01 PM, Tim Kientzle  wrote:
>> >
>> > On Aug 19, 2012, at 12:17 PM, Garrett Cooper wrote:
>> >
>> >> On Sun, Aug 19, 2012 at 9:45 AM, Tim Kientzle  wrote:
>> >>>
>> >>> On Aug 12, 2012, at 6:20 AM, Paul Schenkeveld wrote:
>> >>>
>>  Hi,
>> 
>>  I have a wrapper script that builds packages in a chroot environment
>>  which happily runs on release 6 thru 9 and earlier 10 but fails with:
>> 
>>  tar: getvfsbyname failed: No such file or directory
>> 
>>  on a recent -CURRENT.
>> >>>
>> >>> libarchive does do an initial getvfsbyname() when you ask it
>> >>> to traverse a directory tree so that it can accurately handle later
>> >>> requests about mountpoints and filesystem types.  This code
>> >>> is admittedly a little intricate.
>> >>
>> >>The problem most likely is the fact that all mountpoints are
>> >> exposed via chroot, thus, if it's checking to see if a mountpoint
>> >> exists, it may exist outside of the chroot.
>> >>
>> >
>> > I reviewed the code to refresh my memory.   Some
>> > of what I said before was not quite right.
>> >
>> > Libarchive's directory traversal tracks information about
>> > the filesystem type so that clients such as bsdtar can
>> > efficiently skip synthetic filesystems (/dev or /proc) or
>> > network filesystems (NFS or SMB mounts).
>> >
>> > The net effect is something like this:
>> >
>> >For each file:
>> >stat() or lstat() or fstat() the file
>> >look up dev number in an internal cache
>> >if the dev number is new:
>> > fstatfs() the open fd to get the FS name
>> > getvfsbyname() to identify the FS type
>> >
>> > Unless there's a logic error in libarchive itself, this
>> > would suggest that somehow fstatfs() is returning
>> > a filesystem type that getvfsbyname() can't
>> > identify.
>> >
>> > Paul:
>> > What filesystem are you using?
>> >
>> > What does "mount" show?
>> >
>> > Does it work outside the chroot?
>>
>> I also see the same on the redports.org build machines.
>> It builds within a jail there which is completely on a tmpfs.
>> Interestinly everything is fine with a 10-CURRENT/amd64
>> jail but it breaks in a 10-CURRENT/i386 jail. Both are
>> running on the same 10-CURRENT/amd64 which is
>> around 2 months old.
>>
>> https://redports.org/buildarchive/20120814130205-56327/
>
> Try this.
>
> diff --git a/sys/kern/vfs_subr.c b/sys/kern/vfs_subr.c
> index 1d6136a..631d3f2 100644
> --- a/sys/kern/vfs_subr.c
> +++ b/sys/kern/vfs_subr.c
> @@ -41,6 +41,7 @@
>  #include 
>  __FBSDID("$FreeBSD$");
>
> +#include "opt_compat.h"
>  #include "opt_ddb.h"
>  #include "opt_watchdog.h"
>
> @@ -3111,21 +3112,49 @@ DB_SHOW_COMMAND(mount, db_show_mount)
>  /*
>   * Fill in a struct xvfsconf based on a struct vfsconf.
>   */
> -static void
> -vfsconf2x(struct vfsconf *vfsp, struct xvfsconf *xvfsp)
> +static int
> +vfsconf2x(struct sysctl_req *req, struct vfsconf *vfsp)
>  {
> +   struct xvfsconf xvfsp;
>
> -   strcpy(xvfsp->vfc_name, vfsp->vfc_name);
> -   xvfsp->vfc_typenum = vfsp->vfc_typenum;
> -   xvfsp->vfc_refcount = vfsp->vfc_refcount;
> -   xvfsp->vfc_flags = vfsp->vfc_flags;
> +   bzero(&xvfsp, sizeof(xvfsp));
> +   strcpy(xvfsp.vfc_name, vfsp->vfc_name);
> +   xvfsp.vfc_typenum = vfsp->vfc_typenum;
> +   xvfsp.vfc_refcount = vfsp->vfc_refcount;
> +   xvfsp.vfc_flags = vfsp->vfc_flags;
> /*
>  * These are unused in userland, we keep them
>  * to not break binary compatibility.
>  */
> -   xvfsp->vfc_vfsops = NULL;
> -   xvfsp->vfc_next = NULL;
> +   xvfsp.vfc_vfsops = NULL;
> +   xvfsp.vfc_next = NULL;
> +   return (SYSCTL_OUT(req, &xvfsp, sizeof(xvfsp)));
> +}
> +
> +#ifdef COMPAT_FREEBSD32
> +struct xvfsconf32 {
> +   uint32_tvfc_vfsops;
> +   charvfc_name[MFSNAMELEN];
> +   int32_t vfc_typenum;
> +   int32_t vfc_refcount;
> +   int32_t vfc_flags;
> +   uint32_tvfc_next;
> +};
> +
> +static int
> +vfsconf2x32(struct sysctl_req *req, struct vfsconf *vfsp)
> +{
> +   struct xvfsconf32 xvfsp;
> +
> +   strcpy(xvfsp.vfc_name, vfsp->vfc_name);
> +   xvfsp.vfc_typenum = vfsp->vfc_typenum;
> +   xvfsp.vfc_refcount = vfsp->vfc_refcount;
> +   xvfsp.vfc_flags = vfsp->vfc_flags;
> +   xvfsp.vfc_vfsops = 0;
> +   xvfsp.vfc_next = 0;
> +   return (SYSCTL_OUT(req, &xvfsp, sizeof(xvfsp)));
>  }
> +#endif
>
>  /*
>   * Top level filesystem related information gathering.
> @@ -3134,14 +3163,16 @@ static int
>  sysctl_vfs_conflist(SYSCTL_HANDLER_ARGS)
>  {
> struct vfsconf *vfsp;
> -   struct xvfsconf xvfsp;
> int error;
>
> error = 0;
> TAILQ_FOREACH(vfsp, &vfsconf, vfc_list) {
> -   bzero(&xvf

Re: make package fails in chroot: tar: getvfsbyname failed: No such file or directory

[Bernhard Fröhlich]

On Sun, Aug 19, 2012 at 10:01 PM, Tim Kientzle  wrote:
>
> On Aug 19, 2012, at 12:17 PM, Garrett Cooper wrote:
>
>> On Sun, Aug 19, 2012 at 9:45 AM, Tim Kientzle  wrote:
>>>
>>> On Aug 12, 2012, at 6:20 AM, Paul Schenkeveld wrote:
>>>
 Hi,

 I have a wrapper script that builds packages in a chroot environment
 which happily runs on release 6 thru 9 and earlier 10 but fails with:

 tar: getvfsbyname failed: No such file or directory

 on a recent -CURRENT.
>>>
>>> libarchive does do an initial getvfsbyname() when you ask it
>>> to traverse a directory tree so that it can accurately handle later
>>> requests about mountpoints and filesystem types.  This code
>>> is admittedly a little intricate.
>>
>>The problem most likely is the fact that all mountpoints are
>> exposed via chroot, thus, if it's checking to see if a mountpoint
>> exists, it may exist outside of the chroot.
>>
>
> I reviewed the code to refresh my memory.   Some
> of what I said before was not quite right.
>
> Libarchive's directory traversal tracks information about
> the filesystem type so that clients such as bsdtar can
> efficiently skip synthetic filesystems (/dev or /proc) or
> network filesystems (NFS or SMB mounts).
>
> The net effect is something like this:
>
>For each file:
>stat() or lstat() or fstat() the file
>look up dev number in an internal cache
>if the dev number is new:
> fstatfs() the open fd to get the FS name
> getvfsbyname() to identify the FS type
>
> Unless there's a logic error in libarchive itself, this
> would suggest that somehow fstatfs() is returning
> a filesystem type that getvfsbyname() can't
> identify.
>
> Paul:
> What filesystem are you using?
>
> What does "mount" show?
>
> Does it work outside the chroot?

I also see the same on the redports.org build machines.
It builds within a jail there which is completely on a tmpfs.
Interestinly everything is fine with a 10-CURRENT/amd64
jail but it breaks in a 10-CURRENT/i386 jail. Both are
running on the same 10-CURRENT/amd64 which is
around 2 months old.

https://redports.org/buildarchive/20120814130205-56327/

-- 
Bernhard Froehlich
http://www.bluelife.at/
___
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: VirtualBox: Eating up 100% CPU, freezing Windows 7

[Bernhard Fröhlich]

On Fr.,   3. Aug. 2012 06:18:33 CEST, Kevin Oberman  wrote:

> On Thu, Aug 2, 2012 at 12:54 AM, Hartmann, O.
>  wrote:
> > I discover that when running Windows 7 in a VirtualBox On FreeBSD 10
> > (r238968: Wed Aug 1 14:26:40 CEST 2012), VBox is most recent from the
> > ports, that the VirtualBox eats up 100% CPU time and freezes Windows 7
> > for more than a minute. For a minute or so, I can work, then, the
> > freeze occurs again.
> > 
> > I can't see this behaviour with a Ubuntu Guest on the same box. Is
> > there Windows 7 specifica to be aware of?
> 
> I am seeing the same thing. Also Win7 guest with Windows showing idle
> process at 99%, but my system is showing VB at 100%. The VM is only
> running a single CPU, so FreeBSD is still running OK, but the Win7
> system seems to freeze up periodically.
> 
> 9.1-PRERELEASE on amd64 updated yesterday (though it has been this way
> since VB was updated to 4.1.18. Guest additions for 4.1.18
> installed.All ports current. I'm thinking of backing off to 4.1.16.

Can someone confirm that this is a regression in 4.1.18? Then I could talk to 
upstream and see if I can get that adressed.

-- 
http://www.bluelife.at/
___
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: Virtualbox

[Bernhard Fröhlich]

>Hi
>
>Has anyone managed to make Virtualbox work on 9-Current?  Since
>installing 3.1.2-OSE VMs, all brand new, abort on startup.
>
>The last part of the log seems pertinent:
>
>00:00:15.481 !!Assertion Failed!!
>00:00:15.481 Expression: paPages[i].Phys != 0 && paPages[i].Phys !=
NIL_RTHCPHYS && >!(paPages[i].Phys & PAGE_OFFSET_MASK)
>00:00:15.481 Location  :
/usr/ports/emulators/virtualbox-ose/work/VirtualBox-3.1.2_OSE/src/VBox
>/VMM/MMHyper.cpp(610) int MMR3HyperMapPages(VM*, void*, RTR0PTR, size_t,
const SUPPAGE*, 
>const char*, RTGCPTR64*)
>00:00:15.482 i=0x0 Phys= Heap
>
>Does anyone have any ideas?


Thanks for the report. I've talked to Alexander Eichner and he gave me a
patch that could
fix that problem. Could you please try to build the virtualbox-ose-kmod port
with that patch?
If it works we will include it in the port update coming quite soon.

http://pastebin.ca/1808090

If that does not help please create a backtrace from the vbox coredump and
send the vbox.log.

Thanks!

--
Bernhard Fröhlich
http://www.bluelife.at/
-- 
View this message in context: 
http://old.nabble.com/Virtualbox-tp27705983p27714203.html
Sent from the freebsd-current mailing list archive at Nabble.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"