Re: Interpreted language(s) in the base
Hello, Doug. You wrote 16 августа 2010 г., 10:15:55: lua too flavor of the day, not enough track record of stability, not enough installed base/proven utility To be honest, lua is used in TONS of (commercial and, often, console) games as scripting engine, without any issues with stability or speed. Console games are very special world, where stability is holy cow, BTW. some JavaScript engines probably fit the description. Yikes! Sorry I asked. :) Best scripting language ever :) Mixup of Lisp and Self, disguised to looks like traditional language. And, yes, I'm serious here. But JavaScript have one problem: both good open-source engines (SpiderMonkey and V8) don't have good system library for file/io/process operations. They are too-browser specific. They can be easily stipped down to bare engines (very small, very efficient), but in such case here is huge amount of work by writing all native objects and operations needed for system scripting. -- // Black Lion AKA Lev Serebryakov l...@freebsd.org ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Runaway intr, not flash related
On 08/19/2010 10:43, Bjoern A. Zeeb wrote: On Thu, 19 Aug 2010, Doug Barton wrote: On 08/19/2010 08:24, Andriy Gapon wrote: I am sorry, but I don't see anything dramatically wrong here. So swi4: clock uses 5.76% of WCPU, is that such a big deal to be called runaway intr? That's the symptom. Have you ever posted a vmstat -i for when this actually happens? Yes. At the time I was told that it was uninteresting, but I'll include it again next time. Thanks, Doug -- Improve the effectiveness of your Internet presence with a domain name makeover!http://SupersetSolutions.com/ Computers are useless. They can only give you answers. -- Pablo Picasso ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: recent ath changes related panic
On Fri, Aug 20, 2010 at 08:31, Bernhard Schmidt bschm...@techwires.net wrote:
On Fri, Aug 20, 2010 at 01:04, Chris Ruiz yr.retar...@gmail.com wrote:
I run a PCI Atheros card in hostap mode on CURRENT.
a...@pci0:6:0:0: class=0x02 card=0x5a001385 chip=0x0013168c
rev=0x01 hdr=0x00
vendor = 'Atheros Communications Inc.'
device = '802.11a/b/g Wireless Adapter (AR2312)'
class = network
subclass = ethernet
Everything works fine with r211193 but with newer kernels I receive
the same panic related to the ath0 tasq.
I guess this also happens with post-r211314 kernels?
Seems like I missed you wrap a few ieee80211_ratectl_node_init()
calls. Please try attached patch, it should fix it.
--
Bernhard
Index: sys/net80211/ieee80211_node.c
===
--- sys/net80211/ieee80211_node.c (revision 211524)
+++ sys/net80211/ieee80211_node.c (working copy)
@@ -817,8 +817,7 @@ ieee80211_sta_join(struct ieee80211vap *vap, struc
if (ieee80211_iserp_rateset(ni-ni_rates))
ni-ni_flags |= IEEE80211_NODE_ERP;
ieee80211_node_setuptxparms(ni);
- if (vap-iv_caps IEEE80211_C_RATECTL)
- ieee80211_ratectl_node_init(ni);
+ ieee80211_ratectl_node_init(ni);
return ieee80211_sta_join1(ieee80211_ref_node(ni));
}
Index: sys/net80211/ieee80211_sta.c
===
--- sys/net80211/ieee80211_sta.c (revision 211524)
+++ sys/net80211/ieee80211_sta.c (working copy)
@@ -1597,8 +1597,7 @@ sta_recv_mgmt(struct ieee80211_node *ni, struct mb
IEEE80211_F_JOIN | IEEE80211_F_DOBRS);
ieee80211_setup_basic_htrates(ni, htinfo);
ieee80211_node_setuptxparms(ni);
- if (vap-iv_caps IEEE80211_C_RATECTL)
-ieee80211_ratectl_node_init(ni);
+ ieee80211_ratectl_node_init(ni);
} else {
#ifdef IEEE80211_SUPPORT_SUPERG
if (IEEE80211_ATH_CAP(vap, ni, IEEE80211_NODE_ATH))
Index: sys/net80211/ieee80211_ratectl.h
===
--- sys/net80211/ieee80211_ratectl.h (revision 211524)
+++ sys/net80211/ieee80211_ratectl.h (working copy)
@@ -77,7 +77,8 @@ ieee80211_ratectl_node_init(struct ieee80211_node
{
const struct ieee80211vap *vap = ni-ni_vap;
- vap-iv_rate-ir_node_init(ni);
+ if (vap-iv_caps IEEE80211_C_RATECTL)
+ vap-iv_rate-ir_node_init(ni);
}
static void __inline
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: recent ath changes related panic
On Fri, Aug 20, 2010 at 01:04, Chris Ruiz yr.retar...@gmail.com wrote: I run a PCI Atheros card in hostap mode on CURRENT. a...@pci0:6:0:0: class=0x02 card=0x5a001385 chip=0x0013168c rev=0x01 hdr=0x00 vendor = 'Atheros Communications Inc.' device = '802.11a/b/g Wireless Adapter (AR2312)' class = network subclass = ethernet Everything works fine with r211193 but with newer kernels I receive the same panic related to the ath0 tasq. I guess this also happens with post-r211314 kernels? the panic - http://tinypic.com/r/11t3g39/4 the backtrace - http://tinypic.com/r/nv4786/4 Sorry about the pics, I don't have access to serial or dcons. -- Chris Ruiz - http://twitter.com/chrisattack http://chrisattack.com ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org -- Bernhard ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
HPC/CUDA on FreeBSD (was: Re: Removal of ICC (intel compiler) bits from mk)
Hi, I'm taking out arch and some people from the CC and only keep curr...@. This is getting off topic for the initial thread. Quoting Anton Shterenlikht me...@bristol.ac.uk (from Thu, 19 Aug 2010 21:10:24 +0100): On Thu, Aug 19, 2010 at 11:35:48AM +0200, Alexander Leidinger wrote: Quoting Dag-Erling SmÃ??rgrav d...@des.no (from Thu, 19 Aug 2010 11:16:23 +0200): Alexander Leidinger alexan...@leidinger.net writes: If someone would get icc 11.x up and runnig as a port (similar to what we have for outdated icc version in the ports collection), I would have a look if my contact at Intel is still working there in a position which allows him to get a commercial license for us. Does that really matter? We're not going to start building releases with icc, are we? It could matter for ports, I do not know if it matters for parts in src. The commercial license is also the only way that we could get icc installed on machines in the FreeBSD cluster (if there's interest to have another compiler *for FreeBSD development* to check the source against... the warnng and error messages are better that those of gcc, I do not know how they compare to clang). If one begins to mention FreeBSD clusters, and moreover FreeBSD HPC, then this becomes a somewhat different discussion. One of the stubmling blocks for HPC on FreeBSD (just one of many, perhaps not even the major one) is a complete lack of good quality commercial compilers. All weÃ'got is gcc or clang. Both are not really that great, and definitely inferior to commercial compilers, e.g. Intel. What IÃ'm saying is that it would be great if Intel sold a compiler for FreeBSD. I'd ve bought a copy. But from what others have said, my impression is that the ICC port is unlikely to fill this void. After I (and other people which provided patches) ported icc to FreeBSD someone from IIRC Asia took the port as an example and ported Intels Fortran compiler to FreeBSD in the same way (he was able to use a lot of the icc port, only some minor modifications where necessary). I had the impression that this was used for HPC. P.S. My interests and expertise are in computational mechanics, not in compilers, so feel free to correct me if IÃ'm wrong. In general: The resulting code (for icc and ifc) was working. The application binary code itself was/is the same (modulo differences in system headers), the only things which need to be changed are the startup code and the libs. We managed to do that. P.P.S. Regarding FreeBSD HPC see also this thead: http://lists.freebsd.org/pipermail/freebsd-questions/2010-August/220264.html (FreeBSD, GPGPU and OpenCL/CUDA) That's not the way we would like it to be, but at least it is possible: http://blogs.freebsdish.org/jhb/2010/07/20/using-cuda-with-the-native-freebsdamd64-nvidia-driver/ When I was working on icc, I had an idea about a liblinux2freebsd which would provide common linux-symbols and map them to FreeBSD-equivalents (together with some predefined objdump/objcopy/... scripts to modify linux libs) so that you can take a linux lib and use it to create native FreeBSD programs. Sort of like the NDIS layer in the kernel to run Windows binary drivers. Unfortunately I never got the time to work on this. Something like this could have maybe been used to mangle the linux cuda libs to be used on FreeBSD natively. Bye, Alexander. -- Neither spread the germs of gossip nor encourage others to do so. http://www.Leidinger.netAlexander @ Leidinger.net: PGP ID = B0063FE7 http://www.FreeBSD.org netchild @ FreeBSD.org : PGP ID = 72077137 ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Removal of ICC (intel compiler) bits from mk
Anton Shterenlikht me...@bristol.ac.uk writes: It could matter for ports, I do not know if it matters for parts in src. The commercial license is also the only way that we could get icc installed on machines in the FreeBSD cluster [...] If one begins to mention FreeBSD clusters, and moreover FreeBSD HPC, Not FreeBSD clusters, but *the* FreeBSD cluster, i.e. the .f.o machines hosted by Y!. DES -- Dag-Erling Smørgrav - d...@des.no ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Official request: Please make GNU grep the default
2010/8/19 Dag-Erling Smørgrav d...@des.no: time seconds seconds calls ms/call ms/call name 38.8 0.03 0.03 12717 0.00 0.00 memchr [5] 35.6 0.07 0.03 395 0.08 0.08 _read [6] 16.4 0.08 0.01 0 100.00% _mcount [7] memchr()? Really? I've just looked at grep_fgetln(). Surely memchr() isn't required there. Adrian ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Official request: Please make GNU grep the default
Doug Barton do...@freebsd.org writes: There are 2 questions, did I do the right thing, and how should people report problems in general. As for myself, while I have some facility in C it's not my strong suit. Yes, I could have produced a profiling version of grep, but it would have taken me a lot more than 10 minutes because I don't even build the profiled libs on a regular basis. That's fair. I didn't use to do that because it increases build time considerably, but now I do. If you have profiling libraries installed, you can build a profiling version of grep (or any program) like so: % cd /usr/src/usr.bin/grep % make clean % make DEBUG_FLAGS=-pg -g -DNO_SHARED Do *not make install, because the result will be dog slow and you don't want to use it in production. Every time you run it, it will leave a file named grep.gmon in your current directory, so: % /usr/obj/usr/src/usr.bin/grep/grep -q ^xfce4-wm /usr/ports/INDEX-9 % gprof /usr/obj/usr/src/usr.bin/grep/grep grep.gmon | less More generally however I think that we need to be realistic with what we expect people to do about reporting problems. This is not about what we expect people to do but about what I expect *you*, an experienced FreeBSD committer, to do :) 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: [head tinderbox] failure on powerpc64/powerpc
Nathan Whitehorn nwhiteh...@freebsd.org writes: The problem is that until yesterday, you could not build a powerpc64 LINT, and so it was trying to build a PPC32 kernel with a 64-bit toolchain. An actual powerpc64 kernel does not include ofw_standard.c. This should be fixed now with r211483, so long as the LINT config is made with TARGET_ARCH set (and is not reused for 32 and 64-bit builds). There is a seat-belt mechanism I should add soon that will complain earlier about architecture mismatches like this. Thanks for your patience. stage 3.2: building everything [...] /src/sys/powerpc/fpu/fpu_emu.c: In function 'fpu_execute': /src/sys/powerpc/fpu/fpu_emu.c:329: warning: format '%x' expects type 'unsigned int', but argument 3 has type 'long int' /src/sys/powerpc/fpu/fpu_emu.c:329: warning: format '%x' expects type 'unsigned int', but argument 5 has type 'long int' /src/sys/powerpc/fpu/fpu_emu.c:359: warning: format '%x' expects type 'unsigned int', but argument 3 has type 'long int' /src/sys/powerpc/fpu/fpu_emu.c:359: warning: format '%x' expects type 'unsigned int', but argument 5 has type 'long int' /src/sys/powerpc/fpu/fpu_emu.c:376: warning: format '%x' expects type 'unsigned int', but argument 3 has type 'long int' /src/sys/powerpc/fpu/fpu_emu.c:376: warning: format '%x' expects type 'unsigned int', but argument 4 has type 'vm_offset_t' /src/sys/powerpc/fpu/fpu_emu.c:778: warning: format '%x' expects type 'unsigned int', but argument 3 has type 'register_t' *** Error code 1 Stop in /obj/powerpc.powerpc64/src/sys/LINT. :) 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
[SPAM] Re: Official request: Please make GNU grep the default
On 2010-08-20 11:10, Dag-Erling Smørgrav wrote: If you have profiling libraries installed, you can build a profiling version of grep (or any program) like so: % cd /usr/src/usr.bin/grep % make clean % make DEBUG_FLAGS=-pg -g -DNO_SHARED Do *not make install, because the result will be dog slow and you don't want to use it in production. Every time you run it, it will leave a file named grep.gmon in your current directory, so: As a side note, this maybe should be posted in the handbook and/or on the wiki for reference, so people who want to profile slow applications know how to do it. Regards! //Niclas ___ 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
Adrian Chadd adr...@freebsd.org writes: I've just looked at grep_fgetln(). Surely memchr() isn't required there. Of course it is, how else are you going to locate the '\n'? OTOH, I'm not sure grep_fgetln() is needed at all. 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
[head tinderbox] failure on powerpc64/powerpc
TB --- 2010-08-20 08:41:47 - tinderbox 2.6 running on freebsd-current.sentex.ca TB --- 2010-08-20 08:41:47 - starting HEAD tinderbox run for powerpc64/powerpc TB --- 2010-08-20 08:41:47 - cleaning the object tree TB --- 2010-08-20 08:42:39 - cvsupping the source tree TB --- 2010-08-20 08:42:39 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/HEAD/powerpc64/powerpc/supfile TB --- 2010-08-20 08:44:17 - building world TB --- 2010-08-20 08:44:17 - MAKEOBJDIRPREFIX=/obj TB --- 2010-08-20 08:44:17 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2010-08-20 08:44:17 - TARGET=powerpc TB --- 2010-08-20 08:44:17 - TARGET_ARCH=powerpc64 TB --- 2010-08-20 08:44:17 - TZ=UTC TB --- 2010-08-20 08:44:17 - __MAKE_CONF=/dev/null TB --- 2010-08-20 08:44:17 - cd /src TB --- 2010-08-20 08:44:17 - /usr/bin/make -B buildworld World build started on Fri Aug 20 08:44:17 UTC 2010 Rebuilding the temporary build tree stage 1.1: legacy release compatibility shims stage 1.2: bootstrap tools stage 2.1: cleaning up the object tree stage 2.2: rebuilding the object tree stage 2.3: build tools stage 3: cross tools stage 4.1: building includes stage 4.2: building libraries stage 4.3: make dependencies stage 4.4: building everything stage 5.1: building 32 bit shim libraries World build completed on Fri Aug 20 10:26:25 UTC 2010 TB --- 2010-08-20 10:26:25 - generating LINT kernel config TB --- 2010-08-20 10:26:25 - cd /src/sys/powerpc/conf TB --- 2010-08-20 10:26:25 - /usr/bin/make -B LINT TB --- 2010-08-20 10:26:25 - building LINT kernel TB --- 2010-08-20 10:26:25 - MAKEOBJDIRPREFIX=/obj TB --- 2010-08-20 10:26:25 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2010-08-20 10:26:25 - TARGET=powerpc TB --- 2010-08-20 10:26:25 - TARGET_ARCH=powerpc64 TB --- 2010-08-20 10:26:25 - TZ=UTC TB --- 2010-08-20 10:26:25 - __MAKE_CONF=/dev/null TB --- 2010-08-20 10:26:25 - cd /src TB --- 2010-08-20 10:26:25 - /usr/bin/make -B buildkernel KERNCONF=LINT Kernel build for LINT started on Fri Aug 20 10:26:25 UTC 2010 stage 1: configuring the kernel stage 2.1: cleaning up the object tree stage 2.2: rebuilding the object tree stage 2.3: build tools stage 3.1: making dependencies stage 3.2: building everything Kernel build for LINT completed on Fri Aug 20 10:52:26 UTC 2010 TB --- 2010-08-20 10:52:26 - building GENERIC kernel TB --- 2010-08-20 10:52:26 - MAKEOBJDIRPREFIX=/obj TB --- 2010-08-20 10:52:26 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2010-08-20 10:52:26 - TARGET=powerpc TB --- 2010-08-20 10:52:26 - TARGET_ARCH=powerpc64 TB --- 2010-08-20 10:52:26 - TZ=UTC TB --- 2010-08-20 10:52:26 - __MAKE_CONF=/dev/null TB --- 2010-08-20 10:52:26 - cd /src TB --- 2010-08-20 10:52:26 - /usr/bin/make -B buildkernel KERNCONF=GENERIC Kernel build for GENERIC started on Fri Aug 20 10:52:26 UTC 2010 stage 1: configuring the kernel stage 2.1: cleaning up the object tree stage 2.2: rebuilding the object tree stage 2.3: build tools stage 3.1: making dependencies stage 3.2: building everything [...] /src/sys/dev/ofw/ofw_standard.c:705: warning: cast to pointer from integer of different size /src/sys/dev/ofw/ofw_standard.c: In function 'ofw_std_release': /src/sys/dev/ofw/ofw_standard.c:719: warning: cast from pointer to integer of different size /src/sys/dev/ofw/ofw_standard.c:724: warning: cast from pointer to integer of different size /src/sys/dev/ofw/ofw_standard.c: In function 'ofw_std_enter': /src/sys/dev/ofw/ofw_standard.c:742: warning: cast from pointer to integer of different size /src/sys/dev/ofw/ofw_standard.c: In function 'ofw_std_exit': /src/sys/dev/ofw/ofw_standard.c:760: warning: cast from pointer to integer of different size *** Error code 1 Stop in /obj/powerpc.powerpc64/src/sys/GENERIC. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2010-08-20 10:57:49 - WARNING: /usr/bin/make returned exit code 1 TB --- 2010-08-20 10:57:49 - ERROR: failed to build GENERIC kernel TB --- 2010-08-20 10:57:49 - 5629.71 user 1551.20 system 8161.55 real http://tinderbox.freebsd.org/tinderbox-head-HEAD-powerpc64-powerpc.full ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Official request: Please make GNU grep the default
2010/8/20 Dag-Erling Smørgrav d...@des.no: Adrian Chadd adr...@freebsd.org writes: I've just looked at grep_fgetln(). Surely memchr() isn't required there. Of course it is, how else are you going to locate the '\n'? OTOH, I'm not sure grep_fgetln() is needed at all. It seems a bit strange that memchr(), which should be hitting data that's in the cache (as it was recently read, right?) is showing up so high in the profiling results. memchr() in libc/string/memchr.c looks like how I'd inline it, so, hm. Have you tried this in pmc? Adrian ___ 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
Adrian Chadd adr...@freebsd.org writes: Have you tried this in pmc? No. I can't figure out how to use pmcstat, but I did find a bug in it: if you specify an output file with -o, but the command line is otherwise incomplete or incorrect, it will print usage information to the output file instead of stderr. 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: [head tinderbox] failure on powerpc64/powerpc
On 08/20/10 04:26, Dag-Erling Smørgrav wrote: Nathan Whitehornnwhiteh...@freebsd.org writes: The problem is that until yesterday, you could not build a powerpc64 LINT, and so it was trying to build a PPC32 kernel with a 64-bit toolchain. An actual powerpc64 kernel does not include ofw_standard.c. This should be fixed now with r211483, so long as the LINT config is made with TARGET_ARCH set (and is not reused for 32 and 64-bit builds). There is a seat-belt mechanism I should add soon that will complain earlier about architecture mismatches like this. Thanks for your patience. stage 3.2: building everything [...] /src/sys/powerpc/fpu/fpu_emu.c: In function 'fpu_execute': /src/sys/powerpc/fpu/fpu_emu.c:329: warning: format '%x' expects type 'unsigned int', but argument 3 has type 'long int' /src/sys/powerpc/fpu/fpu_emu.c:329: warning: format '%x' expects type 'unsigned int', but argument 5 has type 'long int' /src/sys/powerpc/fpu/fpu_emu.c:359: warning: format '%x' expects type 'unsigned int', but argument 3 has type 'long int' /src/sys/powerpc/fpu/fpu_emu.c:359: warning: format '%x' expects type 'unsigned int', but argument 5 has type 'long int' /src/sys/powerpc/fpu/fpu_emu.c:376: warning: format '%x' expects type 'unsigned int', but argument 3 has type 'long int' /src/sys/powerpc/fpu/fpu_emu.c:376: warning: format '%x' expects type 'unsigned int', but argument 4 has type 'vm_offset_t' /src/sys/powerpc/fpu/fpu_emu.c:778: warning: format '%x' expects type 'unsigned int', but argument 3 has type 'register_t' *** Error code 1 Stop in /obj/powerpc.powerpc64/src/sys/LINT. OK, that one is fixed now too. :) Next up: tinderbox needs to build GENERIC64, not GENERIC, on powerpc64. make buildkernel is programmed to do the right thing is you don't pass a KERNCONF, but tinderbox apparently passes GENERIC explicitly. This one's in your court! -Nathan ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: fusefs-kmod broken?
Hans Petter Selasky wrote:
Do you have all the drivers you need in the kernel?
./uart/uart.h:extern struct uart_class uart_z8530_class __attribute__((weak))
;
./uart/uart_bus_scc.c: sc-sc_class = uart_z8530_class;
./uart/uart_cpu_powerpc.c: class = uart_z8530_class;
./uart/uart_cpu_powerpc.c: class = uart_z8530_class;
./uart/uart_cpu_sparc64.c: class = uart_z8530_class;
./uart/uart_dev_z8530.c:struct uart_class uart_z8530_class = {
./uart/uart_subr.c: uart_z8530_class,
What drivers do you sugest? These are what's configured.
device ucom
device uplcom
device uart# 8250, 16[45]50 based serial ports
device puc
The 2 DS2480 (1-wire bus masters) are on 2 PL2303 usb serial ports.
Reading the devices works fine:
[brane] /1-wire # ls
10.0ADC53010800 10.AB2D4C010800 26.1D82B500 bus.0 structure
10.174637010800 10.BD4437010800 26.2882B500 bus.1 system
10.19D24C010800 10.E32C4C010800 29.83290300 settingsuncached
10.4A6237010800 1D.33F00D00 29.A52A0300 simultaneous
10.725A4C010800 1D.6A560B00 alarm statistics
[brane] /1-wire # cat 10.0ADC53010800/temperature
22.1875
It's writing to the 29.A52A0300 or 29.83290300 PIO registers
that results in the panic.
[brane] /1-wire # ls 29.A52A0300
LCD_H PIO.ALL latch.4 r_address sensed.7
LCD_M PIO.BYTElatch.5 r_idsensed.ALL
PIO.0 address latch.6 r_locator sensed.BYTE
PIO.1 crc8latch.7 sensed.0set_alarm
PIO.2 family latch.ALL sensed.1strobe
PIO.3 id latch.BYTE sensed.2type
PIO.4 latch.0 locator sensed.3
PIO.5 latch.1 por sensed.4
PIO.6 latch.2 power sensed.5
PIO.7 latch.3 present sensed.6
Ian
--
Ian Freislich
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: LOR on nfs: vfs_vnops.c:301 kern_descrip.c:1580
On 19 August 2010 17:34, John Baldwin j...@freebsd.org wrote: On Thursday, August 19, 2010 5:29:25 am pluknet wrote: On 19 August 2010 00:07, John Baldwin j...@freebsd.org wrote: On Wednesday, August 18, 2010 3:17:56 pm pluknet wrote: On 18 August 2010 23:11, pluknet pluk...@gmail.com wrote: On 18 August 2010 17:46, Kostik Belousov kostik...@gmail.com wrote: On Wed, Aug 18, 2010 at 02:43:19PM +0400, pluknet wrote: On 18 August 2010 12:07, pluknet pluk...@gmail.com wrote: On 17 August 2010 20:04, Kostik Belousov kostik...@gmail.com wrote: Also please take a note of the John' suggestion to use the taskqueue. I decided to go this road. Thank you both. Now I do nfs buildkernel survive and prepare some benchmark results. So, I modified the patch to defer proc_create() with taskqueue(9). Below is `time make -j5 buildkernel WITHOUT_MODULES=yes` perf. evaluation. Done on 4-way CPU on clean /usr/obj with /usr/src /usr/obj both nfs-mounted over 1Gbit LAN. clean old 1137.985u 239.411s 7:42.15 298.0% 6538+2133k 87+43388io 226pf+0w clean new 1134.755u 240.032s 7:41.25 298.0% 6553+2133k 87+43367io 224pf+0w Patch needs polishing, though it generally works. Not sure if shep_chan (or whatever name it will get) needs locking. As I said yesterday, if several requests to create nfsiod coming one after another, you would loose all but the last. You should put the requests into the list, probably protected by nfs_iod_mtx. How about this patch? Still several things to ask. 1) I used malloc instance w/ M_NOWAIT, since it's called with nfs_iod_mtx held. 2) Probably busy/done gymnastics is a wrong mess. Your help is appreciated. 3) if (1) is fine, is it right to use fail: logic (i.e. set NFSIOD_NOT_AVAILABLE) on memory shortage? Not tested. There are debug printf() left intentionally to see how 3 contexts run under load to each other. I attached these messages as well if that makes sense. Ah, yes. Sorry, forgot about that. Your task handler needs to run in a loop until the list of requests is empty. If multiple threads call taskqueue_enqueue() before your task is scheduled, they will be consolidated down to a single call of your task handler. Thanks for your suggestions. So I converted nfs_nfsiodnew_tq() into loop, and as such I changed a cleanup SLIST_FOREACH() as well to free a bulk of (potentially consolidated) completed requests in one pass. kproc_create() is still out of the SLIST_FOREACH() to avoid calling it with nfs_iod_mtx held. - int error, i; - int newiod; + int i, newiod, error; You should sort these alphabetically if you are going to change this. I would probably just leave it as-is. Err.. that's resulted after a set of changes. Thanks for noting that. Also, I'm not sure how this works as you don't actually wait for the task to complete. If the taskqueue_enqueue() doesn't preempt, then you may read ni_error as zero before the kproc has actually been created and return success even though an nfsiod hasn't been created. I put taskqueue_drain() right after taskqueue_enqueue() to be in sync with task handler. That was part to think about, as I didn't find such a use pattern. It seems though that tasks are launched now strictly one-by-one, without visible parallelism (as far as debug printf()s don't overlap anymore). Ah, if it is safe to sleep then I have a couple of suggestions: Cool, credits go to John :). I just adopted all of your changes (attached). - Use M_WAITOK to malloc() so you don't have to worry about the failure case (I see Rick already suggested this). After all that reduces to the following replacement in nfs_nfsiodnew(). So, no regression should be there in theory. mtx_unlock(nfs_iod_mtx); - kproc_create(...) + malloc(...) mtx_lock(nfs_iod_mtx); It survived after this simple test running for an hour, which forces creation of many iods with r/w from 300 threads: nfsserv:/home/svn/freebsd/obj_exp on /usr/obj (nfs) ./randomio /usr/obj/file 100 0.5 0 4096 60 100 ./randomio /usr/obj/file 100 0.5 0 4096 60 100 ./randomio /usr/obj/file 100 0.5 0 4096 60 100 while [ true ]; do sysctl vfs.nfs.iodmax=2; sysctl vfs.nfs.iodmax=60; sleep 20; done randomio is from ports/149838. P.S. it's funny to see in top 0 root 10 440 0K 144K deadlk 2 23:16 28.86% kernel Someone might think the kernel is in deadlock. -- wbr, pluknet nfsiod_tq_lock.3.diff Description: Binary data ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Whiteout support for tmpfs [Was: unionfs a little improvement]
Hi all, Even though the proposed fix for unionfs would still be nice to have in SVN, I just wrote a patch for tmpfs to add support for whiteouts: http://80386.nl/pub/tmpfs-whiteout.txt Basically I've implemented it by allowing directory entries to refer to NULL inodes, to indicate the entry is a whiteout. I think the patch should work pretty well, but what I dislike about it, is that when it removes a file and replaces it by a whiteout, it deallocates the entire directory entry, followed by the allocation of a new directory entry for the whiteout. This could be done more efficiently, but the problem is that it turns the code into a mess. Any comments? -- Ed Schouten e...@80386.nl WWW: http://80386.nl/ pgpuEIWRJzq7F.pgp Description: PGP signature
Re: LOR on nfs: vfs_vnops.c:301 kern_descrip.c:1580
On Fri, Aug 20, 2010 at 08:55:08PM +0400, pluknet wrote: On 19 August 2010 17:34, John Baldwin j...@freebsd.org wrote: On Thursday, August 19, 2010 5:29:25 am pluknet wrote: On 19 August 2010 00:07, John Baldwin j...@freebsd.org wrote: On Wednesday, August 18, 2010 3:17:56 pm pluknet wrote: On 18 August 2010 23:11, pluknet pluk...@gmail.com wrote: On 18 August 2010 17:46, Kostik Belousov kostik...@gmail.com wrote: On Wed, Aug 18, 2010 at 02:43:19PM +0400, pluknet wrote: On 18 August 2010 12:07, pluknet pluk...@gmail.com wrote: On 17 August 2010 20:04, Kostik Belousov kostik...@gmail.com wrote: Also please take a note of the John' suggestion to use the taskqueue. I decided to go this road. Thank you both. Now I do nfs buildkernel survive and prepare some benchmark results. So, I modified the patch to defer proc_create() with taskqueue(9). Below is `time make -j5 buildkernel WITHOUT_MODULES=yes` perf. evaluation. Done on 4-way CPU on clean /usr/obj with /usr/src /usr/obj both nfs-mounted over 1Gbit LAN. clean old 1137.985u 239.411s 7:42.15 298.0% 6538+2133k 87+43388io 226pf+0w clean new 1134.755u 240.032s 7:41.25 298.0% 6553+2133k 87+43367io 224pf+0w Patch needs polishing, though it generally works. Not sure if shep_chan (or whatever name it will get) needs locking. As I said yesterday, if several requests to create nfsiod coming one after another, you would loose all but the last. You should put the requests into the list, probably protected by nfs_iod_mtx. How about this patch? Still several things to ask. 1) I used malloc instance w/ M_NOWAIT, since it's called with nfs_iod_mtx held. 2) Probably busy/done gymnastics is a wrong mess. Your help is appreciated. 3) if (1) is fine, is it right to use fail: logic (i.e. set NFSIOD_NOT_AVAILABLE) on memory shortage? Not tested. There are debug printf() left intentionally to see how 3 contexts run under load to each other. I attached these messages as well if that makes sense. Ah, yes. Sorry, forgot about that. Your task handler needs to run in a loop until the list of requests is empty. If multiple threads call taskqueue_enqueue() before your task is scheduled, they will be consolidated down to a single call of your task handler. Thanks for your suggestions. So I converted nfs_nfsiodnew_tq() into loop, and as such I changed a cleanup SLIST_FOREACH() as well to free a bulk of (potentially consolidated) completed requests in one pass. kproc_create() is still out of the SLIST_FOREACH() to avoid calling it with nfs_iod_mtx held. - int error, i; - int newiod; + int i, newiod, error; You should sort these alphabetically if you are going to change this. I would probably just leave it as-is. Err.. that's resulted after a set of changes. Thanks for noting that. Also, I'm not sure how this works as you don't actually wait for the task to complete. If the taskqueue_enqueue() doesn't preempt, then you may read ni_error as zero before the kproc has actually been created and return success even though an nfsiod hasn't been created. I put taskqueue_drain() right after taskqueue_enqueue() to be in sync with task handler. That was part to think about, as I didn't find such a use pattern. It seems though that tasks are launched now strictly one-by-one, without visible parallelism (as far as debug printf()s don't overlap anymore). Ah, if it is safe to sleep then I have a couple of suggestions: Cool, credits go to John :). I just adopted all of your changes (attached). - Use M_WAITOK to malloc() so you don't have to worry about the failure case (I see Rick already suggested this). After all that reduces to the following replacement in nfs_nfsiodnew(). So, no regression should be there in theory. mtx_unlock(nfs_iod_mtx); - kproc_create(...) + malloc(...) mtx_lock(nfs_iod_mtx); It survived after this simple test running for an hour, which forces creation of many iods with r/w from 300 threads: nfsserv:/home/svn/freebsd/obj_exp on /usr/obj (nfs) ./randomio /usr/obj/file 100 0.5 0 4096 60 100 ./randomio /usr/obj/file 100 0.5 0 4096 60 100 ./randomio /usr/obj/file 100 0.5 0 4096 60 100 while [ true ]; do sysctl vfs.nfs.iodmax=2; sysctl vfs.nfs.iodmax=60; sleep 20; done randomio is from ports/149838. P.S. it's funny to see in top 0 root 10 440 0K 144K deadlk 2 23:16 28.86% kernel Someone might think the kernel is in deadlock. It seems nobody replied to the mdf@ objection against wait of the new proc startup being equivalent to the LOR. I think that the wait is safe, because the task is executed in the context of the different process
Re: [head tinderbox] failure on powerpc64/powerpc
Nathan Whitehorn nwhiteh...@freebsd.org writes: Next up: tinderbox needs to build GENERIC64, not GENERIC, on powerpc64. make buildkernel is programmed to do the right thing is you don't pass a KERNCONF, but tinderbox apparently passes GENERIC explicitly. This one's in your court! There is no way to fix this with the current tinderbox code. MHO is that the entire powerpc64 thing is very poorly thought out. DES -- Dag-Erling Smørgrav - d...@des.no ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Official request: Please make GNU grep the default
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. 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: Interpreted language(s) in the base
C. P. Ghost cpgh...@cordula.ws writes: After all LISP-like syntax is *still* more common and prevalent than Lua, e.g. in Elisp, guile, esh, scsh and a lot of other apps that use it as a small language. So we can expect more users to be at least partially familiar with it. And there *are* lightweight MIT- or BSD-licensed scheme interpreters out there too: Considering that the majority of people who might be interested in using this know *neither* Lisp *nor* Lua, my vote is for Lua, because people who are familiar with neither will be more open to learning Lua, which resembles other languages they already know, than Lisp, which doesn't. 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: Interpreted language(s) in the base
Gabor PALI p...@freebsd.org writes: Sorry for chiming in, just a quick idea. If you find the get a high-level language that compiled to C idea good, I don't think it's a good idea, and I don't understand why this thread seems stuck in that rut. DES -- Dag-Erling Smørgrav - d...@des.no ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: LOR on nfs: vfs_vnops.c:301 kern_descrip.c:1580
On Friday, August 20, 2010 3:19:53 pm Kostik Belousov wrote: On Fri, Aug 20, 2010 at 08:55:08PM +0400, pluknet wrote: On 19 August 2010 17:34, John Baldwin j...@freebsd.org wrote: On Thursday, August 19, 2010 5:29:25 am pluknet wrote: On 19 August 2010 00:07, John Baldwin j...@freebsd.org wrote: On Wednesday, August 18, 2010 3:17:56 pm pluknet wrote: On 18 August 2010 23:11, pluknet pluk...@gmail.com wrote: On 18 August 2010 17:46, Kostik Belousov kostik...@gmail.com wrote: On Wed, Aug 18, 2010 at 02:43:19PM +0400, pluknet wrote: On 18 August 2010 12:07, pluknet pluk...@gmail.com wrote: On 17 August 2010 20:04, Kostik Belousov kostik...@gmail.com wrote: Also please take a note of the John' suggestion to use the taskqueue. I decided to go this road. Thank you both. Now I do nfs buildkernel survive and prepare some benchmark results. So, I modified the patch to defer proc_create() with taskqueue(9). Below is `time make -j5 buildkernel WITHOUT_MODULES=yes` perf. evaluation. Done on 4-way CPU on clean /usr/obj with /usr/src /usr/obj both nfs-mounted over 1Gbit LAN. clean old 1137.985u 239.411s 7:42.15 298.0% 6538+2133k 87+43388io 226pf+0w clean new 1134.755u 240.032s 7:41.25 298.0% 6553+2133k 87+43367io 224pf+0w Patch needs polishing, though it generally works. Not sure if shep_chan (or whatever name it will get) needs locking. As I said yesterday, if several requests to create nfsiod coming one after another, you would loose all but the last. You should put the requests into the list, probably protected by nfs_iod_mtx. How about this patch? Still several things to ask. 1) I used malloc instance w/ M_NOWAIT, since it's called with nfs_iod_mtx held. 2) Probably busy/done gymnastics is a wrong mess. Your help is appreciated. 3) if (1) is fine, is it right to use fail: logic (i.e. set NFSIOD_NOT_AVAILABLE) on memory shortage? Not tested. There are debug printf() left intentionally to see how 3 contexts run under load to each other. I attached these messages as well if that makes sense. Ah, yes. Sorry, forgot about that. Your task handler needs to run in a loop until the list of requests is empty. If multiple threads call taskqueue_enqueue() before your task is scheduled, they will be consolidated down to a single call of your task handler. Thanks for your suggestions. So I converted nfs_nfsiodnew_tq() into loop, and as such I changed a cleanup SLIST_FOREACH() as well to free a bulk of (potentially consolidated) completed requests in one pass. kproc_create() is still out of the SLIST_FOREACH() to avoid calling it with nfs_iod_mtx held. - int error, i; - int newiod; + int i, newiod, error; You should sort these alphabetically if you are going to change this. I would probably just leave it as-is. Err.. that's resulted after a set of changes. Thanks for noting that. Also, I'm not sure how this works as you don't actually wait for the task to complete. If the taskqueue_enqueue() doesn't preempt, then you may read ni_error as zero before the kproc has actually been created and return success even though an nfsiod hasn't been created. I put taskqueue_drain() right after taskqueue_enqueue() to be in sync with task handler. That was part to think about, as I didn't find such a use pattern. It seems though that tasks are launched now strictly one-by-one, without visible parallelism (as far as debug printf()s don't overlap anymore). Ah, if it is safe to sleep then I have a couple of suggestions: Cool, credits go to John :). I just adopted all of your changes (attached). - Use M_WAITOK to malloc() so you don't have to worry about the failure case (I see Rick already suggested this). After all that reduces to the following replacement in nfs_nfsiodnew(). So, no regression should be there in theory. mtx_unlock(nfs_iod_mtx); - kproc_create(...) + malloc(...) mtx_lock(nfs_iod_mtx); It survived after this simple test running for an hour, which forces creation of many iods with r/w from 300 threads: nfsserv:/home/svn/freebsd/obj_exp on /usr/obj (nfs) ./randomio /usr/obj/file 100 0.5 0 4096 60 100 ./randomio /usr/obj/file 100 0.5 0 4096 60 100 ./randomio /usr/obj/file 100 0.5 0 4096 60 100 while [ true ]; do sysctl vfs.nfs.iodmax=2; sysctl vfs.nfs.iodmax=60; sleep 20; done randomio is from ports/149838. P.S. it's funny to see in top 0 root 10 440 0K 144K deadlk 2 23:16 28.86% kernel Someone might think the
Re: Official request: Please make GNU grep the default
b. f. bf1...@googlemail.com writes: At r211506, 'grep -wq' does not seem to work properly (in the very least, it is not the same as with GNU grep), Does not seem to work properly is not a very useful statement. The least you could do is provide an example. 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: Interpreted language(s) in the base
2010/8/20 Dag-Erling Smørgrav d...@des.no: Gabor PALI p...@freebsd.org writes: Sorry for chiming in, just a quick idea. If you find the get a high-level language that compiled to C idea good, I don't think it's a good idea Could you be more specific on your concerns? I am just curious. I don't understand why this thread seems stuck in that rut. Perhaps because people want to write more reliable code faster? :g ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: LOR on nfs: vfs_vnops.c:301 kern_descrip.c:1580
On Fri, Aug 20, 2010 at 03:35:48PM -0400, John Baldwin wrote: On Friday, August 20, 2010 3:19:53 pm Kostik Belousov wrote: It seems nobody replied to the mdf@ objection against wait of the new proc startup being equivalent to the LOR. I think that the wait is safe, because the task is executed in the context of the different process then the enqueue request. This might be worth noting in the comment or commit message. I do wonder if we could get away with not waiting at all and always return -1? You could have the task handler actually finish the toggle of the tristate in the array. Potentially you could even dispense with the linked list of malloc'd structures and just walk the array creating processes for any entries in the in-progress state in the task handler. You might also want to avoid submitting entries for new threads if there is already a pending one? If that is the case it could be further simplified by having the task always create a single kthread when scheduled and just scheduling the task anytime a request needs one. I think this is not that easy. Please take a look at nfs_asyncio(). There is a lot of logic what to do in case an nfsiod thread was found or not etc. pgpoeoqZ8MHhL.pgp Description: PGP signature
Re: LOR on nfs: vfs_vnops.c:301 kern_descrip.c:1580
On Friday, August 20, 2010 3:42:27 pm Kostik Belousov wrote: On Fri, Aug 20, 2010 at 03:35:48PM -0400, John Baldwin wrote: On Friday, August 20, 2010 3:19:53 pm Kostik Belousov wrote: It seems nobody replied to the mdf@ objection against wait of the new proc startup being equivalent to the LOR. I think that the wait is safe, because the task is executed in the context of the different process then the enqueue request. This might be worth noting in the comment or commit message. I do wonder if we could get away with not waiting at all and always return -1? You could have the task handler actually finish the toggle of the tristate in the array. Potentially you could even dispense with the linked list of malloc'd structures and just walk the array creating processes for any entries in the in-progress state in the task handler. You might also want to avoid submitting entries for new threads if there is already a pending one? If that is the case it could be further simplified by having the task always create a single kthread when scheduled and just scheduling the task anytime a request needs one. I think this is not that easy. Please take a look at nfs_asyncio(). There is a lot of logic what to do in case an nfsiod thread was found or not etc. Gah, the real problem is that unless the new kproc starts up super fast we would invariably return EIO causing the I/O to be performed synchronously more often. Given that, I think pluknet's patch is fine once it is updated for the module unload case. -- 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
CD/DVD ejecting after sysinstall
References: http://www.mail-archive.com/svn-src-...@freebsd.org/msg24380.html http://forums.freebsd.org/showthread.php?t=17126 This commit automatically ejects the CD when sysinstall exits which almost had dire consequences for me this week. As described in the forum post, I keep a LiveFS CD in all of my servers so that I can remotely diagnose and fix issues. I have done this for several years now, and it has saved my tail many times. However, I got a surprise when I tried it today with the new 8.1 LiveFS CDs I had just burned. After attempting to fix a problem from the LiveFS and rebooting back to the HD, the problem still existed. No problem. I just tried to boot back to the CD only to find that it was gone. Luckily, this was on a box in-house, so I was quickly able to see what was wrong. Now that I have the commit, I can roll my own patched sysinstall and CDs, but the question is: Should we be ejecting the media without any prompt? Obviously, for my use case, I liked the old behavior of just reminding the user to eject the media when rebooting. I understand that may not be optimal for some users. Can we present a dialog asking the user if they want the media to be ejected? That still leaves me at risk of selecting the wrong answer, I suppose. I would rather not have to roll my own LiveFS CDs every time, though. Thoughts from anyone else? (Please copy me on responses.) - Jim ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Interpreted language(s) in the base
On 8/20/2010 12:35 PM, Dag-Erling Smørgrav wrote: Gabor PALIp...@freebsd.org writes: Sorry for chiming in, just a quick idea. If you find the get a high-level language that compiled to C idea good, I don't think it's a good idea, and I don't understand why this thread seems stuck in that rut. If your only tool is a hammer, all your problems look like nails. -- ... 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: Interpreted language(s) in the base
On Thu, 19 Aug 2010 20:35:59 +0200 C. P. Ghost cpgh...@cordula.ws wrote:
But seriously, the point isn't so much which specific interpreter
we use (if we go down this road), it's about libraries: most
sysadmin tasks require some basic networking and I/O,
and a FFI to seamlessly call out C functions from .so libs.
And, of course, instead of writing 1,001 sysadmin scripts
with endless code duplication and reinventing of the wheel,
common sysadmin tasks should also be made into reusable
functions, grouped into modules.
Exactly what I had in mind.
And we don't have to argue about which language. I would
suggest setting up a wiki page to list all the system scripts
people want to write and get cracking in your favorite
language! May the best effort win :-) At the very least we
will get some useful tools out of this effort. =A0I will
certainly help out with Scheme.
Funny idea. I only hope we won't end up with a typical
post-dot-com young developer distribution, a la:
60% PHP (yuck!)
25% Java (and XML-everywhere)
15% ${OTHERS}
;-)
If that is what people want then so be it :-)
But I think only little languages like forth, lua, sh, rc,
es scheme have small footprint interpreters that start up
fast and are reasonably efficient.
Anyway, system programming in Scheme is what interests me and
something I already tinker with on and off. If anyone is
interested (in helping or just playing with it), let me know
privately (but *not* on this mailing list).
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Interpreted language(s) in the base
On Fri, Aug 20, 2010 at 10:35 PM, Bakul Shah ba...@bitblocks.com wrote: Anyway, system programming in Scheme is what interests me and something I already tinker with on and off. If anyone is interested (in helping or just playing with it), let me know privately (but *not* on this mailing list). Not Scheme but still FP, and it is about little languages (called domain-specific languages these days) that you may find interesting: http://donsbot.wordpress.com/2010/08/17/practical-haskell/ :g ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: recent ath changes related panic
On Fri, Aug 20, 2010 at 1:56 AM, Bernhard Schmidt bschm...@techwires.net wrote: On Fri, Aug 20, 2010 at 08:31, Bernhard Schmidt bschm...@techwires.net wrote: On Fri, Aug 20, 2010 at 01:04, Chris Ruiz yr.retar...@gmail.com wrote: I run a PCI Atheros card in hostap mode on CURRENT. a...@pci0:6:0:0: class=0x02 card=0x5a001385 chip=0x0013168c rev=0x01 hdr=0x00 vendor = 'Atheros Communications Inc.' device = '802.11a/b/g Wireless Adapter (AR2312)' class = network subclass = ethernet Everything works fine with r211193 but with newer kernels I receive the same panic related to the ath0 tasq. I guess this also happens with post-r211314 kernels? Seems like I missed you wrap a few ieee80211_ratectl_node_init() calls. Please try attached patch, it should fix it. Thanks! My system no longer panics at the login prompt. -- Chris - http://twitter.com/chrisattack http://chrisattack.com ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Interpreted language(s) in the base
On Fri, 20 Aug 2010 21:33:08 +0200 =?utf-8?Q?Dag-Erling_Sm=C3=B8rgrav?= d...@des.no wrote: C. P. Ghost cpgh...@cordula.ws writes: After all LISP-like syntax is *still* more common and prevalent than Lua, e.g. in Elisp, guile, esh, scsh and a lot of other apps that use it as a small language. So we can expect more users to be at least partially familiar with it. And there *are* lightweight MIT- or BSD-licensed scheme interpreters out there too: Considering that the majority of people who might be interested in using this know *neither* Lisp *nor* Lua, my vote is for Lua, because people who are familiar with neither will be more open to learning Lua, which resembles other languages they already know, than Lisp, which doesn't. [Couldn't resist responding but my last message on this tangent] If you are open to learning a C like language, one can provide a C like frontend syntax to most of Scheme to a degreee similar to lua. Like C/Lua etc. Scheme is also a block structured language. Apart from syntax, the key differences are: - everything is an expression. - variables are not typed (anything can be assigned to a var) - functions can be anonymous, nested and returned from other functions - symbols lists are built-in unlike in C - no built-in structs, unions or ptrs - a very powerful macro facility - support for continuations ksm for instance implements a C like syntax. See http://square.umin.ac.jp/hchang/ksm/ref/ksm_13.html [Yes, I am aware of Dylan and what happened to it but still think this can be a useful effort] ___ 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 8/20/10, Dag-Erling Smørgrav d...@des.no wrote:
b. f. bf1...@googlemail.com writes:
At r211506, 'grep -wq' does not seem to work properly (in the very
least, it is not the same as with GNU grep),
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.
Using a current ports tree, go to a port with 'lisp' in CATEGORIES,
and run any ports target that requires 'check-categories', e.g.:
make -C /usr/ports/math/maxima check-categories
maxima-5.22.1: Makefile error: category lisp not in list of valid categories.
*** Error code 1
Stop in /mnt/disk2/usr/ports/math/maxima.
From bsd.port.mk:
2941 VALID_CATEGORIES+= accessibility afterstep arabic archivers
astro audio \
2942 benchmarks biology cad chinese comms converters databases \
2943 deskutils devel docs dns editors elisp emulators
finance french ftp \
2944 games geography german gnome gnustep graphics hamradio
haskell hebrew hungarian \
2945 ipv6 irc japanese java kde kld korean lang linux lisp \
2946 mail math mbone misc multimedia net net-im net-mgmt
net-p2p news \
2947 palm parallel pear perl5 plan9 polish portuguese ports-mgmt \
2948 print python ruby rubygems russian \
2949 scheme science security shells spanish sysutils \
2950 tcl textproc tk \
2951 ukrainian vietnamese windowmaker www \
2952 x11 x11-clocks x11-drivers x11-fm x11-fonts
x11-servers x11-themes \
2953 x11-toolkits x11-wm xfce zope
2954
2955 check-categories:
2956 .for cat in ${CATEGORIES}
2957 @if ${ECHO_CMD} ${VALID_CATEGORIES} | ${GREP} -wq ${cat}; then \
2958 ${TRUE}; \
2959 else \
2960 ${ECHO_MSG} ${PKGNAME}: Makefile error:
category ${cat} not in list of valid categories. 2960 ; \
2961 ${FALSE}; \
2962 fi
2963 .endfor
A closer look at VALID_CATEGORIES, using vis -oltw:
VALID_CATEGORIES+=\040accessibility\040afterstep\040arabic\040archivers\040astro\040audio\040\\\$
\011benchmarks\040biology\040cad\040chinese\040comms\040converters\040databases\040\\\$
\011deskutils\040devel\040docs\040dns\040editors\040elisp\040emulators\040finance\040french\040ftp\040\\\$
\011games\040geography\040german\040gnome\040gnustep\040graphics\040hamradio\040haskell\040hebrew\040hungarian\040\\\$
\011ipv6\040irc\040japanese\040java\040kde\040kld\040korean\040lang\040linux\040lisp\040\\\$
\011mail\040math\040mbone\040misc\040multimedia\040net\040net-im\040net-mgmt\040net-p2p\040news\040\\\$
\011palm\040parallel\040pear\040perl5\040plan9\040polish\040portuguese\040ports-mgmt\040\\\$
\011print\040python\040ruby\040rubygems\040russian\040\\\$
\011scheme\040science\040security\040shells\040spanish\040sysutils\040\\\$
\011tcl\040textproc\040tk\040\\\$
\011ukrainian\040vietnamese\040windowmaker\040www\040\\\$
\011x11\040x11-clocks\040x11-drivers\040x11-fm\040x11-fonts\040x11-servers\040x11-themes\040\\\$
\011x11-toolkits\040x11-wm\040xfce\040zope\$
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.
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: CD/DVD ejecting after sysinstall
On 20 Aug 2010, at 20:46, Jim Riggs wrote: References: http://www.mail-archive.com/svn-src-...@freebsd.org/msg24380.html http://forums.freebsd.org/showthread.php?t=17126 This commit automatically ejects the CD when sysinstall exits which almost had dire consequences for me this week. As described in the forum post, I keep a LiveFS CD in all of my servers so that I can remotely diagnose and fix issues. I have done this for several years now, and it has saved my tail many times. However, I got a surprise when I tried it today with the new 8.1 LiveFS CDs I had just burned. After attempting to fix a problem from the LiveFS and rebooting back to the HD, the problem still existed. No problem. I just tried to boot back to the CD only to find that it was gone. Luckily, this was on a box in-house, so I was quickly able to see what was wrong. Now that I have the commit, I can roll my own patched sysinstall and CDs, but the question is: Should we be ejecting the media without any prompt? Obviously, for my use case, I liked the old behavior of just reminding the user to eject the media when rebooting. I understand that may not be optimal for some users. Can we present a dialog asking the user if they want the media to be ejected? That still leaves me at risk of selecting the wrong answer, I suppose. I would rather not have to roll my own LiveFS CDs every time, though. Thoughts from anyone else? (Please copy me on responses.) You are correct. We should not be ejecting the CD without a prompt. If the commit is reverted, it should be explicitly noted in the code so that we don't do this mistake again. Regards, -- Rui Paulo ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
meory file system
Hi, All: I am running 8.1. under /dev, I don't see /dev/md0, so i am trying to add following lines in kernel file and got error messages: options MFS #Memory Filesystem /usr/src/sys/i386/conf/bn39_1: unknown option MFS *** Error code 1 Stop in /usr/src. *** Error code 1 any gurus here know what is happeny here? ___ 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: meory file system
On Fri, Aug 20, 2010 at 03:08:30PM -0700, gahn wrote: Hi, All: I am running 8.1. under /dev, I don't see /dev/md0, so i am trying to add following lines in kernel file and got error messages: options MFS #Memory Filesystem /usr/src/sys/i386/conf/bn39_1: unknown option MFS *** Error code 1 Stop in /usr/src. *** Error code 1 any gurus here know what is happeny here? There isn't a MFS option. Try 'man mdconfig'. PS: Your message should have been sent for freebsd-questi...@freebsd.org. -- Steve ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: [head tinderbox] failure on powerpc64/powerpc
On 08/20/10 14:20, Dag-Erling Smørgrav wrote: Nathan Whitehornnwhiteh...@freebsd.org writes: Next up: tinderbox needs to build GENERIC64, not GENERIC, on powerpc64. make buildkernel is programmed to do the right thing is you don't pass a KERNCONF, but tinderbox apparently passes GENERIC explicitly. This one's in your court! There is no way to fix this with the current tinderbox code. MHO is that the entire powerpc64 thing is very poorly thought out. I'm the first to admit that many of the config tricks involved in this port, and GENERIC64, are ugly hacks, largely because config(8) was not designed with such things in mind. But the alternatives were much worse: - A sys/powerpc64 that duplicated most of sys/powerpc, which would have been a maintenance nightmare (see sun4v). - A sys/powerpc64 that was mostly symlinks and stub includes, which is inelegant at best, and could cause kinds of fascinating problems for user programs including things in machine/. - Bunches of new make variables like TARGET_BIG_ENDIAN and TARGET_64BIT and such like mips and arm have, which is way more awful, as well as precluding tinderbox and make universe coverage in a reasonable way. powerpc64 is the first architecture trying out this new multi-architecture MACHINE approach, which Warner designed to kill off things like TARGET_BIG_ENDIAN, so there are going to be some interesting rough patches along the way, and I really appreciate your patience in sorting them out. To address the immediate problem, I think the best solution is to use the -m option to config to reject kernel configs for different architectures, the way the tinderbox scripts currently skip kernel configs that they are asked to build that don't exist. If you think this is a reasonable approach, I'm happy to code up a patch to tinderbox to do this over the weekend. You can feel free to disconnect powerpc64 from tinderbox in the interim. -Nathan ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: meory file system
2010/8/21 Steve Kargl s...@troutmask.apl.washington.edu: On Fri, Aug 20, 2010 at 03:08:30PM -0700, gahn wrote: Hi, All: I am running 8.1. under /dev, I don't see /dev/md0, so i am trying to add following lines in kernel file and got error messages: options MFS #Memory Filesystem /usr/src/sys/i386/conf/bn39_1: unknown option MFS *** Error code 1 Stop in /usr/src. *** Error code 1 any gurus here know what is happeny here? There isn't a MFS option. Try 'man mdconfig'. Also, have a look at tmpfs ! PS: Your message should have been sent for freebsd-questi...@freebsd.org. -- Steve ___ 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 -- Olivier Smedts _ ASCII ribbon campaign ( ) e-mail: oliv...@gid0.org - against HTML email vCards X www: http://www.gid0.org - against proprietary attachments / \ Il y a seulement 10 sortes de gens dans le monde : ceux qui comprennent le binaire, et ceux qui ne le comprennent pas. ___ 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
Latest intr problems
Here are the results of a vmstat -i, the old dtrace script, and Andriy's new one. interrupt total rate irq1: atkbd0 10420 1 irq9: acpi0 111 0 irq14: ata0 176564 26 irq17: wpi0 105948 15 irq20: hpet0 uhci0+ 858975128 irq22: uhci2 18972 2 cpu0:timer 6655466997 irq256: hdac0 11 0 cpu1:timer 6656559997 Total 14483026 2170 CPU IDFUNCTION:NAME 1 2 :END kernel`loadav value - Distribution - count 16384 | 0 32768 |@@@ 2 65536 |@1 131072 | 0 0xc0b6bf30 value - Distribution - count 65536 | 0 131072 | 1 262144 | 0 kernel`ieee80211_node_timeout value - Distribution - count 131072 | 0 262144 | 1 524288 | 0 kernel`ipport_tick value - Distribution - count 256 | 0 512 |@2 1024 |@@@ 1 2048 | 0 4096 | 0 8192 | 0 16384 |@@@ 4 32768 |@2 65536 | 6 131072 | 0 0xc0b6a9d0 value - Distribution - count 256 | 0 512 |@@@ 1 1024 |@@@ 1 2048 | 0 4096 |@@@ 1 8192 | 0 16384 |@@@ 4 32768 |@@@ 4 65536 | 3 131072 |@@@ 1 262144 | 0 kernel`kbdmux_kbd_intr_timo value - Distribution - count 512 | 0 1024 |@2 2048 |@@@ 1 4096 | 0 8192 | 0 16384 | 3 32768 | 3 65536 | 6 131072 | 0 kernel`nd6_timer value - Distribution - count 1024 | 0 2048 |@@@ 1 4096 | 0 8192 | 0 16384 |@2 32768 | 3 65536 |@5 131072 |@@@ 4 262144 | 0 kernel`uma_timeout value - Distribution - count 524288 | 0 1048576 | 1 2097152 | 0 kernel`usb_power_wdog value - Distribution - count 2048 | 0 4096 |@@@ 1 8192 | 0 16384 | 0 32768 |@@@ 1
why GNU grep is fast
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. #1 trick: GNU grep is fast because it AVOIDS LOOKING AT EVERY INPUT BYTE. #2 trick: GNU grep is fast because it EXECUTES VERY FEW INSTRUCTIONS FOR EACH BYTE that it *does* look at. GNU grep uses the well-known Boyer-Moore algorithm, which looks first for the final letter of the target string, and uses a lookup table to tell it how far ahead it can skip in the input whenever it finds a non-matching character. GNU grep also unrolls the inner loop of Boyer-Moore, and sets up the Boyer-Moore delta table entries in such a way that it doesn't need to do the loop exit test at every unrolled step. The result of this is that, in the limit, GNU grep averages fewer than 3 x86 instructions executed for each input byte it actually looks at (and it skips many bytes entirely). See Fast String Searching, by Andrew Hume and Daniel Sunday, in the November 1991 issue of Software Practice Experience, for a good discussion of Boyer-Moore implementation tricks. It's available as a free PDF online. Once you have fast search, you'll find you also need fast input. GNU grep uses raw Unix input system calls and avoids copying data after reading it. Moreover, GNU grep AVOIDS BREAKING THE INPUT INTO LINES. Looking for newlines would slow grep down by a factor of several times, because to find the newlines it would have to look at every byte! So instead of using line-oriented input, GNU grep reads raw data into a large buffer, searches the buffer using Boyer-Moore, and only when it finds a match does it go and look for the bounding newlines. (Certain command line options like -n disable this optimization.) Finally, when I was last the maintainer of GNU grep (15+ years ago...), GNU grep also tried very hard to set things up so that the *kernel* could ALSO avoid handling every byte of the input, by using mmap() instead of read() for file input. At the time, using read() caused most Unix versions to do extra copying. Since GNU grep passed out of my hands, it appears that use of mmap became non-default, but you can still get it via --mmap. And at least in cases where the data is already file system buffer caches, mmap is still faster: $ time sh -c 'find . -type f -print | xargs grep -l 123456789abcdef' real 0m1.530s user 0m0.230s sys 0m1.357s $ time sh -c 'find . -type f -print | xargs grep --mmap -l 123456789abcdef' real 0m1.201s user 0m0.330s sys 0m0.929s [workload was a 648 megabyte MH mail folder containing 41000 messages] So even nowadays, using --mmap can be worth a 20% speedup. Summary: - Use Boyer-Moore (and unroll its inner loop a few times). - Roll your own unbuffered input using raw system calls. Avoid copying the input bytes before searching them. (Do, however, use buffered *output*. The normal grep scenario is that the amount of output is small compared to the amount of input, so the overhead of output buffer copying is small, while savings due to avoiding many small unbuffered writes can be large.) - Don't look for newlines in the input until after you've found a match. - Try to set things up (page-aligned buffers, page-sized read chunks, optionally use mmap) so the kernel can ALSO avoid copying the bytes. The key to making programs fast is to make them do practically nothing. ;-) Regards, Mike ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
[head tinderbox] failure on powerpc64/powerpc
TB --- 2010-08-21 01:46:10 - tinderbox 2.6 running on freebsd-current.sentex.ca TB --- 2010-08-21 01:46:10 - starting HEAD tinderbox run for powerpc64/powerpc TB --- 2010-08-21 01:46:10 - cleaning the object tree TB --- 2010-08-21 01:47:03 - cvsupping the source tree TB --- 2010-08-21 01:47:03 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/HEAD/powerpc64/powerpc/supfile TB --- 2010-08-21 01:47:34 - building world TB --- 2010-08-21 01:47:34 - MAKEOBJDIRPREFIX=/obj TB --- 2010-08-21 01:47:34 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2010-08-21 01:47:34 - TARGET=powerpc TB --- 2010-08-21 01:47:34 - TARGET_ARCH=powerpc64 TB --- 2010-08-21 01:47:34 - TZ=UTC TB --- 2010-08-21 01:47:34 - __MAKE_CONF=/dev/null TB --- 2010-08-21 01:47:34 - cd /src TB --- 2010-08-21 01:47:34 - /usr/bin/make -B buildworld World build started on Sat Aug 21 01:47:35 UTC 2010 Rebuilding the temporary build tree stage 1.1: legacy release compatibility shims stage 1.2: bootstrap tools stage 2.1: cleaning up the object tree stage 2.2: rebuilding the object tree stage 2.3: build tools stage 3: cross tools stage 4.1: building includes stage 4.2: building libraries stage 4.3: make dependencies stage 4.4: building everything stage 5.1: building 32 bit shim libraries World build completed on Sat Aug 21 03:31:56 UTC 2010 TB --- 2010-08-21 03:31:56 - generating LINT kernel config TB --- 2010-08-21 03:31:56 - cd /src/sys/powerpc/conf TB --- 2010-08-21 03:31:56 - /usr/bin/make -B LINT TB --- 2010-08-21 03:31:56 - building LINT kernel TB --- 2010-08-21 03:31:56 - MAKEOBJDIRPREFIX=/obj TB --- 2010-08-21 03:31:56 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2010-08-21 03:31:56 - TARGET=powerpc TB --- 2010-08-21 03:31:56 - TARGET_ARCH=powerpc64 TB --- 2010-08-21 03:31:56 - TZ=UTC TB --- 2010-08-21 03:31:56 - __MAKE_CONF=/dev/null TB --- 2010-08-21 03:31:56 - cd /src TB --- 2010-08-21 03:31:56 - /usr/bin/make -B buildkernel KERNCONF=LINT Kernel build for LINT started on Sat Aug 21 03:31:56 UTC 2010 stage 1: configuring the kernel stage 2.1: cleaning up the object tree stage 2.2: rebuilding the object tree stage 2.3: build tools stage 3.1: making dependencies stage 3.2: building everything Kernel build for LINT completed on Sat Aug 21 03:57:39 UTC 2010 TB --- 2010-08-21 03:57:39 - building GENERIC kernel TB --- 2010-08-21 03:57:39 - MAKEOBJDIRPREFIX=/obj TB --- 2010-08-21 03:57:39 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2010-08-21 03:57:39 - TARGET=powerpc TB --- 2010-08-21 03:57:39 - TARGET_ARCH=powerpc64 TB --- 2010-08-21 03:57:39 - TZ=UTC TB --- 2010-08-21 03:57:39 - __MAKE_CONF=/dev/null TB --- 2010-08-21 03:57:39 - cd /src TB --- 2010-08-21 03:57:39 - /usr/bin/make -B buildkernel KERNCONF=GENERIC Kernel build for GENERIC started on Sat Aug 21 03:57:39 UTC 2010 stage 1: configuring the kernel stage 2.1: cleaning up the object tree stage 2.2: rebuilding the object tree stage 2.3: build tools stage 3.1: making dependencies stage 3.2: building everything [...] /src/sys/dev/ofw/ofw_standard.c:705: warning: cast to pointer from integer of different size /src/sys/dev/ofw/ofw_standard.c: In function 'ofw_std_release': /src/sys/dev/ofw/ofw_standard.c:719: warning: cast from pointer to integer of different size /src/sys/dev/ofw/ofw_standard.c:724: warning: cast from pointer to integer of different size /src/sys/dev/ofw/ofw_standard.c: In function 'ofw_std_enter': /src/sys/dev/ofw/ofw_standard.c:742: warning: cast from pointer to integer of different size /src/sys/dev/ofw/ofw_standard.c: In function 'ofw_std_exit': /src/sys/dev/ofw/ofw_standard.c:760: warning: cast from pointer to integer of different size *** Error code 1 Stop in /obj/powerpc.powerpc64/src/sys/GENERIC. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2010-08-21 04:03:10 - WARNING: /usr/bin/make returned exit code 1 TB --- 2010-08-21 04:03:10 - ERROR: failed to build GENERIC kernel TB --- 2010-08-21 04:03:10 - 5652.94 user 1594.18 system 8220.05 real http://tinderbox.freebsd.org/tinderbox-head-HEAD-powerpc64-powerpc.full ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
npviewer.bin and nspluginwrapper errors
These are various error messages collected from running X and/or firefox from the command line: *** NSPlugin Viewer *** WARNING: unhandled variable 18 (unknown variable) in NPN_GetValue() I get lots and lots of these, even when things are working well. npviewer.bin: ../src/npw-rpc.c:1190: do_send_NPObject: Assertion `npobj_id != 0' failed. *** NSPlugin Wrapper *** ERROR: NPN_ReleaseObject() get args: Connection closed *** NSPlugin Wrapper *** ERROR: NPP_Destroy() wait for reply: Connection closed *** NSPlugin Wrapper *** ERROR: NPObject 0x2fac2100 is no longer valid! When I get these no longer valid errors is usually about the time that intr starts to run away. *** NSPlugin Wrapper *** WARNING:(/usr/local/tmp/usr/local/ports/www/nspluginwra pper/work/nspluginwrapper-1.2.2/src/npw-wrapper.c:1855):invoke_NPP_Destroy: asse rtion failed: (rpc_method_invoke_possible(plugin-connection)) *** NSPlugin Wrapper *** ERROR: NPClass::HasProperty() wait for reply: Connection closed *** NSPlugin Wrapper *** ERROR: NPObject 0x2f6235d0 is no longer valid! *** NSPlugin Wrapper *** ERROR: NPObject 0x2f6235d0 is no longer valid! *** NSPlugin Wrapper *** ERROR: NPObject 0x2f6235d0 is no longer valid! *** NSPlugin Wrapper *** ERROR: NPObject 0x2f6235d0 is no longer valid! *** NSPlugin Wrapper *** ERROR: NPObject 0x2f6235d0 is no longer valid! *** NSPlugin Wrapper *** ERROR: NPObject 0x2f6235d0 is no longer valid! *** NSPlugin Wrapper *** ERROR: NPObject 0x2f6235d0 is no longer valid! *** NSPlugin Wrapper *** WARNING:(/usr/local/tmp/usr/local/ports/www/nspluginwrapper/work/nspluginwrapper-1.2.2/src/npw-wrapper.c:1855):invoke_NPP_Destroy: assertion failed: (rpc_method_invoke_possible(plugin-connection)) *** NSPlugin Wrapper *** ERROR: NPObject 0x2f6235d0 is no longer valid! *** NSPlugin Wrapper *** WARNING:(/usr/local/tmp/usr/local/ports/www/nspluginwrapper/work/nspluginwrapper-1.2.2/src/npw-wrapper.c:1855):invoke_NPP_Destroy: assertion failed: (rpc_method_invoke_possible(plugin-connection)) -- 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
