linux-kernel - Re: [PATCH] enable readback to get HPET working on ATI SB4x00, kernel 2.6.35

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <alpine.LFD.2.00.1007142134140.3321@localhost.localdomain>
Date:	Wed, 14 Jul 2010 23:04:18 +0200 (CEST)
From:	Thomas Gleixner <tglx@...utronix.de>
To:	Borislav Petkov <borislav.petkov@....com>
cc:	Linus Torvalds <torvalds@...ux-foundation.org>,
	Stephan Wolf <stephan@...zte-bankreihe.de>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	"Herrmann3, Andreas" <Andreas.Herrmann3@....com>
Subject: Re: [PATCH] enable readback to get HPET working on ATI SB4x00, kernel
 2.6.35_rc5

On Wed, 14 Jul 2010, Borislav Petkov wrote:

> From: Linus Torvalds <torvalds@...ux-foundation.org>
> Date: Wed, Jul 14, 2010 at 02:17:27PM -0400
> 
> > > I'll try to find out which chipsets are actually affected but in the
> > > meantime we might want to do a temporary fix by enabling the readback
> > > back(!) on all ATI chipsets so that we don't uncover anymore bugs like
> > > the one above, hmmm?
> > 
> > That sounds like the right solution for now, yes.  Rather than make
> > the readback quirk depend on one particular SMBUS revision, make it
> > happen unconditionally for an AMD northbridge (or is the HPET in the
> > SB?
> 
> Yeah, its in the southbridge which is part of the chipset. Actually
> we'll have to somehow match ATI chipsets only since we have also nVidia
> chipsets with AMD cpus in them.
> 
> /me goes to meditate a little about it.
> 
> > I forget - somebody who knows the details and can test it on a
> > machine or two should do the actual patch).
> 
> I'll try to cook up something unless someone beats me to it.

The patch below works on my collection of ATI chipset based machines.

Stefan, does it solve your problem too ?

Thanks,

	tglx
-----

Subject: x86-ati-chipsets-hpet-force-readback.patch
From: Thomas Gleixner <tglx@...utronix.de>
Date: Wed, 14 Jul 2010 21:36:27 +0200

Signed-off-by: Thomas Gleixner <tglx@...utronix.de>
Index: linux-2.6/arch/x86/kernel/early-quirks.c
===================================================================
--- linux-2.6.orig/arch/x86/kernel/early-quirks.c
+++ linux-2.6/arch/x86/kernel/early-quirks.c
@@ -18,6 +18,7 @@
 #include <asm/apic.h>
 #include <asm/iommu.h>
 #include <asm/gart.h>
+#include <asm/hpet.h>
 
 static void __init fix_hypertransport_config(int num, int slot, int func)
 {
@@ -191,6 +192,21 @@ static void __init ati_bugs_contd(int nu
 }
 #endif
 
+/*
+ * Force the read back of the CMP register in hpet_next_event()
+ * to work around the problem that the CMP register write seems to be
+ * delayed. See hpet_next_event() for details.
+ *
+ * We do this on all SMBUS incarnations for now until we have more
+ * information about the affected chipsets.
+ */
+static void __init ati_hpet_bugs(int num, int slot, int func)
+{
+#ifdef CONFIG_HPET_TIMER
+	hpet_readback_cmp = 1;
+#endif
+}
+
 #define QFLAG_APPLY_ONCE 	0x1
 #define QFLAG_APPLIED		0x2
 #define QFLAG_DONE		(QFLAG_APPLY_ONCE|QFLAG_APPLIED)
@@ -220,6 +236,8 @@ static struct chipset early_qrk[] __init
 	  PCI_CLASS_SERIAL_SMBUS, PCI_ANY_ID, 0, ati_bugs },
 	{ PCI_VENDOR_ID_ATI, PCI_DEVICE_ID_ATI_SBX00_SMBUS,
 	  PCI_CLASS_SERIAL_SMBUS, PCI_ANY_ID, 0, ati_bugs_contd },
+	{ PCI_VENDOR_ID_ATI, PCI_ANY_ID,
+	  PCI_CLASS_SERIAL_SMBUS, PCI_ANY_ID, 0, ati_hpet_bugs },
 	{}
 };
 
Index: linux-2.6/arch/x86/kernel/quirks.c
===================================================================
--- linux-2.6.orig/arch/x86/kernel/quirks.c
+++ linux-2.6/arch/x86/kernel/quirks.c
@@ -498,15 +498,10 @@ void force_hpet_resume(void)
  * See erratum #27 (Misinterpreted MSI Requests May Result in
  * Corrupted LPC DMA Data) in AMD Publication #46837,
  * "SB700 Family Product Errata", Rev. 1.0, March 2010.
- *
- * Also force the read back of the CMP register in hpet_next_event()
- * to work around the problem that the CMP register write seems to be
- * delayed. See hpet_next_event() for details.
  */
 static void force_disable_hpet_msi(struct pci_dev *unused)
 {
 	hpet_msi_disable = 1;
-	hpet_readback_cmp = 1;
 }
 
 DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_ATI, PCI_DEVICE_ID_ATI_SBX00_SMBUS,
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/