Re: recent ath changes related panic

[Bernhard Schmidt]

On Fri, Aug 20, 2010 at 01:04, Chris Ruiz  wrote:
> I run a PCI Atheros card in hostap mode on CURRENT.
>
> a...@pci0:6:0:0:        class=0x02 card=0x5a001385 chip=0x0013168c
> rev=0x01 hdr=0x00
>    vendor     = 'Atheros Communications Inc.'
>    device     = '802.11a/b/g Wireless Adapter (AR2312)'
>    class      = network
>    subclass   = ethernet
>
> Everything works fine with r211193 but with newer kernels I receive
> the same panic related to the ath0 tasq.


I guess this also happens with post-r211314 kernels?


> the panic -
> http://tinypic.com/r/11t3g39/4
>
> the backtrace -
> http://tinypic.com/r/nv4786/4
>
> Sorry about the pics,  I don't have access to serial or dcons.
>
> -- Chris Ruiz
>
> -
> http://twitter.com/chrisattack
> http://chrisattack.com
> ___
> freebsd-current@freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-current
> To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
>



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

Re: recent ath changes related panic

[Bernhard Schmidt]

On Fri, Aug 20, 2010 at 08:31, Bernhard Schmidt  wrote:
> On Fri, Aug 20, 2010 at 01:04, Chris Ruiz  wrote:
>> I run a PCI Atheros card in hostap mode on CURRENT.
>>
>> a...@pci0:6:0:0:        class=0x02 card=0x5a001385 chip=0x0013168c
>> rev=0x01 hdr=0x00
>>    vendor     = 'Atheros Communications Inc.'
>>    device     = '802.11a/b/g Wireless Adapter (AR2312)'
>>    class      = network
>>    subclass   = ethernet
>>
>> Everything works fine with r211193 but with newer kernels I receive
>> the same panic related to the ath0 tasq.
>
>
> I guess this also happens with post-r211314 kernels?

Seems like I missed you wrap a few ieee80211_ratectl_node_init()
calls. Please try attached patch, it should fix it.


-- 
Bernhard
Index: sys/net80211/ieee80211_node.c
===
--- sys/net80211/ieee80211_node.c	(revision 211524)
+++ sys/net80211/ieee80211_node.c	(working copy)
@@ -817,8 +817,7 @@ ieee80211_sta_join(struct ieee80211vap *vap, struc
 	if (ieee80211_iserp_rateset(&ni->ni_rates))
 		ni->ni_flags |= IEEE80211_NODE_ERP;
 	ieee80211_node_setuptxparms(ni);
-	if (vap->iv_caps & IEEE80211_C_RATECTL)
-		ieee80211_ratectl_node_init(ni);
+	ieee80211_ratectl_node_init(ni);
 
 	return ieee80211_sta_join1(ieee80211_ref_node(ni));
 }
Index: sys/net80211/ieee80211_sta.c
===
--- sys/net80211/ieee80211_sta.c	(revision 211524)
+++ sys/net80211/ieee80211_sta.c	(working copy)
@@ -1597,8 +1597,7 @@ sta_recv_mgmt(struct ieee80211_node *ni, struct mb
 			 IEEE80211_F_JOIN | IEEE80211_F_DOBRS);
 			ieee80211_setup_basic_htrates(ni, htinfo);
 			ieee80211_node_setuptxparms(ni);
-			if (vap->iv_caps & IEEE80211_C_RATECTL)
-ieee80211_ratectl_node_init(ni);
+			ieee80211_ratectl_node_init(ni);
 		} else {
 #ifdef IEEE80211_SUPPORT_SUPERG
 			if (IEEE80211_ATH_CAP(vap, ni, IEEE80211_NODE_ATH))
Index: sys/net80211/ieee80211_ratectl.h
===
--- sys/net80211/ieee80211_ratectl.h	(revision 211524)
+++ sys/net80211/ieee80211_ratectl.h	(working copy)
@@ -77,7 +77,8 @@ ieee80211_ratectl_node_init(struct ieee80211_node
 {
 	const struct ieee80211vap *vap = ni->ni_vap;
 
-	vap->iv_rate->ir_node_init(ni);
+	if (vap->iv_caps & IEEE80211_C_RATECTL)
+		vap->iv_rate->ir_node_init(ni);
 }
 
 static void __inline
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: Runaway intr, not flash related

[Doug Barton]

On 08/19/2010 10:43, Bjoern A. Zeeb wrote:

On Thu, 19 Aug 2010, Doug Barton wrote:


On 08/19/2010 08:24, Andriy Gapon wrote:

I am sorry, but I don't see anything dramatically wrong here. So
"swi4: clock" uses 5.76% of WCPU, is that such a big deal to be
called "runaway intr"?


That's the symptom.


Have you ever posted a vmstat -i for when this actually happens?


Yes. At the time I was told that it was uninteresting, but I'll include 
it again next time.



Thanks,

Doug

--

Improve the effectiveness of your Internet presence with
a domain name makeover!http://SupersetSolutions.com/

Computers are useless. They can only give you answers.
-- Pablo Picasso

___
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

[Lev Serebryakov]

Hello, Doug.
You wrote 16 августа 2010 г., 10:15:55:

> lua too "flavor of the day," not enough track record of stability,
> not enough installed base/proven utility
 To   be   honest,  lua  is  used  in TONS of  (commercial and, often,
console) games as scripting engine, without any issues with stability
or speed. Console games are very special world, where stability is holy
cow, BTW.

>> some JavaScript engines probably fit the description.
> Yikes! Sorry I asked.  :)
  Best scripting language ever :) Mixup of Lisp and Self, disguised to
  looks  like  "traditional" language. And, yes, I'm serious here. But
  JavaScript   have   one   problem:  both  good  open-source  engines
  (SpiderMonkey   and   V8)  don't  have  good  "system"  library  for
  file/io/process  operations. They are too-browser specific. They can
  be easily stipped down to bare engines (very small, very efficient),
  but  in  such case here is huge amount of work by writing all native
  objects and operations needed for system scripting.

-- 
// Black Lion AKA Lev Serebryakov 

___
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

[Szilveszter Adam]

On Thu, Aug 19, 2010 at 09:42:01PM +, b. f. wrote:
> Gabor:
> 
> One more thing to look into, in addition to the context problems,
> ndisgen breakage, and problems on certain file systems:
> 
> At r211506, 'grep -wq' does not seem to work properly (in the very
> least, it is not the same as with GNU grep), and has broken the
> 'check-categories' target (and hence builds) of all ports with 'lisp'
> in CATEGORIES.

Seconded. This also breaks the ports using bsd.apache.mk, and what's
worse, it does so silently. I have been bitten by this myself with
www/apache22, several core modules have not been built resulting in a
useless apache installation.

So, I believe there is more to do here than just performance
optimisation.

-- 
Regards:

Szilveszter ADAM
Budapest
Hungary
___
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

[Lev Serebryakov]

Hello, Gabor.
You wrote 14 августа 2010 г., 20:10:56:


> 2, GNU grep uses internal optimizations to get that performance. I think
> it's a wrong approach because the regex library itself should be 
> optimized instead to keep BSD grep clean and simple and to provide the
> same efficiency for all utilities that are linked to the regex library.
> Our libc-regex is definitely need to be replaced at some point in the 
> future but that's a more complex item. See the following references:
> http://wiki.freebsd.org/BSDgrep
> http://wiki.freebsd.org/Regex
  You  don't  have  these  links  on Wiki page, so I post them here. I
  hope,  you've  read  these  articles,  but it is better to duplicate
  links, than miss them.

  http://swtch.com/~rsc/regexp/regexp1.html
  http://swtch.com/~rsc/regexp/


  And  it  iw very strange to see TRE s slow, because it seems, it
  is  based  on "fast" linear approcach, when gnu-regexp is old, slow,
  one...

-- 
// Black Lion AKA Lev Serebryakov 

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

Re: Interpreted language(s) in the base

[B. Estrade]

On Fri, Aug 20, 2010 at 10:47:39AM +1000, Andrew Reilly wrote:
> On Thu, Aug 19, 2010 at 06:40:37PM +0200, Ivan Voras wrote:
> > Will have to disagree on that - part of the point of having such a
> > thing would be to attract young developers, and while the CS crowd
> > will be happy with LISP, anyone starting programming after the first
> > .com bubble will probably be repulsed by non-Algol-like syntaxes.
> 
> I suspect that you're right, though that disappoints me
> somewhat.  The only other language that I'm aware of that does a
> reasonable compiles-to-C and has an algol-like syntax is Eiffel
> (specifically SmartEiffel), but I haven't used it for years,
> and don't know how it's travelling.  It's also nowhere near as
> dynamic and "fun" a programming experience, IMO.

Don't assume that the "CS crowd" are LISP or FP sycophants or that
having to program in C is unattractive to new blood (a term I prefer
over "young developers"). FWIW, I use Perl to prototype all sorts of
algorithms and data structures - and most recently, Qore (I maintain
the lang/qore port). But I don't believe either should be in base when
it's so dead simple to install them from ports. 

Cheers,
Brett

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

-- 
B. Estrade 
___
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

[David Xu]

But I think BSD grep should be compatible with GNU grep,
because almost all scripts are written for GNU grep before
BSD grep appears, it is not practical to rewrite all existing
scripts. Anyway, thanks for your help.

David Xu

Stein Morten Sandbech wrote:

Hi,

GNU grep is OK.  However standard BSD grep also work:

find . -exec grep -i world {} /dev/null \;

or even:

find . -exec grep -in world {} /dev/null \;

if you want linenumbers ...

hth

Stein Morten



On Aug 19, 2010, at 11:29, freebsd-current-requ...@freebsd.org wrote:


