Re: 2.6.0 "Losing too many ticks!"

Re: 2.6.0 "Losing too many ticks!"

[Albert Cahalan]

William Lee Irwin III writes:
> On Wed, Dec 24, 2003 at 07:49:06PM +0100, Giacomo Di Ciocco wrote:

>> today i found a problem when upgrading the kernel of this box from
>> 2.2.20 to 2.6.0, i tried to enable/disable ACPI support in the bios
>> and in the kernel but nothing was resolved. [...]
>> Dec 24 16:36:31 xmas kernel: Losing too many ticks!
>> Dec 24 16:36:31 xmas kernel: TSC cannot be used as a timesource. (Are you
>> running with SpeedStep?)
>> Dec 24 16:36:31 xmas kernel: Falling back to a sane timesource.
>> Contact me for more informations. (or tell me to post it here)
>
> This is not particularly harmful. It just means the kernel
> has detected some variation in the processor's clock speed
> and is using a time source that doesn't change speed along
> with the processor's clock speed.

I sure wouldn't bet on that. More likely, he's simply
losing ticks. He has a Duron processor, which is
highly unlikely to be hooked up to some crummy
speed-changing hardware.

I had a 1 GHz Pentium III box with the same problem.
Linux would give up on the perfectly-correct 1 GHz
clock source in favor of trying, and failing, to
count 1 kHz ticks from the crummy old PIT hardware.
Time loss got so bad that NTP would simply give up.
IDE activity may have had something to do with it.

In his case, maybe ACPI polls something while
interrupts are off.

Re: 2.6.0 "Losing too many ticks!"

[Giacomo Di Ciocco]

Albert Cahalan wrote:

> I sure wouldn't bet on that. More likely, he's simply
> losing ticks. He has a Duron processor, which is
> highly unlikely to be hooked up to some crummy
> speed-changing hardware.
> 
> I had a 1 GHz Pentium III box with the same problem.
> Linux would give up on the perfectly-correct 1 GHz
> clock source in favor of trying, and failing, to
> count 1 kHz ticks from the crummy old PIT hardware.
> Time loss got so bad that NTP would simply give up.
> IDE activity may have had something to do with it.
> 
> In his case, maybe ACPI polls something while
> interrupts are off.
> 
> 

This morning i tried Andrew Morton's kernel which implements the via-tsc-fix 
(ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.0/2.6.0-mm1/broken-out/via-tsc-fix.patch)
the messages are still here (Unknown HZ value! (77) Assume 100.) but after doing 
some comparison with my home workstation which has almost the same hardware the 
speed seems to be returned on the standards.


Regards.

-- 
Giacomo Di Ciocco
Nectarine Administrator
Phone/Fax: (+39) 577663107
Web: http://www.nectarine.info
Irc: irc.nectarine.info #nectarine
Email: admin@nectarine.info (pgp.mit.edu)

Re: 2.6.0 "Losing too many ticks!"

[Giacomo Di Ciocco]

Joe Korty wrote:

 > Or maybe IDE DMA is disabled. That would account for lost
 > ticks during period of heavy disk IO.  Giacomo, type
 >
 >   hdparm /dev/hda
 >
 > If it shows 'using DMA' off, try
 >
 >   hdparm -d1 /dev/hda
 >
 > If that fails then the IDE driver you need is not
 > configured in your kernel.
 >
 > Joe

Hi Joe,
enabling the dma mode has resolved the "Losing too many ticks" thing, now the
system seems running fine, the unique strange thing is the "Unknown HZ value!
(92) Assume 100." message, that appears before the output of any program launched.

Thanks everyone for the support.

Regards.

-- 
Giacomo Di Ciocco
Nectarine Administrator
Phone/Fax: (+39) 577663107
Web: http://www.nectarine.info
Irc: irc.nectarine.info #nectarine
Email: admin@nectarine.info (pgp.mit.edu)

Re: 2.6.0 "Losing too many ticks!"

[Albert Cahalan]

