* Annoying timer problems with via boards
@ 2002-04-08 6:06 Andreas Hartmann
2002-04-23 19:53 ` george anzinger
0 siblings, 1 reply; 2+ messages in thread
From: Andreas Hartmann @ 2002-04-08 6:06 UTC (permalink / raw)
To: linux-kernel
Hello all,
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
^ permalink raw reply [flat|nested] 2+ messages in thread* Re: Annoying timer problems with via boards
2002-04-08 6:06 Annoying timer problems with via boards Andreas Hartmann
@ 2002-04-23 19:53 ` george anzinger
0 siblings, 0 replies; 2+ messages in thread
From: george anzinger @ 2002-04-23 19:53 UTC (permalink / raw)
To: Andreas Hartmann; +Cc: linux-kernel
Andreas Hartmann wrote:
>
> Hello all,
>
> 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?
If the below patch did not fix the problem the one above will not help
either. They both do the same thing, its just that the one above whines
about it.
Both of these fixes depend on the PIT failing by a) generating the
normal interrupt AND b) not properly resetting the internal counter.
This can be deduced from the patch. It is unknown if the PIT then
interrupts when the counter next rolls. If it did, and if it continued
to use the full count instead of the programmed LATCH value, the timer
interrupts would be about 50 ms apart, so time would slow to 1/5 the
actual rate.
Any help on this issue would be welcome...
George
>
> 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/
--
George Anzinger george@mvista.com
High-res-timers: http://sourceforge.net/projects/high-res-timers/
Real time sched: http://sourceforge.net/projects/rtsched/
Preemption patch: http://www.kernel.org/pub/linux/kernel/people/rml
^ permalink raw reply [flat|nested] 2+ messages in thread
end of thread, other threads:[~2002-04-23 19:55 UTC | newest]
Thread overview: 2+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2002-04-08 6:06 Annoying timer problems with via boards Andreas Hartmann
2002-04-23 19:53 ` george anzinger
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox