HEADS UP: timecounters (branch simonb-timecounters) merged into -current

The FreeBSD implementation of Poul-Henning Kamp's
timecounters
was ported and committed to NetBSD-current.

Timecounters will be supported on a per port basis. With
the commit following ports make use of timecounters:
    i386
    amd64
    sparc
    sparc64

Other ports will follow over the time. Hopefully all ports
of NetBSD will be converted to timecounters soon.

Benefits:
    - true nanosecond support
      within the limits of the hardware
    - easier interfacing to hardwarecounters as
      all scaling integration is done at MI level
    - new NTP API (Version 4) - aka Nanokernel
    - simplified internal interface for PPSAPI
    - MP support (minimal coordination needed)

Please test NetBSD-current so we can smoke out bugs early.

Further information:
    Timecounter Paper: http://phk
.freebsd.dk/pubs/timecounter.pdf
    Current Status: http:
//www.kardel.name/timecounters-status.html
    NTP Nanokernel: h
ttp://www.eecis.udel.edu/~mills/ntp/html/kern.html

best regards,
  Frank Kardel & Simon Burge

In article <44875CE2.8090801netbsd.org>,
	Frank Kardel <kardelNetBSD.org> writes:
> Timecounters will be supported on a per port basis.
With
> the commit following ports make use of timecounters:
>     i386
>     amd64
>     sparc
>     sparc64

That will fix the time keeping problems on MP machine?

	Kind regards

-- 
Matthias Scheler                                  http://scheler.de/~matth
ias/

On Thursday 2006-06-08 11:09 +1000, Frank Kardel output:
:Please test NetBSD-current so we can smoke out bugs early.

Seems to have broken wscons/vt support (and X).

With 4 wscons displays, I can't change either via
CTRL+ALT+F{1,2,3,4}
or via  wsconscfg -s {1,2,3,4} .  Also X won't start for me
on screen 5.

Backdating source to '2006-06-07 22:00 UTC' works again.

Is this affecting anyone else?

The patch from simonb in 2005 worked fine.  Also, the branch
worked
OK for me when you asked for people to check it, IIRC, a
couple of
months back.

Regards,
Geoff

On Thu, Jun 08, 2006 at 01:10:26AM +0200, Frank Kardel
wrote:
> Please test NetBSD-current so we can smoke out bugs
early.
> 
I just compiled a test kernel (DIAGNOSTIC & DEBUG
enabled), and it never
finish the boot sequence (or sleeps for really long time),
it stopped
after ukphy0 attachment, however, if I unplug/plug a pccard,
it
detach/attach correctly: 

 cardslot0 at cbb0 slot 0 flags 0
 cardbus0 at cardslot0: bus 2
 pcmcia0 at cardslot0
 timecounter: Timecounter "TSC" frequency
697500160 Hz quality 800
 timecounter: Timecounters tick every 10.000 msec
 timecounter: Timecounter "clockinterrupt"
frequency 100 Hz quality 0
 timecounter: selected timecounter "TSC"
frequency 697500160 Hz quality 800
 fdcintr: got probe interrupt
 fdcintr: got probe interrupt
 fd0 at fdc0 drive 0: 1.44MB, 80 cyl, 2 head, 18 sec
 fdcintr: got probe interrupt
 raidattach: Asked for 8 units
 Kernelized RAIDframe activated
 cardbus_mapreg_map called: cardbus0 0
 cardbus_mapreg_map: physaddr 40000000
 cardbus0: unmap mem space
 tlp0 at cardbus0 function 0: ADMtek AN985 Ethernet, pass
1.1
 cardbus_mapreg_map called: cardbus0 0
 cardbus_mapreg_map: physaddr 40000000
 tlp0: Ethernet address 00:0f:b5:41:34:9c
 ukphy0 at tlp0 phy 1: Generic IEEE 802.3u media interface
 ukphy0: OUI 0x00e092, model 0x0001, rev. 1
 ukphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX,
auto
[... hangs here ...]

If I lower REALEXTMEM (to get a core), it hangs after wd0
attachment.

I can try to get a core if you need it.

regards,

Arnaud

ps: on a pre-merge kernel, it hangs about 3 ou 4 seconds
after the
attach of wd0 and cd0.

On Thu, Jun 08, 2006 at 05:24:37PM +1000, Geoff Wing wrote:
> On Thursday 2006-06-08 11:09 +1000, Frank Kardel
output:
> :Please test NetBSD-current so we can smoke out bugs
early.
> 
> Seems to have broken wscons/vt support (and X).
> 
> With 4 wscons displays, I can't change either via
CTRL+ALT+F{1,2,3,4}
> or via  wsconscfg -s {1,2,3,4} .  Also X won't start
for me on screen 5.
> 
> Backdating source to '2006-06-07 22:00 UTC' works
again.
> 
> Is this affecting anyone else?

Yes, I'm seeing exactly the same (on i386) with sources
from right after
the merge.  My previous build (a few days older) worked
fine.  

	Geert

