2.6.0-test11, TSC cannot be used as a timesource.

2.6.0-test11, TSC cannot be used as a timesource.

[Markku Savela]

I've seen some references to above problem, but no clear answer. The
'ntpd' is complaining a lot...

I have ASUS P4S800. Here is some extracts from dmesg (I can provide
more complete dump, if anyone wants something specific.)

Linux version 2.6.0-test11 (root@moth) (gcc version 3.3.2 (Debian)) #2 SMP Thu Dec 4 22:32:52 EET 2003
...
Kernel command line: BOOT_IMAGE=Linux-2 ro root=301
Initializing CPU#0
PID hash table entries: 1024 (order 10: 8192 bytes)
Detected 2400.326 MHz processor.
...
CPU: Hyper-Threading is disabled
...
Intel machine check reporting enabled on CPU#0.
CPU#0: Intel P4/Xeon Extended MCE MSRs (12) available
CPU#0: Thermal monitoring enabled
Enabling fast FPU save and restore... done.
Enabling unmasked SIMD FPU exception support... done.
Checking 'hlt' instruction... OK.
POSIX conformance testing by UNIFIX
CPU0: Intel(R) Celeron(R) CPU 2.40GHz stepping 09
per-CPU timeslice cutoff: 365.75 usecs.
task migration cache decay timeout: 1 msecs.
enabled ExtINT on CPU#0
...
Using local APIC timer interrupts.
calibrating APIC timer ...
..... CPU clock speed is 2399.0868 MHz.
..... host bus clock speed is 99.0994 MHz.
Starting migration thread for cpu 0
CPUS done 2
...
PCI: Using ACPI for IRQ routing
PCI: if you experience problems, try using option 'pci=noacpi' or even 'acpi=off'
PCI: Cannot allocate resource region 4 of device 0000:00:02.1
radeonfb_pci_register BEGIN
radeonfb: ref_clk=2700, ref_div=60, xclk=15000 from BIOS
radeonfb: probed DDR SGRAM 32768k videoram
radeon_get_moninfo: bios 4 scratch = 2000002
radeonfb: ATI Radeon VE QY DDR SGRAM 32 MB
radeonfb: DVI port no monitor connected
radeonfb: CRT port CRT monitor connected
radeonfb_pci_register END
...
ACPI: Power Button (FF) [PWRF]
ACPI: Processor [CPU0] (supports C1)
...
Real Time Clock Driver v1.12
Linux agpgart interface v0.100 (c) Dave Jones
agpgart: Detected SiS 648 chipset
agpgart: Maximum main memory to use for agp memory: 203M
agpgart: AGP aperture is 64M @ 0xe8000000
[drm] Initialized radeon 1.9.0 20020828 on minor 0
...
Losing too many ticks!
TSC cannot be used as a timesource. (Are you running with SpeedStep?)
Falling back to a sane timesource.
set_rtc_mmss: can't update from 59 to 0

Re: 2.6.0-test11, TSC cannot be used as a timesource.

[Ed Sweetman]

ok, so we've shown it's not dependent on the number of cpu's you have. 
Not dependent on the amd/intel mobo and cpu you have. Not dependendent 
on if you're using akpm's test10 patch on test11 or not.   So this seems 
to be proving to be a real bug.


Markku Savela wrote:
> I've seen some references to above problem, but no clear answer. The
> 'ntpd' is complaining a lot...
> 
> I have ASUS P4S800. Here is some extracts from dmesg (I can provide
> more complete dump, if anyone wants something specific.)
> 
> Linux version 2.6.0-test11 (root@moth) (gcc version 3.3.2 (Debian)) #2 SMP Thu Dec 4 22:32:52 EET 2003
> ...
> Kernel command line: BOOT_IMAGE=Linux-2 ro root=301
> Initializing CPU#0
> PID hash table entries: 1024 (order 10: 8192 bytes)
> Detected 2400.326 MHz processor.
> ...
> CPU: Hyper-Threading is disabled
> ...
> Intel machine check reporting enabled on CPU#0.
> CPU#0: Intel P4/Xeon Extended MCE MSRs (12) available
> CPU#0: Thermal monitoring enabled
> Enabling fast FPU save and restore... done.
> Enabling unmasked SIMD FPU exception support... done.
> Checking 'hlt' instruction... OK.
> POSIX conformance testing by UNIFIX
> CPU0: Intel(R) Celeron(R) CPU 2.40GHz stepping 09
> per-CPU timeslice cutoff: 365.75 usecs.
> task migration cache decay timeout: 1 msecs.
> enabled ExtINT on CPU#0
> ...
> Using local APIC timer interrupts.
> calibrating APIC timer ...
> ..... CPU clock speed is 2399.0868 MHz.
> ..... host bus clock speed is 99.0994 MHz.
> Starting migration thread for cpu 0
> CPUS done 2
> ...
> PCI: Using ACPI for IRQ routing
> PCI: if you experience problems, try using option 'pci=noacpi' or even 'acpi=off'
> PCI: Cannot allocate resource region 4 of device 0000:00:02.1
> radeonfb_pci_register BEGIN
> radeonfb: ref_clk=2700, ref_div=60, xclk=15000 from BIOS
> radeonfb: probed DDR SGRAM 32768k videoram
> radeon_get_moninfo: bios 4 scratch = 2000002
> radeonfb: ATI Radeon VE QY DDR SGRAM 32 MB
> radeonfb: DVI port no monitor connected
> radeonfb: CRT port CRT monitor connected
> radeonfb_pci_register END
> ...
> ACPI: Power Button (FF) [PWRF]
> ACPI: Processor [CPU0] (supports C1)
> ...
> Real Time Clock Driver v1.12
> Linux agpgart interface v0.100 (c) Dave Jones
> agpgart: Detected SiS 648 chipset
> agpgart: Maximum main memory to use for agp memory: 203M
> agpgart: AGP aperture is 64M @ 0xe8000000
> [drm] Initialized radeon 1.9.0 20020828 on minor 0
> ...
> Losing too many ticks!
> TSC cannot be used as a timesource. (Are you running with SpeedStep?)
> Falling back to a sane timesource.
> set_rtc_mmss: can't update from 59 to 0
> -
> 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/
> 

