Re: Problem compiling libs after pass to current

2011-11-28 Thread Maciej Milewski
Dnia niedziela, 27 listopada 2011 19:59:44 ZaRiuS KRiNG pisze:
 Hi! is my first post here and have a little problem try to google some and
 don't find any of value.
 
 A week ago compile the src of current, and after that in any new port i
 install, if compile before any lib, don't work, i need to install pkg from
 repository of that lib and continue compiling the program, and work fine.
 Just have this problem with the libs
 
 Any solution?
Have you updated you ports tree? Maybe you are affected by the issue mentioned 
in ports/UPDATING:

20110928:
  AFFECTS: users of 10-current
  AUTHOR: ead...@freebsd.org

  There are known issues installing ports on FreeBSD 10+ due to
  bogus assumptions by various build scripts. This will not be fixed
  until 9-RELEASE is released.

  There are two workarounds:

  1) Set UNAME_r=9.9-CURRENT in your environment
  2) Set REVISION=9.9 in  ${SRCDIR}/sys/conf/newvers.sh

--
Maciek
___
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: options atapicam and/or device ATA_CAM in kernel config?

2011-11-28 Thread Thomas Mueller
 On 11/27/11, Lowell Gilbert freebsd-questions-lo...@be-well.ilk.org wrote:
  b. f. bf1...@googlemail.com writes:

What is the role of options atapicam and device ATA_CAM in kernel
config file?

Are they redundant?  Kernel will build with both these options, but
will it make things go awry?  Is ATA_CAM deprecated?

  They are redundant and incompatible.  atapicam is deprecated, and
  ATA_CAM is the new default on FreeBSD 9 and 10. Unless you have some
  special requirements, you should use ATA_CAM on recent versions of
  FreeBSD, because it usually performs better than the old ATA code, and
  has added functionality.

  Ah. My apologies to anyone I confused with my incorrect comments.

  I must say that I'm thoroughly disappointed that my searches through the
  official documentation didn't turn up anything related to this. Even the
  Handbook, with extensive practical descriptions of how to use this
  functionality, doesn't mention that its advice is irrelevant to anything
  past 8.x.
   
 The handbook does contain some oblique and scattered references to the
 new code, or at least to constructs that are common to both the old
 and the new code, but the addition of a brief discussion of the
 differences between the new and old ATA code in the handbook -- i.e.,
 the kernel and userland components that are now obsolete, and their
 replacements -- might be of some help to users.  The primary author of
 the new code did add some material to various notes and manpages, but
 he has been very busy writing and debugging code, and English is not
 his first language, so others will have to supplement his efforts.
 Perhaps you could ask for some additions on the freebsd-doc mailing
 list?
 
 b.

Now I see it's options ATA_CAM or device atapicam.  It looks like I
inadvertently transposed device and options in subject line.

Now I think I'll try to rebuild the kernel with options ATA_CAM and drop
device atapicam.

This question needs to be better resolved in time for FreeBSD 9.0-RELEASE.

I cross-post this message to freebsd-current@freebsd.org so the developers
will see it.  FreeBSD users want to be able to burn CDs and DVDs, and since
SCSI hardware has fallen out of style, I can say very few if any FreeBSD 9.0 
users will have an actual SCSI CD or DVD drive.

Tom

___
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: array index of '-16' indexes before the beginning of the array

2011-11-28 Thread Andriy Gapon
on 28/11/2011 02:59 Ryan Stone said the following:
 On Sun, Nov 27, 2011 at 6:42 PM, Andriy Gapon a...@freebsd.org wrote:

 Looks like clang has found a real issue here:
 /usr/src/sys/x86/x86/local_apic.c:311:2: warning: array index of '-16' 
 indexes
 before the beginning of the array [-Warray-bounds]
lapics[apic_id].la_ioint_irqs[IDT_DTRACE_RET - APIC_IO_INTS] =
 IRQ_DTRACE_RET;
 
 Hm, so as far as I can tell the DTrace-related code in local_apic.c is
 bogus.  DTrace's interrupt vectors are 32 and 33, which aren't I/O
 vectors, so local_apic.c shouldn't need to know anything about them.
 I think that the right fix is to remove all of it from local_apic.c.

I think that those vectors fall into a range designated for PIC interrupts.
sys/i386/include/apicvar.h has a nice illustration.

-- 
Andriy Gapon
___
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


WITHOUT_PROFILE=yes by default

2011-11-28 Thread Max Khon
Hello!

Are there any compelling reasons for having profiled libs to be built by
default?
They are of no use for 100% users and 99,999% developers and just slow down
world and universe builds.

Here are the results of running buildworld on 1 core on AMD Athlon(tm) 64
X2 Dual Core Processor 4400+:
make buildworld
 8265,06 real  6400,27 user  1059,2 sys
make buildworld (WITHOUT_PROFILE=yes)
 7840,05 real  5379,13 user   904,61 sys

I would like to disable building profiled libraries by default. Opinions?

Max
___
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: options atapicam and/or device ATA_CAM in kernel config?

2011-11-28 Thread b. f.
 Now I think I'll try to rebuild the kernel with options ATA_CAM and drop
 device atapicam.

 This question needs to be better resolved in time for FreeBSD 9.0-RELEASE.

 I cross-post this message to freebsd-current@freebsd.org so the developers
 will see it.  FreeBSD users want to be able to burn CDs and DVDs, and since
 SCSI hardware has fallen out of style, I can say very few if any FreeBSD 9.0
 users will have an actual SCSI CD or DVD drive.

The new CAM(4) is not just for SCSI devices (and SCSI, as it is
usually used now, does not deal only with the old parallel SCSI
devices). Despite the fact that most CD and DVD drives will now appear
as cdX devices, and cd(4) is full of references to SCSI, most CD and
DVD drives should be supported.  And while burncd(8) will not work
with the new interface, other software in ports should -- for example,
sysutils/cdrtools and sysutils/cdrtools-devel, as was mentioned
before.

b.
___
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: iSCSI initiator: iscontrol cannot be stopped or killed

2011-11-28 Thread Ivan Voras

On 24/11/2011 18:06, Mark Martinec wrote:

If you can get it back into this state,


Sure, *every* time.


a procstat -k -kiscontrol pid  would be very helpful.
(the second -k is not a typo).


# procstat -k -k 5896
   PIDTID COMM TDNAME   KSTACK
  5896 102364 iscontrol-mi_switch+0x174
sleepq_timedwait+0x42 _sleep+0x301 ic_init+0x2f1 iscsi_ioctl+0x525
devfs_ioctl_f+0x7b kern_ioctl+0x115 sys_ioctl+0xfd amd64_syscall+0x450
Xfast_syscall+0xf7


Additional info: the process is blocking on 'ffp', unresponsive to signals:

   UID   PID  PPID CPU PRI NIVSZRSS MWCHAN STAT  TT TIME COMMAND
 0  5896 1   0  20  0  16424   1264 ffpDs??  0:00.04 
iscontrol -c /etc/iscsi.conf -n xxx



You should probably ask at the freebsd-scsi@ mailing list. From looking 
at the code it looks like ffp is used for LUN scan timeout.



___
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 i/o hangs on 9-PRERELEASE

