Re: current sluggish under load in the last few weeks

[b. f.]

 Has something changed in the scheduler recently?

Yes: r242736, r242852+r243069.

Your description of your problem is a bit vague, but you might start
by looking at the effect of the above commits.

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: Why Are You NOT Using FreeBSD?

[b. f.]

 On 05 June 2012 15:33:16 Mark Andrews wrote:
 
  In message 2490439.EC638TI0j3 at x220.ovitrap.com, Erich writes:
   Hi,
  
   On 05 June 2012 12:48:20 Mark Andrews wrote:
   
In message 3506767.Fvm2KmtnYf at x220.ovitrap.com, Erich writes:

 On 05 June 2012 11:24:25 Mark Andrews wrote:
 

   
It's already there.  If you want the ports as of FreeBSD 4.x EOL
then the tag is RELEASE_4_EOL.  If you want ports as of FreeBSD
9.0 then the tag is RELEASE_9_9_0.
   
   I did not know this. Do you have a link for this? I never read about it.
 
  http://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/cvs-tags.html

 All of these, with the exception of HEAD (which is always a valid tag), only 
 apply to the src/ tree. The ports/, doc/, and www/ trees are not branched.

 I understand this that I can use these tags on the FreeBSD sources but not on 
 the ports.

 I never tried this on the ports.

I sent a long reply to your earlier message on freebsd-ports
explaining exactly this -- how each Ports tree snapshot has a version
number: the date spec.  Also, how a few special snapshots also have a
second version number: the release tag.  I also explained how to find
and use these, with and without cvs.  Am I wasting my time by trying
to answer your questions, E.?

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: Why Are You NOT Using FreeBSD?

[b. f.]

On 6/5/12, Erich erichfreebsdl...@ovitrap.com wrote:
 Hi,

 On 05 June 2012 3:08:17 b. f. wrote:
  On 05 June 2012 15:33:16 Mark Andrews wrote:
  
   In message 2490439.EC638TI0j3 at x220.ovitrap.com, Erich writes:
Hi,
   
  All of these, with the exception of HEAD (which is always a valid tag),
  only apply to the src/ tree. The ports/, doc/, and www/ trees are not
  branched.
 
  I understand this that I can use these tags on the FreeBSD sources but
  not on the ports.
 
  I never tried this on the ports.

 I sent a long reply to your earlier message on freebsd-ports
 explaining exactly this -- how each Ports tree snapshot has a version
 number: the date spec.  Also, how a few special snapshots also have a
 second version number: the release tag.  I also explained how to find
 and use these, with and without cvs.  Am I wasting my time by trying
 to answer your questions, E.?

 I think that you missed my point. The point is that this has to be made
 available for beginners. As long as the handbook states that this does not
 apply to the ports tree, at least beginners will stop there.

If you had hoped to make your point by feigning ignorance of something
that you had just been told on another list, then, yes, I missed your
point -- it was a decidedly subtle one.  You write in this thread:

I did not know this. Do you have a link for this? I never read about it.

Despite the fact that I explained it to you earlier, with an example:

http://lists.freebsd.org/pipermail/freebsd-ports/2012-June/075491.html

The part of the Handbook that you cited above, at:

http://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/cvs-tags.html

is the introduction to A.7.1. It refers only to branch tags, and not
to the release tags discussed in A.7.2, where the ports release tags
are mentioned.  This was also in my earlier message, along with the
comment that A.7.2 could be improved.

As far as the version numbers are concerned, I do not understand what
you want.  I already told you how you could use the existing version
numbers with a one-line modification to a sup file, or via cvs.  Do
you want the date spec of the ports tree to be included in the name of
the port tarballs distributed on the FreeBSD server?  Or that you want
portsnap to get a feature to selectively roll-back to earlier ports
tree snapshots?  Or that you simply want changes to the documentation,
explaining how to roll back?  As I told you, I'm a bit skeptical that
your hypothetical beginner, after having encountered a problem
building a port, would usually be able to diagnose the problem and
find the right snapshot to use.  And those that aren't beginners could
probably figure out how to do so with the documentation that already
exists.  But I suppose that the document committers would consider a
proposal to add an example of how to perform a roll-back.

If you want to discuss this further, please move it to a new topic on
the freebsd-ports or freebsd-doc lists, which seem more appropriate.

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: Why Are You NOT Using FreeBSD?

[b. f.]

...
 In any case, suppose a customer comes and asks for an application that
 uses PNG, you just updated your ports tree and then you either:

 1. Have already libpng installed.
 Then you just don't rebuild libpng, just install the new software. You
 do this by going to the ports directory like
 /usr/ports/cathegory/greatstuff and type make install. This will use
 the existing libpng on your system. No trouble.

... except the name of the libpng shared library changed, so the
builds of many ports will fail because they'll look for libpng15
instead of libpng.  Problem.  You could use local modifications to
your tree, or symlinks and libmap.conf(5) settings, to work around
this in many cases, but it would be a nuisance. Also, some other ports
may have been patched to work with the new shared library.  In this
case, it won't make much difference, but, speaking more generally
about updates of this kind, there may be problems.


 2. Don't have libpng installed yet.
 You install the new port any way you like. Since you have no libpng on
 your system, you have no dependencies to upgrade (and wait). You will
 end up with the new libpng on your system. No trouble.


... except that it usually takes a few days for some of the bugs to be
found and fixed, and the dust to settle, even for major updates that
have undergone routine testing.  So if you have a tight deadline,
there could be a problem, because some of your builds may fail due to
unexpected interactions with other software, non-default settings,
etc.  Or some updated software may work differently or improperly.

 Applying some common sense to these situations helps great deal. It also
 helps to avoid any prejudice towards FreeBSD or whatever OS you end up
 using in the process.

Yes.  The sensible thing to do is to check to see that you're not updating your
ports tree immediately after major changes have been made, if you're concerned
about stability, and you don't have much time to fix things. If you have
updated your tree, back-up your installed packages before attempting
to update them
(pkg_create -b, pkgng backup, etc.).  If you then find that the new version
of the tree is unsuitable, you can revert to an earlier snapshot using
cvs/csup and release/date tags, roll back to your old packages, and proceed.

These issues are not peculiar to FreeBSD, and we expect to see
continued improvement in both Ports and the use of packages.

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: Use of C99 extra long double math functions after r236148

[b. f.]

  I do think we should provide something in ports as an interim solution.
  There are other 3rd party applications looking to drop FreeBSD support
  because we are missing APIs that almost all other OS's have.  I'm fine
  if the interim lives in ports and that we don't import substandard
  routines into the base.  I would even be fine with calling it
  /usr/local/lib/libm_inaccurate.so.  However, I do think we need an option.
 

 I think it should be called libm.so.  Otherwise we have to do a serious
 editing job on the Makefiles/configure scripts.

I think that this is as it should be: only those applications that
really need to link against such a library should do so, and this
should be enforced and checked by the port maintainer.  If you call it
by the same name you still need to make other changes to ensure that
the right library is used, and these other changes can be confusing
and lead to problems, as with the openssl and gcc support libraries.
Some portable applications already provide convenient variables in
their build infrastructure, since the quality, coverage, and location
of the math libraries varies on different systems.

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: Use of C99 extra long double math functions after r236148

[b. f.]

 Do we have a wiki page listing the functions in libm we are missing?
 Having some kind of place to track progress and figure out what
 exactly is needed is the first step to getting these APIs into shape.

I already suggested this, and mentioned:

http://wiki.freebsd.org/MissingMathStuff

 Also, are there BSD licensed naive implementations of these functions
 we can use? Would it be okay to have slow, but accurate versions of
 these functions as a stopgap?

I don't know of any BSD-licensed routines that would be suitable for
use in the base system.  You can cobble together replacements from
various ports, with different licenses.  For example, if you wanted
accuracy and correctness, but didn't care about speed, you could use
math/mpc and math/mpfr.  Unfortunately, with many naive
implementations, you often lose more than just speed.

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: Use of C99 extra long double math functions after r236148

[b. f.]

This discussion confirms my impression, that it should be possible as an
interim solution, to use a port for missing math functions (cephes alike
or whatever). The port itself could warn the user about inaccuracies and
edge-cases.

Parts of Cephes are already in ports: math/ldouble.  I had planned to
add the remainder.  It can be useful, but it has problems, some of
which have been described.  The same is true of other open-source
alternatives that I am aware of.


I would be happy to take on any steep learning curve, and make
contributions, if only I were part of a group that would steer me in the
right direction.


A Functional Analyst offering to write code for a floating-point math
library!?!! ;)  You should send me a message off-list: maybe I can
find some time to help.


Anyway, given that floating point is a big issue, and we are about a
decade behind schedule, really suggests that a
floating-point at freebsd.org mailing list is needed.  Or maybe there is an
existing freebsd mailing list you guys already occupy.


I do not know that a separate FreeBSD mailing list would be of great
help, considering the likely volume of traffic, and the fact that we
already have the standards mailing list.  There is also:

http://mailman.oakapple.net/pipermail/numeric-interest/

which serves, among other things, as a forum for discussing changes
and improvements to the open-source math library from which parts of
our system math library were derived:

http://mailman.oakapple.net/pipermail/numeric-interest/2010-September/002054.html

A wiki page detailing problems and procedures, with a wish list for
the system libraries and toolchain(s) might help.  At present there
are only scattered messages in the mailing list archives, PRs, and
http://wiki.freebsd.org/MissingMathStuff .

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: make delete-old performance.

[b. f.]

 I recently ran make delete-old on a -current box and felt it was
 rather slow.  That prompted me to do some more careful experiments.

 On one box where I have both 8-stable and 9-stable available, there
 was a ~30x slowdown (based on 5 runs, ignoring the first).  I don't
 have a -current world on that box so I can't directly compare but on
 another pair of fairly similar boxes, I get a ~180x slowdown between
 8-stable and -current (and that figure is probably optimistic since
 the -current box was idle whereas the 8-stable box was fairly busy).

 I realise that make delete-old isn't something you nede to do every
 day but going from sub-second to multi-minute duration is quite
 noticable.  Can anyone suggest what has caused the change?

The slowdown is probably due - at least in part - to two factors:

- the list of files to be checked for removal has grown substantially,
because missing entries for old knobs and new entries for new knobs
have been added; and

- a new (and slower) method of checking was added in:
http://svnweb.FreeBSD.org/base?view=revisionrevision=220255
because the old method broke down with the size of the new lists of files.

Some changes could be made to lessen the affect of the latter.

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: ctfmerge core dump

[b. f.]

Steve Wills wrote:
 After updating from -CURRENT as of April 5 to one built today, I now get
 a core dump running ctfmerge on libc:

 ctfmerge -L VERSION -g -o libc.so.7 syscall.So fork.So..
 Bus error (core dumped)
 *** [libc.so.7] Error code 138

 Anyone else seeing this or have any idea how to avoid it?

