Ubuntu corrupts real time clock on some dell laptops

This appears to be a regression from Breezy.

Is that debian bug definately the same issue? The problem i and others have experienced scews up things to the point where the machine will not even post, let alone load drivers.. Seems to be specific to dell laptops (6000 + 6400 series) and ubuntu - not seen anything similar elsewhere.
It happened to me when i was reinstalling from the flight 7 CD, i'd been running flight 6 for some time beforehand with no problems.

I've had strange BIOS clock issues too since I upgraded to Dapper.
My PC is a Athlon x2 3800+ on an ASUS a8V motherboard, not Dell.
Several times on cold power on my BIOS warned me that hardware clock wasn't properly set and I had to reset it manually to be able to boot.
Then I noticed system time shifting in ubuntu and I had to resync it with NTP from time to time.
So I thought it was a battery issue but was a bit sceptic because my motherboard is only 2 months old. I changed the battery yesterday, if the problem continues I think that's proff that the problem is Dapper related.

I can confirm such strange BIOS issues. My PC is a Dell Dimension 9150. I have installed Windows XP and Dapper Drake, since Flight 2. I had no problems until the last 2-3 kernel updates. Suddenly, when I want to reboot, Dapper begin to reboot and the BIOS screen appears, as normal. But, not as normal, the BIOS screen stays on my monitor when its finished and nothing happens. Only Ctrl-Alt-Del helps. And same happens again. After 2 reboots with Ctrl-Alt-Del grub appears again on my monitor and I can boot again. I don't have any problems rebooting from Windows, it's only with Dapper Drake. After serveral reboots wih Dapper i get this strange clock error, too. My System won't boot and my system time is totally wrong. I must adjust my system time and i can boot again. The advice with
HWCLOCKPARS="--directisa" didn't help. I hope this informatin helps a little bit.

Sorry for my bad english!

EmperorLinux is selling the Latitude D820 (on which Dapper Drake also produces the "time-of-day clock stopped" problem, see Forum entry linked in the bug description) with Linux preinstalled:

http://www.emperorlinux.com/mfgr/dell/rhino/?tab=details

They use a customized kernel to fully support the notebooks they sell. The kernels can be downloaded on their website. Maybe someone has the skills to compare the settings with the current dapper kernel and maybe is able to check if EmporerLinux has added patches which may solve the problem described in this bug report?

But maybe this is useless. If I understand the website correctly then they use Ubuntu Breezy (if the user wants this). Not Dapper. And maybe Breezy is not affected by the realtime clock problem.

1st: Sorry for multiple posting of the last comment. I'm new :-)

2nd: I don't think we must search so far away (EmperorLinux). As i said before the strange behaviour with BIOS and hardware-clock appears after the last 2-3 kernel updates. I think there must be a new patch that cause this error.
Unfortunately I don't have any older kernelversions to check in which version the error appears the first time. If somebody out there has packages of 2-4 older kernelversions(386/686), i could install and test it, to specifiy in which version the error appears first.

Just met another victim of this bug. He uses Kubuntu Dapper on a Dell Inspiron 9400 laptop. Same BIOS error message "Time-of-day clock stopped".

Ok now I'm sure of it : After this evening reboot I got the dreaded "CMOS clock not set". My CMOS battery is brand new (see my upper post) so it's not a power issue.
There's something wrong with Dapper !
Damn my whole CMOS/BIOS settings have been reset, that's a real pain !!!!

