Jacob,
Thank you very much for helping out - I apologise to you and the list
for the length of my first post - and this one.
Thank you very much for responding to some of my queries.
I have interspersed my responses with your edited version:
On 12/04/12 02:12, Jacob L. Leifman wrote:
First the caveats: I am long time OpenBSD user, but not a developer.
No problem - we are all learners ;-)
The original post was extremely long, and as I wanted to embed my
comments next to the original content they belong to, I also snipped
some irrelevant sections.
On 11 Apr 2012 at 22:14, Michael Davies wrote:
Hello OpenBSD World!!!
Long time Linux user who has recently been looking closely at OpenBSD
...[snipped]
without any problems. I used these package options: -x* then -game*
I have deployed many servers using the same selection with no ill
effect. However, a growing number of ports and packages has various x*
dependencies; and as Theo just recently pointed out on this ML, the
recommended and the only fully supported system configuration is with
everything installed.
I think Theo's words were something like "Why remove X...?"
I took X out because I had no intention of installing anything other
than rsync on this machine - hence further packages/ports were unlikely.
But the default system is very slim (cool!) so I expect I might put
these back in ;-) (Another wipe and install during the testing phase)
(removing these packages from the install - it's a NAS I'm creating
here). I had no problem setting up my static network address etc. etc. I
will install rsync via pkg_add later.
However, I have been trying to find out how OpenBSD handles ACPI/APM
Power Management and disk hibernation.
I have read quite a bit:
1) Michael Lucas' Absolute OpenBSD (2004)
Was highly rated at the time, but that was 16 releases ago...
Yep - he's writing a new one currently - but I couldn't wait ;-)
2) Secure Architectures with OpenBSD (2004)
ditto; good for concepts overview, but most implementation details have
changed quite radically.
Agree - but there's limited hardcopy material. Anything is better than
3) Michael Lucas' Absolute BSD (for FreeBSD) (2002)
old and mostly irrelevant -- the OpenBSD kernel is very different from
FreeBSD, and much of the stuff that FreeBSD chooses to import is either
dated or lacks the necessary kernel support (or both, as for example
the PF code).
I have found much of the book informative to understand general BSD
stuff ;-) and I am installing FBSD in a virtual machine for
experimentation... Toying with the dark side ;-) Bear with me ;-)
4) Calomel - you know the one
too bad -- now you have to UNread it; seriously, according to core
developers it is ALL wrong.
Did I say I'd read it all? I dip into everything to get a bigger picture :-)
5) I've tried to search the archived dialogues on Old Nabble (Difficult)
I have observed that when the developers refer to an old posting they
use http://marc.info/ almost exclusively.
That is VERY, VERY halpful. Thank you.
6) I've searched Daemon Forums
7) I've read the FAQ - Always the last place I look ;-)
When it comes to OpenBSD, the FAQ should be your first stop, closely
followed by the man pages. Official documentation is a source of pride
for the project -- documentation errors, even silly little typos, are
treated as seriously as any other bug.
I wrote that somewhat tongue in cheek ;-) I wasn't dissing the FAQ - I
meant I read it first ;-)) (Apart from "atactl", of course - see below)
This is what I feel I have learned:
1) Advanced Power Management on OpenBSD is handled by apmd. I know that
because enabling it through /etc/rc.conf, rebooting and then issuing zzz
puts the PC to sleep. When I tap a key - it wakes up again (exactly
where I left it). GREAT!
2) apmd does not automatically hibernate my disk (unless I am missing
something) - but it is possible that there are ports (I've read about these
for FreeBSD) which might handle disk hibernation: spindown and diskidle
3) I read somewhere that there is a danger in suspending/hibernating the
disk security wise - but haven't found a full explanation (Is RAM dumped
to disk unencrypted, perhaps?). That would explain why a program to
hibernate the disk isn't included in the default install of OpenBSD.
Unfortunately - searching the OpenBSD mailing lists I have subscribed
too is darn awkward (compared to some other fora - I know some issue
'tarred' archives that can be imported into an e-mail client - ever
considered it? :-) ).
SO... I've come to the fount of all knowledge to seek guidance on the
following:
1) Beyond apmd, is there a default handler of disk hibernation
install-ed/able via default OpenBSD?
2) To use apmd, do I need to maintain a swap partition? Indeed, should I
ALWAYS maintain a swap partition on this simple setup (which is running
fine)? I was hoping to get away without one (currently b: is undefined).
Are you really hurting for space that much? Unlike linux, OpenBSD will
not access the swap unless absolutely necessary. However, once again,
having no swap defined is neither standard nor fully supported setup.
Moreover, swap partition is where the system dumps core during panic. I
found it beneficial to have some swap space defined even when disk
capacity is an issue, and nowhere is it written that it needs to be big
(not even equal to RAM size).
I understand the danger with dumping the core - my DMESG indicates that
the Kernel EXPECTS a partition on wd0b: However, I was pondering whether
you could get away without since there wasn't much going to be happening
on this machine (only rsync-ing)... It isn't a space issue.
3) If spindown or diskidle exist in the packages/ports - would
installing these provide me with a disk hibernation facility for
OpenBSD?
4) Is there another way to manage the PC('NAS') using OpenBSD
to minimize power while the 'NAS' is available 24/7?
apm(8) -C does a pretty good job of dynamically reducing CPU power
waste and atactl(8) should help you configure the built-in functions of
your hard drive. Keep in mind that full system hibernation (aka suspend
to disk) is not compatible with 24/7 availability as you will have to
issue an explicit wake-on-lan and wait for it to become available.
OTOH, a modern system, especially one based on Atom processor and a
laptop SATA drive, does a darn good job of minimizing power waste
without completely shutting down.
Your response here is EXACTLY what I was seeking to elicit. Thank you
for referring to atactl - I hadn't encountered it so far. I'll go and
check it up imminently.
The problem with apm -C on my processor is that DMESG only defines one
supported processor state: 1800MHz I don't think it can step it...
Nevertheless - atactl sounds promising.
The Atom is, as you say, very efficient - the SATA drive takes 50% (22W
- see below) of the max demand of the D525MW (50W at full speed).
Personally this is how I built my home NAS -- I chose components with
modest power requirements and good built-in power management and let it
run 24/7. This way I know all the nightly maintenance is always up-to-
date, and I can even schedule some downloads and offsite backups for
those hours when it does not interfere with my family's Internet usage.
So on 24/7 - I think Nick Holland said that somewhere before... I was
hoping it might have changed...
All you savvy peeps who know where I am going on this - what's my best
case scenario?
An OpenBSD NAS which doesn't hibernate (Thinks... "Where can I get a
100W PSU?") or can I possibly achieve a NAS that hibernates the drive
and "Wake(s) on LAN"?
I'd settle for simply hibernating the disk (That's about 22W there -
You might want to recheck your facts and figures -- 22W is much too
high for a 2.5" SATA drive even peak, and a modern drive like that will
dynamically adjust its power draw, more if you turn on the relevant
settings with atactl(8).
Max draw on spin-up is 4.5A @ 5V = 22W. But you ARE right, typically
it's around 2.5W max. in operation.
half the power draw) - but if the full monty is possible - I'll keep on
digging.
dmesg details follow this EXTREMELY LONG FIRST POST. Thanks for YOUR
patience, y'all ;-)
Mike
P.S. Anybody know why there is an RTC BIOS error 80 for the clock
battery (See below)? Brand New board, this one.
That error is generated by your hardware. You probably need to go into
BIOS setup utility and "Save Settings" which will recalculate the CMOS
checksum and should clear the error.
Strange because it's output through DMESG. Nevertheless, I'll have a
look at saving NVRAM again ;-)
P.P.S. The i386 32-bit version 5.0 works on this MB too - but I haven't
attached the DMESG for that...
**************************************************************
OpenBSD 5.0 (GENERIC.MP) #63: Wed Aug 17 10:14:30 MDT 2011
dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP
RTC BIOS diagnostic error 80<clock_battery>
real mem = 4275666944 (4077MB)
avail mem = 4147728384 (3955MB)
mainbus0 at root
bios0 at mainbus0: SMBIOS rev. 2.5 @ 0xcee98000 (27 entries)
bios0: vendor Intel Corp. version "MWPNT10N.86A.0083.2011.0524.1600"
date 05/24/2011
bios0: Intel Corporation D525MW
acpi0 at bios0: rev 2
acpi0: sleep states S0 S1 S3 S4 S5
...[snipped]
swap on wd0b dump on wd0b
The generic kernel (the only developer supported configuration) expects
the 'b' partition to be available as the swap and dump device.
Indeed - I'd noted this and refer to it above. I suspect I'll put in a
reasonable b: partition when I reinstall ;-)
Thank you for all your comments, much appreciated - two minds etc. etc.
Cheers
Mike