2011-11-28 Thread Pawel Jakub Dawidek
On Fri, Nov 25, 2011 at 01:20:01PM -0600, Mark Felder wrote:
 13:14:32 nas:~  uname -a
 FreeBSD nas.feld.me 9.0-PRERELEASE FreeBSD 9.0-PRERELEASE #3 r227971M: 
 Fri Nov 25 10:07:48 CST 2011 
 r...@nas.feld.me:/usr/obj/tank/svn/sys/GENERIC  amd64
 
 This seemed to start happening sometime after RC1. I tried 8-STABLE and 
 it's happening there too right now. I think whatever caused this was 
 MFC'd. I've also reproduced this on completely different hardware 
 running a single disk ZFS pool.
 
 
 I'm getting this output in dmesg after these hangs I keep seeing.

Mark, those backtrace are not related to ZFS, but to PF. Not sure if
they are at all related to your hangs. Most cases where ZFS I/O seems to
hang are hardware problems, where I/O requests are not completed.

'procstat -kk -a' output might be useful once the hang happens.

 uma_zalloc_arg: zone pfrktable with the following non-sleepable locks 
 held:
 exclusive sleep mutex pf task mtx (pf task mtx) r = 0 
 (0x8199af20) locked @ 
 /tank/svn/sys/modules/pf/../../contrib/pf/net/pf_ioctl.c:1589
 KDB: stack backtrace:
 db_trace_self_wrapper() at db_trace_self_wrapper+0x2a
 kdb_backtrace() at kdb_backtrace+0x37
 _witness_debugger() at _witness_debugger+0x2e
 witness_warn() at witness_warn+0x2c4
 uma_zalloc_arg() at uma_zalloc_arg+0x335
 pfr_create_ktable() at pfr_create_ktable+0xd8
 pfr_ina_define() at pfr_ina_define+0x12b
 pfioctl() at pfioctl+0x1c5a
 devfs_ioctl_f() at devfs_ioctl_f+0x7a
 kern_ioctl() at kern_ioctl+0xcd
 sys_ioctl() at sys_ioctl+0xfd
 amd64_syscall() at amd64_syscall+0x3ac
 Xfast_syscall() at Xfast_syscall+0xf7
 --- syscall (54, FreeBSD ELF64, sys_ioctl), rip = 0x800da711c, rsp = 
 0x7fff9d28, rbp = 0x7fffa1f0 ---

-- 
Pawel Jakub Dawidek   http://www.wheelsystems.com
FreeBSD committer http://www.FreeBSD.org
Am I Evil? Yes, I Am! http://yomoli.com


pgp98vrUuromO.pgp
Description: PGP signature


Re: ee (easy editor) bugged on 9.0?

2011-11-28 Thread Ed Schouten
Hello Jason,

* Jason Edwards sub.m...@gmail.com, 2027 22:15:
 Thanks for the impressive list of advantages! There's just one
 non-critical issue I'd like to address regarding the use of xterm
 terminal type.
 
 When using cons25 terminal, the dialog menus (drawn using
 devel/cdialog and `make config` in portstree as well) are using smooth
 lines to draw boxes and stuff.
 
 But when using xterm terminal, those lines are replaced by 'dashed'
 lines like - - - - - instead of a smooth line without whitespace in
 between. When doing the same via SSH login, the lines are smooth with
 xterm type. So this issue appear to be limited to the console in
 combination with xterm terminal type.
 
 Is there a way to use xterm but still allow cdialog to draw smooth
 lines on the console?

Unfortunately, this is actually a workaround for a problem that existed
all along, even before we switched to TERM=xterm. It's not beautiful,
but needed.

When using TERM=cons25, ncurses applications simply print certain bytes
to do the box drawing, namely these ones:

http://en.wikipedia.org/wiki/Code_page_437#Standard_code_page

This means that if you load a different font file into the console
driver that uses a different character set (e.g. ISO-8859-1), you get
all sorts of math characters and diacritics instead of the box drawing
characters.

With TERM=xterm, this is essentially solved, because box drawing can be
performed using character set independent escape sequences (using ^N and
^O), but the problem is that syscons does not know which glyphs in the
font file correspond with the box drawing characters.

There are two ways to solve this:

- Extend the font file format to include a mapping table of box drawing
  characters to glyph indices,
- Patch syscons to just print +-| instead of the box drawing characters.

The first option would fix it properly, but in my opinion it's not worth
the effort, because time should be spent to just get Unicode working.
The terminal emulator already supports Unicode internally and even
remaps box drawing characters to Unicode. Get Unicode working and you
fix the box drawing issue for free. This is why I have chosen the second
option.

If you really miss the box drawing characters, you can revert SVN
revision 203659. Do keep in mind that it effectively breaks support for
custom fonts/character sets. I think box drawing does work when you
compile your kernel with TEKEN_UTF8 (poor mans UTF-8 support), but
please don't attempt to load any fonts then.

Best regards,
-- 
 Ed Schouten e...@80386.nl
 WWW: http://80386.nl/


pgpuueQ3Esoka.pgp
Description: PGP signature


Re: zfs i/o hangs on 9-PRERELEASE

2011-11-28 Thread Rick Macklem
Pawel Jakub Dawidek wrote:
 On Fri, Nov 25, 2011 at 01:20:01PM -0600, Mark Felder wrote:
  13:14:32 nas:~  uname -a
  FreeBSD nas.feld.me 9.0-PRERELEASE FreeBSD 9.0-PRERELEASE #3
  r227971M:
  Fri Nov 25 10:07:48 CST 2011
  r...@nas.feld.me:/usr/obj/tank/svn/sys/GENERIC amd64
 
  This seemed to start happening sometime after RC1. I tried 8-STABLE
  and
  it's happening there too right now. I think whatever caused this was
  MFC'd. I've also reproduced this on completely different hardware
  running a single disk ZFS pool.
 
 
  I'm getting this output in dmesg after these hangs I keep seeing.
 
 Mark, those backtrace are not related to ZFS, but to PF. Not sure if
 they are at all related to your hangs. Most cases where ZFS I/O seems
 to
 hang are hardware problems, where I/O requests are not completed.
 
He recently posted that his hangs went away when he stopped using NFS.
NFS does use uma_zalloc() and there are several places in pfioctl()
where uma_zalloc(...M_WAITOK...) is called (hidden under pool_get())
when a mutex (the PF_LOCK() one) is held.

I've emailed bz@ related to this.

I'm also not sure if they could be related to his hangs, but it seems
that if uma_zalloc() decides to sleep with the mutex held, something
may break and a broken uma_zalloc() would impact NFS.

rick

 'procstat -kk -a' output might be useful once the hang happens.
 
  uma_zalloc_arg: zone pfrktable with the following non-sleepable
  locks
  held:
  exclusive sleep mutex pf task mtx (pf task mtx) r = 0
  (0x8199af20) locked @
  /tank/svn/sys/modules/pf/../../contrib/pf/net/pf_ioctl.c:1589
  KDB: stack backtrace:
  db_trace_self_wrapper() at db_trace_self_wrapper+0x2a
  kdb_backtrace() at kdb_backtrace+0x37
  _witness_debugger() at _witness_debugger+0x2e
  witness_warn() at witness_warn+0x2c4
  uma_zalloc_arg() at uma_zalloc_arg+0x335
  pfr_create_ktable() at pfr_create_ktable+0xd8
  pfr_ina_define() at pfr_ina_define+0x12b
  pfioctl() at pfioctl+0x1c5a
  devfs_ioctl_f() at devfs_ioctl_f+0x7a
  kern_ioctl() at kern_ioctl+0xcd
  sys_ioctl() at sys_ioctl+0xfd
  amd64_syscall() at amd64_syscall+0x3ac
  Xfast_syscall() at Xfast_syscall+0xf7
  --- syscall (54, FreeBSD ELF64, sys_ioctl), rip = 0x800da711c, rsp =
  0x7fff9d28, rbp = 0x7fffa1f0 ---
 
 --
 Pawel Jakub Dawidek http://www.wheelsystems.com
 FreeBSD committer http://www.FreeBSD.org
 Am I Evil? Yes, I Am! http://yomoli.com
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org


