I now have both servers booting with no apic and no acpi and keeping
perfect time (with ntp running, without there was a minor drift of a
couple of seconds over the course of a day). What is the down side to
running this way? I noticed that certain interrupts are handled
differently. One of my co-workers got the impression that this is part
of a hardware abstraction layer that could lead to virtualization
opportunities. Any idea what the purpose of moving interrupts (in my
case for network cards and USB) to virtual interrupts is? sample below:
[root@remus ~]# cat /proc/interrupts
CPU0 0: 36662232 IO-APIC-edge timer
1: 9 IO-APIC-edge i8042
8: 26 IO-APIC-edge rtc
9: 0 IO-APIC-level acpi
12: 67 IO-APIC-edge i8042
14: 22214 IO-APIC-edge ide0
15: 329561 IO-APIC-edge ide1
177: 0 IO-APIC-level uhci_hcd
185: 218 IO-APIC-level uhci_hcd
193: 0 IO-APIC-level uhci_hcd
201: 2 IO-APIC-level ehci_hcd
217: 26007 IO-APIC-level eth0, eth1
225: 1030795 IO-APIC-level eth2
NMI: 0
LOC: 36663881
ERR: 0
MIS: 0
Regards,
Chuck
Chuck Mattern wrote:
First a grateful thank you to the individuals who posted responses and
an apology for not turning around faster. My day job is plagued with
a project that distinctly resembles the maiden voyage of HMS Titanic
and has been getting the best of me.
I'm trying the later fixes suggested in the bugzilla entry pointed to
by Zoran below (booting with " noapic noacpi apic=off acpi=off").
Interestingly I had noted several of the issues covered in the
responses, different irq handling, ide disk involvement (the onset of
time problems seems to be hastened by high disk io). I'll report back
on the results.
Regards,
Chuck
Zoran Milojevic wrote:
On 2/18/07, Chuck Mattern <camattern@xxxxxxx> wrote:
-Systems will bog down critically after approximately 24 hours loosing
system time at an increasing rate,
We have several IBM boxes (NetVista mostly) @work that would exhibit
similar behavior - run normally at first, then after a few hours the
system clock practically stops; I measured 2 minutes of wall-clock
time for a "sleep 1" to return, and up to 20 seconds for "usleep 1"...
Tried updating BIOS, kernel (4.3, 4.4, updates), some combinations of
boot time parameters (as in: clock={pit|pmtmr|..}, noapic, acpi=off
and the like), without improvement. We just gave up on those due to
the lack of time.
See also: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=203818
Solution from comment 18 may help (that comment was submitted after
we've given up, not sure if it was tried).
Cheers,
Zoran
_______________________________________________
CentOS mailing list
CentOS@xxxxxxxxxx
http://lists.centos.org/mailman/listinfo/centos
_______________________________________________
CentOS mailing list
CentOS@xxxxxxxxxx
http://lists.centos.org/mailman/listinfo/centos