Date: Thu, 19 Aug 2010 16:42:26 +
From: David Xu 
Subject: Re: Official request: Please make GNU grep the default
To: Gabor Kovesdan 
Cc: delp...@freebsd.org, Andrey Chernov ,  Doug
Barton , c...@freebsd.org, curr...@freebsd.org
Message-ID: <4c6d5ef2.2040...@freebsd.org>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed

Gabor Kovesdan wrote:

Yes, I'm sorry for my slow reaction, I got a flu some time ago and that 
prevented me from fixing the bugs earlier. I have several fixes in my 
working copy, which are being discussed with my mentor. Probably, today 
or tomorrow they will be committed.


Gabor

When will the grep -H print file name for me ?  it is rather painful 
that the feature is missing. :-(

So I can not use it with find:

find . -exec grep -H {} world \;
I don't know which file contains the word world.

Regards,
David Xu





___
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 Reilly]

On Thu, Aug 19, 2010 at 06:40:37PM +0200, Ivan Voras wrote:
> Will have to disagree on that - part of the point of having such a
> thing would be to attract young developers, and while the CS crowd
> will be happy with LISP, anyone starting programming after the first
> .com bubble will probably be repulsed by non-Algol-like syntaxes.

I suspect that you're right, though that disappoints me
somewhat.  The only other language that I'm aware of that does a
reasonable compiles-to-C and has an algol-like syntax is Eiffel
(specifically SmartEiffel), but I haven't used it for years,
and don't know how it's travelling.  It's also nowhere near as
dynamic and "fun" a programming experience, IMO.

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: Interpreted language(s) in the base

[Andrew Reilly]

I didn't want to prolong this now mostly off-topic discussion
too much, but:

On Thu, Aug 19, 2010 at 06:00:54PM +0200, C. P. Ghost wrote:
> +1 for a scheme shell, but not for the heavy-weight variety that
> compiles to C, as that would tie them to a subset of ${ARCH}es.

Why do you say that?  Most of the C-generators that I know of
produce fairly standards-compliant C code that should just work
anywhere.  Sure there are some (with sophisticated memory
managers, mostly) that get intimate with the platform, but
presumably we would have to stay away from those for this sort
of exercise...

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"

recent ath changes related panic

[Chris Ruiz]

I run a PCI Atheros card in hostap mode on CURRENT.

a...@pci0:6:0:0:class=0x02 card=0x5a001385 chip=0x0013168c
rev=0x01 hdr=0x00
vendor = 'Atheros Communications Inc.'
device = '802.11a/b/g Wireless Adapter (AR2312)'
class  = network
subclass   = ethernet

Everything works fine with r211193 but with newer kernels I receive
the same panic related to the ath0 tasq.

the panic -
http://tinypic.com/r/11t3g39/4

the backtrace -
http://tinypic.com/r/nv4786/4

Sorry about the pics,  I don't have access to serial or dcons.

-- Chris Ruiz

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

Re: Official request: Please make GNU grep the default

[John Baldwin]

On Thursday, August 19, 2010 10:12:11 am Dimitry Andric wrote:
> On 2010-08-17 23:24, Alan Cox wrote:
> >> So normal mmap is ~3% slower, and prefault mmap does not seem to make
> >> any measurable difference.  I guess the added complexity is not really
> >> worth it, for now.
> > 
> > Do you know what fraction of this time is being spent in the kernel?
> 
> I ran 100 trials again, but now using "time -a -o logfile", so I could
> run ministat over the accumulated results.  This gives:
> 
> x gnugrep
> + bsdgrep-r210927 (the initial version that started this thread)
> * bsdgrep-r211490 (current version)
> % bsdgrep-r211490-mmap-plain
> # bsdgrep-r211490-mmap-prefault
> 
> Real time:
> N   Min   MaxMedian   AvgStddev
> x 100  1.15  1.98  1.181.21220.11159613
> + 100  8.57 14.26  8.799.1823 1.0496126
> * 100  2.81  6.57  2.913.0189 0.4304259
> % 100  2.34  4.03  2.993.00220.12635992
> # 100  2.85  3.49  2.882.8981   0.075232904
> 
> User time:
> N   Min   MaxMedian   AvgStddev
> x 100 0  0.07  0.030.0239   0.015627934
> + 100   1.6  3.33   1.9 1.9760.30264824
> * 100  0.29 1  0.390.40040.08696824
> % 100   1.8  3.56  2.732.72740.13260117
> # 100  2.78  3.04  2.812.82380.04039652
> 
> System time:
> N   Min   MaxMedian   AvgStddev
> x 100  1.08  1.91  1.151.18090.10953617
> + 100  6.55  10.9  6.947.19050.77911809
> * 100  2.38   5.5  2.532.60610.35068445
> % 100  0.18  0.53  0.250.2645   0.053586049
> # 100  0.03  0.54  0.060.0668   0.052259647
> 
> E.g. it looks like bsdgrep with 'plain' mmap performs almost the same
> as the regular bsdgrep (both around 3.0s average), but with mmap much
> more of the time is spent in user mode.

I would add user and system time together and compare the total time.  Given 
that statclock only fires at 128 hz, and we use those counts to subdivide 
rux_runtime, I don't put much faith in user vs system time for benchmarks, 
only the total runtime in rux_runtime (which is user + system) is truly 
accurate.

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

[b. f.]

Gabor:

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

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

Regards,
   b.

P.S. I hope that you have recovered from your influenza, and are
feeling better now.
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

ndisgen is broken (bsdgrep)

[Sergey V. Dyatko]

Hi, 

[ti...@laptop]~%which egrep
/usr/bin/egrep
[ti...@laptop]~%egrep --version
egrep (BSD grep) 2.5.1-FreeBSD

[ti...@laptop]~% fetch
http://tiger.ipfw.ru/files/rt3090_ndiswrapper.tar.gz
[ti...@laptop]~% tar xf rt3090_ndiswrapper.tar.gz
[ti...@laptop]~%cd rt3090_ndiswrapper/
[ti...@laptop]~/temp/rt3090_ndiswrapper%ndisgen rt2860.inf rt2860.sys

==
-- Windows(r) driver converter
---
==

INF file validation

I don't recognize this file format. It may not be a valid .INF
file.

Press enter to try again, or ^C to quit. 

with gnugrep all works fine...

[ti...@laptop]~%uname -a
FreeBSD laptop.minsk.domain 9.0-CURRENT FreeBSD 9.0-CURRENT #9
r211484M: Thu Aug 19 12:31:20 EEST 2010
r...@laptop.minsk.domain:/usr/obj/usr/src/sys/b450  i386

on another box (HEAD, amd64 r210780) same error

Thanks in advance

-- 
wbr, tiger
___
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

[Anton Shterenlikht]

On Thu, Aug 19, 2010 at 11:35:48AM +0200, Alexander Leidinger wrote:
> 
> Quoting Dag-Erling SmÃ??rgrav  (from Thu, 19 Aug 2010  
> 11:16:23 +0200):
> 
> > Alexander Leidinger  writes:
> >> If someone would get icc 11.x up and runnig as a port (similar to what
> >> we have for outdated icc version in the ports collection), I would
> >> have a look if my contact at Intel is still working there in a
> >> position which allows him to get a commercial license for us.
> >
> > Does that really matter?  We're not going to start building releases
> > with icc, are we?
> 
> It could matter for ports, I do not know if it matters for parts in  
> src. The commercial license is also the only way that we could get icc  
> installed on machines in the FreeBSD cluster (if there's interest to  
> have another compiler *for FreeBSD development* to check the source  
> against... the warnng and error messages are better that those of gcc,  
> I do not know how they compare to clang).

If one begins to mention FreeBSD clusters, and moreover FreeBSD HPC, then
this becomes a somewhat different discussion. One of the stubmling
blocks for HPC on FreeBSD (just one of many, perhaps not even the
major one) is a complete lack of good quality commercial compilers.
All weÃ'got is gcc or clang. Both are not really that great, and 
definitely inferior to commercial compilers, e.g. Intel. What IÃ'm
saying is that it would be great if Intel sold a compiler for FreeBSD.
I'd ve bought a copy. But from what others have said, my impression is that
the ICC port is unlikely to fill this void.

P.S. My interests and expertise are in computational mechanics, not in
compilers, so feel free to correct me if IÃ'm wrong.

P.P.S. Regarding FreeBSD HPC see also this thead:
 http://lists.freebsd.org/pipermail/freebsd-questions/2010-August/220264.html  
(FreeBSD, GPGPU and OpenCL/CUDA)


