Folks, I'm facing a strange situation on my systems running FC5 and my research has resulted in some information which I'm not about. I've to mention that this problem showed up with FC5 and was not there when FC4 was running. The system clock is misbehaving and sometimes goes backward. No ntpd running (read on) ==>> Kernel version 2.6.17-1.2174_FC5 ==>> vpddecode results # vpddecode 2.7 BIOS Build ID: 24KT55AUS Product Name: Netvista M42 Motherboard Serial Number: IBM Machine Type/Model: 8305K8U ==>> rtc results (some of it and compare to result of "date" CMOS Battery is Okay ;-) rtc_time : 16:40:28 rtc_date : 2006-09-04 Mon Sep 4 15:21:15 CDT 2006 15:21:15 up 10:26, 1 user, load average: 0.00, 0.09, 0.09 Note that rtc_time is accurate but output from date command is not ==>> result of running "date" repeatedly [root@ibmac30 ~]# date Mon Sep 4 15:21:30 CDT 2006 [root@ibmac30 ~]# date Mon Sep 4 15:21:32 CDT 2006 [root@ibmac30 ~]# date Mon Sep 4 15:21:29 CDT 2006 [root@ibmac30 ~]# date Mon Sep 4 15:21:30 CDT 2006 [root@ibmac30 ~]# date Mon Sep 4 15:21:31 CDT 2006 [root@ibmac30 ~]# date Mon Sep 4 15:21:32 CDT 2006 [root@ibmac30 ~]# date Mon Sep 4 15:21:29 CDT 2006 [root@ibmac30 ~]# date Mon Sep 4 15:21:31 CDT 2006 Note that the seconds in the displayed time goes like this: 30, 32, 29, 30, 31, 32, 29, 31 It moves backward. What is causing this when ntpd is not running and "drift" file has 0.0 in it and there is no /etc/adjtime (I made sure of that)? When the system is booted up, it seems to be OK and it takes few hours (10 to 24 hours) to get to this mode. The performance goes down. "sleep 1" takes about 20-60 seconds to complete. I'm not running ntpd. The BIOS clock is set to local time zone. I have hourly cron job which runs ntpdate and then writes the system clock to HW clock, removes /etc/adjtime and /var/lib/ntp/drift. This is to make sure nothing is interfering with time. I have also updated the BIOS to most recent version available for this IBM Netvista M42 model (this was one of the solutions). The onboard battery seems to be fine based on using /proc/driver/rtc ==>> I noticed the following in the output of "dmesg" Simple Boot Flag at 0x6c set to 0x1 * This chipset may have PM-Timer Bug. Due to workarounds for a bug, * this time source is slow. If you are sure your timer does not have * this bug, please use "pmtmr_good" to disable the workaround IBM machine detected. Enabling interrupts during APM calls. apm: BIOS version 1.2 Flags 0x03 (Driver version 1.16ac) apm: overridden by ACPI. I did a search for "pmtmr_good" and I came across the following two: http://www.ussg.iu.edu/hypermail/linux/kernel/0603.2/2604.html http://www.tglx.de/projects/hrtimers/2.6.17/broken-out/time-i386-clocksource-drivers-pm-timer-doesnt-use-workaround-if-chipset-is-not-buggy-acpi_pm-cleanup.patch The above two discuss some situation with strange chip-set and the work-around for "gray-list" (I have no idea what that is) what is the source of the problem and how to find it? where should I go from here? should I disable "acpid"? should I use "pmtmr_good" boot parameter? should I disable power management functions of the BIOS? (this is desktop model) which log file to look at to figure out what is going on? Regards, Ali Sobhi ------------------------------------------------------------------------- Sr. Consultant - IBM Research Human Ability and Accessibility Center 512-823-0064 (T/L 793) sobhi@xxxxxxxxxx http://www.ibm.com/able/ ------------------------------------------------------------------------- -- fedora-list mailing list fedora-list@xxxxxxxxxx To unsubscribe: https://www.redhat.com/mailman/listinfo/fedora-list
