[Linux-ia64] Re: kernel update (relative to 2.4.4)

[Bill Nottingham <notting@redhat.com>]

David Mosberger (davidm@hpl.hp.com) said: 
> The latest IA-64 patch is (finally) available at:
> 
>  ftp://ftp.kernel.org/pub/linux/kernel/ports/ia64/
> 
> in file linux-2.4.4-ia64-010508.diff*.  Thanks to Johannes Erdfelt,
> USB is working again and I hope this kernel will be quite stable for
> everybody (famous last words...).

Any chance that more of this stuff that hasn't been merged into
the main tree in the past will get merged (460GX agpgart, EFI GUID
partition tables, etc)?

Bill


> 
> What's changed:
> 
> 	- clean up boot parameter passing between elilo and kernel
> 	  (Stephane Eranian)
> 	- optimized do_csum() some more (Jun Nakajima)
> 	- AGP GART update (Chris Ahna)
> 	- fix pci-pool routines to work on 64-bit platforms (Johannes
>           Erdfelt)
> 	- more IA-32 updates (Don Dugger, me)
> 	- make machine_halt() do nothing instead of rebooting the
> 	  machine; this has the desirable effect that "shutdown -h"
> 	  will really halt instead of rebooting the machine; the
> 	  machine does *not* power off, however (I don't think the
> 	  current firmware/hw supports this)
> 	- use KERNEL_PG_* constants instead of hardcoding the page
> 	  size used in the kernel's identity mapped regions (Tony Luck)
> 	- added getunwind() system call as a means to get unwind info
> 	  for the gate page (signal handler trampoline for now;
> 	  light-weight syscall stubs in the future) and add unwind info
> 	  to signal trampoline
> 	- move EFI vars from /proc/efi to /proc/efi/vars/ (Matt Domsch)
> 	- for MP machines, sync cycle counter register (ar.itc) of
> 	  each CPU with the time keeper CPU on boot up & exploit this
> 	  to provide fine-grained time in gettimeofday()
> 	- clean up & fix coredump creation
> 	- clean up debug messages in cs4281 drivers to avoid compiler
> 	  warnings
> 	- make the register backing store of a newly execve()'d
> 	  process start at a nicely aligned address again
> 	- fix spin_unlock() to do barrier() in correct place (Jack Steiner)
> 	- add a couple of spare longs to sigcontext structure to
> 	  provide room for future extensibility
> 
> Some notes: I didn't apply Jes's qla1280 clean up patch yet.  I'd very
> much like to do that, but since qlogic is maintaing this driver, I'm
> waiting until they've had a chance to review it.
> 
> If you look at the cycle counter sync'ing code, you'll see that it's
> very different from what has been proposed in the past.  There is a
> good reason for this: the new code allows arbitrary pairs of CPUs to
> sync at any point in time.  At this point, the only time the syncing
> is actually done is at boot time, but in the future we'll want to
> support online replacement of CPUs and with a pair-wise syncing
> approach, this is trivial to support.  Also, the new code uses a close
> loop to sync the counters.  This ensures that there are no
> unaccounted-for error sources.  The syncing tends to work quite well
> in pratice: usually, we seem to get a pair of CPUs to within <10
> cycles of each other (assuming that the interconnect between the two
> CPUs has symmetric latencies).  However, I'm also quite sure that
> someone with a better memory of control theory could optimize the
> current code for faster convergence (and perhaps more stable behavior
> in the presence of large amounts of noise).  Please feel free to take
> this as a challenge! ;-)
> 
> BIG CAVEAT: even though the kernel currently is syncing the cycle
> counters, application code MUST NOT rely on this.  Instead, if an
> application needs fine-grained and light-weight timestamps, it should
> use the POSIX *clock* routines that Uli added recently to libc.  I can
> almost guarantee you that future machines will NOT have synchronized
> clocks (and we'll also want to support systems where different CPUs
> have different clock speeds) and because of this, the *clock* routines
> and gettimeofday() are the recommended and RELIABLE way for obtaining
> fine-grained timestamps.
> 
> Enjoy,
> 
> 	--david
> 
> _______________________________________________
> Linux-IA64 mailing list
> Linux-IA64@linuxia64.org
> http://lists.linuxia64.org/lists/listinfo/linux-ia64
>