Re: CFR: Replace man/manpath/whatis/apropos with a shell script

[Gordon Tetlow]

On Wed, Aug 18, 2010 at 5:01 PM, Anonymous  wrote:

> Gordon Tetlow  writes:
>
> It doesn't search in bin/../man nor in bin/.man. For example,
> my PATH contains $LOCALBASE/bin:$HOME/.bin, while /etc/manpath.config
> is default one and contains /usr/local/man which does not exist here.
>

Guess I missed that pretty badly in my port. I'll go back and retool the
logic for this but that'll take a bit of time.

I guess there is one more bug.
>
>  $ MANPATH=$HOME/.bin/man man mplayer
>  zcat: HOME/.bin/man/man1/mplayer.1: not in gzip format
>  $ MANPATH=$HOME/.bin/man man -ddd mplayer
>  -- Using architecture: amd64:amd64
>  -- Using pager: less
>  -- Using manual sections: 1:1aout:8:2:3:n:4:5:6:7:9:l
>  -- Using locale paths: en_US.UTF-8:en.UTF-8:.
>  -- Searching for mplayer
>  -- Searching section 1
>  --   Searching directory HOME/.bin/man/man1
>  -- Found manpage HOME/.bin/man/man1/mplayer.1
>  -- Skipping catpage: not found or old
>  -- Command: /usr/bin/zcat HOME/.bin/man/man1/mplayer.1 | /usr/bin/tbl
> | /usr/bin/groff -S -Wall -mtty-char -man -Tascii | /usr/bin/col | less
>

Fixed. Switched to using zcat -f  which works on both compressed and
uncompressed files. (Yay for being lazy!)

Thanks for the report!
Gordon
___
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"

BSD grep performance

[Doug Barton]

On 08/18/2010 10:48, Gabor Kovesdan wrote:


I've just committed a patch with the kind help of Dimitry Andric,
which gives BSD grep a huge performance boost.


Agreed, as I reported earlier.


The performance is now almost comparable to GNU grep.


I think you're using a very liberal definition of "comparable."

http://people.freebsd.org/~dougb/grep-time-trial.sh.txt
http://people.freebsd.org/~dougb/grep-time-trial-2.sh.txt

./grep-time-trial
GNU grep
Elapsed time: 2 seconds

BSD grep
Elapsed time: 15 seconds

./grep-time-trial-2
GNU grep
Elapsed time: 3 seconds

BSD grep
Elapsed time: 11 seconds


I think with this, BSD grep may remain default if no other serious
issues come up.


I'm not going to re-state my opinion here except to say it hasn't 
changed. Even if the performance were not an issue I think the bugs 
mentioned below combined with your 4-day absence should also have been 
considerations. However, in regards to this particular case I think it's 
pretty obvious that I'm either alone, or in a very non-vocal group; so 
c'est la vie.


However, from the standpoint of committer relations I think that first 
stating that you would change the default, then not doing so before all 
of the outstanding issues were resolved is not what I would consider a 
good model for others to follow.



FWIW,

Doug



Please report if you notice something weird.

I know about some minor issues, which aren't fixed yet. I'll be out
for 4 days as of tomorrow but when I come back I'll take care of
these:- Infinite loop when reading directory on ZFS/NFS filesystem
- Problems with context grepping


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

[head tinderbox] failure on powerpc64/powerpc

[FreeBSD Tinderbox]

TB --- 2010-08-19 01:12:25 - tinderbox 2.6 running on freebsd-current.sentex.ca
TB --- 2010-08-19 01:12:25 - starting HEAD tinderbox run for powerpc64/powerpc
TB --- 2010-08-19 01:12:25 - cleaning the object tree
TB --- 2010-08-19 01:13:00 - cvsupping the source tree
TB --- 2010-08-19 01:13:00 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca 
/tinderbox/HEAD/powerpc64/powerpc/supfile
TB --- 2010-08-19 01:13:18 - building world
TB --- 2010-08-19 01:13:18 - MAKEOBJDIRPREFIX=/obj
TB --- 2010-08-19 01:13:18 - PATH=/usr/bin:/usr/sbin:/bin:/sbin
TB --- 2010-08-19 01:13:18 - TARGET=powerpc
TB --- 2010-08-19 01:13:18 - TARGET_ARCH=powerpc64
TB --- 2010-08-19 01:13:18 - TZ=UTC
TB --- 2010-08-19 01:13:18 - __MAKE_CONF=/dev/null
TB --- 2010-08-19 01:13:18 - cd /src
TB --- 2010-08-19 01:13:18 - /usr/bin/make -B buildworld
>>> World build started on Thu Aug 19 01:13:21 UTC 2010
>>> Rebuilding the temporary build tree
>>> stage 1.1: legacy release compatibility shims
>>> stage 1.2: bootstrap tools
>>> stage 2.1: cleaning up the object tree
>>> stage 2.2: rebuilding the object tree
>>> stage 2.3: build tools
>>> stage 3: cross tools
>>> stage 4.1: building includes
>>> stage 4.2: building libraries
>>> stage 4.3: make dependencies
>>> stage 4.4: building everything
>>> stage 5.1: building 32 bit shim libraries
>>> World build completed on Thu Aug 19 02:51:08 UTC 2010
TB --- 2010-08-19 02:51:08 - generating LINT kernel config
TB --- 2010-08-19 02:51:08 - cd /src/sys/powerpc/conf
TB --- 2010-08-19 02:51:08 - /usr/bin/make -B LINT
TB --- 2010-08-19 02:51:08 - building LINT kernel
TB --- 2010-08-19 02:51:08 - MAKEOBJDIRPREFIX=/obj
TB --- 2010-08-19 02:51:08 - PATH=/usr/bin:/usr/sbin:/bin:/sbin
TB --- 2010-08-19 02:51:08 - TARGET=powerpc
TB --- 2010-08-19 02:51:08 - TARGET_ARCH=powerpc64
TB --- 2010-08-19 02:51:08 - TZ=UTC
TB --- 2010-08-19 02:51:08 - __MAKE_CONF=/dev/null
TB --- 2010-08-19 02:51:08 - cd /src
TB --- 2010-08-19 02:51:08 - /usr/bin/make -B buildkernel KERNCONF=LINT
>>> Kernel build for LINT started on Thu Aug 19 02:51:08 UTC 2010
>>> stage 1: configuring the kernel
>>> stage 2.1: cleaning up the object tree
>>> stage 2.2: rebuilding the object tree
>>> stage 2.3: build tools
>>> stage 3.1: making dependencies
>>> stage 3.2: building everything
[...]
/src/sys/dev/ofw/ofw_standard.c:705: warning: cast to pointer from integer of 
different size
/src/sys/dev/ofw/ofw_standard.c: In function 'ofw_std_release':
/src/sys/dev/ofw/ofw_standard.c:719: warning: cast from pointer to integer of 
different size
/src/sys/dev/ofw/ofw_standard.c:724: warning: cast from pointer to integer of 
different size
/src/sys/dev/ofw/ofw_standard.c: In function 'ofw_std_enter':
/src/sys/dev/ofw/ofw_standard.c:742: warning: cast from pointer to integer of 
different size
/src/sys/dev/ofw/ofw_standard.c: In function 'ofw_std_exit':
/src/sys/dev/ofw/ofw_standard.c:760: warning: cast from pointer to integer of 
different size
*** Error code 1

Stop in /obj/powerpc.powerpc64/src/sys/LINT.
*** Error code 1

Stop in /src.
*** Error code 1

Stop in /src.
TB --- 2010-08-19 03:04:31 - WARNING: /usr/bin/make returned exit code  1 
TB --- 2010-08-19 03:04:31 - ERROR: failed to build lint kernel
TB --- 2010-08-19 03:04:31 - 4834.63 user 1183.45 system 6726.66 real


http://tinderbox.freebsd.org/tinderbox-head-HEAD-powerpc64-powerpc.full
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: CFR: Replace man/manpath/whatis/apropos with a shell script

[Hiroki Sato]

Gordon Tetlow  wrote
  in :

go> On Wed, Aug 18, 2010 at 12:11 AM, Gordon Tetlow  wrote:
go>
go> > All,
go> >
go> > I sat down and rewrote the man tools from a relatively old codebase to a
go> > single shell script. My original motivation was to allow multiple
go> > configuration files so port installations did not have to mess with
go> > /etc/manpath.config (like perl for example) when needing to manipulate the
go> > manpath. After looking at the existing code, I figured I could rewrite it 
as
go> > a shell script relatively easily.
go> >
go> > Script (install as /usr/bin/man, /usr/bin/manpath, /usr/bin/apropos,
go> > /usr/bin/whatis)
go> > 
http://people.freebsd.org/~gordon/man.sh
go> >
go> > Features of the new code:
go> >
go> > 1. BSD licensed (old code is GPL).
go> > 2. Imports configuration from /usr/local/etc/man.d/*.conf and 
/etc/man.conf
go> > (purposefully changed the manpath.config file since it is a different
go> > syntax).
go> > 3. Allows ports to override the toolset used to display the manpage based
go> > on language. This was done to try to merge the functionality of the
go> > japanese/man port into the base system as much as possible.
go> >
go> > I've tried to make this mirror the functionality, directory search order,
go> > and arguments as the current base implementation.
go> >
go> > This brings me to my next point. I need some testers willing to try this
go> > out. It would be particularly great if I could get some foreign language
go> > testers with localized manpage installations. If something doesn't work 
the
go> > way you expect, please contact me and I can help debug it (using man -ddd
go> >  will generally give me the debug information I need).
go> >
go> > Thanks,
go> > Gordon
go> >
go>
go> I did some additional testing with the japanese/man-doc port and found the
go> following was necessary:

 Great, I will test it and get back to you!

-- Hiroki


pgpQyXyxPu4Qz.pgp
Description: PGP signature

Re: 8.1-release + zfs v15 df(1) hangs

[jhell]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 08/18/2010 15:46, Andriy Gapon wrote:
> on 18/08/2010 22:07 Marian Hettwer said the following:
>> I'll try and reproduce that tomorrow. I would say, a hanging nfs mount
>> shouldn't lead to a hanging around df(1).
> 
> See df -n.
> 

Going with this & making an addition.

I usually add this to my periodic.conf:
daily_status_disks_df_flags="-h -i -t ufs,zfs"

Adding '-c' for a system that has ZFS produces results that are not
correct for a total, but stating it more for reference. It might make
sense to patch df(1) so it looks at the begging portion of the
file-system up to the first '/' and get the value for free and used from
that but this is tricky when refreserved, quota and other properties
come into play and is a little beyond what df is meant for. But that
subject is for another thread.

I do wonder if it would make sense to just split the daily_status_disks*
into daily_status_{FILESYSTEM} to look like this
daily_status_ufs_df_flags etc... and keep daily_status_disks_df to be
defined as daily_status_disks_df="ufs zfs xfs"

Ignore random babbling meant to spur thought. ;)


Regards,

- -- 

 jhell,v
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.16 (FreeBSD)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iQEcBAEBAgAGBQJMbIQnAAoJEJBXh4mJ2FR+1lkH/3UbwkUE0L7AbivsIc1bjZA6
R+6lVv80xquXrgxZiMZWAhd40fqaduztM9hWzicL2yEVIsg+lp1WE4IRo2pyUdFs
ZTDsa3RcDpXeTt2NmUdMHefd0RC0aRrrAmf1JGifUs2/UNHpT/5PP1fIl783P71J
z8VFNcGcCmCSUcSdg8I14LDoFAqfbA0DkpTDyYrQVcHmNEp7aBgvJBNF+9/3y4R9
wC6+CbPVy93L3yOmxIfEM88oHtq4zfMRLcNreMAx+bQntzM7bA2xJrXV8Zkt5Jok
RFqE7TScKyE89YulkosSFMs1OK0SwTFDHZdAIO4mM4V9mVcaaZ8iWTiGrlZRxoQ=
=Kf91
-END PGP SIGNATURE-
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

unionfs a little improvement

[Daichi GOTO]

Hi Ed and unionfs fan gyus.

Ed pointed out a contradict behavior between current
unionfs implementation and its manual, and sent me a
patch.

Thanks Ed ;)


Index: sys/fs/unionfs/union_vfsops.c
===
--- sys/fs/unionfs/union_vfsops.c   (revision 211093)
+++ sys/fs/unionfs/union_vfsops.c   (working copy)
@@ -89,7 +89,6 @@
u_short ufile;
unionfs_copymode copymode;
unionfs_whitemode whitemode;
-   struct componentname fakecn;
struct nameidata nd, *ndp;
struct vattrva;

@@ -280,26 +279,6 @@
mp->mnt_flag |= ump->um_uppervp->v_mount->mnt_flag & MNT_RDONLY;

/*
-* Check whiteout
-*/
-   if ((mp->mnt_flag & MNT_RDONLY) == 0) {
-   memset(&fakecn, 0, sizeof(fakecn));
-   fakecn.cn_nameiop = LOOKUP;
-   fakecn.cn_thread = td;
-   error = VOP_WHITEOUT(ump->um_uppervp, &fakecn, LOOKUP);
-   if (error) {
-   if (below) {
-   VOP_UNLOCK(ump->um_uppervp, 0);
-   vrele(upperrootvp);
-   } else
-   vput(ump->um_uppervp);
-   free(ump, M_UNIONFSMNT);
-   mp->mnt_data = NULL;
-   return (error);
-   }
-   }
-
-   /*
 * Unlock the node
 */
VOP_UNLOCK(ump->um_uppervp, 0);



Ed's message here:


Just for fun I was hacking on a writable bootcd, using unionfs and
tmpfs. I noticed tmpfs doesn't support whiteouts (yet). This prevents
unionfs from mounting tmpfs on top. I do want to be able to use tmpfs,
even if it means we can't get any whiteouts.

The manpage says the following:

Without whiteout support from the file system backing the upper layer,
there is no way that delete and rename operations on lower layer 
objects

can be done.  EROFS is returned for this kind of operations along with
any others which would make modifications to the lower layer, such as
chmod(1).

This seems to contradict the current behaviour, which is to deny the
mount altogether. The attached patch makes it work, but instead of
EROFS, it now returns EOPNOTSUPP, as generated by VOP_WHITEOUT().



