Denis R. wrote:
Hi Mark,
Ok, I have recompiled my kernel and excluded the support for SMP and ACPI.
Well, Denis, I've solved it and I bet you can't guess what it was - it
was the fscking keyboard!!!
After spending the last 8 hours building kernels (about 20) with
unnecessary stuff removed and trying various options documented in
/sys/i386/conf/NOTES I finally nailed it down. What made me wonder was a
kernel option BROKEN_KEYBOARD_RESET which disables the use of the
keyboard controller to reset the CPU for reboot. This is needed on some
systems with broken keyboard controllers.. Although that option didn't
fix it it made me think.
I have one of those black and silver Compaq Multimedia USB keyboards so,
out of desperation as much as anything I swapped it for an old PS/2 one
I have lying around and voila! the problem went away. I guess that there
must be something non-standard about it (maybe the circuitry for the MM
keys?), in fact that is kind of confirmed by the fact that when I tried
it with a USB-PS/2 adaptor in the PS/2 port the BIOS couldn't find it -
and yes, the Award BIOS on this A7M266-D m/b has the classic
No keyboard detected or keyboard error
Press F1 to continue or DEL for Setup
Also, the fact that all the boot messages in /var/log/messages had the
same timestamp was a red herring - I've just look at a messages file off
my old machine (4.9) and that is the same.
BTW, if you haven't done so already, I would take a long look in
/sys/i386/conf/NOTES, there is a lot of stuff in there about time,
timecounters, clocks etc. plus known issues an workround options for the
kernel (such as BROKEN_KEYBOARD_RESET) which may well solve your problem
and allow you to run a SMP kernel again. Search for (w/o quotes)
BROKEN_KEYBOARD_RESET, CLOCK OPTIONS, NO_MIXED_MODE, Notes on
APM. The last one mentions If apm is omitted, some systems require
sysctl kern.timecounter.method=1 for correct timekeeping. which, IIUIC,
you put in /boot/loader.conf and it permits you to pick the timer to use
from kern.timecounter.choice:
/home/mark{13}% sysctl kern.timecounter.choice
kern.timecounter.choice: TSC(-100) ACPI-fast(1000) i8254(0) dummy(-100)
HTH and thanks for your time in helping to resolve my problem.
Regards,
Mark.
All my weird problems with slow time have disappeared. The kernel time
stays dead on along with the ntpd. The uptime shows the correct amount of
days. It was funny to see after 3 days that the machine had been up for 1
day.
My dmesg shows a new line now (TSC):
Timecounter i8254 frequency 1193182 Hz quality 0
Timecounter TSC frequency 448945381 Hz quality 800
-su-2.05b# uname -a
FreeBSD mta2 5.2.1-RELEASE-p1 FreeBSD 5.2.1-RELEASE-p1 #0: Mon Mar 8
16:28:46 PST 2004 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/DRKERNEL i386
If you install 4.9, my bet is that you will have the same problem with
your SMP motherboard.
Try this in your /boot/device.hints
hint.acpi.0.disabled=1
Let us know. If this is not a production machine, just out of curiosity,
recompile the kernel without SMP and take a note if the time jumps at
reboot again. This experiment will take less time than the complete
reinstall with 4.9.
Regards!
Denis
To follow up:
Based on your comments Denis, I tried the
kern.timecounter.hardware=i8254 workround - didn't work. I also spun a
UP kernel - that didn't work either. Confirms that it is something
specific to my machine (or the Asus A7M266-D m/b and BIOS).
Where does FreeBSD store the corrupted time across reboots though and,
more importantly, why?
I don't know where to go from here. I do have an old IDE drive lying
around so I guess I could put 4.9 on that and see if the problem exists
there as well.
Regards,
Mark
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-questions
To unsubscribe, send any mail to [EMAIL PROTECTED]
.
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-questions
To unsubscribe, send any mail to [EMAIL PROTECTED]
