2.6.12.3 clock drifting twice too fast (amd64)

2.6.12.3 clock drifting twice too fast (amd64)

[jerome lacoste]

Installed stock 2.6.12.3 on a brand new amd64 box with an Asus extreme
AX 300 SE/t mainboard.

I remember seeing a message in the boot saying something along:

  "cannot connect to hardware clock."

And now I see that the time is changing too fast (about 2 seconds each second).

I don't have visual on the boot sequence anymore (only remote access).
Kernel earlier than 2.6.11 won't boot on the box (SATA chipset unsupported).

Some info below (probably irrelevant).

What should I try?

Linux manies 2.6.12.3 #1 Thu Jul 28 12:49:15 CEST 2005 x86_64 GNU/Linux

jerome@manies:~$ lspci
0000:00:00.0 Host bridge: ATI Technologies Inc: Unknown device 5951
0000:00:02.0 PCI bridge: ATI Technologies Inc: Unknown device 5a34
0000:00:11.0 RAID bus controller: ATI Technologies Inc: Unknown device 437a
0000:00:12.0 RAID bus controller: ATI Technologies Inc: Unknown device 4379
0000:00:13.0 USB Controller: ATI Technologies Inc: Unknown device 4374
0000:00:13.1 USB Controller: ATI Technologies Inc: Unknown device 4375
0000:00:13.2 USB Controller: ATI Technologies Inc: Unknown device 4373
0000:00:14.0 SMBus: ATI Technologies Inc: Unknown device 4372 (rev 04)
0000:00:14.1 IDE interface: ATI Technologies Inc: Unknown device 4376
0000:00:14.3 ISA bridge: ATI Technologies Inc: Unknown device 4377
0000:00:14.4 PCI bridge: ATI Technologies Inc: Unknown device 4371
0000:00:14.5 Multimedia audio controller: ATI Technologies Inc:
Unknown device 4370
0000:00:18.0 Host bridge: Advanced Micro Devices [AMD] K8 NorthBridge
0000:00:18.1 Host bridge: Advanced Micro Devices [AMD] K8 NorthBridge
0000:00:18.2 Host bridge: Advanced Micro Devices [AMD] K8 NorthBridge
0000:00:18.3 Host bridge: Advanced Micro Devices [AMD] K8 NorthBridge
0000:01:00.0 VGA compatible controller: ATI Technologies Inc: Unknown
device 5b60
0000:01:00.1 Display controller: ATI Technologies Inc: Unknown device 5b70
0000:02:05.0 Multimedia video controller: Brooktree Corporation Bt878
Video Capture (rev 11)
0000:02:05.1 Multimedia controller: Brooktree Corporation Bt878 Audio
Capture (rev 11)
0000:02:0b.0 Ethernet controller: Realtek Semiconductor Co., Ltd.
RTL-8139/8139C/8139C+ (rev 10)

jerome@manies:~$ cat /proc/interrupts 
           CPU0       
  0:   22456064    IO-APIC-edge  timer
  1:       6175    IO-APIC-edge  i8042
  7:          0    IO-APIC-edge  parport0
  8:          0    IO-APIC-edge  rtc
 12:     241004    IO-APIC-edge  i8042
 14:     201574    IO-APIC-edge  ide0
 16:         23   IO-APIC-level  bttv0
 17:     370224   IO-APIC-level  ATI IXP
 19:         33   IO-APIC-level  ohci_hcd:usb1, ohci_hcd:usb2, ehci_hcd:usb3
 20:     221385   IO-APIC-level  eth0
 21:          0   IO-APIC-level  acpi
 22:      65322   IO-APIC-level  libata
 23:          0   IO-APIC-level  libata
NMI:       9788 
LOC:   11226651 
ERR:         18

Re: 2.6.12.3 clock drifting twice too fast (amd64)

[Christoph Lameter]

On Tue, 16 Aug 2005, jerome lacoste wrote:

> Installed stock 2.6.12.3 on a brand new amd64 box with an Asus extreme
> AX 300 SE/t mainboard.
> 
> I remember seeing a message in the boot saying something along:
> 
>   "cannot connect to hardware clock."
> 
> And now I see that the time is changing too fast (about 2 seconds each second).

The timer interrupt is probably called twice for some reason and therefore 
time runs twice as fast. Try using HPET for interrupt timing.

> I don't have visual on the boot sequence anymore (only remote access).

Use serial console or netconsole. The boot information is logged. Try 
dmesg.

Re: 2.6.12.3 clock drifting twice too fast (amd64)

