Bug 245834 - hwclock --systohc Freeze
hwclock --systohc Freeze
Status: CLOSED INSUFFICIENT_DATA
Product: Fedora
Classification: Fedora
Component: kernel (Show other bugs)
7
x86_64 Linux
low Severity medium
: ---
: ---
Assigned To: Kernel Maintainer List
Fedora Extras Quality Assurance
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2007-06-26 18:45 EDT by Jay Goodman
Modified: 2008-02-15 21:17 EST (History)
2 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2008-02-15 21:17:43 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Jay Goodman 2007-06-26 18:45:25 EDT
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 


How reproducible:

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 
  
Actual results:

Freeze 

Expected results:

shutdown with power off

Additional info:

smolt: http://smolt.fedoraproject.org/show?UUID=65db44ea-e176-442d-b73e-692d85dcb2bf
Comment 1 Chuck Ebbert 2007-06-26 19:20:21 EDT
Was /etc/sysconfig/ntpd changed from the default?

Default appears to be SYNC_HWCLOCK=no

Comment 2 Chuck Ebbert 2007-06-26 19:21:26 EDT
...and hang setting clock on dv9000 is apparently a known problem.
Comment 3 Jay Goodman 2007-06-26 19:39:50 EDT
...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. 
Comment 4 Christopher Brown 2007-09-17 14:33:47 EDT
Hello Jay,

I'm reviewing this bug as part of the kernel bug triage project, an attempt to
isolate current bugs in the fedora kernel.

http://fedoraproject.org/wiki/KernelBugTriage

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.

Cheers
Chris
Comment 5 Jay Goodman 2007-10-12 22:42:23 EDT
yes, still happening

hwclock pkg ver
util-linux-2.13-0.54.fc7

kern vers
2.6.22.9-91.fc7 #1 SMP Thu Sep 27 20:47:39 EDT 2007 x86_64 

/proc/cmdline
ro root=LABEL=/ iommu=off  agp=off video=vesa:ywrap,mtrr vga=0x317 quiet 
Comment 6 Chuck Ebbert 2007-10-15 14:09:21 EDT
(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.
Comment 7 David Reed 2007-11-18 18:06:17 EST
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.
Comment 8 David Reed 2007-12-17 17:06:43 EST
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.
Comment 9 Christopher Brown 2008-01-09 10:28:49 EST
Hello David,

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?
Comment 10 Christopher Brown 2008-02-15 21:17:43 EST
Closing as per previous comment. Please re-open if this is still an issue for you.

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