-- 
Anton Shterenlikht
Room 2.6, Queen's Building
Mech Eng Dept
Bristol University
University Walk, Bristol BS8 1TR, UK
Tel: +44 (0)117 331 5944
Fax: +44 (0)117 929 4423
___
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-19 18:42, David Xu wrote:
> When will the grep -H print file name for me ?  it is rather painful 
> that the feature is missing. :-(
> So I can not use it with find:
> 
> find . -exec grep -H {} world \;
> I don't know which file contains the word world.

I think you mean:

  find . -exec grep -H world {} \;

instead?  In any case, the fix is trivial, please try the attachment.
diff --git a/usr.bin/grep/grep.c b/usr.bin/grep/grep.c
index 3cb277c..cc710ef 100644
--- a/usr.bin/grep/grep.c
+++ b/usr.bin/grep/grep.c
@@ -682,8 +682,6 @@ main(int argc, char *argv[])
if (dirbehave == DIR_RECURSE)
c = grep_tree(aargv);
else {
-   if (aargc == 1)
-   hflag = true;
for (c = 0; aargc--; ++aargv) {
if ((finclude || fexclude) && !file_matching(*aargv))
continue;
___
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 16:59:50 - tinderbox 2.6 running on freebsd-current.sentex.ca
TB --- 2010-08-19 16:59:50 - starting HEAD tinderbox run for powerpc64/powerpc
TB --- 2010-08-19 16:59:50 - cleaning the object tree
TB --- 2010-08-19 17:00:31 - cvsupping the source tree
TB --- 2010-08-19 17:00:31 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca 
/tinderbox/HEAD/powerpc64/powerpc/supfile
TB --- 2010-08-19 17:01:45 - building world
TB --- 2010-08-19 17:01:45 - MAKEOBJDIRPREFIX=/obj
TB --- 2010-08-19 17:01:45 - PATH=/usr/bin:/usr/sbin:/bin:/sbin
TB --- 2010-08-19 17:01:45 - TARGET=powerpc
TB --- 2010-08-19 17:01:45 - TARGET_ARCH=powerpc64
TB --- 2010-08-19 17:01:45 - TZ=UTC
TB --- 2010-08-19 17:01:45 - __MAKE_CONF=/dev/null
TB --- 2010-08-19 17:01:45 - cd /src
TB --- 2010-08-19 17:01:45 - /usr/bin/make -B buildworld
>>> World build started on Thu Aug 19 17:01:46 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 18:40:01 UTC 2010
TB --- 2010-08-19 18:40:01 - generating LINT kernel config
TB --- 2010-08-19 18:40:01 - cd /src/sys/powerpc/conf
TB --- 2010-08-19 18:40:01 - /usr/bin/make -B LINT
TB --- 2010-08-19 18:40:01 - building LINT kernel
TB --- 2010-08-19 18:40:01 - MAKEOBJDIRPREFIX=/obj
TB --- 2010-08-19 18:40:01 - PATH=/usr/bin:/usr/sbin:/bin:/sbin
TB --- 2010-08-19 18:40:01 - TARGET=powerpc
TB --- 2010-08-19 18:40:01 - TARGET_ARCH=powerpc64
TB --- 2010-08-19 18:40:01 - TZ=UTC
TB --- 2010-08-19 18:40:01 - __MAKE_CONF=/dev/null
TB --- 2010-08-19 18:40:01 - cd /src
TB --- 2010-08-19 18:40:01 - /usr/bin/make -B buildkernel KERNCONF=LINT
>>> Kernel build for LINT started on Thu Aug 19 18:40:01 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/powerpc/fpu/fpu_emu.c: In function 'fpu_execute':
/src/sys/powerpc/fpu/fpu_emu.c:329: warning: format '%x' expects type 'unsigned 
int', but argument 3 has type 'long int'
/src/sys/powerpc/fpu/fpu_emu.c:329: warning: format '%x' expects type 'unsigned 
int', but argument 5 has type 'long int'
/src/sys/powerpc/fpu/fpu_emu.c:359: warning: format '%x' expects type 'unsigned 
int', but argument 3 has type 'long int'
/src/sys/powerpc/fpu/fpu_emu.c:359: warning: format '%x' expects type 'unsigned 
int', but argument 5 has type 'long int'
/src/sys/powerpc/fpu/fpu_emu.c:376: warning: format '%x' expects type 'unsigned 
int', but argument 3 has type 'long int'
/src/sys/powerpc/fpu/fpu_emu.c:376: warning: format '%x' expects type 'unsigned 
int', but argument 4 has type 'vm_offset_t'
/src/sys/powerpc/fpu/fpu_emu.c:778: warning: format '%x' expects type 'unsigned 
int', but argument 3 has type 'register_t'
*** 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 18:53:53 - WARNING: /usr/bin/make returned exit code  1 
TB --- 2010-08-19 18:53:53 - ERROR: failed to build lint kernel
TB --- 2010-08-19 18:53:53 - 4836.18 user 1209.40 system 6843.79 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: Removal of ICC (intel compiler) bits from mk

[Doug Barton]

I think sometimes we act as if code that is removed from the tree is 
gone forever, with no possibility of it ever returning. I don't 
understand this attitude. :)  If something is unsupported it should be 
removed, Q.E.D. There is no reason to think of possible reasons that we 
might want it to stay.


Meanwhile, FYI, ports/lang/icc7 has been marked DEPRECATED since 8/8 
with removal scheduled for 2010-09-01 based on the distinfo not 
containing a SHA256 line and (AFAICS) no distfiles available. If and 
only if someone wants to actively develop a newer version the old port 
will remain in the repo and can still be used as the basis of a repo 
copy to a newer version if that is necessary and/or desirable.



hth,

Doug

--

Improve the effectiveness of your Internet presence with
a domain name makeover!http://SupersetSolutions.com/

Computers are useless. They can only give you answers.
-- Pablo Picasso

___
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

[C. P. Ghost]

On Thu, Aug 19, 2010 at 7:22 PM, Bakul Shah  wrote:
> +1 for Scheme! It has a lot in its favor (see below).
>
> But this is an abstract discussion. Until there are plenty of
> useful system scripts (in one of these languages) that people
> really want, nothing is going to change.

Yes, it's abstract: I want my bikeshed named Gauche (lang/gauche): ;-)

http://practical-scheme.net/gauche/

But seriously, the point isn't so much which specific interpreter
we use (if we go down this road), it's about libraries: most
sysadmin tasks require some basic networking and I/O,
and a FFI to seamlessly call out C functions from .so libs.
Ideally a shell with a REPL loop, but even that isn't strictly
necessary for the scripts.

And, of course, instead of writing 1,001 sysadmin scripts
with endless code duplication and reinventing of the wheel,
common sysadmin tasks should also be made into reusable
functions, grouped into modules.

We're talking about a major task here, and no matter if it
will be in the base or as a port, it's something that will take
some time to emerge, so it's not a realistic option in the
short (or even middle) term.

> There is no reason to wait until something is in the base.
> And we don't have to argue about which language. I would
> suggest setting up a wiki page to list all the system scripts
> people want to write and get cracking in your favorite
> language! May the best effort win :-) At the very least we
> will get some useful tools out of this effort.  I will
> certainly help out with Scheme.

Funny idea. I only hope we won't end up with a typical
post-dot-com young developer distribution, a la:

  60% PHP (yuck!)
  25% Java (and XML-everywhere)
  15% ${OTHERS}

;-)

> Scheme has many interpreters & compilers so you can write
> Scheme scripts to be interpreted and at some point compile
> them for better performance if necessary. Scheme has some
> excellent text books, a precise definition for a given
> standard, it changes slowly, has IDEs and so on. If you stick
> to the R4RS subset, almost every scheme interprpter/compiler
> will handle it.  It has a very powerful macro facility.  Its
> interpreters can be very small. s9fes and tinyscheme for
> example are about 5K lines of C code each.  "Stalin" compiles
> Scheme to some extremely tight C code by doing global program
> analysis.  And there are many other systems in between.  slib
> is a library of a lot of useful packages that can be used
> with most Schemes.  Many of these interpreters can be used
> from C/C++.  Many provide a C-FFI to call C functions.
> Tinyscheme packages all of Scheme state in a single structure
> so one can easily create a separate Scheme interpreter per
> thread.  There is even a vi clone written in 4K lines s9fes
> Scheme!  Still beta but already useful.
>
> These many choices can be very confusing but we can pick one
> and stick to writing R4RS portable Scheme code.

Yes, but see above w.r.t. the needed library. And, again, it's
an academic discussion, as much as I'd love to do sysadmin
scripts in Scheme myself.

-cpghost.

-- 
Cordula's Web. http://www.cordula.ws/
___
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

[Doug Barton]

On 08/19/2010 04:13, Dag-Erling Smørgrav wrote:

It would have been far more "constructive and distinctively polite" to
take ten minutes to build and run a profiling version of grep, and
include the results in the OP.


Meta-comment first. des and I are both people of strong opinions, and we 
agree on more than we disagree on. I have no problem with him stating 
his opinion here, and I don't care if he agrees with me after I state 
mine. :)


There are 2 questions, did I do the right thing, and how should people 
report problems in general. As for myself, while I have some facility in 
C it's not my strong suit. Yes, I could have produced a profiling 
version of grep, but it would have taken me a lot more than 10 minutes 
because I don't even build the profiled libs on a regular basis. In this 
specific case I also didn't think it was "my job" to do so. Gabor is the 
one developing BSD grep, as far as I'm concerned it's up to him to get 
its performance up to par. I certainly have no objection to others 
helping him, and I'm glad that raising the issue of performance has 
resulted in more attention and assistance being directed at the problem. 
But I feel that I did my part by providing simple to reproduce test 
cases that Gabor could use.


More generally however I think that we need to be realistic with what we 
expect people to do about reporting problems. We WANT more "regular 
users" to use -current early on in the development cycle, and if they 
see problems to report them. Chastising people for not doing profiling 
runs of things that they are reporting problems with is not going to 
accomplish that goal.



Doug

--

Improve the effectiveness of your Internet presence with
a domain name makeover!http://SupersetSolutions.com/

Computers are useless. They can only give you answers.
-- Pablo Picasso

___
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

[Ulrich Spörlein]