[jerome lacoste]

On 8/16/05, Christoph Lameter <clameter@engr.sgi.com> wrote:
> On Tue, 16 Aug 2005, jerome lacoste wrote:
> 
> > Installed stock 2.6.12.3 on a brand new amd64 box with an Asus extreme
> > AX 300 SE/t mainboard.

Ooops the main board is a Sapphire Axion XP200PA-A58SL. The
aforementionned name is the video card's one...

> > I remember seeing a message in the boot saying something along:
> >
> >   "cannot connect to hardware clock."
> >
> > And now I see that the time is changing too fast (about 2 seconds each second).
> 
> The timer interrupt is probably called twice for some reason and therefore
> time runs twice as fast. Try using HPET for interrupt timing.

Sorry to sound stupid but how do you use HPET?

My latest kernel config has:

> grep HPET /usr/src/linux-2.6.12.3/.config
CONFIG_HPET_TIMER=y
CONFIG_HPET=y
# CONFIG_HPET_RTC_IRQ is not set
CONFIG_HPET_MMAP=y

So it should be enabled, right?

The kernel config doc talks about a 'miscdevice' named /dev/hpec/

I have this
root@manies:/usr/src/linux-2.6.12.3 # ls -la /dev/hpet 
crw-rw----  1 root root 10, 228 Aug 16 15:17 /dev/hpet

I didn't find /usr/src/linux-2.6.12.3/Documentation/hpet.txt very
explicit on what to do. I managed to compile the example code after
tweeking it

--- hpet.c.orig 2005-08-16 23:30:58.000000000 +0200
+++ hpet.c      2005-08-17 00:01:43.000000000 +0200
@@ -1,3 +1,6 @@
+/**
+ * Compile with  gcc -s -I/usr/src/linux-`uname -r`/include -Wall
-Wstrict-prototypes hpet.c -o hpet
+ */
 #include <stdio.h>
 #include <stdlib.h>
 #include <unistd.h>
@@ -13,6 +16,8 @@
 #include <fcntl.h>
 #include <errno.h>
 #include <sys/time.h>
+typedef u_int32_t u32;
+typedef u_int64_t u64;
 #include <linux/hpet.h>
 
 
But as I don't know which device_name to specify (I tried /dev/hpet
and /dev/rtc), I am kinda stuck.


I've also tried rtctest.c (from the rtc. documentation). When run, it
ends by displaying:
Typing "cat /proc/interrupts" will show 131 more events on IRQ 8.
But it only add 117 interrupts for me.
And when ran, this test program correctly counts the seconds. I.e.
time is not too fast.

I also see that the reported RTC time really differs from the time
returned by the date command. I am a little bit confused.

E.g. 

with rtctestnew a modified version of rtctest.c that: displays current
rtc time, register an alarm for 5 secs, waits for the event, and
redisplays for the new rtc time.

> date; ./rtctestnew ; date
Tue Aug 16 22:49:18 CEST 2005
Current RTC date/time is 17-8-2005, 03:03:20.
Alarm time now set to 03:03:25.
Waiting 5 seconds for alarm... okay. Alarm rang.
Current RTC date/time is 17-8-2005, 03:03:25.
                         *** Test complete ***
Tue Aug 16 22:49:28 CEST 2005

rtc time is now 7 hours more than current time. rtc time updates
correctly (+5 seconds) while date is increased 10 seconds. timezone is
correct.

Any idea?

> > I don't have visual on the boot sequence anymore (only remote access).
> 
> Use serial console or netconsole. The boot information is logged. Try
> dmesg.

serial will be hard. The machine is 2500 km away with a non geek in front of it.

Can I use netconsole over ppp ?

Jerome

Re: 2.6.12.3 clock drifting twice too fast (amd64)

[john stultz]

On Tue, 2005-08-16 at 12:10 +0200, jerome lacoste wrote:
> Installed stock 2.6.12.3 on a brand new amd64 box with an Asus extreme
> AX 300 SE/t mainboard.
> 
> I remember seeing a message in the boot saying something along:
> 
>   "cannot connect to hardware clock."
> 
> And now I see that the time is changing too fast (about 2 seconds each second).
[snip]
> 0000:00:00.0 Host bridge: ATI Technologies Inc: Unknown device 5951

Looks like the AMD/ATI bug.

http://bugzilla.kernel.org/show_bug.cgi?id=3927

thanks
-john

Re: 2.6.12.3 clock drifting twice too fast (amd64)

