On 8/15/10, Doug Barton wrote:
> On 08/14/2010 09:54, b. f. wrote:
>>> My "runaway intr" problem with flash has been continuing all
>>> along, but since no one has been interested in helping with it I
>>> haven't reported it for a while. However, today, for the first
>>> time, it happened when I h
On 08/14/2010 20:30, Doug Barton wrote:
I'm still using powerd, and it seems to be working as expected.
Sorry, I should have added here that I've also tried running WITHOUT
powerd, and the runaway intr problem still happens.
Doug
--
Improve the effectiveness of your Internet prese
On 08/14/2010 09:54, b. f. wrote:
My "runaway intr" problem with flash has been continuing all
along, but since no one has been interested in helping with it I
haven't reported it for a while. However, today, for the first
time, it happened when I had not run flash at all since I booted.
My syst
My $0.02 may not be worth much, but ...
On Aug 14, 2010, at 9:55 PM, Doug Barton wrote:
I was hoping to avoid commenting on this, but my feeling (and I
would be glad to be wrong about it) from reading the responses is
that there is a fair degree of knee-jerk reaction to what seems to
be "Th
On 15 August 2010 13:55, Doug Barton wrote:
> Our default grep should be significantly slower than the old grep because:
>
> I think that new grep which is times slower than the old grep is still
> in the acceptable range.
I think that new grep which is 1000 times slower than the old grep i
Hi all,
Over the past 18 hours, I've received 22 emails in this thread.
In email number 5, sent a mere 25 minutes after the thread started, gabor@
said that he agreed that the performance penalty in BSD grep compared to
GNU grep was excessive and that he was going to revert back to having GNU
gre
On 08/14/2010 19:02, Randy Bush wrote:
I think that new grep which is times slower than the old grep is
still in the acceptable range.
you are forcing more time to be spent on the mailing list than working
the code.
Not my intention at all, but I feel your pain. I really thought this w
> I think that new grep which is times slower than the old grep is
> still in the acceptable range.
you are forcing more time to be spent on the mailing list than working
the code. and many of us have to care about the license issue.
randy
___
Hello all
I installed the FreeBSD/amd64 8.0 and updated to 9-CURRENT with csup
Following...
# cp /usr/share/examples/cvsup/standard-supfile /root && cd /root && sed -ie
's/CHANGE_THIS/cvsup.de/g' standard-supfile && sed -ie 's/CHANGE_THIS/./g'
standard-supfile && csup -g -L 2 /root/standard-supfi
On 08/14/2010 18:34, Steve Kargl wrote:
On Sat, Aug 14, 2010 at 06:12:34PM -0700, Doug Barton wrote:
Sophisticated users who DO care about performance and/or DO use
grep in interesting and creative ways will put up with the breakage
for a while, then switch their make.conf to use GNU grep, usua
On Sat, Aug 14, 2010 at 06:12:34PM -0700, Doug Barton wrote:
>
> Sophisticated users who DO care about performance and/or DO use grep in
> interesting and creative ways will put up with the breakage for a while,
> then switch their make.conf to use GNU grep, usually silently. Therefore
> they stop
On 08/14/2010 09:10, Gabor Kovesdan wrote:
> Em 2010.08.13. 10:52, Roman Divacky escreveu:
>> what about optimizing BSD grep instead?
>>
> [... picking one mail from the many that suggest this ...]
... and responding to your message for the same reason ... :)
[Snipping the bit about why it's
Ivan,
I know that you mean this at least semi-humorously, however I'm going to
provide a dead-serious reply below.
On 08/14/2010 16:04, Ivan Voras wrote:
> On 13.8.2010 11:34, Doug Barton wrote:
>
>> To be fair, I didn't notice a performance difference either until I
>> started revamping this cod
On 13.8.2010 11:34, Doug Barton wrote:
> On 08/13/2010 02:08, Gabor Kovesdan wrote:
>> Ok, I'll take care of this soon, and make GNU grep default, again with a
>> knob to build BSD grep. I agree with you that we cannot allow such a big
>> performance drawback but I my measures only showed significa
In message: <4c66c0a4.3000...@freebsd.org>
Gabor Kovesdan writes:
: 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, toda
On Sat, Aug 14, 2010 at 19:43, David Wolfskill wrote:
> On Sat, Aug 14, 2010 at 07:05:40PM +0200, Bernhard Schmidt wrote:
>> ...
>> > OK; I reverted by doing this:
>> >
>> > g1-46(9.0-C)[1] cd /usr/src
>> > g1-46(9.0-C)[2] svn merge -c -211295 file:///svn/freebsd/src/base/head
>> > --- Reverse-mer
On Sat, Aug 14, 2010 at 07:05:40PM +0200, Bernhard Schmidt wrote:
> ...
> > OK; I reverted by doing this:
> >
> > g1-46(9.0-C)[1] cd /usr/src
> > g1-46(9.0-C)[2] svn merge -c -211295 file:///svn/freebsd/src/base/head
> > --- Reverse-merging r211295 into 'sys':
> > U sys/net80211/ieee80211_node.c
On Sat, Aug 14, 2010 at 18:47, David Wolfskill wrote:
> On Sun, Aug 15, 2010 at 12:07:13AM +0800, Adrian Chadd wrote:
>> You should be able to revert the ath changes reasonably easy.
>>
>> Would you mind doing that and see if that fixes or contributes to the
>> problem?
>
> OK; I reverted by doin
On 2010-08-14 17:53, Andrey Chernov wrote:
> From my point of
> view importing of the latest GNU grep instead would have more benefits.
Unfortunately GNU grep switched to GPLv3 as of version 2.5.3. The last
GPLv2 version of grep is 2.5.1, which is already in our tree.
__
>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
On Sun, Aug 15, 2010 at 12:07:13AM +0800, Adrian Chadd wrote:
> You should be able to revert the ath changes reasonably easy.
>
> Would you mind doing that and see if that fixes or contributes to the problem?
OK; I reverted by doing this:
g1-46(9.0-C)[1] cd /usr/src
g1-46(9.0-C)[2] svn merge -c
You should be able to revert the ath changes reasonably easy.
Would you mind doing that and see if that fixes or contributes to the problem?
Thanks,
Adrian
On 14 August 2010 23:29, David Wolfskill wrote:
> Previously built @r211278; just build r211295 this morning, and didn't
> quite pass th
Em 2010.08.14. 17:53, Andrey Chernov escreveu:
On Fri, Aug 13, 2010 at 01:43:16AM -0700, Doug Barton wrote:
Gabor,
I hope at this point it goes without saying that I have a lot of respect
I am Nth on this. Although I do a lot of l10n work in the beautefull less
bureocracy FreeBSD tim
Em 2010.08.13. 10:52, Roman Divacky escreveu:
what about optimizing BSD grep instead?
[... picking one mail from the many that suggest this ...]
The problem is that optimization is not that trivial. I think the
bottleneck is the regex library because:
1, BSD grep is so simple. There may be
On Sun, Aug 15, 2010 at 12:07:13AM +0800, Adrian Chadd wrote:
> You should be able to revert the ath changes reasonably easy.
>
> Would you mind doing that and see if that fixes or contributes to the problem?
Will do; I'll report back when I have information to report -- probably
within 30 minute
On Fri, Aug 13, 2010 at 01:43:16AM -0700, Doug Barton wrote:
> Gabor,
>
> I hope at this point it goes without saying that I have a lot of respect
I am Nth on this. Although I do a lot of l10n work in the beautefull less
bureocracy FreeBSD time and very appreciate what Gabor did, the problem is
Hi,
I've committed a couple more small AR9160 related fixes. Please test
if_ath if you're using AR9160 in any mode (hostap, adhoc, station) and
provide some feedback.
Thanks,
Adrian
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org
On Sat, Aug 14, 2010 at 06:23:55PM +0300, Daniel Braniss wrote:
> > On Sat, 14 Aug 2010, Julian H. Stacey wrote:
> >
> > >> why would you want to lock a file for reading anyways?
> > >
> > > Does current bsdgrep read lock by default ?
> > > If so, it would be better off by default, enabled by an o
> On Sat, 14 Aug 2010, Julian H. Stacey wrote:
>
> >> why would you want to lock a file for reading anyways?
> >
> > Does current bsdgrep read lock by default ?
> > If so, it would be better off by default, enabled by an option.
> > 8.0-RELEASE man grep (gnu) does not mention locking.
>
> bsdgrep
On Sat, 14 Aug 2010, Ian FREISLICH wrote:
Pyun YongHyeon wrote:
I'm working on it but I was not able to reproduce the issue on my
AR8131/AR8132/AR8151/AR8152 sample boards. However it seems AR8132
is the only controller that shows this issue and I vaguely remember
a couple of users reported the
On Sat, 14 Aug 2010, Julian H. Stacey wrote:
why would you want to lock a file for reading anyways?
Does current bsdgrep read lock by default ?
If so, it would be better off by default, enabled by an option.
8.0-RELEASE man grep (gnu) does not mention locking.
bsdgrep in -current does lock v
On 14-08-2010 4:35, Sam Fourman Jr. wrote:
> >> BSD grep
> >> Elapsed time: 47 seconds
> >
> > what about optimizing BSD grep instead?
>
> I think this is reasonable, leave BSD grep default for a few more weeks, and
> work on performance enhancements. I agree that changing the default back
> for
Kurt Jaeger wrote:
> Hi!
>
> > Pyun YongHyeon wrote:
> > > I'm working on it but I was not able to reproduce the issue on my
> > > AR8131/AR8132/AR8151/AR8152 sample boards. However it seems AR8132
> > > is the only controller that shows this issue and I vaguely remember
> > > a couple of users re
> why would you want to lock a file for reading anyways?
Does current bsdgrep read lock by default ?
If so, it would be better off by default, enabled by an option.
8.0-RELEASE man grep (gnu) does not mention locking.
Cheers,
Julian
--
Julian Stacey: BSD Unix Linux C Sys Eng Consultants Munich h
>> BSD grep
>> Elapsed time: 47 seconds
>
> what about optimizing BSD grep instead?
I think this is reasonable, leave BSD grep default for a few more weeks, and
work on performance enhancements. I agree that changing the default back
for a RELEASE is probably a good idea, but the exposure to wider
> This message is in MIME format. The first part should be readable text,
> while the remaining parts are likely unreadable without MIME-aware tools.
>
> --56599777-398594934-1281714095=:35204
> Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed
>
> On Fri, 13 Aug 2010, Gabor Kovesdan
Hi!
> Pyun YongHyeon wrote:
> > I'm working on it but I was not able to reproduce the issue on my
> > AR8131/AR8132/AR8151/AR8152 sample boards. However it seems AR8132
> > is the only controller that shows this issue and I vaguely remember
> > a couple of users reported the issue.
> > I'll update
Pyun YongHyeon wrote:
> I'm working on it but I was not able to reproduce the issue on my
> AR8131/AR8132/AR8151/AR8152 sample boards. However it seems AR8132
> is the only controller that shows this issue and I vaguely remember
> a couple of users reported the issue.
> I'll update PR 148772 if I m
38 matches
Mail list logo