Re: CVS commit: src/regress/sys/net

2011-03-03 Thread David Laight
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

2011-03-03 Thread Matthias Scheler
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

2011-03-03 Thread David Holland
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

2011-03-03 Thread Matthias Scheler
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

2011-03-03 Thread Christos Zoulas
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

2011-03-03 Thread matthew green

 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

2011-03-03 Thread Jukka Ruohonen
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

2011-03-03 Thread matthew green

 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.