On Tue, 2006-09-12 at 17:44 +0100, David Woodhouse wrote:
> asm-x86_64/elf.h requires asm/processor.h, which does not exist
> asm-x86_64/signal.h requires linux/linkage.h, which does not exist
> asm-x86_64/unistd.h requires linux/linkage.h, which does not exist
> asm-x86_64/vsyscall.h requires linux/seqlock.h, which does not exist
Again, move stuff which shouldn't be visible inside (mostly already existing)
#ifdef __KERNEL__.
This fixes a bunch of mislabelled and unlabelled #endifs in unistd.h and also
cleans that up to conform with what's visible on other architectures, since
the minimal fix for the error reported about would have involved a more
intrusive patch, renesting other ifdefs.
Signed-off-by: David Woodhouse <dwmw2@infradead.org>
Cc: Sam Ravnborg <sam@ravnborg.org>
Cc: Andi Kleen <ak@suse.de>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
There are unfortunately more and more multi processor Opteron systems which
don't have HPET timer support in the southbridge. This covers in particular
Nvidia and VIA chipsets. They also don't guarantee that the TSCs are
synchronized between CPUs; and especially with MP powernow the systems are
nearly unusable because the time gets very inconsistent between CPUs.
The timer code for x86-64 was originally written under the assumption that we
could fall back to the HPET timer on such systems. But this doesn't work
there.
Another alternative is to use the ACPI PM timer as primary time source. This
patch does that. The kernel only uses PM timer when there is no other choice
because it has some disadvantages.
Ported over from i386. It should be faster than the i386 version because I
dropped the "read three times" workaround, but is still considerable slower
than HPET and also does not work together with vsyscalls which have to be
disabled.
Cc: <mark.langsdorf@amd.com>
Signed-off-by: Andi Kleen <ak@suse.de>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
Initial git repository build. I'm not bothering with the full history,
even though we have it. We can create a separate "historical" git
archive of that later if we want to, and in the meantime it's about
3.2GB when imported into git - space that would just make the early
git days unnecessarily complicated, when we don't have a lot of good
infrastructure for it.
Let it rip!
