from:"Volodymyr Kostyrko"

Re: gptzfsboot grew a lot after skein support was added; need knob to control bloat

2017-01-31 Thread Volodymyr Kostyrko


Shawn Webb wrote:

On Fri, Jan 27, 2017 at 12:30:17PM -0500, Allan Jude wrote:

On 2017-01-27 12:05, Warner Losh wrote:

On Fri, Jan 27, 2017 at 12:34 AM, Toomas Soome  wrote:



On 27. jaan 2017, at 1:40, Ngie Cooper (yaneurabeya)  
wrote:

Hi,
  I tried upgrading one of my workstations and unfortunately the 
freebsd-boot partition is too small (I follow manpage directions, exactly, and 
those seem to be too small as of 10.3-RELEASE timeframe), and I don???t have 
enough space or ability to resize the partition and make it bigger. So, I???m 
in need of a build knob to control the bloat, and/or having an alternative boot 
loader without geli/skein/crypto support compiled in. Would you be opposed to 
the work?
Thanks,
-Ngie



I do agree that since the geli knob is already there, it may do. Of course we 
also can think of additional knobs, but there is an issue - it wont help just 
to exclude some files, the additional features also do sit in the code, so the 
replacement stubs will be needed, also testing them all over will take some 
time. And the preprocessor spaghetti really is nasty thing to deal with;)

And then there is another issue (partly why I did the feature support in first 
place) - as the kernel does not block user from enabling the features, the user 
can end up facing non-bootable setup which is also not good, as user is using 
perfectly legal options, and still the whole thing is just rendered unusable???


I'm curious why you can't find the space for a bigger partition?
Almost all drives these days are partitioned with a little wasted
space, and that wasted space should be more than enough to cover us
here. Also, most drives have a swap partition that can be shrunk a
trivial amount to get space for this...

Warner



I need to do some testing to make a recipe that works for it, but the
other option is to use the ZFS bootcode area.

ZFS it self, reserves something like 3.5 mb of space in the ZFS
partition, for boot code. This is how we boot ZFS on MBR.

It should be possible to use this on GPT as well, we just don't.


In the future, maybe it'd be a good idea for the installer to leave
more space (a few MB, perhaps?) between the freebsd-boot and
freebsd-swap partitions? At least, for ZFS installs.


This would do anything. If you have swap after the boot partition you 
always can drop the swap, make larger boot and create the swap back on 
the free space.


--
Sphinx of black quartz judge my vow.
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: Import rcorder-visualize.sh from NetBSD?

2016-12-06 Thread Volodymyr Kostyrko


Eric van Gyzen wrote:

Would anyone object to me importing this script from NetBSD?

http://cvsweb.netbsd.org/bsdweb.cgi/~checkout~/src/sbin/rcorder/rcorder-visualize.sh?rev=1.5=text/plain

I ask in particular because of the non-BSD license.  This seems like a
no-brainer, but I'm going to play it safe and ask first.


I remember I wrote something similar for one pr.

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=200375

--
Sphinx of black quartz judge my vow.
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: External toolchain support broken for devel/llvm38 but not devel/llvm37

2016-08-30 Thread Volodymyr Kostyrko


Matthew Macy wrote:

It looks like there is something broken with the devel/llvm38 port or external 
toolchain support has regressed:


This works:
make  XCC=/usr/local/bin/clang37 XCXX=/usr/local/bin/clang++37 
XCPP=/usr/local/bin/clang-cpp37  buildworld -j12 -s

This fails:
  make  XCC=/usr/local/bin/clang38 XCXX=/usr/local/bin/clang++38 
XCPP=/usr/local/bin/clang-cpp38 buildworld -j12 -s

with:

/home/mmacy/devel/build/mnt/storage/mmacy/devel/drm-next-merge/tmp/usr/bin/ld: 
/usr/local/llvm38/bin/../lib/clang/3.8.1/lib/freebsd/libclang_rt.ubsan_standalone-x86_64.a:
 No such file: No such file or directory
clang-3.8: error: linker command failed with exit code 1 (use -v to see 
invocation)


I second this - I also faced it. I think this is not a problem with a 
ports but rather with a build as correspondent files can be found in 
/usr/obj under /usr/obj/usr/src/tmp/usr/lib/clang/3.8.0/lib/freebsd/. 
Looks like this files are compiled during build but taken from 
compilers's directory. Linking 'em to the target directory makes build 
succeed.


--
Sphinx of black quartz judge my vow.
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

[patch] bug 187081 (swaplate fix)

2015-10-19 Thread Volodymyr Kostyrko


Hi all.

I recently added my own patch to bug 
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=187081


Can anyone take a look?

--
Sphinx of black quartz judge my vow.
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: boot failure after upgrade to HEAD from svn: zfs i/o error - all block copies unavailable invalid format

2013-12-12 Thread Volodymyr Kostyrko


10.12.2013 18:59, 乔楚 wrote:

*Today, after **upgrade to HEAD from svn, My FreeBSD can't boot.*

*Error message:*

*ZFS: i/o error all block copies unavailable
**Invalid format*


I see you are using GPT. Have you updated bootcode then? Can you import 
your pool from any HEAD snapshot?


--
Sphinx of black quartz, judge my vow.
___
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: lang/gcc not build

2013-11-28 Thread Volodymyr Kostyrko


26.11.2013 19:47, Alexander Panyushkin wrote:

#portmaster lang/gcc
[...]
cd /usr/ports/lang/gcc/work/gcc-4.6.4 ; contrib/gcc_update --touch
configure: loading site script /usr/ports/Templates/config.site
checking build system type... x86_64-portbld-freebsd10.0
checking host system type... x86_64-portbld-freebsd10.0
checking target system type... x86_64-portbld-freebsd10.0
checking for a BSD-compatible install... /usr/bin/install -c -o root -g
wheel
checking whether ln works... yes
checking whether ln -s works... yes
checking for a sed that does not truncate output... (cached) /usr/bin/sed
checking for gawk... (cached) /usr/bin/awk
checking for gcc... gcc46
checking for C compiler default output file name...
configure: error: in `/usr/ports/lang/gcc/work/build':
configure: error: C compiler cannot create executables
See `config.log' for more details.
===  Script ../gcc-4.6.4/configure failed unexpectedly.
Please report the problem to ger...@freebsd.org [maintainer] and attach the
/usr/ports/lang/gcc/work/build/config.log including the output of the
failure
of your make command. Also, it might be a good idea to provide an overview
of all packages installed on your system (e.g. a /usr/local/sbin/pkg-static
info -g -Ea).
*** Error code 1

#
/etc/make.conf

..if ${.CURDIR:N*/ports/lang/gcc*} == 
CFLAGS= -O2 -march=athlon64-sse3 -mtune=athlon64-sse3 -pipe -Wformat
CPPFLAGS+= -D_FORTIFY_SOURCE=2
USE_GCC=4.6
..endif


Added this to my make.conf and tested - WFM. The problem is not there. 
Can you post a sample of /usr/ports/lang/gcc/work/build/config.log as 
log suggests?


PS: CFLAGS= is a bit rough thing to have, CFLAGS+= would be much better.

PPS: clang is mature enough and works correctly with CPUTYPE?=native so 
-march and -mtune can be substituted for that one.


--
Sphinx of black quartz, judge my vow.
___
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: cron(8) improvement

2013-11-06 Thread Volodymyr Kostyrko


05.11.2013 20:21, Mark Felder wrote:



On Tue, Nov 5, 2013, at 11:37, Nikolai Lifanov wrote:

On 11/05/13 12:31, Allan Jude wrote:

This came up in discussion on IRC and I thought I should throw it at the
list so I don't forget.

A user was asking how to do what linux cron does, where there is a
directory /etc/cron.d/ that packages and add files to to create crontabs.

Making FreeBSD's cron (Vixie Cron) include /etc/cron.d/ and
/usr/local/etc/cron.d/ in the /etc/crontab format seems like a very
useful feature, especially for pkg(8) as it makes it easy and safe to
programatically add and remove crontabs as part of a package.




Shouldn't we encourage packages to use periodic(8) when possible?



Yes but our default periodic configuration in /etc/crontab is only
configured to be as granular as daily. If this is something that should
run hourly or at very strange intervals then cron is a better choice.


So why we shouldn't add something like:

0 * * * * root periodic hourly
@reboot root periodic reboot

I already do this on some machines to take hourly and boot snapshots 
with zfSnap. And I think periodic is much better place for such tasks.


--
Sphinx of black quartz, judge my vow.
___
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

bmake vs fmake - ports-mgmt/portconf fails to work

2013-10-22 Thread Volodymyr Kostyrko


Hi all.

I'm playing with 10 beta1 and found that:

/usr/ports/editors/vim# make
make: /etc/make.conf line 17: warning: WITH_BDB_VER=5
make: /etc/make.conf line 18: Need an operator
make: /etc/make.conf line 17: warning: 
_JAVA_PREFERRED_PORTS=JAVA_PORT_NATIVE_OPENJDK_JDK_1_7

make: /etc/make.conf line 18: Need an operator
make: /etc/make.conf line 17: warning: 
GHOSTSCRIPT_PORT=print/ghostscript9

make: /etc/make.conf line 18: Need an operator
make: /etc/make.conf line 17: warning: WITH_CCACHE_BUILD=
make: /etc/make.conf line 18: Need an operator
make: /etc/make.conf line 17: warning: WITHOUT_X11=
make: /etc/make.conf line 18: Need an operator

# fmake
/etc/make.conf, line 17: warning: WITH_BDB_VER=5
/etc/make.conf, line 17: warning: 
_JAVA_PREFERRED_PORTS=JAVA_PORT_NATIVE_OPENJDK_JDK_1_7

/etc/make.conf, line 17: warning: GHOSTSCRIPT_PORT=print/ghostscript9
/etc/make.conf, line 17: warning: WITH_CCACHE_BUILD=
/etc/make.conf, line 17: warning: WITHOUT_X11=

The offending code looks like:

# Begin portconf settings
# Do not touch these lines
.if !empty(.CURDIR:M/usr/ports*)  exists(/usr/local/libexec/portconf)
_PORTCONF!=/usr/local/libexec/portconf
.for i in ${_PORTCONF:S/|/ /g}
.warning ${i:S/%/ /g}
${i:S/%/ /g} # - here is the error
.endfor
.endif
# End portconf settings

Looks like bmake doesn't allow to insert variable definition from 
another variable.


--
Sphinx of black quartz, judge my vow.
___
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

2013-08-23 Thread Volodymyr Kostyrko


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


--
Sphinx of black quartz, judge my vow.
___
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: ports/177488: qemu-1.4

2013-04-01 Thread Volodymyr Kostyrko


2013-03-30 10:23, Juergen Lock wrote:

disable some unneeded function, and make qemu 1.4 compilable on FreeBSD 9.1



I think you are building qemu git head as the hexdump function at least
isn't in 1.4.0?  Anyway I have meanwhile updated the qemu-devel port
to 1.4.0 with some similar patches to yours and (among other things)
preliminary bsd-user improvements mostly by ssson and cognet, will
leave the PR open for when I need the hexdump patch for a future
update.


Doesn't build WITHOUT_CURL:

block/qcow.o: In function `encrypt_sectors':
/tmp/ports/usr/ports/emulators/qemu-devel/work/qemu-1.4.0/block/qcow.c:250: 
undefined reference to `AES_cbc_encrypt'

block/qcow2-cluster.o: In function `qcow2_encrypt_sectors':
/tmp/ports/usr/ports/emulators/qemu-devel/work/qemu-1.4.0/block/qcow2-cluster.c:309: 
undefined reference to `AES_cbc_encrypt'

gmake: *** [qemu-nbd] Помилка 1
gmake: *** Очікування завершення завдань...
block/qcow.o: In function `encrypt_sectors':
/tmp/ports/usr/ports/emulators/qemu-devel/work/qemu-1.4.0/block/qcow.c:250: 
undefined reference to `AES_cbc_encrypt'

block/qcow2-cluster.o: In function `qcow2_encrypt_sectors':
/tmp/ports/usr/ports/emulators/qemu-devel/work/qemu-1.4.0/block/qcow2-cluster.c:309: 
undefined reference to `AES_cbc_encrypt'


--
Sphinx of black quartz, judge my vow.
___
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: CURRENT: lang/gcc fails to build on CURRENT with error: configure: error: no usable dependency style found

2013-03-11 Thread Volodymyr Kostyrko


11.03.2013 18:57, O. Hartmann пишет:

On Mon, 2013-03-11 at 17:29 +0100, Dimitry Andric wrote:

On 2013-03-11 14:15, Niclas Zeising wrote:



BSD grep does something very strange here:

$ echo 'foo.bar' | grep foo.bar
foo.bar
$ echo 'foo.barx' | grep foo.bar
foo.barx
$ echo 'sub/foo.bar' | grep sub/foo.bar
sub/foo.bar
$ echo 'sub/foo.barx' | grep sub/foo.bar
$ echo $?
1

So why does it not match in the last case?  GNU grep works:

