mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
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;

  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®