On Thursday 2006-06-08 17:25 +1000, Geoff Wing output:
:Seems to have broken wscons/vt support (and X).
:With 4 wscons displays, I can't change either via
CTRL+ALT+F{1,2,3,4}
:or via  wsconscfg -s {1,2,3,4} .  Also X won't start for
me on screen 5.

Fixed with Matthias Drochner's revert of hardclock_ticks to
signed int.

Regards,
Geoff

On Fri, Jun 09, 2006 at 12:16:48PM +1000, Geoff Wing wrote:
> Fixed with Matthias Drochner's revert of
hardclock_ticks to signed int.

Yes, indeed.

A big caveat though: if you use the broken (can't switch
consoles) kernel
with a softdep mounted filesystem ("soft
dependencies" in the mount output),
you should sync and carefully reboot *ASAP* with a fixed
kernel - softdeps
do not work in those kernels either.

Martin

Hello,

At Thu, 08 Jun 2006 01:10:26 +0200,
Frank Kardel wrote:
> Please test NetBSD-current so we can smoke out bugs
early.

I'm using ThinkPad X32 that CPU is Intel Pentium M 745
1.8GHz.  With
the fastest CPU clock, timecounter works fine.  But it's
broken by
the slower CPU clocks.

1.8GHz:

% sysctl -w machdep.est.frequency.target=1800
machdep.est.frequency.target: 1000 -> 1800
% /usr/bin/time sleep 10
       10.00 real         0.00 user         0.00 sys

600MHz:

% sysctl -w machdep.est.frequency.target=600
machdep.est.frequency.target: 1800 -> 600
% /usr/bin/time sleep 10
        3.33 real         0.00 user         0.00 sys

With 600MHz, the command actually takes 10 seconds in real
time, but
the output of time(1) is 1/3.

best regards.
-- 
 Kouichirou Hiratsuka
   hirapo6.nsk.ne.jp

At Thu, 08 Jun 2006 01:10:26 +0200,
Frank Kardel <kardelnetbsd.org> wrote:
> 
> Please test NetBSD-current so we can smoke out bugs
early.

On my laptop PC, the TSC counter counts only 6 seconds
in 10 real-seconds.
I think this is related to Enhanced SpeedStep, as
the PC is running with machdep.est.frequency.current = 600,
while machdep.est.frequency.current = 1000 at the boot time.

When I use another counter, the clock doesn't lose time.
# e.g., sysctl -w kern.timecounter.hardware=i8254



NetBSD 3.99.21 (MITANA) #109: Fri Jun  9 11:24:46 JST 2006
	kenmitana.nanohz.org:/usr/src/sys/arch/i386/compile/MITA
NA
total memory = 1270 MB
avail memory = 1241 MB
timecounter: Timecounter "i8254" frequency
1193182 Hz quality 100
...
cpu0 at mainbus0: (uniprocessor)
cpu0: Intel Pentium M (Banias) (686-class), 996.82 MHz, id
0x695
cpu0: features
a7e9fbbf<FPU,VME,DE,PSE,TSC,MSR,MCE,CX8,APIC,SEP,MTRR>
cpu0: features
a7e9fbbf<PGE,MCA,CMOV,PAT,CFLUSH,DS,ACPI,MMX>
cpu0: features a7e9fbbf<FXSR,SSE,SSE2,TM,SBF>
cpu0: features2 180<EST,TM2>
cpu0: "Intel(R) Pentium(R) M processor 1000MHz"
cpu0: I-cache 32 KB 64B/line 8-way, D-cache 32 KB 64B/line
8-way
cpu0: using thermal monitor 2
cpu0: Enhanced SpeedStep (1004 mV) 1000 MHz
cpu0: Enhanced SpeedStep frequencies available (MHz): 1000
900 800 600
...
apm0 at mainbus0: Advanced Power Management BIOS
apm0: Power Management spec V1.2
timecounter: Timecounter "TSC" frequency
996791680 Hz quality 800
timecounter: Timecounters tick every 10.000 msec
timecounter: Timecounter "clockinterrupt"
frequency 100 Hz quality 0
timecounter: selected timecounter "TSC"
frequency 996791680 Hz quality 800


regards,
-- 
KAMADA Ken'ichi <kamadananohz.org>

Hi there,

there is also a strange thing with auich since I compiled
the kernel 
featuring timecounters. Look at the auich0 rate on this
excerpt from dmesg:


timecounter: Timecounter "TSC" frequency
1196183000 Hz quality 800
WARNING: Callback scheduled before sysmon task queue thread
present.
timecounter: Timecounters tick every 10.000 msec
timecounter: Timecounter "clockinterrupt"
frequency 100 Hz quality 0
timecounter: selected timecounter "TSC"
frequency 1196183000 Hz quality 800
auich0: measured ac97 link rate at 8378 Hz, will use 48000
Hz


Normally, it should be around 47 to 48 kHz, as it was
before.

The frequency of the TSC counter is correct, though.
Vincent