[head tinderbox] failure on i386/i386

2011-11-28 Thread FreeBSD Tinderbox
TB --- 2011-11-28 13:40:00 - tinderbox 2.8 running on freebsd-current.sentex.ca
TB --- 2011-11-28 13:40:00 - starting HEAD tinderbox run for i386/i386
TB --- 2011-11-28 13:40:00 - cleaning the object tree
TB --- 2011-11-28 13:40:55 - cvsupping the source tree
TB --- 2011-11-28 13:40:55 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca 
/tinderbox/HEAD/i386/i386/supfile
TB --- 2011-11-28 13:46:19 - building world
TB --- 2011-11-28 13:46:19 - CROSS_BUILD_TESTING=YES
TB --- 2011-11-28 13:46:19 - MAKEOBJDIRPREFIX=/obj
TB --- 2011-11-28 13:46:19 - PATH=/usr/bin:/usr/sbin:/bin:/sbin
TB --- 2011-11-28 13:46:19 - SRCCONF=/dev/null
TB --- 2011-11-28 13:46:19 - TARGET=i386
TB --- 2011-11-28 13:46:19 - TARGET_ARCH=i386
TB --- 2011-11-28 13:46:19 - TZ=UTC
TB --- 2011-11-28 13:46:19 - __MAKE_CONF=/dev/null
TB --- 2011-11-28 13:46:19 - cd /src
TB --- 2011-11-28 13:46:19 - /usr/bin/make -B buildworld
 World build started on Mon Nov 28 13:46:19 UTC 2011
 Rebuilding the temporary build tree
 stage 1.1: legacy release compatibility shims
 stage 1.2: bootstrap tools
 stage 2.1: cleaning up the object tree
 stage 2.2: rebuilding the object tree
 stage 2.3: build tools
 stage 3: cross tools
 stage 4.1: building includes
 stage 4.2: building libraries
 stage 4.3: make dependencies
 stage 4.4: building everything
[...]
c++ -O2 -pipe -fstack-protector -Wsystem-headers -Werror 
-I/src/gnu/usr.bin/gperf/../../../contrib/gperf/lib -I/src/gnu/usr.bin/gperf -c 
/src/gnu/usr.bin/gperf/../../../contrib/gperf/src/search.cc
c++ -O2 -pipe -fstack-protector -Wsystem-headers -Werror 
-I/src/gnu/usr.bin/gperf/../../../contrib/gperf/lib -I/src/gnu/usr.bin/gperf -c 
/src/gnu/usr.bin/gperf/../../../contrib/gperf/src/version.cc
c++ -O2 -pipe -fstack-protector -Wsystem-headers -Werror 
-I/src/gnu/usr.bin/gperf/../../../contrib/gperf/lib -I/src/gnu/usr.bin/gperf -c 
/src/gnu/usr.bin/gperf/../../../contrib/gperf/lib/getline.cc
c++ -O2 -pipe -fstack-protector -Wsystem-headers -Werror 
-I/src/gnu/usr.bin/gperf/../../../contrib/gperf/lib -I/src/gnu/usr.bin/gperf -c 
/src/gnu/usr.bin/gperf/../../../contrib/gperf/lib/hash.cc
c++ -O2 -pipe -fstack-protector -Wsystem-headers -Werror 
-I/src/gnu/usr.bin/gperf/../../../contrib/gperf/lib -I/src/gnu/usr.bin/gperf  
-o gperf bool-array.o hash-table.o input.o keyword-list.o keyword.o main.o 
options.o output.o positions.o search.o version.o getline.o hash.o 
gzip -cn /src/gnu/usr.bin/gperf/../../../contrib/gperf/doc/gperf.1  gperf.1.gz
=== gnu/usr.bin/gperf/doc (all)
make: don't know how to make gperf.info. Stop
*** Error code 2

Stop in /src/gnu/usr.bin/gperf.
*** Error code 1

Stop in /src/gnu/usr.bin.
*** Error code 1

Stop in /src/gnu.
*** Error code 1

Stop in /src.
*** Error code 1

Stop in /src.
*** Error code 1

Stop in /src.
TB --- 2011-11-28 15:34:42 - WARNING: /usr/bin/make returned exit code  1 
TB --- 2011-11-28 15:34:42 - ERROR: failed to build world
TB --- 2011-11-28 15:34:43 - 5301.79 user 861.04 system 6882.46 real


http://tinderbox.freebsd.org/tinderbox-head-HEAD-i386-i386.full
___
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


[head tinderbox] failure on mips/mips

2011-11-28 Thread FreeBSD Tinderbox
TB --- 2011-11-28 15:42:45 - tinderbox 2.8 running on freebsd-current.sentex.ca
TB --- 2011-11-28 15:42:45 - starting HEAD tinderbox run for mips/mips
TB --- 2011-11-28 15:42:45 - cleaning the object tree
TB --- 2011-11-28 15:42:55 - cvsupping the source tree
TB --- 2011-11-28 15:42:55 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca 
/tinderbox/HEAD/mips/mips/supfile
TB --- 2011-11-28 15:43:17 - building world
TB --- 2011-11-28 15:43:17 - CROSS_BUILD_TESTING=YES
TB --- 2011-11-28 15:43:17 - MAKEOBJDIRPREFIX=/obj
TB --- 2011-11-28 15:43:17 - PATH=/usr/bin:/usr/sbin:/bin:/sbin
TB --- 2011-11-28 15:43:17 - SRCCONF=/dev/null
TB --- 2011-11-28 15:43:17 - TARGET=mips
TB --- 2011-11-28 15:43:17 - TARGET_ARCH=mips
TB --- 2011-11-28 15:43:17 - TZ=UTC
TB --- 2011-11-28 15:43:17 - __MAKE_CONF=/dev/null
TB --- 2011-11-28 15:43:17 - cd /src
TB --- 2011-11-28 15:43:17 - /usr/bin/make -B buildworld
 World build started on Mon Nov 28 15:43:18 UTC 2011
 Rebuilding the temporary build tree
 stage 1.1: legacy release compatibility shims
 stage 1.2: bootstrap tools
 stage 2.1: cleaning up the object tree
 stage 2.2: rebuilding the object tree
 stage 2.3: build tools
 stage 3: cross tools
 stage 4.1: building includes
 stage 4.2: building libraries
 stage 4.3: make dependencies
 stage 4.4: building everything
