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] [day] [month] [year] [list]
Message-ID: <87iq23i2vp.fsf@spindle.srvr.nix>
Date:	Sat, 18 Sep 2010 14:43:06 +0100
From:	Nix <nix@...eri.org.uk>
To:	Damien Wyart <damien.wyart@...e.fr>
Cc:	Thomas Gleixner <tglx@...utronix.de>,
	LKML <linux-kernel@...r.kernel.org>, Ingo Molnar <mingo@...e.hu>,
	"H. Peter Anvin" <hpa@...or.com>,
	Artur Skawina <art.08.09@...il.com>,
	John Drescher <drescherjm@...il.com>,
	Venkatesh Pallipadi <venki@...gle.com>,
	Arjan van de Ven <arjan@...ux.intel.com>,
	Andreas Herrmann <andreas.herrmann3@....com>,
	Borislav Petkov <borislav.petkov@....com>,
	Suresh Siddha <suresh.b.siddha@...el.com>
Subject: Re: [PATCH RFC] x86: hpet: Avoid the readback penalty

On 18 Sep 2010, Damien Wyart uttered the following:

> * Thomas Gleixner <tglx@...utronix.de> [2010-09-15 15:11]:
>> > x86: hpet: Work around hardware stupidity
>
>> After my brain recovered from yesterdays exposure with the x86 timer
>> horror, I came up with a different solution for this problem, which
>> avoids the readback of the compare register completely. It works
>> nicely on my affected ATI system, but needs some exposure to the other
>> machines.
>
> Comments for this different solution seemed fine, but it seems only the
> first one was commited into mainline and then stable. Is this intended?

I assumed he was letting people shake the bugs out rather than inflict
what is basically just a performance improvement on -stable. For the
record: no bugs here. I also know why one of my machines was unaffected,
and it provides even more confirmation that this bug is correctly
identified, as if we needed more. It's not using the HPET at all:

Clock Event Device: cs5535-clockevt

Every single machine I owned with an HPET was affected by this bug: they
all work perfectly well now.
--
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/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