Re: RTC clock doesn't generate interrupts
On Mon, May 21, 2007 at 04:55:32PM +1000, Peter Jeremy wrote: On 2007-May-20 21:38:09 +0200, Victor Balada Diaz [EMAIL PROTECTED] wrote: I tried the machdep.adjkerntz trick and didn't work very well. If i'm on 0 irqs per second after changing the value i get 1 irq per second. If i'm on 20 i get 21, and so on. The machdep.adjkerntz trick works by reading the status register - which implicitly acknowledges the interrupt and allows further interrupts to be generated. I can't explain how this would effectivly increase the interrupt frequency by 1Hz. Is is possible your CMOS battery is dead? After waiting a few days to be sure the problem doesn't happen again I can confirm that the problem was that the CMOS battery was dead. Changed it and now it's working without any problems. Is there any guide out there for tracking hardware failures? I think that a chapter about hardware related problems could be a great addition to the handbook. Thanks a lot for your help! -- La prueba más fehaciente de que existe vida inteligente en otros planetas, es que no han intentado contactar con nosotros. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: RTC clock doesn't generate interrupts
On 2007-May-20 21:38:09 +0200, Victor Balada Diaz [EMAIL PROTECTED] wrote: I tried the machdep.adjkerntz trick and didn't work very well. If i'm on 0 irqs per second after changing the value i get 1 irq per second. If i'm on 20 i get 21, and so on. The machdep.adjkerntz trick works by reading the status register - which implicitly acknowledges the interrupt and allows further interrupts to be generated. I can't explain how this would effectivly increase the interrupt frequency by 1Hz. Is is possible your CMOS battery is dead? Do you know of any other workaround/patch that i can try? Setting the time/date will have the same effect. -- Peter Jeremy pgpASPfJ8ofXo.pgp Description: PGP signature
RTC clock doesn't generate interrupts
Hello, I have a server with FreeBSD 6.2 that is not generating RTC IRQs. When the system boots everything it's working fine and I get 128 interrupts per second but after a few hours the system starts losing RTC interrupts. If I enable powerd it happens much faster than without it. I've searched on the internet for other people with the same problem and I've found that this one[1] could be related, but as I'm not using APM can't use the workaround. Any ideas on how could I fix this? Attached are the dmesg and vmstat -i output. [1]: http://docs.freebsd.org/cgi/getmsg.cgi?fetch=27863+0+archive/2000/freebsd-hardware/2130.freebsd-hardware -- La prueba más fehaciente de que existe vida inteligente en otros planetas, es que no han intentado contactar con nosotros. Copyright (c) 1992-2007 The FreeBSD Project. Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 The Regents of the University of California. All rights reserved. FreeBSD is a registered trademark of The FreeBSD Foundation. FreeBSD 6.2-RELEASE-p2 #0: Sun Mar 11 23:57:37 CET 2007 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/EQUILIBRIUM Timecounter i8254 frequency 1193182 Hz quality 0 CPU: Intel Pentium III (868.64-MHz 686-class CPU) Origin = GenuineIntel Id = 0x68a Stepping = 10 Features=0x383fbffFPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,MMX,FXSR,SSE real memory = 401473536 (382 MB) avail memory = 383381504 (365 MB) pnpbios: Bad PnP BIOS data checksum acpi0: INTEL SOLANO70 on motherboard acpi0: Power Button (fixed) Timecounter ACPI-fast frequency 3579545 Hz quality 1000 acpi_timer0: 24-bit timer at 3.579545MHz port 0x408-0x40b on acpi0 cpu0: ACPI CPU on acpi0 acpi_throttle0: ACPI CPU Throttling on cpu0 pcib0: ACPI Host-PCI bridge port 0xcf8-0xcff on acpi0 pci0: ACPI PCI bus on pcib0 agp0: Intel 82815 (i815 GMCH) SVGA controller mem 0xf800-0xfbff,0xffa8-0xffaf irq 11 at device 2.0 on pci0 pcib1: ACPI PCI-PCI bridge at device 30.0 on pci0 pci1: ACPI PCI bus on pcib1 fxp0: Intel 82559 Pro/100 Ethernet port 0xdc00-0xdc3f mem 0xff8fe000-0xff8fefff,0xff70-0xff7f irq 7 at device 3.0 on pci1 miibus0: MII bus on fxp0 inphy0: i82555 10/100 media interface on miibus0 inphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto fxp0: Ethernet address: 00:30:48:22:8d:9e fxp1: Intel 82559 Pro/100 Ethernet port 0xd480-0xd4bf mem 0xff8fd000-0xff8fdfff,0xff60-0xff6f irq 11 at device 4.0 on pci1 miibus1: MII bus on fxp1 inphy1: i82555 10/100 media interface on miibus1 inphy1: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto fxp1: Ethernet address: 00:30:48:22:8d:9d ahc0: Adaptec aic7899 Ultra160 SCSI adapter port 0xd000-0xd0ff mem 0xff8fc000-0xff8fcfff irq 3 at device 5.0 on pci1 ahc0: [GIANT-LOCKED] aic7899: Ultra160 Wide Channel A, SCSI Id=7, 32/253 SCBs ahc1: Adaptec aic7899 Ultra160 SCSI adapter port 0xd800-0xd8ff mem 0xff8ff000-0xff8f irq 10 at device 5.1 on pci1 ahc1: [GIANT-LOCKED] aic7899: Ultra160 Wide Channel B, SCSI Id=7, 32/253 SCBs isab0: PCI-ISA bridge at device 31.0 on pci0 isa0: ISA bus on isab0 atapci0: Intel ICH2 UDMA100 controller port 0x1f0-0x1f7,0x3f6,0x170-0x177,0x376,0xffa0-0xffaf at device 31.1 on pci0 ata0: ATA channel 0 on atapci0 ata1: ATA channel 1 on atapci0 pci0: serial bus, USB at device 31.2 (no driver attached) pci0: serial bus, SMBus at device 31.3 (no driver attached) pci0: serial bus, USB at device 31.4 (no driver attached) acpi_button0: Sleep Button on acpi0 atkbdc0: Keyboard controller (i8042) port 0x60,0x64 irq 1 on acpi0 atkbd0: AT Keyboard irq 1 on atkbdc0 atkbd0: [GIANT-LOCKED] sio0: 16550A-compatible COM port port 0x3f8-0x3ff irq 4 flags 0x10 on acpi0 sio0: type 16550A pmtimer0 on isa0 orm0: ISA Option ROMs at iomem 0xc-0xc9fff,0xcc000-0xccfff,0xcd000-0xcdfff,0xce000-0xd3fff on isa0 sc0: System console at flags 0x100 on isa0 sc0: VGA 16 virtual consoles, flags=0x300 sio1: configured irq 3 not in bitmap of probed irqs 0 sio1: port may not be enabled vga0: Generic ISA VGA at port 0x3c0-0x3df iomem 0xa-0xb on isa0 Timecounter TSC frequency 868640155 Hz quality 800 Timecounters tick every 1.000 msec ad2: 305245MB Seagate ST3320820A 3.AAC at ata1-master UDMA100 da0 at ahc0 bus 0 target 0 lun 0 da0: SEAGATE ST318437LW 0105 Fixed Direct Access SCSI-3 device da0: 40.000MB/s transfers (20.000MHz, offset 31, 16bit), Tagged Queueing Enabled da0: 17547MB (35937500 512 byte sectors: 255H 63S/T 2237C) da1 at ahc0 bus 0 target 1 lun 0 da1: SEAGATE ST318437LW 0105 Fixed Direct Access SCSI-3 device da1: 40.000MB/s transfers (20.000MHz, offset 31, 16bit), Tagged Queueing Enabled da1: 17547MB (35937500 512 byte sectors: 255H 63S/T 2237C) GEOM_MIRROR: Device os created (id=653370967). GEOM_MIRROR: Device os: provider da0 detected. GEOM_MIRROR: Device os: provider da1 detected. GEOM_MIRROR: Device os: provider da1 activated. GEOM_MIRROR: Device os: provider da0 activated. GEOM_MIRROR: Device os: provider
Re: RTC clock doesn't generate interrupts
On 2007-May-20 18:26:30 +0200, Victor Balada Diaz [EMAIL PROTECTED] wrote: I have a server with FreeBSD 6.2 that is not generating RTC IRQs. When the system boots everything it's working fine and I get 128 interrupts per second but after a few hours the system starts losing RTC interrupts. If I enable powerd it happens much faster than without it. The RTC has a feature that if you ever lose an RTC interrupt (because the interrupt handler wasn't called fast enough), you don't get any more interrupts because the RTC knows it has an interrupt pending and so doesn't generate any more interrupts. I have also bumped into this problem whilst trying to work around a problem with a TurionX2 CPU. I just got the correct fix to work and ignored the work-around. I did find that you can restart the RTC interrupts by setting machdep.adjkerntz (you can leave the value the same, it's the assignment that's important). Enabling powerd will reduce the CPU clock and so exacerbate any problem you have with excessive interrupt latency. I can't suggest what might be the underlying cause of that latency. -- Peter Jeremy pgp7zJhUvUNgt.pgp Description: PGP signature
Re: RTC clock doesn't generate interrupts
On Mon, May 21, 2007 at 05:11:23AM +1000, Peter Jeremy wrote: On 2007-May-20 18:26:30 +0200, Victor Balada Diaz [EMAIL PROTECTED] wrote: I have a server with FreeBSD 6.2 that is not generating RTC IRQs. When the system boots everything it's working fine and I get 128 interrupts per second but after a few hours the system starts losing RTC interrupts. If I enable powerd it happens much faster than without it. The RTC has a feature that if you ever lose an RTC interrupt (because the interrupt handler wasn't called fast enough), you don't get any more interrupts because the RTC knows it has an interrupt pending and so doesn't generate any more interrupts. I have also bumped into this problem whilst trying to work around a problem with a TurionX2 CPU. I just got the correct fix to work and ignored the work-around. I did find that you can restart the RTC interrupts by setting machdep.adjkerntz (you can leave the value the same, it's the assignment that's important). Thanks for your fast reply! I tried the machdep.adjkerntz trick and didn't work very well. If i'm on 0 irqs per second after changing the value i get 1 irq per second. If i'm on 20 i get 21, and so on. Do you know of any other workaround/patch that i can try? -- La prueba más fehaciente de que existe vida inteligente en otros planetas, es que no han intentado contactar con nosotros. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: RTC clock doesn't generate interrupts
In the last episode (May 20), Victor Balada Diaz said:
On Mon, May 21, 2007 at 05:11:23AM +1000, Peter Jeremy wrote:
On 2007-May-20 18:26:30 +0200, Victor Balada Diaz [EMAIL PROTECTED] wrote:
I have a server with FreeBSD 6.2 that is not generating RTC IRQs.
When the system boots everything it's working fine and I get 128
interrupts per second but after a few hours the system starts
losing RTC interrupts. If I enable powerd it happens much faster
than without it.
The RTC has a feature that if you ever lose an RTC interrupt
(because the interrupt handler wasn't called fast enough), you
don't get any more interrupts because the RTC knows it has an
interrupt pending and so doesn't generate any more interrupts.
I have also bumped into this problem whilst trying to work around a
problem with a TurionX2 CPU. I just got the correct fix to work
and ignored the work-around.
I did find that you can restart the RTC interrupts by setting
machdep.adjkerntz (you can leave the value the same, it's the
assignment that's important).
Thanks for your fast reply!
I tried the machdep.adjkerntz trick and didn't work very well.
If i'm on 0 irqs per second after changing the value i get 1
irq per second. If i'm on 20 i get 21, and so on.
Do you know of any other workaround/patch that i can try?
Here's what I use on a couple of Dell 2400's. I put it in cron to fire
every 5 minutes:
#! /bin/sh
# fixrtc - kick the RTC if it stops running
# get the interrupt rate for the stat clock over one second
getticks() {
( vmstat -i ; sleep 1 ; vmstat -i ) |
awk '/rtc/ { if (sum) sum+=$3; else sum-=$3 } END { print sum }'
}
ticks=$( getticks )
# It should be firing at 128 hz. If not, kick it
if [ $ticks -lt 64 ] ; then
echo Stat clock has died. Attempting to reset.
echo
/etc/rc.d/ntpd stop
echo
/usr/sbin/ntpdate -b pool.ntp.org
echo
/etc/rc.d/ntpd start
echo
echo RTC interrupt rate is now $(getticks)
fi
--
Dan Nelson
[EMAIL PROTECTED]
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to [EMAIL PROTECTED]