On Thu, 19.08.2010 at 16:42:26 +, David Xu wrote:
> Gabor Kovesdan wrote:
> 
> > Yes, I'm sorry for my slow reaction, I got a flu some time ago and that 
> > prevented me from fixing the bugs earlier. I have several fixes in my 
> > working copy, which are being discussed with my mentor. Probably, today 
> > or tomorrow they will be committed.
> > 
> > Gabor
> > 
> 
> When will the grep -H print file name for me ?  it is rather painful 
> that the feature is missing. :-(
> So I can not use it with find:
> 
> find . -exec grep -H {} world \;
> I don't know which file contains the word world.

Workaround:

find . -exec grep word {} +

(yeah, not what you asked for ...)

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

Re: Runaway intr, not flash related

[Bjoern A. Zeeb]

On Thu, 19 Aug 2010, Doug Barton wrote:


On 08/19/2010 08:24, Andriy Gapon wrote:

I am sorry, but I don't see anything dramatically wrong here. So
"swi4: clock" uses 5.76% of WCPU, is that such a big deal to be
called "runaway intr"?


That's the symptom.


Have you ever posted a vmstat -i for when this actually happens?

/bz

--
Bjoern A. Zeeb   This signature is about you not me.
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: Runaway intr, not flash related

[Andriy Gapon]

on 19/08/2010 20:30 Doug Barton said the following:
> On 08/19/2010 08:24, Andriy Gapon wrote:
>> I am sorry, but I don't see anything dramatically wrong here. So
>> "swi4: clock" uses 5.76% of WCPU, is that such a big deal to be
>> called "runaway intr"?
> 
> That's the symptom.

OK, I see.

Perhaps you will find this message (and its ancestor thread) interesting:
http://lists.freebsd.org/pipermail/freebsd-hackers/2008-February/023447.html
I believe that your issue is different, but perhaps that stuff will inspire you 
to
use ktr(4) and schedgraph to properly debug this issue.  I strongly believe that
you have some sort of a scheduling issue and ktr seems to be the way to
investigate it.

Perhaps, you can first try the following dtrace script.
It should give a better view of what statclock sees, but I am not sure if that
information will be sufficient.
//
fbt::statclock:entry
/curthread->td_oncpu == 0/
{

@stacks0[stack()] = count();
counts0++;
}

fbt::statclock:entry
/curthread->td_oncpu == 1/
{

@stacks1[stack()] = count();
counts1++;
}

fbt::statclock:entry
{

@stacks[pid, tid, stack()] = count();
counts++;
}

END
{
printf("\n");
printf("* CPU 0:\n");
normalize(@stacks0, counts0 / 100);
trunc(@stacks0, 5);
printa("%...@u\n\n", @stacks0);

printf("\n\n");
printf("* CPU 1:\n");
normalize(@stacks1, counts1 / 100);
trunc(@stacks1, 5);
printa("%...@u\n\n", @stacks1);

printf("\n\n");
printf("* Top Processes:\n");
normalize(@stacks, counts / 200);
trunc(@stacks, 20);
printa(@stacks);
}
//
You would run this script when the problem hits, few seconds should be 
sufficient.
You may want to play with values in trunc() calls, you may also want to filter
gathered statistics (using conditions in /.../) by pid/tid if you spot anything
interesting unusual.

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

[Bakul Shah]

On Thu, 19 Aug 2010 18:00:54 +0200 "C. P. Ghost"   wrote:
> On Wed, Aug 18, 2010 at 3:43 PM, Andrew Reilly  wro=
> te:
> > 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). =A0You 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.
> 
> +1 for a scheme shell, but not for the heavy-weight variety that
> compiles to C, as that would tie them to a subset of ${ARCH}es.

+1 for Scheme! It has a lot in its favor (see below).

But this is an abstract discussion. Until there are plenty of
useful system scripts (in one of these languages) that people
really want, nothing is going to change.

There is no reason to wait until something is in the base.
And we don't have to argue about which language. I would
suggest setting up a wiki page to list all the system scripts
people want to write and get cracking in your favorite
language! May the best effort win :-) At the very least we
will get some useful tools out of this effort.  I will
certainly help out with Scheme.

-- bakul

Scheme has many interpreters & compilers so you can write
Scheme scripts to be interpreted and at some point compile
them for better performance if necessary. Scheme has some
excellent text books, a precise definition for a given
standard, it changes slowly, has IDEs and so on. If you stick
to the R4RS subset, almost every scheme interprpter/compiler
will handle it.  It has a very powerful macro facility.  Its
interpreters can be very small. s9fes and tinyscheme for
example are about 5K lines of C code each.  "Stalin" compiles
Scheme to some extremely tight C code by doing global program
analysis.  And there are many other systems in between.  slib
is a library of a lot of useful packages that can be used
with most Schemes.  Many of these interpreters can be used
from C/C++.  Many provide a C-FFI to call C functions.
Tinyscheme packages all of Scheme state in a single structure
so one can easily create a separate Scheme interpreter per
thread.  There is even a vi clone written in 4K lines s9fes
Scheme!  Still beta but already useful.

These many choices can be very confusing but we can pick one
and stick to writing R4RS portable Scheme code.
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: Runaway intr, not flash related

[Doug Barton]

On 08/19/2010 08:24, Andriy Gapon wrote:

I am sorry, but I don't see anything dramatically wrong here. So
"swi4: clock" uses 5.76% of WCPU, is that such a big deal to be
called "runaway intr"?


That's the symptom.


A lot of CPU time is idle and a lot is used by userland processes
(e.g. Xorg). Can you provide data that better illustrate your
problem?


The problem is that when this happens, the system becomes unusable. 
Videos stop playing, switching between windows takes more and more time, 
mail client is painfully slow, etc. If I leave the system alone when 
this starts happening the clock eventually consumes all CPU, the system 
freezes, or it crashes. Since the last 2 require a full fsck to recover 
from I tend to power down first. :)


BTW, something interesting happened the other day. I was having this 
problem over and over with the same hulu video, so I finally switched to 
windows in order to just finish watching it. After about 5 minutes 
watching the same show in windows the video started to stall just like 
it had in freebsd, but after about 5 seconds of that it "caught up" with 
itself, and I was able to watch the last 20 or so minutes without any 
problems.



Doug

--

Improve the effectiveness of your Internet presence with
a domain name makeover!http://SupersetSolutions.com/

Computers are useless. They can only give you answers.
-- Pablo Picasso

___
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

[Gabor PALI]

Folks,

Sorry for chiming in, just a quick idea.  If you find the "get a
high-level language that compiled to C" idea good, it might be worth
to take look at Feldspar [1].  It is about defining a domain-specific
language for a given domain (Digital Signal Processing) that compiles
to standard ISO C99.  It is an embedded language in Haskell (*), it
requires some research work from the side of implementation, but it
looks interesting to me.


:g

[1] http://feldspar.inf.elte.hu/feldspar/

(*) "A domain-specific language for writing compilers." :)
___
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

[Ivan Voras]

On 19/08/2010, C. P. Ghost  wrote:
> On Wed, Aug 18, 2010 at 3:43 PM, 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).
>>
>> Unfortunately it seems that quite a lot of people have issues
>> with lisp syntax these days.
>
> +1 for a scheme shell, but not for the heavy-weight variety that
> compiles to C, as that would tie them to a subset of ${ARCH}es.
>
> After all LISP-like syntax is *still* more common and prevalent
> than Lua, e.g. in Elisp, guile, esh, scsh and a lot of other apps
> that use it as a small language. So we can expect more users
> to be at least partially familiar with it. And there *are* lightweight
> MIT- or BSD-licensed scheme interpreters out there too:
>
> http://community.schemewiki.org/?scheme-faq-standards#implementations

Will have to disagree on that - part of the point of having such a
thing would be to attract young developers, and while the CS crowd
will be happy with LISP, anyone starting programming after the first
.com bubble will probably be repulsed by non-Algol-like syntaxes.
___
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

[C. P. Ghost]

On Wed, Aug 18, 2010 at 3:43 PM, 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).
>
> Unfortunately it seems that quite a lot of people have issues
> with lisp syntax these days.

+1 for a scheme shell, but not for the heavy-weight variety that
compiles to C, as that would tie them to a subset of ${ARCH}es.

After all LISP-like syntax is *still* more common and prevalent
than Lua, e.g. in Elisp, guile, esh, scsh and a lot of other apps
that use it as a small language. So we can expect more users
to be at least partially familiar with it. And there *are* lightweight
MIT- or BSD-licensed scheme interpreters out there too:

http://community.schemewiki.org/?scheme-faq-standards#implementations

-cpghost.

-- 
Cordula's Web. http://www.cordula.ws/
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: [head tinderbox] failure on powerpc64/powerpc

[Nathan Whitehorn]

On 08/19/10 01:40, Dag-Erling Smørgrav wrote:

FreeBSD Tinderbox  writes:
   

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.
 

Line 705 in ofw_standard.c is

return ((void *)args.baseaddr);

args.baseaddr is a cell_t, which is defined in:

typedef uint32_tcell_t;

which I assume is correct for powerpc (32-bits), but probably not for
powerpc64.  Note that it is defined as uint64_t on sparc64 and sun4v,
and in sys/boot as unsigned long int, which is the correct size on both
32-bit and 64-bit machines (assuming I32LP64).
   


The problem is that until yesterday, you could not build a powerpc64 
LINT, and so it was trying to build a PPC32 kernel with a 64-bit 
toolchain. An actual powerpc64 kernel does not include ofw_standard.c. 
This should be fixed now with r211483, so long as the LINT config is 
made with TARGET_ARCH set (and is not reused for 32 and 64-bit builds). 
There is a seat-belt mechanism I should add soon that will complain 
earlier about architecture mismatches like this. Thanks for your patience.

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

[Alan Cox]

Dimitry Andric wrote:

On 2010-08-17 23:24, Alan Cox wrote:
  

So normal mmap is ~3% slower, and prefault mmap does not seem to make
any measurable difference.  I guess the added complexity is not really
worth it, for now.
  

Do you know what fraction of this time is being spent in the kernel?