[...]
c++ -O -pipe -G0 -Wsystem-headers -Werror 
-I/src/gnu/usr.bin/gperf/../../../contrib/gperf/lib -I/src/gnu/usr.bin/gperf -c 
/src/gnu/usr.bin/gperf/../../../contrib/gperf/src/search.cc
c++ -O -pipe -G0 -Wsystem-headers -Werror 
-I/src/gnu/usr.bin/gperf/../../../contrib/gperf/lib -I/src/gnu/usr.bin/gperf -c 
/src/gnu/usr.bin/gperf/../../../contrib/gperf/src/version.cc
c++ -O -pipe -G0 -Wsystem-headers -Werror 
-I/src/gnu/usr.bin/gperf/../../../contrib/gperf/lib -I/src/gnu/usr.bin/gperf -c 
/src/gnu/usr.bin/gperf/../../../contrib/gperf/lib/getline.cc
c++ -O -pipe -G0 -Wsystem-headers -Werror 
-I/src/gnu/usr.bin/gperf/../../../contrib/gperf/lib -I/src/gnu/usr.bin/gperf -c 
/src/gnu/usr.bin/gperf/../../../contrib/gperf/lib/hash.cc
c++ -O -pipe -G0 -Wsystem-headers -Werror 
-I/src/gnu/usr.bin/gperf/../../../contrib/gperf/lib -I/src/gnu/usr.bin/gperf  
-o gperf bool-array.o hash-table.o input.o keyword-list.o keyword.o main.o 
options.o output.o positions.o search.o version.o getline.o hash.o 
gzip -cn /src/gnu/usr.bin/gperf/../../../contrib/gperf/doc/gperf.1  gperf.1.gz
=== gnu/usr.bin/gperf/doc (all)
make: don't know how to make gperf.info. Stop
*** Error code 2

Stop in /src/gnu/usr.bin/gperf.
*** Error code 1

Stop in /src/gnu/usr.bin.
*** Error code 1

Stop in /src/gnu.
*** Error code 1

Stop in /src.
*** Error code 1

Stop in /src.
*** Error code 1

Stop in /src.
TB --- 2011-11-28 16:25:36 - WARNING: /usr/bin/make returned exit code  1 
TB --- 2011-11-28 16:25:36 - ERROR: failed to build world
TB --- 2011-11-28 16:25:36 - 1792.92 user 525.52 system 2571.67 real


http://tinderbox.freebsd.org/tinderbox-head-HEAD-mips-mips.full
___
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


[head tinderbox] failure on ia64/ia64

2011-11-28 Thread FreeBSD Tinderbox
TB --- 2011-11-28 15:34:43 - tinderbox 2.8 running on freebsd-current.sentex.ca
TB --- 2011-11-28 15:34:43 - starting HEAD tinderbox run for ia64/ia64
TB --- 2011-11-28 15:34:43 - cleaning the object tree
TB --- 2011-11-28 15:35:01 - cvsupping the source tree
TB --- 2011-11-28 15:35:01 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca 
/tinderbox/HEAD/ia64/ia64/supfile
TB --- 2011-11-28 15:35:22 - building world
TB --- 2011-11-28 15:35:22 - CROSS_BUILD_TESTING=YES
TB --- 2011-11-28 15:35:22 - MAKEOBJDIRPREFIX=/obj
TB --- 2011-11-28 15:35:22 - PATH=/usr/bin:/usr/sbin:/bin:/sbin
TB --- 2011-11-28 15:35:22 - SRCCONF=/dev/null
TB --- 2011-11-28 15:35:22 - TARGET=ia64
TB --- 2011-11-28 15:35:22 - TARGET_ARCH=ia64
TB --- 2011-11-28 15:35:22 - TZ=UTC
TB --- 2011-11-28 15:35:22 - __MAKE_CONF=/dev/null
TB --- 2011-11-28 15:35:22 - cd /src
TB --- 2011-11-28 15:35:22 - /usr/bin/make -B buildworld
 World build started on Mon Nov 28 15:35:23 UTC 2011
 Rebuilding the temporary build tree
 stage 1.1: legacy release compatibility shims
 stage 1.2: bootstrap tools
 stage 2.1: cleaning up the object tree
 stage 2.2: rebuilding the object tree
 stage 2.3: build tools
 stage 3: cross tools
 stage 4.1: building includes
 stage 4.2: building libraries
 stage 4.3: make dependencies
 stage 4.4: building everything
[...]
c++ -O2 -pipe -Wsystem-headers -Werror 
-I/src/gnu/usr.bin/gperf/../../../contrib/gperf/lib -I/src/gnu/usr.bin/gperf -c 
/src/gnu/usr.bin/gperf/../../../contrib/gperf/src/search.cc
c++ -O2 -pipe -Wsystem-headers -Werror 
-I/src/gnu/usr.bin/gperf/../../../contrib/gperf/lib -I/src/gnu/usr.bin/gperf -c 
/src/gnu/usr.bin/gperf/../../../contrib/gperf/src/version.cc
c++ -O2 -pipe -Wsystem-headers -Werror 
-I/src/gnu/usr.bin/gperf/../../../contrib/gperf/lib -I/src/gnu/usr.bin/gperf -c 
/src/gnu/usr.bin/gperf/../../../contrib/gperf/lib/getline.cc
c++ -O2 -pipe -Wsystem-headers -Werror 
-I/src/gnu/usr.bin/gperf/../../../contrib/gperf/lib -I/src/gnu/usr.bin/gperf -c 
/src/gnu/usr.bin/gperf/../../../contrib/gperf/lib/hash.cc
c++ -O2 -pipe -Wsystem-headers -Werror 
-I/src/gnu/usr.bin/gperf/../../../contrib/gperf/lib -I/src/gnu/usr.bin/gperf  
-o gperf bool-array.o hash-table.o input.o keyword-list.o keyword.o main.o 
options.o output.o positions.o search.o version.o getline.o hash.o 
gzip -cn /src/gnu/usr.bin/gperf/../../../contrib/gperf/doc/gperf.1  gperf.1.gz
=== gnu/usr.bin/gperf/doc (all)
make: don't know how to make gperf.info. Stop
*** Error code 2

Stop in /src/gnu/usr.bin/gperf.
*** Error code 1

Stop in /src/gnu/usr.bin.
*** Error code 1

Stop in /src/gnu.
*** Error code 1

Stop in /src.
*** Error code 1

Stop in /src.
*** Error code 1

Stop in /src.
TB --- 2011-11-28 16:32:24 - WARNING: /usr/bin/make returned exit code  1 
TB --- 2011-11-28 16:32:24 - ERROR: failed to build world
TB --- 2011-11-28 16:32:24 - 2658.14 user 590.20 system 3460.15 real


http://tinderbox.freebsd.org/tinderbox-head-HEAD-ia64-ia64.full
___
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: Problem compiling libs after pass to current

2011-11-28 Thread ZaRiuS KRiNG
Ok, the second know how make, but the first no.

How can set new uname -r in the environment? Sorry but in some things need
a lot of experience, and for that try use current

About what programs got the fail? Chromium and Abiword, with one, 2-3 with
second just one. But make that, pkg_add -r and continue with compiling but
want learn how solve the problem no, just evade it

Thanks for all

2011/11/28 Maciej Milewski m...@dat.pl

 Dnia niedziela, 27 listopada 2011 19:59:44 ZaRiuS KRiNG pisze:
  Hi! is my first post here and have a little problem try to google some
 and
  don't find any of value.
 
  A week ago compile the src of current, and after that in any new port i
  install, if compile before any lib, don't work, i need to install pkg
 from
  repository of that lib and continue compiling the program, and work fine.
  Just have this problem with the libs
 
  Any solution?
 Have you updated you ports tree? Maybe you are affected by the issue
 mentioned
 in ports/UPDATING:

 20110928:
  AFFECTS: users of 10-current
  AUTHOR: ead...@freebsd.org

  There are known issues installing ports on FreeBSD 10+ due to
  bogus assumptions by various build scripts. This will not be fixed
  until 9-RELEASE is released.

  There are two workarounds:

  1) Set UNAME_r=9.9-CURRENT in your environment
  2) Set REVISION=9.9 in  ${SRCDIR}/sys/conf/newvers.sh

 --
 Maciek