[jerome lacoste]

On 8/16/05, john stultz <johnstul@us.ibm.com> wrote:
> On Tue, 2005-08-16 at 12:10 +0200, jerome lacoste wrote:
> > Installed stock 2.6.12.3 on a brand new amd64 box with an Asus extreme
> > AX 300 SE/t mainboard.
> >
> > I remember seeing a message in the boot saying something along:
> >
> >   "cannot connect to hardware clock."
> >
> > And now I see that the time is changing too fast (about 2 seconds each second).
> [snip]
> > 0000:00:00.0 Host bridge: ATI Technologies Inc: Unknown device 5951
> 
> Looks like the AMD/ATI bug.
> 
> http://bugzilla.kernel.org/show_bug.cgi?id=3927

Sounds like it. I will have to try the patch.

Good catch John!

Jerome

Re: 2.6.12.3 clock drifting twice too fast (amd64)

[Jeff Mahoney]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Christoph Lameter wrote:
> On Tue, 16 Aug 2005, jerome lacoste wrote:
> 
>>Installed stock 2.6.12.3 on a brand new amd64 box with an Asus extreme
>>AX 300 SE/t mainboard.
>>
>>I remember seeing a message in the boot saying something along:
>>
>>  "cannot connect to hardware clock."
>>
>>And now I see that the time is changing too fast (about 2 seconds each second).
> 
> The timer interrupt is probably called twice for some reason and therefore 
> time runs twice as fast. Try using HPET for interrupt timing.
> 
>>I don't have visual on the boot sequence anymore (only remote access).
> 
> Use serial console or netconsole. The boot information is logged. Try 
> dmesg.

I am seeing similar results on my Acer Ferrari 4000 (Turion64 ML-37). It
does appear that time is running 2x normal time.

Booting with noapictimer cleared up the timing issues, though it did
introduce some IRQ badness.

- -Jeff

- --
Jeff Mahoney
SuSE Labs
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.0 (GNU/Linux)

iD8DBQFDAnPzLPWxlyuTD7IRAuQ+AKCoK4Bvj9YaSxK1cYzK/LQUGcj2pQCgmBKK
hGeSfGE+CvdNzqW3pN5LQq8=
=wtra
-----END PGP SIGNATURE-----

Re: 2.6.12.3 clock drifting twice too fast (amd64)

[yhlu]

Me too. If use latest kernel mouse is dead.

By the way, did you solve the battery problem in Linux. "Can not read
battery status"

YH

On 8/16/05, Jeff Mahoney <jeffm@suse.com> wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> Christoph Lameter wrote:
> > On Tue, 16 Aug 2005, jerome lacoste wrote:
> >
> >>Installed stock 2.6.12.3 on a brand new amd64 box with an Asus extreme
> >>AX 300 SE/t mainboard.
> >>
> >>I remember seeing a message in the boot saying something along:
> >>
> >>  "cannot connect to hardware clock."
> >>
> >>And now I see that the time is changing too fast (about 2 seconds each second).
> >
> > The timer interrupt is probably called twice for some reason and therefore
> > time runs twice as fast. Try using HPET for interrupt timing.
> >
> >>I don't have visual on the boot sequence anymore (only remote access).
> >
> > Use serial console or netconsole. The boot information is logged. Try
> > dmesg.
> 
> I am seeing similar results on my Acer Ferrari 4000 (Turion64 ML-37). It
> does appear that time is running 2x normal time.
> 
> Booting with noapictimer cleared up the timing issues, though it did
> introduce some IRQ badness.
> 
> - -Jeff
> 
> - --
> Jeff Mahoney
> SuSE Labs
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.0 (GNU/Linux)
> 
> iD8DBQFDAnPzLPWxlyuTD7IRAuQ+AKCoK4Bvj9YaSxK1cYzK/LQUGcj2pQCgmBKK
> hGeSfGE+CvdNzqW3pN5LQq8=
> =wtra
> -----END PGP SIGNATURE-----
> -
> 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.12.3 clock drifting twice too fast (amd64)

[Jeff Mahoney]

[-- Attachment #1: Type: text/plain, Size: 1361 bytes --]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

fyhlu wrote:
> Me too. If use latest kernel mouse is dead.
> 
> By the way, did you solve the battery problem in Linux. "Can not read
> battery status"

Yes. It's a problem with the DSDT. Install pmtools (for iasl - the acpi
compiler) and grab
ftp://ftp.suse.com/pub/people/jeffm/acpi/Acer_Ferrari_4000.DSDT.asl