It looks like reasonable and patch is simple and effective I guess.
If you unionfs guys or fs guys have some ideas around this patch,
please teach me.

After some tests and a couple of weeks after, I'll commit ed's patch
if there is no objections.

--
Daichi GOTO
CEO | ONGS Inc.
81-42-316-7945 | dai...@ongs.co.jp | http://www.ongs.co.jp
LinkedIn: http://linkedin.com/in/daichigoto
___
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: LOR on nfs: vfs_vnops.c:301 kern_descrip.c:1580

[Rick Macklem]

> On 18 August 2010 12:07, pluknet  wrote:
> > On 17 August 2010 20:04, Kostik Belousov  wrote:
> >
> >>
> >> Also please take a note of the John' suggestion to use the taskqueue.
> >
> > I decided to go this road. Thank you both.
> > Now I do nfs buildkernel survive and prepare some benchmark results.
> >
> 
I'm away from home, so I can only do email and haven't looked at the
patch, but I think you might want to consider avoiding the malloc()
failure by calling malloc(... M_WAITOK); before grabbing the mutex.
Then, set the pointer to NULL if you use it and free it at the end
(I tend to test for non-NULL before calling free(), but others have
pointed out that this isn't necessary.)

I believe this is called "Dykstra's technique", although I used it
a lot before I found out it had been published.

I think handling the case where malloc() fails correctly could
be difficult which is why I suggested the above.

Good luck with the patch, rick


___
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: CFR: Replace man/manpath/whatis/apropos with a shell script

[Anonymous]

Anonymous  writes:

> Gordon Tetlow  writes:
>
>> I've tried to make this mirror the functionality, directory search order,
>> and arguments as the current base implementation.
>>
>> This brings me to my next point. I need some testers willing to try this
>> out. It would be particularly great if I could get some foreign language
>> testers with localized manpage installations. If something doesn't work the
>> way you expect, please contact me and I can help debug it (using man -ddd
>>  will generally give me the debug information I need).
>
> It doesn't search in bin/../man nor in bin/.man.
 
Oops, I meant bin/man there.
___
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: CFR: Replace man/manpath/whatis/apropos with a shell script

[Anonymous]

Gordon Tetlow  writes:

> I've tried to make this mirror the functionality, directory search order,
> and arguments as the current base implementation.
>
> This brings me to my next point. I need some testers willing to try this
> out. It would be particularly great if I could get some foreign language
> testers with localized manpage installations. If something doesn't work the
> way you expect, please contact me and I can help debug it (using man -ddd
>  will generally give me the debug information I need).

It doesn't search in bin/../man nor in bin/.man. For example,
my PATH contains $LOCALBASE/bin:$HOME/.bin, while /etc/manpath.config
is default one and contains /usr/local/man which does not exist here.

  $ man -w mplayer rsync
  HOME/.bin/man/man1/mplayer.1
  LOCALBASE/man/man1/rsync.1.gz

  $ echo $PATH
  
LOCALBASE/libexec/ccache:HOME/.bin:LOCALBASE/sbin:LOCALBASE/bin:/sbin:/bin:/usr/sbin:/usr/bin:/usr/games:HOME/blah/bin

Unfortunately, if ~/.bin is in PATH it still will not search in ~/.man
without touching MANPATH.

But with man.sh it doesn't respect PATH at all.

  $ man -ddd -w mplayer rsync
  -- Using architecture: amd64:amd64
  -- Using pager: less
  -- Using manual sections: 1:1aout:8:2:3:n:4:5:6:7:9:l
  -- Using manual path: /usr/share/man:/usr/share/openssl/man:/usr/local/man
  -- Using locale paths: en_US.UTF-8:en.UTF-8:.
  -- Searching for mplayer
  -- Searching section 1
  --   Searching directory /usr/share/man/en.UTF-8/man1
  --   Searching directory /usr/share/man/man1
  --   Searching directory /usr/share/openssl/man/man1
  -- Searching section 1aout
  --   Searching directory /usr/share/man/en.UTF-8/man1aout
  --   Searching directory /usr/share/man/man1aout
  -- Searching section 8
  --   Searching directory /usr/share/man/en.UTF-8/man8/amd64
  --   Searching directory /usr/share/man/en.UTF-8/man8/amd64
  --   Searching directory /usr/share/man/en.UTF-8/man8
  --   Searching directory /usr/share/man/man8/amd64
  --   Searching directory /usr/share/man/man8/amd64
  --   Searching directory /usr/share/man/man8
  -- Searching section 2
  --   Searching directory /usr/share/man/en.UTF-8/man2
  --   Searching directory /usr/share/man/man2
  -- Searching section 3
  --   Searching directory /usr/share/man/en.UTF-8/man3
  --   Searching directory /usr/share/man/man3
  --   Searching directory /usr/share/openssl/man/man3
  -- Searching section n
  -- Searching section 4
  --   Searching directory /usr/share/man/en.UTF-8/man4/amd64
  --   Searching directory /usr/share/man/en.UTF-8/man4/amd64
  --   Searching directory /usr/share/man/en.UTF-8/man4
  --   Searching directory /usr/share/man/man4/amd64
  --   Searching directory /usr/share/man/man4/amd64
  --   Searching directory /usr/share/man/man4
  -- Searching section 5
  --   Searching directory /usr/share/man/en.UTF-8/man5
  --   Searching directory /usr/share/man/man5
  -- Searching section 6
  --   Searching directory /usr/share/man/en.UTF-8/man6
  --   Searching directory /usr/share/man/man6
  -- Searching section 7
  --   Searching directory /usr/share/man/en.UTF-8/man7
  --   Searching directory /usr/share/man/man7
  -- Searching section 9
  --   Searching directory /usr/share/man/en.UTF-8/man9
  --   Searching directory /usr/share/man/man9
  -- Searching section l
  No manual entry for mplayer
  -- Searching for rsync
  -- Searching section 1
  --   Searching directory /usr/share/man/en.UTF-8/man1
  --   Searching directory /usr/share/man/man1
  --   Searching directory /usr/share/openssl/man/man1
  -- Searching section 1aout
  --   Searching directory /usr/share/man/en.UTF-8/man1aout
  --   Searching directory /usr/share/man/man1aout
  -- Searching section 8
  --   Searching directory /usr/share/man/en.UTF-8/man8/amd64
  --   Searching directory /usr/share/man/en.UTF-8/man8/amd64
  --   Searching directory /usr/share/man/en.UTF-8/man8
  --   Searching directory /usr/share/man/man8/amd64
  --   Searching directory /usr/share/man/man8/amd64
  --   Searching directory /usr/share/man/man8
  -- Searching section 2
  --   Searching directory /usr/share/man/en.UTF-8/man2
  --   Searching directory /usr/share/man/man2
  -- Searching section 3
  --   Searching directory /usr/share/man/en.UTF-8/man3
  --   Searching directory /usr/share/man/man3
  --   Searching directory /usr/share/openssl/man/man3
  -- Searching section n
  -- Searching section 4
  --   Searching directory /usr/share/man/en.UTF-8/man4/amd64
  --   Searching directory /usr/share/man/en.UTF-8/man4/amd64
  --   Searching directory /usr/share/man/en.UTF-8/man4
  --   Searching directory /usr/share/man/man4/amd64
  --   Searching directory /usr/share/man/man4/amd64
  --   Searching directory /usr/share/man/man4
  -- Searching section 5
  --   Searching directory /usr/share/man/en.UTF-8/man5
  --   Searching directory /usr/share/man/man5
  -- Searching section 6
  --   Searching directory /usr/share/man/en.UTF-8/man6
  --   Searching directory /usr/share/man/man6
  -- Searc

Re: Interpreted language(s) in the base

[Andrew Reilly]

Hi Luigi,

On 19/08/2010, at 00:28 , Luigi Rizzo wrote:

> slightly off topic but I disagree  on the latter part.

I didn't expect everyone to agree.  Not sure that I do, necessarily, either.  
(A neat, small language like TCL or Lua is probably better for most of the uses 
we're discussing here.)  Just making a low-impact suggestion to the problem of 
making use of a higher-level language than C while not dragging large lumps of 
code into core, or accumulating maintenance issues.

> The whole point of having source code is to be able to make
> modifications, small or large, private or ones to be contributed
> back. As a teacher, i am very concerned about the ease-of-use for
> non-developer types: it is important to make it easy for people to
> experiments, as this is one of the ways people learn things.

I'm not making any suggestion about preventing or discouraging tinkering.  
After all, we used to carry f2c around in the base, in order to support Fortran 
code.  There's no particular reason *not* to provide the front-end for 
(whatever language), but so long as it's readily available in ports, and 
build-able form a base config, I don't see that being in base is essential.

> Having sources in some fantastic new language 'fuffa' and no 'fuffa2c'
> tool is almost as bad as having no source.

This is an opinion I certainly don't share.  There are many languages that I 
don't like but that doesn't make them useful, or even best-for-purpose in their 
niche.  (a) I'm not suggesting that we don't provide source, and (b) learning a 
new language is an excellent excellent exercise for students, and one that 
they're going to have to go through often, for the rest of their careers.

> (in fact, it is like the
> joke of supplying source for the GPL'd software in your brand new
> LCD tv or appliance. I'd like to know who will ever be able to build
> an updated image and upload it to the appliance)

It's nothing of the sort, of course.  In the scenario I suggested, the task of 
updating the putative program would involve the editors available in base, to 
edit the source shipped with the system.  Only the compilation of the edited 
source might or might not be gated by installing the port for the putative 
compiler.  Several of the examples I gave originally come with an interpreter 
and debugging environment, so even that potential argument need not be a 
blocker.  Not a high bar to entry, I suggest.

Cheers,

-- 
Andrew

___
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

[Dimitry Andric]

On 2010-08-18 23:12, Dimitry Andric wrote:
>> And one trial is not statistically valid - especially given the small
>> differences.  How about multiple multiple trials with ministat.
> 
> The result were averages of three trials

Actually, since I kept using Doug's original grep-time-trial.sh, each of
the three 'trials' consisted of running grep 100 times, and the listed
time was the total elapsed time for those 100 runs.  So I assume that
will reasonably average out the differences between each individual run?

Also, I'm not sure if the actual disk/fs reading performance will differ
much between GNU grep and any other grep, since they will all basically
read through the whole test file sequentially.  For instance, when I
profiled GNU grep with gprof, the top time results were:

  %   cumulative   self  self total
 time   seconds   secondscalls  ms/call  ms/call  name
 99.1   0.59 0.5911497 0.05 0.05  read [5]
  0.6   0.59 0.0011497 0.00 0.00  kwsexec [8]
  0.1   0.59 0.000  100.00%   .mcount (130)
  0.1   0.59 0.001 0.62   594.77  grepfile [3]
  0.1   0.60 0.0011496 0.00 0.00  memmove [9]
  0.0   0.60 0.004 0.03 0.03  memchr [10]
  0.0   0.60 0.0012541 0.00 0.00  memset [16]
  0.0   0.60 0.0011497 0.00 0.00  EGexecute [7]
  0.0   0.60 0.0011497 0.00 0.05  fillbuf [4]
  0.0   0.60 0.0011497 0.00 0.00  grepbuf [6]

E.g. it looks like most of the time is spent in the read system call.
If mmap'ing can help improve that, it would be nice, but I suspect the
gains would be marginal.

The actual performance difference is much more likely to be related to
how efficiently grep parses out lines, and searches for regexps in
there.  BSD grep still has quite some room for improvement in that
department.

___
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: CFR: Replace man/manpath/whatis/apropos with a shell script

[Gordon Tetlow]

On Wed, Aug 18, 2010 at 12:11 AM, Gordon Tetlow  wrote:

> All,
>
> I sat down and rewrote the man tools from a relatively old codebase to a
> single shell script. My original motivation was to allow multiple
> configuration files so port installations did not have to mess with
> /etc/manpath.config (like perl for example) when needing to manipulate the
> manpath. After looking at the existing code, I figured I could rewrite it as
> a shell script relatively easily.
>
> Script (install as /usr/bin/man, /usr/bin/manpath, /usr/bin/apropos,
> /usr/bin/whatis)
> http://people.freebsd.org/~gordon/man.sh
>
> Features of the new code:
>
> 1. BSD licensed (old code is GPL).
> 2. Imports configuration from /usr/local/etc/man.d/*.conf and /etc/man.conf
> (purposefully changed the manpath.config file since it is a different
> syntax).
> 3. Allows ports to override the toolset used to display the manpage based
> on language. This was done to try to merge the functionality of the
> japanese/man port into the base system as much as possible.
>
> I've tried to make this mirror the functionality, directory search order,
> and arguments as the current base implementation.
>
> This brings me to my next point. I need some testers willing to try this
> out. It would be particularly great if I could get some foreign language
> testers with localized manpage installations. If something doesn't work the
> way you expect, please contact me and I can help debug it (using man -ddd
>  will generally give me the debug information I need).
>
> Thanks,
> Gordon
>

I did some additional testing with the japanese/man-doc port and found the
following was necessary:

1. Install my script as /usr/bin/man
2. Install japanese/man-doc
3. Create a /usr/local/etc/man.d/ja-man-doc.conf with the following
contents:

EQN_JA /usr/local/bin/geqn
COL_JA /bin/cat
NROFF_JA /usr/local/bin/groff -S -Wall -mtty-char -man -Tnippon
-dlang=ja_JP.eucJP
PIC_JA /usr/local/bin/gpic
TBL_JA /usr/local/bin/gtbl
TROFF_JA /usr/local/bin/groff -man -dlang=ja_JP.eucJP
MANLOCALE ja_JP.eucJP

4. Create a symlink from /usr/share/man/ja.eucJP -> /usr/local/man/ja
5. Set LC_CTYPE=ja_JP.eucJP
6. man ls

When all is said and done, 3 should be handled by the man-doc port while 4
is a problem.

The current base system man uses the following search order for localized
manpages (which I have emulated):

Look in
/usr/share/man/.
/usr/share/man/
...
/usr/local/man/.
/usr/local/man/
...

Without step 4 from above, if you were to attempt to get a localized manpage
for ls(1) that resides in /usr/local/man/., you would never see
it because the english language manpage in /usr/share/man would be found
first. The japanese man port gets around this by installing their own man
implementation (jman) forcing /usr/local/man/ja before /usr/share/man in
the search order. I'm interested in feedback about whether the search order
should change or if I should leave it as is.
___
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

[Dimitry Andric]

On 2010-08-18 22:52, Peter Jeremy wrote:
>>  grep with normal mmap()   1396s
>>  grep with prefault mmap() 1354s
>>  grep with regular read()  1354s
> 
> Is this with uncached (ie remount the filesystem on each test) or cached
> data?

This is all on the same filesystem, and the test file is ~370MB, so
eventually all data will be in RAM, most likely.  E.g. normal mmap()
seems to add a bit of overhead that explains the slower result.


> Which filesystem (and does it change for different filesystems
> (particularly between UFS and ZFS))?

I only checked on UFS2.


> And one trial is not statistically valid - especially given the small
> differences.  How about multiple multiple trials with ministat.

The result were averages of three trials; they were fairly close to each
other, but I didn't calculate the standard deviation.  I was not aware
of ministat, which looks like a real handy program. :)
___
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

[Peter Jeremy]

On 2010-Aug-17 22:29:46 +0200, Dimitry Andric  wrote:
>On 2010-08-17 18:29, Alan Cox wrote:
>> Try it again on a memory resident file with the MAP_PREFAULT_READ option
>> that is provided by this patch:
>> 
>> http://www.cs.rice.edu/~alc/MAP_PREFAULT_READ.patch
>
>A time trial gives:
>
>  grep with normal mmap()   1396s
>  grep with prefault mmap() 1354s
>  grep with regular read()  1354s

Is this with uncached (ie remount the filesystem on each test) or cached
data?  Which filesystem (and does it change for different filesystems
(particularly between UFS and ZFS))?

And one trial is not statistically valid - especially given the small
differences.  How about multiple multiple trials with ministat.

-- 
Peter Jeremy


pgpPvNHrEZWZQ.pgp
Description: PGP signature

Re: LOR on nfs: vfs_vnops.c:301 kern_descrip.c:1580

[John Baldwin]

On Wednesday, August 18, 2010 3:17:56 pm pluknet wrote:
> On 18 August 2010 23:11, pluknet  wrote:
> > On 18 August 2010 17:46, Kostik Belousov  wrote:
> >> On Wed, Aug 18, 2010 at 02:43:19PM +0400, pluknet wrote:
> >>> On 18 August 2010 12:07, pluknet  wrote:
> >>> > On 17 August 2010 20:04, Kostik Belousov  wrote:
> >>> >
> >>> >>
> >>> >> Also please take a note of the John' suggestion to use the taskqueue.
> >>> >
> >>> > I decided to go this road. Thank you both.
> >>> > Now I do nfs buildkernel survive and prepare some benchmark results.
> >>> >
> >>>
> >>> So, I modified the patch to defer proc_create() with taskqueue(9).
> >>> Below is `time make -j5 buildkernel WITHOUT_MODULES=yes` perf. 
evaluation.
> >>> Done on 4-way CPU on clean /usr/obj with /usr/src & /usr/obj both
> >>> nfs-mounted over 1Gbit LAN.
> >>>
> >>> clean old
> >>> 1137.985u 239.411s 7:42.15 298.0%   6538+2133k 87+43388io 226pf+0w
> >>>
> >>> clean new
> >>> 1134.755u 240.032s 7:41.25 298.0%   6553+2133k 87+43367io 224pf+0w
> >>>
> >>> Patch needs polishing, though it generally works.
> >>> Not sure if shep_chan (or whatever name it will get) needs locking.
> >> As I said yesterday, if several requests to create nfsiod coming one
> >> after another, you would loose all but the last.
> >>
> >> You should put the requests into the list, probably protected by
> >> nfs_iod_mtx.
> >>
> >
> > How about this patch? Still several things to ask.
> > 1) I used malloc instance w/ M_NOWAIT, since it's called with nfs_iod_mtx 
held.
> > 2) Probably busy/done gymnastics is a wrong mess. Your help is 
appreciated.
> > 3) if (1) is fine, is it right to use fail: logic (i.e. set
> > NFSIOD_NOT_AVAILABLE)
> > on memory shortage? Not tested.
> >
> > There are debug printf() left intentionally to see how 3 contexts run 
under load
> > to each other. I attached these messages as well if that makes sense.
> >
> 
> Ah, yes. Sorry, forgot about that.

Your task handler needs to run in a loop until the list of requests is empty.  
If multiple threads call taskqueue_enqueue() before your task is scheduled, 
they will be consolidated down to a single call of your task handler.

-   int error, i;
-   int newiod;
+   int i, newiod, error;

You should sort these alphabetically if you are going to change this.  I would 
probably just leave it as-is.

Also, I'm not sure how this works as you don't actually wait for the task to 
complete.  If the taskqueue_enqueue() doesn't preempt, then you may read 
ni_error as zero before the kproc has actually been created and return success 
even though an nfsiod hasn't been created.

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

Re: Removal of ICC (intel compiler) bits from mk

[Garrett Cooper]

On Wed, Aug 18, 2010 at 10:56 AM, Dimitry Andric  wrote:
> On 2010-08-18 19:37, Rui Paulo wrote:
>> I really don't know how compatible is the latest icc because no one
>> ever updated the ports version. This is actually a hint that no one
>> really uses this anymore.
>
> I recently installed the port, which has icc 8.1, but it fails to
> compile even simple C++ programs, because it cannot cope with the
> libstdc++ headers from g++ 4.2.1.
>
> You have to do all kinds of tricks, such as installing the gcc 3.4.x
> port, and pointing the Intel compiler to its libstdc++ headers and
> libraries, or nothing will work.
>
> Updating that port to icc 11.1 is probably not a trivial task, and
> making sure it compiles programs properly is even trickier... :)

Yeah... I was referring to icc 11.x because of work that my old
group was looking at doing back when I was working on Linux. Anything
older than that probably has compatibility issues :).
Thanks,
-Garrett
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: 8.1-release + zfs v15 df(1) hangs

[Andriy Gapon]

on 18/08/2010 22:07 Marian Hettwer said the following:
> I'll try and reproduce that tomorrow. I would say, a hanging nfs mount
> shouldn't lead to a hanging around df(1).

See df -n.

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

Re: LOR on nfs: vfs_vnops.c:301 kern_descrip.c:1580

[pluknet]

On 18 August 2010 23:11, pluknet  wrote:
> On 18 August 2010 17:46, Kostik Belousov  wrote:
>> On Wed, Aug 18, 2010 at 02:43:19PM +0400, pluknet wrote:
>>> On 18 August 2010 12:07, pluknet  wrote:
>>> > On 17 August 2010 20:04, Kostik Belousov  wrote:
>>> >
>>> >>
>>> >> Also please take a note of the John' suggestion to use the taskqueue.
>>> >
>>> > I decided to go this road. Thank you both.
>>> > Now I do nfs buildkernel survive and prepare some benchmark results.
>>> >
>>>
>>> So, I modified the patch to defer proc_create() with taskqueue(9).
>>> Below is `time make -j5 buildkernel WITHOUT_MODULES=yes` perf. evaluation.
>>> Done on 4-way CPU on clean /usr/obj with /usr/src & /usr/obj both
>>> nfs-mounted over 1Gbit LAN.
>>>
>>> clean old
>>> 1137.985u 239.411s 7:42.15 298.0%       6538+2133k 87+43388io 226pf+0w
>>>
>>> clean new
>>> 1134.755u 240.032s 7:41.25 298.0%       6553+2133k 87+43367io 224pf+0w
>>>
>>> Patch needs polishing, though it generally works.
>>> Not sure if shep_chan (or whatever name it will get) needs locking.
>> As I said yesterday, if several requests to create nfsiod coming one
>> after another, you would loose all but the last.
>>
>> You should put the requests into the list, probably protected by
>> nfs_iod_mtx.
>>
>
> How about this patch? Still several things to ask.
> 1) I used malloc instance w/ M_NOWAIT, since it's called with nfs_iod_mtx 
> held.
> 2) Probably busy/done gymnastics is a wrong mess. Your help is appreciated.
> 3) if (1) is fine, is it right to use fail: logic (i.e. set
> NFSIOD_NOT_AVAILABLE)
> on memory shortage? Not tested.
>
> There are debug printf() left intentionally to see how 3 contexts run under 
> load
> to each other. I attached these messages as well if that makes sense.
>

Ah, yes. Sorry, forgot about that.

This is from last run:
1139.225u 239.873s 7:44.90 296.6%   6524+2130k 77+43153io 220pf+0w

-- 
wbr,
pluknet
___
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: LOR on nfs: vfs_vnops.c:301 kern_descrip.c:1580

[pluknet]

On 18 August 2010 17:46, Kostik Belousov  wrote:
> On Wed, Aug 18, 2010 at 02:43:19PM +0400, pluknet wrote:
>> On 18 August 2010 12:07, pluknet  wrote:
>> > On 17 August 2010 20:04, Kostik Belousov  wrote:
>> >
>> >>
>> >> Also please take a note of the John' suggestion to use the taskqueue.
>> >
>> > I decided to go this road. Thank you both.
>> > Now I do nfs buildkernel survive and prepare some benchmark results.
>> >
>>
>> So, I modified the patch to defer proc_create() with taskqueue(9).
>> Below is `time make -j5 buildkernel WITHOUT_MODULES=yes` perf. evaluation.
>> Done on 4-way CPU on clean /usr/obj with /usr/src & /usr/obj both
>> nfs-mounted over 1Gbit LAN.
>>
>> clean old
>> 1137.985u 239.411s 7:42.15 298.0%       6538+2133k 87+43388io 226pf+0w
>>
>> clean new
>> 1134.755u 240.032s 7:41.25 298.0%       6553+2133k 87+43367io 224pf+0w
>>
>> Patch needs polishing, though it generally works.
>> Not sure if shep_chan (or whatever name it will get) needs locking.
> As I said yesterday, if several requests to create nfsiod coming one
> after another, you would loose all but the last.
>
> You should put the requests into the list, probably protected by
> nfs_iod_mtx.
>

How about this patch? Still several things to ask.
1) I used malloc instance w/ M_NOWAIT, since it's called with nfs_iod_mtx held.
2) Probably busy/done gymnastics is a wrong mess. Your help is appreciated.
3) if (1) is fine, is it right to use fail: logic (i.e. set
NFSIOD_NOT_AVAILABLE)
on memory shortage? Not tested.

There are debug printf() left intentionally to see how 3 contexts run under load
to each other. I attached these messages as well if that makes sense.

-- 
wbr,
pluknet


dmesg.out
Description: Binary data
Index: sys/nfsclient/nfs_subs.c
===
--- sys/nfsclient/nfs_subs.c	(revision 211279)
+++ sys/nfsclient/nfs_subs.c	(working copy)
@@ -59,6 +59,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #include 
 #include 
@@ -117,6 +118,7 @@
 
 struct nfs_bufq	nfs_bufq;
 static struct mtx nfs_xid_mtx;
+struct task	nfs_nfsiodnew_task;
 
 /*
  * and the reverse mapping from generic to Version 2 procedure numbers
@@ -354,6 +356,7 @@
 	 */
 	mtx_init(&nfs_iod_mtx, "NFS iod lock", NULL, MTX_DEF);
 	mtx_init(&nfs_xid_mtx, "NFS xid lock", NULL, MTX_DEF);
+	TASK_INIT(&nfs_nfsiodnew_task, 0, nfs_nfsiodnew_tq, NULL);
 
 	nfs_pbuf_freecnt = nswbuf / 2 + 1;
 
Index: sys/nfsclient/nfs_nfsiod.c
===
--- sys/nfsclient/nfs_nfsiod.c	(revision 211279)
+++ sys/nfsclient/nfs_nfsiod.c	(working copy)
@@ -59,6 +59,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #include 
 #include 
@@ -75,6 +76,17 @@
 
 static void	nfssvc_iod(void *);
 
+struct nfsiod_str {
+	SLIST_ENTRY(nfsiod_str) ni_list;
+	int *ni_inst;
+	int ni_iod;
+	int ni_error;
+	int ni_busy;
+	int ni_done;
+};
+static SLIST_HEAD(, nfsiod_str) nfsiodhead =
+SLIST_HEAD_INITIALIZER(nfsiodhead);
+
 static int nfs_asyncdaemon[NFS_MAXASYNCDAEMON];
 
 SYSCTL_DECL(_vfs_nfs);
@@ -159,11 +171,34 @@
 sizeof (nfs_iodmax), sysctl_iodmax, "IU",
 "Max number of nfsiod kthreads");
 
+void
+nfs_nfsiodnew_tq(__unused void *arg, int pending)
+{
+	struct nfsiod_str *nip;
+
+	mtx_lock(&nfs_iod_mtx);
+	SLIST_FOREACH(nip, &nfsiodhead, ni_list) {
+		printf("tq: SLIST nip: %p\n", nip);
+		if (nip->ni_busy == 0) {
+			nip->ni_busy = 1;
+			break;
+		}
+	}
+	mtx_unlock(&nfs_iod_mtx);
+	KASSERT(nip != NULL, ("nfs_nfsiodnew_tq: nip is NULL"));
+	printf("tq: nip: %p\n", nip);
+	printf("tq: ni_inst: %p\n", nip->ni_inst);
+	printf("tq: ni_iod: %d\n", nip->ni_iod);
+	nip->ni_error = kproc_create(nfssvc_iod, nip->ni_inst, NULL,
+	RFHIGHPID, 0, "nfsiod %d", nip->ni_iod);
+	nip->ni_done = 1;
+}
+
 int
 nfs_nfsiodnew(int set_iodwant)
 {
-	int error, i;
-	int newiod;
+	int i, newiod, error;
+	struct nfsiod_str *nip, *nip_temp;
 
 	if (nfs_numasync >= nfs_iodmax)
 		return (-1);
@@ -178,17 +213,34 @@
 		return (-1);
 	if (set_iodwant > 0)
 		nfs_iodwant[i] = NFSIOD_CREATED_FOR_NFS_ASYNCIO;
+	nip = malloc(sizeof(*nip), M_TEMP, M_NOWAIT | M_ZERO);
+	if (nip == NULL)
+		goto fail;
+	nip->ni_inst = nfs_asyncdaemon + i;
+	nip->ni_iod = newiod;
+	SLIST_INSERT_HEAD(&nfsiodhead, nip, ni_list);
 	mtx_unlock(&nfs_iod_mtx);
-	error = kproc_create(nfssvc_iod, nfs_asyncdaemon + i, NULL, RFHIGHPID,
-	0, "nfsiod %d", newiod);
+	printf("new: nip: %p\n", nip);
+	printf("new: ni_inst: %p\n", nip->ni_inst);
+	printf("new: ni_iod: %d\n", nip->ni_iod);
+	taskqueue_enqueue(taskqueue_thread, &nfs_nfsiodnew_task);
 	mtx_lock(&nfs_iod_mtx);
-	if (error) {
-		if (set_iodwant > 0)
-			nfs_iodwant[i] = NFSIOD_NOT_AVAILABLE;
-		return (-1);
+	error = nip->ni_error;
+	SLIST_FOREACH_SAFE(nip, &nfsiodhead, ni_list, nip_temp) {
+		if (nip->ni_busy != 0 && nip->ni_done != 0) {
+			SLIST_REMOVE(&nfsiodhead, nip, nfsiod_str, ni_list);
+			free(nip, M_TEMP);
+			break;
+		}
 	}
+	if (error)
+		goto fail;
 	nfs_numasyn

Re: 8.1-release + zfs v15 df(1) hangs

[Marian Hettwer]

 Hej there,

Am 18.08.10 17:18, schrieb Andriy Gapon:

on 18/08/2010 11:23 Marian Hettwer said the following:

  Hi All,

i installed freebsd 8.1-release on my workstation (based on the
8.1-release mfsbsd isos) and I'm now experiencing some strange effects.

A df(1) doesn't return and is not killable and while taking a look
around in my process table, I could find several find's hanging around too.

mhettwer  5976  0.0  0.0  6896  1088  13  D+5:55PM   0:00.00 df -h
mhettwer  5351  0.0  0.0  6896  1088  19  D+1:49PM   0:00.00 df -h

Can you run procstat -k to see where exactly the processes are stuck?

for some reason, the stuck df and find processes are gone. And since df 
works again, I could see a nfs mount which I guessed caused the issue.


Hm, so best guess, a hanging nfs mount is not good. I remember I mounted 
it without any special options. just "mount ip:/export /mnt" and 
probably forgot about it.


I'll try and reproduce that tomorrow. I would say, a hanging nfs mount 
shouldn't lead to a hanging around df(1).


all the best,
Marian
___
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

[Wilko Bulte]

Op 18 aug. 2010 om 18:48 heeft Gabor Kovesdan  het volgende 
geschreven:

> Em 2010.08.13. 10:43, Doug Barton escreveu:
>> -BEGIN PGP SIGNED MESSAGE-
>> Hash: SHA256
>> 
>> Gabor,
>> 
>> I hope at this point it goes without saying that I have a lot of respect
>> for the work you've done on BSD grep, and I've already told you that I
>> think you're very courageous for taking the project on. I've been
>> testing and evaluating it for some time now, and I think I've given it a
>> fair trial. You've done a fairly good job of responding to bug reports,
>> and I understand that the exposure BSD grep has received as the default
>> in HEAD has been very valuable in exposing additional areas that need
>> work. However, with all that in mind I am officially asking you to
>> please change the default in HEAD to GNU grep. (Note, I am _not_ asking
>> you to remove BSD grep from the tree, just to change the default.)
>> 
>> My reason is simple, performance. [...]
> 
> I've just committed a patch with the kind help of Dimitry Andric, which gives 
> BSD grep a huge performance boost. The performance is now almost comparable 
> to GNU grep. I think with this, BSD grep may remain default if no other 
> serious issues come up. Please report if you notice something weird.
> 
> I know about some minor issues, which aren't fixed yet. I'll be out for 4 
> days as of tomorrow but when I come back I'll take care of these:
> - Infinite loop when reading directory on ZFS/NFS filesystem
> - Problems with context grepping
> 
> When reply, please remove core@ from CC, let's not bother them with this, I 
> just wanted to let them know that I'm not neglecting this issue but if still 
> demanded for a good reason,

No worries there Gabor!

Wilko

> I'll switch back to default GNU grep.
> 
> Gabor
> 
> 
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: Official request: Please make GNU grep the default

[M. Warner Losh]

In message: <4c6c1cfe.6060...@freebsd.org>
Gabor Kovesdan  writes:
: When reply, please remove core@ from CC, let's not bother them with
: this, I just wanted to let them know that I'm not neglecting this
: issue but if still demanded for a good reason, I'll switch back to
: default GNU grep.

So making it default turned out well in the end.  Sure, there was pain
involved (but this is current), but making it default exposed the pain
that would otherwise have gone unnoticed.  The big hue and cry, while
excessive at times, did result in people actually running the
profiling tools which pointed to the buffering as the number one thing
to fix.  That being fixed now, it looks like we can go to the next
stage: benchmarking again.

Thanks, Gabor and everybody else that contributed, for seeing this
through.

Warner
___
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: Removal of ICC (intel compiler) bits from mk

[Dimitry Andric]

On 2010-08-18 19:37, Rui Paulo wrote:
> I really don't know how compatible is the latest icc because no one
> ever updated the ports version. This is actually a hint that no one
> really uses this anymore.

I recently installed the port, which has icc 8.1, but it fails to
compile even simple C++ programs, because it cannot cope with the
libstdc++ headers from g++ 4.2.1.

You have to do all kinds of tricks, such as installing the gcc 3.4.x
port, and pointing the Intel compiler to its libstdc++ headers and
libraries, or nothing will work.

Updating that port to icc 11.1 is probably not a trivial task, and
making sure it compiles programs properly is even trickier... :)
___
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: Removal of ICC (intel compiler) bits from mk

[Gabor Kovesdan]

 Em 2010.08.18. 19:37, Rui Paulo escreveu:

On 18 Aug 2010, at 18:18, Garrett Cooper wrote:


On Wed, Aug 18, 2010 at 9:23 AM, Rui Paulo  wrote:

Hi,
I've been chatting with the ICC ex-users and they seem to be ok with the 
removal of the ICC bits from share/mk and other places.
The reason is that it doesn't work and no one has volunteered to fix it for 
many years. This seems to indicate that the interest in ICC is low.
If there's anyone against this, speak now or forever be silent. :-)

Later versions of icc are more gcc compliant aren't they? If so,
wouldn't this also be a non-issue to remove the bits, or are there
still some incompatibilities between gcc and icc that are worth
noting?

I really don't know how compatible is the latest icc because no one ever 
updated the ports version. This is actually a hint that no one really uses this 
anymore.
IIRC, apart from the low interest, the problem was that because of ICC's 
license using ICC to test this mk stuff requires a commercial license 
because somehow it is considered a derivative work. It has also 
prevented us from providing better support. In 2006, I wanted to do some 
progress as part of my SoC project because that time there was more 
interest. Alexander (CC'd) may comment on this. I think he has a license 
for FreeBSD work but he is not allowed to give it out to a third party.


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

Re: Official request: Please make GNU grep the default

[Gabor Kovesdan]

 Em 2010.08.13. 10:43, Doug Barton escreveu:

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Gabor,

I hope at this point it goes without saying that I have a lot of respect
for the work you've done on BSD grep, and I've already told you that I
think you're very courageous for taking the project on. I've been
testing and evaluating it for some time now, and I think I've given it a
fair trial. You've done a fairly good job of responding to bug reports,
and I understand that the exposure BSD grep has received as the default
in HEAD has been very valuable in exposing additional areas that need
work. However, with all that in mind I am officially asking you to
please change the default in HEAD to GNU grep. (Note, I am _not_ asking
you to remove BSD grep from the tree, just to change the default.)

My reason is simple, performance. [...]


I've just committed a patch with the kind help of Dimitry Andric, which 
gives BSD grep a huge performance boost. The performance is now almost 
comparable to GNU grep. I think with this, BSD grep may remain default 
if no other serious issues come up. Please report if you notice 
something weird.


I know about some minor issues, which aren't fixed yet. I'll be out for 
4 days as of tomorrow but when I come back I'll take care of these:

- Infinite loop when reading directory on ZFS/NFS filesystem
- Problems with context grepping

When reply, please remove core@ from CC, let's not bother them with 
this, I just wanted to let them know that I'm not neglecting this issue 
but if still demanded for a good reason, I'll switch back to default GNU 
grep.


Gabor


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

Re: Removal of ICC (intel compiler) bits from mk

[Garrett Cooper]

On Wed, Aug 18, 2010 at 10:18 AM, Garrett Cooper  wrote:
> On Wed, Aug 18, 2010 at 9:23 AM, Rui Paulo  wrote:
>> Hi,
>> I've been chatting with the ICC ex-users and they seem to be ok with the 
>> removal of the ICC bits from share/mk and other places.
>> The reason is that it doesn't work and no one has volunteered to fix it for 
>> many years. This seems to indicate that the interest in ICC is low.
>> If there's anyone against this, speak now or forever be silent. :-)
>
>    Later versions of icc are more gcc compliant aren't they? If so,

Sorry -- wrong term. s/compliant/compatible/ :).

> wouldn't this also be a non-issue to remove the bits, or are there
> still some incompatibilities between gcc and icc that are worth
> noting?
> Thanks,
> -Garrett
>
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: Removal of ICC (intel compiler) bits from mk

[Garrett Cooper]

On Wed, Aug 18, 2010 at 9:23 AM, Rui Paulo  wrote:
> Hi,
> I've been chatting with the ICC ex-users and they seem to be ok with the 
> removal of the ICC bits from share/mk and other places.
> The reason is that it doesn't work and no one has volunteered to fix it for 
> many years. This seems to indicate that the interest in ICC is low.
> If there's anyone against this, speak now or forever be silent. :-)

Later versions of icc are more gcc compliant aren't they? If so,
wouldn't this also be a non-issue to remove the bits, or are there
still some incompatibilities between gcc and icc that are worth
noting?
Thanks,
-Garrett
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: Removal of ICC (intel compiler) bits from mk

[Rui Paulo]

On 18 Aug 2010, at 18:18, Garrett Cooper wrote:

> On Wed, Aug 18, 2010 at 9:23 AM, Rui Paulo  wrote:
>> Hi,
>> I've been chatting with the ICC ex-users and they seem to be ok with the 
>> removal of the ICC bits from share/mk and other places.
>> The reason is that it doesn't work and no one has volunteered to fix it for 
>> many years. This seems to indicate that the interest in ICC is low.
>> If there's anyone against this, speak now or forever be silent. :-)
> 
>Later versions of icc are more gcc compliant aren't they? If so,
> wouldn't this also be a non-issue to remove the bits, or are there
> still some incompatibilities between gcc and icc that are worth
> noting?

I really don't know how compatible is the latest icc because no one ever 
updated the ports version. This is actually a hint that no one really uses this 
anymore.

Regards,
--
Rui Paulo


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

Removal of ICC (intel compiler) bits from mk

[Rui Paulo]

Hi,
I've been chatting with the ICC ex-users and they seem to be ok with the 
removal of the ICC bits from share/mk and other places. 
The reason is that it doesn't work and no one has volunteered to fix it for 
many years. This seems to indicate that the interest in ICC is low. 
If there's anyone against this, speak now or forever be silent. :-)

--
Rui Paulo___
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

[Andrew Milton]

+---[ Luigi Rizzo ]--
| On Wed, Aug 18, 2010 at 11:43:41PM +1000, Andrew Reilly wrote:
| > On Sun, Aug 15, 2010 at 11:15:55PM -0700, Doug Barton wrote:
| > > got any other suggestions?
| > 
| > This is very much a "sorry I asked" question, but is none-the
| > less quite a good one, given the size of the hole to be plugged.
| > 
| > I think that a reasonable answer for this sort of thing might be
| > one of the dynamic languages that compiles to C, like (perhaps)
| > one of the schemes (chicken, gambit-C, bigloo, etc).  You get
| > the benefit of flexibility and dynamism with good regexp and
| > data structure ability, good performance, and only requiring the
| > build tools available in the base system, as long as you don't
| > want to be the developer: just ship the C code (as well as the
| > source, of course).
| 
| slightly off topic but I disagree  on the latter part.
| 
| The whole point of having source code is to be able to make
| modifications, small or large, private or ones to be contributed
| back. As a teacher, i am very concerned about the ease-of-use for
| non-developer types: it is important to make it easy for people to
| experiments, as this is one of the ways people learn things.

I have to agree with Luigi. You have to work out your target audience,
and that should be your first constraint to choosing the language.

If the language has a syntax structure that's going to be hard to parse
by non-developers at first glance (like forth or perl), then you're really
limiting the userbase.

C is scriptable and embeddable these days from a variety of projects,
but, I wouldn't recommend that either necessarily (since C doesn't
have dynamic typing), even if we could get 100% architecture coverage.

-- 
Andrew Milton
a...@theinternet.com.au
___
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: CFR: Replace man/manpath/whatis/apropos with a shell script

[Alexander Best]

On Wed Aug 18 10, Gordon Tetlow wrote:
> All,
> 
> I sat down and rewrote the man tools from a relatively old codebase to a
> single shell script. My original motivation was to allow multiple
> configuration files so port installations did not have to mess with
> /etc/manpath.config (like perl for example) when needing to manipulate the
> manpath. After looking at the existing code, I figured I could rewrite it as
> a shell script relatively easily.
> 
> Script (install as /usr/bin/man, /usr/bin/manpath, /usr/bin/apropos,
> /usr/bin/whatis)
> http://people.freebsd.org/~gordon/man.sh

wow! that's great. thanks a lot. :)

could you have a look at gnu/4419? although your script seems to fix this issue
partially, when *.[0-9] and *[0-9].gz manuals exist it will choose the
uncompressed file and complain with "not in gzip format".

it would be nice if your script would prefer compressed over uncompressed
manuals.

however i'm not sure if a different approach might be better. people with more
in depth knowledge might want to comment on this.

cheers.
alex

> 
> Features of the new code:
> 
> 1. BSD licensed (old code is GPL).
> 2. Imports configuration from /usr/local/etc/man.d/*.conf and /etc/man.conf
> (purposefully changed the manpath.config file since it is a different
> syntax).
> 3. Allows ports to override the toolset used to display the manpage based on
> language. This was done to try to merge the functionality of the
> japanese/man port into the base system as much as possible.
> 
> I've tried to make this mirror the functionality, directory search order,
> and arguments as the current base implementation.
> 
> This brings me to my next point. I need some testers willing to try this
> out. It would be particularly great if I could get some foreign language
> testers with localized manpage installations. If something doesn't work the
> way you expect, please contact me and I can help debug it (using man -ddd
>  will generally give me the debug information I need).
> 
> Thanks,
> Gordon

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

Re: ZFS will gone,FreeBSD will import btrfs?

[Artem Belevich]

> So all we need to direct some of the money we already spend for
> supporting developers and certain developments to core ZFS developers no
> longer employed by Sun/Oracle and that way make FreeBSD the primary ZFS
> development platform for the future. If you have the key developers, the
> community will follow.
>

I'd argue that we'll need pjd@ more than ever.

I don't think that ex-OpenSolaris contributors are going to jump to
FreeBSD. There's project Illumos which is essentially an OpenSolaris
fork minus binary-only bits. My guess is that it's got a decent chance
to become a viable OpenSolaris replacement. Interestingly enough,
Illumos plans to import FreeBSD drivers (and some utils) to replace
closed-source ones that used to come from Solaris.

--Artem



On Wed, Aug 18, 2010 at 5:54 AM, Oliver Brandmueller  wrote:
> Hi,
>
> On Tue, Aug 17, 2010 at 09:47:00AM -0700, Xin LI wrote:
>> It's not "gone" since Oracle can not withdraw code that is already
>> licensed under CDDL.  They _may_ choose not to release anything new but
>> we already have a newer zfs version that have basic functionality usable
>> in p4.
>
> So all we need to direct some of the money we already spend for
> supporting developers and certain developments to core ZFS developers no
> longer employed by Sun/Oracle and that way make FreeBSD the primary ZFS
> development platform for the future. If you have the key developers, the
> community will follow.
>
> Before someone starts argueing... I know, it's not that easy and I don't
> have a clue how one would do that. This is most probably more like a
> crazy idea than a plan that could actually work :-/
>
> - Oliver
>
> --
> | Oliver Brandmueller          http://sysadm.in/         o...@sysadm.in |
> |                        Ich bin das Internet. Sowahr ich Gott helfe. |
>
___
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: STABLE kernel panic: privileged instruction fault

[Andriy Gapon]

on 13/08/2010 00:45 Alexey Tarasov said the following:
> Fatal trap 1: privileged instruction fault while in kernel mode
> cpuid = 1; apic id = 01
> instruction pointer = 0x20:0xff8040d2cc83
> stack pointer   = 0x28:0xff8040d2ca80
> frame pointer   = 0x28:0xff0060c0b740

I suspect that either stack is corrupted or non-code is executed (or both).
Stack pointer seems to be too close to instruction pointer and too far from 
frame
pointer.

Can you try to use kgdb and disassemble code (or examine data) near instruction
pointer address and also near frame pointer address?
Also, you might want to rebuild kgdb with a recent change from head, so that it
better maps symbols and addresses in kernel modules.

> code segment= base 0x0, limit 0xf, type 0x1b
> = DPL 0, pres 1, long 1, def32 0, gran 1
> processor eflags= interrupt enabled, resume, IOPL = 0
> current process = 9388 (nginx)
> trap number = 1
> panic: privileged instruction fault
> cpuid = 1
> Uptime: 17d15h48m49s
> Physical memory: 2032 MB
> Dumping 1485 MB: 1470 1454 1438 1422 1406 1390 1374 1358 1342 1326 1310 1294 
> 1278 1262 1246 1230 1214 1198 1182 1166 1150 1134 1118 1102 1086 1070 1054 
> 1038 1022 1006 990 974 958 942 926 910 894 878 862 846 830 814 798 782 766 
> 750 734 718 702 686 670 654 638 622 606 590 574 558 542 526 510 494 478 462 
> 446 430 414 398 382 366 350 334 318 302 286 270 254 238 222 206 190 174 158 
> 142 126 110 94 78 62 46 30 14
> 
> 
> (kgdb) #0  doadump () at pcpu.h:223
> #1  0x80590c59 in boot (howto=260)
> at /usr/src/sys/kern/kern_shutdown.c:416
> #2  0x8059108c in panic (fmt=0x80951fc4 "%s")
> at /usr/src/sys/kern/kern_shutdown.c:579
> #3  0x80878fd8 in trap_fatal (frame=0xff0060c0b740, eva=Variable 
> "eva" is not available.
> )
> at /usr/src/sys/amd64/amd64/trap.c:857
> #4  0x808799ea in trap (frame=0xff8040d2c9d0)
> at /usr/src/sys/amd64/amd64/trap.c:644
> #5  0x8085f983 in calltrap ()
> at /usr/src/sys/amd64/amd64/exception.S:224
> #6  0xff8040d2cc83 in ?? ()
> #7  0xff8040d2cb50 in ?? ()
> #8  0xff8040d2caf0 in ?? ()
> #9  0xff8040d2cbf0 in ?? ()
> #10 0xff0060c0b740 in ?? ()
> #11 0x80b83c60 in sysent ()
> #12 0xff8040d2cc80 in ?? ()
> #13 0xff8040d2cae0 in ?? ()
> #14 0x8059c431 in bintime (bt=0x80ad3140)
> at /usr/src/sys/kern/kern_tc.c:200
> Previous frame inner to this frame (corrupt stack?)
> (kgdb) 



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

CFR: importing openresolv

[Hajimu UMEMOTO]

Hi,

I wish to import openresolv 3.3.5 into our base tree.  It makes
merging the DNS server addresses informed from DHCP, DHCPv6, PPP, ...
into /etc/resolv.conf easier.

http://roy.marples.name/projects/openresolv

My patch against 9-CURRENT can be obtained from:

http://www.imasy.or.jp/~ume/FreeBSD/openresolv-20100818.diff.gz

Sincerely,

--
Hajimu UMEMOTO @ Internet Mutual Aid Society Yokohama, Japan
u...@mahoroba.org  u...@{,jp.}FreeBSD.org
http://www.imasy.org/~ume/
___
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: Mounting cd9660 multiple times gives EBUSY [Was: unionfs a little improvement]

[Ed Schouten]

* Pawel Jakub Dawidek  wrote:
> What you are trying to do here is to mount /dev/iso9660/freebsd for the
> second time? This is not supported. The check is there to prevent doing
> this, as it will panic on you when you try to unmount first mount (not
> really a problem in your case, as the first mount is /, so you probably
> don't want to unmount it, but it is a problem in general).
> 
> You should be able to reproduce the panic with your patch applied by
> doing the following:
> 
>   # mount -t cd9660 /dev/iso9660/freebsd /mnt0
>   # mount -t cd9660 /dev/iso9660/freebsd /mnt1
>   # umount /mnt0

Ah, I see. Well, I changed my setup to use an md root now. Works quite
nicely. Screenshot:

http://80386.nl/pub/livecd.png

Thanks for the explanation!

-- 
 Ed Schouten 
 WWW: http://80386.nl/


pgps9FfC06S09.pgp
Description: PGP signature

Re: 8.1-release + zfs v15 df(1) hangs

[Andriy Gapon]

on 18/08/2010 11:23 Marian Hettwer said the following:
>  Hi All,
> 
> i installed freebsd 8.1-release on my workstation (based on the
> 8.1-release mfsbsd isos) and I'm now experiencing some strange effects.
> 
> A df(1) doesn't return and is not killable and while taking a look
> around in my process table, I could find several find's hanging around too.
> 
> mhettwer  5976  0.0  0.0  6896  1088  13  D+5:55PM   0:00.00 df -h
> mhettwer  5351  0.0  0.0  6896  1088  19  D+1:49PM   0:00.00 df -h

Can you run procstat -k to see where exactly the processes are stuck?

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

Re: Interpreted language(s) in the base

[Luigi Rizzo]

On Wed, Aug 18, 2010 at 11:43:41PM +1000, Andrew Reilly wrote:
> On Sun, Aug 15, 2010 at 11:15:55PM -0700, Doug Barton wrote:
> > got any other suggestions?
> 
> This is very much a "sorry I asked" question, but is none-the
> less quite a good one, given the size of the hole to be plugged.
> 
> I think that a reasonable answer for this sort of thing might be
> one of the dynamic languages that compiles to C, like (perhaps)
> one of the schemes (chicken, gambit-C, bigloo, etc).  You get
> the benefit of flexibility and dynamism with good regexp and
> data structure ability, good performance, and only requiring the
> build tools available in the base system, as long as you don't
> want to be the developer: just ship the C code (as well as the
> source, of course).

slightly off topic but I disagree  on the latter part.

The whole point of having source code is to be able to make
modifications, small or large, private or ones to be contributed
back. As a teacher, i am very concerned about the ease-of-use for
non-developer types: it is important to make it easy for people to
experiments, as this is one of the ways people learn things.

Having sources in some fantastic new language 'fuffa' and no 'fuffa2c'
tool is almost as bad as having no source (in fact, it is like the
joke of supplying source for the GPL'd software in your brand new
LCD tv or appliance. I'd like to know who will ever be able to build
an updated image and upload it to the appliance)

cheers
luigi
___
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: LOR on nfs: vfs_vnops.c:301 kern_descrip.c:1580

[Kostik Belousov]

On Wed, Aug 18, 2010 at 02:43:19PM +0400, pluknet wrote:
> On 18 August 2010 12:07, pluknet  wrote:
> > On 17 August 2010 20:04, Kostik Belousov  wrote:
> >
> >>
> >> Also please take a note of the John' suggestion to use the taskqueue.
> >
> > I decided to go this road. Thank you both.
> > Now I do nfs buildkernel survive and prepare some benchmark results.
> >
> 
> So, I modified the patch to defer proc_create() with taskqueue(9).
> Below is `time make -j5 buildkernel WITHOUT_MODULES=yes` perf. evaluation.
> Done on 4-way CPU on clean /usr/obj with /usr/src & /usr/obj both
> nfs-mounted over 1Gbit LAN.
> 
> clean old
> 1137.985u 239.411s 7:42.15 298.0%   6538+2133k 87+43388io 226pf+0w
> 
> clean new
> 1134.755u 240.032s 7:41.25 298.0%   6553+2133k 87+43367io 224pf+0w
> 
> Patch needs polishing, though it generally works.
> Not sure if shep_chan (or whatever name it will get) needs locking.
As I said yesterday, if several requests to create nfsiod coming one
after another, you would loose all but the last.

You should put the requests into the list, probably protected by
nfs_iod_mtx.


pgp3biVEZldik.pgp
Description: PGP signature

Re: Interpreted language(s) in the base

[Andrew Reilly]

On Sun, Aug 15, 2010 at 11:15:55PM -0700, Doug Barton wrote:
> got any other suggestions?

This is very much a "sorry I asked" question, but is none-the
less quite a good one, given the size of the hole to be plugged.

I think that a reasonable answer for this sort of thing might be
one of the dynamic languages that compiles to C, like (perhaps)
one of the schemes (chicken, gambit-C, bigloo, etc).  You get
the benefit of flexibility and dynamism with good regexp and
data structure ability, good performance, and only requiring the
build tools available in the base system, as long as you don't
want to be the developer: just ship the C code (as well as the
source, of course).

Unfortunately it seems that quite a lot of people have issues
with lisp syntax these days.

There are some other compile-to-C languages that might work too.

[Aside: I think that the answer to this question might get a
*lot* more interesting once we have llvm in the base system (it
comes along with clang).  There are (and I'm sure will be
more) languages that compile down to llvm byte-code without the
contortions required in going through C.]

Cheers,

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

Re: bsdgrep does not work with tail -f | grep combination

[Gabor Kovesdan]

 Em 2010.08.18. 7:42, poyop...@puripuri.plala.or.jp escreveu:

Hi Gabor and others,

As Gabor committed r211364, bsdgrep now works nicely with tail -f.

http://svn.freebsd.org/changeset/base/211364

Thank you very much.
Acknowledgements also go to you and other users. Without quality 
feedback I may not have found myself all reported bugs.


Gabor

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

Re: Building world with clang

[Dag-Erling Smørgrav]

Dimitry Andric  writes:
> Dag-Erling Smørgrav  writes:
> > No, what is used is a variant of method 1 *on top of* method 2 for a
> > very specific case.  You need "a special version of clang" (method 2)
> > anyway to support cross-building.
> Eventually, clang should support building objects for all targets from
> one executable, but not in the short term, unfortunately...

That doesn't matter.  You still need two versions of the compiler.  If
you're cross-building sprac64 on an i386 machine, for instance, you need
an i386 version of the compiler that produces sparc64 binaries *and* a
sparc64 version that produces sparc64 binaries.  The former is used only
during the build, the latter is what will be installed on the target.

DES
-- 
Dag-Erling Smørgrav - d...@des.no
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: Building world with clang

[Dimitry Andric]

On 2010-08-18 11:15, Dag-Erling Smørgrav wrote:
> I'm not a big fan of "reasonable chances" when it comes to the
> toolchain.

Me neither, which is why I created method 2 originally. :)  The
-isysroot method was invented by Roman Divacky in r198248.


> No, what is used is a variant of method 1 *on top of* method 2 for a
> very specific case.  You need "a special version of clang" (method 2)
> anyway to support cross-building.

Eventually, clang should support building objects for all targets from
one executable, but not in the short term, unfortunately...

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

Re: ZFS will gone,FreeBSD will import btrfs?

[Oliver Brandmueller]

Hi,

On Tue, Aug 17, 2010 at 09:47:00AM -0700, Xin LI wrote:
> It's not "gone" since Oracle can not withdraw code that is already
> licensed under CDDL.  They _may_ choose not to release anything new but
> we already have a newer zfs version that have basic functionality usable
> in p4.

So all we need to direct some of the money we already spend for 
supporting developers and certain developments to core ZFS developers no 
longer employed by Sun/Oracle and that way make FreeBSD the primary ZFS 
development platform for the future. If you have the key developers, the 
community will follow.

Before someone starts argueing... I know, it's not that easy and I don't 
have a clue how one would do that. This is most probably more like a 
crazy idea than a plan that could actually work :-/

- Oliver

-- 
| Oliver Brandmueller  http://sysadm.in/ o...@sysadm.in |
|Ich bin das Internet. Sowahr ich Gott helfe. |


pgpyMYQpaY2XO.pgp
Description: PGP signature

[head tinderbox] failure on powerpc64/powerpc

[FreeBSD Tinderbox]

TB --- 2010-08-18 09:18:34 - tinderbox 2.6 running on freebsd-current.sentex.ca
TB --- 2010-08-18 09:18:34 - starting HEAD tinderbox run for powerpc64/powerpc
TB --- 2010-08-18 09:18:34 - mkdir /tinderbox/HEAD/powerpc64
TB --- 2010-08-18 09:18:34 - mkdir /tinderbox/HEAD/powerpc64/powerpc
TB --- 2010-08-18 09:18:34 - cleaning the object tree
TB --- 2010-08-18 09:18:34 - cvsupping the source tree
TB --- 2010-08-18 09:18:34 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca 
/tinderbox/HEAD/powerpc64/powerpc/supfile
TB --- 2010-08-18 09:38:05 - building world
TB --- 2010-08-18 09:38:05 - MAKEOBJDIRPREFIX=/obj
TB --- 2010-08-18 09:38:05 - PATH=/usr/bin:/usr/sbin:/bin:/sbin
TB --- 2010-08-18 09:38:05 - TARGET=powerpc
TB --- 2010-08-18 09:38:05 - TARGET_ARCH=powerpc64
TB --- 2010-08-18 09:38:05 - TZ=UTC
TB --- 2010-08-18 09:38:05 - __MAKE_CONF=/dev/null
TB --- 2010-08-18 09:38:05 - cd /src
TB --- 2010-08-18 09:38:05 - /usr/bin/make -B buildworld
>>> World build started on Wed Aug 18 09:38:06 UTC 2010
>>> Rebuilding the temporary build tree
>>> stage 1.1: legacy release compatibility shims
>>> stage 1.2: bootstrap tools
>>> stage 2.1: cleaning up the object tree
>>> stage 2.2: rebuilding the object tree
>>> stage 2.3: build tools
>>> stage 3: cross tools
>>> stage 4.1: building includes
>>> stage 4.2: building libraries
>>> stage 4.3: make dependencies
>>> stage 4.4: building everything
>>> stage 5.1: building 32 bit shim libraries
>>> World build completed on Wed Aug 18 11:18:07 UTC 2010
TB --- 2010-08-18 11:18:07 - generating LINT kernel config
TB --- 2010-08-18 11:18:07 - cd /src/sys/powerpc/conf
TB --- 2010-08-18 11:18:07 - /usr/bin/make -B LINT
TB --- 2010-08-18 11:18:07 - building LINT kernel
TB --- 2010-08-18 11:18:07 - MAKEOBJDIRPREFIX=/obj
TB --- 2010-08-18 11:18:07 - PATH=/usr/bin:/usr/sbin:/bin:/sbin
TB --- 2010-08-18 11:18:07 - TARGET=powerpc
TB --- 2010-08-18 11:18:07 - TARGET_ARCH=powerpc64
TB --- 2010-08-18 11:18:07 - TZ=UTC
TB --- 2010-08-18 11:18:07 - __MAKE_CONF=/dev/null
TB --- 2010-08-18 11:18:07 - cd /src
TB --- 2010-08-18 11:18:07 - /usr/bin/make -B buildkernel KERNCONF=LINT
>>> Kernel build for LINT started on Wed Aug 18 11:18:07 UTC 2010
>>> stage 1: configuring the kernel
>>> stage 2.1: cleaning up the object tree
>>> stage 2.2: rebuilding the object tree
>>> stage 2.3: build tools
>>> stage 3.1: making dependencies
>>> stage 3.2: building the kernel
[...]
/src/sys/dev/ofw/ofw_standard.c:705: warning: cast to pointer from integer of 
different size
/src/sys/dev/ofw/ofw_standard.c: In function 'ofw_std_release':
/src/sys/dev/ofw/ofw_standard.c:719: warning: cast from pointer to integer of 
different size
/src/sys/dev/ofw/ofw_standard.c:724: warning: cast from pointer to integer of 
different size
/src/sys/dev/ofw/ofw_standard.c: In function 'ofw_std_enter':
/src/sys/dev/ofw/ofw_standard.c:742: warning: cast from pointer to integer of 
different size
/src/sys/dev/ofw/ofw_standard.c: In function 'ofw_std_exit':
/src/sys/dev/ofw/ofw_standard.c:760: warning: cast from pointer to integer of 
different size
*** Error code 1

Stop in /obj/powerpc.powerpc64/src/sys/LINT.
*** Error code 1

Stop in /src.
*** Error code 1

Stop in /src.
TB --- 2010-08-18 11:31:17 - WARNING: /usr/bin/make returned exit code  1 
TB --- 2010-08-18 11:31:17 - ERROR: failed to build lint kernel
TB --- 2010-08-18 11:31:17 - 4864.50 user 1282.72 system 7963.35 real


http://tinderbox.freebsd.org/tinderbox-head-HEAD-powerpc64-powerpc.full
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

CFR: Replace man/manpath/whatis/apropos with a shell script

[Gordon Tetlow]

All,

I sat down and rewrote the man tools from a relatively old codebase to a
single shell script. My original motivation was to allow multiple
configuration files so port installations did not have to mess with
/etc/manpath.config (like perl for example) when needing to manipulate the
manpath. After looking at the existing code, I figured I could rewrite it as
a shell script relatively easily.

Script (install as /usr/bin/man, /usr/bin/manpath, /usr/bin/apropos,
/usr/bin/whatis)
http://people.freebsd.org/~gordon/man.sh

Features of the new code:

1. BSD licensed (old code is GPL).
2. Imports configuration from /usr/local/etc/man.d/*.conf and /etc/man.conf
(purposefully changed the manpath.config file since it is a different
syntax).
3. Allows ports to override the toolset used to display the manpage based on
language. This was done to try to merge the functionality of the
japanese/man port into the base system as much as possible.

I've tried to make this mirror the functionality, directory search order,
and arguments as the current base implementation.

This brings me to my next point. I need some testers willing to try this
out. It would be particularly great if I could get some foreign language
testers with localized manpage installations. If something doesn't work the
way you expect, please contact me and I can help debug it (using man -ddd
 will generally give me the debug information I need).

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

[head tinderbox] failure on sparc64/sun4v

[FreeBSD Tinderbox]

TB --- 2010-08-18 09:47:11 - tinderbox 2.6 running on freebsd-current.sentex.ca
TB --- 2010-08-18 09:47:11 - starting HEAD tinderbox run for sparc64/sun4v
TB --- 2010-08-18 09:47:11 - cleaning the object tree
TB --- 2010-08-18 09:47:41 - cvsupping the source tree
TB --- 2010-08-18 09:47:41 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca 
/tinderbox/HEAD/sparc64/sun4v/supfile
TB --- 2010-08-18 09:50:08 - building world
TB --- 2010-08-18 09:50:08 - MAKEOBJDIRPREFIX=/obj
TB --- 2010-08-18 09:50:08 - PATH=/usr/bin:/usr/sbin:/bin:/sbin
TB --- 2010-08-18 09:50:08 - TARGET=sun4v
TB --- 2010-08-18 09:50:08 - TARGET_ARCH=sparc64
TB --- 2010-08-18 09:50:08 - TZ=UTC
TB --- 2010-08-18 09:50:08 - __MAKE_CONF=/dev/null
TB --- 2010-08-18 09:50:08 - cd /src
TB --- 2010-08-18 09:50:08 - /usr/bin/make -B buildworld
>>> World build started on Wed Aug 18 09:50:09 UTC 2010
>>> Rebuilding the temporary build tree
>>> stage 1.1: legacy release compatibility shims
>>> stage 1.2: bootstrap tools
>>> stage 2.1: cleaning up the object tree
>>> stage 2.2: rebuilding the object tree
>>> stage 2.3: build tools
>>> stage 3: cross tools
>>> stage 4.1: building includes
>>> stage 4.2: building libraries
>>> stage 4.3: make dependencies
>>> stage 4.4: building everything
>>> World build completed on Wed Aug 18 10:55:36 UTC 2010
TB --- 2010-08-18 10:55:36 - generating LINT kernel config
TB --- 2010-08-18 10:55:36 - cd /src/sys/sun4v/conf
TB --- 2010-08-18 10:55:36 - /usr/bin/make -B LINT
TB --- 2010-08-18 10:55:36 - building LINT kernel
TB --- 2010-08-18 10:55:36 - MAKEOBJDIRPREFIX=/obj
TB --- 2010-08-18 10:55:36 - PATH=/usr/bin:/usr/sbin:/bin:/sbin
TB --- 2010-08-18 10:55:36 - TARGET=sun4v
TB --- 2010-08-18 10:55:36 - TARGET_ARCH=sparc64
TB --- 2010-08-18 10:55:36 - TZ=UTC
TB --- 2010-08-18 10:55:36 - __MAKE_CONF=/dev/null
TB --- 2010-08-18 10:55:36 - cd /src
TB --- 2010-08-18 10:55:36 - /usr/bin/make -B buildkernel KERNCONF=LINT
>>> Kernel build for LINT started on Wed Aug 18 10:55:37 UTC 2010
>>> stage 1: configuring the kernel
>>> stage 2.1: cleaning up the object tree
>>> stage 2.2: rebuilding the object tree
>>> stage 2.3: build tools
>>> stage 3.1: making dependencies
>>> stage 3.2: building the kernel
>>> stage 3.3: building the modules
>>> Kernel build for LINT completed on Wed Aug 18 11:19:24 UTC 2010
TB --- 2010-08-18 11:19:24 - building GENERIC kernel
TB --- 2010-08-18 11:19:24 - MAKEOBJDIRPREFIX=/obj
TB --- 2010-08-18 11:19:24 - PATH=/usr/bin:/usr/sbin:/bin:/sbin
TB --- 2010-08-18 11:19:24 - TARGET=sun4v
TB --- 2010-08-18 11:19:24 - TARGET_ARCH=sparc64
TB --- 2010-08-18 11:19:24 - TZ=UTC
TB --- 2010-08-18 11:19:24 - __MAKE_CONF=/dev/null
TB --- 2010-08-18 11:19:24 - cd /src
TB --- 2010-08-18 11:19:24 - /usr/bin/make -B buildkernel KERNCONF=GENERIC
>>> Kernel build for GENERIC started on Wed Aug 18 11:19:24 UTC 2010
>>> stage 1: configuring the kernel
>>> stage 2.1: cleaning up the object tree
>>> stage 2.2: rebuilding the object tree
>>> stage 2.3: build tools
>>> stage 3.1: making dependencies
>>> stage 3.2: building the kernel
>>> stage 3.3: building the modules
--
cd /obj/sun4v.sparc64/src/sys/GENERIC; MAKEOBJDIRPREFIX=/obj/sun4v.sparc64  
MACHINE_ARCH=sparc64  MACHINE=sun4v  CPUTYPE=  
GROFF_BIN_PATH=/obj/sun4v.sparc64/src/tmp/legacy/usr/bin  
GROFF_FONT_PATH=/obj/sun4v.sparc64/src/tmp/legacy/usr/share/groff_font  
GROFF_TMAC_PATH=/obj/sun4v.sparc64/src/tmp/legacy/usr/share/tmac  
_SHLIBDIRPREFIX=/obj/sun4v.sparc64/src/tmp  VERSION="FreeBSD 8.0-STABLE amd64 
800504"  INSTALL="sh /src/tools/install.sh"  
PATH=/obj/sun4v.sparc64/src/tmp/legacy/usr/sbin:/obj/sun4v.sparc64/src/tmp/legacy/usr/bin:/obj/sun4v.sparc64/src/tmp/legacy/usr/games:/obj/sun4v.sparc64/src/tmp/usr/sbin:/obj/sun4v.sparc64/src/tmp/usr/bin:/obj/sun4v.sparc64/src/tmp/usr/games:/sbin:/bin:/usr/sbin:/usr/bin
 /usr/bin/make KERNEL=kernel modules-all -DNO_MODULES_OBJ
make: don't know how to make modules-all. Stop
*** Error code 2

Stop in /src.
*** Error code 1

Stop in /src.
TB --- 2010-08-18 11:23:06 - WARNING: /usr/bin/make returned exit code  1 
TB --- 2010-08-18 11:23:06 - ERROR: failed to build GENERIC kernel
TB --- 2010-08-18 11:23:06 - 4043.42 user 965.02 system 5754.09 real


http://tinderbox.freebsd.org/tinderbox-head-HEAD-sparc64-sun4v.full
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: bsdgrep does not work with tail -f | grep combination

[poyopoyo]

Hi Gabor and others,

As Gabor committed r211364, bsdgrep now works nicely with tail -f.

http://svn.freebsd.org/changeset/base/211364

Thank you very much.

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

Mounting cd9660 multiple times gives EBUSY [Was: unionfs a little improvement]

[Ed Schouten]

Hi Daichi,

I think Keith Packard of Xorg once wrote a commit message along the
lines of "5000 lines of code removed, feature added" This seems to be
similar, albeit on a smaller scale. ;-)

Apart from this issue with unionfs, I am also experiencing another
issue, where for some reason I cannot perform a second mount of the CD
right after booting the system. Basically, my WIP FreeBSD boot CD does
the following (but written in C):

mount -t cd9660 /dev/iso9660/freebsd /mnt
mount -t tmpfs none /tmp
mount -t unionfs /tmp /mnt
mount -t devfs none /mnt/dev
chroot /mnt /sbin/init

The first step fails with EBUSY. I use the following hack to get it
working, but I don't think it's the proper way to solve it:

%%%
Index: sys/geom/geom_vfs.c
===
--- sys/geom/geom_vfs.c (revision 211093)
+++ sys/geom/geom_vfs.c (working copy)
@@ -162,8 +162,10 @@
 
*cpp = NULL;
bo = &vp->v_bufobj;
+#if 0
if (bo->bo_private != vp)
return (EBUSY);
+#endif
 
pp = g_dev_getprovider(vp->v_rdev);
if (pp == NULL)
%%%

I am really not that familiar with GEOM/VFS to understand the impact of
this change. What does it actually mean if bo->bo_private != vp?

-- 
 Ed Schouten 
 WWW: http://80386.nl/


pgpDtQb4iDzU5.pgp
Description: PGP signature

Re: LOR on nfs: vfs_vnops.c:301 kern_descrip.c:1580

[pluknet]

On 18 August 2010 12:07, pluknet  wrote:
> On 17 August 2010 20:04, Kostik Belousov  wrote:
>
>>
>> Also please take a note of the John' suggestion to use the taskqueue.
>
> I decided to go this road. Thank you both.
> Now I do nfs buildkernel survive and prepare some benchmark results.
>

So, I modified the patch to defer proc_create() with taskqueue(9).
Below is `time make -j5 buildkernel WITHOUT_MODULES=yes` perf. evaluation.
Done on 4-way CPU on clean /usr/obj with /usr/src & /usr/obj both
nfs-mounted over 1Gbit LAN.

clean old
1137.985u 239.411s 7:42.15 298.0%   6538+2133k 87+43388io 226pf+0w

clean new
1134.755u 240.032s 7:41.25 298.0%   6553+2133k 87+43367io 224pf+0w

Patch needs polishing, though it generally works.
Not sure if shep_chan (or whatever name it will get) needs locking.

-- 
wbr,
pluknet


nfsiod_tq.diff
Description: Binary data
___
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: AR9280 "bb hang" and other

[Ian FREISLICH]

Adrian Chadd wrote:
> Can you please change one at a time and see which affected it?

Looking at my logs:

startup:
Aug 18 09:41:40 mini kernel: wlan0: Ethernet address: b4:82:fe:72:16:09
Aug 18 09:41:41 mini kernel: wlan0: link state changed to UP

?:
Aug 18 09:45:25 mini kernel: ath0: bb hang detected (0x80), resetting

RF switch off:
Aug 18 09:49:50 mini kernel: ath0: bb hang detected (0x80), resetting
Aug 18 09:50:13 mini kernel: wlan0: link state changed to DOWN

RF switch on:
Aug 18 09:50:13 mini kernel: wlan0: link state changed to UP

AP changed channels
Aug 18 09:54:40 mini kernel: ath0: bb hang detected (0x80), resetting

wlan0 destroy:
Aug 18 09:56:31 mini kernel: wlan0: link state changed to DOWN
Aug 18 09:56:31 mini dhclient[1300]: Interface wlan0 no longer appears valid.

wlan0 create:
Aug 18 09:56:33 mini kernel: wlan0: Ethernet address: b4:82:fe:72:16:09
Aug 18 09:56:36 mini kernel: wlan0: link state changed to UP

It really looks likes like it's signal related, not card related
because this card still got a signal related bb hang before the
channel change, but not after.

Ian

-- 
Ian Freislich
___
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: AR9280 "bb hang" and other

[Adrian Chadd]

Can you please change one at a time and see which affected it?

Thanks,


Adrian

On 18 August 2010 16:26, Ian FREISLICH  wrote:
> Rui Paulo wrote:
>> On 17 Aug 2010, at 09:17, Ian FREISLICH wrote:
>> > Aug 17 09:29:08 mini kernel: ath0: bb hang detected (0x80), resetting
>> > Aug 17 09:37:57 mini kernel: ath0: bb hang detected (0x80), resetting
>> > Aug 17 09:49:10 mini kernel: ath0: bb hang detected (0x80), resetting
>> > Aug 17 10:06:17 mini kernel: ath0: bb hang detected (0x80), resetting
>>
>> BB hangs are a problem with the 9280 but I don't know how to fix.
>> Hardware errors shouldn't happen, but this might mean you have
>> very aggressive power reduction settings (ACPI C3, etc.) that are
>> interfering with the atheros card. This has happened to me in the
>> past.
>
> Now, I've made 2 changes so I'm not sure which affected it:
>
> 1. I replaced the card with an AR9285
>
> a...@pci0:1:0:0: class=0x028000 card=0x7167144f chip=0x002b168c rev=0x01 
> hdr=0x00
>    vendor  = 'Atheros Communications Inc.'
>    device  = 'Atheros AR9285 Wireless LAN 802.11 a/b/g/n Controller (AR928x)'
>    class   = network
>
> 2. I changed the channel on our AP. (there were 2 other nearby APs
>   on the same channel).
>
> I noticed that I got a lot more bb hangs at the office compared to
> home - there are a lot more APs nearby:
>
> [mini] /usr/home/ianf $ ifconfig wlan0 scan
> SSID/MESH ID    BSSID              CHAN RATE   S:N     INT CAPS
> Ignition        00:26:bb:78:b4:91    6   54M -89:-96  100 EPS  RSN HTCAP WPA 
> WME
> Eco Impact      00:22:3f:55:80:bc   11   54M -92:-96  100 EP   HTCAP WPS WPA 
> WME
> Viic            00:14:6c:49:3f:1c   11   54M -92:-96  100 EPS  WPA ATH WME
> cluelan         00:30:4f:58:bf:96    7   54M -72:-96  100 EPS  WPA ATH WME
> PRIVATE LABEL   00:19:70:05:28:c4    3   54M -79:-96  100 EP   WPA WME
> blinkbroom1     00:18:4d:1c:8e:3a    5   54M -89:-96  100 EPS  WPA
> Sasman          00:26:f2:46:2c:de    1   54M -93:-96  100 EP   WME
> cocoa           00:26:f2:3d:aa:13    3   54M -94:-96  200 EPS  WME HTCAP ATH
> CareCross       30:46:9a:1e:b0:ca    8   54M -35:-96  100 EPS  RSN WPA
>
> We're "cluelan" and we were on channel 3.  Previously, I was seeing
> a hang every 10 minutes or so, since changing the channel to a
> "free" one, I haven't had a hang in the last 40 minutes.  The only
> bb hang I've had was when I deactivated the RF switch on netbook
> and that was a semi-expected result.
>
> Ian
>
> --
> Ian Freislich
> ___
> freebsd-current@freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-current
> To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
>
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: Building world with clang

[Dag-Erling Smørgrav]

Dimitry Andric  writes:
> Alexander Kabaev  writes:
> > Does method 1) work fine with 'make buildenv'? I doubt that. I would
> > strongly suggest we should not lose this feature. I do not like the
> > idea of having to depend on -isystem in CFLAGS in such an environment. 
> I have not tested make buildenv with this method, but since ${CC} is
> modified, not ${CFLAGS}, there is a reasonable chance that it might
> work. :)

I'm not a big fan of "reasonable chances" when it comes to the
toolchain.

> Note a similar method is already being using for the build32 stage on
> amd64, where ${CC} has a bunch of flags (including -isystem, -L and -B)
> appended.

No, what is used is a variant of method 1 *on top of* method 2 for a
very specific case.  You need "a special version of clang" (method 2)
anyway to support cross-building.

DES
-- 
Dag-Erling Smørgrav - d...@des.no
___
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: AR9280 "bb hang" and other

[Rui Paulo]

On 18 Aug 2010, at 09:26, Ian FREISLICH wrote:

> Rui Paulo wrote:
>> On 17 Aug 2010, at 09:17, Ian FREISLICH wrote:
>>> Aug 17 09:29:08 mini kernel: ath0: bb hang detected (0x80), resetting
>>> Aug 17 09:37:57 mini kernel: ath0: bb hang detected (0x80), resetting
>>> Aug 17 09:49:10 mini kernel: ath0: bb hang detected (0x80), resetting
>>> Aug 17 10:06:17 mini kernel: ath0: bb hang detected (0x80), resetting
>> 
>> BB hangs are a problem with the 9280 but I don't know how to fix.
>> Hardware errors shouldn't happen, but this might mean you have
>> very aggressive power reduction settings (ACPI C3, etc.) that are
>> interfering with the atheros card. This has happened to me in the
>> past.
> 
> Now, I've made 2 changes so I'm not sure which affected it:
> 
> 1. I replaced the card with an AR9285
> 
> a...@pci0:1:0:0: class=0x028000 card=0x7167144f chip=0x002b168c rev=0x01 
> hdr=0x00
>vendor  = 'Atheros Communications Inc.'
>device  = 'Atheros AR9285 Wireless LAN 802.11 a/b/g/n Controller (AR928x)'
>class   = network
> 
> 2. I changed the channel on our AP. (there were 2 other nearby APs
>   on the same channel).
> 
> I noticed that I got a lot more bb hangs at the office compared to
> home - there are a lot more APs nearby:
> 
> [mini] /usr/home/ianf $ ifconfig wlan0 scan
> SSID/MESH IDBSSID  CHAN RATE   S:N INT CAPS
> Ignition00:26:bb:78:b4:916   54M -89:-96  100 EPS  RSN HTCAP WPA 
> WME
> Eco Impact  00:22:3f:55:80:bc   11   54M -92:-96  100 EP   HTCAP WPS WPA 
> WME
> Viic00:14:6c:49:3f:1c   11   54M -92:-96  100 EPS  WPA ATH WME
> cluelan 00:30:4f:58:bf:967   54M -72:-96  100 EPS  WPA ATH WME
> PRIVATE LABEL   00:19:70:05:28:c43   54M -79:-96  100 EP   WPA WME
> blinkbroom1 00:18:4d:1c:8e:3a5   54M -89:-96  100 EPS  WPA
> Sasman  00:26:f2:46:2c:de1   54M -93:-96  100 EP   WME
> cocoa   00:26:f2:3d:aa:133   54M -94:-96  200 EPS  WME HTCAP ATH
> CareCross   30:46:9a:1e:b0:ca8   54M -35:-96  100 EPS  RSN WPA
> 
> We're "cluelan" and we were on channel 3.  Previously, I was seeing
> a hang every 10 minutes or so, since changing the channel to a
> "free" one, I haven't had a hang in the last 40 minutes.  The only
> bb hang I've had was when I deactivated the RF switch on netbook
> and that was a semi-expected result.

Yes, the hangs are dependent on the signal and noise conditions.

Regards,
--
Rui Paulo


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

unionfs a little improvement

[Daichi GOTO]

Hi Ed and unionfs fan gyus.

Ed pointed out a contradict behavior between current
unionfs implementation and its manual, and sent me a
patch.

Thanks Ed ;)


Index: sys/fs/unionfs/union_vfsops.c
===
--- sys/fs/unionfs/union_vfsops.c   (revision 211093)
+++ sys/fs/unionfs/union_vfsops.c   (working copy)
@@ -89,7 +89,6 @@
u_short ufile;
unionfs_copymode copymode;
unionfs_whitemode whitemode;
-   struct componentname fakecn;
struct nameidata nd, *ndp;
struct vattrva;

@@ -280,26 +279,6 @@
mp->mnt_flag |= ump->um_uppervp->v_mount->mnt_flag & MNT_RDONLY;

/*
-* Check whiteout
-*/
-   if ((mp->mnt_flag & MNT_RDONLY) == 0) {
-   memset(&fakecn, 0, sizeof(fakecn));
-   fakecn.cn_nameiop = LOOKUP;
-   fakecn.cn_thread = td;
-   error = VOP_WHITEOUT(ump->um_uppervp, &fakecn, LOOKUP);
-   if (error) {
-   if (below) {
-   VOP_UNLOCK(ump->um_uppervp, 0);
-   vrele(upperrootvp);
-   } else
-   vput(ump->um_uppervp);
-   free(ump, M_UNIONFSMNT);
-   mp->mnt_data = NULL;
-   return (error);
-   }
-   }
-
-   /*
 * Unlock the node
 */
VOP_UNLOCK(ump->um_uppervp, 0);



Ed's message here:


Just for fun I was hacking on a writable bootcd, using unionfs and
tmpfs. I noticed tmpfs doesn't support whiteouts (yet). This prevents
unionfs from mounting tmpfs on top. I do want to be able to use tmpfs,
even if it means we can't get any whiteouts.

The manpage says the following:

Without whiteout support from the file system backing the upper layer,
there is no way that delete and rename operations on lower layer 
objects

can be done.  EROFS is returned for this kind of operations along with
any others which would make modifications to the lower layer, such as
chmod(1).

This seems to contradict the current behaviour, which is to deny the
mount altogether. The attached patch makes it work, but instead of
EROFS, it now returns EOPNOTSUPP, as generated by VOP_WHITEOUT().



It looks like reasonable and patch is simple and effective I guess.
If you unionfs guys or fs guys have some ideas around this patch,
please teach me.

After some tests and a couple of weeks after, I'll commit ed's patch
if there is no objections.


--
Daichi GOTO
81-42-316-7945 | dai...@ongs.co.jp | http://www.ongs.co.jp
LinkedIn: http://linkedin.com/in/daichigoto
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

[head tinderbox] failure on i386/i386

[FreeBSD Tinderbox]

TB --- 2010-08-18 06:10:00 - tinderbox 2.6 running on freebsd-current.sentex.ca
TB --- 2010-08-18 06:10:00 - starting HEAD tinderbox run for i386/i386
TB --- 2010-08-18 06:10:00 - cleaning the object tree
TB --- 2010-08-18 06:10:38 - cvsupping the source tree
TB --- 2010-08-18 06:10:38 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca 
/tinderbox/HEAD/i386/i386/supfile
TB --- 2010-08-18 06:16:37 - building world
TB --- 2010-08-18 06:16:37 - MAKEOBJDIRPREFIX=/obj
TB --- 2010-08-18 06:16:37 - PATH=/usr/bin:/usr/sbin:/bin:/sbin
TB --- 2010-08-18 06:16:37 - TARGET=i386
TB --- 2010-08-18 06:16:37 - TARGET_ARCH=i386
TB --- 2010-08-18 06:16:37 - TZ=UTC
TB --- 2010-08-18 06:16:37 - __MAKE_CONF=/dev/null
TB --- 2010-08-18 06:16:37 - cd /src
TB --- 2010-08-18 06:16:37 - /usr/bin/make -B buildworld
>>> World build started on Wed Aug 18 06:16:37 UTC 2010
>>> Rebuilding the temporary build tree
>>> stage 1.1: legacy release compatibility shims
>>> stage 1.2: bootstrap tools
>>> stage 2.1: cleaning up the object tree
>>> stage 2.2: rebuilding the object tree
>>> stage 2.3: build tools
>>> stage 3: cross tools
>>> stage 4.1: building includes
>>> stage 4.2: building libraries
>>> stage 4.3: make dependencies
>>> stage 4.4: building everything
>>> World build completed on Wed Aug 18 08:03:38 UTC 2010
TB --- 2010-08-18 08:03:38 - generating LINT kernel config
TB --- 2010-08-18 08:03:38 - cd /src/sys/i386/conf
TB --- 2010-08-18 08:03:38 - /usr/bin/make -B LINT
TB --- 2010-08-18 08:03:38 - building LINT kernel
TB --- 2010-08-18 08:03:38 - MAKEOBJDIRPREFIX=/obj
TB --- 2010-08-18 08:03:38 - PATH=/usr/bin:/usr/sbin:/bin:/sbin
TB --- 2010-08-18 08:03:38 - TARGET=i386
TB --- 2010-08-18 08:03:38 - TARGET_ARCH=i386
TB --- 2010-08-18 08:03:38 - TZ=UTC
TB --- 2010-08-18 08:03:38 - __MAKE_CONF=/dev/null
TB --- 2010-08-18 08:03:38 - cd /src
TB --- 2010-08-18 08:03:38 - /usr/bin/make -B buildkernel KERNCONF=LINT
>>> Kernel build for LINT started on Wed Aug 18 08:03:38 UTC 2010
>>> stage 1: configuring the kernel
>>> stage 2.1: cleaning up the object tree
>>> stage 2.2: rebuilding the object tree
>>> stage 2.3: build tools
>>> stage 3.1: making dependencies
>>> stage 3.2: building the kernel
>>> stage 3.3: building the modules
>>> Kernel build for LINT completed on Wed Aug 18 08:30:39 UTC 2010
TB --- 2010-08-18 08:30:39 - building GENERIC kernel
TB --- 2010-08-18 08:30:39 - MAKEOBJDIRPREFIX=/obj
TB --- 2010-08-18 08:30:39 - PATH=/usr/bin:/usr/sbin:/bin:/sbin
TB --- 2010-08-18 08:30:39 - TARGET=i386
TB --- 2010-08-18 08:30:39 - TARGET_ARCH=i386
TB --- 2010-08-18 08:30:39 - TZ=UTC
TB --- 2010-08-18 08:30:39 - __MAKE_CONF=/dev/null
TB --- 2010-08-18 08:30:39 - cd /src
TB --- 2010-08-18 08:30:39 - /usr/bin/make -B buildkernel KERNCONF=GENERIC
>>> Kernel build for GENERIC started on Wed Aug 18 08:30:39 UTC 2010
>>> stage 1: configuring the kernel
>>> stage 2.1: cleaning up the object tree
>>> stage 2.2: rebuilding the object tree
>>> stage 2.3: build tools
>>> stage 3.1: making dependencies
>>> stage 3.2: building the kernel
>>> stage 3.3: building the modules
>>> Kernel build for GENERIC completed on Wed Aug 18 08:51:08 UTC 2010
TB --- 2010-08-18 08:51:08 - building PAE kernel
TB --- 2010-08-18 08:51:08 - MAKEOBJDIRPREFIX=/obj
TB --- 2010-08-18 08:51:08 - PATH=/usr/bin:/usr/sbin:/bin:/sbin
TB --- 2010-08-18 08:51:08 - TARGET=i386
TB --- 2010-08-18 08:51:08 - TARGET_ARCH=i386
TB --- 2010-08-18 08:51:08 - TZ=UTC
TB --- 2010-08-18 08:51:08 - __MAKE_CONF=/dev/null
TB --- 2010-08-18 08:51:08 - cd /src
TB --- 2010-08-18 08:51:08 - /usr/bin/make -B buildkernel KERNCONF=PAE
>>> Kernel build for PAE started on Wed Aug 18 08:51:08 UTC 2010
>>> stage 1: configuring the kernel
>>> stage 2.1: cleaning up the object tree
>>> stage 2.2: rebuilding the object tree
>>> stage 2.3: build tools
>>> stage 3.1: making dependencies
>>> stage 3.2: building the kernel
>>> stage 3.3: building the modules
--
cd /obj/i386.i386/src/sys/PAE; MAKEOBJDIRPREFIX=/obj/i386.i386  
MACHINE_ARCH=i386  MACHINE=i386  CPUTYPE=  
GROFF_BIN_PATH=/obj/i386.i386/src/tmp/legacy/usr/bin  
GROFF_FONT_PATH=/obj/i386.i386/src/tmp/legacy/usr/share/groff_font  
GROFF_TMAC_PATH=/obj/i386.i386/src/tmp/legacy/usr/share/tmac  
_SHLIBDIRPREFIX=/obj/i386.i386/src/tmp  VERSION="FreeBSD 8.0-STABLE amd64 
800504"  INSTALL="sh /src/tools/install.sh"  
PATH=/obj/i386.i386/src/tmp/legacy/usr/sbin:/obj/i386.i386/src/tmp/legacy/usr/bin:/obj/i386.i386/src/tmp/legacy/usr/games:/obj/i386.i386/src/tmp/usr/sbin:/obj/i386.i386/src/tmp/usr/bin:/obj/i386.i386/src/tmp/usr/games:/sbin:/bin:/usr/sbin:/usr/bin
 /usr/bin/make KERNEL=kernel modules-all -DNO_MODULES_OBJ
make: don't know how to make modules-all. Stop
*** Error code 2

Stop in /src.
*** Error code 1

Stop in /src.
TB --- 2010-08-18 08:56:29 - WARNING: /usr/bin/make returned exit code  1 
TB --- 2010-08-18 08:56:29 - ERROR: failed to build PAE kernel
TB --- 2010-08-18 08:56:29 - 7339.23 user 1486.

8.1-release + zfs v15 df(1) hangs

[Marian Hettwer]

 Hi All,

i installed freebsd 8.1-release on my workstation (based on the 
8.1-release mfsbsd isos) and I'm now experiencing some strange effects.


A df(1) doesn't return and is not killable and while taking a look 
around in my process table, I could find several find's hanging around too.


mhettwer  5976  0.0  0.0  6896  1088  13  D+5:55PM   0:00.00 df -h
mhettwer  5351  0.0  0.0  6896  1088  19  D+1:49PM   0:00.00 df -h

root   215  0.0  0.0  5804  1232  ??  DMon05AM   0:04.29 find 
-sx / /home /tmp /var /dev/null -type f ( -perm -u+x -or -perm -g+x -or 
-perm -o+x ) ( -perm -u+s -or -perm -g+s ) -exec ls -liTd {} +
root  4139  0.0  0.0  5804  1324  ??  DTue05AM   0:02.38 find 
-sx / /home /tmp /var /dev/null -type f ( -perm -u+x -or -perm -g+x -or 
-perm -o+x ) ( -perm -u+s -or -perm -g+s ) -exec ls -liTd {} +
root  7305  0.0  0.0  5804  1324  ??  D 5:01AM   0:00.43 find 
-sx / /home /tmp /var /dev/null -type f ( -perm -u+x -or -perm -g+x -or 
-perm -o+x ) ( -perm -u+s -or -perm -g+s ) -exec ls -liTd {} +
root 73775  0.0  0.0  5804  1232  ??  DFri05AM   0:10.18 find 
-sx / /home /tmp /var /dev/null -type f ( -perm -u+x -or -perm -g+x -or 
-perm -o+x ) ( -perm -u+s -or -perm -g+s ) -exec ls -liTd {} +
root 94589  0.0  0.0  5804  1232  ??  DSat05AM   0:07.68 find 
-sx / /home /tmp /var /dev/null -type f ( -perm -u+x -or -perm -g+x -or 
-perm -o+x ) ( -perm -u+s -or -perm -g+s ) -exec ls -liTd {} +
nobody   94746  0.0  0.0  5804  1072  ??  DN   Sat06AM   0:07.38 find -s 
/ ! ( -fstype zfs ) -prune -or -path /tmp -prune -or -path /usr/tmp 
-prune -or -path /var/tmp -prune -or -path /var/db/portsnap -prune -or 
-print
root 97430  0.0  0.0  5804  1232  ??  DSun05AM   0:06.02 find 
-sx / /home /tmp /var /dev/null -type f ( -perm -u+x -or -perm -g+x -or 
-perm -o+x ) ( -perm -u+s -or -perm -g+s ) -exec ls -liTd {} +


I couldn't figure out where they're coming from, but since it seems 
there's a new one every night I suspect its coming from a periodic script.


Any ideas how to get rid of those processes?

And yes, I know that zfs V15 isn't in -STABLE for a reason...


# uname -a
# FreeBSD siteop38-1.mobile.rz 8.1-RELEASE FreeBSD 8.1-RELEASE #0: Tue 
Aug  3 12:03:02 UTC 2010 
r...@siteop38-1.mobile.rz:/usr/obj/usr/src/sys/GENERIC  amd64


(I csup'ed to RELENG_8_1 and applied the v15 patch from 
http://mfsbsd.vx.sk/ and did a make world)


best regards,
Marian

PS.: For the author of mfsbsd iso's: I like them. Cool! Thanks! :)
___
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: AR9280 "bb hang" and other

[Ian FREISLICH]

Rui Paulo wrote:
> On 17 Aug 2010, at 09:17, Ian FREISLICH wrote:
> > Aug 17 09:29:08 mini kernel: ath0: bb hang detected (0x80), resetting
> > Aug 17 09:37:57 mini kernel: ath0: bb hang detected (0x80), resetting
> > Aug 17 09:49:10 mini kernel: ath0: bb hang detected (0x80), resetting
> > Aug 17 10:06:17 mini kernel: ath0: bb hang detected (0x80), resetting
>
> BB hangs are a problem with the 9280 but I don't know how to fix.
> Hardware errors shouldn't happen, but this might mean you have
> very aggressive power reduction settings (ACPI C3, etc.) that are
> interfering with the atheros card. This has happened to me in the
> past.

Now, I've made 2 changes so I'm not sure which affected it:

1. I replaced the card with an AR9285

a...@pci0:1:0:0: class=0x028000 card=0x7167144f chip=0x002b168c rev=0x01 
hdr=0x00
vendor  = 'Atheros Communications Inc.'
device  = 'Atheros AR9285 Wireless LAN 802.11 a/b/g/n Controller (AR928x)'
class   = network

2. I changed the channel on our AP. (there were 2 other nearby APs
   on the same channel).

I noticed that I got a lot more bb hangs at the office compared to
home - there are a lot more APs nearby:

[mini] /usr/home/ianf $ ifconfig wlan0 scan
SSID/MESH IDBSSID  CHAN RATE   S:N INT CAPS
Ignition00:26:bb:78:b4:916   54M -89:-96  100 EPS  RSN HTCAP WPA WME
Eco Impact  00:22:3f:55:80:bc   11   54M -92:-96  100 EP   HTCAP WPS WPA WME
Viic00:14:6c:49:3f:1c   11   54M -92:-96  100 EPS  WPA ATH WME
cluelan 00:30:4f:58:bf:967   54M -72:-96  100 EPS  WPA ATH WME
PRIVATE LABEL   00:19:70:05:28:c43   54M -79:-96  100 EP   WPA WME
blinkbroom1 00:18:4d:1c:8e:3a5   54M -89:-96  100 EPS  WPA
Sasman  00:26:f2:46:2c:de1   54M -93:-96  100 EP   WME
cocoa   00:26:f2:3d:aa:133   54M -94:-96  200 EPS  WME HTCAP ATH
CareCross   30:46:9a:1e:b0:ca8   54M -35:-96  100 EPS  RSN WPA

We're "cluelan" and we were on channel 3.  Previously, I was seeing
a hang every 10 minutes or so, since changing the channel to a
"free" one, I haven't had a hang in the last 40 minutes.  The only
bb hang I've had was when I deactivated the RF switch on netbook
and that was a semi-expected result.

Ian

-- 
Ian Freislich
___
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: LOR on nfs: vfs_vnops.c:301 kern_descrip.c:1580

[pluknet]

On 17 August 2010 20:04, Kostik Belousov  wrote:
> On Tue, Aug 17, 2010 at 07:42:41PM +0400, pluknet wrote:
>> 2010/8/16 Kostik Belousov :
>> > On Mon, Aug 16, 2010 at 09:07:24PM +0400, pluknet wrote:
>> >> On 16 August 2010 21:05, pluknet  wrote:
>> >> > Hi.
>> >> >
>> >> > Seeing on mostly idle, recently updated current, while closing a file.
>> >> > Presumably never reported on ML.
>> [...]
>> >>
>> > Both LORs are valid. The fork performed deep inside the VFS call stack
>> > is obviously problematic. As a workaround, you may fix the number of
>> > nfsiods.
>> >
>> > Proper fix might consist of creating a shepherd thread which only task
>> > is to act on the requests on creating new nfsiods.
>> >
>> > Would you try to implement this ? I will provide the assistance, if needed.
>>
>> Hmm.. I tried to move kproc_create() under shepherd thread and now stuck
>> with cp process lockup in [bo_wwait] when cp'ing something on nfs: cp a b.
>> Did I screw up something?
>> See weird draft patch attached (weird, as I have no idea how to nicely
>> exchange data between nfs_nfsiodnew() and shep_thread() thread).
> Most likely, you loose the requests to create nfsiods since the
> existing request in the global variable shep_chan can be overwritten
> by new request. You should either sleep till existing request is serviced,
> or form a queue.

It turns out I passed pointer to pointer instead of pointer
(sorry for my poor English).

>
> Also please take a note of the John' suggestion to use the taskqueue.

I decided to go this road. Thank you both.
Now I do nfs buildkernel survive and prepare some benchmark results.

-- 
wbr,
pluknet
___
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"