___
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: Building FreeBSD 10.0-CURRENT/amd64 of today fails (with clang and WITH_LIBCPLUSPLUS=YES)

2011-11-28 Thread O. Hartmann
Am 11/27/11 22:05, schrieb Garrett Cooper:
 On Sun, Nov 27, 2011 at 9:01 AM, O. Hartmann
 ohart...@zedat.fu-berlin.de wrote:
 Sources of FreeBSD 10.0-CUR/amd64 as svn-ed recently:

 Path: .
 Working Copy Root Path: /usr/src
 URL: svn://svn.freebsd.org/base/head
 Repository Root: svn://svn.freebsd.org/base
 Repository UUID: ccf9f872-aa2e-dd11-9fc8-001c23d0bc1f
 Revision: 228029
 Node Kind: directory
 Schedule: normal
 Last Changed Author: trociny
 Last Changed Rev: 228029
 Last Changed Date: 2011-11-27 17:56:01 +0100 (Sun, 27 Nov 2011)

 fail to build with the following error:
 
 Look for the first Error code in your output -- the line before that
 is the real error. That being said, there were some additional CFLAGS
 that needed to be fed in to make things work with libc++ and libcxxrt
 IIRC.
 Cheers,
 -Garrett


... thanks for the advice.
Is there any chance to find out which Flags one has to set (the WIKI
seems not to mention anything)?

Regards,
Oliver



signature.asc
Description: OpenPGP digital signature


Re: NFS + SVN problem?

2011-11-28 Thread Sean Bruno

 Oh, and don't hesitate to try NFSv4. It should do the locking correctly 
 without
 needing nolockd and the more testing it gets, the better.;-)
 
 rick
 
  Removing soft,intr had no effect. This, I suspect will be problematic
  for clusteradm@ if we start updating hosts in the cluster.
  
  Sean

Doesn't look like dumpster supports V4?

[tcp] dumpster:/vol/volshscratch: NFSPROC_NULL: RPC: Program/version
mismatch; low version = 2, high version = 3
mount_nfs: Cannot immediately mount dumpster:/vol/volshscratch,
backgrounding


___
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: Problem compiling libs after pass to current

2011-11-28 Thread Maciej Milewski
Dnia poniedziałek, 28 listopada 2011 18:55:04 ZaRiuS KRiNG pisze:
 Ok, the second know how make, but the first no.
 
 How can set new uname -r in the environment? Sorry but in some things need
 a lot of experience, and for that try use current
 
 About what programs got the fail? Chromium and Abiword, with one, 2-3 with
 second just one. But make that, pkg_add -r and continue with compiling but
 want learn how solve the problem no, just evade it
 
 Thanks for all
First: don't top post!
Second: you haven't answered the question if you have lately updated your 
ports.

As for setting uname please RTFM of uname, it's there.

Problem is known to be because of bad comparison done by automake/autoconf 
scripts.

Maciek

___
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: Building FreeBSD 10.0-CURRENT/amd64 of today fails (with clang and WITH_LIBCPLUSPLUS=YES)

2011-11-28 Thread Garrett Cooper
On Mon, Nov 28, 2011 at 10:11 AM, O. Hartmann
ohart...@zedat.fu-berlin.de wrote:
 Am 11/27/11 22:05, schrieb Garrett Cooper:
 On Sun, Nov 27, 2011 at 9:01 AM, O. Hartmann
 ohart...@zedat.fu-berlin.de wrote:
 Sources of FreeBSD 10.0-CUR/amd64 as svn-ed recently:

 Path: .
 Working Copy Root Path: /usr/src
 URL: svn://svn.freebsd.org/base/head
 Repository Root: svn://svn.freebsd.org/base
 Repository UUID: ccf9f872-aa2e-dd11-9fc8-001c23d0bc1f
 Revision: 228029
 Node Kind: directory
 Schedule: normal
 Last Changed Author: trociny
 Last Changed Rev: 228029
 Last Changed Date: 2011-11-27 17:56:01 +0100 (Sun, 27 Nov 2011)

 fail to build with the following error:

 Look for the first Error code in your output -- the line before that
 is the real error. That being said, there were some additional CFLAGS
 that needed to be fed in to make things work with libc++ and libcxxrt
 IIRC.
 Cheers,
 -Garrett


 ... thanks for the advice.
 Is there any chance to find out which Flags one has to set (the WIKI
 seems not to mention anything)?

Should be off by default; it can be enabled via WITH_LIBCPLUSPLUS.
-Garrett
___
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: bsdgrep --null has no effect

2011-11-28 Thread Gábor Kövesdán

On 2011.11.27. 12:07, Jan Beich wrote:

Oops, here is a diff. Non -l/-L case still seems to be broken.

   $ echo ta; echo tb; echo tc
   $ gnugrep --null . ? | vis
   a\^@t
   b\^@t
   c\^@t

   $ bsdgrep --null . ? | vis
   a\^@:t
   b\^@:t
   c\^@:t
Thanks Jan, I've just committed this and your other patch to HEAD and 
will MFC it soon.


Gabor
___
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: loader crash / BTX halted on 9.0-RC2 DVD with AMD pseudo-RAID

2011-11-28 Thread John Baldwin
On Tuesday, November 22, 2011 10:07:52 pm John Nielsen wrote:
 On Nov 22, 2011, at 10:26 AM, John Baldwin j...@freebsd.org wrote:
 
  On Monday, November 21, 2011 1:45:36 pm John Nielsen wrote:
  This weekend I downloaded the Freebsd 9.0 RC2 amd64 ISO image and burned 
  it 
  to a DVD. I have a computer that currently runs Windows 7 but I plan to 
  install FreeBSD on it in the near future so I booted it up from the DVD to 
  check the hardware/driver status. Much to my dismay, the boot loader 
  crashed 
  right away (register dump followed by BTX halted) and the computer 
  immediately rebooted. I took a video with my phone so I could capture the 
  crash message, screenshot here:
  
  http://picpaste.com/pics/BTXcrash.1321899682.jpg
  
  I then tried tweaking a few BIOS settings and found that turning off the 
  built-in pseudo-RAID allowed the DVD to boot normally. I changed the SATA 
  type 
  from RAID to AHCI. Fortunately I plan to use the controller in AHCI 
  mode 
  for the FreeBSD installation so this won't end up being a problem for me, 
  but 
  I still thought it was worth reporting.
  
  Hmmm, so this is odd.  It died with an Invalid TSS exception on the iret 
  instruction at the end of the return-from-real-mode trampoline in BTX.  
  Looking at the dump I noticed that PSL_NT is set in %eflags, so for some 
  reason the iret was trying to do a nested task return.  We shouldn't let
  that flag leak out of any real mode code.  Try this patch perhaps:
 
 Thanks for looking!
 
 I put gptboot on a USB stick and tried it with and without the patch.
 Identical behavior in both cases to booting from the DVD (only faster)--BTX
 dump and an instant reboot. I didn't do a screen capture yet but will be
 happy to tomorrow if it will help.

A screen capture would be useful.  It may be that I did not fix the right
copy of the flags.

-- 
John Baldwin
___
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: Building FreeBSD 10.0-CURRENT/amd64 of today fails (with clang and WITH_LIBCPLUSPLUS=YES)

