Re: NetBSD-8 kernel too big?

On 2018-08-30 10:00 AM, Mouse wrote: >> My latest build of NetBSD 8 results in a kernel size of 24,964,488 >> bytes. Not sure if "kernel" is really the right term any more. :-) > > Indeed! > > I had a similar experience recently; it was with 5.2, but I suspect > much the same applies to -8. I

NetBSD-8 kernel too big?

My latest build of NetBSD 8 results in a kernel size of 24,964,488 bytes. Not sure if "kernel" is really the right term any more. :-) I have installed it on all of my servers except for one. It is a HP ProLiant DL160se G6. The failure is something like this: Read header failed: input/output

INTRSTACKSIZE in intr.c

There are some inline functions in sys/arch/x86/x86/intr.c that are only called if INTRSTACKSIZE is defined but the functions are declared static in any case which causes compile errors if -Werror is on which happens if developer is true in mk.conf. I don't normally work in the kernel so even

Re: /proc/#/ctl removal

On 08/27/2017 03:59 AM, Christos Zoulas wrote: LGTM, perhaps leave a comment /* old P_FSTRACE 0x0001 */ instead of completely removing the constants for now as a reminder. Isn't that sort of duplicating what CVS does? -- D'Arcy J.M. Cain http://www.NetBSD.org/

Re: IPfilter panic in 7.1

On 07/13/2017 05:29 AM, Stephen Borrill wrote: On Tue, 11 Jul 2017, Christos Zoulas wrote: In article <1n8zh65.79uodgaqcnrcm%m...@netbsd.org>, Emmanuel Dreyfus wrote: I am hit by frequent IPfilter panics on a firewall setup after upgrading to 7.1. Is it something someone else

Increasing entropy

I have been having entropy issues lately. In particular, password generation takes a long time. The apg utility usually takes almost a minute to run. I tried bitstir from pkgsrc which does solve the entropy issue but it does so by working the disk a lot. Besides concerns about lowering the

Re: Increasing entropy

On 12-06-08 02:31 PM, paul_kon...@dell.com wrote: Also, whether our current /dev/random is good or not, stirring /dev/urandom into it is a waste of time, because /dev/urandom is simply /dev/random without the blocking. I see. So basically I should just switch to /dev/urandom if I get too