On 1/2/2015 2:00 PM, Nathan Wheeler wrote:
Try changing the value for the sysctl variable
"kern.timecounter.hardware"? Its just a guess, but its helped me when
I had problems with the clock before.
On Fri, Jan 2, 2015 at 7:47 AM, John Merriam <j...@johnmerriam.net> wrote:
Hello. I have a strange issue with OpenBSD on my Dell OptiPlex 320. The
clock doesn't move:
# date; sleep 55; date
Thu Jan 1 02:25:47 EST 2015
Thu Jan 1 02:25:47 EST 2015
I see the same behavior with 5.6-release amd64 and -current amd64. The
clock works fine in Windows and Linux on this machine. I installed the
December 27th snapshot on it so I can mess around with it and try to get it
fixed. Has anyone seen this before? If not, any tips on what to try or
where I should start looking in the code to try to figure out what's going
on?
Below is the dmesg:
*snip*
Thanks. I probably should have thought to look for a knob like that.
The clock works fine with kern.timecounter.hardware set to either i8254
or acpitimer0 but not when it is set to acpihpet0
The OptiPlex 320 was designed and produced not long after HPET started
showing up in PCs. I would guess the OptiPlex 320 has a buggy HPET.
Since it isn't supported by Dell anymore, I doubt they would be
interested in trying to fix it via a BIOS update if it would even be
possible for them to fix it in the BIOS.
Is it worth messing around with to try to get HPET working on the
OptiPlex 320 in OpenBSD or would it be written off as buggy hardware? I
guess that assumes it could work at all...
Here's another question that I have after reading up on this stuff. Is
it worth using the HPET or ACPI timers in OpenBSD for non desktop
machines? Obviously it depends on one's particular situation but from
my reading it sounds like the most common reason to want better timers
is multimedia which is usually not something to worry about on most servers.
--
John Merriam
