linux-kernel - Re: [PATCH] x86: enable hpet=force for AMD SB400

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:	Tue, 24 Jun 2008 18:00:41 +0200
From:	Andreas Herrmann <andreas.herrmann3@....com>
To:	Thomas Gleixner <tglx@...utronix.de>
CC:	Alistair John Strachan <alistair@...zero.co.uk>,
	Andrew Morton <akpm@...ux-foundation.org>, mingo@...e.hu,
	hpa@...or.com, linux-kernel@...r.kernel.org
Subject: Re: [PATCH] x86: enable hpet=force for AMD SB400

On Sun, May 11, 2008 at 11:03:16AM +0200, Thomas Gleixner wrote:
> On Sun, 11 May 2008, Alistair John Strachan wrote:
> > > Well we don't have to auto-enable the hpet.  Simply adding a loud "you
> > > should try the hpet=force option" printk would help a lot of people.
> > 
> > I'm a bit confused about the policy here: if we look at the Intel chipset 
> > overrides for HPET, they conditionally enable the HPET _without_ the 
> > hpet=force option if you have a chipset on the whitelist.
> > 
> > If Intel can do this on their chipsets, why is this not being done for the ATI 
> > chipsets for which (presumably) AMD have specs?
> 
> Well, we have no confirmation for the correctness of the non Intel
> quirks so far. I'm happy to move them into unconditional mode once
> AMD/ATI/NVidia tell us that the HPET is indeed discoverable this way.
>  
> > One thing I'd considered was that HPET isn't actually used very often on Intel 
> > chipsets because on most recent Intel CPUs the TSC is stable, but I think 
> 
> Well, stable except for the C-States. We still need a backup clock
> source as TSC is stopping in C3.
> 
> > either the Intel quirk should be consistent with the hpet=force usage, 
> > or "known correct" HPET overrides should just always be applied.
> 
> That's what we do. We have "known correct" for Intel and those which
> work on the patch submitters box w/o confirmation of the
> correctness. I guess the SB400 one can move into the "is correct"
> category, Andreas ???

Sorry for the late reply, but I had to look for the spec in the first
place ;-) and I have done some coding and testing since then.
(Well, the patch was written as a quick hack to get HPET working on my
private laptop.)

The point is that at least some revisions of IXP400/IXP450 have indeed
hardware issues regarding HPET. Thus HPET works only for certain
chip revisions.

Currently I am internally discussing whether it makes sense to enable
(and properly configure) HPET for those chipset revisions.

BTW, if outcome of this discussion is that HPET on IXP400/IXP450
shouldn't be used then IMHO a quirk is needed to reliably disable it.
I.e. disable it even if a system provides an ACPI HPET table.

Thanks for your patience.


Regards,

Andreas


--
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/