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]

Date:	Thu, 15 Jul 2010 09:06:13 +0200
From:	Stephan Wolf <stephan@...zte-bankreihe.de>
To:	Thomas Gleixner <tglx@...utronix.de>
CC:	Borislav Petkov <borislav.petkov@....com>,
	Linus Torvalds <torvalds@...ux-foundation.org>,
	"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

Am 14.07.2010 23:04, schrieb Thomas Gleixner:
> 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,
>    

Hi, the patch above solves the problem on my machine.

Thanks,
Stephan
--
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/