I've been playing with different HZ values in the 2.4 kernel for a while
now, and apparantly Linus also has decided to introduce a USER_HZ
constant (I used CLOCKS_PER_SEC) while raising the HZ value on x86 to
1000.

On x86 timekeeping has shown to be relative fragile when raising HZ (OK,
I tried HZ=2048 which is quite high) because of the way the interrupt
timer is configured to fire HZ times each second.  This is done by
configuring a divisor in the timer chip (LATCH) which divides a certain
clock (1193180) and makes the chip fire interrupts at the resulting
frequency.

Now comes the catch: NTP requires a clock accuracy of 500 ppm.  For some
HZ values the clock is not accurate enough to meet this requirement,
hence NTP won't work well.

An example HZ value is 1020 which exceeds the 500 ppm requirement.  In
this case the best approximation is 1019.8 Hz.  the xtime.tv_usec value
is raised with a value of 980 each tick which means that after one
second the tv_usec value has increased with 999404 (should be 1000000)
which is an accuracy of 596 ppm.

Some more examples:
	  HZ Accuracy (ppm)
	---- --------------
	 100             17
	1000            151
	1024            632
	2000            687
	2008            343
	2011             18
	2048           1249

What I've been doing is replace tv_usec by tv_nsec, meaning xtime is now
a timespec instead of a timeval.  This allows the accuracy to be
improved by a factor of 1000 for any (well ...  any?) HZ value. 

Of course all kinds of calculations had te be improved as well.  The
ACTHZ constantant is introduced to approximate the actual HZ value, it's
used to do some approximations of other related values. 

Cset exclude: greg@kroah.com|ChangeSet|20020905153320|19047

into penguin.transmeta.com:/home/penguin/torvalds/repositories/kernel/linux

into penguin.transmeta.com:/home/penguin/torvalds/repositories/kernel/linux

into penguin.transmeta.com:/home/penguin/torvalds/repositories/kernel/linux

into groveronline.com:/root/bk/linux-acpi

during the initcall sequence, after all CPUs have been brought up. 
mtrr_init() calls a static init_other_cpus(), which fires off a function 
on all other cpus to replicate the state across all of them. 

arch/i386/kernel/smpboot.c::smp_callin() had the following: 

#ifdef CONFIG_MTRR
       /*
        * Must be done before calibration delay is computed
        */
       mtrr_init_secondary_cpu ();
#endif


I couldn't figure this one out. The P4 manual says nothing about this, nor
find any other documentation about it. The P4 manual says only that state
must be synchronized across all CPUs, which it is. And, it happens before
anything else is executed on the other CPUs, and before any devices or
drivers have been brought up.

The cyrix mtrr code was also updated to handle this style of SMP initialization.

into penguin.transmeta.com:/home/penguin/torvalds/repositories/kernel/linux

- The early startup code was changed so smp_prepare_cpus() is now called
  before do_basic_setup().  do_basic_setup() is where mtrr_init() is
  called, which mtrr_init_secondary_cpu() is dependent on being called.

- mtrr_init_boot_cpu() was removed from the AP startup code. This was a
  SMP-only hack that made sure mtrr_init() happened when SMP was
  enabled.  That's right - two different code paths to do the same
  thing, obscured by compile-time defines.

The appended patch makes sure mtrr_init() is called before
smp_prepare_cpus(). It's ugly, and I'll work on a cleaner solution, but
James: could you try it and see if it fixes your performance issues?

  Documentation/porting: s/are/and/
  Documentation/directory-locking: s/that means// was repeated

When recalc_sigpending was converted from inline to real function,
appropriate EXPORT_SYMBOL() was not created.  Needed at least for ncpfs
and lockd.

Update kernel-api.tmpl to reflect mtrr changes so that the docs will build.

The pci_bus_* functions should be used instead.

- fix polling logic
- add ability to write [chassis/rxe]#slot# instead of just slot#

into groveronline.com:/root/bk/linux-acpi

- removed pci_announce_device_to_drivers() prototype as the function is long gone
- always call /sbin/hotplug when pci devices are added to the system if
  so configured (this includes during the system bring up.)

I added a bug in 2.5.23 when cleaning up something that
was broken ... it wasn't broken in quite the way I had
thought at the time!

This fixes a problem some folk have reported recently
with ISO-IN, by masking a common non-error outcome.

Please merge to Linus' tree, on top of the one patch
you already have queued.  Thanks to Nemosoft for such
quick turnaround on testing!

This patch fixes a problem with big endian machines and scanner drivers which
use the SCANNER_IOCTL_CTRLMSG ioctl. The big endian to little endian swap was
done twice, resulting in a no-op.

Also, have you sent in the one-line fix I found for the abort bug?
Andries found that it cured his BUG_ON problem.  In case you didn't save a
copy of it, I've included it below.

Somewhere around 2.5.31 the method for setting and clearing interrupts
changed:

From-                     To-
save_flags(flags);        local_irq_save(flags);
cli();

restore_flags(flags);     local_irq_restore(flags);


Though bordering on trivial, including toshiba support with stock 2.5.34
fails to compile, which this patch seems to fix. This patch fixes this
issue and has worked reliably for me under 2.5.31, though it is untested on
2.5.32 and 2.5.33 because I didn't manage to get those to work.

A note to those that are a bit rough on kernel patch newbies.... submitting
a kernel patch for the very first time is a rather intimidating experience
so please don't chew my head off unless its absolutely necessary.

See my point? I was so worried that Cristoph Hellwig is going to come to
my house and eat me I forgot to include the patch itself. :)

into kroah.com:/home/greg/linux/BK/gregkh-2.5

into kroah.com:/home/greg/linux/BK/gregkh-2.5