$ echo 'sub/foo.barx' | gnugrep sub/foo.bar
sub/foo.barx


After disabling WITH_BSD_GREP and rebuild of the system, it seems that
the machines in question now build lang/gcc.




So how about resurrecting 
http://www.freebsd.org/cgi/query-pr.cgi?pr=bin/167921 ? Looks like 
BSD_GREP still has some problems with slashes.


http://scan.freebsd.your.org/freebsd-head/usr.bin.grep/2013-03-10-amd64/ 
has some good pointers on where to start. I'm not that familiar with C 
to dive in.


--
Sphinx of black quartz, judge my vow.
___
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: Circular port dependency

2013-01-11 Thread Volodymyr Kostyrko


11.01.2013 03:21, George Mitchell:

I grabbed the ports tree as of 308518, the RELEASE_9_1_0 tag.


The current and supported version of ports is HEAD.


devel/libtool won't build, because it requires autom4te during the


Can you provide some logs showing how it can't be built?


configure phase.  So I put BUILD_DEPENDS= autom4te:devel/autoconf
in the Makefile.  But autoconf depends on gmake, which depends on
gettext, which depends on libiconv, which depends on libtool.
What to do?


--
Sphinx of black quartz, judge my vow.
___
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: clang compiled kernel panic when mounting zfs root on i386

2012-12-20 Thread Volodymyr Kostyrko


18.12.2012 00:20, Andriy Gapon:

It's been already mentioned many times that ZFS works much better on amd64.
It's up to a (potential) user to understand limitations of i386 and to decide
whether to use ZFS, in what situations and how.

You may want to consider using KSTACK_PAGES=4 in your kernel configuration.


For last two fays my system seems stable on kernel compiled with 
KSTACK_PAGES=4 and WITH_CLANG_IS_CC.


--
Sphinx of black quartz, judge my vow.
___
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: clang compiled kernel panic when mounting zfs root on i386

2012-12-17 Thread Volodymyr Kostyrko


13.12.2012 12:25, Andriy Gapon:

on 12/12/2012 21:35 Dimitry Andric said the following:

Especially the recursive spa_load and traverse_visitbp calls are scary,
because that can grow out of hand very quickly.  It is probably tricky
to remove the recursion...


Re-entering spa_load once is normal and is expected.
traverse_visitbp is also expected to recurse depending on data layout.
So yeah, it's probably even trickier than teaching clang to allocate smaller 
stack
frames ;-)


I hit this one again, but this time my world and kernel are compiled 
with stock gcc. Pictures 3 to 5:


https://picasaweb.google.com/104021007361271711472/I386ZfsDoubleFault

This happens on mounting root after unclean shutdown. I fixed my pool 
with booting amd64 kernel, after this i386 kernel starts fine.


Maybe it's just time to accept that ZFS on i386 is not stable? Current 
handbook elaborates on ZFS like it's known to work on i386.


--
Sphinx of black quartz, judge my vow.
___
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: clang compiled kernel panic when mounting zfs root on i386

2012-12-13 Thread Volodymyr Kostyrko


12.12.2012 21:35, Dimitry Andric:

On 2012-12-12 14:04, Volodymyr Kostyrko wrote:

04.12.2012 00:41, Konstantin Belousov:

Please try the patch below. It might give an immediate relief, but still
there are many offenders in the backtrace.


I'm having almost the same issue and the patch doesn't work for me.

...

Looking at the stack frame addresses, it seems some of them are mangled.
Did you type this by hand? The differences between subsequent frames
are a bit strange because of it (and because of awk's integer
processing):


Yes, I had typed that by hand. I attached link to the pictures just in case.


The kernel stack is just 8,192 bytes; since you can see these routines
are all consuming massive amounts of stack, and the calls are very
deeply nested, it is almost inevitable that it would crash.

Especially the recursive spa_load and traverse_visitbp calls are scary,
because that can grow out of hand very quickly.  It is probably tricky
to remove the recursion...


After playing more with this kernel I also found it can crash not only 
by this scenario. There are different possible ways.


I actually don't think there's a point fixing it right now. New clang is 
coming anyway...


--
Sphinx of black quartz, judge my vow.
___
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: clang compiled kernel panic when mounting zfs root on i386

2012-12-12 Thread Volodymyr Kostyrko


04.12.2012 00:41, Konstantin Belousov:

Please try the patch below. It might give an immediate relief, but still
there are many offenders in the backtrace.


I'm having almost the same issue and the patch doesn't work for me.

Trying to mount root from zfs:limb0 []...

Fatal double fault:
eip = 0x835a6bce
esp = 0x875c2fd4
ebp = 0x875c3018
cpuid = 0; apic id = 00
panic: double fault
cpuid = 0
KDB: stack backtrace:
db_trace_self_wrapper(8380283b,20646920,3030203d,3831000a,a3a000a,...) 
at db_trace_self_wrapper+0x36/frame 0x83a10f10
kdb_backtrace(8383658f,0,83837c3d,83a10fc0,0,...) at 
kdb_backtrace+0x30/frame 0x83a10f70

panic(83837c3d,0,0,0,875c3018,...) at panic+0x1bc/frame 0x83a10fb4
dblfault_handler() at cpu_fetch_syscall_args/frame 0x83a10fb4
--- trap 0x17, eip = 8x835a6bce, esp = 0x875c2fd4, ebp = 0x875c3018 ---
witness_checkorder(843df808,9,8382a15c,7dd,0,...) at 
witness_checkorder+0x2e/frame 0x875c3018
_mtx_lock_flags(843df808,0,8382a15c,7dd,202,...) at 
_mtx_lock_flags+0x7a/frame 0x875c3040
uma_zalloc_arg(843de960,0,102,2,2,...) at uma_zalloc_arg+0x5df/franc 
0x875c3090
malloc(38,83d03100,102,875c3138,83c01d1a,...) at malloc+0xe9/frame 
0x875c30c0
zfs_kmem_alloc(38,102,8,83cab2fe,157,...) at zfs_kmem_alloc+0x20/frame 
0x875c30d4
vdev_mirror_io_start(87e3eb20,10,B7e3eb20,1,87d3f618,...) at 
vdev_mirror_io_start+0x14a/frame 0x875c3138
zio_vdev_io_start(87e3eb20,8795dbcO,87e3eb20,875c3340,200,...) at 
zio_vdev_io_start+0x1a6/frame Ox875c3180
zio_execute(87e3eb20.87c8f000,880a0640,8807d400,200,...) at 
zio_execute+0x103/frame 0x875c31b0
spa_load_verify_cb(87c8f000,0,880a0640,87f7b708,875c3340,...) at 
spa_load_verify_cb+0x89/frame 0x875c31f0
traverse_visitbp(87f7b708,880a0640,875c3340,875c3db8,0,...) at 
traverse_visitbp+0x1e6/frame 0x875c3320
traverse_dnode(87f7b708,15,0,3,O,...) at traverse_dnode+0x92/frame 
0x875c337O
traverse_visitbp(87f7b6cc,880a4000,875c3520,87f7b744,83b92d10,...) at 
traverse_visitbp+0xc40/frame 0x875c34a0
traverse_visitbp(87f7b744,88096000,875c3650,87f7b834,83b92d10,...) at 
traverse_visitbp+0xd33/frame 0xB75c35d0
traverse_visitbp(87f7b834,88074000,875c3780,87f7b8ac,83b92d10,...) at 
traverse_visitbp+0xd33/frame 0x875c3700


traverse_visitbp(87f7b8ac,8806c000,875c38b0,87f7b924,83b92d10,...) at 
traverse_visitbp+0xd33/frame 0x875c3830
traverse_visitbp(87f7b924,88064000,875c39e0,87f7b99c,83b92d10,...) at 
traverse_visitbp+0xd33/frame 0x875c3960
traverse_visitbp(87f7b99c,87fce000,875c3b10,87f7ba14,83b92d10,...) at 
traverse_visitbp+0xd33/frame 0x875c3a90
traverse_visitbp(87f7ba14,88061040,875c3be0,875c3db8,0,...) at 
traverse_visitbp+0xd33/frame 0x875c3bc0
traverse_dnode(87f7ba14,15,0,0,0,...) at traverse_dnode+0x92/frame 
0x875c3c10
traverse_visitbp(0,87f8ee80,875c3d68,2,834,...) at 
traverse_visitbp+0x822/frame 0x875c3d40
traverse_impl(15,0,87f8ee80,261400,0,...) at traverse_impl+0x268/frane 
0x875c3df0
traverse_pool(87c8f000,261400,0,d,83bec290,...) at 
traverse_pool+0x273/frame 0x875c3e90

spa_load(0,1,875c4034,83ca82f2,8,...) at spa_load+0x1d8f/frame 0x875c3fa8
spa_load(0,0,83a48934,1,14,...) at spa_load+0x114c/frame 0x875c40c0
spa_load_best(0,,,1,0,...) at spa_load_best+0x71/frame 
0x875c3e90
spa_open_common(83ca3ca6,0,0,875c42f0,83bb9dec,...) at 
spa_open_common+0x11a/frame 0x875c4174
spa_open(875c41e0,875c41dc,83ca3ca6,0,0,...) at spa_open+0x27/frame 
0x875c4188
dsl_dir_open_spa(0,87d47350,83ca4039,875c4358,875c4354,...) at 
dsl_dir_open_spa+0x6c/frame 0x875c42f0
dsl_dataset_hold(87d47350,87a36000,875c43a0,87a36000,87a36000,...) at 
dsl_data_hold+0x3a/frame 0x875c436c
dsl_dataset_own(87d47350,0,87a3600,875c43a0,83d01e30,...) at 
dsl_dataset_own+0x21/frame 0x875c4388
dmu_objset_own(87d4350,2,1,87a36000,875c43f0,...) at 
dmu_objset_own+0x2a/frame 0x875c43b0
zfsvfs_create(87d47350,875c4504,83cb0b68,68e,87d47350,...) at 
zfsvfs_create+0x4c/frame 0x875c4400
zfs_mount(87d40ce4,83cb5Bd0,87d46300,87957500,8384fd28,...) at 
zfs_mount+0x4a9/frame 0x875c4630
vfs_donmount(8795dbc0,4000,0,875c48b8,87d46380,...) at 
vfs_donmount+0xc94/frame 0x875c48a0
kernel_mount(87d473d0,4000,0,0,839de044,...) at kernel_mount+0x6b/frame 
0x875c48e0
parse_mount(87d47400,8385a800,0,1,0,...) at parse_mount+0x622/frame 
0x875c49f8
vfs_mountroot(83a491c4,4,837f68a2,2ba,0,...) at 
vfs_mountroot+0x6f1/frame 0x875c4c60
start_init(0,875c4d08,837f8f83,3d8,0,...) at start_init+0x6a/frame 
0x875c4ccc