Yes, I'm also seeing such problems when attempting to build a r235052
amd64 kernel on r235035 amd64. (This problem did not occur when
building a r235035 amd64 world and kernel on r234854 amd64.)  ctfmerge
succeeds for several kernel modules but fails with kgssapi.ko.debug,
linux.ko.debug, or kernel.debug. I'm not yet sure which change has
caused this, or how to avoid it.

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: ctfmerge core dump

[b. f.]

On 5/5/12, Steve Wills swi...@freebsd.org wrote:
 On 05/05/12 15:43, b. f. wrote:
 Steve Wills wrote:
 After updating from -CURRENT as of April 5 to one built today, I now get
 a core dump running ctfmerge on libc:

 ctfmerge -L VERSION -g -o libc.so.7 syscall.So fork.So..
 Bus error (core dumped)
 *** [libc.so.7] Error code 138

 Anyone else seeing this or have any idea how to avoid it?

 Yes, I'm also seeing such problems when attempting to build a r235052
 amd64 kernel on r235035 amd64. (This problem did not occur when
 building a r235035 amd64 world and kernel on r234854 amd64.)  ctfmerge
 succeeds for several kernel modules but fails with kgssapi.ko.debug,
 linux.ko.debug, or kernel.debug. I'm not yet sure which change has
 caused this, or how to avoid it.


 Thanks for the info. I took a look at the dump and see this:

 % sudo gdb /usr/bin/ctfmerge ctfmerge.core
 [GDB will not be able to debug user-mode threads: Undefined symbol
 td_thr_getxmmregs]
 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...
 Core was generated by `ctfmerge'.
 Program terminated with signal 10, Bus error.
 Reading symbols from /lib/libctf.so.2...done.
 Loaded symbols for /lib/libctf.so.2
 Reading symbols from /usr/lib/libdwarf.so.3...done.
 Loaded symbols for /usr/lib/libdwarf.so.3
 Reading symbols from /usr/lib/libelf.so.1...done.
 Loaded symbols for /usr/lib/libelf.so.1
 Reading symbols from /lib/libz.so.6...done.
 Loaded symbols for /lib/libz.so.6
 Reading symbols from /lib/libthr.so.3...done.
 Loaded symbols for /lib/libthr.so.3
 Reading symbols from /lib/libc.so.7...done.
 Loaded symbols for /lib/libc.so.7
 Reading symbols from /libexec/ld-elf.so.1...done.
 Loaded symbols for /libexec/ld-elf.so.1
 #0  0x004064b0 in fifo_len (f=0x801c29070) at
 /usr/src/cddl/usr.bin/ctfmerge/../../../cddl/contrib/opensolaris/tools/ctf/cvt/fifo.c:128
 128 for (i = 0, fn = f-f_head; fn; fn = fn-fn_next, i++);
 (gdb) bt
 #0  0x004064b0 in fifo_len (f=0x801c29070) at
 /usr/src/cddl/usr.bin/ctfmerge/../../../cddl/contrib/opensolaris/tools/ctf/cvt/fifo.c:128
 #1  0x0040622c in worker_thread (wq=0x610ee0) at
 /usr/src/cddl/usr.bin/ctfmerge/../../../cddl/contrib/opensolaris/tools/ctf/cvt/ctfmerge.c:329
 #2  0x000801078da9 in thread_start (curthread=0x801c0f800) at
 /usr/src/lib/libthr/thread/thr_create.c:284
 #3  0x in ?? ()
 Cannot access memory at address 0x7f5fb000
 (gdb)


After reverting the recent libthr changes in r234947, I am no longer
encountering this problem.

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: Extend search range of FreeBSD-10 libtools/configure fixup (was: Re: FreeBSD 10.0-CURRENT/AMD64 (CLANG): lang/gcc46 fails to build)

[b. f.]

 Am 07.12.2011 09:32, schrieb Dimitry Andric:
  That said, you are most likely running into an issue with the fix for
  FreeBSD 10-CURRENT in bsd.port.mk, causing the lto-plugin stage
  configure script to fail.
 
  This is because the gcc ports unpack their source code into
  ${WRKDIR}/gcc-${VERSIONSTRING}, and then override WRKSRC to
  ${WRKDIR}/build.  Since bsd.port.mk only applies the run-autotools-fixup
  to ${WRKSRC}, the gcc source itself is not properly fixed up.
 
  You can try the attached patch, which fixes this (and fixes it for all
  other ports that override WKRSRC).

 I had solved a similar problem for BDB a few weeks back and made the
 same modification (start searching in WRKDIR instead of in WRKSRC).

 This leads to (minimally) higher run time for the fixup, but it should
 make a number of ports currently broken on FBSD10 automagically build
 again ...

 And the pattern for libtool/configure type files should sufficiently
 prevent patching of files not touched by the current invocation of find.

 SO I'd vote to get that patch into SVN ...

We've had a patch to do this, and make a few other related changes,
for about a month now.  I'm not sure why it hasn't gone into
bsd.port.mk yet -- perhaps Martin had some other work to do -- but I
think that it will appear soon.

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

[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: 10.0-CUR r226986 ports (general)

[b. f.]

   It turns out that the problem is more general! A lot of ./configure
   scripts are detecting in 10-CUR that they can't or should not build
   shared libs; the problem is that the OS is detected now as
 
  As a temporary workaround, add WITH_FBSD10_FIX=1 to /etc/make.conf.

 ports/UPDATING and some of the mails in the archive of -current
 recommend setting UNAME_r=9.0-CURRENT; is this the same or which method
 is prefered?

No, it is not the same.  You can either masquerade, by setting UNAME_r
and OSVERSION, or by editing the headers and scripts that define them;
or you can use WITH_FBSD10_FIX for ports that define HAS_CONFIGURE
(which is implied by USE_AUTOTOOLS and GNU_CONFIGURE).  Right now the
masquerading is probably safer, because there are some problems with
the fix that are still being resolved -- and a few ports that may fail
despite the fix.  But of course if you help to test without
masquerading, these problems will be resolved sooner.

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: 10.0-CUR r226986 ports (general)

[b. f.]

On 11/3/11, O. Hartmann ohart...@zedat.fu-berlin.de wrote:
 Am 11/03/11 18:42, schrieb b. f.:

So I presume the WITH_FBSD10_FIX flag is set in /etc/make.conf, right?

You can set it in a number of  local Makefiles that are automatically
included during a port build.  That includes make.conf, and the others
mentioned in ports/Mk/bsd.port.mk.  A few days ago Martin also added
WITH_FBSD10_FIX to the Makefiles of a number of commonly-used ports
that need the fix.

Setting this and try building ports without the masquerading will help
those people involved in fixing more than the masquerading solution? If

Yes.  Some of the known problems with the current fix don't occur when
ports are built in tinderboxes or clean sandboxes, but on live systems
that already have other ports installed.

 On the other hand, as far as I know, there was only suggested using
 UNAME_r. When do I have to use the OSVERSION?


You don't have to alter OSVERSION, but if you do not, then for those
ports that have WITH_FBSD10_FIX set in their Makefiles, the fix will
be applied, and you will be subject to any problems that the fix may
cause, even though you are trying to masquerade as a version of
FreeBSD less than 10.  Look at the conditional that determine whether
any action is taken during the run-autotools-fixup target in
ports/Mk/bsd.port.mk.

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: Shared libraries version bump?

[b. f.]

 I think I'll rebuild all ports, and more, maybe I should make and keep 
 packages in case I can't update to BETA3 in place.

If you want to be on the safe side, a complete rebuild is probably a
good idea -- and moreover, one that removes all ports and cleans out
${PREFIX} and ${PKG_DBDIR} before rebuilding any ports, if you can
afford the downtime.  Otherwise, the new misc/compat8x port can help
ease the transition.  If they aren't available on pre-release media,
default packages for certain architectures are available at:

ftp://ftp.freebsd.org/pub/FreeBSD/ports/${ARCH}/packages-9-current/

Depending on the architecture, and when you download them, they will
have been compiled on a variety of recent versions of 9, but will
probably work on the BETAs, at least with misc/compat8x, as a stopgap
while you rebuild ports.

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: cvsup broken on amd64?

[b. f.]

 I have an Atom 330 with 9.0-BETA2/amd64 installed.

 I did a pkg_add -r cvsup-without-gui at first after installation.
 Using cvsup, resulted in a core dump (illegal instruction).

 I then removed all ports, and installed cvsup-without-gui from source.
 Started cvsup... core dump again.

 I then got the cvsup binary from a FreeBSD 8 i386 system, installed
 compat8x and also copied the missing libutil.so.8 from FreeBSD/i386
 and cvsuped the source (8.2-STABLE i386 cvsup worked).

 Then I rebuilt world, kernel (removed all debugging options from GENERIC).

 Then I removed all ports once more and reinstalled cvsup-without-gui
 from ports once more.

 And now again...

It may be broken -- I seem to recall some earlier complaints about
problems on one of the list.  But is there a reason why you are
attempting to use it, when /usr/bin/csup is available, and is
generally thought to be superior?


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: PHORONIX: OpenCL, GLSL Back-End For LLVM May Soon Open Up

[b. f.]

On 8/30/11, K. Macy km...@freebsd.org wrote:
 On Tue, Aug 30, 2011 at 9:47 PM, Pedro F. Giffuni giffu...@tutopia.com
 wrote:
 FWIW;

 Christopher Bergström and Pathscale delivered the EKOPath
 Compiler Suite, but no one followed up:

 (From the WantedPorts Wiki)
 https://github.com/pathscale/path64-suite


No one has contributed a port yet (a compiler port requires a lot of
care), but the compiler is being used by quite a few people, so I
doubt that Pathscale has been discouraged by the response.


 There has been very low interest in the FreeBSD port,
 and unfortunately this is a bad signal that we give to
 companies that want to contribute :(.


 The problem I have with that is that they only support the high-end
 computing variant of the card which I doubt any of us has. Without the
 documentation to extend the work to ordinary cards, e.g. my GTX460, it
 isn't that useful.

Yes, but native, high-quality code supporting some of the best
hardware would probably attract more interest in our OS as an HPC
platform, and Pathscale may be in a position to supply us, if not with
support for a wider range of hardware, at least with information and
advice on how to provide it -- perhaps with your missing documents.
So if you are interested, I'd urge you to get in touch with Bergström.
This seems like the kind of project that would be worthy of an initial
investment from the FreeBSD Foundation and other interested parties.

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: PHORONIX: OpenCL, GLSL Back-End For LLVM May Soon Open Up

[b. f.]

 By the beginning of this year Pathscale introduced a kind of compiler
 capable of HMPP, a very smart model
 like OpenMP. This compiler seems not to be ready by now and I never got
 access to a beta version to test
 whether it was capable of compiling CUDA ready code. As far as I know,
 HMPP is also an open standard.

 Well, conclusively, there seems no real solution to be present for
 FreeBSD by now (as I mentioned, the
 Linuxulator is no real alternative due to its 32bit limitations).

Christopher Bergström of PathScale offered to serve as an advocate for
release of portions of PathScale's code so that it could be used in
FreeBSD [1].  Did anyone take him up on it?  I'd think that
negotiations of this sort would be of interest to the FreeBSD
Foundation and other parties.

[1] http://lists.freebsd.org/pipermail/freebsd-questions/2011-June/231181.html
___
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: Updating our TCP and socket sysctl values...

[b. f.]

  I believe it's time to up these values to something that's in line with 
  higher speed
  local networks, such as 10G.  Perhaps it's time to move these to 2MB 
  instead of 256K.
 
  Thoughts?
 
 
  This never happened, did it?  Was there a reason?
 

 I went back and looked at the mail thread.  I didn't see any strong objections
 so I think you should commit this for 9.x.

 np@ did point out that nmbclusters also lags on modern hardware so consider 
 upping
 that at the same time.

I thought Bruce's observation, in:

http://lists.freebsd.org/pipermail/freebsd-arch/2011-March/011193.html

that:

...there is an mostly-unrelated bufferbloat problem that is
purely local.  If you have a buffer that is larger than an Ln cache (or
about half than), then actually using just a single buffer of that size
guarantees thrashing of the Ln cache, so that almost every memory access
is an Ln cache miss.  Even with current hardware, a buffer of size 256K
will thrash most L1 caches and a buffer of size a few MB will thrash most
L2 caches.

, and his suggestion for some sort of auto-tuning, deserve
consideration.  Are you going to address this problem (at least the L2
and higher cache thrashing), or give some suggestions for tuning in
UPDATING and the relevant manpages?

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: Thoughts on TMPFS no longer being considered highly experimental

[b. f.]

Peter Holm wrote:
 On Fri, Jun 24, 2011 at 10:57:16PM +0300, Kostik Belousov wrote:
  On Fri, Jun 24, 2011 at 06:20:03PM +0200, Peter Holm wrote:
   Got a panic: Not a vnode object quite fast:
  
   http://people.freebsd.org/~pho/stress/log/kostik441.txt
 
  Ah, yes, this is an assertion that was added in the r209702.
  http://people.freebsd.org/~kib/misc/tmpfs.7.patch

 Looks good. The mmap(2) test doesn't panic any more, nor does any of
 the other TMPFS tests I have.

Is this patch under consideration for inclusion in 9.0?

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

Recursive nullfs mounts and r224655

[b. f.]

Recent changes to the kernel (sys/kern/vfs_mount.c, in r224655?)
between r224550 and r224655 have broken my tinderbox setup.  It had a
tmpfs filesystem mounted at /T and a UFS filesystem mounted at /U,
and, when setting up the tinderbox, performed:

mkdir /U/u1
mkdir /U/u2
mkdir /T/t1
mount -t nullfs /T/t1 /U/u1
mkdir-p /U/u1/u3/u4
mount -t nullfs /U/u2 /U/u1/u3/u4
...

This worked at r224550 and before.  It now fails at the second nullfs
mount, with ENOENT(mount_nullfs: No such file or directory).

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: Recursive nullfs mounts and r224655

[b. f.]

On 8/6/11, Kostik Belousov kostik...@gmail.com wrote:
 On Sat, Aug 06, 2011 at 04:44:25AM -0400, b. f. wrote:
 Recent changes to the kernel (sys/kern/vfs_mount.c, in r224655?)
 between r224550 and r224655 have broken my tinderbox setup.  It had a
 tmpfs filesystem mounted at /T and a UFS filesystem mounted at /U,
 and, when setting up the tinderbox, performed:

 mkdir /U/u1
 mkdir /U/u2
 mkdir /T/t1
 mount -t nullfs /T/t1 /U/u1
 mkdir-p /U/u1/u3/u4
 mount -t nullfs /U/u2 /U/u1/u3/u4
 ...

 This worked at r224550 and before.  It now fails at the second nullfs
 mount, with ENOENT(mount_nullfs: No such file or directory).
 r224615 and r224655 must be reverted.

 The reason for your trouble is that nullfs cannot cache any vnodes,
 thus reclaiming anything that get reference count of 0. This interacts
 badly with VOP_VNTOCNP() which has to operate on the vnodes with
 zero refcount, since we cannot decrement refcount under the namecache
 lock.

 Trying to update vptocnp(9) interface is too intrusive change for freeze
 period.



Thank you for the analysis, it will make fixing this problem locally a
bit easier, while you sort it out.  Does 224614 have a bearing on this
problem, as well as 224615?

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: CURRENT /usr/ports

[b. f.]

Matthias Apitz:
...
 I'm running -CURRENT on my laptop (r220692 from ~mid of April) and
 /usr/ports from CVS from the same day; I want from time to time (let's
 says once a week) SVN update my kernel and userland; I know that these
 two should be in sync, but what about the ports? I have installed around
 1200 ports I'm used to use. Is there any special note in /usr/src/UPDATING
 when the ABI changes and would break the compiled ports?

There is a lot of relevant information in UPDATING, but this file
doesn't focus on ports, and some changes that affect ports aren't
mentioned. You can find some workarounds or IGNORE settings in
individual port Makefiles based upon OSVERSION, some open PRs which
describe known problems (and, occasionally, solutions), and a partial
list of problems at:

http://wiki.freebsd.org/PortsBrokenOnCurrent

(but this last listing is somewhat incomplete and out-of-date). You
can also find build logs at:

http://pointyhat.freebsd.org/errorlogs/

Efforts to find and fix these problems will accelerate after the
slush/freeze that will precede the release of FreeBSD 9.

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: svn commit: r220430 - head/sys/amd64/amd64

[b. f.]

  Author: jhb
  Date: Thu Apr  7 21:32:25 2011
...
  URL: http://svn.freebsd.org/changeset/base/220430
...

 I think that this commit (plus r220431) has broken something in my 
 environment.
 After updating to the most recent head I started to get semi-random problems 
 in
 various areas:
 - named would consistently fail to start, but with different errors 
 (assertions)
 - ^Z and fg result in a process getting SIGSEGV
 - X sometimes fails to start complaining about failed VT switch

 Reverting just these two commits restores sanity.

 Just in case, my processor is AMD (arch is obviously amd64).

I experienced similar problems (UP amd64, AMD Mobile Athlon64
processor) and reported it  to kib@ and jhb@.

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: FreeBSD Compiler Benchmark: gcc-base vs. gcc-ports vs. clang

[b. f.]

 Putting the 'speed' question completely aside, I would like to comment
 on other issue(s) there. The switching of the ports to use the port-provided
 compiler (and binutils) would be very useful and often talked about feature.

 Your approach of USE_GCC_BUILD as implemented is probably not going
 to work. The problem is that gcc provides two libraries, libgcc and
 libstdc++, that are not forward-compatible with the same libraries from
 older compilers and our base.

 libstdc++ definitely did grown new symbols and new versions of old
 symbols, and I suspect that libgcc did the same. Also, we are trusting
 the ABI stability premise.

 For this scheme to work, we at least need a gcc-runtime port with dsos
 provided by full port, and some mechnanism to force the binaries
 compiled with port gcc to use gcc-runtime libs instead of base.
 Might be, -Rpath linker cludge.

There are a number of incompatible libraries.  The existing USE_GCC
scheme adds -Wl,rpath=... flags to CFLAGS and LDFLAGS in bsd.gcc.mk,
in an attempt to point the binaries to newer libraries.  Matuska is
not suggesting changing this -- his proposed new variable
USE_GCC_BUILD uses the existing USE_GCC framework, and differs from
the existing usage only in that it does not register any runtime
dependencies on lang/gcc*  in the packages that are produced.  His new
variable is intended, as he said, only for ports that don't need any
of the compiler libraries at runtime.

There are only two reasons for doing this: (1) reducing the number of
dependencies that must be installed when installing a package, or (2)
attempting to use lang/gcc4* to build a port that is currently needed
to build lang/gcc4* itself, without causing a problem with circular
dependencies.

For (2), I think that there are only:

devel/gmake
devel/binutils
devel/bison
lang/perl5.1[02]
devel/binutils
devel/libelf
converters/libiconv

(the others have runtime dependencies on libgcc_s) and the new
variable could not be added to the port Makefiles, because it would
still cause problems with circular dependencies when building these
ports if lang/gcc4* were not already installed.  It would have to be
added by users in local Makefiles, who had arranged their builds so
that it could be used.  But since the same effect could be obtained by
editing packages or the package database after the build, or by using
the methods Matuska advocated in:

http://www.freebsd.org/doc/en_US.ISO8859-1/articles/custom-gcc/index.html

the new variable does not seem to be worth including for the purpose of (2).

For (1), I'm not sure how many ports could use it.  We are already
working on reducing the amount of dependencies for those ports that
USE_FORTRAN or USE_GCC, by trying to add runtime-only lang/gcc4*
ports, but, owing to some awkward details involving the Ports
infrastructure and the way tinderboxes operate, the existing
lang/gcc4* ports have to be split into non-intersecting slave ports,
so there has been a delay while we sort out the details.

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: FreeBSD Compiler Benchmark: gcc-base vs. gcc-ports vs. clang

[b. f.]

Martin Matuska wrote:
 we have performed a benchmark of the perl binary compiled with base gcc,
 ports gcc and ports clang using the perlbench benchmark suite.
 Our benchmark was performed solely on amd64 with 10 different processors
 and we have tried different -march= flags to compare binary performance
 of the same compiler with different flags.

 Here is some statistics from the results:
 - clang falls 10% behind the base gcc 4.2.1 (test average)
 - gcc 4.5 from ports gives 5-10% better average performance than the
 base gcc 4.2.1
 - 4% average penalty for Intel Atom and -march=nocona (using gcc from base)
 - core i7 class processors run best with -march=nocona (using gcc from base)

...

 More information, detailed test results and test configuration are at
 our blog:
 http://blog.vx.sk/archives/25-FreeBSD-Compiler-Benchmark-gcc-base-vs-gcc-ports-vs-clang.html

Methodological objections aside, thank you for conducting tests and
publishing the results. Are you going to continue to conduct tests as
lang/gcc4*  (the default for USE_GCC/USE_FORTRAN may be switched from
4.5 to 4.6 after the upcoming release of 4.6) and clang (there seem to
be improvements in the more recent versions -- e.g.,
http://llvm.org/viewvc/llvm-project?view=revrevision=127208 ) are
updated?

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: status of WITHOUT_SYSINSTALL

[b. f.]

   just wanted to ask what the current situation on WITHOUT_SYSINSTALL is? 
   it
   seems the option gets completely ignored after a recent commit.

I thought that Alex was going to follow up on this (cf.
http://markmail.org/message/bkbygrx5z5ascukh ) with Warner.

   should src.conf be adjusted to mention that WITHOUT_SYSINSTALL == noop or
   should the option be completely removed?

Please, no.  Just turn the bits of it that were disabled back on, and
finish implementing it, as the two of you suggested earlier.
Especially since the default installer may be changed, and most people
may not need or want it.

  
   also in usr.sbin/Makefile, the sysinstall entry should be moved upwards 
   to the
   other non-optional build directories imo.
 
      The build didn't even really function when specifying
  WITHOUT_SYSINSTALL before Nate's recent commits -- so why worry about
  the state of things?
 
  due to inconsistency? src.conf says WITHOUT_SYSINSTALL will not build
  sysinstall(1). that's obviously wrong.

 I think this context was forgotten:
 http://markmail.org/message/fk2xqlrtvljjo3rf

Yes, please preserve the context next time.


 Also:

 $ find /usr/src/ -name 'Makefile*' | xargs grep WITHOUT_SYSINSTALL
 $ echo $?
 1
 $ svn info /usr/src/ | grep Revision | sed 's,Revision: ,,'
 219120

 Doesn't look like this sentinel is honored anywhere.

? bsd.own.mk, where it's transformed into a MK_SYSINSTALL value that
is referenced elsewhere, although not everywhere it should be.  But
you know this already, as shown in your previous patches!

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: More if_ath churn coming your way!

[b. f.]

Adrian Chadd wrote:
 2011/1/22 Dima Panov fluffy at fluffy.khv.ru:

  22.01.2011, 22:19, Adrian Chadd adrian.chadd at gmail.com:

 This is why I really do need this tested as much as possible. I'll put
 up instructions on how to build if_ath as a module (that's what I'm
 doing on my RELENG_8 EEEPC - I'm running the HEAD if_ath on it for
 testing on the AR9280) and then sort out any and all issues on the
 AR5416, AR9160, AR9280 and AR9285.

 Throwing 11n into the mix right now is just a bit too much for me to take on. 
 :)

Would you look to see if any of your improvements can also be used by uath(4)?

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: More if_ath churn coming your way!

[b. f.]

On 1/22/11, Adrian Chadd adr...@freebsd.org wrote:
 On 23 January 2011 01:11, b. f. bf1...@googlemail.com wrote:

 Would you look to see if any of your improvements can also be used by
 uath(4)?

 Nope, sorry. I can only do two things at a time. :)

I didn't mean immediately, but at some point in the not-too-distant
future.  Or do you lack the hardware, if not the time?

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: lockup with vidcontrol VESA_800x600

[b. f.]

On 1/19/11, Jung-uk Kim j...@freebsd.org wrote:
 On Tuesday 18 January 2011 10:08 pm, b. f. wrote:
 Marc UBM Bocklet ubm.freebsd at googlemail.com wrote:

 Please try the attached patch.

Your patch fixes my problem.  With the patch, I can use the
problematic modes on my machine without panics.  Well done; thank you
for the quick response.

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: lockup with vidcontrol VESA_800x600

[b. f.]

Marc UBM Bocklet ubm.freebsd at googlemail.com wrote:
 Yesterday I upgraded to

 FreeBSD hostname 9.0-CURRENT FreeBSD 9.0-CURRENT #28: Sat Jan  8
 17:05:30 CET 2011

 and vidcontrol VESA_800x600 stopped working (again). I exchanged emails
 with jkim about a similar problem in February 2010 (vidcontrol
 VESA_800x600 would mangle the screen output), there was no definitive
 resolution, but it started working again sometime around July 2010.

 Now however, when I try to set VESA_800x600, my machine seems to
 lockup. It no longer responds to any input, I cannot ping it and I
 cannot drop to the debugger.

 I've tried setting other modes, but trying to set them results in:

 obtaining new video mode parameters: operation not supported by device.

 graphics card is a:

 vgapci0 at pci0:1:0:0: class=0x03 card=0x013a1002 chip=0x514c1002
 rev=0x00 hdr=0x00 vendor = 'ATI Technologies Inc. / Advanced Micro
 Devices, Inc.' device = 'Radeon 8500 / 8500LE (R200)'
 class  = display
 subclass   = VGA


I'm joining the chorus of those having problems with video
mode-switching on recent 9-CURRENT. From r216756 through r217561, I'm
able to reliably panic my UP i386 machine by using MODE_268, which
'vidcontrol -i mode' describes as:

mode# flags   typesize   font  window  linear buffer
--
268 (0x10c) 0x000d T 132x60  8x8   0xb8000 32k 32k 0xfc00 15k

Prior to 28 Dec. 2010,  on versions of 9-CURRENT less than three
months old, MODE_268 was my default video mode.  A number of other
modes that used to work now also trigger panics.  I've been forced to
fall back to MODE_48:

mode# flags   typesize   font  window  linear buffer
--
 48 (0x030) 0x0001 T 90x60   8x8   0xb8000 32k 32k 0x 32k

which works fine. A representative panic with a problematic mode is:

kernel trap 12 with interrupts disabled


Fatal trap 12: page fault while in kernel mode
fault virtual address   = 0xcd29a05b
fault code  = supervisor write, page not present
instruction pointer = 0x20:0xc0746391
stack pointer   = 0x28:0xcd299714
frame pointer   = 0x28:0xcd299714
code segment= base 0x0, limit 0xf, type 0x1b
= DPL 0, pres 1, def32 1, gran 1
processor eflags= resume, IOPL = 0
current process = 94550 (vidcontrol)

and a backtrace shows:

db:1:lockedvnods  show pcpu
cpuid= 0
dynamic pcpu = 0x40d080
curthread= 0xc2b7c5a0: pid 94550 vidcontrol
curpcb   = 0xcd299d80
fpcurthread  = 0xc2b7c5a0: pid 94550 vidcontrol
idlethread   = 0xc2851870: tid 13 idle
APIC ID  = 0
currentldt   = 0x50
db:1:pcpu  bt
Tracing pid 94550 tid 100057 td 0xc2b7c5a0
fpusave(0,9e000,cd299778,c073106c,cd299ff0,...) at 0xc0746391 = fpusave+0x11
npxsave(cd299ff0) at 0xc07463b1 = npxsave+0x11
vm86_bioscall(10,cd2997a0,c08540a0,0,0,...) at 0xc073106c = vm86_bioscall+0x3c
x86bios_intr(cd299818,10,cd299848,0,0,...) at 0xc074d6f2 = x86bios_intr+0xd2
vesa_set_mode(c084dfc0,10c,cd299920,c2bb8354,5a,...) at 0xc094ee49 =
vesa_set_mode+0xf9
set_mode(c082ea80,0,3c,0,c2834000,...) at 0xc050cc9f = set_mode+0x7f
sc_set_text_mode(c082ea80,c2834000,10c,84,3c,...) at 0xc050b0e0 =
sc_set_text_mode+0x220
vesa_ioctl(c2834000,2000560c,cd299cf4,c2b7c5a0,c2b7c5a0,...) at
0xc095065c = vesa_ioctl+0xac
sctty_ioctl(c2834000,2000560c,cd299cf4,c2b7c5a0,7,...) at 0xc050f015 =
sctty_ioctl+0x35
tty_ioctl(c2834000,2000560c,cd299cf4,3,c2b7c5a0,...) at 0xc05cb314 =
tty_ioctl+0x44
ttydev_ioctl(c28c5800,2000560c,cd299cf4,3,c2b7c5a0,...) at 0xc05cca1d
= ttydev_ioctl+0x1ad
devfs_ioctl_f(c2a75508,2000560c,cd299cf4,c2a53780,c2b7c5a0,...) at
0xc0516b3a = devfs_ioctl_f+0x10a
kern_ioctl(c2b7c5a0,0,2000560c,cd299cf4,299cec,...) at 0xc05bbae8 =
kern_ioctl+0x288
ioctl(c2b7c5a0,cd299cec,cd299d28,cd299d80,28161bb0,...) at 0xc05bbc4f
= ioctl+0x12f
syscallenter(c2b7c5a0,cd299ce4,cd299ce4,0,c2b7c5a0,...) at 0xc05b7428
= syscallenter+0x348
syscall(cd299d28) at 0xc0743ab4 = syscall+0x34
Xint0x80_syscall() at 0xc0730ab1 = Xint0x80_syscall+0x21
--- syscall (54, FreeBSD ELF32, ioctl), eip = 0x2817b82b, esp =
0xbfbfe86c, ebp = 0xbfbfe8a8 ---

Any suggestions about how to fix this?  I can furnish more information
about my kernel config, etc., if necessary.

Regards,
   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: a few OptionalObsoleteFiles.inc improvements

[b. f.]

On 12/17/10, Alexander Best arun...@freebsd.org wrote:
 On Tue Dec 14 10, b. f. wrote:
 Alexander Best wrote:

...

 The last part of your patch reverts a change that Warner Losh made in
 r212525 as part of his tbemd project merge.  It's possible that this
 change may have been an unintended, but it followed a discussion in
 which Warner rejected a related patch proposed by Garrett Cooper,
 partly because sysinstall is included in build-tools in Makefile.inc1,
 even though some thought that it should not be.  In any event, you
 should probably look into that before committing the last part of your
 patch.

 so is csh, but still you can set WITHOUT_TCSH=true and have a world without
 (t)csh.

I'll be more explicit:

Garrett's original patch went a little farther than yours: he also
conditionally removed sysinstall (subject to the use of
WITHOUT_SYSINSTALL) from build-tools in Makefile.inc1, as is done now
under other knobs with sys/modules/aic7xxx/aicasm,
share/syscons/scrnmaps, kerberos5/tools, and rescue/rescue.  That is
primarily what resulted in it being rejected, as no one remembered why
it had been added in:

http://svn.freebsd.org/viewvc/base?view=revisionrevision=71238

Subsequently, Warner agreed that it could in fact be removed:

http://lists.freebsd.org/pipermail/freebsd-arch/2010-June/010398.html

However, he didn't remove it, and even later effectively disabled the
WITHOUT_SYSINSTALL knob.  So I'm suggesting that you find out why he
changed his mind (it may have been an oversight), and if sysinstall
really isn't needed, then not only make the changes that you
originally proposed, but also prevent it from being built in the first
place during build-tools, like Garrett did.  (The same should be done
for other parts of that target, too, like the csh bits.)

...

 no need to worry i'll commit any changes, since i don't have commit rights.
 ;)

...or before asking someone else to commit it.

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: a few OptionalObsoleteFiles.inc improvements

[b. f.]

Alexander Best wrote:

any thoughts on this patch? it adds files which will be removed when
WITHOUT_SYSCONS is set. also it makes sure sysinstall(8) and sade(8) only get
installed when WITHOUT_SYSINSTALL wasn't defined and also that any related
executables and manual pages get removed if in fact that var is defined.

...

diff --git a/usr.sbin/Makefile b/usr.sbin/Makefile
index f3e853e..2151868 100644
--- a/usr.sbin/Makefile
+++ b/usr.sbin/Makefile
@@ -250,7 +250,6 @@ SUBDIR+=ftp-proxy
 SUBDIR+=   pkg_install
 .endif

-# XXX MK_TOOLCHAIN?
 .if ${MK_PMC} != no
 SUBDIR+=   pmcannotate
 SUBDIR+=   pmccontrol
@@ -283,7 +282,9 @@ SUBDIR+=praliases
 SUBDIR+=   sendmail
 .endif
 
+.if ${MK_SYSINSTALL} != no
 SUBDIR+=   sysinstall
+.endif

I'm glad to see that you're filling in some of the many missing bits
in this file.

The last part of your patch reverts a change that Warner Losh made in
r212525 as part of his tbemd project merge.  It's possible that this
change may have been an unintended, but it followed a discussion in
which Warner rejected a related patch proposed by Garrett Cooper,
partly because sysinstall is included in build-tools in Makefile.inc1,
even though some thought that it should not be.  In any event, you
should probably look into that before committing the last part of your
patch.

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: Clang now builds world and kernel, on i386 and amd64

[b. f.]

Dmitry Andric wrote:
On 2010-09-25 21:16, Paul B Mahol wrote:
 When to expect to get rid of GNU as and other binutils tools?

Work is progressing steadily on the clang/llvm integrated assembler,
which removes the need for an external assembler such as gas, and which
should also reduce compile times further.  This is really in alpha state
right now, but Roman Divacky (who is one of the active contributors) can
probably tell more about its progress.

Another important component is of course the linker, but I am not aware
of a similar project to replace that; excepting gold, but that is a
GPLv3 project too, unfortunately.

There has been another effort underway for some time:

http://sourceforge.net/apps/trac/elftoolchain/

Perhaps some coordination between those working on llvm in FreeBSD,
and the elftoolchain project, would be helpful?

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

An LOR recently observed on r212598

[b. f.]

An LOR, which resembles another reported in:

http://lists.freebsd.org/pipermail/freebsd-current/2010-August/018986.html

but none that I noticed at:

http://sources.zabbadoz.net/freebsd/lor.html

lock order reversal:
1st 0xff0001696098 ufs (ufs) @ /mnt/disk2/usr/src/sys/kern/vfs_lookup.c:501
2nd 0xff8026d985b8 bufwait (bufwait) @
/mnt/disk2/usr/src/sys/ufs/ffs/ffs_softdep.c:11309
3rd 0xff0001705638 ufs (ufs) @ /mnt/disk2/usr/src/sys/kern/vfs_subr.c:2111
KDB: stack backtrace:
db_trace_self_wrapper() at 0x801cae5a = db_trace_self_wrapper+0x2a
_witness_debugger() at 0x802ba265 = _witness_debugger+0x65
witness_checkorder() at 0x802bb513 = witness_checkorder+0x833
__lockmgr_args() at 0x8025efad = __lockmgr_args+0xd4d
ffs_lock() at 0x8041a9af = ffs_lock+0x8f
VOP_LOCK1_APV() at 0x804ab13b = VOP_LOCK1_APV+0x9b
_vn_lock() at 0x80313c67 = _vn_lock+0x57
vget() at 0x8030775b = vget+0x7b
vfs_hash_get() at 0x802fb065 = vfs_hash_get+0xd5
ffs_vgetf() at 0x80415ca8 = ffs_vgetf+0x48
softdep_sync_metadata() at 0x8041309e = softdep_sync_metadata+0x5de
ffs_syncvnode() at 0x8041a65a = ffs_syncvnode+0x22a
ffs_truncate() at 0x803fac38 = ffs_truncate+0x408
ufs_direnter() at 0x8042284d = ufs_direnter+0x6fd
ufs_makeinode() at 0x80427a74 = ufs_makeinode+0x254
VOP_CREATE_APV() at 0x804abaad = VOP_CREATE_APV+0x8d
vn_open_cred() at 0x80313642 = vn_open_cred+0x452
kern_openat() at 0x803126f1 = kern_openat+0x181
syscallenter() at 0x802b274a = syscallenter+0x1aa
syscall() at 0x8046dfac = syscall+0x4c
Xfast_syscall() at 0x8045a332 = Xfast_syscall+0xe2
--- syscall (5, FreeBSD ELF64, open), rip = 0x800726ddc, rsp =
0x7fffeac8, rbp = 0 ---


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: NOTICE: New event timer management code got to HEAD

[b. f.]

Alexander:

Are the changes to sys/kern/sched_ule.c in your supplementary hack

http://people.freebsd.org/~mav/tm6292_idle.patch

still useful, or have they been superseded by the other changes in

http://svn.freebsd.org/changeset/base/212541 ?

Regards,
 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: One-shot-oriented event timers management

[b. f.]

In:

http://people.freebsd.org/~mav/timers_oneshot7.patch

you need to offset the declaration of 'cpu' in getnextevent() on line
256 of src/sys/kern/kern_clocksource.c by #ifdef SMP, because it is
not used otherwise, and will break UP kernel builds with our default
warnings and -Werror.

Incidentally, do you intend to commit the tm6292_idle.patch along with
the new timer code, after testing is satisfactory?  Or is this not
appropriate for general use?  If it isn't suitable for all users,
perhaps some of the periods of the events in that patch can be
abstracted and made tunable, so that we can make it possible to
conserve power, and also keep others happy?

Regards,
  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: Latest intr problems

[b. f.]

On 8/23/10, John Baldwin j...@freebsd.org wrote:
 On Saturday, August 21, 2010 11:28:41 am Andriy Gapon wrote:
 on 21/08/2010 16:04 b. f. said the following:
  Andriy Gapon wrote:
  on 21/08/2010 12:35 Andriy Gapon said the following:
  I feel like you might be having a problem with clocks...
  FWIW, I am reading this document http://edc.intel.com/Link.aspx?id=1484
  and I see this sentence: All of the clocks in the processor core are
  stopped in the C3 state.
 
  I see that you have C3 state enabled and it's regularly entered:
  dev.cpu.0.cx_usage: 0.00% 5.51% 94.48% last 305us
 
  I don't think this accounts for all of his problems, unless his
  machine has an unusual configuration.

 Well, let's try to not muddy the waters prematurely.

 It could easily account for it.  If the lapic is going to sleep in C3, then
 you are actually missing statclock interrupts and likely screwing up the
 accounting (idle threads wouldn't accumulate time correctly for example).
 Even though his system really isn't spending a lot of time executing
 interrupts, the cp_time[] values would be skewed and wrong.

Right, I can easily see how it is _a_ problem.  I remembered that it
was the reason Alexander gave for reviving the use of the rtc and the
i8254 as eventtimers/timecounters, and it's partly why I suggested
switching clock sources earlier.   My point in my reply to Andriy was
that Doug had reported similar problems  when the hpet was the sole
eventtimer/timecounter, and also when the i8254 was the only one,
which suggested that there were other problems, too.  But then Doug
also assured me that he was satisfied that usb wasn't the source of
the problem, where now he and Andriy seem to think it plays a primary
role, so I give up.  I only hope that new interrupt-handling that you
are working on makes the system less susceptible to these kinds of
problems.

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

Fwd: Latest intr problems

[b. f.]

Andriy Gapon wrote:
on 21/08/2010 12:35 Andriy Gapon said the following:
 I feel like you might be having a problem with clocks...

FWIW, I am reading this document http://edc.intel.com/Link.aspx?id=1484
and I see this sentence: All of the clocks in the processor core are
stopped in the C3 state.

I see that you have C3 state enabled and it's regularly entered:
dev.cpu.0.cx_usage: 0.00% 5.51% 94.48% last 305us

I don't think this accounts for all of his problems, unless his
machine has an unusual configuration.  Alexander and I recommended
that he try different clocks, and just recently, for example, he wrote
that he had used:

loader.conf
hint.apic.0.clock=0
hint.atrtc.0.clock=0
hint.attimer.0.clock=0
hint.hpet.0.legacy_route=1
machdep.disable_rtc_set=1
kern.eventtimer.timer2=HPET
kern.eventtimer.timer1=NONE (Or, if available, HPET1, ...)
kern.eventtimer.singlemul=1

sysctl.conf:
kern.timecounter.hardware=HPET

and reported that it did not help.  The HPET doesn't usually suffer
from the problem that you are describing, right?


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: Latest intr problems

[b. f.]

On 8/21/10, Andriy Gapon a...@icyb.net.ua wrote:
 on 21/08/2010 16:04 b. f. said the following:
 Andriy Gapon wrote:
 on 21/08/2010 12:35 Andriy Gapon said the following:

 Well, let's try to not muddy the waters prematurely.

It's not premature to say that his machine has some peculiar
clock-related features, that should be kept in mind while testing.
This came up earlier:

http://lists.freebsd.org/pipermail/freebsd-current/2010-June/018179.html

and is partly why I recommended some of the settings below.


 Alexander and I recommended
 that he try different clocks, and just recently, for example, he wrote
 that he had used:

 loader.conf
 hint.apic.0.clock=0
 hint.atrtc.0.clock=0
 hint.attimer.0.clock=0
 hint.hpet.0.legacy_route=1

 Well, I don't see much point in doing the above in this situation.

We suspected clock problems as well, and were trying to isolate the
problem taking other clocks completely out of consideration.  Probably
the legacy_route could have been discarded, but in that case the
second eventtimer  would have to be emulated with NONE.


 machdep.disable_rtc_set=1
 kern.eventtimer.timer2=HPET
 kern.eventtimer.timer1=NONE (Or, if available, HPET1, ...)

 So, what was actually used here?
 I don't think that NONE is a good idea.

Doug will have to answer that -- he wasn't specific in his reply.

 kern.eventtimer.singlemul=1

 sysctl.conf:
 kern.timecounter.hardware=HPET

 and reported that it did not help.  The HPET doesn't usually suffer
 from the problem that you are describing, right?

 Right.
 Still I would prefer that Doug would do the cleaner experiment(s) that I
 suggested.  And if the problem persists then elimination of LAPIC timer
 would
 make the picture clearer (for me).

Sure, let's see if restraining the C-states yields any results.


 P.S.
 I still think that KTR+schedgraph would be the best tool here.

Attilio recommended that originally, then (reportedly) changed his
mind and said to try dtrace.  I brought it up again earlier, and Doug
said that he would make some experiments.

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: Official request: Please make GNU grep the default

[b. f.]

On 8/20/10, Dag-Erling Smørgrav d...@des.no wrote:
 b. f. bf1...@googlemail.com writes:
 At r211506, 'grep -wq' does not seem to work properly (in the very
 least, it is not the same as with GNU grep),

 Does not seem to work properly is not a very useful statement.  The
 least you could do is provide an example.

I did provide an example, later in the same sentence that you quoted.
Using a current ports tree, go to a port with 'lisp' in CATEGORIES,
and run any ports target that requires 'check-categories', e.g.:

make -C /usr/ports/math/maxima check-categories
maxima-5.22.1: Makefile error: category lisp not in list of valid categories.
*** Error code 1

Stop in /mnt/disk2/usr/ports/math/maxima.

From bsd.port.mk:

   2941 VALID_CATEGORIES+= accessibility afterstep arabic archivers
astro audio \
   2942 benchmarks biology cad chinese comms converters databases \
   2943 deskutils devel docs dns editors elisp emulators
finance french ftp \
   2944 games geography german gnome gnustep graphics hamradio
haskell hebrew hungarian \
   2945 ipv6 irc japanese java kde kld korean lang linux lisp \
   2946 mail math mbone misc multimedia net net-im net-mgmt
net-p2p news \
   2947 palm parallel pear perl5 plan9 polish portuguese ports-mgmt \
   2948 print python ruby rubygems russian \
   2949 scheme science security shells spanish sysutils \
   2950 tcl textproc tk \
   2951 ukrainian vietnamese windowmaker www \
   2952 x11 x11-clocks x11-drivers x11-fm x11-fonts
x11-servers x11-themes \
   2953 x11-toolkits x11-wm xfce zope
   2954
   2955 check-categories:
   2956 .for cat in ${CATEGORIES}
   2957 @if ${ECHO_CMD} ${VALID_CATEGORIES} | ${GREP} -wq ${cat}; then \
   2958 ${TRUE}; \
   2959 else \
   2960 ${ECHO_MSG} ${PKGNAME}: Makefile error:
category ${cat} not in list of valid categories.   2960 ; \
   2961 ${FALSE}; \
   2962 fi
   2963 .endfor

A closer look at VALID_CATEGORIES, using vis -oltw:

VALID_CATEGORIES+=\040accessibility\040afterstep\040arabic\040archivers\040astro\040audio\040\\\$
\011benchmarks\040biology\040cad\040chinese\040comms\040converters\040databases\040\\\$
\011deskutils\040devel\040docs\040dns\040editors\040elisp\040emulators\040finance\040french\040ftp\040\\\$
\011games\040geography\040german\040gnome\040gnustep\040graphics\040hamradio\040haskell\040hebrew\040hungarian\040\\\$
\011ipv6\040irc\040japanese\040java\040kde\040kld\040korean\040lang\040linux\040lisp\040\\\$
\011mail\040math\040mbone\040misc\040multimedia\040net\040net-im\040net-mgmt\040net-p2p\040news\040\\\$
\011palm\040parallel\040pear\040perl5\040plan9\040polish\040portuguese\040ports-mgmt\040\\\$
\011print\040python\040ruby\040rubygems\040russian\040\\\$
\011scheme\040science\040security\040shells\040spanish\040sysutils\040\\\$
\011tcl\040textproc\040tk\040\\\$
\011ukrainian\040vietnamese\040windowmaker\040www\040\\\$
\011x11\040x11-clocks\040x11-drivers\040x11-fm\040x11-fonts\040x11-servers\040x11-themes\040\\\$
\011x11-toolkits\040x11-wm\040xfce\040zope\$

The lisp category is the only category that causes a problem with the
new bsdgrep, and I didn't take the time to analyze why ( which is why
I was not more specific in my original message). 'lisp' is preceded by
'elisp', which would normally be a match for the 'lisp' in a port
Makefile, were it not for the -w flag.  'x11' succeeds, but it
precedes all of the x11-* categories.  I suspect that there is an
error in the logic of either the -w or the -q flag implementation in
bsdgrep, which causes problems when the two options are used together.
The target succeeds as expected with GNU grep.

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: Official request: Please make GNU grep the default

[b. f.]

Gabor:

One more thing to look into, in addition to the context problems,
ndisgen breakage, and problems on certain file systems:

At r211506, 'grep -wq' does not seem to work properly (in the very
least, it is not the same as with GNU grep), and has broken the
'check-categories' target (and hence builds) of all ports with 'lisp'
in CATEGORIES.

Regards,
   b.

P.S. I hope that you have recovered from your influenza, and are
feeling better now.
___
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: Interpreted language(s) in the base

[b. f.]

2010/8/16 Dag-Erling Smørgrav des at des.no:
 Doug Barton dougb at FreeBSD.org writes:
 lua   too flavor of the day, not enough track record of stability,
       not enough installed base/proven utility

 You're wrong.  Lua has been around for ages and is especially widely
 used as a game scripting engine.  It is not intended as a standalone
 language, but as an embeddable scripting engine.  We could easily create
 our own scripting language based on lua with FreeBSD-specific functions,
 and there would be no fear of interfering with third-party software,
 because it wouldn't be called lua.

It looks like this is rearing its head again elsewhere:

http://mail-index.netbsd.org/tech-userlevel/2009/10/24/msg002827.html

http://socghop.appspot.com/gsoc/student_project/show/google/gsoc2010/netbsd/t127230760748

Student Name: Lourival Vieira
Organization: The NetBSD Foundation
Organization Home Page: http://www.netbsd.org/
Mentor Name: Marc Balmer
Title: Provide support for dynamic NetBSD kernel extensions using the
Lua language - Lunatik/NetBSD Abstract: This project has the goal to
develop a framework to provide support for dynamically extending the
NetBSD kernel using the Lua programming language. I intend to allow
adaptation of the kernel and its subsystems for different purposes at
runtime, through download of Lua scripts and exposure of kernel
internals to Lua. Moreover, this framework will provide support for
rapid prototyping and experimentation with new algorithms and
mechanisms inside the kernel.


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: Runaway intr, not flash related

[b. f.]

On 8/15/10, Doug Barton do...@freebsd.org wrote:
 On 08/14/2010 09:54, b. f. wrote:
 My runaway intr problem with flash has been continuing all
 along, but since no one has been interested in helping with it I
 haven't reported it for a while. However, today, for the first
 time, it happened when I had not run flash at all since I booted.

 My system: Dell D620, C2D, i386, SMP, r210908

 swi4: clock is the culprit again this time, but when flash
 triggers this problem I sometimes see hdac as the culprit, FYI.

 The problem happens MOST often when I'm viewing a flash video, but it
 can also happen other times. Interestingly, what often happens is that
 everything is fine while I'm viewing the video, but intr runs away after
 I close the window. I was sort of surprised by this myself, but now I
 have verified it numerous times.

 It happens without running flash (as I pointed out in this message) and
 last night I was able to trigger it several times without running X at all.

 The usual device that runs away is the clock, but sometimes (about 1 in
 20) it's hdac.


What were you doing when you triggered the interrupt problem without
running X?  Was there a lot of network, audio device, or disk activity
at the time? Are these failures without X consistently reproducible,
or unpredictable?  Can you remember the revision number of the last
version of -CURRENT that didn't have these problems?

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: Runaway intr, not flash related

[b. f.]

My runaway intr problem with flash has been continuing all along, but
since no one has been interested in helping with it I haven't reported
it for a while. However, today, for the first time, it happened when I
had not run flash at all since I booted.

My system:
Dell D620, C2D, i386, SMP, r210908

swi4: clock is the culprit again this time, but when flash triggers this
problem I sometimes see hdac as the culprit, FYI.

I wouldn't say that no one is interested in helping.  (And I think
you've received a few more suggestions than your other recent message
to freebsd-developers suggests.)  For my part, I find it a bit
difficult to track the status of your interrupt problem, and the
interactivity problem, which may or may not be related.

--Have you ruled out any contribution from overheating, like I think
you were experiencing before with this machine?  At one point, you
were following some of mav@'s suggestions for power-saving, but then
you posted a configuration that suggested that you had abandoned some
of these settings and returned to the defaults.  So are you running
hot, or being throttled now?  Have you tried running at a kern.hz 
1000, with throttling disabled, to see if that ameliorates the
problem?

--What graphics driver are you using?  You were using
x11/nvidia-driver, but then after the kib@ and alc@'s vm changes that
led to problems with that driver, I thought you were using
x11-drivers/xf86-video-nv -- is that still the case?  Does switching
drivers seem to influence the frequency or severity of the problems?

--When do you experience these problems?  Do they ever occur when you
are _not_ running X?  Have you tried temporarily disabling your usb
and network devices, to see if they are contributing to the problem?
Are you able to watch flash videos from local media, as opposed to
those from a remote site, without problems?

--Did you follow mav@'s suggestion to use something other than your
hpet for the eventcounter and timecounter?  The possible use of the
hpet is one of the main differences between the new and old timing
code, and you reported some problems with your hpet earlier.

--Did you follow attilio@'s suggestion to obtain scheduling traces for
the interactivity problem, as described in
src/tools/sched/schedgraph.py?

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: [CFT] if_ath updates - ar5416 (macbook pro, etc)

[b. f.]

...
 ugen3.3: product 0x2234 vendor 0x1915 at usbus3, cfg=0 md=HOST
 spd=HIGH (480Mbps) pwr=ON

 That vendor:product combination is in the above list.

 It looks like it's this:

 http://linuxwireless.org/en/users/Drivers/zd1211rw


Are you sure about that? I don't see a Linksys WUSB54G revision in the
list of supported devices for that driver:

http://linuxwireless.org/en/users/Drivers/zd1211rw/devices

But I know that some versions of the WUSB54G used Intersil/Conexant
chipsets, and:

http://tomoyo.sourceforge.jp/cgi-bin/lxr/source/drivers/net/wireless/p54/p54usb.c

has:

 51 {USB_DEVICE(0x1915, 0x2234)},   /* Linksys WUSB54G OEM */

and states that this is a first-generation USB device with a
Intersil/Conexant ISL3886 chipset and a net2280 usb-pci bridge).  See
more details at:

http://linuxwireless.org/en/users/Drivers/p54

So maybe weongyo@ could make this work with upgt(4)?

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: [head tinderbox] failure on amd64/amd64

[b. f.]

 FreeBSD Tinderbox tinderbox at freebsd.org writes:
  === games/fortune/strfile (obj,depend,all,install)
  /obj/src/tmp/src/games/fortune/strfile created for 
  /src/games/fortune/strfile
  rm -f .depend
  mkdep -f .depend -a-I/obj/src/tmp/legacy/usr/include 
  /src/games/fortune/strfile/strfile.c
  echo strfile: /usr/lib/libc.a /obj/src/tmp/legacy/usr/lib/libegacy.a  
  .depend
  cc -O2 -pipe -std=gnu99   -I/obj/src/tmp/legacy/usr/include -c 
  /src/games/fortune/strfile/strfile.c
  cc -O2 -pipe -std=gnu99   -I/obj/src/tmp/legacy/usr/include  -static 
  -L/obj/src/tmp/legacy/usr/lib -o strfile strfile.o -legacy
  Syntax error: end of file unexpected (expecting ))
  *** Error code 2
 
  Stop in /src/games/fortune/strfile.

 Does anyone have any idea what caused this?  The exact same error
 occurred on all platforms / architectures.

Some recent changes (r210612) to system makefiles related to the
userland dtrace project.  I think Rui fixed it with two subsequent
commits, r210636 and r210656.

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: BSD grep fixes

[b. f.]

On 7/28/10, Gabor Kovesdan ga...@freebsd.org wrote:
 Em 2010.07.27. 5:59, b. f. escreveu:

 Thanks for bringing this up, I'll take a look and try to implement the
 same behaviour. And I will also document the behaviour.

I don't think that the current behavior of bsdgrep is necessarily bad
-- in fact it seems to me to be simple and intuitive: nothing is
excluded or included implicitly, and (I think) the last match wins,
unlike in gnu grep.  I mention it only because it is different, and
you may want to consider how closely you want it to mimic the behavior
of gnu grep for the sake of compatibility.  If bsdgrep already passed
a ports exp-run, and build/installworld now work without any problems,
then it may be simpler to just retain the current behavior.  Either
way, though, the effect of overlapping --(in|ex)clude(-dir) options
should be explicitly mentioned in the manpage.  Thank you, by the way,
for your efforts to provide us with good BSD-licensed tools.  I hope
that you can find the time and energy to continue with the iconv,
regex, and other text-processing tool improvements.

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: BSD grep fixes

[b. f.]

Other important differences between bsdgrep and GNU grep:

The --include option in bsdgrep does not have the same effect as the
corresponding option in GNU grep -- in GNU grep, that option causes
_only_ those files matching the file inclusion pattern to be searched.
 To obtain the same behavior in bsdgrep, one must issue something like
--exclude '*' --include pattern.

The effect of multiple overlapping --include and --exclude options is
different in the two greps.  It would be wise to add comments about
precedence of such options in the bsdgrep manpage, as is done, for
example, in bsdtar(1).


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: Interactivity problems

[b. f.]

I use -current on my laptop as my regular X platform, and for the last
few months I've been noticing that interactivity problems have been
getting a lot worse, by which I mean that if I have something running in
the background that is either disk or cpu intensive, anything else I try
to do on the system suffers. The most usual symptom is painfully slow
refresh times on windows, skipping audio, jumpy mouse, etc. These
problems persist even if I nice the hungry process.

Does it only happen when X is running?  Have you tried using gsched(8)
to see if that helps when disk activity is involved?


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

Our aging base system heimdal

[b. f.]

Is anybody planning to update the base system heimdal, which has been
largely untouched since May 2008?  In addition to the many other
bug-fixes and improvements in the current version 1.3.3 (see, for
example:

http://www.h5l.org/releases.html

), there are patches for heimdal vulnerabilities 2010-05-27 and
2010-03-21 (CVE-2010-1321), which are described at:

http://www.h5l.org/advisories.html

Others have mentioned that they have problems using our base system
heimdal -- problems that cannot be easily circumvented by rebuilding
WITHOUT_KERBEROS, and using security/krb5 (security/heimdal is badly
outdated), because this leaves various dependent base system utilities
behind, if they are not modified.

Regards,
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: Our aging base system krb5 [heimdal]

[b. f.]

I would love for it to go away entirely, and those base-system
components that depend on it to learn how to use either Kerberos
implementation from ports.  (I'd also love for the ancient and broken
base version of libcom_err to go away -- there's no knob to turn it
off, and the shared library conflicts with ports/krb5.)

I think that would please a lot of people -- but is the project still
committed to having a Kerberos implementation as one of a few
important applications in the base system, so that users don't have to
rely upon ports?  Would relegating it to ports mean that Kerberos
would be disabled by default in base system utilities, so that the
base system is self-hosting?  What incompatibilities exist between
that latest versions of the MIT Kerberos and Heimdal implementations?
How does des@ feel about it, since libpam and openssh may have to be
altered?

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: [TESTING]: ClangBSD branch needs testing before the import to HEAD

[b. f.]

Mark Linimon wrote:
On Tue, Jun 01, 2010 at 12:18:41PM +0200, Alban Hertroys wrote:
 Compiler bugs in gcc are probably just as hard to find as compiler bugs
 in clang

There are two types of compiler bug: a) bug that produces bad code; b)
bug that makes the compiler crash.


Let's remember that the entire toolchain is important here, and not
just the compiler.  Some of the problems can be attributed to our old
binutils.

For comparison, bitrot that is probably due to older ports not keeping
up with compiler changes is at:

http://portsmon.freebsd.org/portsconcordanceforbuilderror.py?build_error=gcc4_error


How did you obtain gcc4-errors?

We're not alone here: some major GNU/Linux distributions, NetBSD, and
DragonFlyBSD are using newer versions of binutils and/or gcc, so we
can look at their patches and error logs to fix some problems.

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: [TESTING]: ClangBSD branch needs testing before the import to HEAD

[b. f.]

On 6/4/10, Andriy Gapon a...@icyb.net.ua wrote:
 on 04/06/2010 11:13 b. f. said the following:
 Mark Linimon wrote:
 On Tue, Jun 01, 2010 at 12:18:41PM +0200, Alban Hertroys wrote:
 Compiler bugs in gcc are probably just as hard to find as compiler bugs
 in clang
 There are two types of compiler bug: a) bug that produces bad code; b)
 bug that makes the compiler crash.


 Let's remember that the entire toolchain is important here, and not
 just the compiler.  Some of the problems can be attributed to our old
 binutils.

 For comparison, bitrot that is probably due to older ports not keeping
 up with compiler changes is at:

 http://portsmon.freebsd.org/portsconcordanceforbuilderror.py?build_error=gcc4_error


 How did you obtain gcc4-errors?

 We're not alone here: some major GNU/Linux distributions, NetBSD, and
 DragonFlyBSD are using newer versions of binutils and/or gcc, so we
 can look at their patches and error logs to fix some problems.

 DragonFlyBSD and NetBSD use newer GCC?
 This is the first time I hear about that.
 No doubt about major Linux distributions, though.

DragonFlyBSD imported gcc 4.4 into their development branch in August
2009, binutils 2.20 in Oct. 2009, and switched to binutils 2.20 and
gcc 4.4.2 in their 2.6.1 release:

http://www.dragonflybsd.org/release26/
http://gitweb.dragonflybsd.org/dragonfly.git/history/HEAD:/gnu/lib/gcc44
http://gitweb.dragonflybsd.org/dragonfly.git/history/HEAD:/gnu/usr.bin/binutils220

NetBSD allows one to set HAVE_BINUTILS=2.19 and use

http://cvsweb.netbsd.org/bsdweb.cgi/src/external/gpl3/?only_with_tag=MAIN

See the README there for their policy statement.  I think they decided
to bite the bullet and allow optional use of the later version because
it was becoming increasingly hard to support some of their many
architectures with the old stuff.  But no doubt their mailing lists
have more information.

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: [TESTING]: ClangBSD branch needs testing before the import to HEAD

[b. f.]

On 6/4/10, Mark Linimon lini...@lonesome.com wrote:
 On Fri, Jun 04, 2010 at 08:13:55AM +, b. f. wrote:
 How did you obtain gcc4-errors?

 bzgrep -q See URL:http://gcc.gnu.org/bugs.html for instructions.  Part
 of ports/Tools/portbuild/scripts/processonelog .

But are you actually building with lang/gcc4* and devel/binutils when
these advisories are generated?  If so, what added configuration
settings are you using?

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: [TESTING]: ClangBSD branch needs testing before the import to HEAD

[b. f.]

On 6/4/10, b. f. bf1...@googlemail.com wrote:
 On 6/4/10, Andriy Gapon a...@icyb.net.ua wrote:
 on 04/06/2010 11:13 b. f. said the following:
 Mark Linimon wrote:
 On Tue, Jun 01, 2010 at 12:18:41PM +0200, Alban Hertroys wrote:


 NetBSD allows one to set HAVE_BINUTILS=2.19 and use

 http://cvsweb.netbsd.org/bsdweb.cgi/src/external/gpl3/?only_with_tag=MAIN

 See the README there for their policy statement.  I think they decided
 to bite the bullet and allow optional use of the later version because
 it was becoming increasingly hard to support some of their many
 architectures with the old stuff.  But no doubt their mailing lists
 have more information.

I should say that, with reference to the NetBSD changes I mentioned
earlier, and John Baldwin's comments about having a GPLv3 toolchain
option in our own tree, that despite NetBSD's cautious policy
statement regarding GPLv3-licensed software in their base system, and
their requirement that such software should be optional, it appears
that use of such software is now their _default_ since Nov. 2009:

http://cvsweb.netbsd.org/bsdweb.cgi/src/share/mk/bsd.own.mk.diff?r1=1.593r2=1.594only_with_tag=MAINf=h

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: 'buildworld' not always pulling in /etc/src.conf

[b. f.]

Wouldn't it be great, if /etc/make.conf disappeared completely?

To be replaced by /etc/src.conf for buildworld/kernel stuff.

And /etc/ports.conf for ports building stuff.


Er, and replaced by what for using make on the many things that are
neither in the base system, nor in FreeBSD Ports?  The world of
software is a big place.

With no linkage of any kind between the two, with all the magic hidden in
/usr/ports/Mk and /usr/share/Mk.

Maybe I'm dreaming, but wouldn't it make things a lot simpler in the long
run?

Just because you have a make.conf, doesn't mean that you can't have a
ports.conf, or that you must continue to use src.conf in the way that
it is used now.

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: [TESTING]: ClangBSD branch needs testing before the import to HEAD

[b. f.]

I'm a bit disappointed in the polemical nature of some of the comments
in this thread.  I think we're all better off because of the existence
of the FSF and their affiliates, and of a body of useful software
under the (L)GPL, even if we prefer another license.  No one has
forced us to use the work that they've made freely available.

With regard to importing clang now, I think that the effort needed for
switching to a new compiler will not be greatly diminished by waiting,
and we will be better served by learning about possible problems (and
attempting to have them fixed upstream) sooner rather than later.
Those who are concerned about introducing more variables into
debugging will still be free to disregard reports involving clang for
now if they choose, and we can emphasize that users should provide
information about which compiler is involved in bug reports.

Please, will those managing the import follow the recommendation of
the tool-chain summit in allowing users to opt out of building and
installing clang and any related tools with a knob in src.conf, and
add support for ripping it out via the delete-old(-libs) targets and
tools/build/mk/OptionalObsoleteFiles.inc, as part of any initial
import?

Also, others have announced that they are running regression tests on
systems built with clang.  Would it be possible to set up some
regularly scheduled tests to uncover possible problems, if this hasn't
been done already?

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: wpa_supplicant (Was: Re: wpi not working on today's current (r208626))

[b. f.]

On 5/29/10, Rui Paulo rpa...@freebsd.org wrote:

 On 29 May 2010, at 05:39, b. f. wrote:

 On 5/28/10, Doug Barton do...@freebsd.org wrote:
 On 5/28/2010 4:50 PM, b. f. wrote:

 I can't see any problems when using WPA2 with AES on r208606 i386 with
 uath(4).  I'm updating this machine to r208630 tonight, and if I
 encounter problems with the later revision, I'll let you know.

 Ok, thanks.

 Are
 you saying that you experienced problems when trying to use a r207134
 base with a r208626 kernel?  If that's the case, I would recommend
 updating the base to the same revision as the kernel, and then
 retesting.

 Yes, that's what I'm doing I actually tried running the newly built
 wpa_supplicant but that didn't work. I'm kind of hesitant to do the full
 upgrade since I'm having kernel problems with the nvidia driver, but if
 I'm sure wpa_supplicant will work then I suppose I can bite the bullet.


 It appears that something is wrong.  My wireless stick no longer
 associates with the network with r208630.  I'll do some tinkering.

 That's odd. The only way for that to happen would be caused bug in the
 taskqueue stuff that zml committed, I think, but that's a long shot.

 Regards,
 --
 Rui Paulo

Yes, that was also my suspicion, and after seeing, via top(1), that
ifconfig is stuck in the   *taskq state while attempting to set up
the wlan, I believe either r208623, or r208624, or both, is
responsible for the regression.

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: Call for Test and Review: bwn(4) - another Broadcom Wireless driver

[b. f.]

Hi, with yesterday's CURRENT my bwn works partially.

this is my hardware
siba_bwn0 at pci0:4:0:0:class=0x028000 card=0x04b514e4 chip=0x431514e4
rev=0x01 hdr=0x00
vendor = 'Broadcom Corporation'
device = 'Broadcom Wireless b/g (BCM4315/BCM22062000)'
class  = network

it works with WPA ap without destroy/re-create wlan0
, but it's unstable, at the first time it works, it goes forth and
back between associated and no carrier,
the other times it stay associated but network is down.
and this usually followed by system freeze if I `/etc/rc.d/netif restart` 
later.

and it never get associated with a open ap.

This sounds similar to the problems detailed in the recent wpa
supplicant (Was: Re: wpi not working on today's current ... thread.
Have you tried reverting r208623 and r208624?

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: wpa_supplicant (Was: Re: wpi not working on today's current (r208626))

[b. f.]

On 05/28/10 13:18, Doug Barton wrote:
 I am trying to update -current in order to try kib's patch for the
 nvidia driver, and the wpi driver won't establish a connection. I'm
 using r207134 right now without any problems, but that's a long time
 back to try and do a binary search.

 I don't see any changes to wpi or wpa_supplicant between then and now,
 anyone have an idea of where to look? My WAP is using WPA2 with AES if
 that's any help.

Correction, the problem seems to be more generally with wpa_supplicant.
I tried with the new kernel and my ath PCMCIA card (AR5416 mac 13.10
RF2133 phy 8.1) and it doesn't work with the latest kernel either.
However, the same card is working fine with the older kernel (I'm using
it now).

I can't see any problems when using WPA2 with AES on r208606 i386 with
uath(4).  I'm updating this machine to r208630 tonight, and if I
encounter problems with the later revision, I'll let you know.  Are
you saying that you experienced problems when trying to use a r207134
base with a r208626 kernel?  If that's the case, I would recommend
updating the base to the same revision as the kernel, and then
retesting.

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: wpa_supplicant (Was: Re: wpi not working on today's current (r208626))

[b. f.]

On 5/28/10, Doug Barton do...@freebsd.org wrote:
 On 5/28/2010 4:50 PM, b. f. wrote:

 I can't see any problems when using WPA2 with AES on r208606 i386 with
 uath(4).  I'm updating this machine to r208630 tonight, and if I
 encounter problems with the later revision, I'll let you know.

 Ok, thanks.

 Are
 you saying that you experienced problems when trying to use a r207134
 base with a r208626 kernel?  If that's the case, I would recommend
 updating the base to the same revision as the kernel, and then
 retesting.

 Yes, that's what I'm doing I actually tried running the newly built
 wpa_supplicant but that didn't work. I'm kind of hesitant to do the full
 upgrade since I'm having kernel problems with the nvidia driver, but if
 I'm sure wpa_supplicant will work then I suppose I can bite the bullet.


It appears that something is wrong.  My wireless stick no longer
associates with the network with r208630.  I'll do some tinkering.

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: Recent sys/vm/ changes and nvidia-driver

[b. f.]

On 5/10/10, Brandon Gooch jamesbrandongo...@gmail.com wrote:


 Is there a final target state regarding the work and/or a time-frame
 for completion? Perhaps a heads-up e-mail to the freebsd-current
 mailing list when the first round of commits have settled in? I'm
 wondering, due to the Nvidia issue stated in this thread, as well as
 panics I'm seeing using VirtualBox on my computer running HEAD.


Kip, could you please add an entry for the __FreeBSD_version 900011 to
 the Porter's
Handbook table in doc/en_US.ISO8859-1/books/porters-handbook/book.sgml
, as documented in src/sys/sys/param.h, if no one else beats you to
it?  In addition to alerting porters to the VM changes, it will remind
them that we've also had a version bump after the import of OpenSSL
0.9.8n.

Regards,
  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: Recent sys/vm/ changes and nvidia-driver

[b. f.]

On 05/08/10 13:36, Alan Cox wrote:
 Doug Barton wrote:
 On 05/05/10 11:56, Alan Cox wrote:

 I'm afraid that I would advise waiting a few days.  This round of
 changes
 are not yet complete.

What performance differences, if any, can we expect on uniprocessors
from the vm page lock-related changes? Kip's original post on -arch
mentioned some performance improvements and no significant
regressions, but on a dual 4-core machine.

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: Recent sys/vm/ changes and nvidia-driver

[b. f.]

On 5/8/10, Kip Macy kip.m...@gmail.com wrote:
 On Sat, May 8, 2010 at 2:39 PM, Brandon Gooch
 jamesbrandongo...@gmail.com wrote:
 On Sat, May 8, 2010 at 4:20 PM, b. f. bf1...@googlemail.com wrote:
 On 05/08/10 13:36, Alan Cox wrote:
 Doug Barton wrote:
 On 05/05/10 11:56, Alan Cox wrote:

 I'm afraid that I would advise waiting a few days.  This round of
 changes
 are not yet complete.

 What performance differences, if any, can we expect on uniprocessors
 from the vm page lock-related changes? Kip's original post on -arch
 mentioned some performance improvements and no significant
 regressions, but on a dual 4-core machine.

 Alan (or Kip): Is there a document available that describes the work
 being done on the VM system?

 I would like to -- or like make and attempt to -- read such a document...

 Hey b. f., to which post on -arch are you referring?


I was referring to the message listed in Kip's link below.

 there is no document. The basic idea is straightforward, but there are
 some unpleasant edges to cope with.

 http://www.mavetju.org/mail/view_message.php?list=freebsd-archid=3155260thread=no

 -Kip

___
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: svn commit: r206497 - in head: sbin/geom/class sbin/geom/class/sched sys/geom/sched sys/modules/geom sys/modules/geom/geom_sched sys/modules/geom/geom_sched/gs_sched sys/modules/geom/geom_sched/g

[b. f.]

Author: luigi
Date: Mon Apr 12 16:37:45 2010
New Revision: 206497
URL: http://svn.freebsd.org/changeset/base/206497

Log:
  Bring in geom_sched, support for scheduling disk I/O requests
  in a device independent manner. Also include an example anticipatory
  scheduler, gsched_rr, which gives very nice performance improvements
  in presence of competing random access patterns.

Thank you for bringing this in.  Do you or your collaborators also
plan to add the BFQ scheduler that was in the earlier separate
tarballs?  The numbers at

http://algo.ing.unimo.it/people/paolo/disk_sched/

suggest that it worked well in a different context.

Also, there is a typographical error in the gsched(8) manpage: in the
EXAMPLES section, -s should be -a in:

   # Configure device ad0 to use scheduler 'rr':
   geom sched insert -s rr ad0


Regards,
   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: svn commit: r206497 - in head: sbin/geom/class sbin/geom/class/sched sys/geom/sched sys/modules/geom sys/modules/geom/geom_sched sys/modules/geom/geom_sched/gs_sched sys/modules/geom/geom_sched/g

[b. f.]

On 4/13/10, Luigi Rizzo ri...@iet.unipi.it wrote:
 On Tue, Apr 13, 2010 at 07:09:50PM +, b. f. wrote:
 Author: luigi
 Date: Mon Apr 12 16:37:45 2010
 New Revision: 206497
 URL: http://svn.freebsd.org/changeset/base/206497
 
 Log:
   Bring in geom_sched, support for scheduling disk I/O requests
   in a device independent manner. Also include an example anticipatory
   scheduler, gsched_rr, which gives very nice performance improvements
   in presence of competing random access patterns.

 Thank you for bringing this in.  Do you or your collaborators also
 plan to add the BFQ scheduler that was in the earlier separate

 sooner or later, yes.

Oh, good.

What do you think about adding an easy way to automatically enable
scheduling on designated disks -- an rc-script, like that for geli,
for example?


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

$B$h$&$3$=!"$"$f$_$N%[!<%`%Z!<%8(B$B$X(B

[$B$&quot;$f$_(B]

$B$O$8$a$^$7$F!"$"$f$_(B $B$H8@$$$^$9!#(B

$BFMA3$N%a!<%k$G!"$4$a$s$J$5$$!#(B

$B$3$s$J;d$,%[!<%`%Z!<%8$r:n$C$A$c$$$^$7$?!#(B
$B$^$@!"2?$bL5$$$s$@$1$I!&!&!&!#(B
$B$G$b!"$3$s$J;d$G$b(B"$B%j!{%k!<%He$KBg$-$/$H$j$"$2$F$b$i$($F$H$C$F$b%O%C%T!<$G$9!#(B
http://www1.sphere.ne.jp/cube/idol/

$B$I$)!