I ran 100 trials again, but now using "time -a -o logfile", so I could
run ministat over the accumulated results.  This gives:

x gnugrep
+ bsdgrep-r210927 (the initial version that started this thread)
* bsdgrep-r211490 (current version)
% bsdgrep-r211490-mmap-plain
# bsdgrep-r211490-mmap-prefault

Real time:
N   Min   MaxMedian   AvgStddev
x 100  1.15  1.98  1.181.21220.11159613
+ 100  8.57 14.26  8.799.1823 1.0496126
* 100  2.81  6.57  2.913.0189 0.4304259
% 100  2.34  4.03  2.993.00220.12635992
# 100  2.85  3.49  2.882.8981   0.075232904

User time:
N   Min   MaxMedian   AvgStddev
x 100 0  0.07  0.030.0239   0.015627934
+ 100   1.6  3.33   1.9 1.9760.30264824
* 100  0.29 1  0.390.40040.08696824
% 100   1.8  3.56  2.732.72740.13260117
# 100  2.78  3.04  2.812.82380.04039652

System time:
N   Min   MaxMedian   AvgStddev
x 100  1.08  1.91  1.151.18090.10953617
+ 100  6.55  10.9  6.947.19050.77911809
* 100  2.38   5.5  2.532.60610.35068445
% 100  0.18  0.53  0.250.2645   0.053586049
# 100  0.03  0.54  0.060.0668   0.052259647

E.g. it looks like bsdgrep with 'plain' mmap performs almost the same
as the regular bsdgrep (both around 3.0s average), but with mmap much
more of the time is spent in user mode.

  


That makes sense to me.  With traditional I/O, such as read(2), the 
copyout to user space fills the  processor's data cache with the data to 
be processed.  Grep's core algorithm in user space shouldn't be 
experiencing cache misses to obtain the data.  By and large, the cache 
misses will have occurred in the kernel.  However, once you switch to 
mmap(2), the kernel never touches the data, and all cache misses occur 
in user space.  You ought to be able to confirm this with pmcstat's 
sampling mode set to sample L2 cache misses.


Here is what actually puzzles me about these results.  With traditional 
I/O, even after the optimizations to bsdgrep, the system time for 
gnugrep is still less than half that of the optimized bsdgrep.  I 
haven't looked at the changes, but I would have thought the system time 
for gnugrep and bsdgrep would be almost the same.



And it seems prefaulting does help now!  I guess it also makes sense to
add madvise(..., MADV_SEQUENTIAL)?

  


This won't matter as long as you are working with memory resident 
files.  With a memory resident file, it would only be a waste of cycles.


  

Does
the value of "sysctl vm.pmap.pde.mappings" increase as a result of your
test?  If not, there is still room for improvement in the results with
mmap().



It always stays at 0, I have never seen any other value.
  


Addressing this issue would mostly affect the system time, which is 
already tiny for mmap-prefault, so I wouldn't be concerned about this (yet).


Did you ever describe your test machine?  If so, I'm sorry, but I missed 
that.  Is it running an amd64 or i386 kernel?  Can you briefly describe 
what kind of processor and memory it has?


Regards,
Alan

___
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

[Tijl Coosemans]

On Thursday 19 August 2010 15:38:54 Dag-Erling Smørgrav wrote:
> Gabor Kovesdan  writes:
>> 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.
> 
> Not quite, as Doug pointed out.  I don't know what benchmark you're
> using, but I'm using a greatly simplified variant of Doug's:
> 
> % time sh -c 'for n in $(jot 1000) ; do /usr/obj/usr/src/usr.bin/grep/grep -q 
> "^xfce4-wm" /usr/ports/INDEX-9 ; done'
> sh -c   13.57s user 7.06s system 99% cpu 20.783 total
> % time sh -c 'for n in $(jot 1000) ; do 
> /usr/obj/usr/src/gnu/usr.bin/grep/grep -q "^xfce4-wm" /usr/ports/INDEX-9 ; 
> done'
> sh -c   7.98s user 7.47s system 100% cpu 15.424 total
> 
> The bottleneck is now in quite an unexpected location:
> 
>   %   cumulative   self  self total   
>  time   seconds   secondscalls  ms/call  ms/call  name
>  38.8   0.03 0.0312717 0.00 0.00  memchr [5]
>  35.6   0.07 0.03  395 0.08 0.08  _read [6]
>  16.4   0.08 0.010  100.00%   _mcount [7]
>   1.7   0.08 0.0012362 0.00 0.00  memset [9]
>   1.5   0.08 0.000  100.00%   .mcount (110)
>   1.5   0.08 0.000   43.41%   re_search_internal [8]
>   0.8   0.08 0.00  820 0.00 0.00  memcpy [12]
>   0.6   0.09 0.0037045 0.00 0.00  free [13]
>   0.6   0.09 0.0012332 0.00 0.01  grep_fgetln [4]
>   0.6   0.09 0.001 0.4966.27  procfile [3]
>   0.4   0.09 0.000  100.00%   
> re_string_construct_common [26]
>   0.3   0.09 0.001 0.25 0.34  _Read_RuneMagi [27]
>   0.1   0.09 0.00  261 0.00 0.00  arena_avail_comp [39]
>   0.1   0.09 0.00  155 0.00 0.00  arena_malloc [24]
>   0.1   0.09 0.00  153 0.00 0.00  arena_bin_malloc_easy 
> [40]
>   0.1   0.09 0.00   54 0.00 0.00  arena_avail_tree_insert 
> [35]
>   0.1   0.09 0.005 0.02 0.02  arena_purge [37]
>   0.1   0.09 0.003 0.04 0.44  setlocale [10]
>   0.1   0.09 0.001 0.12 0.46  __wrap_setrunelocale 
> [21]
>   0.1   0.09 0.000   21.76%   re_string_destruct [14]
>   0.1   0.09 0.000  100.00%   regexec [38]
> 
> The culprit seems to be the first memchr() in grep_fgetln().  For some
> reason, even with -O2, it is not inlined:
> 
> % echo "disassemble grep_fgetln" | gdb -q -batch -x /dev/stdin 
> /usr/obj/usr/src/usr.bin/grep/grep | grep memchr
> 0x0040291e : callq  0x40176c 
> 0x004029fa : callq  0x40176c 

The base system gcc doesn't have a built-in version of memchr to inline.


signature.asc
Description: This is a digitally signed message part.

Re: Runaway intr, not flash related

[Andriy Gapon]

