Unfortunately the timer problem isn't fixed and I know other persons having
this problem, too.
We found another patch for kernel 2.4.15 at
http://www.uwsg.iu.edu/hypermail/linux/kernel/0111.1/0951.html
Unfortunately this patch doesn't fit to kernel 2.4.18. Could somebody
please adopt it to the actual kernel for testing? Or could somebody please
find a better solution?
Sometime ago, I tested this patch, which didn't help:
--- linux-2.4.15-pre3/arch/i386/kernel/time.c Sun Nov 11 21:33:31 2001
+++ linux-2.4.15-pre3-new/arch/i386/kernel/time.c Mon Nov 12 14:04:20 2001
@@ -501,6 +501,19 @@
count = inb_p(0x40); /* read the latched count */
count |= inb(0x40) << 8;
+
+ /*
+ * When using some via chipsets (as the vt82c686a, for example)
+ * the system timer counter (i8253) should be reprogrammed in
+ * this case, otherwise it may be reset to a wrong value.
+ */
+ if (count > LATCH-1) {
+ outb_p(0x34, 0x43);
+ outb_p(LATCH & 0xff, 0x40);
+ outb(LATCH >> 8, 0x40);
+ count = LATCH - 1;
+ }
+
spin_unlock(&i8253_lock);
count = ((LATCH-1) - count) * TICK_SIZE;
------------------------------------------------------------------------------------
http://www.uwsg.iu.edu/hypermail/linux/kernel/0111.1/0951.html is:
diff -urN linux-2.4.15-pre4/arch/i386/kernel/time.c
linux/arch/i386/kernel/time.c
--- linux-2.4.15-pre4/arch/i386/kernel/time.c Mon Nov 12 22:31:52 2001
+++ linux/arch/i386/kernel/time.c Mon Nov 12 22:52:25 2001
@@ -112,6 +112,50 @@
return delay_at_last_interrupt + edx;
}
+/*
+ * VIA hardware bug workaround with check if it is really needed and
+ * a printk that could tell us what's exactly happening on machines which
+ * trigger the check, but are not VIA-based.
+ *
+ * Must be called with the i8253_spinlock held.
+ */
+
+static void via_reset_and_whine(int *count)
+{
+ static unsigned long last_whine = 0;
+ unsigned long new_whine;
+ int count2;
+
+ new_whine = last_whine;
+
+ outb_p(0x00, 0x43); /* Re-read the timer */
+ count2 = inb_p(0x40);
+ count2 |= inb(0x40) << 8;
+
+ if (time_after(jiffies, last_whine)) {
+ printk(KERN_WARNING "timer.c: VIA bug check triggered. "
+ "Value read %d [%#x], re-read %d [%#x]\n",
+ *count, *count, count2, count2);
+ new_whine = jiffies + HZ;
+ }
+
+ *count = count2;
+
+ if (count2 > LATCH) { /* Still bad */
+ if (time_after(jiffies, last_whine)) {
+ printk(KERN_WARNING "timer.c VIA bug really
present. "
+ "Resetting PIT timer.\n");
+ new_whine = jiffies + HZ;
+ }
+ outb_p(0x34, 0x43);
+ outb_p(LATCH & 0xff, 0x40);
+ outb(LATCH >> 8, 0x40);
+ *count = LATCH - 1;
+ }
+
+ last_whine = new_whine;
+}
+
#define TICK_SIZE tick
spinlock_t i8253_lock = SPIN_LOCK_UNLOCKED;
@@ -180,12 +224,8 @@
count |= inb_p(0x40) << 8;
/* VIA686a test code... reset the latch if count > max + 1 */
- if (count > LATCH) {
- outb_p(0x34, 0x43);
- outb_p(LATCH & 0xff, 0x40);
- outb(LATCH >> 8, 0x40);
- count = LATCH - 1;
- }
+ if (count > LATCH)
+ via_reset_and_whine(&count);
spin_unlock(&i8253_lock);
@@ -501,6 +541,10 @@
count = inb_p(0x40); /* read the latched count */
count |= inb(0x40) << 8;
+
+ if (count > LATCH)
+ via_reset_and_whine(&count);
+
spin_unlock(&i8253_lock);
count = ((LATCH-1) - count) * TICK_SIZE;
-----------------------------------------------------------------------------
I hope, that this patch could help and I'd like to test it with kernel
2.4.18.
The problem is very annoying and should really be solved. I have to reboot
all few hours because of crazy programms according to suddenly changing
time.
lspci says about my hardware:
00:00.0 Host bridge: VIA Technologies, Inc. VT8371 [KX133] (rev 02)
Flags: bus master, medium devsel, latency 0
Memory at d6000000 (32-bit, prefetchable) [size=32M]
Capabilities: [a0] AGP version 2.0
00:01.0 PCI bridge: VIA Technologies, Inc. VT8371 [PCI-PCI Bridge] (prog-if
00 [Normal decode])
Flags: bus master, 66Mhz, medium devsel, latency 0
Bus: primary=00, secondary=01, subordinate=01, sec-latency=0
I/O behind bridge: 0000c000-0000cfff
Memory behind bridge: d4000000-d5ffffff
Prefetchable memory behind bridge: d0000000-d3ffffff
Capabilities: [80] Power Management version 2
00:07.0 ISA bridge: VIA Technologies, Inc. VT82C686 [Apollo Super] (rev 22)
Subsystem: VIA Technologies, Inc. VT82C686/A PCI to ISA Bridge
Flags: bus master, stepping, medium devsel, latency 0
00:07.1 IDE interface: VIA Technologies, Inc. VT82C586 IDE [Apollo] (rev
10) (prog-if 8a [Master SecP PriP])
Flags: bus master, medium devsel, latency 32
I/O ports at d000 [size=16]
Capabilities: [c0] Power Management version 2
00:07.2 USB Controller: VIA Technologies, Inc. VT82C586B USB (rev 10)
(prog-if 00 [UHCI])
Subsystem: Unknown device 0925:1234
Flags: bus master, medium devsel, latency 32, IRQ 9
I/O ports at d400 [size=32]
Capabilities: [80] Power Management version 2
00:07.4 Host bridge: VIA Technologies, Inc. VT82C686 [Apollo Super ACPI]
(rev 30)
Flags: medium devsel, IRQ 9
Capabilities: [68] Power Management version 2
00:07.5 Multimedia audio controller: VIA Technologies, Inc. VT82C686
[Apollo Super AC97/Audio] (rev 20)
Subsystem: VIA Technologies, Inc.: Unknown device 4511
Flags: medium devsel, IRQ 7
I/O ports at dc00 [size=256]
I/O ports at e000 [size=4]
I/O ports at e400 [size=4]
Capabilities: [c0] Power Management version 2
[...]
Regards,
Andreas Hartmann
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/