Bug 245834
| Summary: | hwclock --systohc Freeze | ||
|---|---|---|---|
| Product: | [Fedora] Fedora | Reporter: | Jay Goodman <redhat-bugzilla> |
| Component: | kernel | Assignee: | Kernel Maintainer List <kernel-maint> |
| Status: | CLOSED INSUFFICIENT_DATA | QA Contact: | Fedora Extras Quality Assurance <extras-qa> |
| Severity: | medium | Docs Contact: | |
| Priority: | low | ||
| Version: | 7 | CC: | chris.brown, riku.seppala |
| Target Milestone: | --- | ||
| Target Release: | --- | ||
| Hardware: | x86_64 | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Fixed In Version: | Doc Type: | Bug Fix | |
| Doc Text: | Story Points: | --- | |
| Clone Of: | Environment: | ||
| Last Closed: | 2008-02-16 02:17:43 UTC | Type: | --- |
| Regression: | --- | Mount Type: | --- |
| Documentation: | --- | CRM: | |
| Verified Versions: | Category: | --- | |
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
| Cloudforms Team: | --- | Target Upstream Version: | |
| Embargoed: | |||
|
Description
Jay Goodman
2007-06-26 22:45:25 UTC
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. 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 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 (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. 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? Closing as per previous comment. Please re-open if this is still an issue for you. |