on 12/08/2010 23:57 Doug Barton said the following:
> My "runaway intr" problem with flash has been continuing all along, but
> since no one has been interested in helping with it I haven't reported
> it for a while. However, today, for the first time, it happened when I
> had not run flash at all since I booted.
> 
> My system:
> Dell D620, C2D, i386, SMP, r210908
> 
> swi4: clock is the culprit again this time, but when flash triggers this
> problem I sometimes see hdac as the culprit, FYI.
> 
> 
> last pid: 19763;  load averages:  1.05,  1.40,  1.18up 0+01:58:20 
> 13:41:19
> 129 processes: 3 running, 106 sleeping, 20 waiting
> CPU 0: 20.8% user,  0.0% nice,  6.9% system,  8.5% interrupt, 63.8% idle
> CPU 1: 56.9% user,  0.0% nice,  8.5% system,  1.5% interrupt, 33.1% idle
> Mem: 182M Active, 1279M Inact, 187M Wired, 18M Cache, 112M Buf, 334M Free
> Swap: 1024M Total, 1024M Free
> 
>   PID USERNAME   PRI NICE   SIZERES STATE   C   TIME   WCPU COMMAND
>10 root   171 ki31 0K16K RUN 1  87:55 63.72% {idle:
> cpu1}
>10 root   171 ki31 0K16K RUN 0  88:03 60.69% {idle:
> cpu0}
>  1621 dougb  1020   162M   141M select  0  14:19 29.54% Xorg
>11 root   -32- 0K   160K WAIT0   0:33  5.76% {swi4:
> clock}
>  1668 dougb   970 36808K 20864K select  0   0:38  3.61% {initial
> thread
>  1692 dougb80 11136K  2284K nanslp  0   2:13  2.15% wmwlmon
> 19763 dougb   960  9912K  2076K CPU11   0:01  1.57% top
>17 root96- 0K 8K syncer  1   0:48  1.17% syncer
>  1684 dougb   960 11020K  2108K select  1   1:10  1.12% wmbsdbatt
>  1762 dougb   960 36284K 15540K select  0   0:04  0.39% {initial
> thread
>11 root   -64- 0K   160K WAIT0   0:03  0.15% {irq22:
> uhci2}
>   783 root960  9684K  1232K select  0   0:21  0.10% moused
>  1663 dougb   960 21388K  8912K select  1   0:15  0.10% openbox
>11 root   -32- 0K   160K WAIT1   0:17  0.05% {swi4:
> clock}
>  1817 dougb   960 90820K 53672K select  0   3:23  0.00% {initial
> thread
> 0 root   -160 0K64K sched   0   0:26  0.00% {swapper}

I am sorry, but I don't see anything dramatically wrong here.
So "swi4: clock" uses 5.76% of WCPU, is that such a big deal to be called 
"runaway
intr"?
A lot of CPU time is idle and a lot is used by userland processes (e.g. Xorg).
Can you provide data that better illustrate your problem?

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

[Dimitry Andric]

On 2010-08-17 23:24, Alan Cox wrote:
>> So normal mmap is ~3% slower, and prefault mmap does not seem to make
>> any measurable difference.  I guess the added complexity is not really
>> worth it, for now.
> 
> Do you know what fraction of this time is being spent in the kernel?

I ran 100 trials again, but now using "time -a -o logfile", so I could
run ministat over the accumulated results.  This gives:

x gnugrep
+ bsdgrep-r210927 (the initial version that started this thread)
* bsdgrep-r211490 (current version)
% bsdgrep-r211490-mmap-plain
# bsdgrep-r211490-mmap-prefault

Real time:
N   Min   MaxMedian   AvgStddev
x 100  1.15  1.98  1.181.21220.11159613
+ 100  8.57 14.26  8.799.1823 1.0496126
* 100  2.81  6.57  2.913.0189 0.4304259
% 100  2.34  4.03  2.993.00220.12635992
# 100  2.85  3.49  2.882.8981   0.075232904

User time:
N   Min   MaxMedian   AvgStddev
x 100 0  0.07  0.030.0239   0.015627934
+ 100   1.6  3.33   1.9 1.9760.30264824
* 100  0.29 1  0.390.40040.08696824
% 100   1.8  3.56  2.732.72740.13260117
# 100  2.78  3.04  2.812.82380.04039652

System time:
N   Min   MaxMedian   AvgStddev
x 100  1.08  1.91  1.151.18090.10953617
+ 100  6.55  10.9  6.947.19050.77911809
* 100  2.38   5.5  2.532.60610.35068445
% 100  0.18  0.53  0.250.2645   0.053586049
# 100  0.03  0.54  0.060.0668   0.052259647

E.g. it looks like bsdgrep with 'plain' mmap performs almost the same
as the regular bsdgrep (both around 3.0s average), but with mmap much
more of the time is spent in user mode.

And it seems prefaulting does help now!  I guess it also makes sense to
add madvise(..., MADV_SEQUENTIAL)?


> Does
> the value of "sysctl vm.pmap.pde.mappings" increase as a result of your
> test?  If not, there is still room for improvement in the results with
> mmap().

It always stays at 0, I have never seen any other value.
___
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

[Dag-Erling Smørgrav]

Gabor Kovesdan  writes:
> 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.

Not quite, as Doug pointed out.  I don't know what benchmark you're
using, but I'm using a greatly simplified variant of Doug's:

% time sh -c 'for n in $(jot 1000) ; do /usr/obj/usr/src/usr.bin/grep/grep -q 
"^xfce4-wm" /usr/ports/INDEX-9 ; done' 
sh -c   13.57s user 7.06s system 99% cpu 20.783 total
% time sh -c 'for n in $(jot 1000) ; do /usr/obj/usr/src/gnu/usr.bin/grep/grep 
-q "^xfce4-wm" /usr/ports/INDEX-9 ; done'
sh -c   7.98s user 7.47s system 100% cpu 15.424 total

The bottleneck is now in quite an unexpected location:

  %   cumulative   self  self total   
 time   seconds   secondscalls  ms/call  ms/call  name
 38.8   0.03 0.0312717 0.00 0.00  memchr [5]
 35.6   0.07 0.03  395 0.08 0.08  _read [6]
 16.4   0.08 0.010  100.00%   _mcount [7]
  1.7   0.08 0.0012362 0.00 0.00  memset [9]
  1.5   0.08 0.000  100.00%   .mcount (110)
  1.5   0.08 0.000   43.41%   re_search_internal [8]
  0.8   0.08 0.00  820 0.00 0.00  memcpy [12]
  0.6   0.09 0.0037045 0.00 0.00  free [13]
  0.6   0.09 0.0012332 0.00 0.01  grep_fgetln [4]
  0.6   0.09 0.001 0.4966.27  procfile [3]
  0.4   0.09 0.000  100.00%   
re_string_construct_common [26]
  0.3   0.09 0.001 0.25 0.34  _Read_RuneMagi [27]
  0.1   0.09 0.00  261 0.00 0.00  arena_avail_comp [39]
  0.1   0.09 0.00  155 0.00 0.00  arena_malloc [24]
  0.1   0.09 0.00  153 0.00 0.00  arena_bin_malloc_easy [40]
  0.1   0.09 0.00   54 0.00 0.00  arena_avail_tree_insert 
[35]
  0.1   0.09 0.005 0.02 0.02  arena_purge [37]
  0.1   0.09 0.003 0.04 0.44  setlocale [10]
  0.1   0.09 0.001 0.12 0.46  __wrap_setrunelocale [21]
  0.1   0.09 0.000   21.76%   re_string_destruct [14]
  0.1   0.09 0.000  100.00%   regexec [38]

The culprit seems to be the first memchr() in grep_fgetln().  For some
reason, even with -O2, it is not inlined:

% echo "disassemble grep_fgetln" | gdb -q -batch -x /dev/stdin 
/usr/obj/usr/src/usr.bin/grep/grep | grep memchr
0x0040291e :   callq  0x40176c 
0x004029fa :   callq  0x40176c 

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

[John Baldwin]

On Thursday, August 19, 2010 5:29:25 am pluknet wrote:
> On 19 August 2010 00:07, John Baldwin  wrote:
> > 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.
> 
> Thanks for your suggestions.
> 
> So I converted nfs_nfsiodnew_tq() into loop, and as such
> I changed a cleanup SLIST_FOREACH() as well to free a bulk of
> (potentially consolidated) completed requests in one pass.
> kproc_create() is still out of the SLIST_FOREACH() to avoid calling it
> with nfs_iod_mtx held.
> 
> >
> > -   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.
> 
> Err.. that's resulted after a set of changes. Thanks for noting that.
> 
> >
> > 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.
> >
> 
> I put taskqueue_drain() right after taskqueue_enqueue() to be in sync with
> task handler. That was part to think about, as I didn't find such a use 
> pattern.
> It seems though that tasks are launched now strictly one-by-one, without
> visible parallelism (as far as debug printf()s don't overlap anymore).

Ah, if it is safe to sleep then I have a couple of suggestions:

- Use M_WAITOK to malloc() so you don't have to worry about the failure case
  (I see Rick already suggested this).

- Use something like this in the code that schedules the task:

mtx_unlock(&nfs_iod_mtx);
nip = malloc(..., M_WAITOK);
/* Initialize nip. */
mtx_lock(&nfs_iod_mtx);
SLIST_INSERT_HEAD(...); /* Maybe use STAILQ_INSERT_TAIL() instead? */
taskqueue_enqueue(...);
while (!nip->done)
mtx_sleep(nip, &nfs_iod_mtx, ...);
mtx_unlock(&nfs_iod_mtx);
error = nip->ni_error;
free(nip);
/* Existing if (error), etc. code */

and something like this in the task handler:

mtx_lock(&nfs_iod_mtx);
while ((nip = STAILQ_FIRST(...)) != NULL) {
STAILQ_REMOVE_HEAD(...);
mtx_unlock(&nfs_iod_mtx);
/* Create thread, setting ni_error, etc. */
mtx_lock(&nfsd_iod_mtx);
wakeup(nip);
}
mtx_unlock(&nfs_iod_mtx);

The sleep/wakeup pattern is far more common than using taskqueue_drain() for
this sort of thing.  Using STAILQ instead of SLIST would give you "fairer"
FIFO processing btw.

-- 
John Baldwin
__

Re: Official request: Please make GNU grep the default

[John Baldwin]

On Wednesday, August 18, 2010 5:54:41 pm Dimitry Andric wrote:
> 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?

You need the distribution, not just the averages so you can detect outliers 
and determine the standard deviation and confidence intervals.  You could use 
ministat on a file that contained all 100 runtimes perhaps.  I would use at 
least 10 trials though, 3 is a bit small.

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

[Matthias Andree]

Am 19.08.2010 11:35, schrieb Alexander Leidinger:
> 
> Quoting Dag-Erling Smørgrav  (from Thu, 19 Aug 2010  
> 11:16:23 +0200):
> 
>> Alexander Leidinger  writes:
>>> If someone would get icc 11.x up and runnig as a port (similar to what
>>> we have for outdated icc version in the ports collection), I would
>>> have a look if my contact at Intel is still working there in a
>>> position which allows him to get a commercial license for us.
>>
>> Does that really matter?  We're not going to start building releases
>> with icc, are we?
> 
> It could matter for ports, I do not know if it matters for parts in  
> src. The commercial license is also the only way that we could get icc  
> installed on machines in the FreeBSD cluster (if there's interest to  
> have another compiler *for FreeBSD development* to check the source  
> against... the warnng and error messages are better that those of gcc,  
> I do not know how they compare to clang).

Clang is a mixed experience. I've used it only for C so far, and there are some
code issues that it doesn't check at all yet; issues that GCC or ICC would
complain about. ICC11 warnings (I've only used it on Linux for the software
where I'm upstream maintainer) seem plentiful if you request remarks, too.

However, clang diagnostics are easier to understand than GCCs and usually more
helpful - which was a design goal.

Note that devel/clang ships with a static analyzer that should now finally work,
as of clang-2.7_2. It can trace call trees back and pinpoint how, for instance,
your code forgets to check NULL dereference, where there are dead
initializations or assignments, or similar.  I found it to be a bit more solid
than GCC in my use cases, but note it's advertised as work-in-progress.
Details/Usage: http://clang-analyzer.llvm.org/scan-build.html

-- 
Matthias Andree
___
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

[Andrew Milton]

+---[ V. T. Mueller, Continum ]--
| 
| In other words: as long as there are unresolved issues, the default 
| should be set to GNU grep. This doesn't stop anyone from improving the 
| BSD grep we're all waiting for. It only does good to those who rely on 
| using grep - expecting correctness and speed.

When did -current become -stable?

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

[Dag-Erling Smørgrav]

"V. T. Mueller, Continum"  writes:
> Dag-Erling Smørgrav  writes:
> > Based on my 12 years of experience in this project, you are very,
> > very wrong.
> An 'argumentation' like the above is simply a killer phrase that ends
> every discussion.

An 'argumentation' like the above is simply a killer phrase that ends
every discussion, especially when it's based on selective quoting.
Here's what you left out:

  > I would also second, that changing back the default immediately then
  > would have been the better choice.
  No, it would only have ensured that nobody except Gabor used it.

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

[V. T. Mueller, Continum]

Dag-Erling Smørgrav wrote:

In other words: as long as there are unresolved issues, the default
should be set to GNU grep. This doesn't stop anyone from improving the
BSD grep we're all waiting for. It only does good to those who rely on
using grep - expecting correctness and speed.


Based on my 12 years of experience in this project, you are very, very
wrong.


An 'argumentation' like the above is simply a killer phrase that ends 
every discussion.
OTOH, absence of valid argumentation doesn't necessarily mean that your 
statement has to be wrong.
I'm always willing to learn. Since you've also tried to correct me about 
constructive and polite behaviour - might I suggest that you add a few 
words about what is right in your opinion, when telling folks they are 
wrong? This would add to both, I guess.


Cheers
vt

--
Volker T. Mueller
Continum AG
Bismarckallee 7d
79098 Freiburg i. Br.
Tel. +49 761 21711171
Fax. +49 761 21711198
http://www.continum.net

Sitz der Gesellschaft: Freiburg im Breisgau
Registergericht: Amtsgericht Freiburg, HRB 6866
Vorstand: Rolf Mathis, Volker T. Mueller
Vorsitzender d. Aufsichtsrats: Prof. Dr. Karl-F. Fischbach

___
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

[Dag-Erling Smørgrav]

"V. T. Mueller, Continum"  writes:
> If you're alluding to Dougs original email, I will strictly disagree.
> He found a performance issue which noone had seen or brought up before
> and gave feedback to Gabor in a constructive and distinctively polite
> manner.

It would have been far more "constructive and distinctively polite" to
take ten minutes to build and run a profiling version of grep, and
include the results in the OP.

> I would also second, that changing back the default immediately then
> would have been the better choice.

No, it would only have ensured that nobody except Gabor used it.

> In other words: as long as there are unresolved issues, the default
> should be set to GNU grep. This doesn't stop anyone from improving the
> BSD grep we're all waiting for. It only does good to those who rely on
> using grep - expecting correctness and speed.

Based on my 12 years of experience in this project, you are very, very
wrong.

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

[V. T. Mueller, Continum]

Dag-Erling Smørgrav wrote:

There is a lesson here: people who are unsatisfied with the performance
of ${TOOL} should profile it before they start a flamefest on -current.


If you're alluding to Dougs original email, I will strictly disagree.
He found a performance issue which noone had seen or brought up before 
and gave feedback to Gabor in a constructive and distinctively polite 
manner.


I would also second, that changing back the default immediately then 
would have been the better choice.


That others supported Gabor in doing profiling and suggesting 
improvements is a fine thing, and contributes to what makes this 
community stand out from others.


In other words: as long as there are unresolved issues, the default 
should be set to GNU grep. This doesn't stop anyone from improving the 
BSD grep we're all waiting for. It only does good to those who rely on 
using grep - expecting correctness and speed.


My $0.02
vt

--
Volker T. Mueller
Continum AG
Bismarckallee 7d
79098 Freiburg i. Br.
Tel. +49 761 21711171
Fax. +49 761 21711198
http://www.continum.net

Sitz der Gesellschaft: Freiburg im Breisgau
Registergericht: Amtsgericht Freiburg, HRB 6866
Vorstand: Rolf Mathis, Volker T. Mueller
Vorsitzender d. Aufsichtsrats: Prof. Dr. Karl-F. Fischbach

___
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

[Stein Morten Sandbech]

Hi,

GNU grep is OK.  However standard BSD grep also work:

find . -exec grep -i world {} /dev/null \;

or even:

find . -exec grep -in world {} /dev/null \;

if you want linenumbers ...

hth

Stein Morten



On Aug 19, 2010, at 11:29, freebsd-current-requ...@freebsd.org wrote:

> Date: Thu, 19 Aug 2010 16:42:26 +
> From: David Xu 
> Subject: Re: Official request: Please make GNU grep the default
> To: Gabor Kovesdan 
> Cc: delp...@freebsd.org, Andrey Chernov ,  Doug
>   Barton , c...@freebsd.org, curr...@freebsd.org
> Message-ID: <4c6d5ef2.2040...@freebsd.org>
> Content-Type: text/plain; charset=ISO-8859-1; format=flowed
> 
> Gabor Kovesdan wrote:
> 
>> Yes, I'm sorry for my slow reaction, I got a flu some time ago and that 
>> prevented me from fixing the bugs earlier. I have several fixes in my 
>> working copy, which are being discussed with my mentor. Probably, today 
>> or tomorrow they will be committed.
>> 
>> Gabor
>> 
> 
> When will the grep -H print file name for me ?  it is rather painful 
> that the feature is missing. :-(
> So I can not use it with find:
> 
> find . -exec grep -H {} world \;
> I don't know which file contains the word world.
> 
> Regards,
> David Xu

___
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, Alexander Best wrote:
> 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".

this seems to have been fixed by switching to `zcat -f`. thanks a lot. :)

i guess gnu/4419 can be closed once your script enters the tree.

cheers.
alex

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

-- 
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: STABLE kernel panic: privileged instruction fault

[Alexey Tarasov]

Hello Andriy!


On Aug 18, 2010, at 7:30 PM, Andriy Gapon wrote:

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

We have the similar discussion with Kostik Belousov here:
http://lists.freebsd.org/pipermail/freebsd-stable/2010-August/058287.html

I'm installing new kernel with DDB on the servers now and waiting for the panic.

Thank you for your reply!

--
Alexey Tarasov

(\__/) 
(='.'=) 
E[: | | | | :]З 
(")_(")

___
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

[Alexander Leidinger]

Quoting "V. T. Mueller, Continum"  (from  
Thu, 19 Aug 2010 11:15:19 +0200):



Alexander Leidinger wrote:

Alexander Leidinger wrote:
If someone would get icc 11.x up and runnig as a port (similar to  
what we have for outdated icc version in the ports collection), I  
would have a look if my contact at Intel is still working there  
in a position which allows him to get a commercial license for us.


A while ago it was stated by MySQL AB, that their dbms performs  
about 20% better when compiled with icc instead of gcc. Is this  
(still) true?


This looks overly simplified. "It runs better on CPU X with  
benchmark Y on Mainboard Z when you use gcc A.B.C with options D  
and compare it to icc E.F.G with options H." is something you can  
use in such cases, but it doesn't tell you if it will be the case  
on your machines with your workload.


If you want to know if it is faster on your machines with your  
workload, then there is only one way to find it out: try it (be  
warned, due to the amount of optimization options available in  
gcc/icc, something like this will take a lot of time, as there are  
a lot of combinations to try).


Sounds reasonable. But doesn't that mean, that there is no need to  
(take the hassle to) support icc in the future? Especially while  
folks are being keen on abandon gcc for clang?


It may matter in the HPC community where optimization to a specific  
CPU matters (it doesn't matter that much for MySQL). There it does not  
matter much to have the kernel compiled with icc, but a icc port would  
be handy for them.


Bye,
Alexander.

--
I hold it, that a little rebellion, now and then, is a good thing...
-- Thomas Jefferson

http://www.Leidinger.netAlexander @ Leidinger.net: PGP ID = B0063FE7
http://www.FreeBSD.org   netchild @ FreeBSD.org  : PGP ID = 72077137
___
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

[Alexander Leidinger]

Quoting Dag-Erling Smørgrav  (from Thu, 19 Aug 2010  
11:16:23 +0200):



Alexander Leidinger  writes:

If someone would get icc 11.x up and runnig as a port (similar to what
we have for outdated icc version in the ports collection), I would
have a look if my contact at Intel is still working there in a
position which allows him to get a commercial license for us.


Does that really matter?  We're not going to start building releases
with icc, are we?


It could matter for ports, I do not know if it matters for parts in  
src. The commercial license is also the only way that we could get icc  
installed on machines in the FreeBSD cluster (if there's interest to  
have another compiler *for FreeBSD development* to check the source  
against... the warnng and error messages are better that those of gcc,  
I do not know how they compare to clang).


Bye,
Alexander.

--
 Fry: I'm not a robot like you. I don't like having disks crammed
 into me... unless they're Oreos, and then only in the mouth.

http://www.Leidinger.netAlexander @ Leidinger.net: PGP ID = B0063FE7
http://www.FreeBSD.org   netchild @ FreeBSD.org  : PGP ID = 72077137
___
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 19 August 2010 04:04, Rick Macklem  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.
>> >
>>
> 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

Nice :)

I need to step back and get a timeout
to re-think how to use this technique.

-- 
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 19 August 2010 00:07, John Baldwin  wrote:
> 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.

Thanks for your suggestions.

So I converted nfs_nfsiodnew_tq() into loop, and as such
I changed a cleanup SLIST_FOREACH() as well to free a bulk of
(potentially consolidated) completed requests in one pass.
kproc_create() is still out of the SLIST_FOREACH() to avoid calling it
with nfs_iod_mtx held.

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

Err.. that's resulted after a set of changes. Thanks for noting that.

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

I put taskqueue_drain() right after taskqueue_enqueue() to be in sync with
task handler. That was part to think about, as I didn't find such a use pattern.
It seems though that tasks are launched now strictly one-by-one, without
visible parallelism (as far as debug printf()s don't overlap anymore).

-- 
wbr,
pluknet


nfsiod_tq_lock.2.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: BSD grep performance

[Dag-Erling Smørgrav]

Doug Barton  writes:
> 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.

"This is madness!"
"Madness?  This...  is...  CURRENT!"

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

[Dag-Erling Smørgrav]

"M. Warner Losh"  writes:
> 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.

There is a lesson here: people who are unsatisfied with the performance
of ${TOOL} should profile it before they start a flamefest on -current.

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

[Dag-Erling Smørgrav]

Alexander Leidinger  writes:
> If someone would get icc 11.x up and runnig as a port (similar to what
> we have for outdated icc version in the ports collection), I would
> have a look if my contact at Intel is still working there in a
> position which allows him to get a commercial license for us.

Does that really matter?  We're not going to start building releases
with icc, are we?

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

[V. T. Mueller, Continum]

Alexander Leidinger wrote:

Alexander Leidinger wrote:
If someone would get icc 11.x up and runnig as a port (similar to 
what we have for outdated icc version in the ports collection), I 
would have a look if my contact at Intel is still working there in a 
position which allows him to get a commercial license for us.


A while ago it was stated by MySQL AB, that their dbms performs about 
20% better when compiled with icc instead of gcc. Is this (still) true?


This looks overly simplified. "It runs better on CPU X with benchmark Y 
on Mainboard Z when you use gcc A.B.C with options D and compare it to 
icc E.F.G with options H." is something you can use in such cases, but 
it doesn't tell you if it will be the case on your machines with your 
workload.


If you want to know if it is faster on your machines with your workload, 
then there is only one way to find it out: try it (be warned, due to the 
amount of optimization options available in gcc/icc, something like this 
will take a lot of time, as there are a lot of combinations to try).


Sounds reasonable. But doesn't that mean, that there is no need to (take 
the hassle to) support icc in the future? Especially while folks are 
being keen on abandon gcc for clang?


Cheers
vt
--
Volker T. Mueller
Continum AG
Bismarckallee 7d
79098 Freiburg i. Br.
Tel. +49 761 21711171
Fax. +49 761 21711198
http://www.continum.net

Sitz der Gesellschaft: Freiburg im Breisgau
Registergericht: Amtsgericht Freiburg, HRB 6866
Vorstand: Rolf Mathis, Volker T. Mueller
Vorsitzender d. Aufsichtsrats: Prof. Dr. Karl-F. Fischbach

___
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

[Dag-Erling Smørgrav]

Luigi Rizzo  writes:
> 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)

Actually, the GPL requires that you provide the source in a buildable
condition (even if you only ship patches), and most mid-to-high-end AV
equipment these days will load and run (or flash) software from a USB
mass storage device or CD / DVD.  That's certainly the case for my Sony
Bravia TV (http://products.sel.sony.com/opensource/source_bivl.shtml)
and my NAD Bluray player (not Linux, AFAIK).

Furthermore, the GPLv3 forbids the use of GPLv3 software on devices that
can't be flashed by the user (the "TiVo clause"), although the bits that
are most commonly used in embedded devices (Linux itself and busybox)
are still under GPLv2.

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

[Steven Hartland]

Out of interest I tried the first test here add ack into the mix we
I've grown to like as a developer as it uses some nice sensible
defaults for every day use avoiding svn etc.

Its a pure perl app so wasn't expecting it to be particularly quick
in the single file case, its much quicker in the multi file case, but it
seems to do quite well.

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

GNU grep 2.5.1-FreeBSD (base on 8.1-RELEASE)
Elapsed time: 2 seconds

BSD grep ( from ports 2.5.1 )
Elapsed time: 48 seconds

ack 1.92 ( perl 5.8.9 )
Elapsed time: 4 seconds

   Regards
   Steve


This e.mail is private and confidential between Multiplay (UK) Ltd. and the person or entity to whom it is addressed. In the event of misdirection, the recipient is prohibited from using, copying, printing or otherwise disseminating it or any information contained in it. 


In the event of misdirection, illegible or incomplete transmission please 
telephone +44 845 868 1337
or return the E.mail to postmas...@multiplay.co.uk.

___
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

[Alexander Leidinger]

Quoting "V. T. Mueller, Continum"  (from  
Thu, 19 Aug 2010 09:20:26 +0200):



Hello,

Alexander Leidinger wrote:
If someone would get icc 11.x up and runnig as a port (similar to  
what we have for outdated icc version in the ports collection), I  
would have a look if my contact at Intel is still working there in  
a position which allows him to get a commercial license for us.


A while ago it was stated by MySQL AB, that their dbms performs  
about 20% better when compiled with icc instead of gcc. Is this  
(still) true?


This looks overly simplified. "It runs better on CPU X with benchmark  
Y on Mainboard Z when you use gcc A.B.C with options D and compare it  
to icc E.F.G with options H." is something you can use in such cases,  
but it doesn't tell you if it will be the case on your machines with  
your workload.


If you want to know if it is faster on your machines with your  
workload, then there is only one way to find it out: try it (be  
warned, due to the amount of optimization options available in  
gcc/icc, something like this will take a lot of time, as there are a  
lot of combinations to try).


Bye,
Alexander.

--
Today is the first day of the rest of your life.

http://www.Leidinger.netAlexander @ Leidinger.net: PGP ID = B0063FE7
http://www.FreeBSD.org   netchild @ FreeBSD.org  : PGP ID = 72077137
___
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

[David Xu]

Gabor Kovesdan wrote:

Yes, I'm sorry for my slow reaction, I got a flu some time ago and that 
prevented me from fixing the bugs earlier. I have several fixes in my 
working copy, which are being discussed with my mentor. Probably, today 
or tomorrow they will be committed.


Gabor



When will the grep -H print file name for me ?  it is rather painful 
that the feature is missing. :-(

So I can not use it with find:

find . -exec grep -H {} world \;
I don't know which file contains the word world.

Regards,
David Xu

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

Re: [head tinderbox] failure on powerpc64/powerpc

[Dag-Erling Smørgrav]

FreeBSD Tinderbox  writes:
 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.

Line 705 in ofw_standard.c is

return ((void *)args.baseaddr);

args.baseaddr is a cell_t, which is defined in :

typedef uint32_tcell_t;

which I assume is correct for powerpc (32-bits), but probably not for
powerpc64.  Note that it is defined as uint64_t on sparc64 and sun4v,
and in sys/boot as unsigned long int, which is the correct size on both
32-bit and 64-bit machines (assuming I32LP64).

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

[Gordon Tetlow]

On Wed, Aug 18, 2010 at 11:52 PM, Gordon Tetlow  wrote:

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

Added. Latest version at http://people.freebsd.org/~gordon/man.sh

It's a slightly different heuristic than the existing man implementation
since I don't support the notion of MANPATH_MAP. Here's the order:

Default manpaths (/usr/share/man:/usr/share/openssl/man:/usr/local/man)
Parse $PATH (path/man:path/MAN:(if ending in /bin)path/../man)
Parse config files

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"

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

[V. T. Mueller, Continum]

Hello,

Alexander Leidinger wrote:
If someone would get icc 11.x up and runnig as a port (similar to what 
we have for outdated icc version in the ports collection), I would have 
a look if my contact at Intel is still working there in a position which 
allows him to get a commercial license for us.


A while ago it was stated by MySQL AB, that their dbms performs about 
20% better when compiled with icc instead of gcc. Is this (still) true?


Cheers,
--
Volker T. Mueller
Continum AG
Bismarckallee 7d
79098 Freiburg i. Br.
Tel. +49 761 21711171
Fax. +49 761 21711198
http://www.continum.net

Sitz der Gesellschaft: Freiburg im Breisgau
Registergericht: Amtsgericht Freiburg, HRB 6866
Vorstand: Rolf Mathis, Volker T. Mueller
Vorsitzender d. Aufsichtsrats: Prof. Dr. Karl-F. Fischbach

___
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

[Alexander Leidinger]

Quoting Dimitry Andric  (from Wed, 18 Aug 2010  
19:56:44 +0200):



Updating that port to icc 11.1 is probably not a trivial task, and
making sure it compiles programs properly is even trickier... :)


It is not as trivial as a normal "configure;make;make install" port,  
but with the existing ports already having sorted out a lot of the big  
problems I think it is more a question of time, interest, and lack of  
fear for doing it (I'm available to answer questions -- as far as I  
remember -- regarding the things being done in the old icc ports, in  
case someone has time, interest... and no fear).


Bye,
Alexander.

--
Alimony is like buying oats for a dead horse.
-- Arthur Baer

http://www.Leidinger.netAlexander @ Leidinger.net: PGP ID = B0063FE7
http://www.FreeBSD.org   netchild @ FreeBSD.org  : PGP ID = 72077137
___
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

[Alexander Leidinger]

Quoting Gabor Kovesdan  (from Wed, 18 Aug 2010  
19:56:01 +0200):



 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


If we wanted to ship binaries, we would have to compile them with the  
commercial license.


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.


At some point I got a license (IIRC for 2-users) which could have been  
installed in the cluster, but this would have meant to install a  
license server somewhere. The license was also the only commercial  
license I had which would have allowed to run the amd64... ehrm...  
em64t version of icc. This was for icc 9.x and I have some doubts this  
license will work with icc 11.x.


If someone would get icc 11.x up and runnig as a port (similar to what  
we have for outdated icc version in the ports collection), I would  
have a look if my contact at Intel is still working there in a  
position which allows him to get a commercial license for us.


Bye,
Alexander.

--
http://www.Leidinger.net  Alexander @ Leidinger.net: PGP ID = B0063FE7
http://www.FreeBSD.org netchild @ FreeBSD.org  : PGP ID = 72077137
The happiest time in any man's life is just after the first divorce.
-- J. K. Galbraith

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