> That fixed it. Thanks, Blaz!
>
> So now I have to wonder why this fixed the problem? Is this a sign of
> some other problem, or is it just something that is an issue with
> non-Intel i386 hardware?
I believe the apm code switches the whole system to use some other clock
source. In my case, it was an old AMD K5 box, on which the clock was running
*extermely slow* (like one second every minute). It was originally running
Linux and it exhibited the same problem under Linux. We thought it was purely
broken hardware or a broken BIOS, I tried upgrading to the latest BIOS - still
no go.
Later I tried to install FreeBSD on it nevertheless and it worked - but as
soon as I installed a custom kernel it failed. Well, now with "device apm" the
machine is happily humming along and you wouldn't be reading this message if
it wasn't working (the box is now our company firewall, running FreeBSD
4.1.1).
Back to your question, somebody more familiar with the apm code might give you
the answer. Or somebody more familiar with the system clocks on FreeBSD, maybe
[EMAIL PROTECTED]? I'm not sure if he's reading this list, though.
Blaz Zupan, Medinet d.o.o, Linhartova 21, 2000 Maribor, Slovenia
E-mail: [EMAIL PROTECTED], Tel: +386-2-320-6320, Fax: +386-2-320-6325
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-stable" in the body of the message