lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite for Android: free password hash cracker in your pocket
[<prev] [next>] [thread-next>] [day] [month] [year] [list]
Message-ID: <3efb10970701050443t3ca6bdf7t1c18aec2b446db0e@mail.gmail.com>
Date:	Fri, 5 Jan 2007 13:43:26 +0100
From:	"Remy Bohmer" <l.pinguin@...il.com>
To:	"Dries Kimpe" <Dries.Kimpe@....kuleuven.be>
Cc:	mingo@...e.hu, linux-kernel@...r.kernel.org
Subject: Re: [BUG-RT] RTC has been stopped-> long delay during boot, soft reboot->GRUB fails to call getrtsecs()

Hello Dries,

Thanks for your reply, but as it looks a lot like the same problem, I
want to mention that we do NOT have a Dell system here. It is a
Fujitsu Siemens i945 motherboard. I also saw the problem about "long
delays during boot by hwclock" on an old i845 Kontron Motherboard,
running the same installation/kernel as I mentioned, which we were
using for years and never showed this problems until we start using
this kernel. The RTC clock that was stopped is only seen twice on this
Fujitsu siemens board, not on any other.

So, as it is not a Dell system ,and we therefor have a different BIOS,
I doubt it is BIOS related. Further, I discovered that the problem
also occured in a system that is not tickless. I can therefor exclude
now that it is NOT related to the CONFIG_NO_HZ option, despite what I
mentioned in my previous mail.

In my case it also was NO battery problem, but removing the battery
was the only way to reset the RTC to get it ticking again.

We have enabled HPET in BIOS and kernel.

I have tested the 2.6.20rc3-rt0 kernel of Ingo (as he suggested) by
booting it a few times, and until now we have not seen this problem,
but the long term will learn if it is really gone.


Kind Regards,

Remy Böhmer



2007/1/5, Dries Kimpe <Dries.Kimpe@....kuleuven.be>:
> In-Reply-To: <3efb10970701020838n61db5388l94b2f0ed38073edd@...l.gmail.com>
>
> I found this mail on the LKML.org list, and didn't want to bother to
> subscribe to the list, so I post this directly. Sorry ;-)
>
> I'm suspecting the problem is not related to the rt-kernel at all.
>
> This looks like a well known (but no real solution as far as I know)
> DELL bios problem.
>
> * Somehow, the RTC gets corrupted and stops counting.
> * On recent dell laptops (D420, a.o.) the BIOS sometimes checks the
> clock (everytime a thorough BIOS check is done)
> and just stops with the message "time-of-day clock stopped" (look for
> this on google); On some systems, one can enter the BIOS setup at this
> point,
> causing the bios to reset the clock and solving the problem. On others
> (like the D420), the only problem is to make the B IOS reinitialize the
> clock.
>
> * Once the clock is corrupted, it never runs again (some say a reboot in
> XP can solve it);
>  It is NOT a battery problem. Just disconnecting the battery, causing
> the BIOS to reinitialize NVRAM solves the problem.
>
> I use to have this problem on my D420, and it seemed to go away by:
> - disabling the RTC interrupt in the kernel
> - enabling the HPET timer RTC emulation
>
> More info:
> http://www.ubuntuforums.org/showthread.php?t=176954
> http://www.ubuntuforums.org/showthread.php?t=149565
> https://launchpad.net/distros/ubuntu/+source/linux-source-2.6.15/+bug/43745
>
> Hope this helps.
>
>  Greetings,
>  Dries
>
>
>
> Disclaimer: http://www.kuleuven.be/cwis/email_disclaimer.htm
>
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