2011-11-28 Thread O. Hartmann
Am 11/28/11 20:10, schrieb Garrett Cooper:
 On Mon, Nov 28, 2011 at 10:11 AM, O. Hartmann
 ohart...@zedat.fu-berlin.de wrote:
 Am 11/27/11 22:05, schrieb Garrett Cooper:
 On Sun, Nov 27, 2011 at 9:01 AM, O. Hartmann
 ohart...@zedat.fu-berlin.de wrote:
 Sources of FreeBSD 10.0-CUR/amd64 as svn-ed recently:

 Path: .
 Working Copy Root Path: /usr/src
 URL: svn://svn.freebsd.org/base/head
 Repository Root: svn://svn.freebsd.org/base
 Repository UUID: ccf9f872-aa2e-dd11-9fc8-001c23d0bc1f
 Revision: 228029
 Node Kind: directory
 Schedule: normal
 Last Changed Author: trociny
 Last Changed Rev: 228029
 Last Changed Date: 2011-11-27 17:56:01 +0100 (Sun, 27 Nov 2011)

 fail to build with the following error:

 Look for the first Error code in your output -- the line before that
 is the real error. That being said, there were some additional CFLAGS
 that needed to be fed in to make things work with libc++ and libcxxrt
 IIRC.
 Cheers,
 -Garrett


 ... thanks for the advice.
 Is there any chance to find out which Flags one has to set (the WIKI
 seems not to mention anything)?
 
 Should be off by default; it can be enabled via WITH_LIBCPLUSPLUS.
 -Garrett
 ___


Hello Garrett.
Yes, it is off by default and the system build well with this feature
off by default. But when enabling WITH_LIBCPLUSPLUS in /etc/src.conf,
I get always the error I started this thread with.

Well, either this is a real error and I should PR, or it is my
impatience that tries to use something still getting merged.

I tried to look at the wiki for that, but it does not mention anything
else apart the flag WITH_LIBCPLUSPLUS. No additional CFLAGS or something
... so I'm a little bit confused.

Regards,
Oliver



signature.asc
Description: OpenPGP digital signature


Re: iSCSI initiator: iscontrol cannot be stopped or killed

2011-11-28 Thread Xin LI
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On 11/23/11 16:26, Mark Martinec wrote:
 Problem: the iscontrol process starts normally and establishes a
 session and brings up a device, but it cannot be stopped. It does
 not react to a HUP signal, and neither to KILL.
 
 The /dev/da0 device is operational and the remote disk remains 
 normally accessible, regardless of how I try to (unsuccessfully) 
 shutdown the iscontrol process. The ps reports the state of the 
 process as Ds, not doing anything. A ktrace does not show any 
 reaction to a received signal. A restart seems to be necessary to
 break the iSCSI session.
 
 Using FreeBSD 9.0-rc2, amd64, also tried with 9.0-PRERELEASE (csup
 tag=RELENG_9 as of today).  This used to work normally as
 documented on the same host with the same iscsi.conf config file
 before upgrading from 8.2 to 9.0.
 
 Anybody else experiencing this problem? Suggestions welcome.

Try procstat -kk pid to find the calling stack, as a start?  This
could be very useful when tracking down problems.

Also the 'D' flag from ps(1) output in most times are not quite useful
and ps -o wchan would tell you what exactly it was waiting for, just FYI.

Cheers,
- -- 
Xin LI delp...@delphij.nethttps://www.delphij.net/
FreeBSD - The Power to Serve!   Live free or die
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.18 (FreeBSD)

iQEcBAEBCAAGBQJO1BXMAAoJEATO+BI/yjfBd2AIAJW1xHR93fN5eROUz9rs1YiX
8ANhcPTLmScN04YJb65ytm/BYUVKAtUN/rct2seZPosHO+REvYJhF7Tz5DKRRHJX
h+LG65S3HNBR9GBLdadw5BusbvU+T18oTvrxnqPtB1vcn5pEvQk0xtw3M3R/PrIu
V45mACO0f51auQl8oHfTUKzY48k06eDszyQhlrGCbY1FTydUU2e8AqJKd6GEIx31
f6kd0WGTpcIam6WdONpTR08d2HoPp/zK0gUADW+S2NiKfzDCy/PvJL+02lK2YlEy
M6dvnk62X6Tfkv1SV947WZT57UMDZkXbVNgwjvxwT5tSKUUbeGGvm241ZnLN2HI=
=IZ2x
-END PGP SIGNATURE-
___
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: Building FreeBSD 10.0-CURRENT/amd64 of today fails (with clang and WITH_LIBCPLUSPLUS=YES)

2011-11-28 Thread Garrett Cooper
On Mon, Nov 28, 2011 at 2:59 PM, O. Hartmann
ohart...@zedat.fu-berlin.de wrote:
 Am 11/28/11 20:10, schrieb Garrett Cooper:
 On Mon, Nov 28, 2011 at 10:11 AM, O. Hartmann
 ohart...@zedat.fu-berlin.de wrote:
 Am 11/27/11 22:05, schrieb Garrett Cooper:
 On Sun, Nov 27, 2011 at 9:01 AM, O. Hartmann
 ohart...@zedat.fu-berlin.de wrote:
 Sources of FreeBSD 10.0-CUR/amd64 as svn-ed recently:

 Path: .
 Working Copy Root Path: /usr/src
 URL: svn://svn.freebsd.org/base/head
 Repository Root: svn://svn.freebsd.org/base
 Repository UUID: ccf9f872-aa2e-dd11-9fc8-001c23d0bc1f
 Revision: 228029
 Node Kind: directory
 Schedule: normal
 Last Changed Author: trociny
 Last Changed Rev: 228029
 Last Changed Date: 2011-11-27 17:56:01 +0100 (Sun, 27 Nov 2011)

 fail to build with the following error:

 Look for the first Error code in your output -- the line before that
 is the real error. That being said, there were some additional CFLAGS
 that needed to be fed in to make things work with libc++ and libcxxrt
 IIRC.
 Cheers,
 -Garrett


 ... thanks for the advice.
 Is there any chance to find out which Flags one has to set (the WIKI
 seems not to mention anything)?

 Should be off by default; it can be enabled via WITH_LIBCPLUSPLUS.
 -Garrett
 ___


 Hello Garrett.
 Yes, it is off by default and the system build well with this feature
 off by default. But when enabling WITH_LIBCPLUSPLUS in /etc/src.conf,
 I get always the error I started this thread with.

 Well, either this is a real error and I should PR, or it is my
 impatience that tries to use something still getting merged.

 I tried to look at the wiki for that, but it does not mention anything
 else apart the flag WITH_LIBCPLUSPLUS. No additional CFLAGS or something
 ... so I'm a little bit confused.

Read through http://osdir.com/ml/freebsd-current/2011-11/msg00718.html
-- in particular:

libcxxrt and libc++ are now in contrib and building with the base system, but
are not used by anything (and are only built if you set WITH_LIBCPLUSPLUS=yes
when building world, not by default). If you want to test some code with the
new stack, you need to build it and then specify  -stdlib=libc++  to clang++
(both when compiling and linking).

That being said, if there's something else that's required I've CCed
David for visibility. I would definitely include the full build log
somewhere else so someone can analyze the error.

Cheers,
-Garrett
___
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: bsdgrep --null has no effect

2011-11-28 Thread O. Hartmann
Am 11/28/11 21:23, schrieb Gábor Kövesdán:
 On 2011.11.27. 12:07, Jan Beich wrote:
 Oops, here is a diff. Non -l/-L case still seems to be broken.

$ echo ta; echo tb; echo tc
$ gnugrep --null . ? | vis
a\^@t
b\^@t
c\^@t