into home.transmeta.com:/home/torvalds/v2.5/linux

This avoids a crash that can be caused by a CLONE_DETACHED thread.

There are 4 different scenarios of late boot:

1.	no initrd or ROOT_DEV is ram0.  That's the simplest one - we want
	whatever is on ROOT_DEV as final root.

2.	initrd is there, ROOT_DEV is not ram0, /linuxrc on initrd doesn't
	exit.   We want initrd mounted, /linuxrc launched and /linuxrc
	will mount whatever it wants, maybe do pivot_root and exec init
	itself.  Task with PID 1 (parent of linuxrc) will sit there reaping
	zombies, never leaving the kernel mode.

3.	initrd is there, ROOT_DEV is not ram0, /linuxrc on initrd does exit
	and sets real-root-dev to 256 (1:0, aka. ram0).   We want initrd
	mounted, /linuxrc launched and we expect linuxrc to mount all stuff
	we need, maybe do pivot root and exit.  Parent of /linuxrc (PID 1)
	will proceed to exec init once /linuxrc is done.

4.	initrd is there, ROOT_DEV is not ram0, /linuxrc on initrd might have
	done something or not, but when it exits real-root-dev is not ram0.
	We want initrd mounted, /linuxrc launched and when it exits we are
	going to mount final root according to real-root-dev.  If there is
	/initrd on the final root, initrd will be moved there.  Otherwise
	initrd will be unmounted and its memory (if possible) freed.  Then
	we exec init from final root.

Note that we want the parent of linuxrc chrooted to initrd while linuxrc
runs - otherwise things like request_module() will be rather unhappy.  That
goes for all variants that run linuxrc.

Scenarios above go in order of increasing complexity.  Let's start with #4:

	we had loaded initrd
	we mount initrd on /root
	we open / and /old (on initrd)
	chdir /root
	mount -- move . /
	chroot .

Now we have initrd mounted on /, we are chrooted into it but keep opened
descriptors of / and /old, so we'll be able to break out of jail later.

	we fork a child that will be linuxrc
	child closes opened descriptors, opens /dev/console, dups it to stdout
and stderr, does setsid and execs /linuxrc.

	parent sits there reaping zombies until child is finished.

Note that both parent and linuxrc are chrooted into /initrd and if linuxrc
calls pivot_root, the parent will also have its root/cwd switched.

	OK, child is finished and after checking real_root_dev we see that
it's not MKDEV(1,0).  Now we know that it's scenario #4.
We break out of jail, doing the following:

	fchdir to /old on rootfs
	mount --move / .
	fchdir to / on rootfs
	chroot to .

That will move initrd to /old and leave us with root and cwd in / of rootfs.
We can close these two descriptors now - they'd done their job.

	We mount final root to /root
	We attempt to mount -- move /old /root/initrd; if we are successful -
we chdir to /root, mount --move . / and chroot to .  That will leave us with
	* final root on /
	* initrd on /initrd of final root
	* cwd and root on final root.

At that point we simply exec init.

	Now, if mount --move had failed, we got to clean up the mess.  We
unmount (with MNT_DETACH) initrd from /old and do BLKFLSBUF on ram0.  After
that we have final root on /root, initrd maybe still alive, but not mounted
anywhere and our root/cwd in / of rootfs.  Again,

	chdir /root
	mount --move . /
	chroot to .

and we have final root mounted on /, we are chrooted into it and it's time
for exec init.

	That's it for scenario 4.  The rest will be simpler - there's less
work to do.

#3 diverges from #4 after linuxrc had finished and we had already broken out
of jail.  Whatever we got from linuxrc is mounted on /old now, so we move it
back to /, get chrooted there and exec init.   We could've left earlier
(skipping the move to /old and move back parts), but that would lead to
even messier logics in prepare_namespace() ;-/

#2 means that parent of /linuxrc never gets past waiting its child to finish.
End of story.

#1 is the simplest variant - it mounts final root on /root and then does usual
"chdir there, mount --move . /, chroot to ." and execs init.

Relevant code is in prepare_namespace()/handle_initrd() and yes, it's messy.
Had been even worse... ;-/

CONFIG_M386 kernel running on PPro+ processor with X86_FEATURE_PGE may
set _PAGE_GLOBAL bit: then __flush_tlb_one must use invlpg instruction.
H. J. Lu reports (LKML 8 Sept) that his P4 reboots due to this problem.

This fixes the bootup crash.  There were two initialization bugs:

	- INIT_SIGNAL needs to set shared_pending.

	- exec() needs to set up newsig properly.

the second one caused the crash Anton saw.

This patch uses the atomic copy_from_user() facility in
generic_file_write().

This required a change in the prepare_write/commit_write API
definition.  It is no longer the case that these functions will kmap
the page for you.

If any part of the kernel wants to get at the page in the write path,
it now has to kmap it for itself.  The best way to do this is with
kmap_atomic(KM_USER0).

This patch updates all callers.  It also converts several places which
were unnecessarily using kmap() over to using kmap_atomic().

The reiserfs changes here are Oleg Drokin's revised version.

The patch has been tested with loop, ext2, ext3, reiserfs, jfs,
minixfs, vfat, iso9660, nfs and the ramdisk driver.

I haven't fixed the racy deadlock avoidance thing in
generic_file_write() - the case where we take a fault when the source
and dest of the copy are both the same pagecache page.

There is a printk in there now which will trigger if the page was
unexpectedly not present.  And guess what?  I get 50-100 of them when
running `dbench 64' on mem=48m.   This deadlock can happen.

This patch allows the kernel to hold atomic kmaps in file_read_actor().

We try to fault in the page, then take an atomic kmap.  If the atomic
copy_to_user() then faults, drop a printk and fall back to kmap().