Bug 8069 - clock way to fast
Summary: clock way to fast
Status: REJECTED INSUFFICIENT_DATA
Alias: None
Product: Timers
Classification: Unclassified
Component: Realtime Clock (show other bugs)
Hardware: i386 Linux
: P2 high
Assignee: john stultz
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2007-02-23 02:47 UTC by Jethro Borsje
Modified: 2008-09-22 12:45 UTC (History)
3 users (show)

See Also:
Kernel Version: 2.6.17-10mdv
Subsystem:
Regression: ---
Bisected commit-id:


Attachments
A zip file of the requested output for 2.6.17-11mdv (21.46 KB, application/octet-stream)
2007-06-04 01:12 UTC, Jethro Borsje
Details
A zip file of the requested output for 2.6.17-14mdv (20.63 KB, application/octet-stream)
2007-06-04 02:39 UTC, Jethro Borsje
Details

Description Jethro Borsje 2007-02-23 02:47:31 UTC
Distribution: Mandriva 2007
Hardware Environment: Toshiba Satellite A100-510
Software Environment: KDE 3.5.4
Problem Description:
My clock runs way to fast, this means that in every "normal" minute, my system
clock lets a few minutes pass by. 

I have used the following boot options to try to solve this issue:
- noapictimer
- no_timer_check
- notsc

The first one ("noapictimer") seems to solve it. Booting with "noapic" also
solves the problem. However, this intrduces a new problem, by booting with one
of these options my wired NIC (Realtek RTL8139) does not work anymore.
Comment 1 Len Brown 2007-03-07 19:32:00 UTC
does it get better with "acpi=off"?
Comment 2 Jethro Borsje 2007-03-08 00:18:26 UTC
If I use "acpi=off" my NIC (Realtek RTL8139) does not work anymore.
Comment 3 Thomas Gleixner 2007-03-08 00:32:07 UTC
On Thu, 2007-03-08 at 00:18 -0800, bugme-daemon@bugzilla.kernel.org
wrote:
> ------- Additional Comments From jborsje@xs4all.nl  2007-03-08 00:18 -------
> If I use "acpi=off" my NIC (Realtek RTL8139) does not work anymore.

Can you check the clock nevertheless ?

	tglx


Comment 4 Jethro Borsje 2007-03-08 00:45:00 UTC
Yes "acpi=off" fixes the problem with the clock.
Comment 5 john stultz 2007-03-08 09:58:04 UTC
Was there a version of the kernel that did not exhibit this behavior?
Also are you running the latest version of your system's BIOS?
Comment 6 Len Brown 2007-03-08 20:52:41 UTC
For both the default and the "acpi=off" case, please
attach the complete dmesg and paste the /proc/interrupts
Comment 7 Jethro Borsje 2007-03-26 06:41:30 UTC
[quote]Was there a version of the kernel that did not exhibit this behavior?[/quote]
Not that I know of.

[quote]Also are you running the latest version of your system's BIOS?[/quote]I
believe I am, I am not able to find a newer version.

[quote]For both the default and the "acpi=off" case, please
attach the complete dmesg and paste the /proc/interrupts[/quote]
I will provide this information within the next few days.
Comment 8 Adrian Bunk 2007-06-03 14:35:42 UTC
Jethro?
Comment 9 Jethro Borsje 2007-06-04 00:11:44 UTC
I am so sorry, you are right, I still have to provide the information. I will
start collecting it right away.
Comment 10 Thomas Gleixner 2007-06-04 00:37:52 UTC
Does this happen with a more recent kernel as well ?
Comment 11 Jethro Borsje 2007-06-04 01:12:01 UTC
Created attachment 11662 [details]
A zip file of the requested output for 2.6.17-11mdv

This zip file contains the requested output. I apologize for taking so long.
Can you let me know if it helps? If you need any more information please do not
hesitate to ask.
==================================================================

NOTE: apic and lapic where always on
==================================================================

DEFAULT CASE:
- no extra boot options
- acpi = on
- nic works fine
- clock is too fast

==================================================================
ACPI=OFF CASE:
- no extra boot options
- acpi = off
- nic does not work
- clock works fine
- no GUI anymore when booting normally with this configuration (from
lilo.conf):
[quote]
default="linux"
boot=/dev/sda
map=/boot/map
keytable=/boot/us-intl.klt
menu-scheme=wb:bw:wb:bw
compact
prompt
nowarn
timeout=100
message=/boot/message
image=/boot/vmlinuz
	label="linux"
	root=/dev/sda6
	initrd=/boot/initrd.img
	append="resume=/dev/sda7 splash=silent acpi=ht"
	vga=788
[/quote]

I managed to boot into the failsafe mode:
[quote]
image=/boot/vmlinuz
	label="failsafe"
	root=/dev/sda6
	initrd=/boot/initrd.img
	append="failsafe resume=/dev/sda7"
[/quote]

This placed me on the command line as root. I could then run "startx" (as
root). Which resulted in a proper KDE session. In this session the NIC was not
working.

==================================================================
WORKING CASE:
- extra boot options: "noapictimer irqpoll"
- acpi = on
- nic works fine
- clock works fine
Comment 12 Jethro Borsje 2007-06-04 01:49:43 UTC
I forgot to say I created the output with 2.6.17-11mdv. I now see that there is
a kernel 2.6.17-14mdv available from the rpm sources. I will upgrade to this one
and try it again.
Comment 13 Jethro Borsje 2007-06-04 02:39:24 UTC
Created attachment 11670 [details]
A zip file of the requested output for 2.6.17-14mdv

Here is the requested output with kernel 2.6.17-14mdv.

==========================================
NOTE: apic and lapic are always on

==========================================
DEFAULT CASE:
- no extra boot options
- acpi=on
- nic  works  fine
- clock too fast
- USB did not work (it chrashed in 30 seconds)

==========================================
ACPI=OFF CASE:
- no extra boot options
- acpi=off
- nic does not work
- clock too fast
- I did not experience a USB crash
- I had the same GUI problems as with 2.6.17-10mdv

==========================================
WORKING CASE:
- extra boot options: "noapictimer irqpoll"
- acpi = on
- nic works fine
- clock works fine

==========================================
So overall the new kernel introduced a USB problem, and also made the clock
going to fast when booting with acpi=off. In 2.6.17-10mdv at least the clock
worked when booting with acpi=off (and I also did not experience the USB
problem).
Comment 14 Natalie Protasevich 2007-11-02 13:51:44 UTC
Any progress with this so far?
Jethro, how does this work with newer kernels?
Thanks.
Comment 15 Alan 2008-09-22 12:45:32 UTC
No response 

Note You need to log in before you can comment on or make changes to this bug.