Time keeping problems with 5.0-RELEASE
I just updated a 4.7-STABLE system (last rebuilt using sources from Jan 7, 2003) to 5.0-RELEASE, and now the system clock is going nuts. I had the same problem when I updated from 3-STABLE to 4-STABLE quite a while back. To solve the problem then, I added the following to my kernel configuration file: device apm0 at nexus? disable flags 0x20 For my 5.0 kernel configuration, I have: device apm In /boot/device.hints, I have: hint.apm.0.disabled=1 hint.apm.0.flags=0x20 Unfortunately, this isn't working. Is there something different I need to do for 5.0? Looking in NOTES for information about APM, I see a reference to a sysctl variable kern.timecounter.method, but that doesn't seem to be a valid oid in 5.0. I don't think this system (a cheap, old Cyrix MediaGX-based computer) supports ACPI. At the very least, ACPI isn't enabled by default at boot time as it is on my Athlon system. -Patrick To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
RE: Time keeping problems with 5.0-RELEASE
On 23-Jan-2003 Patrick Hartling wrote: I just updated a 4.7-STABLE system (last rebuilt using sources from Jan 7, 2003) to 5.0-RELEASE, and now the system clock is going nuts. I had the same problem when I updated from 3-STABLE to 4-STABLE quite a while back. To solve the problem then, I added the following to my kernel configuration file: device apm0 at nexus? disable flags 0x20 For my 5.0 kernel configuration, I have: device apm In /boot/device.hints, I have: hint.apm.0.disabled=1 hint.apm.0.flags=0x20 Unfortunately, this isn't working. Is there something different I need to do for 5.0? Looking in NOTES for information about APM, I see a reference to a sysctl variable kern.timecounter.method, but that doesn't seem to be a valid oid in 5.0. I don't think this system (a cheap, old Cyrix MediaGX-based computer) supports ACPI. At the very least, ACPI isn't enabled by default at boot time as it is on my Athlon system. The sysctl is now kern.timecounter.hardware. For example: sysctl kern.timecounter.hardware kern.timecounter.hardware: ACPI-safe If it is currently set to 'tsc', try changing it to 'i8254' and see if it works better. If so, you can stick that in /etc/sysctl.conf. -- John Baldwin [EMAIL PROTECTED]http://www.FreeBSD.org/~jhb/ Power Users Use the Power to Serve! - http://www.FreeBSD.org/ To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Time keeping problems with 5.0-RELEASE
That fixed it. Thanks a bunch. :) -Patrick John Baldwin wrote: On 23-Jan-2003 Patrick Hartling wrote: I just updated a 4.7-STABLE system (last rebuilt using sources from Jan 7, 2003) to 5.0-RELEASE, and now the system clock is going nuts. I had the same problem when I updated from 3-STABLE to 4-STABLE quite a while back. To solve the problem then, I added the following to my kernel configuration file: device apm0 at nexus? disable flags 0x20 For my 5.0 kernel configuration, I have: device apm In /boot/device.hints, I have: hint.apm.0.disabled=1 hint.apm.0.flags=0x20 Unfortunately, this isn't working. Is there something different I need to do for 5.0? Looking in NOTES for information about APM, I see a reference to a sysctl variable kern.timecounter.method, but that doesn't seem to be a valid oid in 5.0. I don't think this system (a cheap, old Cyrix MediaGX-based computer) supports ACPI. At the very least, ACPI isn't enabled by default at boot time as it is on my Athlon system. The sysctl is now kern.timecounter.hardware. For example: sysctl kern.timecounter.hardware kern.timecounter.hardware: ACPI-safe If it is currently set to 'tsc', try changing it to 'i8254' and see if it works better. If so, you can stick that in /etc/sysctl.conf. -- Patrick L. Hartling | Research Assistant, VRAC [EMAIL PROTECTED]| 2274 Howe Hall Room 2624 PGP: http://www.137.org/patrick/pgp.txt | T: +1.515.294.4916 http://www.137.org/patrick/ | http://www.vrac.iastate.edu/ To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message