Re: 2.6.0-test11, TSC cannot be used as a timesource.

[Zwane Mwaikambo]

On Sat, 6 Dec 2003, Markku Savela wrote:

> I've seen some references to above problem, but no clear answer. The
> 'ntpd' is complaining a lot...
>
> I have ASUS P4S800. Here is some extracts from dmesg (I can provide
> more complete dump, if anyone wants something specific.)

Does this only happen when running X11?

Re: 2.6.0-test11, TSC cannot be used as a timesource.

[Markku Savela]

> From: Zwane Mwaikambo <zwane@arm.linux.org.uk>
> On Sat, 6 Dec 2003, Markku Savela wrote:
> 
> > I've seen some references to above problem, but no clear answer. The
> > 'ntpd' is complaining a lot...
> >
> > I have ASUS P4S800. Here is some extracts from dmesg (I can provide
> > more complete dump, if anyone wants something specific.)
> 
> Does this only happen when running X11?

Hmm.. possibly. When I boot single user, it does not appear to happen.

After "init 2" and X and everything running, the notice appears in
about 5-10 minutes. All I have in X is couple of XTerms and doing
occasional "dmesg". I have Gnome2 with Sawfish, and GKrellM running.

Yes, my X is for older kernel

  XFree86 Version 4.3.0
  Release Date: 27 February 2003
  X Protocol Version 11, Revision 0, Release 6.6
  Build Operating System: Linux 2.4.18-24.8.0smp i686 [ELF]

and I had to disable "dri" loading totally. If I enable "dri", and
start X that uses it, the machines crashes totally, no X logs, no
syslog or anything comes out. Total death (I just assumes that
expecting DRI to work was just too much). Maybe I should disable all
acceleration...

Re: 2.6.0-test11, TSC cannot be used as a timesource.

[Zwane Mwaikambo]

On Sat, 6 Dec 2003, Markku Savela wrote:

> > Does this only happen when running X11?
>
> Hmm.. possibly. When I boot single user, it does not appear to happen.
>
> After "init 2" and X and everything running, the notice appears in
> about 5-10 minutes. All I have in X is couple of XTerms and doing
> occasional "dmesg". I have Gnome2 with Sawfish, and GKrellM running.
>
> Yes, my X is for older kernel
>
>   XFree86 Version 4.3.0
>   Release Date: 27 February 2003
>   X Protocol Version 11, Revision 0, Release 6.6
>   Build Operating System: Linux 2.4.18-24.8.0smp i686 [ELF]
>
> and I had to disable "dri" loading totally. If I enable "dri", and
> start X that uses it, the machines crashes totally, no X logs, no
> syslog or anything comes out. Total death (I just assumes that
> expecting DRI to work was just too much). Maybe I should disable all
> acceleration...

Hmm ok i was actually suspecting something DRI related. Can you send an
lspci? and perhaps full dmesg?

Re: 2.6.0-test11, TSC cannot be used as a timesource.

[Dmitry Torokhov]

On Saturday 06 December 2003 03:56 pm, Markku Savela wrote:
> > From: Zwane Mwaikambo <zwane@arm.linux.org.uk>
> >
> > On Sat, 6 Dec 2003, Markku Savela wrote:
> > > I've seen some references to above problem, but no clear answer.
> > > The 'ntpd' is complaining a lot...
> > >
> > > I have ASUS P4S800. Here is some extracts from dmesg (I can provide
> > > more complete dump, if anyone wants something specific.)
> >
> > Does this only happen when running X11?
>
> Hmm.. possibly. When I boot single user, it does not appear to happen.
>