$ bsdgrep --null . ? | vis
a\^@:t
b\^@:t
c\^@:t
 Thanks Jan, I've just committed this and your other patch to HEAD and
 will MFC it soon.
 
 Gabor

After the patch of grep the mentioned port astro/stellarium build
perfectly again!

Thanks a lot for fast resposne.

Regards,
Oliver



signature.asc
Description: OpenPGP digital signature


Re: if_clone.c allows creating multiple interfaces with the same name

2011-11-28 Thread Daan Vreeken
Hi Glebius,

On Friday 25 November 2011 15:32:58 Gleb Smirnoff wrote:
 On Fri, Nov 25, 2011 at 05:19:35PM +0400, Gleb Smirnoff wrote:
 T On Thu, Nov 24, 2011 at 09:28:51AM +0100, Daan Vreeken wrote:
 T D Recently I've discovered a bug in if_clone.c and if.c where the code
 allows T D multiple interfaces to be created with exactly the same name
 (which leads to T D all sorts of other interesting problems).
 T D I've submitted a PR about this with patches, which can be found here
 : T D
 T D http://www.freebsd.org/cgi/query-pr.cgi?pr=162789
 T D
 T D Could anyone take a look at it?
 T
 T I decided to simply if_clone code utilizing generic unit allocator.
 Patch T atteched. Now I'll try to merge it with your ideas.

 Here is if_cloner patched with additional ifunit() check, as you suggested.
 Please review my patch and test it, and then we can commit it.

Thanks for the looking into this and for your quick commit. I like your twist
on the patch with the move from the unit bitmap to allocating unit numbers
with alloc_unr(9).

I do have two comments on the new code though.
Before, in the !wildcard case, ifc_alloc_unit() would return ENOSPC when the
user requested a unit number larger than ifc-ifc_maxunit. Now the function
returns EEXIST in that case because alloc_unr_specific() returns -1 both
when a number is already allocated and when the number exceeds it's limits.
This leads to the somewhat confusing:

# ifconfig bridge123456 create
ifconfig: SIOCIFCREATE2: File exists

Apart from that I'm a bit worried about the /* XXXGL: yep, it's a unit leak
*/ part of your change. Once a unit number is leaked, there currently seems
to be no way to ever get it back. In a worst case scenario, where the names of
multiple interfaces in a row collides with the numbers alloc_unr() returns, an
entire row of unit numbers could be leaked during the creation of a single
cloned interface.
We have a product where cloned interfaces come and go very frequently. I'd
hate to run out of unit numbers after 'just a few' years of uptime ;-)

I've created a new patch on top of your change that fixes both of these
problems. Could you have a look at the attached diff?
In case the attachment doesn't survive the list, it can also be found here:


http://www.vitsch.nl/pub-diffs/if_clone-ENOSPC-and-unr-leak-fix-2011-11-29.diff


 Considering the second part, that adds locking. Unfortunately, right now we
 have numerous races in the network configuration ocde. Many SIOCSsomething
 ioctls can race with each other producing unpredictable results and kernel
 panics. So, running two ifconfig(8) in parallel is a bad idea today. :(
 Your patch with IFNET_NAMING_LOCK() just plumbs one race case: a race
 between two SIOCSIFNAME ioctls. And it doesn't plumb a race between
 SIOCSIFNAME vs SIOCIFCREATE, because IFNET_NAMING_LOCK() is dropped after
 unit allocation, but prior to interface attachement to global interface
 list.

Are you sure? With the patch in the PR, the relevant code in 
ifc_simple_create() would become :

...
IFNET_NAMING_LOCK();
err = ifc_alloc_unit(ifc, unit);
if (err != 0) {
IFNET_NAMING_UNLOCK();
return (err);
}

err = ifcs-ifcs_create(ifc, unit, params);
IFNET_NAMING_UNLOCK();
if (err != 0) {
ifc_free_unit(ifc, unit);
return (err);
}
...

The lock is acquired before the call to ifc_alloc_unit().
In the non-error case (e.g. when creating an if_bridge interface) the call
ends up calling bridge_clone_create(), which calls ether_ifattach(), which
calls if_attach() - if_attach_internal() where the ifp is added to the ifnet
list.
Only when that's done, the lock is dropped.

Am I overlooking something obvious here?


 From my point of view, we need a generic approach to ioctl() vs ioctl()
 races, may be some global serializer of all re-configuration requests of
 interfaces and addresses.


Thanks,
-- 
Daan Vreeken
Vitsch Electronics
http://Vitsch.nl
tel: +31-(0)40-7113051 / +31-(0)6-46210825
KvK nr: 17174380
Index: sys/net/if_clone.c
===
--- sys/net/if_clone.c	(revision 228109)
+++ sys/net/if_clone.c	(working copy)
@@ -436,30 +436,49 @@
 }
 
 int
