clock too slow - big time offset with ntpdate

[Ian Smith]

On Thu, 3 May 2007, Martin Dieringer wrote:
 > On Thu, 3 May 2007, Ian Smith wrote:
 > >
 > > > > Now I got following while playing sound on the Compaq:
 > > > >
 > > > > kernel: calcru: runtime went backwards from 183711700 usec to 183167434 usec for pid 12 (swi4: clock sio)
 > > > >
 > > > > here I have a working clock, but also intermittent sound output
 > >
 > > To which I suggested, after a bit of hunting:
 > >
 > > > http://www.freebsd.org/doc/en/books/faq/book.html#CALCRU-NEGATIVE
 > 
 > this refers to freebsd 4?

You've just reasserted this, I read in the latest round :)

No, the FAQ refers to versions 4, 5 and 6.  The only reference there to
freebsd 4 is regarding using the -w switch with sysctl (ie, irrelevant).

Most of the messages returned by the search I suggested are recent (6.X)

 > > > and
 > > > http://lists.freebsd.org/pipermail/freebsd-stable/ searching for
 > > > 'calcru: runtime went backwards' provides many hits, as does google;
 > > > seems it could be a number of things, perhaps choice of timecounter.
 > 
 > didn't help me
 > 
 > It was always kern.timecounter.hardware: i8254

Ok, then it's quite possibly powerd trying to use APM rather than ACPI.

 > > Also a bit further down in the FAQ:
 > > '5.25. Why does the clock on my laptop keep incorrect time?'
 > >
 > > Have you had a look at those FAQ entries?  Might they be relevant?
 > >
 > > How about showing us /var/run/dmesg.boot for at least one of these two
 > > machines?  I'm still curious as to what Timecounter & HZ is selected:
 > > show us 'sysctl kern.timecounter' and 'sysctl -a | grep -i cpu' ?
 > 
 > # sysctl kern.timecounter
[..]
 > kern.timecounter.hardware: i8254
 > kern.timecounter.choice: TSC(-1000) i8254(0) dummy(-1000000)
 > kern.timecounter.tick: 1
 > 
 > # sysctl -a | grep -i cpu
 > kern.threads.virtual_cpu: 1
 > kern.ccpu: 1948
 > kern.smp.maxcpus: 1
 > kern.smp.cpus: 1
 > debug.cpufreq.lowest: 0
 > debug.cpufreq.verbose: 0
 > hw.ncpu: 1
 > machdep.cpu_idle_hlt: 1
 > dev.cpu.0.%driver: cpu
 > dev.cpu.0.%parent: legacy0
 > dev.cpu.0.freq: 1400
 > dev.cpu.0.freq_levels: 1400/-1 1225/-1 1200/-1 1050/-1 1000/-1 875/-1
 > 800/-1 700/-1 600/-1 525/-1 450/-1 375/-1 300/-1 225/-1 150/-1 75/-1
 > dev.est.0.%parent: cpu0
 > dev.cpufreq.0.%driver: cpufreq
 > dev.cpufreq.0.%parent: cpu0
 > dev.p4tcc.0.%desc: CPU Frequency Thermal Control
 > dev.p4tcc.0.%parent: cpu0

>From your dmesg:

  est0: <Enhanced SpeedStep Frequency Control> on cpu0
  p4tcc0: <CPU Frequency Thermal Control> on cpu0
  apm0: <APM BIOS> on motherboard
  apm0: found APM BIOS v1.2, connected at v1.2

You say you can't use ACPI, as suspend/resume and pccards? don't work. 
Searching the acpi list for 't42p' produces messages suggesting the
former has been made to work; I didn't notice any mention of the latter
either way, however I did notice these in your dmesg: 

  module_register: module isa/cbb already exists!
  Module isa/cbb failed to register: 17
  module_register: module pci/cbb already exists!
  Module pci/cbb failed to register: 17


Bottom line might be: if it hurts when you run powerd with APM, don't.

I may be wrong, but suspect the chances of anybody working on any nits
in est or p4tcc with APM may be minimal, whereas ACPI is being regularly
maintained and enhanced.  If you want powerd to work, I'd suggest trying
ACPI again and reporting any problems to the acpi list (assuming you've
first updated your BIOS and EC to latest versions from IBM, or Compaq
for your other equally? problematic powerd-on-APM laptop).

 > dmesg.today is attached

This line is odd, usually only appearing when APM isn't loaded (or not
working right?) but may depend on what's in loader.conf or in kernel: 

 > WARNING: apm_saver module requires apm enabled

Does kldstat show apm_saver.ko ok?

Cheers, Ian