Do you have an ACPI battery stat or thermal monitor apps running (I see
that you have ACPI active). Does it help it you increase the polling 
interval? Too many systems spend too much time in SCI handler...

Dmitry
 

Re: 2.6.0-test11, TSC cannot be used as a timesource.

[Zwane Mwaikambo]

On Sat, 6 Dec 2003, Dmitry Torokhov wrote:

> On Saturday 06 December 2003 03:56 pm, Markku Savela wrote:
> > > From: Zwane Mwaikambo <zwane@arm.linux.org.uk>
> > >
> > > On Sat, 6 Dec 2003, Markku Savela wrote:
> > > > I've seen some references to above problem, but no clear answer.
> > > > The 'ntpd' is complaining a lot...
> > > >
> > > > I have ASUS P4S800. Here is some extracts from dmesg (I can provide
> > > > more complete dump, if anyone wants something specific.)
> > >
> > > Does this only happen when running X11?
> >
> > Hmm.. possibly. When I boot single user, it does not appear to happen.
> >
>
> Do you have an ACPI battery stat or thermal monitor apps running (I see
> that you have ACPI active). Does it help it you increase the polling
> interval? Too many systems spend too much time in SCI handler...

Yes cat /proc/interrupts might also give some sort of rough indication.

Re: 2.6.0-test11, TSC cannot be used as a timesource.

[Markku Savela]

> Yes cat /proc/interrupts might also give some sort of rough indication.

cat /proc/interrupts
           CPU0
  0:    6713992    IO-APIC-edge  timer
  1:       9451    IO-APIC-edge  i8042
  2:          0          XT-PIC  cascade
  8:          4    IO-APIC-edge  rtc
 12:      19373    IO-APIC-edge  i8042
 14:      38987    IO-APIC-edge  ide0
 15:         10    IO-APIC-edge  ide1
 17:      16753   IO-APIC-level  eth0
 18:          0   IO-APIC-level  SiS SI7012
 20:          0   IO-APIC-level  acpi
 23:          0   IO-APIC-level  ehci_hcd
NMI:          0
LOC:    6721795
ERR:          0
MIS:          0
uptime
 00:18:43 up  1:52,  5 users,  load average: 0.00, 0.01, 0.00

Re: 2.6.0-test11, TSC cannot be used as a timesource.

[Ed Sweetman]

Zwane Mwaikambo wrote:
> On Sat, 6 Dec 2003, Dmitry Torokhov wrote:
> 
> 
>>On Saturday 06 December 2003 03:56 pm, Markku Savela wrote:
>>
>>>>From: Zwane Mwaikambo <zwane@arm.linux.org.uk>
>>>>
>>>>On Sat, 6 Dec 2003, Markku Savela wrote:
>>>>
>>>>>I've seen some references to above problem, but no clear answer.
>>>>>The 'ntpd' is complaining a lot...
>>>>>
>>>>>I have ASUS P4S800. Here is some extracts from dmesg (I can provide
>>>>>more complete dump, if anyone wants something specific.)
>>>>
>>>>Does this only happen when running X11?
>>>
>>>Hmm.. possibly. When I boot single user, it does not appear to happen.
>>>
>>
>>Do you have an ACPI battery stat or thermal monitor apps running (I see
>>that you have ACPI active). Does it help it you increase the polling
>>interval? Too many systems spend too much time in SCI handler...
> 
> 
> Yes cat /proc/interrupts might also give some sort of rough indication.


It took over 3 days to trigger it on my system, so booting to  single 
user mode and waiting 5 minutes is not a good marker of deciding if 
that's the case or not.  Also, i dont have SCSI compiled in my kernel at 
all yet this happens. So that idea is out.


Here is my /proc/interrupts
            CPU0
   0:  426319022          XT-PIC  timer
   1:     409358          XT-PIC  i8042
   2:          0          XT-PIC  cascade
   5:          0          XT-PIC  acpi
   8:  136058006          XT-PIC  rtc
  11:   23497500          XT-PIC  uhci_hcd, uhci_hcd, eth0, EMU10K1
  12:   25482865          XT-PIC  bttv0
  14:    1440279          XT-PIC  ide0
  15:     405600          XT-PIC  ide1
NMI:          0
LOC:  426178067
ERR:     554364
MIS:          0

Re: 2.6.0-test11, TSC cannot be used as a timesource.

[Zwane Mwaikambo]

On Sat, 6 Dec 2003, Ed Sweetman wrote:

> It took over 3 days to trigger it on my system, so booting to  single
> user mode and waiting 5 minutes is not a good marker of deciding if
> that's the case or not.  Also, i dont have SCSI compiled in my kernel at
> all yet this happens. So that idea is out.

Not SCSI but SCI (System Control Interrupt)

> Here is my /proc/interrupts
>             CPU0
>    0:  426319022          XT-PIC  timer
>    1:     409358          XT-PIC  i8042
>    2:          0          XT-PIC  cascade
>    5:          0          XT-PIC  acpi

That would be irq5