Red Hat Bugzilla – Bug 245834
hwclock --systohc Freeze
Last modified: 2008-02-15 21:17:43 EST
Description of problem:
Shutdown's call to Sync the system time to hwclock hard locks. No panic, just a
hard lock. This can be mark a duplicate of 227234 that was logged for fc6.
Version-Release number of selected component (if applicable):
2.6.21-1.3228.fc7 #1 SMP
Always unless "noapic pci=noacpi" is specified as a kernel param.
Currently I have pci=routeirq and have had pci=pirq
Steps to Reproduce:
1. shutdown -h
2. which calls /etc/init.d/halt
3. which calls /sbin/hwclose
shutdown with power off
Was /etc/sysconfig/ntpd changed from the default?
Default appears to be SYNC_HWCLOCK=no
...and hang setting clock on dv9000 is apparently a known problem.
...not reporting an ntpd issue
...thats why I said could be marked a duplicate of 227234, but still have a
record for f7 as well
maybe /etc/rc.d/init.d/halt should have an /etc/sysconfing/halt settings file
and checks some args before for hwclock syncing as does ntpd since this is a
known issue on several hardware platforms.
I'm reviewing this bug as part of the kernel bug triage project, an attempt to
isolate current bugs in the fedora kernel.
I am CC'ing myself to this bug and will try and assist you in resolving it if I can.
There hasn't been much activity on this bug for a while. Could you tell me if
you are still having problems with the latest kernel?
If the problem no longer exists then please close this bug or I'll do so in a
few days if there is no additional information lodged.
yes, still happening
hwclock pkg ver
184.108.40.206-91.fc7 #1 SMP Thu Sep 27 20:47:39 EDT 2007 x86_64
ro root=LABEL=/ iommu=off agp=off video=vesa:ywrap,mtrr vga=0x317 quiet
(In reply to comment #3)
> ...not reporting an ntpd issue
> ...thats why I said could be marked a duplicate of 227234, but still have a
> record for f7 as well
> maybe /etc/rc.d/init.d/halt should have an /etc/sysconfing/halt settings file
> and checks some args before for hwclock syncing as does ntpd since this is a
> known issue on several hardware platforms.
I suggested that to the initscripts maintainer, but he doesn't want to do that.
As I just commented in 227234, I would suggest that the line running hwclock in
this script is unnecessary, redundant, and dangerous, since hwclock failing can
cause the disks to not be synced.
The kernel updates the RTC when ntpd has synchronized the kernel clock, by
calling update_persistent_clock() internally approximately every 11 minutes.
This doesn't cover the case when ntpd is not being used, but the user can set
the RTC whenever he/she manually updates the RTC using hwclock.
update_persistent_clock() has recently been fixed (2.6.24rc3) to work on x86_64
platforms correctly, but it has always worked on i386 platforms and others.
Further info: I have tracked down the cause of this hwclock freeze on my system,
and a patch for the cause is in process. The basic issue is that ioport 0x80 is
used to insert delays after other ioport operations, but on my HP Pavilion
dv9000z, and probably this one as well, too many such ioport operations
eventually cause a hard bus freeze.
What's the latest on this - have you been able to test the patch successfully?
Is it possible for you to reference said patch in this bug?
Closing as per previous comment. Please re-open if this is still an issue for you.