-ifc_alloc_unit(struct if_clone *ifc, int *unit)
+ifc_alloc_unit(struct if_clone *ifc, int *unit_nr)
 {
 	char name[IFNAMSIZ];
-	int wildcard;
+	int ret, unit, wildcard;
 
-	wildcard = (*unit  0);
+	unit = *unit_nr;
+	wildcard = (unit  0);
 retry:
-	if (wildcard) {
-		*unit = alloc_unr(ifc-ifc_unrhdr);
-		if (*unit == -1)
+	if (unit  ifc-ifc_maxunit)
+		return (ENOSPC);
+
+	if (unit  0) {
+		/* first, try to allocate a unit number automatically */
+		unit = alloc_unr(ifc-ifc_unrhdr);
+		if (unit == -1)
 			return (ENOSPC);
 	} else {
-		*unit = alloc_unr_specific(ifc-ifc_unrhdr, *unit);
-		if (*unit == -1)
-			return (EEXIST);
+		ret = 

Re: WITHOUT_PROFILE=yes by default

2011-11-28 Thread Doug Barton
On 11/28/2011 02:38, Max Khon wrote:
 Are there any compelling reasons for having profiled libs to be built by
 default?

Nope. It's been one of the first things I disable after I install a new
system for at least a decade.

Ideally we could do this for 9.0.


Doug

-- 

We could put the whole Internet into a book.
Too practical.

Breadth of IT experience, and depth of knowledge in the DNS.
Yours for the right price.  :)  http://SupersetSolutions.com/

___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org


Re: WITHOUT_PROFILE=yes by default

2011-11-28 Thread Poul-Henning Kamp
In message 4ed4222e.5010...@freebsd.org, Doug Barton writes:
On 11/28/2011 02:38, Max Khon wrote:

 Are there any compelling reasons for having profiled libs to be built by
 default?

Nope. It's been one of the first things I disable after I install a new
system for at least a decade.

Ideally we could do this for 9.0.

Can we at least keep one (small) library compiled for profiling, so
that compiling for profiling doesn't get broken by accident ?

-- 
Poul-Henning Kamp   | UNIX since Zilog Zeus 3.20
p...@freebsd.org | TCP/IP since RFC 956
FreeBSD committer   | BSD since 4.3-tahoe
Never attribute to malice what can adequately be explained by incompetence.
___
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: WITHOUT_PROFILE=yes by default

2011-11-28 Thread Doug Barton
On 11/28/2011 16:33, Poul-Henning Kamp wrote:
 In message 4ed4222e.5010...@freebsd.org, Doug Barton writes:
 On 11/28/2011 02:38, Max Khon wrote:
 
 Are there any compelling reasons for having profiled libs to be built by
 default?

 Nope. It's been one of the first things I disable after I install a new
 system for at least a decade.

 Ideally we could do this for 9.0.
 
 Can we at least keep one (small) library compiled for profiling, so
 that compiling for profiling doesn't get broken by accident ?

I think WITH_PROFILE is probably a good idea for the tinderbox?


-- 

We could put the whole Internet into a book.
Too practical.

Breadth of IT experience, and depth of knowledge in the DNS.
Yours for the right price.  :)  http://SupersetSolutions.com/

___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org


upgrade issue 8.x to 9.0-RC2: libz.so.5 not found

2011-11-28 Thread allan

Hello everyone,

First a quick introduction, then my project, then my problem.

==My FreeBSD involvement==

I've been dabbling with FreeBSD since I set up stokes.ca at pair.com over
a decade ago.  I liked the service at Pair, so I installed FreeBSD at home
on a spare box.  One of those evil Fujitsu disk drives took out my stable
4.x test system before I had a complete set of backups (Fujitsu was early
into fluid dynamic bearings and I purchased on acoustics).  I won't pain
anyone by recalling the 5.x experience that followed.  I had a 6.x system
for a long time, but it never got much beyond a quasi offline backup
spool.  The 30GB system disk finally conked out--this was expected, so I
slapped a new system disk into a box that had previously been my
workstation, and performed a fresh 8 series installation.

Unfortunately, I was never able to mount my PATA backup drive because of
issues with the JMicron 363 PATA controller chip on the Asus P5B.  These
issues still exist in 9.x FWIW.  Last week I finally shut down my
firewall, stretched the drive cables across (to a different Core Duo
mainboard not afflicted with a JMicron PATA controller) and scarfed the
aging data.  I had the data elsewhere in bits and pieces so there was
never great urgency, the value was mainly that this was my only
_organized_ backup set.

==7 men EGTB==

I'm getting more serious about FreeBSD again because I'm becoming involved
over the next few years in a hobby project to compute the chess
seven-piece EGTB data set, which will total 60TB I think, when someday the
computation completes.  I'm mostly interested in compressed disk
representations which permit high access speed that can be used by chess
engines in real time.  I might do a few pieces of the retrograde
computation myself, but nowhere close to the whole thing.  To perform the
computation with full chess accuracy you need to begin with maximal
promotion: two kings and five queens, and then work down through crazy
promotions, such as two kings and five bishops, and then finally to
positions that could possibly someday occur in a real chess game: many
terabytes of computationally intense bootstrap to cover some very tiny
corner cases (how tiny is a question I'm interested to explore, but most
chess purists aren't).

Even a small piece of the project would generate copious data so I've
rigged up an experimental ZFS v28 box with a triple mirror on three 500GB
disks I had lying around (two slightly enterprisy, one a Seagate refurb). 
I think of it as a two-way mirror with a pre-silvered hot spare that's
better than nothing.  I put 6GB of memory into the box and tried out
deduplication.  It ran great.  I don't expect to use this feature (in
hobby production) any time soon.  I'll probably upgrade all the drives
after the waters recede in Thailand and run fairly basic parameters.

This week I'm intending to purchase a pair of Intel 311 SSD drives (20GB
SLC) as a mirrored ZIL or ZIL/ARC option (Newegg.ca has them for $110). 
Warn me soon if I'm doing something stupid!  I wish my ZFS box had
chipkill ECC, but that upgrade is out of my budget at present, since it
involves a whole new system board, CPU, and memory.  I'm going to have to
live a bit on the edge with other backups (and integrity checksums)
available.  I have some general interest in testing out what ZFS can do on
fully configured box.  I also do a lot of R programming and I'm
experimenting with HDF5 for large data sets.  The ZIL upgrade doesn't
pertain much to my EGTB project.

I'm either not brave enough or insane enough to put my FreeBSD system
volume onto the ZFS mirror, as much as that seems kind of cool.  Plain old
UFS on a separate drive for me.  Have others had success with ZFS system
volumes?

==Broken upgrade problem==

I was able to do a binary upgrade from 8.x to 9.0-RC2-p0.  Slick.  I once
skimmed Colin's thesis, but the math is heavy--I understood enough to
grasp that it's an excellent piece of work, and certainly much
appreciated.

After the binary upgrade my system runs well enough to initiate a ZFS pool
and survive some ZFS pounding over the network (20GB data set with a
recursive symlink deduplicated many times over until I finally killed it).

However, programs such as startx and portupgrade are failing with the
message libz.so.5 not found.  I know I can fix this with an evil
symlink, but that doesn't seem right, and what else is broken?  Is there
not a facility in portupgrade to scan my live dependencies and warn me of
breakage?  I have not encountered such a beast in my gleanings to date.

On the first pass I skipped the package build step in my haste to break
everything.  That didn't work well (of course), so I rolled it back
(sweet) and followed instructions: including the Ruby preamble and the
triple Beetlejuice freebsd-update incantation.

If there's an easy way to fix the mess, I'll do so, but otherwise there's
no reason not to repair the problem with the blunt tool of a fresh system
installation.  

Re: WITHOUT_PROFILE=yes by default

2011-11-28 Thread Max Khon
Doug,

On Tue, Nov 29, 2011 at 7:35 AM, Doug Barton do...@freebsd.org wrote:

 Are there any compelling reasons for having profiled libs to be built by
  default?
 
  Nope. It's been one of the first things I disable after I install a new
  system for at least a decade.
 
  Ideally we could do this for 9.0.
 
  Can we at least keep one (small) library compiled for profiling, so
  that compiling for profiling doesn't get broken by accident ?

 I think WITH_PROFILE is probably a good idea for the tinderbox?


Who is in charge for tinderbox these days?

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


removing libreadline from base system

2011-11-28 Thread Max Khon
Hello!

It is possible to build and link our in-tree gdb  friends with libedit
after r228114.

The remaining question is what to do with libreadline:

1) just build  link gdb with libedit

OR

2) re-import libreadline from gdb sources and build INTERNALLIB version of
it that is never installed and is linked only to gdb

I am inclined to go for 1) but libedit may have (and has) incompatibilities
with libreadline.

Max
___
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: upgrade issue 8.x to 9.0-RC2: libz.so.5 not found

2011-11-28 Thread Martin Sugioarto
Am Mon, 28 Nov 2011 17:49:50 -0800
schrieb al...@stokes.ca:

 Hello everyone,

Hi,

(I'll shorten this a bit, because I don't have opinions on everything
you wrote)
 
 I'm either not brave enough or insane enough to put my FreeBSD system
 volume onto the ZFS mirror, as much as that seems kind of cool.
 Plain old UFS on a separate drive for me.  Have others had success
 with ZFS system volumes?

Since 8.2 I can confirm that ZFS was stable enough for me. But I have
to admit that I'm still a bit sceptical because (even it's been long
time ago) once I ended up with a broken zpool that spewed panics on
zpool initialization. That was a horrible experience that I won't
forget that easily.
 
 However, programs such as startx and portupgrade are failing with the
 message libz.so.5 not found.  I know I can fix this with an evil
 symlink, but that doesn't seem right, and what else is broken?  Is
 there not a facility in portupgrade to scan my live dependencies and
 warn me of breakage?  I have not encountered such a beast in my
 gleanings to date.

There is a little helper in port sysutils/bsdadminscripts called
pkg_libchk.

I use this tool very often like this:

pkg_libchk -qo  broken.txt

And then I cat it to portmaster:

portmaster -d `cat broken.txt`

I don't know anymore how the portmaster step works with portupgrade,
you need to figure this out by yourself.
 
--
Martin


signature.asc
Description: PGP signature