You'll need to enable ACPI_CUSTOM_DSDT to do use it, or if you're on a
SUSE system (sorry, I don't know if/which other systems support this),
you can enable a new DSDT by including it in the init{rd,ramfs}. (See
the -a option to mkinitrd)

The attached script will turn your AML file into a character array for
use with ACPI_CUSTOM_DSDT.

There are other issues that need to be worked out in the DSDT, and since
I'm not an ACPI guru (or even anything beyond a casual observer), this
may take some time. Specifically, I get this ...
nsxfeval-0251 [06] acpi_evaluate_object  : Handle is NULL and Pathname
is relative
... for several paths, which a bit of debugging tells me is _PR[0-3]
from the root node. Unfortunately, there is no instance of _PR[0-3] in
the DSDT asl file.

- -Jeff

- --
Jeff Mahoney
SuSE Labs
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.0 (GNU/Linux)

iD8DBQFDAzmpLPWxlyuTD7IRAhupAJ9rAXNZAX3tzHxCzwYuPUE1LO/ivwCghvTT
8uaZtso9gnu9FGk8Imjk94k=
=Iesw
-----END PGP SIGNATURE-----

[-- Attachment #2: file2string.pl --]
[-- Type: application/x-perl, Size: 276 bytes --]

Re: 2.6.12.3 clock drifting twice too fast (amd64)

[yhlu]

thanks

YH

On 8/17/05, Jeff Mahoney <jeffm@suse.com> wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> fyhlu wrote:
> > Me too. If use latest kernel mouse is dead.
> >
> > By the way, did you solve the battery problem in Linux. "Can not read
> > battery status"
> 
> Yes. It's a problem with the DSDT. Install pmtools (for iasl - the acpi
> compiler) and grab
> ftp://ftp.suse.com/pub/people/jeffm/acpi/Acer_Ferrari_4000.DSDT.asl
> 
> You'll need to enable ACPI_CUSTOM_DSDT to do use it, or if you're on a
> SUSE system (sorry, I don't know if/which other systems support this),
> you can enable a new DSDT by including it in the init{rd,ramfs}. (See
> the -a option to mkinitrd)
> 
> The attached script will turn your AML file into a character array for
> use with ACPI_CUSTOM_DSDT.
> 
> There are other issues that need to be worked out in the DSDT, and since
> I'm not an ACPI guru (or even anything beyond a casual observer), this
> may take some time. Specifically, I get this ...
> nsxfeval-0251 [06] acpi_evaluate_object  : Handle is NULL and Pathname
> is relative
> ... for several paths, which a bit of debugging tells me is _PR[0-3]
> from the root node. Unfortunately, there is no instance of _PR[0-3] in
> the DSDT asl file.
> 
> - -Jeff
> 
> - --
> Jeff Mahoney
> SuSE Labs
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.0 (GNU/Linux)
> 
> iD8DBQFDAzmpLPWxlyuTD7IRAhupAJ9rAXNZAX3tzHxCzwYuPUE1LO/ivwCghvTT
> 8uaZtso9gnu9FGk8Imjk94k=
> =Iesw
> -----END PGP SIGNATURE-----
> 
> 
>

Re: 2.6.12.3 clock drifting twice too fast (amd64)

[jerome lacoste]

On 8/17/05, jerome lacoste <jerome.lacoste@gmail.com> wrote:
> On 8/16/05, john stultz <johnstul@us.ibm.com> wrote:
> > On Tue, 2005-08-16 at 12:10 +0200, jerome lacoste wrote:
> > > Installed stock 2.6.12.3 on a brand new amd64 box with an Asus extreme
> > > AX 300 SE/t mainboard.
> > >
> > > I remember seeing a message in the boot saying something along:
> > >
> > >   "cannot connect to hardware clock."
> > >
> > > And now I see that the time is changing too fast (about 2 seconds each second).
> > [snip]
> > > 0000:00:00.0 Host bridge: ATI Technologies Inc: Unknown device 5951
> >
> > Looks like the AMD/ATI bug.
> >
> > http://bugzilla.kernel.org/show_bug.cgi?id=3927
>
> Sounds like it. I will have to try the patch.
>
> Good catch John!

Didn't have time to try the patch as my disk died. I installed a fresh
ubuntu with 2.6.12 (+ vendor patches) instead of 2.6.12.3, and the
issue disappeared.

So maybe ubuntu backported the aforementionned fix to their kernel.

Anyway, one less thing to worry.

jerome