i have this problem, too. dell inspiron 9400, 2 weeks old, damn!!!
i sent it already to the dell support. :-(
we need a fix really fast!!! 2 weeks left ...

Unfortunately, no changes with the new kernel (2.6.15-23.35). I still need three reboots to see grub again and booting in recovery mode show me "select() to /dev/rtc to wait for clock tick timed out" on the console.
I hope this isn't the final kernel for dapper drake!
If there are more information i can provide, tell me.

Pascal, this is not an indication that the new kernel does not work. Maybe the old kernel already has corrupted your hardware and the new kernel is just suffering from the consequences.

An indication if the kernel works would be running it on a fresh Dell system or a recovered Dell system (removing all batteries to reset the bios) and try out if the problem occures again. Unfortunately I can't test this myself. I gave my D820 to a windows user. If the problem is solved in dapper I may buy this laptop again.

Apparenty, the command that is raising this error is hwclock.

Then, a woraround is ridding off hwclock as a service.

Just execute this line:

rm /etc/rc*/*hwclock*

Are you sure about this? I can corrupt the real-time clock by just running the kernel. I used the kernel parameter init=/sbin/reboot to reproduce the problem after some dozens of reboots. And as far as I know no scripts in /etc/rc.d are run when I use a init parameter like this.

Maybe the hwclock script doesn't PRODUCE the problem but is the first who SEE the problem? After the kernel has corrupted the real-time clock I can use my laptop normally (except that the clock does not run forward when laptop is powered down) as long as the BIOS doesn't do a full check on startup. I've also seen this "select()" error message someone mentioned. Maybe it comes from the hwclock script. But for me it looks like this is just a consequence of the bug and not the producer.

I undertand now.

I have another idea.

I guess the kernel accesses the real time clock by writing to /dev/rtc
So, we must disable the module rtc.

$ cat /etc/modprobe.d/blacklist | grep rtc
blacklist rtc

Will it work?

There seem to be two phases to the problem on my Inspiron 6400 with kernel 2.6.15-22.686

* something corrupts the RTC or BIOS NV data. This might be when the hwclock is written at shutdown. [1]

* as long as the BIOS does not do a full verify during POST, it loads the MBR and booting continues as normal. However, something has failed because the grub timer does not count down, and the time displayed on the Gnome panel is incorrect. [2]

* if, however, the BIOS does do a full verify, then it detects the corruption and halts with the 'Time-of-day clock stopped' error. [3]

Notes:

[1] Last night, I was running Celestia. It crashed badly (touchpad, keyboard and USB mouse were not responsive, gdm would not restart and I could not select a tty) and I had to use the power button to turn off. I don't know if this would have written the hardware clock. On another occasion, I tried to do a sleep and/or hibernate and got a coma instead. I had to remove AC power and main battery to recover. But perhaps sleep/hibernate also write to hwclock?

[2] If you notice the grub timer has frozen, you can still use the keyboard to select a kernel/OS in the grub menu and boot that way. If you boot into Windows XP, WinXP seems to do something to restore the BIOS settings to normality.

[3] and you replace the motherboard. Some people have reported success by removing the coin-cell battery, but others have not.

I have the same problem here. If I could just remove the NVRAM cell...

Well, is it me or am I seeing a pattern here? All laptops reported to have this issue are Dell. Dimension & Inspiron.

My old laptop (inspiron 1150) has not been upgraded. And I guess I will when the bug is fixed :-)

Inspiron 6400 laptop
BIOS: A03
Kernel: 2.6.15-23-686

Some people have suggested changing HWCLOCKPARS="--directisa" in /etc/init.d/hwclock.sh.

I made this change last night, and restarted once or twice since then, including a boot into Windows XP.

This afternoon, the 'Time-of-day clock stopped' failure occurred again after I changed a BIOS setting.

Whatever --directisa does, it is not a complete fix for the problem.

Is there not yet a fix for this?

I think severity should be set to "critical", an operating system *must not* corrupt the bios! I would really not like to install Dapper on a Dell Laptop if I cannot be sure not to break it.

I agree with Frederick: I have offered to install Dapper on a friend's new Dell laptop when it arrives this week, but I am loathe to do so in the current climate.

Regards,
David

So Dapper has finally been released (well done guys), but this bug which essentially ruins perfectly normal hardware is still not fixed (not even "assigned" to anyone). This is not good.

I used to be a Kubuntu Dapper user and now I've been forced to switch to OpenSUSE. Because of this bug.

Does this mean that Dapper has been released to the general public with this bug included?

I've been keeping a close eye on this bug report, and information surrounding it. Since it is affecting a very specific group of systems (of which I have none), it's hard to say what is causing it. I'd suggest creating a bug on the kernel bugzilla to get some upstream interest in this, perhaps even Dell themselves could comment.

Hi guys! I only want to comment that I have a Dell Inspiron 6000 with latest bios working with no problems. Kernel 2.6.15-23-686.

I can confirm this bug with the released Dapper, on a Dell 6400m laptop, kernel 2.6.15-23-686.
Random pressing of the power button and the occasional alt-ctl-del will boot it up. But while in the dumb flashing-dash state, even booting from CD doesn't work. Meanwhile bringing up the BIOS screen can be done reliably.

If at first you don't succeed... experiment a bit.

I am now able to successfully boot my Dell 6400 laptop.

I set the boot method to 'Thorough' in the BIOS. It boots slower, but works.
Hope that works for the rest of you.

I am experiencing the same problem with my brand new (2 months old) laptop, which is at dell as i post this, because of this error.
I think (not sure) it was the update to 2.6.15-22, that corrupted my clock. Some other thing I noticed is that support for the wireless card was build-in, but not working. 2.6.15-23 fixed that. Maybe it has something to do with it?

I'll be getting my laptop back tomorrow, I think. Does anyone know if it's safe to run the final of dapper with my inspiron 6400?

To Ken: Do you mean that pressing ctrl-alt-del will get i through the "Time-of-day clock stopped" error?

If you can access the CMOS battery then it's safe to try Dapper again. If it corrupts the BIOS again then you can simply remove the CMOS battery, wait some time to let the BIOS reset and it will boot again. The Dell Latitude D820 has this battery under the cover of the memory slots. So you just have to remove one screw and this cover and then you can pull out the battery.

But after Dapper was released (with 2.6.15-23 kernel) it got very quite here. Maybe the problem is solved. Or maybe all affected people have switched to an other laptop. Like me :-)

If someone has a Dell Latitude D820 (where recovering from the problem is quite easy because of the accessible CMOS battery) it would be very nice if he tries the current kernel and start it with kernel option "init=/sbin/reboot". If it survives this extreme-rebooting for some hours then I think we can be pretty sure the problem is solved. My D820 died after an hour or so and I could reproduce this several times while playing with kernel options like disabling acpi.

By the way: Currently I'm using a Dell Latitude D810 and I have installed Dapper when the Final was released. Up to now no problems. But I'm not doing an extreme reboot on this machine because the battery is not as easily accessible as the one of the D820. If the problem occurs I will first see it in the grub boot menu when the count down is no longer working. If this happens I will boot Windows, I heard this also fixes the problem and I hope this really works. But maybe the D810 is not affacted at all by this bug (if it's still present).

I don't know what the "Time-of-day clock stopped" error is. My laptop just froze after the BIOS had finished booting, with a blank screen flashing a cursor.
As I said, using the 'thorough' boot mode fixed this. Dapper runs without problem now.

To those who wish to clear out their CMOS RAM... My laptop was delivered DOA. The tech on on the other end of the support phone line told me to hold down the power button for longer than 15 seconds, to zero out the CMOS. Maybe that is all you need to do. She didn't suggest I remove the battery. (However she also got me to remove the RAM modules, which I think was pretty stupid.) -In the end a technician came out and replaced the motherboard. That's what I get for buying on price!

Ken, I think your problem is a different one. The "thorough" boot mode made things worse for me. When the CMOS clock is corrupted then my D820 was still able to boot but the hardware clock was no longer working and the counter in the grub boot menu was no longer counting down. The "Time-of-day-clock stopped" error appears when the BIOS does a thorough check once (which is also done when a BIOS setting is changed) while the CMOS clock is corrupted. During my extreme-rebooting tests I had activated Thorough boot mode so I can immediately see when the BIOS gets corrupted. So at least for the Latitude D820 the "thorough" boot mode does not fix the "time-of-day clock stopped" error. That's why I think that your problem may have nothing to do with this bug. Or maybe your laptop reacts totally different to this bug than other laptops.

On a new D820, I've installed from the dapper drake desktop 6.06 iso, updated packages, including kernel to 2.6.15-25-686 and I set the default runlevel to 6 (reboot) and let it go for a couple of hours. Good news is that I didn't experience the time-of-day clock stopped" error. So it seems more likely that this problem has been fixed in these later kernels.

I'm getting my laptop back this night, so I'll also be testing it with the newest kernel 2.6.15-25-686.

But what is the next step? Is someout going to figure out where the error occured? Are we just going to leave this bug, because it seems to be resolved in the newest kernel? Anyone got any ideas about this?

I also have a Dell Latitude D820, with BIOS vA01. I experienced the frozen GRUB boot timer while running some of the Dapper betas, but once I installed the actual 6.06 release, my GRUB timer started working again. I've also never experienced the BIOS corruption issue that others have. I also run 6.06 on a Dell Latitude X300, with no problems. just FYI.

I've been using my Dell Inspiron 6400 for 3 weeks, almost every day. I've been running these kernels: 2.6.15-25-686 and 2.6.15-26-686. No problems at all. I guess the bug is fixed. Can anyone confirm?

I have a Dell XPS m1210 and I can reproduce the bug here. The --directisa switch didn't help at all. Now my laptop doesn't boot and I have to figure out a way to reset its BIOS somehow.

I just installed Ubuntu 2.6.15-26-386 #1 PREEMPT Thu Aug 3 02:52:00 UTC 2006 i686 GNU/Linux on a DESKTOP Dell Optiplex GX620.

The hwclock command doesn't work. The system says "select() to /dev/rtc to wait for clock tick timed out". Also I had some pretty weird messages during installation about my battery being low; not sure if that's related.

I think it's all the same problem, and I bet it's in /dev/rtc.

I have a

- Dell Inspiron 6400
- with Bios revision A3.

[1] After a 2 months of use, grub would hang while booting. The countdown to boot would not work.

[2] Today I changed BIOS settings for the second time. The system will not boot anymore and simply displays "Time-of-day clock stopped" message.

Haven't tried pulling the coin cell battery yet.

I think the severity of this bug should be increased to "Critical"...

As a continuation to my previous post (see above).

After removing and replacing the coin cell battery, the laptop started booting again.
(not that I did like to this again, as I had to remove the keyboard).

Also, Grub is once again able to count down and boot automatically.

[...]

FYI: Turns out that Dell has a BIOS diagnostics tool for download (works as a bootable ISO). I would like to suggest to folks with this problem, that are still able to boot, to try using it; in order to help diagnose this.

I'll try it if grub's countdown stops again.

This seems to be fixed by the edgy kernel. I'll investigate why and how to see about a dapper backport.

Mark, thanks for the use of the laptop to test.

Oops, wrong bug report.

The debian bug is not the same one as this. It describes a hang on Dell laptops in hwclock, which is worked around by using --directisa. Out problem isn't a hang.

I'd be interested if someone could tell me the output of this command:

sudo hwclock -D

This should provide more informationa bout what is going on.

Please, someone test this on edgy so we can find out if it's already fixed or not.

This bug is my current priority.

Ben --

OK. I ran it twice, as shown below, on my new Dell OptiPlex GX620
Mini-Tower: Intel Pentium 4 Processor 650 with HT (3.4GHz, 2M, 800MHz
FSB). I'm running Dapper 2.6.15-26-386 #1 PREEMPT Thu Aug 3 02:52:00 UTC 2006 i686 GNU/Linux

As far as I can tell, the new information that -D reveals is that it
gave the same number of seconds since 1969 both times, even though it
says it '...got clock tick' after it says that the select() timed out.

root@manche:~# hwclock -D
hwclock from util-linux-2.12r
Using /dev/rtc interface to clock.
Last drift adjustment done at 1121000000 seconds after 1969
Last calibration done at 1121000000 seconds after 1969
Hardware clock is on UTC time
Assuming hardware clock is kept in UTC time.
Waiting for clock tick...
select() to /dev/rtc to wait for clock tick timed out
...got clock tick
root@manche:~# uname -a
Linux manche 2.6.15-26-386 #1 PREEMPT Thu Aug 3 02:52:00 UTC 2006 i686 GNU/Linux
root@manche:~# hwclock -D
hwclock from util-linux-2.12r
Using /dev/rtc interface to clock.
Last drift adjustment done at 1121000000 seconds after 1969
Last calibration done at 1121000000 seconds after 1969
Hardware clock is on UTC time
Assuming hardware clock is kept in UTC time.
Waiting for clock tick...
select() to /dev/rtc to wait for clock tick timed out
...got clock tick
root@manche:~#

I ran the above tests after I pulled the battery out of the motherboard,
waited a few hours, put it back in, and reset all the BIOS options and
rtc, just in case there was some sort of corruption there, as noted
in other bug reports. It didn't make any difference.

I'm glad you're upgrading the status of this bug to critical. I agree
that it's pretty serious. I can't keep the machine's rtc synchronized
with real time, which ultimately will make a variety of messes
(e.g. CVS).

Ben Collins <email address hidden> writes:

> The debian bug is not the same one as this. It describes a hang on Dell
> laptops in hwclock, which is worked around by using --directisa. Out
> problem isn't a hang.
>
> I'd be interested if someone could tell me the output of this command:
>
> sudo hwclock -D
>
> This should provide more informationa bout what is going on.
>
> ** Changed in: util-linux (Debian)
> Importance: Unknown => Untriaged
> Bugwatch: Debian Bug tracker #277298 => None
>
> ** Changed in: util-linux (Debian)
> Status: Unconfirmed => Rejected
>
> --
> Ubuntu corrupts real time clock on some dell laptops
> https://launchpad.net/bugs/43745
>
>
>

--

-- Steve

Steven R. Newcomb, Consultant
Coolheads Consulting

Co-editor, Topic Maps International Standard (ISO/IEC 13250)
Co-editor, draft Topic Maps -- Reference Model (ISO/IEC 13250-5)

<email address hidden>
http://www.coolheads.com

direct: +1 540 951 9773
main: +1 540 951 9774
fax: +1 540 951 9775

208 Highview Drive
Blacksburg, Virginia 24060 USA

(Confidential to all US government personnel to whom this private
letter is not addressed and who are reading it in the absence of a
specific search warrant: You are violating the law and you are
co-conspiring to subvert the Constitution that you are sworn to
defend. You can either refuse to commit this crime, or you c...

Hello,

Glad to hear you are working on this bug!

This is a Inspiron 6400, BIOS revision A3. It's running Dapper. (I might install Edgy for a test during the weekend but I won't promisse)

 ~ # linuxinfo
Linux duo 2.6.15-26-686 #1 SMP PREEMPT Thu Aug 3 03:13:28 UTC 2006
Two Intel Unknown 1662MHz processors, 5319.98 total bogomips, 1001M RAM
System library 2.3.6

 ~ # hwclock -D
hwclock from util-linux-2.12r
Using /dev/rtc interface to clock.
Last drift adjustment done at 1156463253 seconds after 1969
Last calibration done at 1156463253 seconds after 1969
Hardware clock is on UTC time
Assuming hardware clock is kept in UTC time.
Waiting for clock tick...
...got clock tick
Time read from Hardware Clock: 2006/08/25 17:54:06
Hw clock time : 2006/08/25 17:54:06 = 1156528446 seconds since 1969
Fri Aug 25 19:54:06 2006 -0.738670 seconds

Ben Collins <email address hidden> writes:

> The debian bug is not the same one as this. It describes a hang on Dell
> laptops in hwclock, which is worked around by using --directisa.

Regarding the hwclock problem on my Dell 620GX box, I added

 HWCLOCKPARS=--directisa

to

 /etc/default/rcS

...and now hwclock works perfectly!

-- Steve

Steven R. Newcomb, Consultant
Coolheads Consulting

Co-editor, Topic Maps International Standard (ISO/IEC 13250)
Co-editor, draft Topic Maps -- Reference Model (ISO/IEC 13250-5)

<email address hidden>
http://www.coolheads.com

direct: +1 540 951 9773
main: +1 540 951 9774
fax: +1 540 951 9775

208 Highview Drive
Blacksburg, Virginia 24060 USA

(Confidential to all US government personnel to whom this private
letter is not addressed and who are reading it in the absence of a
specific search warrant: You are violating the law and you are
co-conspiring to subvert the Constitution that you are sworn to
defend. You can either refuse to commit this crime, or you can expect
to suffer criminal sanctions in the future, when the current
administration of the United States of America has been replaced by
one that respects the rule of law. I do not envy you for having to
make this difficult choice, but I urge you to make it wisely.)

Here are results on Edgy, I used a "daily" Edgy Eft Live CD from 29 of August.

The laptop is a Dell Inspiron 6400 with BIOS revision A3.

# uname -a
Linux ubuntu 2.6.17-6-686 #2 SMP Fri Aug 11 22:09:15 UTC 2006 i686 GNU/Linux

# hwclock -D
hwclock from util-linux-2.12r
Using /dev/rtc interface to clock.
Last drift adjustment done at 1146000000 seconds after 1969
Last calibration done at 1146000000 seconds after 1969
Hardware clock is on UTC time
Assuming hardware clock is kept in UTC time.
Waiting for clock tick...
...got clock tick
Time read from Hardware Clock: 2006/08/30 23:01:08
Hw clock time : 2006/08/30 23:01:08 = 1156978868 seconds since 1969
Wed 30 Aug 2006 11:01:08 PM UTC -0.038377 seconds

Hello,
I have a Dell Inspiron 6400, I am using Ubuntu 6.06.1 LTS.

I am running my custom own kernel
# uname -a
Linux yack-yack 2.6.17.6 #1 SMP PREEMPT Wed Jul 26 20:26:02 CST 2006 i686 GNU/Linux

$ sudo hwclock -D
hwclock from util-linux-2.12r
Using /dev/rtc interface to clock.
Last drift adjustment done at 1157034115 seconds after 1969
Last calibration done at 1157034115 seconds after 1969
Hardware clock is on local time
Assuming hardware clock is kept in local time.
Waiting for clock tick...
...got clock tick
Time read from Hardware Clock: 2006/09/01 00:03:20
Hw clock time : 2006/09/01 00:03:20 = 1157090600 seconds since 1969
Fri 01 Sep 2006 12:03:20 AM CST -0.210056 seconds

$ sudo hwclock -D --directisa
hwclock from util-linux-2.12r
Using direct I/O instructions to ISA clock.
Last drift adjustment done at 1157034115 seconds after 1969
Last calibration done at 1157034115 seconds after 1969
Hardware clock is on local time
Assuming hardware clock is kept in local time.
Waiting for clock tick...
...got clock tick
Time read from Hardware Clock: 2006/09/01 00:04:23
Hw clock time : 2006/09/01 00:04:23 = 1157090663 seconds since 1969
Fri 01 Sep 2006 12:04:23 AM CST -0.856189 seconds

---
Today I had to remove the coin battery because I receive "Time-of-day clock stopped", later read this page. I though to remove rtc module from kernel, but I don't think without rtc module solved this time problem.

Anyways...

Anybody have been tested this solution for this distribution and kernel. Well I added --directisa to /etc/init.d/hwclock.sh, I will tell you if this solved this situation.

Regards

Hello again,

I forgot, I'm upgraded to bios revision A08 last week.
Now I'm running the following script to force the bug happen.

while true; do
  sudo /etc/init.d/hwclock.sh start;
  sleep 2;
  sudo /etc/init.d/hwclock.sh stop;
  sleep 2;
done

...And guess, I got it, because in other term ran the following script:
~$ while true; do sudo hwclock --show; sleep 2; done
Password:
Fri 01 Sep 2006 12:39:07 AM CST -0.475796 seconds
select() to /dev/rtc to wait for clock tick timed out
select() to /dev/rtc to wait for clock tick timed out

Well, had to kill a lot of instances of hwclock that were running. I didn't know that script lauch a new instance each time.
My conclusion is, Ubuntu 6.06.1 with Linunx 2.6.17 is affected too, even using --directisa.

Anybody has a solution for this.

Regards,

Stumbled upon the same problem. I have a Sony Vaio SZ250P notebook. Something ugly happened (sky2 ethernet fault?), got a kernel panic, and after reboot I started to have that 'select() to /dev/rtc to wait for clock tick timed out' messages, which were persistent across reboots. After a bit of investigating, I found out that my RTC clock had just stopped counting -- it had frozen on some particular time moment and just was not updating anymore. Removing the battery from the notebook wasn't helpful -- it seemed like these notebooks had a separate coin-cell battery inside. Since the device was on warranty and I was too lazy to get myself to service and had the device opened and battery removed there, I started to tinker with the RTC clock CMOS registers, and finally found a way to resume the clock from software, without any physical intervention. The RTC has a 'disable update' bit -- it is sufficient to set it first, and then to clear it again. I'm attaching a simple C program that does just that. Compile it with 'gcc rtc-resume.c -o rtc-resume', and then run './rtc-resume' as root. Hope this helps.

Still no understanding on why that happened, but at least a simple way to fix it when it happens.

Hi, first of all sorry for my bad english!!

When I'was booting my Dapper 6.06 on my Dell Optiplex SX280 for the first time, i got the well known "select() to /dev/rtc to wait for clock tick timed out" problem. I decided to upgrade the SX280 BIOS from rev. A04 to A08 before trying anything else. ¡And it worked fine!

Now my Dapper boots with no problem.

Hello

I've searched the web for this problem and here is an idea I found. It makes sense so I'm thinking it might be the answer to what causes the bug. This is why I post it here so that Ben Collins can check it out:

"Just on of those late night thoughts as I reread some of this. What
if the problem is that Linux somehow uses access to the CMOS in a way
that tends to draw down the battery? That would make having a new,
fresh battery (well connected) a critical item, and would explain why
some posters (your name) have problems that come back "after a few
days" (battery more used or in a colder enviornment??) and why there
are so many 6400s out there with no such problem and why those with
the problem seem to be unable to predict when it will happen or not."

Also, has anyone tried the rtc-resume.c?

Good luck solving the bug. As soon as it's fixed I might reconsider and buy a Dell laptop. Otherwise not since I can't live without Ubuntu :-)

> access to the CMOS in a way that tends to draw down the battery?

This sounds wrong. Whenever I had this problem with the CMOS clock I just removed the CMOS battery for about 30 seconds and reinserted the same battery and everything was working again. So the battery was not empty and I never replaced it with a new battery. I'm still pretty sure the kernel just sometimes corrupts somehow something in the BIOS (A very exact explanation, isn't it? ;-). Removing and re-inserting the battery just causes the BIOS to reset properly so everything works again. And it must be the kernel which corrupts the BIOS and no other appliations because I can reproduce the problem by just starting the kernel again and again with the option init=/sbin/reboot. So in my opinion fiddling around with the /etc/init.d/hwclock stuff is not a solution.

Sorry, I have to correct me: It's not "can reproduce the problem". It must be "could reproduce the problem". I no longer use the Latitude D820 because of this bug so I'm not able to try out if it's still reproducable with current kernels.

Tis occurs alson on edgy with an dell inspiron 640m .
To fix remove de cell battery : instructions found here http://support.euro.dell.com/support/edocs/systems/ins640m/en/SM/coinbatt.htm#wp1123661

and run the bios setup to set new values .

but is there a fix for under edgy ?

doing

# chmod -x /etc/init.d/hwclock*

as suggested in the forum topic linked to in my original bug report
seems to have worked for me (i've not had the problem since) but I
may just have got lucky - I've not gone looking for trouble as i don't
really fancy taking my laptop to bits again.

On 29/09/06, sen <email address hidden> wrote:
> Tis occurs alson on edgy with an dell inspiron 640m .
> To fix remove de cell battery : instructions found here http://support.euro.dell.com/support/edocs/systems/ins640m/en/SM/coinbatt.htm#wp1123661
>
> and run the bios setup to set new values .
>
> but is there a fix for under edgy ?
>
> --
> Ubuntu corrupts real time clock on some dell laptops
> https://launchpad.net/bugs/43745
>

Owke will do that , if anything occurs again i will make a post here again

tnx for the help tough :)

>> Please, someone test this on edgy so we can find out if it's already fixed or not.
> Tis occurs alson on edgy with an dell inspiron 640m
comment at https://launchpad.net/distros/ubuntu/+source/linux-source-2.6.17/+bug/43745/comments/55

Please, please, can somebody help clarify the following:

- shouldn't this problem appear in flashing evidence in the "Known issues" section of the release notes of Dapper? Since Dapper is "LTS" one can expect it to be installed even after Edgy is released and people should be warned about potential (though fixable) damages to their hardware (even if in the end it should turn out that it is Dell fault). Please, remember how the situation was managed when there was a Mandrake distro that was dangerous to LG cdrom readers...

- is this bug also in edgy as the previous note seems to suggest? Is edgy going to be released with this bug unclosed? In this case, shouldn't the above be considered also for the release notes of edgy?

- giving big big evidence to this problem couldn't be useful not just to save users from getting burned with it, but possibly also to get support from kernel people or even Dell in dealing with it?

- at what level of confidence one can consider this thing to be "ubuntu-specific" and not related to a general kernel/system software issue that for some reasons is only exposed more frequently by Dapper?

- can somebody indicate a "mean time between rtc failures" under "normal" laptop usage conditions (2-3 boots a day) ?

Addendum... can it be related to this?
I am just quoting from debian bug 277298 and sites quoted therein...

I saw this:

http://lists.us.dell.com/pipermail/linux-poweredge/2005-February/042501.html

which suggests that the RTC hang issue can be solved by setting
CONFIG_HPET_RTC_IRQ=y
I have confirmed that on a dell 1850, which used to hang when hwclock
ran, the above configuration setting allows a normal boot. I suspect,
but have not yet confirmed, that disabling HPET may also prevent hangs.

and also...

Found by Googling for "8208CA", and then reading Google's
    "cached" copy. (This stuff isn't easy to find - the original
    has evidently been taken down:

    sunsite.rediris.es/sites/download.intel.nl/
design/chipsets/specupdt/290739.htm
                    ^^ Estonia??)

    This document may or may not explain 2.8.1 real-time clock
    problem.

Problem:
    Under certain conditions, a CPU generated I/O read to RTC
    (Real Time Clock) registers 0-9 may return an incorrect
    value. The issue occurs on the read path from the RTC
    registers and the RTC value in the registers is not impacted.
    Should the certain conditions occur, one or more of the bits
    read from the RTC registers may be incorrect. The issue has
    only been found using a synthetic test and has not been seen
    using commercially available software. [ <= N.B. ]

   "Implication:
    An operating system or software applications which
    synchronizes the time/date value with the RTC <registers may
    get an incorrect value.

   "Workaround:
    BIOS workaround is available in the Intel ICH3-S BIOS
    Specification Update Rev 2.01. The workaround does take into
    account multiple CPUs and Hyper Threading. The workaround uses
    timers to zero-in on the window where invalide RTC I/O read
    data could be returned. Using the software SMI, HPET timers
    and port 71 traps, the BIOS will ensure that there are no
    accesses to the RTC during this timing window.

I've been using Dapper on a Dell Inspiron 6400 for about a month and didn't experience this problem so far. I'm using BIOS Rev A08.

Just in case, some time ago a Dell tech support guy told me how to reset the BIOS while we were trying to solve a thermal problem (BTW, the fix was to upgrade the BIOS from rev 06 to 08). I don't clearly remember the process but I think it was the following one:

* Extract the battery
* Unplug the power cord
* Keep the power button pressed for approx 2 minutes

Did you try upgrading the BIOS?

I will post the hwclock output later because I have the laptop at home. Please let me know if I can help with anything else before I upgrade to Edgy Eft.

Best regards,

Esteban

Hi,

I've got the same RTC problem with D420 laptop (with already one mainboard replaced :P because of this). I just noticed that rtc-resume.c doesn't help in my case. Booting to Windows XP helps.

Hi,

I'm not a kernel hacker, but I'm just wondering if this could be a compiler bug in compiler (gcc 4.0.3) that is bundled with Dapper. That came to my mind because of the fact (?) that bug is not present in Edgy official kernel and other distributions.

I'm using 2.6.18 kernel, the same kernel which I compiled in Dapper, and am having still the same bug.

This is the output of hwclock on my Inspiron 6400 running BIOS rev A08 with factory default settings and doing OK with Dapper:

esteban@darko:~$ sudo hwclock -D
hwclock from util-linux-2.12r
Using /dev/rtc interface to clock.
Last drift adjustment done at 1161744804 seconds after 1969
Last calibration done at 1161744804 seconds after 1969
Hardware clock is on local time
Assuming hardware clock is kept in local time.
Waiting for clock tick...
...got clock tick
Time read from Hardware Clock: 2006/10/28 17:19:04
Hw clock time : 2006/10/28 17:19:04 = 1162066744 seconds since 1969
Sat 28 Oct 2006 05:19:04 PM ART -0.294788 seconds

I'll upgrade to Edgy Eft and see what happens.

I downloaded the ubuntu 6.10 alternative CD to boot my Dell 640m, the message "time-of-day clock stopped" displayed. I had to take out the battery for some time...

Inspiron 9400 + Ubuntu Edgy: the message "time-of-day clock stopped" displayed after some days of normal use.

Inspiron 6400 :

Ubuntu edgy with 2.6.17-10-generic #2 SMP

The message "time-of-day clock stopped" happened after several days on this new ubuntu release.

Removing and replacing the coin cell battery allows me to boot again...
(I've also update the bios : A06 --> A09)

This bug is VERY CRITICAL !

I am using imac g3 summer 2000 Dapper Installed. Everything went fine until i noticed that the date was April 7, 1976. I tried changing it to the current date which it did until i did a reboot which changed it back to April 7, 1976. I noticed a few days later that the date moved but everytime i changed the date it reverts back to what it is, that is
April 7, 1976 plus number of days after i installed Dapper

wierd

It is with great sadness that I report Kubuntu 6.10 Edgy corrupts the bios on my old (5 years) Inspiron 8000 Pentium 3 1GHZ. So it appears that this problem is not limited to newer hardware.

Installed Kubuntu 6.10 Edgy, rebooted 5 times or so. And when booting up the Bios message appeared stating that the date/time had been lost and did I want to F1 Set the date/time now or F2 ignore this error. Luckily this BIOS has more user friendly options than my Inspiron 6400 which simply displays the infuriating "time of date clock stopped" message and then fails to boot or do anything.

This is very serious guys, what action is being done to investigate this problem? Nearly 6 months and no resolution.

(I'm surprised this has not been Slashdotted about yet).

This occurred yesterday on a new install of 6.10 edgy desktop on a new Dell Latitude D820 with BIOS A03. BIOS diagnostics from setup the RTC failed. Clock raced until edgy came up. Disconnected and reconnected the coin-cell battery as instructed and set the BIOS clock on startup. BIOS passed diagnostics. System seems OK.

Questions: does this situation risk corrupting or losing data? Will I likely see the problem recur? Our group will not be able to use Ubuntu if the answer to these questions is yes.

Thanks

for tracking purposes... pls report if you try feisty. thanks

I'm another one living in fear; it hasn't happened yet, but a resolution on this would be nice.

My setup is:
Phoenix ROM BIOS PLUS Version 1.10 A09
Dapper, 2.6.15-23-386, on Insprion 6400

Could it be BIOS version dependent?

I noticed over on the ubuntu forums, there is a thread, but nobody seems to have heard about the issue.

http://www.ubuntuforums.org/showthread.php?t=264976&highlight=bios+clock+stopped

Just to keep you up-to-date: Some months ago I stopped using the Dell Latitude D820 because of this problem and moved back to a Dell Latitude D810 which was not affected. Now I got my hands on an D820 again, installed Edgy on it and did some hours of auto-reboots (My previous D820 did not survive this). No problems. I'm using the D820 for a month now and no problem did occur. I'm using BIOS Revision A04. My previous D820 had BIOS revision A01. Maybe Dell has fixed the problem in a newer revision.

For me (at least) the problem is solved.

Same thing for me as Klaus Reimer .
I'am using the dell inspirion 640m with the latest bios update from dell rev 05 I believe.
and working now back on edgy for a month and half . so i still cross my finger every time I boot but for so far it seems that dell did something in the bios updates .
My 5 cents

I also do not have any problems anymore, since the Dapper drake final.
Now running: Ubuntu Edgy, Linux kernel 2.6.17-10-generic.
Laptop: Dell Inspiron 6400 (don't know which BIOS update, never updated)

I had the laptop since March, and it has been repaired because of this problem with a kernel in the beta version of dapper, in June. I guess dell upgraded my BIOS, but I'm not sure.

I can finally install and use ubuntu 6.10 on my Dell Inspiron 640m after upgrading the BIOS.

Please retest against 2.6.20-2 when it is available in the feisty archive.

It seems to be fixed for me too.
(dell inspiron 9400, feisty, 2.6.20)

For me (with kernel 2.6.17) the problem didn't appear again... Difficult to say if the problem is fixed by upgrading the bios or not...

I also confim that the edgy 2.6.17 did not give any problem to me in the last month on a Dell D820. The machine was upgraded to firmware A04, so I cannot really say whether:

1) kernel 2.6.17 fixed the issue
2) firmware upgrade A04 fixed the issue
3) I have just been lucky in not hitting the problem so far

Somehow, I tend to think that 2) is the correct one.

Well, it's not limited to Dell laptops. I can confirm that it also occurs on a new Dell PowerEdge 840.

The funny thing is that I run 6.06 for a reason, namely that this version is supposed to be supported for a long period of time. Yet it's not (being?) fixed in Dapper but Edy and Feisty seem to be dealing with it much better.

Guess I'll have to install Edgy in order not to run any risks.

Ouch. Did you report it on the bug list? I had to finish configuring that laptop so went to Opensuse 10.2. I really like Ubuntu, however. Good luck!

-----Original Message-----
>From: wr19026 <email address hidden>
>Sent: Jan 31, 2007 6:39 PM
>To: <email address hidden>
>Subject: [Bug 43745] Re: Ubuntu corrupts real time clock on some dell laptops
>
>Well, it's not limited to Dell laptops. I can confirm that it also
>occurs on a new Dell PowerEdge 840.
>
>The funny thing is that I run 6.06 for a reason, namely that this
>version is supposed to be supported for a long period of time. Yet it's
>not (being?) fixed in Dapper but Edy and Feisty seem to be dealing with
>it much better.
>
>Guess I'll have to install Edgy in order not to run any risks.
>
>--
>Ubuntu corrupts real time clock on some dell laptops
>https://launchpad.net/bugs/43745

On Wed, Jan 31, 2007 at 11:39:50PM -0000, wr19026 wrote:
> Well, it's not limited to Dell laptops. I can confirm that it also
> occurs on a new Dell PowerEdge 840.

Can you please post exactly the steps you took that invoked the
failure, the symptom as you see it, and what you did to recover?
We've never seen anything like this on SuSE or Red Hat-based distros,
and I was unable to make an Inspiron 6400 fail in any manner with
several versions of Ubuntu.

With details on how you're reproducing the failure, perhaps we can
actually find it.

Also, what's your BIOS version on the PE840?

Thanks,
Matt

--
Matt Domsch
Software Architect
Dell Linux Solutions linux.dell.com & www.dell.com/linux
Linux on Dell mailing lists @ http://lists.us.dell.com

Problem in BIOS? revise proyect: http://www.linuxfirmwarekit.org/

I had the same problem with my new Dell Latitude D620, the reason - my mistake, i force shutdown Edgy when it was in the process of shutting down. Used this guide to unplug the coin cell battery. I had to go into the bios and change the FASTIR to com2 after that.

My bios - http://ftp.us.dell.com/bios/D620_A07.EXE

Guide i used - http://support.dell.com/support/edocs/systems/latd620/en/SM/coincell.htm#wp1111212

I have a Dell Inspiron 6400, running Edgy with some packages from Feisty, in particular kernel 2.6.20-9-lowlatency, version 2.6.20-9.16.

I frequently put the laptop in suspend-to-disk using `hibernate`. After a number of hibernate-wakeup cycles, it starts going downhill.

First, the Grub timer doesn't count down. But I can hit Esc and then select the kernel manually, then the system boots and restores my desktop OK. The desktop clock is still showing the time when the system was put to hibernation, but after about 1 minute, it gets synchronised to the correct time (ntp kicking in?).

Now, after I hibernate the system once more and wake it up again, the clock doesn't get updated to the correct time. It's still running however, but it's behind. If the system stayed in hibernate for 1 hour, the clock will be 1 hour behind.

Doing sudo hwclock --hctosys results in this:

select() to /dev/rtc to wait for clock tick timed out

I didn't dare to force a full power-on test, because I've heard some people had to change their motherboards after that.

Hope it helps.

Iulian, do you have the latest Dell firmware for your laptop installed? You say you use the latest Ubuntu version so this may be an indicator that this error was not solved in Ubuntu or the Linux kernel but it was solved in the Dell firmware. I'm using a Dell Latitude D820 and with the latest firmware I did not run into this problem in the last months. I even did a extreme-rebooting-test as I did to confirm the reproducability of the bug and it worked fine. So maybe there is a newer firmware available for the Inspiron, too, and it will fix the bug.

To solve your current problem you may try to boot windows once (it was reported that this fixes the clock). If you don't have windows installed then maybe a Windows boot CD (Installation disks? Live CD?) may work, too. Or try to remove the cmos battery (also called coin battery) of the laptop for some minutes to reset the BIOS configuration. This solved the problem for me even in the latest state (when the laptop stopped working at all)

Hi,

Firmware upgrade doesn't help always, like not in my case. I have upgraded
to the latest bios version A3 on latitude D420 and can confirm that the
problem hasn't disappeared by BIOS upgrade. It doesn't happen very often in
my use, but it has happened once, therefore the problem remains.

On Fri, Mar 09, 2007 at 06:51:34AM -0000, Klaus Reimer wrote:
> Iulian, do you have the latest Dell firmware for your laptop installed?
> You say you use the latest Ubuntu version so this may be an indicator
> that this error was not solved in Ubuntu or the Linux kernel but it was
> solved in the Dell firmware. I'm using a Dell Latitude D820 and with the
> latest firmware I did not run into this problem in the last months. I
> even did a extreme-rebooting-test as I did to confirm the
> reproducability of the bug and it worked fine. So maybe there is a newer
> firmware available for the Inspiron, too, and it will fix the bug.

--
Tuomas Airaksinen, Ph.D. student
University of Jyväskylä, Finland

We will not be fixing this for Edgy. The problem is resolved in Feisty+

A candidate for 6.06.2 if the fix from Feisty can be backported. No longer a critical issue. Newer kernel and/or bios seems to resolve it.

Will not fix in 6.06.2. BIOS updates appear to resolve the problem.