fork_exit(835107b0,0,875c4d08) at fork_init+0x7c/frame 0x875c4cf4
fork_trampoline() at fork_trampoline+0x8/frame 0x875c4cf4
--- trap 0, eip = 0, esp = 0x875c4d40, ebp = O ---
KDB: enter: panic
[ thread pid 1 tid 12 J
Stopped at kdb_enter+0x3d: movl $O,kdb_why
db

Source pictures are at 
https://picasaweb.google.com/104021007361271711472/I386ZfsDoubleFault?authuser=0feat=directlink

just in case I missed something.

--
Sphinx of black quartz, judge my vow.
___
freebsd-current@freebsd.org mailing list

Re: No ATA disks on 9.1-RC3

2012-11-19 Thread Volodymyr Kostyrko


19.11.2012 10:24, Alex Keda wrote:

ada0 at ahcich0 bus 0 scbus0 target 0 lun 0
ada0: WDC WD1600BEVT-00A0RT0 01.01A01 ATA-8 SATA 2.x device
ada0: 300.000MB/s transfers (SATA 2.x, UDMA6, PIO 8192bytes)
ada0: Command Queueing enabled
ada0: 152627MB (312581809 512 byte sectors: 16H 63S/T 16383C)
ada0: Previously was known as ad4


Looking for this one? ATA_CAM was made default for now.

--
Sphinx of black quartz, judge my vow.
___
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: No ATA disks on 9.1-RC3

2012-11-19 Thread Volodymyr Kostyrko


19.11.2012 10:59, Volodymyr Kostyrko wrote:

19.11.2012 10:24, Alex Keda wrote:

ada0 at ahcich0 bus 0 scbus0 target 0 lun 0
ada0: WDC WD1600BEVT-00A0RT0 01.01A01 ATA-8 SATA 2.x device
ada0: 300.000MB/s transfers (SATA 2.x, UDMA6, PIO 8192bytes)
ada0: Command Queueing enabled
ada0: 152627MB (312581809 512 byte sectors: 16H 63S/T 16383C)
ada0: Previously was known as ad4


Looking for this one? ATA_CAM was made default for now.


Damn I'm sorry. Looks like I need my coffee back...

The change actually is at:

 ahci0: ATI IXP600 AHCI SATA controller port 
0x9000-0x9007,0x9008-0x900b,0x9010-0x9017,0x5018-0x501b,0x5020-0x502f 
mem 0xd0409000-0xd04093ff irq 16 at device 18.0 on pci0

 ahci0: AHCI v1.10 with 4 3Gbps ports, Port Multiplier not supported

and

 ahci0: ATI IXP600 AHCI SATA controller port 
0x9000-0x9007,0x9008-0x900b,0x9010-0x9017,0x5018-0x501b,0x5020-0x502f 
mem 0xd0409000-0xd04093ff irq 16 at device 18.0 on pci0

 ioapic0: routing intpin 16 (PCI IRQ 16) to lapic 0 vector 52
 ahci0: AHCI v0.00 with 1 ?Gbps ports, Port Multiplier not supported 
with FBS

 ahci0: Caps: ?Gbps FBS 2cmd 1ports

The bad thing about that is that there was no major rewrite of ahci code 
in this timeframe. There are some point that can be checked though:


1. What is your BIOS settings for controller? Can you try switching it 
between Legacy/Compatible mode? There was a change that fixed behavior 
for detecting different BIOS settings.


2. You can try using modular driver for this one, this means adding this 
to kernel:


nodevice ata
device atacore
device ataati
device ataahci

--
Sphinx of black quartz, judge my vow.
___
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: No ATA disks on 9.1-RC3

2012-11-19 Thread Volodymyr Kostyrko


19.11.2012 15:01, Alex Keda wrote:

It's not build
config:
===
root@HP:/usr/src # vim /usr/src/sys/amd64/conf/HP
#
include GENERIC
ident HPKERNEL

nodevice ata
nodevice siis
device atacore
device ataati
device ataahci


Looks like I have missed `device atapci` here.


=

error:
=
MAKE=make sh /usr/src/sys/conf/newvers.sh HPKERNEL
/usr/local/bin/svnversion
cc -c -O2 -frename-registers -pipe -fno-strict-aliasing -std=c99 -g
-Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes
-Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef
-Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs
-fdiagnostics-show-option -nostdinc -I. -I/usr/src/sys
-I/usr/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS
-include opt_global.h -fno-common -finline-limit=8000 --param
inline-unit-growth=100 --param large-function-growth=1000
-fno-omit-frame-pointer -mcmodel=kernel -mno-red-zone -mno-mmx -mno-sse
-msoft-float -fno-asynchronous-unwind-tables -ffreestanding
-fstack-protector vers.c
linking kernel.debug
ata-ahci.o: In function `ata_ahci_ata_attach':
/usr/src/sys/dev/ata/chipsets/ata-ahci.c:128: undefined reference to
`ata_pci_ch_attach'


--
Sphinx of black quartz, judge my vow.
___
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: No ATA disks on 9.1-RC3

2012-11-19 Thread Volodymyr Kostyrko


19.11.2012 15:59, Alex Keda wrote:

19.11.2012 17:18, Volodymyr Kostyrko пишет:

19.11.2012 15:01, Alex Keda wrote:

It's not build
config:
===
root@HP:/usr/src # vim /usr/src/sys/amd64/conf/HP
#
include GENERIC
ident HPKERNEL

nodevice ata
nodevice siis
device atacore
device ataati
device ataahci


Looks like I have missed `device atapci` here.

OK, I rebuild kernel - no happy - error remains


So this is rather IXP600 support problem, try hitting freebsd-stable 
or... freebsd-hardware?


--
Sphinx of black quartz, judge my vow.
___
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: Buying recommendation for silent router/fileserver

2012-10-12 Thread Volodymyr Kostyrko


11.10.2012 17:54, Ulrich Spörlein wrote:

Hey guys,

I need to replace an aging Pentium IV system that has been serving as my
router, access point, file- and mediaserver for quite some time now. The
replacement should have:

- amd64 CPU (for ZFS, obviously)
- 2x GigE (igress, egress interfaces)
- some form of wlan interface (I currently use an Atheros based PCI card)
- eSATA for attaching a backup disk where I stream ZFS snapshots to
- serial port is always nice, for when I mess up an upgrade
- fan-less if possible

So far, this here seems to fit the bill perfectly
http://www.fit-pc.com/web/fit-pc/intensepc/
but pricing seems to defy any reality.

It does not state directly which chipsets are used for Wifi and
Ethernet, the block diagram claims Ethernet chips to be Intel 82579 and
RTL8111D, but I don't trust that fully.

For Wifi I can always fall back to sticking in a supported USB stick,
although that's kinda hacky.

So how well is networking going to be supported by FreeBSD? Should I
just bite the bullet and find out?


Why not trying to look at cheap barebones or desktop PC's?

http://www.silentpcreview.com/Sapphire_Edge_HD3
http://www.newegg.com/Product/Product.aspx?Item=N82E16856119070

They are cheaper, hold much better processors for ZFS and can be 
upgraded with extra GigE/eSATA interfaces by USB3.


--
Sphinx of black quartz, judge my vow.
___
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: [HEADSUP] Upcoming GNU sort removal

2012-10-05 Thread Volodymyr Kostyrko


04.10.2012 13:53, Gabor Kovesdan wrote:

it has been more than 3 months ago that BSD sort became default in HEAD
and no serious complaints have been raised against it since then so I
plan to permanently remove GNU sort from head in the next days. If you
have any objection, please raise it now.


http://scan.freebsd.your.org/freebsd-head/usr.bin.grep/2012-01-12-amd64/

/usr/src/usr.bin/grep/regex/xmalloc.c:341:7: warning: Use of memory 
after it is freed

  hash_table_del(xmalloc_table, ptr);
  ^ ~~~
1 warning generated.

/usr/src/usr.bin/grep/regex/tre-fastmatch.c:534:3: warning: Result of 
'malloc' is converted to a pointer of type 'unsigned int', which is 
incompatible with sizeof operand type 'int'

  FILL_BMGS;
  ^
/usr/src/usr.bin/grep/regex/tre-fastmatch.c:343:19: note: expanded from 
macro 'FILL_BMGS'

  fg-sbmGs = xmalloc(fg-len * sizeof(int));   \
  ^
/usr/src/usr.bin/grep/regex/xmalloc.h:69:23: note: expanded from macro 
'xmalloc'

#define xmalloc(size) malloc(size)
  ^~ 
/usr/src/usr.bin/grep/regex/tre-fastmatch.c:537:3: warning: Result of 
'malloc' is converted to a pointer of type 'unsigned int', which is 
incompatible with sizeof operand type 'int'

  FILL_BMGS_WIDE;
  ^~
/usr/src/usr.bin/grep/regex/tre-fastmatch.c:359:18: note: expanded from 
macro 'FILL_BMGS_WIDE'

  fg-bmGs = xmalloc(fg-wlen * sizeof(int));   \
 ^
/usr/src/usr.bin/grep/regex/xmalloc.h:69:23: note: expanded from macro 
'xmalloc'

#define xmalloc(size) malloc(size)
  ^~ 
/usr/src/usr.bin/grep/regex/tre-fastmatch.c:707:3: warning: Memory is 
never released; potential leak of memory pointed to by 'tmp'

  STORE_MBS_PAT;
  ^
/usr/src/usr.bin/grep/regex/tre-fastmatch.c:97:14: note: expanded from 
macro 'STORE_MBS_PAT'

  return REG_ESPACE;\
 ^~
/usr/src/usr.bin/grep/regex/tre-fastmatch.c:766:3: warning: Result of 
'malloc' is converted to a pointer of type 'unsigned int', which is 
incompatible with sizeof operand type 'int'

  FILL_BMGS;
  ^
/usr/src/usr.bin/grep/regex/tre-fastmatch.c:343:19: note: expanded from 
macro 'FILL_BMGS'

  fg-sbmGs = xmalloc(fg-len * sizeof(int));   \
  ^
/usr/src/usr.bin/grep/regex/xmalloc.h:69:23: note: expanded from macro 
'xmalloc'

#define xmalloc(size) malloc(size)
  ^~ 
/usr/src/usr.bin/grep/regex/tre-fastmatch.c:769:3: warning: Result of 
'malloc' is converted to a pointer of type 'unsigned int', which is 
incompatible with sizeof operand type 'int'

  FILL_BMGS_WIDE;
  ^~
/usr/src/usr.bin/grep/regex/tre-fastmatch.c:359:18: note: expanded from 
macro 'FILL_BMGS_WIDE'

  fg-bmGs = xmalloc(fg-wlen * sizeof(int));   \
 ^
/usr/src/usr.bin/grep/regex/xmalloc.h:69:23: note: expanded from macro 
'xmalloc'

#define xmalloc(size) malloc(size)
  ^~ 
5 warnings generated.

How about fixing http://www.freebsd.org/cgi/query-pr.cgi?pr=bin/167921 ?

 /usr/bin/grep 
/tmp/ports/.amd_mnt/faz/host/usr/ports/textproc/docbook-410/work/\\.

Segmentation fault (core dumped)

 uname -a
FreeBSD ar1l0u 9.1-PRERELEASE FreeBSD 9.1-PRERELEASE #0 r241156M: Wed 
Oct  3 13:58:16 EEST 2012 arcade@ar1l0u:/usr/obj/usr/src/sys/MINIMAL 
 amd64


 gdb /usr/obj/usr/src/usr.bin/grep/grep grep.core
GNU gdb 6.1.1 [FreeBSD]
Copyright 2004 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain 
conditions.

Type show copying to see the conditions.
There is absolutely no warranty for GDB.  Type show warranty for details.
This GDB was configured as amd64-marcel-freebsd...(no debugging 
symbols found)...

Core was generated by `grep'.
Program terminated with signal 11, Segmentation fault.
Reading symbols from /lib/libz.so.6...(no debugging symbols found)...done.
Loaded symbols for /lib/libz.so.6
Reading symbols from /usr/lib/liblzma.so.5...(no debugging symbols 
found)...done.

Loaded symbols for /usr/lib/liblzma.so.5
Reading symbols from /usr/lib/libbz2.so.4...(no debugging symbols 
found)...done.

Loaded symbols for /usr/lib/libbz2.so.4
Reading symbols from /usr/lib/libgnuregex.so.5...(no debugging symbols 
found)...done.

Loaded symbols for /usr/lib/libgnuregex.so.5
Reading symbols from /lib/libc.so.7...(no debugging symbols found)...done.
Loaded symbols for /lib/libc.so.7
Reading symbols from /libexec/ld-elf.so.1...(no debugging symbols 
found)...done.

Loaded symbols for /libexec/ld-elf.so.1
#0  0x004069d2 in tre_compile_fast ()
(gdb) bt full
#0  0x004069d2 in tre_compile_fast ()
No symbol table info available.
#1  0x00404d06 in tre_fastncomp ()
No symbol table

Re: [HEADSUP] Upcoming GNU sort removal

2012-10-05 Thread Volodymyr Kostyrko


05.10.2012 13:57, Volodymyr Kostyrko wrote:

04.10.2012 13:53, Gabor Kovesdan wrote:

it has been more than 3 months ago that BSD sort became default in HEAD
and no serious complaints have been raised against it since then so I
plan to permanently remove GNU sort from head in the next days. If you
have any objection, please raise it now.


http://scan.freebsd.your.org/freebsd-head/usr.bin.grep/2012-01-12-amd64/


Please excuse me for this, I misread the subject.

--
Sphinx of black quartz, judge my vow.
___
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 development audio system: KLANG

2012-08-13 Thread Volodymyr Kostyrko


O. Hartmann wrote:

A few days ago, I stumbled into sthis at Phoronix:

http://www.phoronix.com/scan.php?page=news_itempx=MTE1NzY

KLANG is supposed to be an exchange audio system for the kernel,
replacing several userland backed systems. Phoronix also claims this
approach is supposed to support the FreeBSD kernel and yes, I'd like to
see something been developed not even for Linux these days.

On the website of KLANG, located here,

http://klang.eudyptula.org/

I couldn't find much of information regarding FreeBSD.

But I'd like to draw attention towards this for FreeBSD people, if they
didn't already have noticed. It is like in science - no spreading of
informations makes it hard to discover what's going on ...


I think the main problems with this one would be:

1. It's targeted at fixing Linux bugs, not FreeBSD ones. FreeBSD sound 
system had in-kernel virtual channel mixing support for years.


2. It's claiming very spurious tasks like adding full audio routing 
support like JACK does. I personally think that most users doesn't need 
it and I can't really say who and how will benefit of this.


3. What drivers would be supported? FreeBSD OSS and ALSA still have 
working support for Aureal Vortex despite those ones were already 
dropped at OSS4. How long it will take to support at least 50% of 
hardware list?


4. Where is source?

Anyway, good luck to them.

--
Sphinx of black quartz judge my vow.
___
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: New Xorg: graphics/dri: fails to compile with CLANG: nouveau_array.c:49:16: error: illegal storage class on function, *extract_u = EXTRACT(char, unsigned, 1);

2012-05-28 Thread Volodymyr Kostyrko


Dimitry Andric wrote:

On 2012-04-28 13:12, Volodymyr Kostyrko wrote:

O. Hartmann wrote:

Is there in official way to get this fixed with CLANG? I see that
files folder in graphics/dri is missing, so none of the  fixes for both
the faulty source files


I think the patch should go to graphics/libGL.

cd /usr/ports/graphics/libGL/files
fetch -rao -
'http://cgit.freedesktop.org/mesa/mesa/patch/?id=4aa1ac5fe94b5696095229ee3568bf4fa7cfed95'
| sed -e 's|^--- a/src|--- src|' -e 's|^+++ b/src|+++ src|'  patch-nouveau

Should do.


Please try this patch (lightly tested):

http://www.andric.com/freebsd/clang/clangports-graphics-libGL-3.diff


Works for me. Could this one be commited? It looks better then my quick 
hack.


--
Sphinx of black quartz judge my vow.
___
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

does anyone care about periodic scripts?

2012-05-07 Thread Volodymyr Kostyrko


Hi all.

It seems that patches to periodic scripts have hard time coming into the 
tree. I personally filed 
http://www.freebsd.org/cgi/query-pr.cgi?pr=conf/165817 and still there's 
no move despite change is purely cosmetical and just fixes right way of 
things.


And this is not just one and only case, pr's are numerous and get 
minimal to no attention at all:


http://www.freebsd.org/cgi/query-pr.cgi?pr=conf/165956

http://www.freebsd.org/cgi/query-pr.cgi?pr=conf/30938

How can I assist with this pr's? Whom should I bug to get some answer 
about them?


--
Sphinx of black quartz judge my vow.
___
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: New Xorg: graphics/dri: fails to compile with CLANG: nouveau_array.c:49:16: error: illegal storage class on function, *extract_u = EXTRACT(char, unsigned, 1);

2012-04-28 Thread Volodymyr Kostyrko


O. Hartmann wrote:

Is there in official way to get this fixed with CLANG? I see that
files folder in graphics/dri is missing, so none of the  fixes for both
the faulty source files


I think the patch should go to graphics/libGL.

cd /usr/ports/graphics/libGL/files
fetch -rao - 
'http://cgit.freedesktop.org/mesa/mesa/patch/?id=4aa1ac5fe94b5696095229ee3568bf4fa7cfed95' 
| sed -e 's|^--- a/src|--- src|' -e 's|^+++ b/src|+++ src|'  patch-nouveau


Should do.

--
Sphinx of black quartz judge my vow.
___
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: About kern.ipc.semmap on FreeBSD 9

2012-03-22 Thread Volodymyr Kostyrko


Efraín Déctor wrote:

Hello. I’m currently testing FreeBSD 9.0, I want to use it as a OS for a 
PostgreSQL Server. However, it is recommended to modified some paramerts such 
as semaphores (http://www.postgresql.org/docs/9.1/static/kernel-resources.html 
):

kern.ipc.semmap=256

But when I tried to change the value on FreeBSD this pops up:

sysctl: unknown oid 'kern.ipc.semmap'

What Can I do to resolve this issue?.


This one can be modified only in /boot/loader.conf

--
Sphinx of black quartz judge my vow.
___
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: Enhancing the user experience with tcsh

2012-02-13 Thread Volodymyr Kostyrko


Alex Keda wrote:

On 10.02.2012 21:07, Chuck Burns wrote:

set prompt = [%n@%m]%c04%# 

it's not needed

need some as
alias ll ls -lAhG
alias ls ls -G
set autolist = TAB
bindkey \e[3~ delete-char
.
and other _really_ necessary settings


This can be as simple as defining CLICOLOR. However colors of ls -G 
wouldn't match with default color set in LSCOLORS so correct LS_COLORS 
string would be needed too.


--
Sphinx of black quartz judge my vow.
___
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: Enhancing the user experience with tcsh

2012-02-13 Thread Volodymyr Kostyrko


Chris Rees wrote:

set prompt = [%n@%m]%c04%# 


it's not needed

need some as
alias ll ls -lAhG
alias ls ls -G


Lscolors are an abomination.  -F or nothing at all is better; remember some
people will use white xterms etc.


Yeah, a +1 for me. Plain xterm with colorized output makes you feel like 
using fork to pry your eyes out... That's surely not a good default.


--
Sphinx of black quartz judge my vow.
___
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: [CFT] Xorg Upgrade 7.5.2

2012-02-13 Thread Volodymyr Kostyrko


Adam K Kirchhoff wrote:


I've run it for a while now and am actually having a pretty serious
issue:

http://thorn.visualtech.com/screenshot.jpg

As you can see, that big window on the right monitor (though certainly
doesn't limit itself to just that screen) is almost entirely corrupt.
It's an xfce4 Terminal, though this can happen with nearly any window,
and happens both with compositing enabled or disabled.  Getting the
window to redraw somehow (either by highlighting all the text or
resizing it) will fix tha areas that are redrawn.

The problem is most often triggered by moving the window around, or
moving other windows around on top of it.  Unfortunately, it makes X
barely usable.


I'm not involved with testing new version but I can second this issue 
with current version in ports. When I managed to add my TV as a second 
screen XFCE draws garbage instead of desktop on the second screen. E17 
however worked like a charm. I mean... you sure this is not an XFCE issue?


--
Sphinx of black quartz judge my vow.
___
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: [CFT] Xorg Upgrade 7.5.2

2012-02-13 Thread Volodymyr Kostyrko


Adam K Kirchhoff wrote:

I've run it for a while now and am actually having a pretty serious
issue:

http://thorn.visualtech.com/screenshot.jpg

As you can see, that big window on the right monitor (though
certainly doesn't limit itself to just that screen) is almost
entirely corrupt. It's an xfce4 Terminal, though this can happen
with nearly any window, and happens both with compositing enabled
or disabled.  Getting the window to redraw somehow (either by
highlighting all the text or resizing it) will fix tha areas that
are redrawn.

The problem is most often triggered by moving the window around, or
moving other windows around on top of it.  Unfortunately, it makes X
barely usable.


I'm not involved with testing new version but I can second this issue
with current version in ports. When I managed to add my TV as a
second screen XFCE draws garbage instead of desktop on the second
screen. E17 however worked like a charm. I mean... you sure this is
not an XFCE issue?


Yes, I'm quite sure. This happens with xfce4, kde4 and just plain
openbox.

I've seen similar distortion (though not quite the same as what's in my
screenshot) from the radeon driver even before testing this new
version.  I will, however, confirm these various corruptions with the
radeon driver happen less with E17.


Yep, radeon here too.

--
Sphinx of black quartz judge my vow.
___
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: Enhancing the user experience with tcsh

2012-02-10 Thread Volodymyr Kostyrko


Eitan Adler wrote:

set filec
-   set history = 100
-   set savehist = 100
+   set history = 1
+   set savehist = 1


Just why not (1 merge)?


+   set autolist
+   # Use history to aid expansion
+   set autoexpand
set mail = (/var/mail/$USER)
if ( $?tcsh ) then
bindkey ^W backward-delete-word
bindkey -k up history-search-backward
bindkey -k down history-search-forward
endif
+   set prompt = [%n@%m]%c04%# 
+   set promptchars = %#
  endif



I'm fully against changing promptchars, that's pointless. Including more 
useful data in prompt is good anyway, but why any [] around? I think 
everything should be just a little more descriptive, like:


set prompt = %n@%m %c04%m%# 

--
Sphinx of black quartz judge my vow.
___
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 9 recompile ports

2012-01-13 Thread Volodymyr Kostyrko


George Kontostanos wrote:

Greetings all and my apologies for cross posting!

There seems to be a confusion regarding the ABI change in FreeBSD 9
and if this affects the usual upgrade path which includes a full port
rebuild.

The relevant post is here: http://forums.freebsd.org/showthread.php?t=28831

Frankly, I am also confused because I remember a relevant discussion a
few months ago in the lists. Traditionally a major RELEASE upgrade
requires a full ports rebuild, however this time there is no
COMPAT_FREEBSD8 in GENERIC and most upgraded systems seem to be
working fine. On the other hand this is stated in UPDATING:

20110828:
 Bump the shared library version numbers for libraries that
 do not use symbol versioning, have changed the ABI compared
 to stable/8 and which shared library version was not bumped.
 Done as part of 9.0-RELEASE cycle.

Your input would be appreciated!


Why can't it be that only shared libraries should be bumped, but no 
kernel incompatible changes were introduced?


--
Sphinx of black quartz judge my vow.
___
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: periodic emails

2012-01-04 Thread Volodymyr Kostyrko


04.01.2012 13:57, Gleb Smirnoff wrote:

Does security_show_success=YES suppress the security report entirely
(no mail sent), if no security related issues found?


Yes.

PS: I also prefer setting *_show_badconfig to 'yes' in case something is 
just not working right.


--
Sphinx of black quartz judge my vow.
___
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: Benchmark (Phoronix): FreeBSD 9.0-RC2 vs. Oracle Linux 6.1 Server

2011-12-15 Thread Volodymyr Kostyrko


15.12.2011 15:48, Jeremy Chadwick wrote:

I'm getting to the point where I'm considering formulating a private
mail to Jeff Roberson, requesting that he be aware of the discussion
that's happening (not that he necessarily follow or read it), and that
based on what I can tell we're at a roadblock -- nobody so far is
absolutely certain how to benchmark and compare ULE vs. 4BSD in
multiple ways, so that those of us involved here can run such utilities
and provide the data somewhere central for devs to review.  I only
mention this because so far I haven't seen anyone really say okay, this
is what we should be using for these kinds of tests.  Yay nature of the
beast.


I'll try to summarize and propose a test scenario. I don't know whether 
this helps or not.


We should have two different task types for this one. The first would be 
Super Affine tasks. They should use few to none syscalls, use medium 
math, have low memory footprint. No syscalls means this tasks will never 
stop for memory/disk or other activity so each time the queue is looked 
upon this task will be ready to run. Medium math means this shouldn't be 
just a simple big loop so that processor will really compute something 
with this data. Low memory footprint means this task can reside with 
data on CPU L1 cache for eons. I'm not sure about branch prediction, 
should it be distorted or not...


The other task type would be Worker. It doesn't matter what it does but 
it agressively uses syscalls like working with files/directories.


There should be at least one SA-task per core and at least 10 (?) 
W-tasks per core.


--
Sphinx of black quartz judge my vow.
___
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: replacement of ataidle for freebsd 9

2011-10-24 Thread Volodymyr Kostyrko


23.10.2011 11:12, Eugene Dzhurinsky wrote:

In the mentime, can you please advice how can I use camcontrol in order to
disable APM for my HDD?


@reboot camcontrol idle ada0 -t 300 ; camcontrol idle ada1 -t 300

--
Sphinx of black quartz judge my vow.
___
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

BETA3 core dump

2011-10-01 Thread Volodymyr Kostyrko


Hi all.

BETA3 dumps core on running heavy disk bound application. Built with 
clang and kernel is custom, but I can try to reproduce it on GENERIC if 
that matters.


http://limbo.xim.bz/core.txt.0

--
Sphinx of black quartz judge my vow.
___
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: BETA3 core dump

2011-10-01 Thread Volodymyr Kostyrko


01.10.2011 13:20, Volodymyr Kostyrko wrote:

BETA3 dumps core on running heavy disk bound application. Built with
clang and kernel is custom, but I can try to reproduce it on GENERIC if
that matters.

http://limbo.xim.bz/core.txt.0


Sorry, I've fixed permissions.

--
Sphinx of black quartz judge my vow.
___
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: Compiling BETA2 with clang fails

2011-09-09 Thread Volodymyr Kostyrko


09.09.2011 11:52, Dimitry Andric wrote:

I did a few test builds with 'high' CPU values for -march, and I ran
into various problems. I'd discourage the use of -march=native for now,
at least with clang. It will take some time to investigate.


Hey, I already posted results of build without -march at all.


...

# nm -D /usr/obj/usr/src/tmp/usr/lib/libc.so

...

That's the problem - libraries miss most symbols.


This is why I still think you have the stdin/out/err problem, in some
way. Can you please check /usr/obj/usr/src/lib/libc/Version.map? It
should have about 2775 lines, otherwise your libc build is busted.


This build was without ccache and CPUTYPE or march. Busted:

=== Version.map ===
FBSD_1.0 {
};

FBSD_1.1 {
} FBSD_1.0;

FBSD_1.2 {
} FBSD_1.1;

FBSDprivate_1.0 {
local:
*;
} FBSD_1.2;

=== Version.map ===

Smoking logs gives this:

cat /usr/src/lib/libc/i386/Symbol.map /usr/src/lib/libc/db/Symbol.map 
/usr/src/lib/libc/compat-43/Symbol.map 
/usr/src/lib/libc/gdtoa/Symbol.map /usr/src/lib/libc/gen/Symbol.map 
/usr/src/lib/libc/gmon/Symbol.map /usr/src/lib/libc/inet/Symbol.map 
/usr/src/lib/libc/locale/Symbol.map /usr/src/lib/libc/nameser/Symbol.map 
/usr/src/lib/libc/net/Symbol.map /usr/src/lib/libc/nls/Symbol.map 
/usr/src/lib/libc/posix1e/Symbol.map /usr/src/lib/libc/quad/Symbol.map 
/usr/src/lib/libc/regex/Symbol.map /usr/src/lib/libc/resolv/Symbol.map 
/usr/src/lib/libc/stdio/Symbol.map /usr/src/lib/libc/stdlib/Symbol.map 
/usr/src/lib/libc/stdtime/Symbol.map /usr/src/lib/libc/string/Symbol.map 
/usr/src/lib/libc/sys/Symbol.map /usr/src/lib/libc/rpc/Symbol.map 
/usr/src/lib/libc/uuid/Symbol.map /usr/src/lib/libc/xdr/Symbol.map 
/usr/src/lib/libc/yp/Symbol.map | clang++ - -  | awk -v 
vfile=/usr/src/lib/libc/Versions.def -f 
/usr/src/share/mk/version_gen.awk  Version.map

clang++: error: -E or -x required when input is from standard input
clang++: error: -E or -x required when input is from standard input

And this is purely my fault because I incorrectly redefined CPP.

Great thanks to everyone. I'll try to remember what I have learned this 
week.


--
Sphinx of black quartz judge my vow.
___
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: Compiling BETA2 with clang fails

2011-09-08 Thread Volodymyr Kostyrko


06.09.2011 17:44, Olivier Smedts wrote:

You mean like fully rebuilding system with gcc and -march=athlon-xp and then
try again?


Like cleaning /usr/obj/ and then buildworld with clang but with
-march=athlon-xp instead of -march=native.
As the problem does not seem to be in your current world but rather in
the bootstrap clang compiled with -march=native, you should not have
to {build,install}world with gcc first.


I cleaned /usr/obj and made a build with -march=athlon-xp. Same errors.

I've also tried to investigate further.

This happens when clang runs linker to link a binary. It runs something 
like:


/usr/obj/usr/src/tmp/usr/bin/ld --eh-frame-hdr -dynamic-linker 
/libexec/ld-elf.so.1 -m elf_i386_fbsd -o atrun 
/usr/obj/usr/src/tmp/usr/lib/crt1.o /usr/obj/usr/src/tmp/usr/lib/crti.o 
/usr/obj/usr/src/tmp/usr/lib/crtbegin.o -L/usr/obj/usr/src/tmp/usr/lib 
atrun.o gloadavg.o -lpam -lutil -lgcc --as-needed -lgcc_s --no-as-needed 
-lc -lgcc --as-needed -lgcc_s --no-as-needed 
/usr/obj/usr/src/tmp/usr/lib/crtend.o /usr/obj/usr/src/tmp/usr/lib/crtn.o


Showstopper here is -L. If I add -L/usr/lib to this command it completes 
successfully.


# nm -D /usr/obj/usr/src/tmp/usr/lib/libc.so
 A FBSD_1.0
 A FBSD_1.1
 A FBSD_1.2
 A FBSDprivate_1.0
 w _Jv_RegisterClasses
 U __progname
 w __pthread_cxa_finalize
00030624 T __semctl
dbe0 T __stack_chk_fail_local
00012880 T acl_add_perm
000128b0 T acl_delete_perm
00012850 T acl_get_perm_np
 U environ
00029610 T fts_children
000286b0 T fts_close
00029770 T fts_get_clientptr
00029780 T fts_get_stream
00027f70 T fts_open
000287e0 T fts_read
000295d0 T fts_set
00029790 T fts_set_clientptr
000305c4 T msgctl
0001e910 T sem_close
0001e6a0 T sem_destroy
0001edb0 T sem_getvalue
0001e5c0 T sem_init
0001e730 T sem_open
0001ed20 T sem_post
0001ea00 T sem_timedwait
0001ec90 T sem_trywait
0001e9e0 T sem_unlink
0001ec60 T sem_wait
00021a30 T semctl
00030524 T shmctl
0001fff0 T ttyslot

That's the problem - libraries miss most symbols.

That's all for now, I'll be back at this one tomorrow.

--
Sphinx of black quartz judge my vow.
___
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: Compiling BETA2 with clang fails

2011-09-06 Thread Volodymyr Kostyrko


06.09.2011 15:34, Olivier Smedts wrote:

Hm, sorry that I did not notice it before, but maybe you are having the
issue described here:

http://lists.freebsd.org/pipermail/freebsd-current/2011-August/026594.html


I think it's more like the following issue, which is not new :
http://lists.freebsd.org/pipermail/freebsd-current/2011-May/024509.html


Nope, my current world was built by gcc.


I personally avoid -march=native with clang on recent CPUs, and use
-march=core2 instead on a Core2 and a Corei7.


--
Sphinx of black quartz judge my vow.
___
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: Compiling BETA2 with clang fails

2011-09-06 Thread Volodymyr Kostyrko


06.09.2011 16:04, Olivier Smedts wrote:


I think it's more like the following issue, which is not new :
http://lists.freebsd.org/pipermail/freebsd-current/2011-May/024509.html


Nope, my current world was built by gcc.


The problem is not the current world but the bootstrap clang built
with -march=native (or -march=recent_cpu) on some recent CPUs.

What is your processor ?


Athlon XP 2500+

I noticed breakage on recent intel processors too, but haven't yet 
stumbled upon them using -march=native on this one.


--
Sphinx of black quartz judge my vow.
___
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: Compiling BETA2 with clang fails

2011-09-06 Thread Volodymyr Kostyrko


06.09.2011 15:01, Dimitry Andric wrote:


Hm, sorry that I did not notice it before, but maybe you are having the
issue described here:

http://lists.freebsd.org/pipermail/freebsd-current/2011-August/026594.html

What is your current kernel revision?


Can't remember and the machine is offline right now. I just can say it's 
running BETA2 from Sep 2 now.


--
Sphinx of black quartz judge my vow.
___
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: Compiling BETA2 with clang fails

2011-09-06 Thread Volodymyr Kostyrko


06.09.2011 16:25, Olivier Smedts wrote:

What is your processor ?


Athlon XP 2500+

I noticed breakage on recent intel processors too, but haven't yet stumbled
upon them using -march=native on this one.


Can you compile the Host.cpp file referenced in :
http://lists.freebsd.org/pipermail/freebsd-current/2011-May/024499.html


Ah, thanks for the link. Missed that one. I'll post results when I'll 
have access to that machine.



And see which arch the resulting binary detects ?

%clang++ Host.cpp -o Host
%./Host
cpu = corei7

Also, do you have the same problem for a clean buildworld with
-march=athlon-xp instead of -march=native in your make.conf ?


You mean like fully rebuilding system with gcc and -march=athlon-xp and 
then try again?


--
Sphinx of black quartz judge my vow.
___
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: Compiling BETA2 with clang fails

2011-09-06 Thread Volodymyr Kostyrko


06.09.2011 15:01, Dimitry Andric wrote:

Hm, sorry that I did not notice it before, but maybe you are having the
issue described here:

http://lists.freebsd.org/pipermail/freebsd-current/2011-August/026594.html

What is your current kernel revision?


I'm very sorry, my kernel is somewhat older then I thought:

# uname -a
FreeBSD limbo.lan 9.0-BETA2 FreeBSD 9.0-BETA2 #0: Mon Aug 29 09:56:12 
EEST 2011 arc...@limbo.lan:/usr/obj/usr/src/sys/MINIMAL  i386


Not subject to the bug though...

--
Sphinx of black quartz judge my vow.
___
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: Compiling BETA2 with clang fails

2011-09-06 Thread Volodymyr Kostyrko


06.09.2011 16:25, Olivier Smedts wrote:

Can you compile the Host.cpp file referenced in :
http://lists.freebsd.org/pipermail/freebsd-current/2011-May/024499.html

And see which arch the resulting binary detects ?

%clang++ Host.cpp -o Host
%./Host
cpu = corei7


cpu = athlon-xp

 Also, do you have the same problem for a clean buildworld with
 -march=athlon-xp instead of -march=native in your make.conf ?

I'm proceeding with buildworld but I don't think this would get you anyway:

[limbo] ~ clang++ -v -march=athlon-xp Host.cpp
FreeBSD clang version 3.0 (trunk 135360) 20110717
Target: i386-unknown-freebsd9.0
Thread model: posix
 /usr/bin/clang++ -cc1 -triple i386-unknown-freebsd9.0 -emit-obj 
-mrelax-all -disable-free -main-file-name Host.cpp -mrelocation-model 
static -mdisable-fp-elim -masm-verbose -mconstructor-aliases -target-cpu 
athlon-xp -momit-leaf-frame-pointer -v -resource-dir 
/usr/bin/../lib/clang/3.0 -fdeprecated-macro -ferror-limit 19 
-fmessage-length 144 -fcxx-exceptions -fexceptions 
-fdiagnostics-show-option -fcolor-diagnostics -o /tmp/cc-Cq9USc.o -x c++ 
Host.cpp
clang -cc1 version 3.0 based upon llvm 3.0svn hosted on 
i386-unknown-freebsd9.0

ignoring nonexistent directory /usr/include/c++/4.2/backward/backward
ignoring nonexistent directory /usr/bin/../lib/clang/3.0/include
ignoring duplicate directory /usr/include/c++/4.2
ignoring duplicate directory /usr/include/c++/4.2/backward
ignoring duplicate directory /usr/include/c++/4.2/backward
#include ... search starts here:
#include ... search starts here:
 /usr/include/c++/4.2
 /usr/include/c++/4.2/backward
 /usr/include/clang/3.0
 /usr/include
End of search list.
 /usr/bin/ld --eh-frame-hdr -dynamic-linker /libexec/ld-elf.so.1 -m 
elf_i386_fbsd -o a.out /usr/lib/crt1.o /usr/lib/crti.o 
/usr/lib/crtbegin.o -L/usr/lib /tmp/cc-Cq9USc.o -lstdc++ -lm -lgcc 
--as-needed -lgcc_s --no-as-needed -lc -lgcc --as-needed -lgcc_s 
--no-as-needed /usr/lib/crtend.o /usr/lib/crtn.o


[limbo] ~ clang++ -v -march=native Host.cpp
FreeBSD clang version 3.0 (trunk 135360) 20110717
Target: i386-unknown-freebsd9.0
Thread model: posix
 /usr/bin/clang++ -cc1 -triple i386-unknown-freebsd9.0 -emit-obj 
-mrelax-all -disable-free -main-file-name Host.cpp -mrelocation-model 
static -mdisable-fp-elim -masm-verbose -mconstructor-aliases -target-cpu 
athlon-xp -momit-leaf-frame-pointer -v -resource-dir 
/usr/bin/../lib/clang/3.0 -fdeprecated-macro -ferror-limit 19 
-fmessage-length 144 -fcxx-exceptions -fexceptions 
-fdiagnostics-show-option -fcolor-diagnostics -o /tmp/cc-7bAsbw.o -x c++ 
Host.cpp
clang -cc1 version 3.0 based upon llvm 3.0svn hosted on 
i386-unknown-freebsd9.0

ignoring nonexistent directory /usr/include/c++/4.2/backward/backward
ignoring nonexistent directory /usr/bin/../lib/clang/3.0/include
ignoring duplicate directory /usr/include/c++/4.2
ignoring duplicate directory /usr/include/c++/4.2/backward
ignoring duplicate directory /usr/include/c++/4.2/backward
#include ... search starts here:
#include ... search starts here:
 /usr/include/c++/4.2
 /usr/include/c++/4.2/backward
 /usr/include/clang/3.0
 /usr/include
End of search list.
 /usr/bin/ld --eh-frame-hdr -dynamic-linker /libexec/ld-elf.so.1 -m 
elf_i386_fbsd -o a.out /usr/lib/crt1.o /usr/lib/crti.o 
/usr/lib/crtbegin.o  -L/usr/lib /tmp/cc-7bAsbw.o -lstdc++ -lm -lgcc 
--as-needed -lgcc_s --no-as-needed -lc -lgcc --as-needed -lgcc_s 
--no-as-needed /usr/lib/crtend.o /usr/lib/crtn.o


--
Sphinx of black quartz judge my vow.
___
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: Compiling BETA2 with clang fails

2011-09-05 Thread Volodymyr Kostyrko


05.09.2011 10:43, Olivier Smedts wrote:


===  libexec/atrun (all)
clang -O2 -pipe -march=native -DATJOB_DIR=\/var/at/jobs/\
-DLFILE=\/var/at/jobs/.lockfile\  -DLOADAVG_MX=1.5
-DATSPOOL_DIR=\/var/at/spool\  -DVERSION=\2.9\ -DDAEMON_UID=1
-DDAEMON_GID=1  -DDEFAULT_BATCH_QUEUE=\'E\'  -DDEFAULT_AT_QUEUE=\'c\'
-DPERM_PATH=\/var/at/\ -I/usr/src/libexec/atrun/../../usr.bin/at
-I/usr/src/libexec/atrun -DLOGIN_CAP -DPAM -std=gnu99 -fstack-protector
-Wsystem-headers -Wall -Wno-format-y2k -Wno-uninitialized -Wno-pointer-sign
-c /usr/src/libexec/atrun/atrun.c


Try removing -march=native from your CFLAGS.

I have the exact same problem since months on my Core i7 CPU when
using -march=native or -march=corei7. No problems for me with
-march=core2 though.


It so nice you have noted that. I'll be much happier if you also spare 
some time reading my previous emails.


As I noted before this command fails only if run as a part of 'make 
buildworld'. If I cd to that directory and run the same command from 
there it completes successfully yielding working binary. If the error 
would be related to -fPIC, ccache or -march it'll end up with other 
bunch of error messages and result would be irrelevant of invocation and 
environment.


As I suspect some incorrect buildworld behavior I have no other choice 
as running another clean build and presenting new logs. Here you go:


clang -O2 -pipe  -DATJOB_DIR=\/var/at/jobs/\ 
-DLFILE=\/var/at/jobs/.lockfile\  -DLOADAVG_MX=1.5 
-DATSPOOL_DIR=\/var/at/spool\  -DVERSION=\2.9\ -DDAEMON_UID=1 
-DDAEMON_GID=1  -DDEFAULT_BATCH_QUEUE=\'E\'  -DDEFAULT_AT_QUEUE=\'c\' 
-DPERM_PATH=\/var/at/\ -I/usr/src/libexec/atrun/../../usr.bin/at 
-I/usr/src/libexec/atrun -DLOGIN_CAP -DPAM -std=gnu99 -fstack-protector 
-Wsystem-headers -Wall -Wno-format-y2k -Wno-uninitialize

d -Wno-pointer-sign  -o atrun atrun.o gloadavg.o -lpam -lutil
clang: warning: argument unused during compilation: '-std=gnu99'
/usr/obj/usr/src/tmp/usr/lib/crt1.o: In function `_start1':
/usr/src/lib/csu/i386-elf/crt1_c.c:(.text+0x7d): undefined reference to 
`atexit'
/usr/src/lib/csu/i386-elf/crt1_c.c:(.text+0x84): undefined reference to 
`_init_tls'
/usr/src/lib/csu/i386-elf/crt1_c.c:(.text+0x90): undefined reference to 
`atexit'
/usr/src/lib/csu/i386-elf/crt1_c.c:(.text+0xad): undefined reference to 
`exit'

atrun.o: In function `perr':
/usr/src/libexec/atrun/atrun.c:(.text+0x12): undefined reference to `strlen'
/usr/src/libexec/atrun/atrun.c:(.text+0x45): undefined reference to `vwarn'
/usr/src/libexec/atrun/atrun.c:(.text+0x6d): undefined reference to 
`snprintf'
/usr/src/libexec/atrun/atrun.c:(.text+0x8a): undefined reference to 
`vsyslog'

/usr/src/libexec/atrun/atrun.c:(.text+0x9c): undefined reference to `exit'
atrun.o: In function `perrx':
/usr/src/libexec/atrun/atrun.c:(.text+0xd3): undefined reference to `vwarnx'
/usr/src/libexec/atrun/atrun.c:(.text+0xdf): undefined reference to `exit'
/usr/src/libexec/atrun/atrun.c:(.text+0xf3): undefined reference to 
`vsyslog'

/usr/src/libexec/atrun/atrun.c:(.text+0xff): undefined reference to `exit'
atrun.o: In function `main':
/usr/src/libexec/atrun/atrun.c:(.text+0x160): undefined reference to 
`geteuid'
/usr/src/libexec/atrun/atrun.c:(.text+0x174): undefined reference to 
`getegid'
/usr/src/libexec/atrun/atrun.c:(.text+0x186): undefined reference to 
`setegid'
/usr/src/libexec/atrun/atrun.c:(.text+0x193): undefined reference to 
`seteuid'
/usr/src/libexec/atrun/atrun.c:(.text+0x1af): undefined reference to 
`openlog'
/usr/src/libexec/atrun/atrun.c:(.text+0x1b5): undefined reference to 
`opterr'
/usr/src/libexec/atrun/atrun.c:(.text+0x1e6): undefined reference to 
`getopt'
/usr/src/libexec/atrun/atrun.c:(.text+0x1fe): undefined reference to 
`optarg'
/usr/src/libexec/atrun/atrun.c:(.text+0x212): undefined reference to 
`sscanf'
/usr/src/libexec/atrun/atrun.c:(.text+0x250): undefined reference to 
`__stderrp'
/usr/src/libexec/atrun/atrun.c:(.text+0x270): undefined reference to 
`fwrite'

/usr/src/libexec/atrun/atrun.c:(.text+0x27c): undefined reference to `exit'
/usr/src/libexec/atrun/atrun.c:(.text+0x290): undefined reference to 
`syslog'

/usr/src/libexec/atrun/atrun.c:(.text+0x29c): undefined reference to `exit'
/usr/src/libexec/atrun/atrun.c:(.text+0x2a8): undefined reference to `chdir'
/usr/src/libexec/atrun/atrun.c:(.text+0x2bc): undefined reference to 
`opendir'

/usr/src/libexec/atrun/atrun.c:(.text+0x2e0): undefined reference to `time'
/usr/src/libexec/atrun/atrun.c:(.text+0x312): undefined reference to 
`_CurrentRuneLocale'
/usr/src/libexec/atrun/atrun.c:(.text+0x34f): undefined reference to 
`unlink'
/usr/src/libexec/atrun/atrun.c:(.text+0x35d): undefined reference to 
`readdir'

/usr/src/libexec/atrun/atrun.c:(.text+0x379): undefined reference to `stat'
/usr/src/libexec/atrun/atrun.c:(.text+0x3b4): undefined reference to 
`sscanf'
/usr/src/libexec/atrun/atrun.c:(.text+0x3e8): undefined reference to 
`__mb_sb_limit'
/usr/src/libexec/atrun/atrun.c:(.text+0x3fe): undefined

Re: Compiling BETA2 with clang fails

2011-09-05 Thread Volodymyr Kostyrko


06.09.2011 01:11, Olivier Smedts wrote:

===libexec/atrun (all)
clang -O2 -pipe -march=native -DATJOB_DIR=\/var/at/jobs/\
-DLFILE=\/var/at/jobs/.lockfile\  -DLOADAVG_MX=1.5
-DATSPOOL_DIR=\/var/at/spool\  -DVERSION=\2.9\ -DDAEMON_UID=1
-DDAEMON_GID=1  -DDEFAULT_BATCH_QUEUE=\'E\'  -DDEFAULT_AT_QUEUE=\'c\'
-DPERM_PATH=\/var/at/\ -I/usr/src/libexec/atrun/../../usr.bin/at
-I/usr/src/libexec/atrun -DLOGIN_CAP -DPAM -std=gnu99 -fstack-protector
-Wsystem-headers -Wall -Wno-format-y2k -Wno-uninitialized
-Wno-pointer-sign
-c /usr/src/libexec/atrun/atrun.c


Try removing -march=native from your CFLAGS.

I have the exact same problem since months on my Core i7 CPU when
using -march=native or -march=corei7. No problems for me with
-march=core2 though.


It so nice you have noted that. I'll be much happier if you also spare some
time reading my previous emails.


Or you could search this mailing list for the exact same problem
reported some time ago.


Well... I know that clang with -march=native can produce flawed binaries 
but it's quite common for them to SEGFAULT and SIGILL so I made at least 
a clean build to check that this is not the problem.



As I noted before this command fails only if run as a part of 'make
buildworld'. If I cd to that directory and run the same command from there
it completes successfully yielding working binary. If the error would be
related to -fPIC, ccache or -march it'll end up with other bunch of error
messages and result would be irrelevant of invocation and environment.


If you cd to that directory, you'll use the system clang, let's call
it the good clang.

If you buildworld with -march=native or -march=corei7, you'll first
compile a bootstrap clang with -march=native or -march=corei7 (the
bad one) and that one will fail building libexec/atrun. Chicken and
egg problem.

If you try building and installing clang with -march=native or
-march=corei7, you'll have the same error if you then cd to that
directory and make.


As I suspect some incorrect buildworld behavior I have no other choice as
running another clean build and presenting new logs. Here you go:


I really mean a clean build here. /usr/obj was wiped and I started from 
scratch. And it gives me the same error. This is not the problem with 
-march.



clang -O2 -pipe  -DATJOB_DIR=\/var/at/jobs/\
-DLFILE=\/var/at/jobs/.lockfile\  -DLOADAVG_MX=1.5
-DATSPOOL_DIR=\/var/at/spool\  -DVERSION=\2.9\ -DDAEMON_UID=1
-DDAEMON_GID=1  -DDEFAULT_BATCH_QUEUE=\'E\'  -DDEFAULT_AT_QUEUE=\'c\'
-DPERM_PATH=\/var/at/\ -I/usr/src/libexec/atrun/../../usr.bin/at
-I/usr/src/libexec/atrun -DLOGIN_CAP -DPAM -std=gnu99 -fstack-protector
-Wsystem-headers -Wall -Wno-format-y2k -Wno-uninitialize
d -Wno-pointer-sign  -o atrun atrun.o gloadavg.o -lpam -lutil
clang: warning: argument unused during compilation: '-std=gnu99'


Anyway you are right. Using /usr/obj/usr/src/tmp/usr/bin/clang gives me 
the same error while installed clang works. So this is really problem 
with clang.


--
Sphinx of black quartz judge my vow.
___
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: Compiling BETA2 with clang fails

2011-09-04 Thread Volodymyr Kostyrko


04.09.2011 00:15, Dimitry Andric wrote:

On 2011-09-03 22:58, Volodymyr Kostyrko wrote:

03.09.2011 23:43, Dimitry Andric ???(??):

On 2011-09-03 22:22, Volodymyr Kostyrko wrote:

...

.if ${CC:T} == clang
CFLAGS+= -Qunused-arguments -fPIC
.endif


You should not unconditionally add -fPIC. Remove it, and try again.
(The -Qunused-arguments is fine, btw.)


0k, here you go. Just as you say - no -fPIC, no ccache, no anything.

=== libexec/atrun (all)
clang -O2 -pipe -march=native -DATJOB_DIR=\/var/at/jobs/\ 
-DLFILE=\/var/at/jobs/.lockfile\  -DLOADAVG_MX=1.5 
-DATSPOOL_DIR=\/var/at/spool\  -DVERSION=\2.9\ -DDAEMON_UID=1 
-DDAEMON_GID=1  -DDEFAULT_BATCH_QUEUE=\'E\'  -DDEFAULT_AT_QUEUE=\'c\' 
-DPERM_PATH=\/var/at/\ -I/usr/src/libexec/atrun/../../usr.bin/at 
-I/usr/src/libexec/atrun -DLOGIN_CAP -DPAM -std=gnu99 -fstack-protector 
-Wsystem-headers -Wall -Wno-format-y2k -Wno-uninitialized 
-Wno-pointer-sign -c /usr/src/libexec/atrun/atrun.c
clang -O2 -pipe -march=native -DATJOB_DIR=\/var/at/jobs/\ 
-DLFILE=\/var/at/jobs/.lockfile\  -DLOADAVG_MX=1.5 
-DATSPOOL_DIR=\/var/at/spool\  -DVERSION=\2.9\ -DDAEMON_UID=1 
-DDAEMON_GID=1  -DDEFAULT_BATCH_QUEUE=\'E\'  -DDEFAULT_AT_QUEUE=\'c\' 
-DPERM_PATH=\/var/at/\ -I/usr/src/libexec/atrun/../../usr.bin/at 
-I/usr/src/libexec/atrun -DLOGIN_CAP -DPAM -std=gnu99 -fstack-protector 
-Wsystem-headers -Wall -Wno-format-y2k -Wno-uninitialized 
-Wno-pointer-sign -c /usr/src/libexec/atrun/gloadavg.c
clang -O2 -pipe -march=native -DATJOB_DIR=\/var/at/jobs/\ 
-DLFILE=\/var/at/jobs/.lockfile\  -DLOADAVG_MX=1.5 
-DATSPOOL_DIR=\/var/at/spool\  -DVERSION=\2.9\ -DDAEMON_UID=1 
-DDAEMON_GID=1  -DDEFAULT_BATCH_QUEUE=\'E\'  -DDEFAULT_AT_QUEUE=\'c\' 
-DPERM_PATH=\/var/at/\ -I/usr/src/libexec/atrun/../../usr.bin/at 
-I/usr/src/libexec/atrun -DLOGIN_CAP -DPAM -std=gnu99 -fstack-protector 
-Wsystem-headers -Wall -Wno-format-y2k -Wno-uninitialized 
-Wno-pointer-sign  -o atrun atrun.o gloadavg.o -lpam -lutil

clang: warning: argument unused during compilation: '-std=gnu99'
/usr/obj/usr/src/tmp/usr/lib/crt1.o: In function `_start1':
/usr/src/lib/csu/i386-elf/crt1_c.c:(.text+0x7d): undefined reference to 
`atexit'
/usr/src/lib/csu/i386-elf/crt1_c.c:(.text+0x84): undefined reference to 
`_init_tls'
/usr/src/lib/csu/i386-elf/crt1_c.c:(.text+0x90): undefined reference to 
`atexit'
/usr/src/lib/csu/i386-elf/crt1_c.c:(.text+0xad): undefined reference to 
`exit'

atrun.o: In function `perr':
/usr/src/libexec/atrun/atrun.c:(.text+0x12): undefined reference to `strlen'
/usr/src/libexec/atrun/atrun.c:(.text+0x45): undefined reference to `vwarn'
/usr/src/libexec/atrun/atrun.c:(.text+0x6d): undefined reference to 
`snprintf'
/usr/src/libexec/atrun/atrun.c:(.text+0x8a): undefined reference to 
`vsyslog'

/usr/src/libexec/atrun/atrun.c:(.text+0x9c): undefined reference to `exit'
atrun.o: In function `perrx':
/usr/src/libexec/atrun/atrun.c:(.text+0xd3): undefined reference to `vwarnx'
/usr/src/libexec/atrun/atrun.c:(.text+0xdf): undefined reference to `exit'
/usr/src/libexec/atrun/atrun.c:(.text+0xf3): undefined reference to 
`vsyslog'

/usr/src/libexec/atrun/atrun.c:(.text+0xff): undefined reference to `exit'
atrun.o: In function `main':
/usr/src/libexec/atrun/atrun.c:(.text+0x160): undefined reference to 
`geteuid'
/usr/src/libexec/atrun/atrun.c:(.text+0x174): undefined reference to 
`getegid'
/usr/src/libexec/atrun/atrun.c:(.text+0x186): undefined reference to 
`setegid'
/usr/src/libexec/atrun/atrun.c:(.text+0x193): undefined reference to 
`seteuid'
/usr/src/libexec/atrun/atrun.c:(.text+0x1af): undefined reference to 
`openlog'
/usr/src/libexec/atrun/atrun.c:(.text+0x1b5): undefined reference to 
`opterr'
/usr/src/libexec/atrun/atrun.c:(.text+0x1e6): undefined reference to 
`getopt'
/usr/src/libexec/atrun/atrun.c:(.text+0x1fe): undefined reference to 
`optarg'
/usr/src/libexec/atrun/atrun.c:(.text+0x212): undefined reference to 
`sscanf'
/usr/src/libexec/atrun/atrun.c:(.text+0x250): undefined reference to 
`__stderrp'
/usr/src/libexec/atrun/atrun.c:(.text+0x270): undefined reference to 
`fwrite'

/usr/src/libexec/atrun/atrun.c:(.text+0x27c): undefined reference to `exit'
/usr/src/libexec/atrun/atrun.c:(.text+0x290): undefined reference to 
`syslog'

/usr/src/libexec/atrun/atrun.c:(.text+0x29c): undefined reference to `exit'
/usr/src/libexec/atrun/atrun.c:(.text+0x2a8): undefined reference to `chdir'
/usr/src/libexec/atrun/atrun.c:(.text+0x2bc): undefined reference to 
`opendir'

/usr/src/libexec/atrun/atrun.c:(.text+0x2e0): undefined reference to `time'
/usr/src/libexec/atrun/atrun.c:(.text+0x312): undefined reference to 
`_CurrentRuneLocale'
/usr/src/libexec/atrun/atrun.c:(.text+0x34f): undefined reference to 
`unlink'
/usr/src/libexec/atrun/atrun.c:(.text+0x35d): undefined reference to 
`readdir'

/usr/src/libexec/atrun/atrun.c:(.text+0x379): undefined reference to `stat'
/usr/src/libexec/atrun/atrun.c:(.text+0x3b4): undefined reference to 
`sscanf'
/usr/src/libexec/atrun/atrun.c:(.text+0x3e8): undefined

Compiling BETA2 with clang fails

2011-09-03 Thread Volodymyr Kostyrko



Hi all.

=== libexec/bootpd (all)
/usr/local/libexec/ccache/world/clang -O2 -pipe -Qunused-arguments -fPIC 
-march=native -DETC_ETHERS -DSYSLOG -DDEBUG -DVEND_CMU -std=gnu99 
-fstack-protector -Wsystem-headers -Wall -Wno-format-y2k 
-Wno-uninitialized -Wno-pointer-sign -Wformat=2 -Wno-format-extra-args 
-c /usr/src/libexec/bootpd/bootpd.c
/usr/local/libexec/ccache/world/clang -O2 -pipe -Qunused-arguments -fPIC 
-march=native -DETC_ETHERS -DSYSLOG -DDEBUG -DVEND_CMU -std=gnu99 
-fstack-protector -Wsystem-headers -Wall -Wno-format-y2k 
-Wno-uninitialized -Wno-pointer-sign -Wformat=2 -Wno-format-extra-args 
-c /usr/src/libexec/bootpd/dovend.c
/usr/local/libexec/ccache/world/clang -O2 -pipe -Qunused-arguments -fPIC 
-march=native -DETC_ETHERS -DSYSLOG -DDEBUG -DVEND_CMU -std=gnu99 
-fstack-protector -Wsystem-headers -Wall -Wno-format-y2k 
-Wno-uninitialized -Wno-pointer-sign -Wformat=2 -Wno-format-extra-args 
-c /usr/src/libexec/bootpd/readfile.c
/usr/local/libexec/ccache/world/clang -O2 -pipe -Qunused-arguments -fPIC 
-march=native -DETC_ETHERS -DSYSLOG -DDEBUG -DVEND_CMU -std=gnu99 
-fstack-protector -Wsystem-headers -Wall -Wno-format-y2k 
-Wno-uninitialized -Wno-pointer-sign -Wformat=2 -Wno-format-extra-args 
-c /usr/src/libexec/bootpd/hash.c
/usr/local/libexec/ccache/world/clang -O2 -pipe -Qunused-arguments -fPIC 
-march=native -DETC_ETHERS -DSYSLOG -DDEBUG -DVEND_CMU -std=gnu99 
-fstack-protector -Wsystem-headers -Wall -Wno-format-y2k 
-Wno-uninitialized -Wno-pointer-sign -Wformat=2 -Wno-format-extra-args 
-c /usr/src/libexec/bootpd/dumptab.c
/usr/local/libexec/ccache/world/clang -O2 -pipe -Qunused-arguments -fPIC 
-march=native -DETC_ETHERS -DSYSLOG -DDEBUG -DVEND_CMU -std=gnu99 
-fstack-protector -Wsystem-headers -Wall -Wno-format-y2k 
-Wno-uninitialized -Wno-pointer-sign -Wformat=2 -Wno-format-extra-args 
-c /usr/src/libexec/bootpd/lookup.c
/usr/local/libexec/ccache/world/clang -O2 -pipe -Qunused-arguments -fPIC 
-march=native -DETC_ETHERS -DSYSLOG -DDEBUG -DVEND_CMU -std=gnu99 
-fstack-protector -Wsystem-headers -Wall -Wno-format-y2k 
-Wno-uninitialized -Wno-pointer-sign -Wformat=2 -Wno-format-extra-args 
-c /usr/src/libexec/bootpd/getif.c
/usr/local/libexec/ccache/world/clang -O2 -pipe -Qunused-arguments -fPIC 
-march=native -DETC_ETHERS -DSYSLOG -DDEBUG -DVEND_CMU -std=gnu99 
-fstack-protector -Wsystem-headers -Wall -Wno-format-y2k 
-Wno-uninitialized -Wno-pointer-sign -Wformat=2 -Wno-format-extra-args 
-c /usr/src/libexec/bootpd/hwaddr.c
/usr/local/libexec/ccache/world/clang -O2 -pipe -Qunused-arguments -fPIC 
-march=native -DETC_ETHERS -DSYSLOG -DDEBUG -DVEND_CMU -std=gnu99 
-fstack-protector -Wsystem-headers -Wall -Wno-format-y2k 
-Wno-uninitialized -Wno-pointer-sign -Wformat=2 -Wno-format-extra-args 
-c /usr/src/libexec/bootpd/report.c
/usr/local/libexec/ccache/world/clang -O2 -pipe -Qunused-arguments -fPIC 
-march=native -DETC_ETHERS -DSYSLOG -DDEBUG -DVEND_CMU -std=gnu99 
-fstack-protector -Wsystem-headers -Wall -Wno-format-y2k 
-Wno-uninitialized -Wno-pointer-sign -Wformat=2 -Wno-format-extra-args 
-c /usr/src/libexec/bootpd/tzone.c
/usr/local/libexec/ccache/world/clang -O2 -pipe -Qunused-arguments -fPIC 
-march=native -DETC_ETHERS -DSYSLOG -DDEBUG -DVEND_CMU -std=gnu99 
-fstack-protector -Wsystem-headers -Wall -Wno-format-y2k 
-Wno-uninitialized -Wno-pointer-sign -Wformat=2 -Wno-format-extra-args 
-c /usr/src/libexec/bootpd/rtmsg.c
/usr/local/libexec/ccache/world/clang -O2 -pipe -Qunused-arguments -fPIC 
-march=native -DETC_ETHERS -DSYSLOG -DDEBUG -DVEND_CMU -std=gnu99 
-fstack-protector -Wsystem-headers -Wall -Wno-format-y2k 
-Wno-uninitialized -Wno-pointer-sign -Wformat=2 -Wno-format-extra-args 
-o bootpd bootpd.o dovend.o readfile.o hash.o dumptab.o lookup.o getif.o 
hwaddr.o report.o tzone.o rtmsg.o

/usr/obj/usr/src/tmp/usr/lib/crt1.o: In function `_start1':
/usr/src/lib/csu/i386-elf/crt1_c.c:(.text+0x94): undefined reference to 
`atexit'
/usr/src/lib/csu/i386-elf/crt1_c.c:(.text+0x9d): undefined reference to 
`_init_tls'
/usr/src/lib/csu/i386-elf/crt1_c.c:(.text+0xad): undefined reference to 
`atexit'
/usr/src/lib/csu/i386-elf/crt1_c.c:(.text+0xd6): undefined reference to 
`exit'

bootpd.o: In function `main':
/var/db/ccache/tmp/bootpd.tmp.limbo.lan.76586.i:(.text+0x31): undefined 
reference to `strrchr'
/var/db/ccache/tmp/bootpd.tmp.limbo.lan.76586.i:(.text+0xa2): undefined 
reference to `malloc'
/var/db/ccache/tmp/bootpd.tmp.limbo.lan.76586.i:(.text+0xe0): undefined 
reference to `exit'
/var/db/ccache/tmp/bootpd.tmp.limbo.lan.76586.i:(.text+0x12a): undefined 
reference to `__error'
/var/db/ccache/tmp/bootpd.tmp.limbo.lan.76586.i:(.text+0x150): undefined 
reference to `getsockname'
/var/db/ccache/tmp/bootpd.tmp.limbo.lan.76586.i:(.text+0x1c7): undefined 
reference to `gethostname'

bootpd.o: In function `.LBB0_31':
/var/db/ccache/tmp/bootpd.tmp.limbo.lan.76586.i:(.text+0x385): undefined 
reference to `sscanf'

bootpd.o: In function `.LBB0_42':

Re: Compiling BETA2 with clang fails

2011-09-03 Thread Volodymyr Kostyrko


03.09.2011 23:43, Dimitry Andric написав(ла):

On 2011-09-03 22:22, Volodymyr Kostyrko wrote:

Hi all.

=== libexec/bootpd (all)

...

/usr/local/libexec/ccache/world/clang -O2 -pipe -Qunused-arguments -fPIC
-march=native -DETC_ETHERS -DSYSLOG -DDEBUG -DVEND_CMU -std=gnu99
-fstack-protector -Wsystem-headers -Wall -Wno-format-y2k
-Wno-uninitialized -Wno-pointer-sign -Wformat=2 -Wno-format-extra-args
-o bootpd bootpd.o dovend.o readfile.o hash.o dumptab.o lookup.o getif.o
hwaddr.o report.o tzone.o rtmsg.o
/usr/obj/usr/src/tmp/usr/lib/crt1.o: In function `_start1':
/usr/src/lib/csu/i386-elf/crt1_c.c:(.text+0x94): undefined reference to
`atexit'
/usr/src/lib/csu/i386-elf/crt1_c.c:(.text+0x9d): undefined reference to
`_init_tls'
/usr/src/lib/csu/i386-elf/crt1_c.c:(.text+0xad): undefined reference to
`atexit'
/usr/src/lib/csu/i386-elf/crt1_c.c:(.text+0xd6): undefined reference to
`exit'
bootpd.o: In function `main':
/var/db/ccache/tmp/bootpd.tmp.limbo.lan.76586.i:(.text+0x31): undefined
reference to `strrchr'
/var/db/ccache/tmp/bootpd.tmp.limbo.lan.76586.i:(.text+0xa2): undefined
reference to `malloc'
/var/db/ccache/tmp/bootpd.tmp.limbo.lan.76586.i:(.text+0xe0): undefined
reference to `exit'
/var/db/ccache/tmp/bootpd.tmp.limbo.lan.76586.i:(.text+0x12a): undefined
reference to `__error'
/var/db/ccache/tmp/bootpd.tmp.limbo.lan.76586.i:(.text+0x150): undefined
reference to `getsockname'
/var/db/ccache/tmp/bootpd.tmp.limbo.lan.76586.i:(.text+0x1c7): undefined
reference to `gethostname'
bootpd.o: In function `.LBB0_31':
/var/db/ccache/tmp/bootpd.tmp.limbo.lan.76586.i:(.text+0x385): undefined
reference to `sscanf'
bootpd.o: In function `.LBB0_42':
/var/db/ccache/tmp/bootpd.tmp.limbo.lan.76586.i:(.text+0x44d): undefined
reference to `sscanf'
bootpd.o: In function `.LBB0_55':

There may be some problems integrating clang into Makefiles, because if
I cd to /usr/src/libexec/bootpd and run make there everything works fine.


Please post your make.conf/src.conf, and any other environmental
settings which may influence the build. For starters, does it still
fail if you remove ccache and the non-standard CFLAGS?


Yes it does. It's still not the clean tree so I'll try to retest without 
ccache.


I don't think ccache is really involved because as I said before when I 
issue the same command from /usr/obj/usr/src/libexec/bootpd it succeeds.


/etc/make.conf follows:

CPUTYPE?=native
INSTALL:=install -C

WITHOUT_NOUVEAU:=yes

KERNCONF?=MINIMAL #GENERIC

NO_CLEAN:=yes

.if (!empty(.CURDIR:M/usr/src*) || !empty(.CURDIR:M/usr/obj*))
. if !defined(NOCCACHE)
  # GCC 4.2
  #CC:=${CC:C,^cc,/usr/local/libexec/ccache/world/cc,1}
  #CXX:=${CXX:C,^c\+\+,/usr/local/libexec/ccache/world/c++,1}
  # clang
  CC:=${CC:C,^cc,/usr/local/libexec/ccache/world/clang,1}
  CXX:=${CXX:C,^c\+\+,/usr/local/libexec/ccache/world/clang++,1}
  CPP:=${CXX:C,^cpp,/usr/local/libexec/ccache/world/clang -E,1}
  # clang without ccache
  #CC:=${CC:C,^cc,clang,1}
  #CXX:=${CXX:C,^c\+\+,clang++,1}
  #CPP:=${CXX:C,^cpp,clang -E,1}
  # Don't die on warnings
  NO_WERROR=
  WERROR=
  # Don't forget this when using Jails!
  NO_FSCHG=
. endif
.else
. if (empty(.CURDIR:M*/java/openjdk6*)  
empty(.CURDIR:M*/java/openjdk7*)  empty(.CURDIR:M*-kmod*)  
empty(.CURDIR:M*/java/jdk16*))

  #CFLAGS+= -mfpmath=sse,387
  #COPTFLAGS+= -mfpmath=sse,387
. endif
.endif

WRKDIRPREFIX=/tmp/ports
DISABLE_MAKE_JOBS=true

.if ${CC:T} == clang
  CFLAGS+= -Qunused-arguments -fPIC
.endif

--
Sphinx of black quartz judge my vow.
___
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: http://www.freebsd.org/marketing/os-comparison.html

2011-08-30 Thread Volodymyr Kostyrko


30.08.2011 12:30, Mihamina Rakotomandimby wrote:

On 08/29/2011 10:58 PM, Volodymyr Kostyrko wrote:

If that page would be updated at least monthly giving fair comparison
with other os'es it could serve a big pros list for preferring FreeBSD
over other systems.


I dont think a monthly update is the good solution.
A per release update is better, as far as releases bring a new set that
could be compared.


I don't think all other OS'es will bring new set of features only when 
FreeBSD is released.



Then, a deep knwoledge of the other OSes is required in order to keep
credit. I think it's a huge amount of work, that should be assigned to
the project itself.

IMHO, Let's delegate this task to Wikipedia or StackOverflow...


I totally disagree. Sites like Wikipedia or StackOverflow serve they own 
means. When it comes to the point of selecting os you need to show exec 
one page or even give him one document and searching different bits of 
information on different sites wouldn't be pretty. Besides it's much 
better to have control over this page to make sure it's fresh and current.


--
Sphinx of black quartz judge my vow.
___
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: http://www.freebsd.org/marketing/os-comparison.html

2011-08-30 Thread Volodymyr Kostyrko


30.08.2011 12:23, Sergey Kandaurov wrote:

[Taking random email.]

I think we could merge the $subj web page with this one (which is
more actual, as of 7.0): http://www.freebsd.org/features.html



The pages serve different purposes. There's no point in elaborating 
about feature X if feature X support doesn't differ from other OS 
implementation. And we should focus on major differences, not just any 
other feature.


Despite we are a company of enthusiasts most enthusiasts once in a 
lifetime come to the problem of explaining why this OS is better than 
other or why we shouldn't count on FreeBSD yet.


--
Sphinx of black quartz judge my vow.
___
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: http://www.freebsd.org/marketing/os-comparison.html

2011-08-29 Thread Volodymyr Kostyrko


27.08.2011 22:13, Hartmann, O. wrote:

This website should be brushed up or taken offline!
It seems full of vintage stuff from glory days.

http://www.freebsd.org/marketing/os-comparison.html


I think this one would better look like list of major features with os 
comparison, like:


= Networking =
 * IPv6: major support, best stack around.
 * SCTP: full kernel implementation, still no userland support (i.e. 
ssh doesn't work over sctp by default yet).


= Data storage =
 * ZFS: full support, datasets, compression, dedup, other stuff. Linux 
has LVM (?features...) and btrfs (?unstable.. ?features..), Windows has 
dynamic disks since XP (?features).


= SMP =
 * (?something about comparing other shedulers with SCHED_ULE), (?some 
rt stuff), (?some comparison with other interesting shedulers, like 
DragonflyBSD and QNX).


 If that page would be updated at least monthly giving fair comparison 
with other os'es it could serve a big pros list for preferring FreeBSD 
over other systems.


--
Sphinx of black quartz judge my vow.
___
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: ZFS boot fails with two pools

2011-07-07 Thread Volodymyr Kostyrko


07.07.2011 09:22, Berczi Gabor нwrote:


On Jul 6, 2011, at 10:08 PM, Volodymyr Kostyrko wrote:


1. Check that pools have up-to-date boot code.


I tried 8.2 and HEAD. You mean gpart+gptzfsboot+pmbr, right?


Yep.


2. Try to convince bios to boot from the disk of pool2.


There is no disk with a singular ZFS pool.


Any disk from bootable pool.


3. You can possibly try deploying /boot/boot0 MBR selector code over disks of 
data pool. Supplied boot0 code can be used to choose another disk to jump to it 
during boot process and will remember the last choice.


I'm not really sure how to do this with GPT. Should I use boot0 instead of pmbr?


boot0cfg is your old friend


However, this 
(http://freebsd.1045724.n5.nabble.com/Booting-from-ZFS-raidz-td4032461.html) 
may be related to the problem:


That one is too old, I have one machine running 8.2 on raidz2 pool.




You can boot from any of the drives and as long as the BIOS can see
enough drives you should be able to boot.


In my case, the BIOS certainly can not see all members of the raid-z pool. The 
question is: why does it want to boot from raid-z at all, and how could it be 
persuaded to use the mirrored pool instead?


Actuall I think that code on that stages just tries to boot from the 
pool on the current disk.


--
Sphinx of black quartz judge my vow.
___
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: ZFS boot fails with two pools

2011-07-06 Thread Volodymyr Kostyrko


06.07.2011 18:44, Berczi Gabor wrote:

Greets,

For some reason FreeBSD can't boot automatically:

ZFS: i/o error - all block copies unavailable
ZFS: can't read MOS object directory
Can't find root filesystem - giving up
ZFS: unexpected object set type 0
ZFS: unexpected object set type 0

FreeBSD/x86 boot
Default: data:/boot/kernel/kernel
boot:
ZFS: unexpected object set type 0

FreeBSD/x86 boot
Default: data:/boot/kernel/kernel
boot:

I have two pools, pool2 which is a mirrored zpool, and data being a raid-z pool. Note how 
the default should be pool2:/boot/zfsloader. How can I fix this?


1. Check that pools have up-to-date boot code.

2. Try to convince bios to boot from the disk of pool2.

3. You can possibly try deploying /boot/boot0 MBR selector code over 
disks of data pool. Supplied boot0 code can be used to choose another 
disk to jump to it during boot process and will remember the last choice.


--
Sphinx of black quartz judge my vow.
___
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: Thoughts on TMPFS no longer being considered highly experimental

2011-06-29 Thread Volodymyr Kostyrko


23.06.2011 19:31, David O'Brien wrote:

Does anyone object to this patch?

David Wolfskill and I have run TMPFS on a number of machines for two
years with no problems.

I may have missed something, but I'm not aware of any serious PRs on
TMPFS either.



Maybe i'm missing something but creating/removing large number of files 
in one directory on tmpfs was very slow for me. That was long ago and 
ZFS was in so i'll try to retest...


--
Sphinx of black quartz judge my vow.
___
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: ZFS import panic with r219703

2011-03-16 Thread Volodymyr Kostyrko


17.03.2011 01:03, Freddie Cash wrote:

Anytime I try to import my pool built using 24x HAST devices, I get
the following message, and the system reboots:

panic: solaris assert: dmu_free_range(os, smo-smo_object, 0, -1ULL,
tx) == 0, file:
/usr/src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common/fs/space_map.c,
line: 484

Everything runs nicely if I don't import the pool.

Doing a zpool import shows that one of the HAST devices is FAULTED
corrupted data.

Haven't tried anything to remove/replace the faulted device, just
wanted to see if anyone knew what the above error meant.

Pool was created using r219523 and successfully copied over 1 TB of
data from another ZFS system.  Had some issues with gptboot this
morning and the system locking up and rebooting a bunch, and now the
pool won't import.


Oh, the garbled space_map issue. The system will assert any time the 
pool is imported in r/w. ZFSv28 is able to import pool in r/o state and 
this is as far as I know the only way to recover data from such pool. 
Anyway pool should be recreated.


--
Sphinx of black quartz judge my vow.
___
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: HEADS UP: ZFSv28 is in!

2011-03-05 Thread Volodymyr Kostyrko


28.02.2011 15:24, lhmwzy wrote:

Tks for PJD's work for zfs.

Would V28 is the last version of zfs because oracle don't open the zfs
code after V28?


1. Oracle opens the code, but only after some time. AFAIR they do open 
the code after the major releases.
2. All head developers have quit Oracle. They say technology is complete 
an should go on by itself.
3. With current work going on in Illumos aren't we sharing the role of 
'core' for ZFS development?


--
Sphinx of black quartz judge my vow.
___
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

On the modules

2000-06-30 Thread Volodymyr Kostyrko


  When I was compiling the modules I face the following situation. While its possible 
to compile kernel even with -O3 -pipe, the modules still copmpiled with -O -pipe. 
Where I can change this? The search in the /sys/compile returns nothing...

  Next. What would be with the modules in future? Something is not good in division 
for devices and modules. For example, MSDOSFS compiled as module makes it possible to 
forget about compiling it into kernel. On the other hand there are modules that must 
be present at the boot stage to load the system (or devices must be compiled in). May 
be it's possible to convert devices to modules? And then just load needable before 
running kernel? Or just make a option for linking the module into the kernel?

-- 
[WBR], Arcade Zardos. [AIST] [SAT Astronomy//Think to survive!] [mp3.aist.net]


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Re: Scheduler changes?

2000-06-10 Thread Volodymyr Kostyrko


On Fri, Jun 09, 2000 at 08:28:06PM -0400, Brian Fundakowski Feldman wrote:
It's an issue. Nice values count for less than before due to fixes
 that Luoqi Chen made (and I committed). The behavior now isn't optimal,
 but it is better than the system locking up. NICE_WEIGHT might be okay
 to keep at 2. Try the attached diff; I'm pretty sure it won't blow
 things up :)
The diff should make a process at -20 which uses all available CPU
 schedule just slightly the ahead of a process at +20 which uses no CPU.
 A process which uses full CPU at 0 niceness would have a priority of
 128, whereas a process using no CPU at 0 niceness would have a priority
 of 90. All processes will always have a priority less than or equal to
 128, which is the priority at which a process with a niceness of +20
 always runs at. A +20 process won't get better priority than anything
 else, period. Try it out, see how it works for you:)

  I think this is not the clear solution for descibed problem 'couse the dnetc client 
still gets a priority and still have the share of time while other programs might run. 
For me idprio works great. Just change last string in the starting shell scipt.

  idprio 31 su nobody -c "$dir/dnetc -quiet" 2/dev/null /dev/null 

-- 
[WBR], Arcade Zardos. [AIST] [SAT Astronomy//Think to survive!] [mp3.aist.net]


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

62 matches

Mail list logo