Re: runaway intr problems: powerd and/or hw.acpi.cpu.cx_lowest related
on 23/08/2010 06:17 Doug Barton said the following: I also got another interesting set of data today from a runaway intr situation that did not involve swi:4. The symptoms were the same as previously, but the devices involved were totally different. This may have to do with the fact that I switched back to ULE for the testing today, and/or I hadn't set cx_lowest=C3. Yes, ULE rules. 4BSD usually only makes things better when there is some real problem and 4BSD masks it due to its design. http://people.freebsd.org/~dougb/intr-out-3.txt So, hm, npviewer.bin eats all the CPU time? Just google that name and see that you are not alone. Can't help with that though. This was with ULE + USB in the kernel, LAPIC/HPET, cx_lowest=C1, but running powerd with the following: powerd_flags=-a adaptive -b adaptive -n adaptive -- 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: runaway intr problems: powerd and/or hw.acpi.cpu.cx_lowest related
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 fact that the intr threads irq17,
irq256, and irq20; are showing up at all, and/or showing up with more
than a fraction of a percent of cpu time. Usually they don't, and the
fact that they did at that point in time was indicative of the fact that
the runaway intr problem was happening. _Incidentally_ npviewer.bin
was taking up more cpu than it usually does, but I think that's another
symptom of the underlying problem.
Here is a typical, non-problematic top output while running a flash video:
last pid: 10841; load averages: 0.22, 0.12, 0.19up 0+04:15:49
23:46:11
171 processes: 3 running, 148 sleeping, 20 waiting
CPU 0: 14.8% user, 0.0% nice, 3.1% system, 0.0% interrupt, 82.0% idle
CPU 1: 18.8% user, 0.0% nice, 0.0% system, 0.0% interrupt, 81.3% idle
Mem: 342M Active, 1397M Inact, 168M Wired, 49M Cache, 112M Buf, 45M Free
Swap: 1024M Total, 1444K Used, 1022M Free
PID USERNAME PRI NICE SIZERES STATE C TIME WCPU COMMAND
10 root 171 ki31 0K16K CPU00 203:29 82.86% {idle:
cpu0}
10 root 171 ki31 0K16K RUN 1 191:24 81.05% {idle:
cpu1}
10813 dougb 540 420M 78196K select 0 0:18 17.77% npviewer.bin
10822 dougb 470 420M 78196K futex 1 0:05 6.30% npviewer.bin
10839 dougb 450 420M 78196K futex 1 0:03 3.66% npviewer.bin
10840 dougb 450 420M 78196K futex 1 0:03 3.66% npviewer.bin
10832 dougb 450 420M 78196K pcmwrv 1 0:03 2.88% npviewer.bin
1598 dougb 440 163M 142M select 1 12:06 1.56% Xorg
11 root -68- 0K 160K WAIT1 1:10 0.49% {irq17:
wpi0}
10770 dougb 440 178M 136M ucond 0 0:00 0.39%
{firefox-bin}
10770 dougb 450 178M 136M select 1 0:15 0.29% {initial
thread
11 root -80- 0K 160K WAIT0 0:45 0.10%
{irq256: hdac0}
I really wish people would stop focusing on flash here. :) It's simply
the easiest and most consistent way that I have triggered this problem,
it's not the only one.
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: runaway intr problems: powerd and/or hw.acpi.cpu.cx_lowest related
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 fact that the intr threads irq17, irq256,
and irq20; are showing up at all, and/or showing up with more than a fraction
of
a percent of cpu time.
DTrace output doesn't show anything abnormal for those, but it does show that
those interrupts do happen and those drivers do work.
E.g. there is hdac (sound) activity [irq256: hdac0] and wireless activity
[irq17: wpi0]. irq20 is hpet + usb.
So did you do anything wireless? Did you play sound?
The %WCPU may be _reported_ higher than what it actually is due to other issues
with your system (high load by npviewer.bin, HPET+USB interrupt sharing, C3 with
LAPIC timer).
Usually they don't, and the fact that they did at that
point in time was indicative of the fact that the runaway intr problem was
happening. _Incidentally_ npviewer.bin was taking up more cpu than it usually
does, but I think that's another symptom of the underlying problem.
In complex systems it's not always trivially obvious what's incidental and
what's not.
Here is a typical, non-problematic top output while running a flash video:
last pid: 10841; load averages: 0.22, 0.12, 0.19up 0+04:15:49 23:46:11
171 processes: 3 running, 148 sleeping, 20 waiting
CPU 0: 14.8% user, 0.0% nice, 3.1% system, 0.0% interrupt, 82.0% idle
CPU 1: 18.8% user, 0.0% nice, 0.0% system, 0.0% interrupt, 81.3% idle
Mem: 342M Active, 1397M Inact, 168M Wired, 49M Cache, 112M Buf, 45M Free
Swap: 1024M Total, 1444K Used, 1022M Free
PID USERNAME PRI NICE SIZERES STATE C TIME WCPU COMMAND
10 root 171 ki31 0K16K CPU00 203:29 82.86% {idle: cpu0}
10 root 171 ki31 0K16K RUN 1 191:24 81.05% {idle: cpu1}
10813 dougb 540 420M 78196K select 0 0:18 17.77% npviewer.bin
10822 dougb 470 420M 78196K futex 1 0:05 6.30% npviewer.bin
10839 dougb 450 420M 78196K futex 1 0:03 3.66% npviewer.bin
10840 dougb 450 420M 78196K futex 1 0:03 3.66% npviewer.bin
10832 dougb 450 420M 78196K pcmwrv 1 0:03 2.88% npviewer.bin
1598 dougb 440 163M 142M select 1 12:06 1.56% Xorg
11 root -68- 0K 160K WAIT1 1:10 0.49% {irq17: wpi0}
10770 dougb 440 178M 136M ucond 0 0:00 0.39% {firefox-bin}
10770 dougb 450 178M 136M select 1 0:15 0.29% {initial
thread
11 root -80- 0K 160K WAIT0 0:45 0.10% {irq256:
hdac0}
Well, notice that in this case your npviewer.bin processes are not run away
either. They spend most of the time waiting for something and use only a
fraction of CPU time. In the report that I commented on they were mostly
running on CPU (and who knows what else they were doing, like driving sound card
crazy etc).
I really wish people would stop focusing on flash here. :) It's simply the
easiest and most consistent way that I have triggered this problem, it's not
the
only one.
Well, I just interpreted the DTrace output you gave. No prejudice against
flash, although all those reports/complaints by Linux folks are suspicious.
--
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: runaway intr problems: powerd and/or hw.acpi.cpu.cx_lowest related
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 odd bits of that one are the fact that the intr threads irq17, irq256, and irq20; are showing up at all, and/or showing up with more than a fraction of a percent of cpu time. DTrace output doesn't show anything abnormal for those, but it does show that those interrupts do happen and those drivers do work. E.g. there is hdac (sound) activity [irq256: hdac0] and wireless activity [irq17: wpi0]. irq20 is hpet + usb. So did you do anything wireless? Did you play sound? Yes. My laptop is using wireless exclusively, and the streaming/flash video was attempting to play sound, but given that it was starved for resources the video and the audio were both very choppy. The %WCPU may be _reported_ higher than what it actually is due to other issues with your system (high load by npviewer.bin, HPET+USB interrupt sharing, C3 with LAPIC timer). Usually they don't, and the fact that they did at that point in time was indicative of the fact that the runaway intr problem was happening. _Incidentally_ npviewer.bin was taking up more cpu than it usually does, but I think that's another symptom of the underlying problem. In complex systems it's not always trivially obvious what's incidental and what's not. Yep, sorry, no reason for you to have read my mind there. :) Well, I just interpreted the DTrace output you gave. Right-o. I am about 80% ready to take the old HD out and put the new one in and start installing, at which point I'm going to set up the schedgraph stuff which will hopefully give more useful information. 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 mind at least) there is a problem with powerd, at least in the situation like mine where there is IRQ contention for HPET. I forgot to mention that in my previous testing today I tried running just powerd (not changing cx_lowest) and I when intr started running away I could solve the problem by killing powerd. The intr process went back to normal, and I could go back to doing what I was doing without having to reboot again. anyways thanks again, Doug -- ... and that's just a little bit of history repeating. -- Propellerheads Improve the effectiveness of your Internet presence with a domain name makeover!http://SupersetSolutions.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: why GNU grep is fast
Sean C. Farley s...@freebsd.org writes: Dag-Erling Smørgrav d...@des.no 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 small numbers of search terms, since it scans the entire input. I don't see the point in using it in grep, because grep already has an algorithm for constructing finite state machines: regcomp(3). especially those that could be useful for fgrep functionality Not entirely sure what you mean by that, but in most cases, I think Boyer-Moore is a better fit for fgrep. For large numbers of search terms, I might use Aho-Corasick... if it weren't for the fact that, as mentioned, grep already has a regexp engine, which is a superset of Aho-Corasick. It might be a tad slower at building the FSA, because it's more general, and the FSA might occupy a tad more memory, but the complexity is *exactly* the same, and adding Aho-Corasick just for fgrep is, for lack of a better word, pedantry. For all you know, the increased code size could very well offset whatever performance advantage Aho-Corasick might offer. Glimpse may be a POS; I have not used it personally. I only noted its algorithm for possible use within fgrep. Apples and oranges. The problem glimpse tries to solve (fixed corpus, variable search terms) is precisely the opposite of the one fgrep tries to solve (fixed search terms, variable corpus). Glimpse does include grep-like functionality, but in the form of agrep, which is designed for approximate matching. 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: runaway intr problems: powerd and/or hw.acpi.cpu.cx_lowest related
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 mind at least) there is a problem with powerd, at least in the situation like mine where there is IRQ contention for HPET. I forgot to mention that in my previous testing today I tried running just powerd (not changing cx_lowest) and I when intr started running away I could solve the problem by killing powerd. The intr process went back to normal, and I could go back to doing what I was doing without having to reboot again. Speaking of which you seem to have too many powerd levels. What cpufreq drivers are in use on your system? Maybe you'd want to stick to just one of them? E.g.: http://lists.freebsd.org/pipermail/freebsd-stable/2010-March/055666.html -- 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: why GNU grep is fast
Mike Haertel m...@ducky.net writes: Dag-Erling Smørgrav d...@des.no 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 fixed substring. But verifying a match for the full regexp either requires a regexp matcher with the feature start here, at THIS point in the middle of the RE and THAT point in the middle of the buffer, and match backwards and forwards, or else running a more standard RE matcher starting from the beginning of the line. Stupidly enough, I only considered the case where the fixed search string is at the end of the regexp :) For the general case, you'd have to either build a second FSA that mirrors the first, or design your engine and data structures in such a way that the FSA can be traversed in either direction. Then you note which states correspond to the beginning and end of the fixed substring, and run the FSA forward from the end and backward from the beginning. That could prove advantageous when the input consists of very long lines and the frequency of partial matches is relatively high; large files with very long lines are very common in bioinformatics. As you mentioned, you can avoid searching forwards for the next newline if your RE matcher supports using newline as an exit marker. Umm, I don't understand why it needs to support using *anything* as an exit marker. The newline character will simply not match any of the transitions from whichever state the FSA is currently in, and neither will the null character. The only bit that needs to know about them is the bit that handles end-of-line and end-of-word anchors. 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: runaway intr problems: powerd and/or hw.acpi.cpu.cx_lowest related
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/pipermail/freebsd-stable/2010-March/055666.html Ok, so it seems that you're suggesting to disable throttling, so I added the following to /boot/loader.conf: hint.p4tcc.0.disabled=1 hint.p4tcc.1.disabled=1 hint.acpi_throttle.0.disabled=1 hint.acpi_throttle.1.disabled=1 Not sure the .1.'s are necessary, but I wanted to be thorough. With that I get: dev.cpu.0.freq_levels: 2333/31000 2000/26000 1667/22000 1333/17000 1000/13000 dev.est.0.freq_settings: 2333/31000 2000/26000 1667/22000 1333/17000 1000/13000 dev.est.1.freq_settings: 2333/31000 2000/26000 1667/22000 1333/17000 1000/13000 hopefully that's more in line with what it should be? I'd really like to be able to at least use powerd since it does seem to help with heat when the system is idle (and by extension, power consumption as well). Unless you say differently when I get up tomorrow I'll try this configuration for a little while and see how it goes. 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: BSD grep performance
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 serious issues come up. I'm not going to re-state my opinion here except to say it hasn't changed. Even if the performance were not an issue I think the bugs mentioned below combined with your 4-day absence should also have been considerations. However, in regards to this particular case I think it's pretty obvious that I'm either alone, or in a very non-vocal group; so c'est la vie. I think the 4-day absence was not such a big deal given that we are talking about -current, I just wanted to let you know that I would not be responsive because of absence not ignorance. Other people also felt in the same way; it's fine to allow a short unstable period in -current to get things arranged. However, from the standpoint of committer relations I think that first stating that you would change the default, then not doing so before all of the outstanding issues were resolved is not what I would consider a good model for others to follow. I've just changed it back. No, I didn't lie to you, I just wanted to reevaluate if the remaining difference in ther performance was acceptable. We improved it a lot since you let us know about this problem and there is possibility that further improvements are to happen soon. I thank you that you helped the process with valuable feedback but I think it could have been done in a less noisy way and arrogant way. You called the attention to the performance problem, which is fine and necessary but I'd have reacted in the same way if you hadn't CC'd core@ in the very first mail and hadn't included the Official request words in the subject. But I know that there are people, who feel them so important that they have to always call the attention in the noisy way (ego in the Buddhist meaning) and I also have some personal problems that I feel bothered by such type of behaviour. This is a sign for me that I have to practice more acceptance and patience in the life. Gabor ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Official request: Please make GNU grep the default
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 the 'check-categories' target (and hence builds) of all ports with 'lisp' in CATEGORIES. Thanks, I added to my TODO list. P.S. I hope that you have recovered from your influenza, and are feeling better now. Oh, thanks, I'm fine now but I'm moving soon to another country, so will be busy for some time. But I've changed back the default to GNU grep, so now the fixes aren't so urgent. Gabor ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: why GNU grep is fast
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 flamage regarding BSD grep vs GNU grep performance. You may have noticed that discussion too... Anyway, just FYI, here's a quick summary of where GNU grep gets its speed. Hopefully you can carry these ideas over to BSD grep. Thanks, Mike, I'll check how I could adopt these ideas into BSD grep. I think your kind help was such a nice gesture and the open souce world should be based on such cooperation instead of meaningless competition. Gabor ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: why GNU grep is fast
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 regex library. Yes. Oniguruma is slow, Google RE2 only supports Perl and fgrep syntax but not standard regex and Plan 9 implementation iirc only supports fgrep syntax and Unicode but not wchar_t in general. The key comment in Mike's GNU grep notes is the one about not breaking into lines. That's simply double-scanning the input; instead, run the matcher over blocks of text and, when it finds a match, work backwards from the match to find the appropriate line beginning. This is efficient because most lines don't match. I do like the idea. So do I. BTW, the fastgrep portion of bsdgrep is my fault/contribution to do a faster search bypassing the regex library. :) It certainly was not written with any encodings in mind; it was purely ASCII. As I have not kept up with it, I do not know if anyone improved it or not. It has been made wchar-compliant. Gabor ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: [CFT] BSDL iconv in base system
Anonymous swel...@gmail.com 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 to ABI incompatibility, too.
$ cat foo.po
msgid
msgstr
Content-Type: text/plain; charset=UTF-8\n
Content-Transfer-Encoding: 8bit\n
msgid don’t
msgstr do not
$ msgmerge foo.po /dev/null # GNU iconv
. done.
msgid
msgstr
Content-Type: text/plain; charset=UTF-8\n
Content-Transfer-Encoding: 8bit\n
#~ msgid don’t
#~ msgstr do not
$ msgmerge foo.po /dev/null # BSD iconv
. done.
msgid
load: 0.10 cmd: msgmerge 65132 [runnable] 2.74r 2.72u 0.00s 23% 2844k
^C
(gdb) bt
#0 _citrus_iconv_none_iconv_convert (ci=0x80f00f190, in=0x7fff0b40,
inbytes=0x7fff0b40, out=0x7fff0b48, outbytes=0x7fff0b50, flags=0,
invalids=0x7fff0aa0) at
/usr/src/lib/libiconv_modules/iconv_none/citrus_iconv_none.c:119
len = 1
e2big = 0
#1 0x0008064b9142 in _citrus_iconv_convert (cv=0x80f00f190,
in=0x7fff0b38, inbytes=0x7fff0b40, out=0x7fff0b48,
outbytes=0x7fff0b50,
flags=0, nresults=0x7fff0aa0) at citrus_iconv.h:60
No locals.
#2 0x0008064b90b2 in libiconv (handle=0x80f00f190, in=0x7fff0b38,
szin=0x7fff0b40, out=0x7fff0b48, szout=0x7fff0b50)
at /usr/src/lib/libc/iconv/iconv.c:147
ret = 0
err = 0
#3 0x0008036db20a in wrap (mp=0x80f020400, stream=0x80f0123c0,
line_prefix=0x0, extra_indent=0, css_class=0x80370a2f0 msgstr,
name=0x80370a3a9 msgstr, value=0x80f01f0b0 Content-Type: text/plain;
charset=UTF-8\nContent-Transfer-Encoding: 8bit\n, do_wrap=undecided,
page_width=79, charset=0x7fff0d80 UTF-8) at write-po.c:724
#4 0x0008036dcbdd in message_print (mp=0x80f020400, stream=0x80f0123c0,
charset=0x7fff0d80 UTF-8, page_width=79, blank_line=false, debug=false)
at write-po.c:1283
#5 0x0008036dd736 in msgdomain_list_print_po (mdlp=0x80f0071c0,
stream=0x80f0123c0, page_width=79, debug=false) at write-po.c:1511
#6 0x0008036d8859 in msgdomain_list_print (mdlp=0x80f0071c0,
filename=0x80370a0a6 standard output, output_syntax=0x40d7b0, force=false,
debug=false)
at write-catalog.c:246
#7 0x00403604 in main (argc=3, argv=0x7fff0ff0) at msgmerge.c:463
It's a bit tweaked version, though.
%%
Index: devel/gettext/Makefile
===
RCS file: /a/.cvsup/ports/devel/gettext/Makefile,v
retrieving revision 1.87
diff -u -p -r1.87 Makefile
--- devel/gettext/Makefile 3 Jun 2010 09:46:38 - 1.87
+++ devel/gettext/Makefile 23 Aug 2010 10:04:26 -
@@ -28,7 +28,7 @@ CONFIGURE_ENV=ACLOCAL=${TRUE} \
AUTOHEADER=${TRUE} \
MAKEINFO=makeinfo --no-split \
CPPFLAGS=-I${LOCALBASE}/include \
- LDFLAGS=-L${LOCALBASE}/lib \
+ LDFLAGS=-L${LOCALBASE}/lib -liconv \
EMACS=no
CONFIGURE_ARGS=--disable-csharp --disable-threads --disable-openmp \
--with-included-gettext --with-included-glib \
@@ -65,6 +65,8 @@ pre-extract:
.endif
post-patch:
+ @${REINPLACE_CMD} 's/-DENABLE_RELOCATABLE=1//' \
+ ${WRKSRC}/gettext-runtime/intl/Makefile.in
@${FIND} ${WRKSRC} -name configure -print | ${XARGS} \
${REINPLACE_CMD} -e 's|mkdir gmkdir|mkdir|'
.if defined (NOPORTDOCS)
%%
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: [bsdgrep] -w option matches part of words (Was: Apache 2.2 port and missing modules on current.)
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 file_cache...
$ make -V APACHE_MODULES BATCH= | fgrep cache
...disk_cache file_cache...
I guess the failing line is below in bsd.apache.mk
${ECHO_CMD} ${WITHOUT_MODULES} | ${GREP} -wq $${module} 2
/dev/null || \
It can be reduced to
$ echo mem_cache | grep --color -w cache
I'm sorry for this issue, it didn't come up in the exp-run because it
didn't make the port actually fail. I have a fix in my queue, which I
sent to my mentor and I'll commit it soon.
Gabor
Thanks for your help with investigating this. I guess that in that
case submitting PR is unnecesary.
regards!
Here's quick confirmation that with sources builded yesterday, apache22
port compilation was succesful and all modules were populated as
expected. Thanks Gabor! :)
--
Bartosz Stec
___
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. bf1...@googlemail.com writes: Dag-Erling Smørgrav d...@des.no 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 actual grep command line and sample input that demonstrates the problem, the smaller the better: % echo elisp lisp | grep -w lisp echo good || echo bad elisp lisp good % echo elisp lisp | grep -wq lisp echo good || echo bad bad 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) : (notfound ? 2 : 1)); which shows that -q *does* affect the exit code, but my brain refuses to try to understand that code. 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
grep and Regular expression correctness
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 RE2 only supports Perl and fgrep syntax but not standard regex and Plan 9 implementation iirc only supports fgrep syntax and Unicode but not wchar_t in general. I specifically need to mention that the ideas used in the TRE algorithm can work, but that libtre is very buggy (see footnote [1]). 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. Luckily grep does not need the captured subexpressions, and thus does not need the complexity that comes from the ideas behind TRE. I use OS X which inherits an older freebsd suite of tools with bugs like this: echo XababaYababaZ | sed -E 's/((X)(aba|b|ab)(aba|b|ab)(Y)(aba|b|ab)*(Z))/[\1] = [\2][\3][\4][\5][\6][\7]/' [XababaYababaZ] = [X][ab][aba][Y][b][Z] Where the [b] between [Y] and [Z] is completely (insanely) wrong. It cannot even get the leftmost-longest correct: echo ab | sed -E 's/(()|.)(b)/[\1][\3]/' a[][b] Where the answer should have been the same as echo ab | sed -E 's/(.|())(b)/[\1][\3]/' [a][b] I have no idea if these bugs are still present in freebsd-current. Cheers, Chris Kuklewicz [1] libtre has problems such as this (from Haskell's regex-tre wrapper) searchme =~ s(()|^)e :: Array Int (MatchOffset,MatchLength) array (0,2) [(0,(0,2)),(1,(1,0)),(2,(1,0))] The above looks sane but re-ordering the alternative causes the match to fail: searchme =~ s(^|())e :: Array Int (MatchOffset,MatchLength) array (1,0) [] And the problems with ^ and $ are not the only ones: searchme =~ ((s)|(e)|(a))* :: Array Int (MatchOffset,MatchLength) array (0,4) [(0,(0,3)),(1,(2,1)),(2,(-1,0)),(3,(-1,0)),(4,(2,1))] The above is correct, but this is not: searchme =~ ((s)|(e)|())* :: Array Int (MatchOffset,MatchLength) array (0,4) [(0,(0,2)),(1,(1,1)),(2,(-1,0)),(3,(1,1)),(4,(2,0))] ___ 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 problems: powerd and/or hw.acpi.cpu.cx_lowest related
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 to work fine. Using one or the other sort of works, but between the 2 powerd seems to cause the most problems. I think this just means that when C3 is enabled the system is getting skewed results in cp_time[] and so the stats are off. The system isn't actually stuck in an interrupt storm of sorts, the numbers reported to top are just wrong so it looks like it is. -- 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: fusefs-kmod broken?
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 has been broken. Have others seen this? I've tried rebuilding everything from a clean slate but it doesn't help. The machine used to be -STABLE, which worked until 21 April 2010, but no kernel since has worked. brane.freislich.nom.za dumped core - see /var/crash/vmcore.7 Fri Aug 20 16:07:17 SAST 2010 FreeBSD brane.freislich.nom.za 9.0-CURRENT FreeBSD 9.0-CURRENT #4: Fri Aug 20 13:53:55 SAST 2010 i...@brane.freislich.nom.za:/usr/obj/usr/src/sys/BRANE i386 panic: page fault GNU gdb 6.1.1 [FreeBSD] Copyright 2004 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type show copying to see the conditions. There is absolutely no warranty for GDB. Type show warranty for details. This GDB was configured as i386-marcel-freebsd... Unread portion of the kernel message buffer: Fatal trap 12: page fault while in kernel mode fault virtual address = 0x0 fault code= supervisor read, page not present instruction pointer = 0x20:0x0 stack pointer = 0x28:0xe75d3b50 frame pointer = 0x28:0xe75d3c14 code segment = base 0x0, limit 0xf, type 0x1b = DPL 0, pres 1, def32 1, gran 1 processor eflags = interrupt enabled, resume, IOPL = 0 current process = 56578 (sh) trap number = 12 panic: page fault KDB: stack backtrace: db_trace_self_wrapper(c07b0ffc,e75d39e8,c05b4aff,c07af087,c0838240,...) at db_trace_self_wrapper+0x26 kdb_backtrace(c07af087,c0838240,c079b1a4,e75d39f4,e75d39f4,...) at kdb_backtrace+0x29 panic(c079b1a4,c07c9e3f,c784aca0,1,1,...) at panic+0xaf trap_fatal(c783e000,0,1,0,c782c8c0,...) at trap_fatal+0x353 trap_pfault(c274a3a8,0,c669eaa0,c784ab00,c7845000,...) at trap_pfault+0x25b trap(e75d3b10) at trap+0x423 calltrap() at calltrap+0x6 --- trap 0xc, eip = 0, esp = 0xe75d3b50, ebp = 0xe75d3c14 --- uart_z8530_class(c784ab00,ff9c,284052c4,0,402,...) at 0 kern_open(c784ab00,284052c4,0,601,1b6,...) at kern_open+0x35 open(c784ab00,e75d3cec,e75d3d28,e75d3d28,e75d3c02,...) at open+0x30 syscallenter(c784ab00,e75d3ce4,e75d3ce4,0,c784ab00,...) at syscallenter+0x343 syscall(e75d3d28) at syscall+0x34 Xint0x80_syscall() at Xint0x80_syscall+0x21 --- syscall (5, FreeBSD ELF32, open), eip = 0x281e579b, esp = 0xbfbfe96c, ebp = 0xbfbfea28 --- Uptime: 1h49m31s Physical memory: 2007 MB Dumping 194 MB: 179 163 147 131 115 99 83 67 51 35 19 3 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. -- 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: Latest intr problems
On Saturday, August 21, 2010 11:28:41 am Andriy Gapon wrote: on 21/08/2010 16:04 b. f. said the following: Andriy Gapon wrote: on 21/08/2010 12:35 Andriy Gapon said the following: I feel like you might be having a problem with clocks... FWIW, I am reading this document http://edc.intel.com/Link.aspx?id=1484 and I see this sentence: All of the clocks in the processor core are stopped in the C3 state. I see that you have C3 state enabled and it's regularly entered: dev.cpu.0.cx_usage: 0.00% 5.51% 94.48% last 305us I don't think this accounts for all of his problems, unless his machine has an unusual configuration. Well, let's try to not muddy the waters prematurely. It could easily account for it. If the lapic is going to sleep in C3, then you are actually missing statclock interrupts and likely screwing up the accounting (idle threads wouldn't accumulate time correctly for example). Even though his system really isn't spending a lot of time executing interrupts, the cp_time[] values would be skewed and wrong. -- 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: grep and Regular expression correctness
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. Luckily grep does not need the captured subexpressions, and thus does not need the complexity that comes from the ideas behind TRE. [etc] I think grep does potentially need the captured subexpressions, for eg: \([abc]\)99\1 matching eg b99b -- Bob Bishop r...@gid.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: fusefs-kmod broken?
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/vfs_syscalls.c:1040).
1035kern_open(struct thread *td, char *path, enum uio_seg pathseg, int
flags,
1036int mode)
1037{
1038
1039return (kern_openat(td, AT_FDCWD, path, pathseg, flags, mode));
1040}
1041
1042int
1043kern_openat(struct thread *td, int fd, char *path, enum uio_seg pathseg,
1044int flags, int mode)
That's what my reading seemed indicate. I had to downgrade the
system back to 8.0-STABLE at around 21 April 2010, to get the system
working.
I'm currently doing a binary search to find offending commit, since
CURRENT and STABLE panic reliably, and in the same way I'm sure
that the problem is common to both.
I'm down to a window of 9 hours. My money is currently on:
Working file: sys/kern/vfs_syscalls.c
Approved by:re (bz)
revision 1.487.2.7
date: 2010/04/27 10:47:54; author: kib; state: Exp; lines: +2 -15
SVN rev 207270 on 2010-04-27 10:47:54Z by kib
MFC r206547:
Handle a case in kern_openat() when vn_open() change file type from
DTYPE_VNODE.
Ian
--
Ian Freislich
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: fusefs-kmod broken?
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 to look.
(kgdb) l *kern_open+0x35
0xc0649ce5 is in kern_open (/usr/src/sys/kern/vfs_syscalls.c:1040).
1035kern_open(struct thread *td, char *path, enum uio_seg pathseg, int
flags,
1036int mode)
1037{
1038
1039return (kern_openat(td, AT_FDCWD, path, pathseg, flags,
mode));
1040}
1041
1042int
1043kern_openat(struct thread *td, int fd, char *path, enum uio_seg
pathseg,
1044int flags, int mode)
That's what my reading seemed indicate. I had to downgrade the
system back to 8.0-STABLE at around 21 April 2010, to get the system
working.
I'm currently doing a binary search to find offending commit, since
CURRENT and STABLE panic reliably, and in the same way I'm sure
that the problem is common to both.
I'm down to a window of 9 hours. My money is currently on:
Working file: sys/kern/vfs_syscalls.c
Approved by:re (bz)
revision 1.487.2.7
date: 2010/04/27 10:47:54; author: kib; state: Exp; lines: +2 -15
SVN rev 207270 on 2010-04-27 10:47:54Z by kib
MFC r206547:
Handle a case in kern_openat() when vn_open() change file type from
DTYPE_VNODE.
Which most likely means that fusesfs filled its own struct fileops
without properly initializing fo_truncate member.
pgpD99OIXMmOv.pgp
Description: PGP signature
Re: fusefs-kmod broken?
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
0xc0649ce5 is in kern_open (/usr/src/sys/kern/vfs_syscalls.c:1040).
1035kern_open(struct thread *td, char *path, enum uio_seg pathseg, int fl
ags,
1036int mode)
1037{
1038
1039return (kern_openat(td, AT_FDCWD, path, pathseg, flags, mode)
);
1040}
1041
1042int
1043kern_openat(struct thread *td, int fd, char *path, enum uio_seg paths
eg,
1044int flags, int mode)
That's what my reading seemed indicate. I had to downgrade the
system back to 8.0-STABLE at around 21 April 2010, to get the system
working.
I'm currently doing a binary search to find offending commit, since
CURRENT and STABLE panic reliably, and in the same way I'm sure
that the problem is common to both.
I'm down to a window of 9 hours. My money is currently on:
Working file: sys/kern/vfs_syscalls.c
Approved by:re (bz)
revision 1.487.2.7
date: 2010/04/27 10:47:54; author: kib; state: Exp; lines: +2 -15
SVN rev 207270 on 2010-04-27 10:47:54Z by kib
MFC r206547:
Handle a case in kern_openat() when vn_open() change file type from
DTYPE_VNODE.
Confirmed.
1.487.2.6 doesn't panic, 1.487.2.7 does. This is the change that
results in the panic.
--- sys/kern/vfs_syscalls.c 16 Apr 2010 08:32:08 - 1.487.2.6
+++ sys/kern/vfs_syscalls.c 27 Apr 2010 10:47:54 - 1.487.2.7
@@ -35,7 +35,7 @@
*/
#include sys/cdefs.h
-__FBSDID($FreeBSD: src/sys/kern/vfs_syscalls.c,v 1.487.2.6 2010/04/16
08:32:08 kib Exp $);
+__FBSDID($FreeBSD: src/sys/kern/vfs_syscalls.c,v 1.487.2.7 2010/04/27
10:47:54 kib Exp $);
#include opt_compat.h
#include opt_kdtrace.h
@@ -1047,8 +1047,6 @@
struct filedesc *fdp = p-p_fd;
struct file *fp;
struct vnode *vp;
- struct vattr vat;
- struct mount *mp;
int cmode;
struct file *nfp;
int type, indx, error;
@@ -1141,7 +1139,7 @@
}
VOP_UNLOCK(vp, 0);
- if (flags (O_EXLOCK | O_SHLOCK)) {
+ if (fp-f_type == DTYPE_VNODE (flags (O_EXLOCK | O_SHLOCK)) != 0) {
lf.l_whence = SEEK_SET;
lf.l_start = 0;
lf.l_len = 0;
@@ -1158,18 +1156,7 @@
atomic_set_int(fp-f_flag, FHASLOCK);
}
if (flags O_TRUNC) {
- if ((error = vn_start_write(vp, mp, V_WAIT | PCATCH)) != 0)
- goto bad;
- VATTR_NULL(vat);
- vat.va_size = 0;
- vn_lock(vp, LK_EXCLUSIVE | LK_RETRY);
-#ifdef MAC
- error = mac_vnode_check_write(td-td_ucred, fp-f_cred, vp);
- if (error == 0)
-#endif
- error = VOP_SETATTR(vp, vat, td-td_ucred);
- VOP_UNLOCK(vp, 0);
- vn_finished_write(mp);
+ error = fo_truncate(fp, 0, td-td_ucred, td);
if (error)
goto bad;
}
mount:
/dev/fuse0 on /1-wire (fusefs, local, synchronous)
Something about it has a write
echo -n 192 /1-wire/29.A52A0300/PIO.BYTE
Panic. But not like:
echo -n 192 /1-wire/29.A52A0300/PIO.BYTE
I suspect the truncate is not safe. Or, at least this fuse presented
fite cannot be truncated.
Ian
--
Ian Freislich
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: fusefs-kmod broken?
* Kostik Belousov kostik...@gmail.com 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 whether under INVARIATIONS all fileops are set? -- Ed Schouten e...@80386.nl WWW: http://80386.nl/ pgprc8w11HVSV.pgp Description: PGP signature
Re: fusefs-kmod broken?
* Ed Schouten e...@80386.nl wrote: check whether under INVARIATIONS all fileops are set? INVARIANTS, that is. -- Ed Schouten e...@80386.nl WWW: http://80386.nl/ pgp0MtaoWCOzp.pgp Description: PGP signature
Re: grep and Regular expression correctness
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 that comes with the operating system. Luckily grep does not need the captured subexpressions, and thus does not need the complexity that comes from the ideas behind TRE. [etc] I think grep does potentially need the captured subexpressions, for eg: \([abc]\)99\1 matching eg b99b That would be basic POSIX instead of extended POSIX regular expressions. Making basic regular expressions correct is something I have never attempted. Correctness is what I would like to emphasize. GNU grep defines the regex.h header for POSIX regular expressions but does not try to deliver the correct POSIX answer. Getting the wrong answer quickly is not a virtue as debugging prematurely optimized code is too hard. http://www2.research.att.com/~gsf/testregex/re-interpretation.html has the best explanation of basic and extended POSIX regular expressions. And last I checked the ATT code was nearly correct but exponentially slow. I hope that if grep in *BSD and thus OSX gets worked on that it gets more correct, not less. I hope that someday the regex.h engine in *BSD and thus OSX gets fixed, but I am not holding my breath for that. All I have written is a correct (and efficient) extended POSIX matching engine in Haskell and OCaml. Cheers, Chris Kuklewicz ___ 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: fusefs-kmod broken?
On Mon, Aug 23, 2010 at 03:35:55PM +0200, Ed Schouten wrote: * Kostik Belousov kostik...@gmail.com 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 I do not understand your first sentence. Would you please elaborate ? check whether under INVARIATIONS all fileops are set? -- Ed Schouten e...@80386.nl WWW: http://80386.nl/ pgpgzReOqeOyy.pgp Description: PGP signature
Re: fusefs-kmod broken?
* Kostik Belousov kostik...@gmail.com wrote: On Mon, Aug 23, 2010 at 03:35:55PM +0200, Ed Schouten wrote: * Kostik Belousov kostik...@gmail.com 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 I do not understand your first sentence. Would you please elaborate ? Say, you create a cdev, if you don't implement all ops, it will check for null pointers and return error codes accordingly. This doesn't happen for fileops, which is probably one of the reasons why people sometimes forget to implement them. Wouldn't it be better to prevent this form of footshooting by adding assertions? This will add some overhead for any file descriptor created, but a kernel with INVARIANTS isn't meant to be fast. -- Ed Schouten e...@80386.nl WWW: http://80386.nl/ pgpM8zdFvppwk.pgp Description: PGP signature
Re: fusefs-kmod broken?
On Mon, Aug 23, 2010 at 03:47:23PM +0200, Ed Schouten wrote: * Kostik Belousov kostik...@gmail.com wrote: On Mon, Aug 23, 2010 at 03:35:55PM +0200, Ed Schouten wrote: * Kostik Belousov kostik...@gmail.com 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 I do not understand your first sentence. Would you please elaborate ? Say, you create a cdev, if you don't implement all ops, it will check for null pointers and return error codes accordingly. This doesn't happen for fileops, which is probably one of the reasons why people sometimes forget to implement them. Wouldn't it be better to prevent this form of footshooting by adding assertions? This will add some overhead for any file descriptor created, but a kernel with INVARIANTS isn't meant to be fast. Thanks, I see it now. The cdev interface definitely falls into the public kernel interface. Having to fill all cdevsw methods for a random driver is too much burden put on the several dozens maintainers. On the other hand, file level is not much widely used by third-party components, and even in-tree code implements only ten different file types. 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. pgp3IhHedgsuI.pgp Description: PGP signature
Re: fusefs-kmod broken?
* Kostik Belousov kostik...@gmail.com 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 them in finit(), because that way you as a programmer will get punished as soon as possible, namely when you implement the new type of file descriptor. Putting them in the fo_XXX() wrappers makes little sense, because that will only cause a panic 1 microsecond before it would have crashed on the null pointer anyway. -- Ed Schouten e...@80386.nl WWW: http://80386.nl/ pgpZiWUF2pFRF.pgp Description: PGP signature
Re: fusefs-kmod broken?
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 kostik...@gmail.com wrote:
On Mon, Aug 23, 2010 at 03:35:55PM +0200, Ed Schouten wrote:
* Kostik Belousov kostik...@gmail.com wrote:
Which most likely means that fusesfs filled its own struct fileops
without properly initializing fo_truncate member.
=20
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
I do not understand your first sentence. Would you please elaborate ?
=20
Say, you create a cdev, if you don't implement all ops, it will check
for null pointers and return error codes accordingly. This doesn't
happen for fileops, which is probably one of the reasons why people
sometimes forget to implement them.
=20
Wouldn't it be better to prevent this form of footshooting by adding
assertions? This will add some overhead for any file descriptor created,
but a kernel with INVARIANTS isn't meant to be fast.
Thanks, I see it now.
The cdev interface definitely falls into the public kernel interface.
Having to fill all cdevsw methods for a random driver is too much
burden put on the several dozens maintainers.
On the other hand, file level is not much widely used by third-party
components, and even in-tree code implements only ten different file
types.
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.
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, you don't get stung again.
Patch attached to that makes fusefs-kmod not blowup kernels post this change.
Ian
--
Ian Freislich
Index: files/patch-fuse_module__fuse_vnops.c
===
RCS file:
/home/ncvs/ports/sysutils/fusefs-kmod/files/patch-fuse_module__fuse_vnops.c,v
retrieving revision 1.4
diff -u -d -r1.4 patch-fuse_module__fuse_vnops.c
--- files/patch-fuse_module__fuse_vnops.c 30 Oct 2008 15:36:35 -
1.4
+++ files/patch-fuse_module__fuse_vnops.c 23 Aug 2010 14:27:17 -
+@@ -214,6 +214,7 @@
+ * following fields are filled from vnops, but vnops.foo is not
+ * legitimate in a definition, so we set them at module load time
+*/
++ .fo_truncate = NULL,
+ .fo_ioctl= NULL,
+ .fo_poll = NULL,
+ .fo_kqfilter = NULL,
+@@ -799,8 +800,11 @@
struct vnode *vp = ap-a_vp;
struct vattr *vap = ap-a_vap;
struct ucred *cred = ap-a_cred;
@@ -13,7 +21,7 @@
struct fuse_dispatcher fdi;
struct timespec uptsp;
int err = 0;
-@@ -871,7 +874,11 @@
+@@ -871,7 +875,11 @@
fuse_access(ap)
struct vop_access_args /* {
struct vnode *a_vp;
@@ -25,7 +33,7 @@
struct ucred *a_cred;
struct thread *a_td;
} */ *ap;
-@@ -886,7 +893,13 @@
+@@ -886,7 +894,13 @@
else
facp.facc_flags |= FACCESS_DO_ACCESS;
@@ -40,7 +48,7 @@
}
/*
-@@ -946,7 +959,11 @@
+@@ -946,7 +960,11 @@
/* We are to do the check in-kernel */
if (! (facp-facc_flags FACCESS_VA_VALID)) {
@@ -53,7 +61,7 @@
if (err)
return (err);
facp-facc_flags |= FACCESS_VA_VALID;
-@@ -1929,7 +1946,11 @@
+@@ -1929,7 +1947,11 @@
* It will not invalidate pages which are dirty, locked, under
* writeback or mapped into pagetables.)
*/
@@ -65,7 +73,7 @@
fufh-flags |= FOPEN_KEEP_CACHE;
}
-@@ -3005,8 +3026,11 @@
+@@ -3005,8 +3027,11 @@
struct vattr *vap = ap-a_vap;
struct vnode *vp = ap-a_vp;
struct ucred *cred = ap-a_cred;
___
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: fusefs-kmod broken?
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 Schouten wrote: * Kostik Belousov kostik...@gmail.com wrote: On Mon, Aug 23, 2010 at 03:35:55PM +0200, Ed Schouten wrote: * Kostik Belousov kostik...@gmail.com wrote: Which most likely means that fusesfs filled its own struct fileops without properly initializing fo_truncate member. =20 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 I do not understand your first sentence. Would you please elaborate ? =20 Say, you create a cdev, if you don't implement all ops, it will check for null pointers and return error codes accordingly. This doesn't happen for fileops, which is probably one of the reasons why people sometimes forget to implement them. =20 Wouldn't it be better to prevent this form of footshooting by adding assertions? This will add some overhead for any file descriptor created, but a kernel with INVARIANTS isn't meant to be fast. Thanks, I see it now. The cdev interface definitely falls into the public kernel interface. Having to fill all cdevsw methods for a random driver is too much burden put on the several dozens maintainers. On the other hand, file level is not much widely used by third-party components, and even in-tree code implements only ten different file types. 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. 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, you don't get stung again. Patch attached to that makes fusefs-kmod not blowup kernels post this change. Ian -- Ian Freislich Index: files/patch-fuse_module__fuse_vnops.c === RCS file: /home/ncvs/ports/sysutils/fusefs-kmod/files/patch-fuse_module__fuse_vnops.c,v retrieving revision 1.4 diff -u -d -r1.4 patch-fuse_module__fuse_vnops.c --- files/patch-fuse_module__fuse_vnops.c 30 Oct 2008 15:36:35 - 1.4 +++ files/patch-fuse_module__fuse_vnops.c 23 Aug 2010 14:27:17 - +@@ -214,6 +214,7 @@ + * following fields are filled from vnops, but vnops.foo is not + * legitimate in a definition, so we set them at module load time + */ ++.fo_truncate = NULL, + .fo_ioctl= NULL, + .fo_poll = NULL, + .fo_kqfilter = NULL, Did you tested this ? I suppose that it would not change anything. Fuse, most likely, lacks real implementation of .fo_truncate method. The implementation was required for long time, otherwise file truncation would not work. pgp6NZTNqf4rm.pgp Description: PGP signature
Re: fusefs-kmod broken?
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, you don't get stung again.
I am an idiot - that will have no effect. This patch needs to be
included in sysutils/fusefs-kmod/files
--
Ian Freislich
patch-fuse_module__fuse_main.c
--- fuse_module/fuse_main.c.orig2010-08-23 16:52:20.0 +0200
+++ fuse_module/fuse_main.c 2010-08-23 16:48:17.0 +0200
@@ -108,6 +108,7 @@
switch (what) {
case MOD_LOAD:/* kldload */
+ fuse_fileops.fo_truncate = vnops.fo_truncate;
fuse_fileops.fo_ioctl= vnops.fo_ioctl;
fuse_fileops.fo_poll = vnops.fo_poll;
fuse_fileops.fo_kqfilter = vnops.fo_kqfilter;
___
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
What to learn from the BSD grep case [Was: why GNU grep is fast]
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 understanding, -CURRENT is for development and it's fine to expose new pieces of work there but now I'm in doubt about that because of complaining people. On the other hand, an earlier version of BSD grep has been in the ports tree for a very long time and users reported some problems, which have been fixed but still, there is a lot of bugs there which haven't been reported that time. If users don't volunteer to test new pieces of code on a volunteer basis, somehow we have to make them test it, so I think committing BSD grep to -CURRENT was a good decision in the first round. 2, This issue also brought up some bottlenecks and potential optimization points (like memchr() and mmap), which other softwre may benefit from. This is another reason to let such pieces of work in. But unfortunately, this means that noone profiled another utilities because these bottlenecks remained undiscovered. Neither did I. It's a lesson that we have to learn from this particular case. 3, Because of point 2, we need more content to developers-handbook to help development with such ideas and best practices. It has been also raised on another list that our end-user documentation isn't that shiny and cool that it used to be and actually, developers-handbook has never been finished to be more or less complete. If someone looks at it, it looks like a sketch, not a book. I'll see if I can write a section on profiling. 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 slow when I checked it. PCRE supports Perl-style syntax with a POSIX-like API but not POSIX regex. Google RE2 is the same with additional egrep syntax but doesn't have support for standard POSIX regexes. Plan 9 regex only supports egrep syntax. It seems that TRE is the best choice. It is BSD-licensed, supports wchar and POSIX(ish) regexes and it is quite fast. I don't know the theoretical background of regex engines but I'm wondering if it's possible top provide an alternative API with byte-counted buffers and use the heuristical speedup with fixed string matching. As Mike pointed out the POSIX API is quite limiting because it works on NUL-terminated strings and not on byte-counted buffers, so we couldn't just do it with a POSIX-conformant library but it would be nice if we could implement it in such a library with an alternative interface. Gabor ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Official request: Please make GNU grep the default
Dag-Erling Smørgrav d...@des.no 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) : (notfound ? 2 : 1)); which shows that -q *does* affect the exit code, but my brain refuses to try to understand that code. My brain is in need of a break from $REALJOB. POSIX says EXIT STATUS The following exit values shall be returned: 0 One or more lines were selected. 1 No lines were selected. 1 An error occurred. CONSEQUENCES OF ERRORS If the -q option is specified, the exit status shall be zero if an input line is selected, even if an error was detected. Otherwise, default actions shall be performed. I suppose c is supposed to indicate, in some manner, whether an error occurred, but it's hard to tell; the code seems almost deliberately obfuscated. The name gives no clue whatsoever as to its meaning. It is incremented like a counter, but tested like a boolean. Its value is derived from the value returned by procfile(), but that value is also named c, and is derived from values returned by other functions which I could not be bothered to track down. In any case - c notfoundqflag result truetruetrue0 truetruefalse 2 truefalse true0 truefalse false 0 false truetrue2 false truefalse 2 false false true1 false false false 1 By this point, my brain is tied into the shape of a pretzel, but it looks like c might actually be a count of matching lines and notfound might be an error flag. I give it -10 for calling the count c instead of count or matches (I'm being generous because c is the first letter of count), another -10 for testing it as a boolean instead of comparing it to 0, -1,000 for calling the error flag notfound, and -1,000,000 for writing code so convoluted that, even with the source code in front of me, I had to reverse-engineer it to figure out what it does. I think that adds up to -1,001,020. 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: Latest intr problems
On 8/23/10, John Baldwin j...@freebsd.org wrote: On Saturday, August 21, 2010 11:28:41 am Andriy Gapon wrote: on 21/08/2010 16:04 b. f. said the following: Andriy Gapon wrote: on 21/08/2010 12:35 Andriy Gapon said the following: I feel like you might be having a problem with clocks... FWIW, I am reading this document http://edc.intel.com/Link.aspx?id=1484 and I see this sentence: All of the clocks in the processor core are stopped in the C3 state. I see that you have C3 state enabled and it's regularly entered: dev.cpu.0.cx_usage: 0.00% 5.51% 94.48% last 305us I don't think this accounts for all of his problems, unless his machine has an unusual configuration. Well, let's try to not muddy the waters prematurely. It could easily account for it. If the lapic is going to sleep in C3, then you are actually missing statclock interrupts and likely screwing up the accounting (idle threads wouldn't accumulate time correctly for example). Even though his system really isn't spending a lot of time executing interrupts, the cp_time[] values would be skewed and wrong. Right, I can easily see how it is _a_ problem. I remembered that it was the reason Alexander gave for reviving the use of the rtc and the i8254 as eventtimers/timecounters, and it's partly why I suggested switching clock sources earlier. My point in my reply to Andriy was that Doug had reported similar problems when the hpet was the sole eventtimer/timecounter, and also when the i8254 was the only one, which suggested that there were other problems, too. But then Doug also assured me that he was satisfied that usb wasn't the source of the problem, where now he and Andriy seem to think it plays a primary role, so I give up. I only hope that new interrupt-handling that you are working on makes the system less susceptible to these kinds of problems. b. ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Official request: Please make GNU grep the default
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 the 'lisp' in a port
Makefile, were it not for the -w flag. 'x11' succeeds, but it
precedes all of the x11-* categories. I suspect that there is an
error in the logic of either the -w or the -q flag implementation in
bsdgrep, which causes problems when the two options are used together.
The target succeeds as expected with GNU grep.
Can you please try the following patch? I think this solves more than
one problem in bsdgrep's logic, but it needs to be reviewed by Gabor and
others.
In usr.bin/grep/util.c, in the function procline(), there is the
following fragment:
290 /* Loop to process the whole line */
291 while (st = l-len) {
[...]
295 /* Loop to compare with all the patterns */
296 for (i = 0; i patterns; i++) {
[... sets r to 0 if a match was found ...]
336 if (r == 0) {
[...]
341 /* matches - skip further patterns
*/
342 if ((color != NULL !oflag) ||
qflag || lflag)
343 break;
344 }
345 }
[...]
351 /* One pass if we are not recording matches */
352 if ((color != NULL !oflag) || qflag || lflag)
353 break;
[...]
357 }
If during the first iteration of the loop to process the whole line
no match was found (for example, if doing a word search for lisp and
the string elisp is found instead), AND the -q option was used, the
test in line 352 aborts the whole loop, without searching any further!
Thus it will miss the lisp string later in the line.
It looks like line 352 should only be evaluated if the for() loop just
above it resulted in one or or more matches, so it is probably easiest
to just replace line 343 with a goto that jumps out of the two enclosing
loops (it is still a pity C does not have a break 2 statement), and
delete lines 351..353 entirely.
However, if there are unintended side effects, for example with weird
combinations of the --color, -o and/or -l flags, please let me know. :)
diff --git a/usr.bin/grep/util.c b/usr.bin/grep/util.c
index c65d8f2..97a14f3 100644
--- a/usr.bin/grep/util.c
+++ b/usr.bin/grep/util.c
@@ -340,7 +340,7 @@ procline(struct str *l, int nottext)
matches[m++] = pmatch;
/* matches - skip further patterns */
if ((color != NULL !oflag) || qflag
|| lflag)
- break;
+ goto skip;
}
}
@@ -348,9 +348,6 @@ procline(struct str *l, int nottext)
c = !c;
break;
}
- /* One pass if we are not recording matches */
- if ((color != NULL !oflag) || qflag || lflag)
- break;
if (st == (size_t)pmatch.rm_so)
break; /* No matches */
@@ -358,6 +355,7 @@ procline(struct str *l, int nottext)
} else
c = !vflag;
+skip:
if (c binbehave == BINFILE_BIN nottext)
return (c); /* Binary file */
___
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: What to learn from the BSD grep case [Was: why GNU grep is fast]
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 bug reports and sharp criticism, as well. According to my understanding, -CURRENT is for development and it's fine to expose new pieces of work there but now I'm in doubt about that because of complaining people. On the other hand, an earlier version of BSD grep has been in the ports tree for a very long time and users reported some problems, which have been fixed but still, there is a lot of bugs there which haven't been reported that time. If users don't volunteer to test new pieces of code on a volunteer basis, somehow we have to make them test it, so I think committing BSD grep to -CURRENT was a good decision in the first round. You did everything right. You were responsive, you were open to suggestions, and you got the code in. Even more importantly, you got the code in a year before 9.0, instead of waiting until the last minute, months from now, and creating a dilemma for the release engineers. Software is an iterative process of feedback and improvement. The way that you've handled this should be a model for the project. Scott ___ 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 wrote: Alan Cox a...@cs.rice.edu 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 have thought the system time for gnugrep and bsdgrep would be almost the same. Two reasons: 1) BSD grep does tons of unnecessary memory-to-memory copy operations in grep_fgetln(). 2) GNU grep has its own highly optimized regex code. Umm, not really. Notice that I said system time not user time. Even after the recent changes to optimize the I/O in bsdgrep, Dimitry's results show that bsdgrep is spending more than twice as much time in the kernel as gnugrep. That said, in the end, you may be right in the sense that the user space inefficiencies may indirectly result in more cache misses in the kernel because the additional user space memory used by bsdgrep displaces more kernel data from the cache between system calls. However, I would not jump to that conclusion. The explanation for the difference in system time may be more straightforward and easy to fix. It would be nice to see a comparison of bsdgrep and gnugrep using pmcstat to profile L2 cache misses. That might be enlightening. 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: runaway intr problems: powerd and/or hw.acpi.cpu.cx_lowest related
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_lowest less than C1 things seem to work fine. Using one or the other sort of works, but between the 2 powerd seems to cause the most problems. I think this just means that when C3 is enabled the system is getting skewed results in cp_time[] and so the stats are off. The system isn't actually stuck in an interrupt storm of sorts, the numbers reported to top are just wrong so it looks like it is. That may be true, however what's happening at that time is that the video and audio both become choppy (as in, painfully so) and every other thing that's running, whether it's desktop clients like thunderbird or something being compiled, also moves very very slow, as if it's resource-starved. So while I'm perfectly ready to admit that the top output may be just a symptom instead of the real problem, something fundamentally bad IS happening under the hood. 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
New FreeBSD SVN seed snapshot
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 snapshot can be found at: ftp://ftp.freebsd.org/pub/FreeBSD/development/subversion/ You need ports/archivers/xz installed if you aren't running FreeBSD 8.1+. Thanks to rpaulo and bz for prodding my into finding out how this worked and making the new snapshot :-). I can't think of what else to say, so that was probably it :-). -- Simon L. B. Nielsen Hat: svn janitor ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: CFT: xl(4) WOL
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 don't know whether WOL really works or not but I did not see any regressions. If you're user of xl(4) please give it try and let me know whether I introduced regressions. You can find latest WOL patch at the following URL. http://people.freebsd.org/~yongari/xl/xl.wol.patch FYI: Patch committed to HEAD(r211717). ___ 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: New FreeBSD SVN seed snapshot
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/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: New FreeBSD SVN seed snapshot
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 (svnmirror-base-r211583.tar.xz) = 893293980 SHA256 (svnmirror-base-r211583.tar.xz) = aeb176e4f8121e1ceab9be3acbc15d7d09995de2a5262e1db5999f92571799a1 MD5 (svnmirror-base-r211583.tar.xz) = caf3ba55c2d5bf3c140b2127b6722ae6 -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (Darwin) iEYEARECAAYFAkxy2ZQACgkQFdaIBMps37IHcwCgiqbxZGzaVHwujhPpvQcFarM0 ZEMAn2P9KtafEfr5OBfgSy9wtG94sOKD =0Y7Z -END PGP SIGNATURE- I'm using a new MUA so I'm not entirely sure if will leave the above signature without mangling it... If it fails, for now the info is at http://people.freebsd.org/~simon/tmp/seedinfo.txt.asc (will go away at some point in the future). -- Simon L. B. Nielsen ___ 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: softupdate with journal panic
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 seems identical to this report:
http://docs.freebsd.org/cgi/mid.cgi?AANLkTinPjiOV21kDLZYV5WScrhLMN7DY8E8jVHWPU5mC
I believe that dotdotremref in this case is legitimately NULL. With this
assumption, the following patch would help.
diff --git a/sys/ufs/ffs/ffs_softdep.c b/sys/ufs/ffs/ffs_softdep.c
index b666c0f..65e5255 100644
--- a/sys/ufs/ffs/ffs_softdep.c
+++ b/sys/ufs/ffs/ffs_softdep.c
@@ -6770,7 +6794,8 @@ cancel_diradd(dap, dirrem, jremref, dotremref,
dotdotremref)
mkdir-md_jaddref = NULL;
if (mkdir-md_state MKDIR_PARENT) {
if (cancel_jaddref(jaddref, NULL,
- dirrem-dm_jwork) == 0) {
+ dirrem-dm_jwork) == 0
+ dotdotremref != NULL) {
free_jremref(dotdotremref);
dotdotremref = NULL;
}
pgpC3HRGXzRwT.pgp
Description: PGP signature
[head tinderbox] failure on powerpc/powerpc
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/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/HEAD/powerpc/powerpc/supfile TB --- 2010-08-23 20:44:39 - building world TB --- 2010-08-23 20:44:39 - MAKEOBJDIRPREFIX=/obj TB --- 2010-08-23 20:44:39 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2010-08-23 20:44:39 - TARGET=powerpc TB --- 2010-08-23 20:44:39 - TARGET_ARCH=powerpc TB --- 2010-08-23 20:44:39 - TZ=UTC TB --- 2010-08-23 20:44:39 - __MAKE_CONF=/dev/null TB --- 2010-08-23 20:44:39 - cd /src TB --- 2010-08-23 20:44:39 - /usr/bin/make -B buildworld World build started on Mon Aug 23 20:44:39 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 [...] cc -O2 -pipe -DLOADER_DISK_SUPPORT -DLOADER_UFS_SUPPORT -DLOADER_CD9660_SUPPORT -DLOADER_GZIP_SUPPORT -DLOADER_NET_SUPPORT -DLOADER_NFS_SUPPORT -DBOOT_FORTH -I/src/sys/boot/powerpc/ofw/../../ficl -I/src/sys/boot/powerpc/ofw/../../ficl/powerpc -DNETIF_OPEN_CLOSE_ONCE -I/src/sys/boot/powerpc/ofw/../../common -I/src/sys/boot/powerpc/ofw/../../.. -I. -ffreestanding -msoft-float -DRELOC=0x1C0 -Wa,-mppc64bridge -I/src/sys/boot/powerpc/ofw/../../ofw/libofw -I/src/sys/boot/powerpc/ofw/../../../../lib/libstand/ -std=gnu99 -c /src/sys/boot/powerpc/ofw/../../common/load_elf32.c cc -O2 -pipe -DLOADER_DISK_SUPPORT -DLOADER_UFS_SUPPORT -DLOADER_CD9660_SUPPORT -DLOADER_GZIP_SUPPORT -DLOADER_NET_SUPPORT -DLOADER_NFS_SUPPORT -DBOOT_FORTH -I/src/sys/boot/powerpc/ofw/../../ficl -I/src/sys/boot/powerpc/ofw/../../ficl/powerpc -DNETIF_OPEN_CLOSE_ONCE -I/src/sys/boot/powerpc/ofw/../../common -I/src/sys/boot/powerpc/ofw/../../.. -I. -ffreestanding -msoft-float -DRELOC=0x1C0 -Wa,-mppc64bridge -I/src/sys/boot/powerpc/ofw/../../ofw/libofw -I/src/sys/boot/powerpc/ofw/../../../../lib/libstand/ -std=gnu99 -c /src/sys/boot/powerpc/ofw/../../common/reloc_elf32.c cc -O2 -pipe -DLOADER_DISK_SUPPORT -DLOADER_UFS_SUPPORT -DLOADER_CD9660_SUPPORT -DLOADER_GZIP_SUPPORT -DLOADER_NET_SUPPORT -DLOADER_NFS_SUPPORT -DBOOT_FORTH -I/src/sys/boot/powerpc/ofw/../../ficl -I/src/sys/boot/powerpc/ofw/../../ficl/powerpc -DNETIF_OPEN_CLOSE_ONCE -I/src/sys/boot/powerpc/ofw/../../common -I/src/sys/boot/powerpc/ofw/../../.. -I. -ffreestanding -msoft-float -DRELOC=0x1C0 -Wa,-mppc64bridge -I/src/sys/boot/powerpc/ofw/../../ofw/libofw -I/src/sys/boot/powerpc/ofw/../../../../lib/libstand/ -std=gnu99 -c /src/sys/boot/powerpc/ofw/../../common/dev_net.c cc -O2 -pipe -DLOADER_DISK_SUPPORT -DLOADER_UFS_SUPPORT -DLOADER_CD9660_SUPPORT -DLOADER_GZIP_SUPPORT -DLOADER_NET_SUPPORT -DLOADER_NFS_SUPPORT -DBOOT_FORTH -I/src/sys/boot/powerpc/ofw/../../ficl -I/src/sys/boot/powerpc/ofw/../../ficl/powerpc -DNETIF_OPEN_CLOSE_ONCE -I/src/sys/boot/powerpc/ofw/../../common -I/src/sys/boot/powerpc/ofw/../../.. -I. -ffreestanding -msoft-float -DRELOC=0x1C0 -Wa,-mppc64bridge -I/src/sys/boot/powerpc/ofw/../../ofw/libofw -I/src/sys/boot/powerpc/ofw/../../../../lib/libstand/ -std=gnu99 -c /src/sys/boot/powerpc/ofw/../../common/interp_forth.c cc -O2 -pipe -DLOADER_DISK_SUPPORT -DLOADER_UFS_SUPPORT -DLOADER_CD9660_SUPPORT -DLOADER_GZIP_SUPPORT -DLOADER_NET_SUPPORT -DLOADER_NFS_SUPPORT -DBOOT_FORTH -I/src/sys/boot/powerpc/ofw/../../ficl -I/src/sys/boot/powerpc/ofw/../../ficl/powerpc -DNETIF_OPEN_CLOSE_ONCE -I/src/sys/boot/powerpc/ofw/../../common -I/src/sys/boot/powerpc/ofw/../../.. -I. -ffreestanding -msoft-float -DRELOC=0x1C0 -Wa,-mppc64bridge -I/src/sys/boot/powerpc/ofw/../../ofw/libofw -I/src/sys/boot/powerpc/ofw/../../../../lib/libstand/ -std=gnu99 -c /src/sys/boot/powerpc/ofw/../../ofw/common/main.c cc -O2 -pipe -DLOADER_DISK_SUPPORT -DLOADER_UFS_SUPPORT -DLOADER_CD9660_SUPPORT -DLOADER_GZIP_SUPPORT -DLOADER_NET_SUPPORT -DLOADER_NFS_SUPPORT -DBOOT_FORTH -I/src/sys/boot/powerpc/ofw/../../ficl -I/src/sys/boot/powerpc/ofw/../../ficl/powerpc -DNETIF_OPEN_CLOSE_ONCE -I/src/sys/boot/powerpc/ofw/../../common -I/src/sys/boot/powerpc/ofw/../../.. -I. -ffreestanding -msoft-float -DRELOC=0x1C0 -Wa,-mppc64bridge -I/src/sys/boot/powerpc/ofw/../../ofw/libofw -I/src/sys/boot/powerpc/ofw/../../../../lib/libstand/ -std=gnu99 -nostdlib -static -T /src/sys/boot/powerpc/ofw/ldscript.powerpc -o loader conf.o metadata.o vers.o start.o ucmpdi2.o boot.o commands.o console.o devopen.o interp.o interp_backslash.o interp_parse.o ls.o misc.o module.o panic.o load_elf32.o reloc_elf32.o dev_net.o interp_forth.o main.o
Re: What to learn from the BSD grep case [Was: why GNU grep is fast]
On Mon, Aug 23, 2010 at 5:04 PM, Gabor Kovesdan ga...@freebsd.org 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 slow when I checked it. PCRE supports Perl-style syntax with a POSIX-like API but not POSIX regex. Google RE2 is the same with additional egrep syntax but doesn't have support for standard POSIX regexes. Plan 9 regex only supports egrep syntax. It seems that TRE is the best choice. It is BSD-licensed, supports wchar and POSIX(ish) regexes and it is quite fast. I know it's C++ and not exactly what you're needing, but have you evaluated Boost::Regex? Isn't there some code that can be retrofitted into a C lib? http://www.boost.org/doc/libs/1_44_0/libs/regex/doc/html/index.html I don't know the theoretical background of regex engines but I'm wondering if it's possible top provide an alternative API with byte-counted buffers and use the heuristical speedup with fixed string matching. As Mike pointed out the POSIX API is quite limiting because it works on NUL-terminated strings and not on byte-counted buffers, so we couldn't just do it with a POSIX-conformant library but it would be nice if we could implement it in such a library with an alternative interface. Gabor -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
Sleep/Lenovo SL410
Hope double post is ok, have issue with -CURRENT and ACPI. Kernel is ~week old cvsup -CURRENT amd64, issue has occurred with all versions of freebsd amd64 tried, however. Upon entering S3 sleep (or S4), the laptop emits 3 loud beeps and the sleep indicator begins flashing faster than normal. Older -CURRENT kernels also result in spinning fans at this point, which no longer occurs. Device will remain in this state indefinitely. Device must be powered off using the ten second rule. Occurs with custom kernel as well as GENERIC. Last entry is /var/log/messages is: Aug 23 17:59:09 ono-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 dump: http://pastebin.com/buQktjnq Dmesg: Copyright (c) 1992-2010 The FreeBSD Project. Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 The Regents of the University of California. All rights reserved. FreeBSD is a registered trademark of The FreeBSD Foundation. FreeBSD 9.0-CURRENT #2: Sun Aug 15 23:33:22 PDT 2010 r...@ono-sendai.local:/usr/obj/usr/src/sys/ONOSENDAI amd64 CPU: Intel(R) Core(TM)2 Duo CPU T6570 @ 2.10GHz (2094.80-MHz K8-class CPU) Origin = GenuineIntel Id = 0x1067a Family = 6 Model = 17 Stepping = 10 Features=0xbfebfbffFPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CLFLUSH,DTS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE Features2=0x408e3bdSSE3,DTES64,MON,DS_CPL,VMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,SSE4.1,XSAVE AMD Features=0x20100800SYSCALL,NX,LM AMD Features2=0x1LAHF TSC: P-state invariant real memory = 4294967296 (4096 MB) avail memory = 3927597056 (3745 MB) Event timer LAPIC frequency 0 Hz quality 500 ACPI APIC Table: LENOVO TP-6J FreeBSD/SMP: Multiprocessor System Detected: 2 CPUs FreeBSD/SMP: 1 package(s) x 2 core(s) cpu0 (BSP): APIC ID: 0 cpu1 (AP): APIC ID: 1 ioapic0 Version 2.0 irqs 0-23 on motherboard kbd1 at kbdmux0 cryptosoft0: software crypto on motherboard acpi0: LENOVO TP-6J on motherboard acpi0: [ITHREAD] acpi0: Power Button (fixed) hpet0: High Precision Event Timer iomem 0xfed0-0xfed003ff on acpi0 Timecounter HPET frequency 14318180 Hz quality 900 hpet0: [FILTER] Event timer HPET frequency 14318180 Hz quality 450 Event timer HPET1 frequency 14318180 Hz quality 440 Event timer HPET2 frequency 14318180 Hz quality 440 Event timer HPET3 frequency 14318180 Hz quality 440 Timecounter ACPI-safe frequency 3579545 Hz quality 850 acpi_timer0: 24-bit timer at 3.579545MHz port 0x408-0x40b on acpi0 cpu0: ACPI CPU on acpi0 cpu1: ACPI CPU on acpi0 acpi_ec0: Embedded Controller: GPE 0x17 port 0x62,0x66 on acpi0 pcib0: ACPI Host-PCI bridge port 0xcf8-0xcff on acpi0 pci0: ACPI PCI bus on pcib0 vgapci0: VGA-compatible display port 0x1800-0x1807 mem 0xf240-0xf27f,0xd000-0xdfff irq 16 at device 2.0 on pci0 agp0: Intel GM45 SVGA controller on vgapci0 agp0: aperture size is 256M, detected 131068k stolen memory drm0: Mobile Intel\M-B\M-. GM45 Express Chipset on vgapci0 info: [drm] MSI enabled 1 message(s) vgapci0: child drm0 requested pci_enable_busmaster info: [drm] AGP at 0xd000 256MB info: [drm] Initialized i915 1.6.0 20080730 vgapci1: VGA-compatible display mem 0xf210-0xf21f at device 2.1 on pci0 uhci0: Intel 82801I (ICH9) USB controller port 0x1820-0x183f irq 16 at device 26.0 on pci0 uhci0: [ITHREAD] usbus0: Intel 82801I (ICH9) USB controller on uhci0 uhci1: Intel 82801I (ICH9) USB controller port 0x1840-0x185f irq 21 at device 26.1 on pci0 uhci1: [ITHREAD] usbus1: Intel 82801I (ICH9) USB controller on uhci1 uhci2: Intel 82801I (ICH9) USB controller port 0x1860-0x187f irq 19 at device 26.2 on pci0 uhci2: [ITHREAD] usbus2: Intel 82801I (ICH9) USB controller on uhci2 ehci0: Intel 82801I (ICH9) USB 2.0 controller mem 0xf2a04800-0xf2a04bff irq 19 at device 26.7 on pci0 ehci0: [ITHREAD] usbus3: EHCI version 1.0 usbus3: Intel 82801I (ICH9) USB 2.0 controller on ehci0 hdac0: Intel 82801I High Definition Audio Controller mem 0xf2a0-0xf2a03fff irq 22 at device 27.0 on pci0 hdac0: HDA Driver Revision: 20100226_0142 hdac0: [ITHREAD] pcib1: ACPI PCI-PCI bridge irq 17 at device 28.0 on pci0 pci2: ACPI PCI bus on pcib1 pci2: base peripheral at device 0.0 (no driver attached) pci2: base peripheral, SD host controller at device 0.2 (no driver attached) pci2: base peripheral at device 0.3 (no driver attached) pci2: base peripheral at device 0.4 (no driver attached) pcib2: ACPI PCI-PCI bridge irq 16 at device 28.1 on pci0 pci3: ACPI PCI bus on pcib2 pcib3: ACPI PCI-PCI bridge irq 18 at device 28.2 on pci0 pci4: ACPI PCI bus on pcib3 pcib4: ACPI PCI-PCI bridge irq 19 at device 28.3 on pci0 pci5: ACPI PCI bus on pcib4 iwn0: Intel(R) PRO/Wireless 1000 mem 0xf220-0xf2201fff irq 19 at device 0.0 on pci5 iwn0
Re: Sleep/Lenovo SL410
On 08/23/10 21:49, Matt wrote: Please note atrtc0 error in dmesg? [ .. ] atrtc0: AT realtime clock 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 ___ 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: softupdate with journal panic
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 directory rename config test.
Your problem seems identical to this report:
http://docs.freebsd.org/cgi/mid.cgi?AANLkTinPjiOV21kDLZYV5WScrhLMN7DY8E8jVHWPU5mC
I believe that dotdotremref in this case is legitimately NULL. With this
assumption, the following patch would help.
Confirmed - with the patch below, it works as expected; thanks!
imb
diff --git a/sys/ufs/ffs/ffs_softdep.c b/sys/ufs/ffs/ffs_softdep.c
index b666c0f..65e5255 100644
--- a/sys/ufs/ffs/ffs_softdep.c
+++ b/sys/ufs/ffs/ffs_softdep.c
@@ -6770,7 +6794,8 @@ cancel_diradd(dap, dirrem, jremref, dotremref,
dotdotremref)
mkdir-md_jaddref = NULL;
if (mkdir-md_state MKDIR_PARENT) {
if (cancel_jaddref(jaddref, NULL,
- dirrem-dm_jwork) == 0) {
+ dirrem-dm_jwork) == 0
+ dotdotremref != NULL) {
free_jremref(dotdotremref);
dotdotremref = NULL;
}
___
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: softupdate with journal panic
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 a panic during the directory rename config test. Your problem seems identical to this report: http://docs.freebsd.org/cgi/mid.cgi?AANLkTinPjiOV21kDLZYV5WScrhLMN7DY8E8jVHWPU5mC I believe that dotdotremref in this case is legitimately NULL. With this assumption, the following patch would help. diff --git a/sys/ufs/ffs/ffs_softdep.c b/sys/ufs/ffs/ffs_softdep.c index b666c0f..65e5255 100644 --- a/sys/ufs/ffs/ffs_softdep.c Yes, works for me. - Peter ___ 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
