TSC cannot be used as a timesource -> SOLVED

• Previous message: Lawrence MacIntyre: "Re: Any changes in Multicast code between 2.4.20 and 2.4.22/23 ?"
• Next in thread: Tim Schmielau: "Re: TSC cannot be used as a timesource -> SOLVED"
• Reply: Tim Schmielau: "Re: TSC cannot be used as a timesource -> SOLVED"
• Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]

Date:	Tue, 6 Jan 2004 15:00:44 +0100
To: linux-kernel@vger.kernel.org

Good morning,

First part of this message is somewhat of a FYI, second an issue that
troubles me, and which I don't know if it may be related to the first.

First
-----
Until today I had my Linux system running on an old 1.7Gb /dev/hda and a
newer 20Gb /dev/hdb. Because the 1.7Gb was extremely unreliable with
DMA (established a long time ago), I always had it off for that disk;
the 20Gb disk had DMA on (udma4).

Kernel in recent months has always been the current 2.6.0-testNN and
since its release, kernel 2.6.0

With the 2.6 kernels (and possibly with late 2.5 versions too?) I would
always get the mystifying:

  Losing too many ticks!
  TSC cannot be used as a timesource. (Are you running with SpeedStep?)
  Falling back to a sane timesource.

during the boot-up, right at the point it seems where a standard e2fsck
is run.

Today I installed a new 80Gb harddisk, making the 20Gb /dev/hda and
the 80Gb /dev/hdb, and junking the 1.7Gb. Both have DMA enabled (udma5).

It seems the TSC problem has vanished, no more such messages -- knock on
wood.

FYI, I have an ASUS P4PE motherboard with Intel 2.4GHz, here's lspci
and /proc/cpu:

00:00.0 Host bridge: Intel Corp. 82845G/GL [Brookdale-G] Chipset Host Bridge (rev 02)
00:01.0 PCI bridge: Intel Corp. 82845G/GL [Brookdale-G] Chipset AGP Bridge (rev 02)
00:1d.0 USB Controller: Intel Corp. 82801DB USB (Hub #1) (rev 02)
00:1d.1 USB Controller: Intel Corp. 82801DB USB (Hub #2) (rev 02)
00:1d.2 USB Controller: Intel Corp. 82801DB USB (Hub #3) (rev 02)
00:1d.7 USB Controller: Intel Corp. 82801DB USB2 (rev 02)
00:1e.0 PCI bridge: Intel Corp. 82801BA/CA/DB/EB PCI Bridge (rev 82)
00:1f.0 ISA bridge: Intel Corp. 82801DB LPC Interface Controller (rev 02)
00:1f.1 IDE interface: Intel Corp. 82801DB Ultra ATA Storage Controller (rev 02)
00:1f.3 SMBus: Intel Corp. 82801DB/DBM SMBus Controller (rev 02)
00:1f.5 Multimedia audio controller: Intel Corp. 82801DB AC'97 Audio Controller (rev 02)
01:00.0 VGA compatible controller: nVidia Corporation NV18 [GeForce4 MX 440SE AGP 8x] (rev a2)
02:0b.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL-8029(AS)
02:0c.0 Multimedia audio controller: C-Media Electronics Inc CM8738 (rev 10)
02:0d.0 Multimedia video controller: Brooktree Corporation Bt878 Video Capture (rev 11)
02:0d.1 Multimedia controller: Brooktree Corporation Bt878 Audio Capture (rev 11)

processor : 0
vendor_id : GenuineIntel
cpu family : 15
model : 2
model name : Intel(R) Pentium(R) 4 CPU 2.40GHz
stepping : 7
cpu MHz : 2406.215
cache size : 512 KB
physical id : 0
siblings : 1
fdiv_bug : no
hlt_bug : no
f00f_bug : no
coma_bug : no
fpu : yes
fpu_exception : yes
cpuid level : 2
wp : yes
flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe cid
bogomips : 4751.36

Anyone who wants more info, let me know and I'll be glad to provide.

Second
------
In order to use my new 80Gb harddisk, I first installed it alongside
the two 'old' disks, as /dev/hdc, so as to be able to move ca. 16Gb of
data from the 20Gb to the 80Gb. So I temporarily had:
hda: 1.7Gb / no dma
hdb: 20Gb / udma4
hdc: 80Gb / udma5

Now here's what happened: during the one foul swoop 'cp -axvp *' from
the 20Gb HD to the 80Gb HD, at two times the copying process seemed
to 'hang' for ca. 10-15 minutes (at least there were two times I noticed),
the copy being in a 'D' state (uninterruptable sleep).

By the time the cp was finally finished (could be ~1.5 hr later wall clock
time!), the system clock was running behind ca. 45 minutes!

The same odd behaviour was noticed some time later when I copied a small
2Gb from the 20Gb HD to the 80Gb HD. During that copy, the system clock
ran behind ca. 10 minutes.

I had no other major apps running at the time, other than a TV program
running in an xawtv window through my Pinnacle PCTV Pro TV-card, which
doesn't affect system load much (might as well enjoy the time, I thought).
Nothing else.

What I /did/ have was a redirect of stdout/stderr of the 'cp' process on
both occasions (quite verbose), to a file on the 1.7Gb HD, which rose to
about 36Mb for the first copy.
So all three HD's were accessed continuously during both copies.

After bootup, the system time was in sync with wall-clock time again.

I was and am running Linux-2.6.0.

So, is this a problem with this kernel version? May it be caused by the
differing DMA for ide0 (no dma for the old 1.7Gb HD and udma5 for the
20Gb HD)? Or be related to the now seemingly gone TSC pain-in-the-a**?
Anything else?

I have my 20Gb and 80Gb up and running now --and smoothly at that, it
seems--, the 1.7Gb is out, and I'll keep an eye on this problem (will
do some tests tomorrow), but meanwhile I'd thought I'd just throw it
in there.

Thanks for your time.

BJ

-- 
 typos hapen
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

• Previous message: Lawrence MacIntyre: "Re: Any changes in Multicast code between 2.4.20 and 2.4.22/23 ?"
• Next in thread: Tim Schmielau: "Re: TSC cannot be used as a timesource -> SOLVED"
• Reply: Tim Schmielau: "Re: TSC cannot be used as a timesource -> SOLVED"
• Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]