Derrick Lobo | 1 Dec 14:52 2009

Optizing kernel config

How do I optimize this if I have 4 CPU and 16gb of ram

< maxusers      128             # estimated number of users
< options         MAXUPRC=1800
< options         SHMMAXPGS=131072
< options         SEMMNI=256
< options         SEMMNS=512
< options         SEMMAP=1024
< options         NMBCLUSTERS=16384

Derrick

Joerg Sonnenberger | 1 Dec 15:34 2009
Picon

Re: Optizing kernel config

On Tue, Dec 01, 2009 at 08:52:43AM -0500, Derrick Lobo wrote:
> How do I optimize this if I have 4 CPU and 16gb of ram

If you have a reasonable modern NetBSD, the shared memory and IPC
options are obsolete. You should use the corresponding sysctls.

The optimal setting for nmbclusters depends a lot on what you are
actually doing, so without further information it is hard to tell.

Joerg

Andrew Smallshaw | 1 Dec 17:34 2009
Picon

Re: Multiboot header license change

On Mon, Nov 30, 2009 at 04:55:47PM +0000, Stephen Borrill wrote:
> On Mon, 30 Nov 2009, Andrew Smallshaw wrote:
> >
> >I'm thinking that provides a fresh workaround for the long-standing
> >bug on VIA ITX systems.  The old advice (use an old bootloader) is
> >getting trickier a it gets more and more outdated.  I know I had
> >plenty of issues getting this 5.0 system installed - from memory I
> >needed the bootblocks from 1.6 and the installer from 4.0 to install
> >5.0...
> 
> EDEN/Samuel 2?
> 
> dsl <at>  has just committed a fix for this. I aim to test a backport soon.

Nice one!  I had a play with this pulled from the daily build last
night.  I built a USB drive installer using boot, bootxx_ffsv1 and
mbr from the daily build and everything else simply copied over
from the 5.0-RELEASE installation CD.  No issues to report at all
- it simply works.  I haven't tried it on the hard drive since that
is a working system I'd rather leave alone.

In terms of a data point if that is useful this was on an EPIA
ME6000 board.

n2e$ dmesg|grep cpu
cpu0 at mainbus0: IDT/VIA 686-class, 599MHz, id 0x673

I can't tell you how pleased I am by this.  They're good little
boards for a certain class of problem and it's nice that they work
properly again.
(Continue reading)

Hou, Ruoyu | 1 Dec 18:35 2009
Picon

Japanese Keyboard Layout in Console

Hi all,

I've installed NetBSD on a laptop with Japanese keyboard layout and now 
I encountered with some weird problems.

The keyboard of the box has 84 keys, which the manufacturer claims to 
conform OADG 106 standard. <PageUp>, <PageDown>,<Home>,<End> are bound 
to <Up>,<Down>,<Left>,<Right>, respectively, and triggered with <Fn> 
key. Keyboard encoding in wscons.conf was set to jp, and jp106 without 
additional rules in xorg.conf. Then I noticed some odd output.

In X window, nearly every output perfectly fits the keysyms except one 
key: <^/'upper dash'>. the shifted one ("upper dash") is output as 
tilde. Those conversion keys (henkan, muhenkan, hirakana/katakana) are 
also correctly recognized.

In console, however, <backspace> and <delete> act the same. <Home> <End>
<'upper dash'> all produce tilde while the actual <0/~> echoes only 0 
but no tilde whether shifted or not. Moreover, while I can use 
<Ctrl>-<Alt>-<Fx> to switch ttys, emacs in console mode failed to 
recognize <Alt> as Meta key so I was obliged to use <Esc> as Meta.

<'upper dash'> seems redundant and I do not really care it, but the 
synced <backspace> and <delete>, unrecognized <Alt> in emacs are pain in 
my ass. I guess this may be fixed by remapping my keyboard with proper 
scan code. Is there anyone who experienced similar problem? I would 
appreciate any hints or references.

Regards,
--

-- 
(Continue reading)

David Laight | 1 Dec 19:19 2009
Picon

Re: Xeon X3430 = immediate panic

On Mon, Nov 30, 2009 at 10:58:48PM +0000, Matthias Scheler wrote:
> On Mon, Nov 30, 2009 at 06:12:54PM +0100, Christoph Egger wrote:
> > > How do they do that? Do they modify interrupt vector 13 so it
> > > doesn't panic the kernel but instead sets some variable?
> > 
> > Linux and Xen have a rdmsr_safe and wrmsr_safe function
> > which sets up a 'fixup' section where the cpu jumps to on #GP.
> > The rdmsr_safe/wrmsr_safe return failure in that case.
> 
> How hard is it to implement something like that in NetBSD? The FreeBSD
> code which does this looks straightforward. But I don't know enough
> about IDT handling in NetBSD.

The #GP fault handling shouldn't be that much different from the page fault
handling. So I suspect the same sort of hackery that allows page faults
to be non-fatal could be used.

	David

--

-- 
David Laight: david <at> l8s.co.uk

Steve Blinkhorn | 1 Dec 18:35 2009
Picon

system call incompatibilities across releases

Three years ago I got badly bitten trying to upgrade a remote colo
server from 1.6 to 3.0.   There were two sources of difficulty: the
first was to do with the introduction of PAM; but what really did it
was the system call incompatibility introduced that meant that 3.0
binaries would not interoperate with a 1.6 kernel, so I ended up
unable to finish the business of copying all the 3.0 files (including
pam.d) into place.   So I had to go to the server farm and install
manually.

