From: Vojtech Pavlik <vojtech@suse.cz>
To: Alan Cox <alan@lxorguk.ukuu.org.uk>
Cc: Neale Banks <neale@lowendale.com.au>,
Jeronimo Pellegrini <pellegrini@mpcnet.com.br>,
Nils Philippsen <nils@wombat.dialup.fht-esslingen.de>,
linux-kernel@vger.kernel.org
Subject: Re: [PATCH] VIA timer fix was removed?
Date: Mon, 12 Nov 2001 22:58:32 +0100 [thread overview]
Message-ID: <20011112225832.A19107@suse.cz> (raw)
In-Reply-To: <Pine.LNX.4.05.10111130821580.3768-200000@marina.lowendale.com.au> <E163Og3-0007Aw-00@the-village.bc.nu>
In-Reply-To: <E163Og3-0007Aw-00@the-village.bc.nu>; from alan@lxorguk.ukuu.org.uk on Mon, Nov 12, 2001 at 09:31:35PM +0000
[-- Attachment #1: Type: text/plain, Size: 1218 bytes --]
On Mon, Nov 12, 2001 at 09:31:35PM +0000, Alan Cox wrote:
> > Attached (untested) patch against 21.2.20 (which still has the $SUBJECT
> > code) should implement timer=no-via686a option to disable this. Hopefully
> > I'll get it tested in the next day or two.
>
> This isnt the real problem - we are seeing it triggered by cases we dont
> underatand that seem to be software. We need to find those
I don't think it's software. At least it's definitely not locking. It's
happening on machines where none of the drivers missing the locks are
used (only ftape and analog joystick).
I think it's the old Neptune bug biting us again. I'd like to verify
this theory - do you have any list of people who've seen the VIA bugfix
triggered on non-VIA hardware? Some might be willing to test
experimental patches ...
... like the one attached. It doesn't add anything that already hasn't
been there, but:
1) Should be safe for machines that have
a different bug than VIA. It'll print a message
but won't reset the timer if the > LATCH reading
isn't persistent.
2) Should printk enough data to shed some light
on what is triggering the VIA check.
Patch against 2.4.15-pre4.
--
Vojtech Pavlik
SuSE Labs
[-- Attachment #2: new-via-check.diff --]
[-- Type: text/plain, Size: 2113 bytes --]
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;
next prev parent reply other threads:[~2001-11-12 21:59 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2001-11-12 13:14 Jeronimo Pellegrini
2001-11-12 14:48 ` Andrzej Krzysztofowicz
2001-11-12 16:05 ` Jeronimo Pellegrini
2001-11-12 18:49 ` Nils Philippsen
2001-11-12 19:00 ` Jeronimo Pellegrini
2001-11-12 21:27 ` Neale Banks
2001-11-12 21:31 ` Alan Cox
2001-11-12 21:58 ` Vojtech Pavlik [this message]
2001-11-12 21:59 ` Neale Banks
2001-11-12 22:43 ` Alan Cox
2001-11-12 19:21 ` Nils Philippsen
[not found] <20011119182927.A19179@suse.cz>
2002-04-08 6:33 ` Neale Banks
2002-04-08 7:24 ` Vojtech Pavlik
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20011112225832.A19107@suse.cz \
--to=vojtech@suse.cz \
--cc=alan@lxorguk.ukuu.org.uk \
--cc=linux-kernel@vger.kernel.org \
--cc=neale@lowendale.com.au \
--cc=nils@wombat.dialup.fht-esslingen.de \
--cc=pellegrini@mpcnet.com.br \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®