On Tue, Aug 24, 2010 at 12:12:57AM +0300, Kostik Belousov wrote:
> On Sun, Aug 22, 2010 at 03:21:04PM +0200, Peter Holm wrote:
> > On Sat, Aug 21, 2010 at 01:49:45PM -0400, Michael Butler wrote:
> > > While updating sysutils/coreutils port on -current as of this morning
> > > (SVN r211550), I noted
On 08/23/10 17:12, Kostik Belousov wrote:
> On Sun, Aug 22, 2010 at 03:21:04PM +0200, Peter Holm wrote:
>> On Sat, Aug 21, 2010 at 01:49:45PM -0400, Michael Butler wrote:
>>> While updating sysutils/coreutils port on -current as of this morning
>>> (SVN r211550), I noted a panic during the director
On 08/23/10 21:49, Matt wrote:
> Please note atrtc0 error in dmesg?
[ .. ]
> atrtc0: port 0x70-0x77 irq 8 on acpi0
> atrtc0: Warning: Couldn't map I/O.
> atrtc0: [FILTER]
I get this on a Toshiba A105 but it doesn't seem to hurt anything,
imb
___
-sendai acpi: suspend at 20100823 17:59:09
Please note atrtc0 error in dmesg?
Can provide KERNCONF or other files as needed.
Thank you all! I have been using various *bsd since I was 15 (~decade),
can't tell you how grateful I am for your work, I hope to be able to
help more soon!
ACPI
On Mon, Aug 23, 2010 at 5:04 PM, Gabor Kovesdan wrote:
> 4, We really need a good regex library. From the comments, it seems there's
> no such in the open source world. GNU libregex isn't efficient because GNU
> grep uses those workarounds that Mike kindly pointed out. Oniguruma was
> extremely sl
TB --- 2010-08-23 20:43:22 - tinderbox 2.6 running on freebsd-current.sentex.ca
TB --- 2010-08-23 20:43:22 - starting HEAD tinderbox run for powerpc/powerpc
TB --- 2010-08-23 20:43:22 - cleaning the object tree
TB --- 2010-08-23 20:44:03 - cvsupping the source tree
TB --- 2010-08-23 20:44:03 - /usr
On Sun, Aug 22, 2010 at 03:21:04PM +0200, Peter Holm wrote:
> On Sat, Aug 21, 2010 at 01:49:45PM -0400, Michael Butler wrote:
> > While updating sysutils/coreutils port on -current as of this morning
> > (SVN r211550), I noted a panic during the directory rename config test.
> >
>
> Your problem
On 23 Aug 2010, at 21:27, Max Laier wrote:
> On Monday 23 August 2010 20:56:08 Simon L. B. Nielsen wrote:
>> I can't think of what else to say, so that was probably it :-).
>
> MD5/SHA256/SIZE?
People use that? That sounds difficult ;-)
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
SIZE (svn
On Monday 23 August 2010 20:56:08 Simon L. B. Nielsen wrote:
> I can't think of what else to say, so that was probably it :-).
MD5/SHA256/SIZE?
Thank you!
Max
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebs
On Wed, Aug 11, 2010 at 03:31:50PM -0700, Pyun YongHyeon wrote:
> Hi,
>
> Here is patch that adds support WOL for xl(4). Note, not all xl(4)
> controllers support WOL. Some controllers require additional 3-wire
> auxiliary remote wakeup connector to draw power. I don't have the
> connector so I do
Hey,
I have made a new snapshot of the svn repo which can be used to start new
FreeBSD svn mirrors.
Hopefully I made it the right way, but... let me know if there are any issues.
Since the original snapshot was made by peter the repo was 'packed' which means
it uses a lot fewer files.
The sna
On 08/23/2010 05:39, John Baldwin wrote:
On Sunday, August 22, 2010 11:17:44 pm Doug Barton wrote:
Thanks to help from Andriy I've been working on narrowing down the cause
of my "runaway intr" problems and we've found some interesting things.
First, if I use neither powerd nor set hw.acpi.cpu.cx
Dag-Erling Smørgrav wrote:
Alan Cox writes:
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 h
On Aug 23, 2010, at 9:04 AM, Gabor Kovesdan wrote:
> Hi all,
>
> there are some consequences that we can see from the grep case. Here I'd like
> to add a summary, which raises some questions. All comments are welcome.
>
> 1, When grep entered -CURRENT and bugs were found I immediately got kind
On 2010-08-20 23:07, b. f. wrote:
> The lisp category is the only category that causes a problem with the
> new bsdgrep, and I didn't take the time to analyze why ( which is why
> I was not more specific in my original message). 'lisp' is preceded by
> 'elisp', which would normally be a match for t
On 8/23/10, John Baldwin wrote:
> On Saturday, August 21, 2010 11:28:41 am Andriy Gapon wrote:
>> on 21/08/2010 16:04 b. f. said the following:
>> > Andriy Gapon wrote:
>> >> on 21/08/2010 12:35 Andriy Gapon said the following:
>> >>> I feel like you might be having a problem with clocks...
>> >>
Dag-Erling Smørgrav writes:
> No idea what causes it, but a quick grep (hah!) for qflag turns up the
> following horror:
>
> /* Find out the correct return value according to the
>results and the command line option. */
> exit(c ? (notfound ? (qflag ? 0 : 2) : 0) : (not
Hi all,
there are some consequences that we can see from the grep case. Here I'd
like to add a summary, which raises some questions. All comments are
welcome.
1, When grep entered -CURRENT and bugs were found I immediately got kind
bug reports and sharp criticism, as well. According to my u
Ian FREISLICH wrote:
> So, in this case is the fusefs module broken? I'm guessing it is.
> I don't like the way fuse_fileops is initialised in fuse4bsd. I
> would prefer for the struct to be zeroed and then the fo_xxx
> implimented bits set as appropriate. That way when the struct is
> changed,
On Mon, Aug 23, 2010 at 04:32:58PM +0200, Ian FREISLICH wrote:
> Kostik Belousov wrote:
> >
> > --7hK5U8dVDlZxii7z
> > Content-Type: text/plain; charset=us-ascii
> > Content-Disposition: inline
> > Content-Transfer-Encoding: quoted-printable
> >
> > On Mon, Aug 23, 2010 at 03:47:23PM +0200, Ed Sc
Kostik Belousov wrote:
>
> --7hK5U8dVDlZxii7z
> Content-Type: text/plain; charset=us-ascii
> Content-Disposition: inline
> Content-Transfer-Encoding: quoted-printable
>
> On Mon, Aug 23, 2010 at 03:47:23PM +0200, Ed Schouten wrote:
> > * Kostik Belousov wrote:
> > > On Mon, Aug 23, 2010 at 03:35
* Kostik Belousov wrote:
> I would not object loudly if someone put such checks as proposed
> under INVARIANTS, but also I do not see a real point in having them.
> Might be slightly better to put the checks, again under INVARIANTS,
> in the fo_XXX() wrappers.
Well, the entire point is to put the
On Mon, Aug 23, 2010 at 03:47:23PM +0200, Ed Schouten wrote:
> * Kostik Belousov wrote:
> > On Mon, Aug 23, 2010 at 03:35:55PM +0200, Ed Schouten wrote:
> > > * Kostik Belousov wrote:
> > > > Which most likely means that fusesfs filled its own struct fileops
> > > > without properly initializing
* Kostik Belousov wrote:
> On Mon, Aug 23, 2010 at 03:35:55PM +0200, Ed Schouten wrote:
> > * Kostik Belousov wrote:
> > > Which most likely means that fusesfs filled its own struct fileops
> > > without properly initializing fo_truncate member.
> >
> > It's a bit misleading that cdevs automatic
On Mon, Aug 23, 2010 at 03:35:55PM +0200, Ed Schouten wrote:
> * Kostik Belousov wrote:
> > Which most likely means that fusesfs filled its own struct fileops
> > without properly initializing fo_truncate member.
>
> It's a bit misleading that cdevs automatically patch the table, while
> the file
On 23/08/2010 13:45, Bob Bishop wrote:
> On 23 Aug 2010, at 12:51, chrisk-free...@list.mightyreason.com wrote:
>> [...]The hardest part of POSIX regular expressions is in picking out the
>> correct captured subexpressions. This makes programs like "sed"
>> vulnerable to the bad regex.h engine tha
* Ed Schouten wrote:
> check whether under INVARIATIONS all fileops are set?
INVARIANTS, that is.
--
Ed Schouten
WWW: http://80386.nl/
pgp0MtaoWCOzp.pgp
Description: PGP signature
* Kostik Belousov wrote:
> Which most likely means that fusesfs filled its own struct fileops
> without properly initializing fo_truncate member.
It's a bit misleading that cdevs automatically patch the table, while
the fileops don't. Maybe it would be a good idea to patch finit() to
check whethe
Ian FREISLICH wrote:
> John Baldwin wrote:
> > The uart thing is a red herring, notice the actual PC value is '0'. Someth
ing
> > in kern_open() invoked a NULL function pointer. Doing 'l *kern_open+0x35'
in
> > kgdb would be a good start of where to look.
>
> (kgdb) l *kern_open+0x35
> 0xc0649c
On Mon, Aug 23, 2010 at 02:58:59PM +0200, Ian FREISLICH wrote:
> John Baldwin wrote:
> > The uart thing is a red herring, notice the actual PC value is '0'.
> > Something
> > in kern_open() invoked a NULL function pointer. Doing 'l *kern_open+0x35'
> > in
> > kgdb would be a good start of where
John Baldwin wrote:
> The uart thing is a red herring, notice the actual PC value is '0'. Something
> in kern_open() invoked a NULL function pointer. Doing 'l *kern_open+0x35' in
> kgdb would be a good start of where to look.
(kgdb) l *kern_open+0x35
0xc0649ce5 is in kern_open (/usr/src/sys/kern
Hi,
On 23 Aug 2010, at 12:51, chrisk-free...@list.mightyreason.com wrote:
> [...]The hardest part of POSIX regular expressions is in picking out the
> correct captured subexpressions. This makes programs like "sed"
> vulnerable to the bad regex.h engine that comes with the operating system.
>
>
On Saturday, August 21, 2010 11:28:41 am Andriy Gapon wrote:
> on 21/08/2010 16:04 b. f. said the following:
> > Andriy Gapon wrote:
> >> on 21/08/2010 12:35 Andriy Gapon said the following:
> >>> I feel like you might be having a problem with clocks...
> >> FWIW, I am reading this document http://
On Friday, August 20, 2010 12:11:00 pm Ian FREISLICH wrote:
> Hi
>
> I have a system that relies on Fuse and OWFS to manage the power
> at my house. I get the following panic when writing to to one of
> the PIO devices:
>
> The panic isn't really helpful because it looks like the stack frame
> h
On Sunday, August 22, 2010 11:17:44 pm Doug Barton wrote:
> Thanks to help from Andriy I've been working on narrowing down the cause
> of my "runaway intr" problems and we've found some interesting things.
> First, if I use neither powerd nor set hw.acpi.cpu.cx_lowest less than
> C1 things seem
I saw the discussion on this list with the subject "why GNU grep is
fast" and I thought I would contribute to a discussion of the
correctness of the POSIX regular expressions.
Gabor wrote:
>> I believe Gabor is considering TRE for a good replacement regex library.
> Yes. Oniguruma is slow, Google
"b. f." writes:
> Dag-Erling Smørgrav writes:
> > "Does not seem to work properly" is not a very useful statement. The
> > least you could do is provide an example.
> I did provide an example, later in the same sentence that you quoted.
I forgot to answer this part. By example, I mean an actua
On 2010-08-10 23:39, Bartosz Stec wrote:
On 2010-08-10 23:12, Gabor Kovesdan wrote:
Em 2010.08.10. 19:45, Anonymous escreveu:
Seems like APACHE_MODULES is incorrectly populated.
$ make -V APACHE_MODULES BATCH=
GREP=${LOCALBASE-/usr/local}/bin/grep | fgrep cache
...cache disk_cache fi
Anonymous writes:
[...]
> BTW, running GNU iconv(1) with following in libmap.conf
>
> libiconv.so.3 libc.so.7
>
> produces
>
> $ gnu-iconv
> /libexec/ld-elf.so.1: Undefined symbol "_libiconv_version" referenced from
> COPY relocation in LOCALBASE/bin/iconv
I guess gettext hanging is due t
Later on, he summarizes some of the existing implementations,
including comments about the Plan 9 implementation and his own RE2,
both of which efficiently handle international text (which seems to
be a major concern of Gabor's).
I believe Gabor is considering TRE for a good replacement re
Em 2010.08.21. 4:31, Mike Haertel escreveu:
Hi Gabor,
I am the original author of GNU grep. I am also a FreeBSD user,
although I live on -stable (and older) and rarely pay attention
to -current.
However, while searching the -current mailing list for an unrelated
reason, I stumbled across some
Em 2010.08.19. 23:42, b. f. escreveu:
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
Em 2010.08.19. 8:41, Doug Barton escreveu:
The performance is now almost comparable to GNU grep.
I think you're using a very liberal definition of "comparable."
Ok, comparable for the casual cases but not generally comparable.
I think with this, BSD grep may remain default if no other se
On 08/23/2010 01:01, Andriy Gapon wrote:
Speaking of which you seem to have too many powerd levels.
D'oh!
What cpufreq drivers are in use on your system?
The only one I have is the cpufreq that's in GENERIC.
Maybe you'd want to stick to just one of them?
E.g.:
http://lists.freebsd.org/pi
Mike Haertel writes:
> Dag-Erling Smørgrav writes:
> > You don't really need to "isolate the containing line" unless you have
> > an actual match, do you?
> Theoretically no. However, suppose the pattern was /foo.*blah/.
> The Boyer-Moore search will be for "blah", since that's the longest
> fix
on 23/08/2010 10:55 Doug Barton said the following:
> Meanwhile, with the combination of ULE, no powerd, and cx_lowest=C1 I was able
> to watch 2 movies streaming over flash, plus do backups to various USB drives,
> read mail, etc. etc. for several hours; all without a hiccup. So clearly (in
> my
"Sean C. Farley" writes:
> Dag-Erling Smørgrav writes:
> > Aho-Corasick is not really a search algorithm, but an algorithm for
> > constructing a table-driven finite state machine that will match
> > either of the search strings you fed it. I believe it is less
> > efficient than Boyer-Moore for
On 8/23/2010 12:23 AM, Andriy Gapon wrote:
on 23/08/2010 09:48 Doug Barton said the following:
On 08/22/2010 23:20, Andriy Gapon wrote:
on 23/08/2010 06:17 Doug Barton said the following:
http://people.freebsd.org/~dougb/intr-out-3.txt
So, hm, npviewer.bin eats all the CPU time?
No, the o
on 23/08/2010 09:48 Doug Barton said the following:
> On 08/22/2010 23:20, Andriy Gapon wrote:
>> on 23/08/2010 06:17 Doug Barton said the following:
>>
>>> http://people.freebsd.org/~dougb/intr-out-3.txt
>>
>> So, hm, npviewer.bin eats all the CPU time?
>
> No, the odd bits of that one are the fa
49 matches
Mail list logo
