Re: CVS commit: src/regress/sys/net
On Thu, Mar 03, 2011 at 12:27:19AM +, David Holland wrote: On Tue, Mar 01, 2011 at 08:02:40AM +, David Laight wrote: autogen requires ed(1), which is not provided by our toolchain. (In other words, this causes a odd build failure on some Linux build hosts.) I've not looked, but it is probably not too hard to change the script to use a different tool. (Possibly just a shell script) This should do the trick, modulo feeding in ${TOOL_AWK} properly: ... +awk $1 ' +state == 0 /^ether_aton_r/ { print prev; state = 1; } +state == 1 { print; } +state == 1 /^}$/ { state = 2; } +{ prev = $0; } +' $2 Looks like that would be even simpler in sed :-) David -- David Laight: da...@l8s.co.uk
Re: CVS commit: src/sys/fs/msdosfs
On Thu, Mar 03, 2011 at 08:10:45AM +, Antti Kantee wrote: Module Name: src Committed By: pooka Date: Thu Mar 3 08:10:45 UTC 2011 Modified Files: src/sys/fs/msdosfs: msdosfs_vnops.c Log Message: In rename, use char[12]?for new names instead of [11]. At least one routine called from here (unix2dosfn) expects and uses all of a [12]. This may fix the stack size exceeded problem which has been triggering in gson's test runs. (i'm not entirely sure why it doesn't trigger in anyone else's env) Is he perhaps using USE_SSP=yes? Kind regards -- Matthias Scheler http://zhadum.org.uk/
Re: CVS commit: src/regress/sys/net
On Thu, Mar 03, 2011 at 08:09:49AM +, David Laight wrote: +awk $1 ' +state == 0 /^ether_aton_r/ { print prev; state = 1; } +state == 1 { print; } +state == 1 /^}$/ { state = 2; } +{ prev = $0; } +' $2 Looks like that would be even simpler in sed :-) It's not - at best you'd have to branch, sed isn't stateful enough. -- David A. Holland dholl...@netbsd.org
Re: CVS commit: src/sys/fs/msdosfs
On Thu, Mar 03, 2011 at 11:12:35AM +0200, Antti Kantee wrote: Is he perhaps using USE_SSP=yes? Isn't that the default? Only for kernels and certain directories e.g. src/lib/libc. Maybe we should: 1.) Build all tests with USE_SSP=yes. 2.) Run them with MALLOC_OPTIONS set to AJ. Kind regards -- Matthias Scheler http://zhadum.org.uk/
Re: CVS commit: src/sys/arch/amd64/include
In article 20110304033425.0e01017...@cvs.netbsd.org, Joerg Sonnenberger source-changes-d@NetBSD.org wrote: -=-=-=-=-=- Module Name: src Committed By: joerg Date: Fri Mar 4 03:34:24 UTC 2011 Modified Files: src/sys/arch/amd64/include: vmparam.h Log Message: Reduce MAXSSIZ to 64MB, otherwise netbsd32 binaries crash in ld.elf_so, including the trivial main(){}. Add a warning to not modify this without testing compatibility mode. Please revert this. The 32 bit emulation is supposed to be using MAXSSIZ32. christos
re: CVS commit: src/sys/arch/x86/x86
Module Name: src Committed By: jruoho Date: Fri Mar 4 04:53:28 UTC 2011 Modified Files: src/sys/arch/x86/x86: est.c powernow.c Log Message: Raise the return value of the match-function of est(4) and powernow(4). The assigned priorities are now: 10 for acpicpu(4), 5 for est(4) and powernow(4), and 1 for odcm(4). These are used to pick the preferred driver. to the best of my knowledge, odcm(4) is separate to est(4) and old school speedstep, and both can be active at the same time. i've certainly done this on an old P4-M. .mrg.
Re: CVS commit: src/sys/arch/x86/x86
On Fri, Mar 04, 2011 at 04:04:53PM +1100, matthew green wrote: Raise the return value of the match-function of est(4) and powernow(4). The assigned priorities are now: 10 for acpicpu(4), 5 for est(4) and powernow(4), and 1 for odcm(4). These are used to pick the preferred driver. to the best of my knowledge, odcm(4) is separate to est(4) and old school speedstep, and both can be active at the same time. i've certainly done this on an old P4-M. This was discussed on port-i386@ and port-amd64@. Yes, both may be used at the same time. Yet, this is a curiosity. ODCM is nearly useless. No one even reported using it. - Jukka.
re: CVS commit: src/sys/arch/x86/x86
On Fri, Mar 04, 2011 at 04:04:53PM +1100, matthew green wrote: Raise the return value of the match-function of est(4) and powernow(4). The assigned priorities are now: 10 for acpicpu(4), 5 for est(4) and powernow(4), and 1 for odcm(4). These are used to pick the preferred driver. to the best of my knowledge, odcm(4) is separate to est(4) and old school speedstep, and both can be active at the same time. i've certainly done this on an old P4-M. This was discussed on port-i386@ and port-amd64@. Yes, both may be used at the same time. Yet, this is a curiosity. ODCM is nearly useless. No one even reported using it. yes - i never bothered to commit my code to use it because i could only measure at best a 1-2% battery life increase (ie, i wasn't really even sure i saw anything!) for a 7/8ths drop in performance (ie, running at 1/8 duty cycles.) .mrg.