linux-kernel - Re: + clocksource-increase-initcall-priority.patch added to -mm tree

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: <1160340722.5686.85.camel@localhost.localdomain>
Date:	Sun, 08 Oct 2006 22:52:02 +0200
From:	Thomas Gleixner <tglx@...utronix.de>
To:	Daniel Walker <dwalker@...sta.com>
Cc:	akpm@...l.org, johnstul@...ibm.com, mingo@...e.hu,
	zippel@...ux-m68k.org, LKML <linux-kernel@...r.kernel.org>
Subject: Re: + clocksource-increase-initcall-priority.patch added to -mm
	tree

On Sun, 2006-10-08 at 13:39 -0700, Daniel Walker wrote:
> > The reason why this was delayed into late boot is simply that the
> > unstable, unsynchronized TSC's made way too much trouble and the pmtimer
> > can not be initialized early.
> > 
> > I'm not going to accept that. Your change might work on 5 machines you
> > have tested on, but we start over with the same breakage we solved
> > already. 
> 
> Your going to have to explain the breakage further. I don't recall
> seeing any discussion on this.

See above, but I'm happy to copy it.
> > The reason why this was delayed into late boot is simply that the
> > unstable, unsynchronized TSC's made way too much trouble and the pmtimer
> > can not be initialized early.

I don't have the bug reports handy, but they are in the LKML archives.

> > This early boot instrumentation code can work with low resolution time
> > information quite well and none of the boot code does need any high res
> > time information. Boot code is different from a running system and has
> > different requirements. 
> > 
> > This is a solution for a nonexisting problem, which just brings back
> > already solved ones.
> 
> There is at least one existing problem which it does solve. 

Which one exactly? I'm not aware of a problem with the existing code at
all.

> How about we
> discuss the early TSC boot breakage, which you mention above, so I can
> properly fix this situation.

See above. Also it interferes probably with the highres/dyntick code, as
we might switch over way too early. Have not looked into that yet.

	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/