[Soekris] sc1100 TSC bug and scx200_hrt

[Jim Cromie]

hi Alexander, David, Ted,

thanks for your help.
The fix is in to 18-mmX (probably temporarily, til its added to 19-rc1),
and has been forwarded to -stable for consideration/inclusion into 18.1

heres a brief explanation of things ( in case it helps you isolate any 
more bugs ;-)


GTS - Generic Timekeeping System - tests the TSC against jiffies (for 
10ms I think)
and thus detects some bad TSCs, including the one on the sc-1100.  IIUC, 
this chip turns
off the tsc when cpu executes 'halt', which happens a lot, esp on an 
unbusy system.
idle=poll keeps scheduler from using 'halt', which 'fixes' the TSC 
(mostly?), but makes the
cpu run hot. 

If you see this:
 TSC appears to be running slowly. Marking it as unstable
then GTS is operating correctly.

If you dont see it on your sc-1100 running linux-2.6.19-rcX, please 
report it to me.
it may be necessary to lengthen the sanity test to make it suitably 
stringent.

GTS rates each clocksource by quality (a single number quantifying time 
resolution, accuracy,
drift, cost of reading, etc - heuristically).  It will choose the best 
available source.
If the TSC is detected as bad, GTS de-rates it, and falls back to the 
next best clock, which
used to be the PIT, but is now the scx200_hrt (if youve built it).

The TSC is the only clock that is sanity-checked, as TSCs are the only 
clocksources that are so flaky
across a wide range of cpus.


clock=tsc on the bootline will force the selection of the named clock, 
which can be queried from:

/sys/devices/system/clocksource/clocksource0/current_clocksource

or set too, via:  echo tsc > (above)

Once modprobed, clocksources cannot be removed, only un-selected (by 
selecting another).
This is why scx200_hrt appears in lsmod as:
scx200_hrt              2872  0 [permanent]


I dont at present have any current NTP numbers to share here, though 
David posted these, which I re-send.
If you get better numbers with scx200_hrt, please post, along with uptime.
Also, send same for pit, tsc.  I suspect tsc's slowness might be evident 
in the last 4 numbers below.

% ntpq -pcrv
     remote           refid      st t when poll reach   delay   offset  jitter
==============================================================================
*portico.dedekin 198.6.255.249    2 u   64  128  377    1.369   -4.837   0.778
 LOCAL(0)        LOCAL(0)        13 l   25   64  377    0.000    0.000   0.004
assID=0 status=0664 leap_none, sync_ntp, 6 events, event_peer/strat_chg,
version="ntpd 4.2.0a at 1:4.2.0a+stable-2-r Fri Aug 26 10:30:12 UTC 2005 (1)"?,
processor="i586", system="Linux/2.6.18-soekris-2", leap=00, stratum=3,
precision=-18, rootdelay=36.754, rootdispersion=50.836, peer=18212,
refid=192.168.0.10,
reftime=c8c996f0.f10b8498  Sat, Sep 30 2006 21:22:56.941, poll=7,
clock=0xc8c99832.37ecfe9b, state=4, offset=-4.837, frequency=-25.335,
noise=0.864, jitter=0.778, stability=42.192
---------------------


I hope this is useful
jimc