linux-kernel - Re: [RESEND] Fast TSC calibration fails with v3.14-rc1 and later

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.DEB.2.02.1403121729060.18573@ionos.tec.linutronix.de>
Date:	Wed, 12 Mar 2014 17:39:15 +0100 (CET)
From:	Thomas Gleixner <tglx@...utronix.de>
To:	joeyli <jlee@...e.com>
cc:	"Rafael J. Wysocki" <rjw@...ysocki.net>,
	Julian Wollrath <jwollrath@....de>, x86@...nel.org,
	LKML <linux-kernel@...r.kernel.org>,
	"Rafael J. Wysocki" <rafael.j.wysocki@...el.com>,
	"H. Peter Anvin" <hpa@...or.com>
Subject: Re: [RESEND] Fast TSC calibration fails with v3.14-rc1 and later

On Wed, 12 Mar 2014, Thomas Gleixner wrote:
> On Wed, 12 Mar 2014, Thomas Gleixner wrote:
> 
> > On Wed, 12 Mar 2014, joeyli wrote:
> > > I think maybe still using ACPI_FADT_NO_CMOS_RTC to check does
> > > acpi_early_init() need run before timekeeping_init().
> > > If there have any future machine that applied ACPI TAD but "Fast TSC
> > > calibration" fail, at least the alternate TSC calibration can work
> > > around issue.
> > 
> > Well, it can work around, but it sucks as it's way slower than the
> > fast one. And we really don't want to pay that price for some half
> > baken ACPI nonsense.
> > 
> > Why exactly do you need that ACPI stuff before timekeeping_init()?
> 
> According to the changelog:
> 
>     And, we want accessing ACPI TAD device to set system clock, so move
>     acpi_early_init() before timekeeping_init(). This final position is
>     also before efi_enter_virtual_mode().
> 
> Why do we need to access that TAD thing (whatever newfangled that is)
> at this point?

And we have no support for that nonsense in tree, so why do we need to
disturb functionality which does not need that at all?

We can revisit the issue when we actually have reached a conclusion
how to deal with that and when we are merging something which supports
TAD.

Up to then we really can live without that and put the call just
before efi_enter_virtual_mode().

Even if the TAD stuff should be used to set system time, you can do so
way after timekeeping_init() when the proper driver is
installed. That's how a lot of embedded systems do it today simply
because they can't access the rtc that early.

There is no point to inflict this ACPI nonsense in early boot. It's
bad enough that we have to deal with it at all.

Thanks,

	tglx


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