On Thu, 2003-12-25 at 13:14, Giacomo Di Ciocco wrote:
> Joe Korty wrote:
> 
>  > Or maybe IDE DMA is disabled. That would account for lost
>  > ticks during period of heavy disk IO.  Giacomo, type
>  >
>  >   hdparm /dev/hda
>  >
>  > If it shows 'using DMA' off, try
>  >
>  >   hdparm -d1 /dev/hda
>  >
>  > If that fails then the IDE driver you need is not
>  > configured in your kernel.
>  >
>  > Joe
> 
> Hi Joe,
> enabling the dma mode has resolved the "Losing too many ticks" thing, now the
> system seems running fine,

OK. So DMA must be on when HZ is 1000. Let's have
the kernel refuse to load the IDE driver w/o DMA
if HZ is over 100. Ha, ha, only serious... :-(

>  the unique strange thing is the "Unknown HZ value!
> (92) Assume 100." message, that appears before the output of any program launched.

Your clock is screwed. Reboot, or upgrade procps
to a version that can compensate. Version 3.1.15
from http://procps.sf.net/ is best.

Here's the release notes:

------------------------------------------------
[ANNOUNCE] procps 3.1.15

This release supports the NSA's high-security SELinux
on the 2.6.0 kernel, without any additional libraries
required. Thread support no longer sets off chkrootkit
on buggy 2.4.xx kernels. (the PID 0 problem) Now "top"
works on terminals with auto-margin problems.

For those of you still upgrading from procps 2.0.xx releases,
you can expect:

* ps fully supports thread display (H, -L, m, -m, and -T)
* ps can display NSA SELinux security contexts
* top can show CPU usage for IO-wait, IRQ, and softirq
* can set $PS_FORMAT to choose your own default ps format
* better width control ("ps -o pid,wchan:42,args")
* width of ps PID column adjusts to your system
* vmstat lets you choose units you like: 1000, 1024, 1000000...
* top can sort by any column (old sort keys available too)
* top can select a single user to display
* top can be put in multi-window mode and/or color mode
* vmstat has the -s option, as found on UNIX and BSD systems
* vmstat has the -f option, as found on UNIX and BSD systems
* watch doesn't eat the first blank line by mistake
* vmstat uses a fast O(1) algorithm on 2.5.xx kernels
* pmap command is SunOS-compatible
* vmstat shows IO-wait time
* pgrep and pkill can find the oldest matching process
* sysctl handles the Linux 2.5.xx VLAN interfaces
* ps has a new "-F" format (very nice, like DYNIX/ptx has)
* ps with proper BSD process selection
* better handling of very long uptimes

There's a procps-feedback@lists.sf.net mailing list you can
use for feature requests, bug reports, and so on. Use it!
Feedback makes things happen.

http://procps.sf.net/
http://procps.sf.net/procps-3.1.15.tar.gz

------------- recent changes -------------

procps-3.1.14 --> procps-3.1.15

hide kernel PID bug (Linux 2.4.13-pre1 to 2.4.MAX)   #217278 #219730 #217525 #224470
ps: faster threaded display
top: auto-margin problem                           #217559
ps: support NSA SELinux, all builds, Linux 2.6+    #193648
sysctl: tweak man page for ESR's broken parser

procps-3.1.13 --> procps-3.1.14

top: displays on more genuine serial terminals
handle 32-bit dev_t of Linux 2.6
ps: finally, m and -m satisfy the original design
ps: distinct per-thread and whole-process pending signals

procps-3.1.12 --> procps-3.1.13

ps: can display NPTL threads w/ kernel patch
no seLinux for now (new kernel interface)   

procps-3.1.11 --> procps-3.1.12

ps: explicit width ("ps -o pid,wchan:42,args")
ps: $PS_FORMAT works properly                    #201575
top: new Linux 2.6.0-test4 CPU stats shown
top: multiple -p options work again
top: fixed 4 GB wrap-around
ps: has a set of tests to ensure correctness
man page: /var/run/utmp, not /etc/utmp           #206583
required flags moved out of CFLAGS               #205429
RPM generation handles /lib64
WCHAN skips leading '.'
vmstat: numerous new features

procps-3.1.10 --> procps-3.1.11

compile with gcc 2.95 again (C99 issue)

procps-3.1.9 --> procps-3.1.10

handle GPLONLY_ symbols                       #143549 #188374
kill: better man page
skill: better man page
ps: PID-like columns change width as needed
top: COMMAND instead of Command
vmstat: -m displays slabinfo
vmstat: -d displays disk stats

------------------------------------------------------------

Re: 2.6.0 "Losing too many ticks"

[Giacomo Di Ciocco]

Hi all,
sorry but i figured just now that i dont have specified the most important 
detail, the system goes _really_ _really_ slow, and when starting programs from 
console it says "Unknown HZ (68) assuming 100", where 68 may vary from 60 to 80.

Regards


-- 
Giacomo Di Ciocco
Nectarine Administrator
Phone/Fax: 0577663107
Web: http://www.nectarine.info
Irc: irc.nectarine.info #nectarine
Email: admin@nectarine.info (pgp.mit.edu)

2.6.0 "Losing too many ticks!"

[Giacomo Di Ciocco]

Hi all,
today i found a problem when upgrading the kernel of this box from 2.2.20 to
2.6.0, i tried to enable/disable ACPI support in the bios and in the kernel but
nothing was resolved.

processor       : 0
vendor_id       : AuthenticAMD
cpu family      : 6
model           : 3
model name      : AMD Duron(tm) Processor
stepping        : 1
cpu MHz         : 797.317
cache size      : 64 KB

00:00.0 Host bridge: VIA Technologies, Inc. VT8363/8365 [KT133/KM133] (rev 02)
00:01.0 PCI bridge: VIA Technologies, Inc. VT8363/8365 [KT133/KM133 AGP]
00:07.0 ISA bridge: VIA Technologies, Inc. VT82C686 [Apollo Super South] (rev 40)
00:07.1 IDE interface: VIA Technologies, Inc. Bus Master IDE (rev 06)
00:07.2 USB Controller: VIA Technologies, Inc. UHCI USB (rev 16)
00:07.3 USB Controller: VIA Technologies, Inc. UHCI USB (rev 16)
00:07.4 Host bridge: VIA Technologies, Inc. VT82C686 [Apollo Super ACPI] (rev 40)
00:07.5 Multimedia audio controller: VIA Technologies, Inc. AC97 Audio
Controller (rev 50)
00:0a.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL-8139 (rev 10)
01:00.0 VGA compatible controller: ATI Technologies Inc Radeon VE QY



Dec 24 16:36:31 xmas kernel: Losing too many ticks!
Dec 24 16:36:31 xmas kernel: TSC cannot be used as a timesource. (Are you
running with SpeedStep?)
Dec 24 16:36:31 xmas kernel: Falling back to a sane timesource.


Contact me for more informations. (or tell me to post it here)

Regards.

-- 
Giacomo Di Ciocco
Nectarine Administrator
Phone/Fax: 0577663107
Web: http://www.nectarine.info
Irc: irc.nectarine.info #nectarine
Email: admin@nectarine.info (pgp.mit.edu)

Re: 2.6.0 "Losing too many ticks!"

[William Lee Irwin III]

On Wed, Dec 24, 2003 at 07:49:06PM +0100, Giacomo Di Ciocco wrote:
> today i found a problem when upgrading the kernel of this box from
> 2.2.20 to 2.6.0, i tried to enable/disable ACPI support in the bios
> and in the kernel but nothing was resolved.
[...]
> Dec 24 16:36:31 xmas kernel: Losing too many ticks!
> Dec 24 16:36:31 xmas kernel: TSC cannot be used as a timesource. (Are you
> running with SpeedStep?)
> Dec 24 16:36:31 xmas kernel: Falling back to a sane timesource.
> Contact me for more informations. (or tell me to post it here)

This is not particularly harmful. It just means the kernel has detected
some variation in the processor's clock speed and is using a time source
that doesn't change speed along with the processor's clock speed.


-- wli

Re: 2.6.0 "Losing too many ticks!"

[Michael Heyse]

William Lee Irwin III wrote:

> This is not particularly harmful. It just means the kernel has detected
> some variation in the processor's clock speed and is using a time source
> that doesn't change speed along with the processor's clock speed.

I had the same problem with an AMD K6-2 on VIA Aladdin V chipset, and it 
WAS harmful, time source not sane at all, because the clock went at 
about half speed.

What worked for me: using Andrew Morton's kernel, it includes a 
via-tsc-fix.patch, now everything's all right.

Greetings,

Michael