Unable to boost maxusers in custom kernel.

[Kevin Kinsey]

Worth Bishop wrote:
> Thanks Kevin -
> 
>> First, I guess, be sure that it's using the file
>> you're specifying.
> 
> I've sure wondered about this. As I've compiled & installed the custom 
> kernels, I've watched the changes in the size & date/time stamp to the 
> /kernel binary file. It's definitely changing, and I think I've done 
> everything I'm supposed to to tell the system what kernel file to use. 
> I've gone so far as to copy the /kernel file into /kernel.GENERIC 
> (keeping a backup kernel.GENERIC) with the same results.
> 
> What troubles me is that every time I reboot I see:  FreeBSD 4.3-RELEASE 
> #0: Sat Apr 21 10:54:49 GMT 2001
> jkh at narf.osd.bsdi.com:/usr/src/sys/compile/GENERIC in the messages. I 
> don't see :/usr/src/sys/compile/MYKERNEL, even though I've changed the 
> ident line and every other reference to GENERIC I can find in the 
> configuration file to MYKERNEL.
> 

This is the output of "uname -a", I'm quite sure, and therefore is
a reference to the userland, and the kernel that was in place when
it was built.  If the kernel has a different date/time, etc., then
you've built it just fine...question is, what's up with the MAXUSERS
thing.


> What else can I do to ensure that the system is using the kernel I 
> intend it to use?
> 

That's about it.


> I've not tried setting maxusers to "0" but will. And as for 
> patches...well, I kind of inherited this system and am guessing patches 
> have been sporadically applied if at all. My own expertise is all OJT 
> and what I've gleaned from manuals, online help, folks like you, etc. My 
> inclination is to upgrade ASAP to newest release, but as this is a 
> production system with no hot spare and those who control it are 
> fanatically opposed to any downtime...it may need to reach crisis point 
> before that can be done.
> 
> Thanks again for any suggestions!
> 
> Worth Bishop
> 

I'm not sure I've any further suggestions.  I've pretty much decided
to keep close to updated; however, and somewhat unfortunately perhaps,
I've no boxes so "busy" and "mission-critical" that they can't be
rebooted now and again.....

Kevin Kinsey


> ----- Original Message ----- From: "Kevin Kinsey" <kdk at daleco.biz>
> To: "Worth Bishop" <wbishop at twosensemedia.com>
> Cc: <freebsd-questions at freebsd.org>
> Sent: Friday, July 07, 2006 4:11 AM
> Subject: Re: Unable to boost maxusers in custom kernel.
> 
> 
>> Worth Bishop wrote:
>>> Running FreeBSD 4.3 (I know - upgrade on the way, but would like to 
>>> know what's going on here for future ref), on AMD Athlon MP 1600 
>>> (1393.79-MHz 686-class CPU) with 1.5 Gb RAM. Ran up against 'too many 
>>> files' problem, dropped packets, maxing out mbuf's, proc files, etc.
>>>
>>> Attempted to compile custom kernel based on GENERIC only by changing 
>>> maxusers from 32 to (first) 512, then 256, then 128. No matter what, 
>>> system rebooted with 32 maxusers, 4096 mbugs, 1024 max mbuf clusters, 
>>> 1024 maxfiles. Can reset maxfiles via sysctl, but why won't maxusers 
>>> stick?
>>>
>>> Have tried building both with:
>>>
>>> #  /usr/sbin/config MYKERNEL
>>> #  cd ../../comple/MYKERNEL
>>> #  make depend
>>> #  make
>>> #  make install
>>> #  reboot
>>>
>>> and with
>>>
>>> #  cd /usr/src
>>> #  make buildkernel KERNCONF=MYKERNEL
>>> #  make installkernel KERNCONF=MYKERNEL
>>> #  reboot
>>>
>>> No discernable error messages.
>>>
>>> What am I missing?
>>>
>>
>> First, I guess, be sure that it's using the file
>> you're specifying.
>>
>> Next, hmm, per the Handbook, have you tried "0" (to let
>> the system "auto-tune" itself?)
>>
>> That said, after 4.5*, you can set this variable in
>> /boot/loader.conf ... I've no idea ATM whether or not
>> this behavior was "MFC'ed" back into your code stream
>> or not ... (surely you're not running 4.3 UNPATCHED<?!!>)
>> you may wish to check /boot/defaults/loader.conf for
>> evidence of this theory, and, if you find it, give that
>> a try as well.
>>
>>
>> HTH,
>>
>> Kevin Kinsey
>>
>> *This information isn't in the handbook (I don't think ...
>> I sent a doc PR a day or two ago on it due to a post
>> here by someone who was having troubles in the same
>> area, I guess...). 
> 
> 
> 
> 


-- 
No problem is insoluble in all conceivable circumstances.