The time has come to do another round of upgrades, so I'm
understandably concerned not to run into any similar issues.   Is
there a document somewhere that lists potential issues of this kind?
I have the impression that documentation concentrates on typical or
preferred ways of installing, configuring etc., to the exclusion of
boundary conditions, like remote upgrades to headless servers, for
which one needs to tap into the wisdom of the community.

--

-- 
Steve Blinkhorn <steve <at> prd.co.uk>

Quentin Garnier | 1 Dec 20:03 2009
Picon

Re: system call incompatibilities across releases

On Tue, Dec 01, 2009 at 05:35:49PM +0000, Steve Blinkhorn wrote:
> Three years ago I got badly bitten trying to upgrade a remote colo
> server from 1.6 to 3.0.   There were two sources of difficulty: the
> first was to do with the introduction of PAM; but what really did it
> was the system call incompatibility introduced that meant that 3.0
> binaries would not interoperate with a 1.6 kernel, so I ended up
> unable to finish the business of copying all the 3.0 files (including
> pam.d) into place.   So I had to go to the server farm and install
> manually.

Are you really saying that you're upset that 3.0 binaries were not
meant to be run with a 1.6 kernel?

> The time has come to do another round of upgrades, so I'm
> understandably concerned not to run into any similar issues.   Is
> there a document somewhere that lists potential issues of this kind?

Well, I'm pretty sure everything that describes how to update a system
include booting a new kernel first...

And then running etcupdate of course;  you probably wouldn't have been
hit so hard with PAM if you had done that.

--

-- 
Quentin Garnier - cube <at> cubidou.net - cube <at> NetBSD.org
"See the look on my face from staying too long in one place
[...] every time the morning breaks I know I'm closer to falling"
KT Tunstall, Saving My Face, Drastic Fantastic, 2007.
Steve Blinkhorn | 1 Dec 20:48 2009
Picon

Re: system call incompatibilities across releases

 Quentin Garnier wrote:
> 
> On Tue, Dec 01, 2009 at 05:35:49PM +0000, Steve Blinkhorn wrote:
> > Three years ago I got badly bitten trying to upgrade a remote colo
> > server from 1.6 to 3.0.   There were two sources of difficulty: the
> > first was to do with the introduction of PAM; but what really did it
> > was the system call incompatibility introduced that meant that 3.0
> > binaries would not interoperate with a 1.6 kernel, so I ended up
> > unable to finish the business of copying all the 3.0 files (including
> > pam.d) into place.   So I had to go to the server farm and install
> > manually.
> 
> Are you really saying that you're upset that 3.0 binaries were not
> meant to be run with a 1.6 kernel?

No, I'm not saying anything at all concerning how I felt, I'm
describing a sequence of events, briefly, which was a source of real
difficulty and which I wouldn't like to have to handle again.  There's
a lot of implicit knowledge held by people whose lives are more
entangled with the detail than is the case for those of us for whom
computing is just an enabling technology, and it doesn't always shine
through the documentation. 

> 
> > The time has come to do another round of upgrades, so I'm
> > understandably concerned not to run into any similar issues.   Is
> > there a document somewhere that lists potential issues of this kind?
> 
> Well, I'm pretty sure everything that describes how to update a system
> include booting a new kernel first...
(Continue reading)

Dave Huang | 1 Dec 21:06 2009

Re: system call incompatibilities across releases

Steve Blinkhorn wrote:
> And if I had booted a new kernel first, I would have been unable to
> log in remotely because of PAM, so I wouldn't have been able to run
> etcupdate, a fortiori.   That's precisely the sort of gotcha I want to
> avoid.   See what I mean?

Hmm, it's been a long time since I upgraded to 3.0, but is that really the 
case? It doesn't seem like the kernel would have anything to do with PAM. 
I've always done upgrades by installing the new kernel first (and only the 
kernel) and booting that, then installing the userland binaries. IIRC, the 
only time there were some issues with that was when scheduler activations 
were removed from the kernel, and pthread-using binaries didn't work, but 
that didn't prevent me from installing new binaries.

Manuel Bouyer | 1 Dec 21:17 2009

Re: system call incompatibilities across releases

On Tue, Dec 01, 2009 at 07:48:10PM +0000, Steve Blinkhorn wrote:
> [...]
> And if I had booted a new kernel first, I would have been unable to
> log in remotely because of PAM, so I wouldn't have been able to run
> etcupdate, a fortiori.   That's precisely the sort of gotcha I want to
> avoid.   See what I mean?

No, pam has nothing to do with the kernel. The correct upgrade sequence
is:
1) install new kernel (with COMPAT_30 of course, if your build your
  own kernel), reboot
2) extract .tgz sets (exept etc and xetc) for new binaries in /
3) extract etc.tgz and xetc.tgz in /tmp and run
   postinstall -s /tmp -d / fix
   (fix manually issues that postinstall couldn't sort out and run again,
   until all is OK).

Don't reboot between 2 and 3 of course, or you'll boot a half-upgraded
system and could have issues.
This has worked for me between 1.6 and 3.0, and again between 3.0 and
5.0 on a wide variety of systems.

--

-- 
Manuel Bouyer <bouyer <at> antioche.eu.org>
     NetBSD: 26 ans d'experience feront toujours la difference
--


Gmane