Ingo's CPU scheduler update (in -mm kernels) needs a new sched_clock()
function which returns nanoseconds.

The patch provides implementations for ppc, ppc64, x86_64 and sparc64.

The x86_64 version could have overflow issues, the calculation is done in
32bits only with an multiply.  But I hope it's good enough for the scheduler

The ppc64 version needs scaling: it's only accurate for 1GHz CPUs.

From: Ingo Molnar <mingo@elte.hu>

the attached scheduler patch (against test2-mm2) adds the scheduling
infrastructure items discussed on lkml. I got good feedback - and while i
dont expect it to solve all problems, it does solve a number of bad ones:

 - test_starve.c code from David Mosberger

 - thud.c making the system unusuable due to unfairness

 - fair/accurate sleep average based on a finegrained clock

 - audio skipping way too easily

other changes in sched-test2-mm2-A3:

 - ia64 sched_clock() code, from David Mosberger.

 - migration thread startup without relying on implicit scheduling
   behavior. While the current 2.6 code is correct (due to the cpu-up code
   adding CPUs one by one), but it's also fragile - and this code cannot
   be carried over into the 2.4 backports. So adding this method would
   clean up the startup and would make it easier to have 2.4 backports.

and here's the original changelog for the scheduler changes:

 - cycle accuracy (nanosec resolution) timekeeping within the scheduler.
   This fixes a number of audio artifacts (skipping) i've reproduced. I
   dont think we can get away without going cycle accuracy - reading the
   cycle counter adds some overhead, but it's acceptable. The first
   nanosec-accuracy patch was done by Mike Galbraith - this patch is
   different but similar in nature. I went further in also changing the
   sleep_avg to be of nanosec resolution.

 - more finegrained timeslices: there's now a timeslice 'sub unit' of 50
   usecs (TIMESLICE_GRANULARITY) - CPU hogs on the same priority level
   will roundrobin with this unit. This change is intended to make gaming
   latencies shorter.

 - include scheduling latency in sleep bonus calculation. This change
   extends the sleep-average calculation to the period of time a task
   spends on the runqueue but doesnt get scheduled yet, right after
   wakeup. Note that tasks that were preempted (ie. not woken up) and are
   still on the runqueue do not get this benefit. This change closes one
   of the last hole in the dynamic priority estimation, it should result
   in interactive tasks getting more priority under heavy load. This
   change also fixes the test-starve.c testcase from David Mosberger.


The TSC-based scheduler clock is disabled on ia32 NUMA platforms.  (ie. 
platforms that have unsynched TSC for sure.) Those platforms should provide
the proper code to rely on the TSC in a global way.  (no such infrastructure
exists at the moment - the monotonic TSC-based clock doesnt deal with TSC
offsets either, as far as i can tell.)

From: OGAWA Hirofumi <hirofumi@mail.parknet.co.jp>

This elisp was obsolete on recently emacs's cc-mode. And this should
be personally set.

From: OGAWA Hirofumi <hirofumi@mail.parknet.co.jp>

This does the following,

1) This removes the nls modules for only alias. For backward
   compatible, this adds ->alias, and ->alias provides alias of charset.

2) For autoloading the module by the alias, use MODULE_ALIAS mechanism.

3) From changelog of module-init-tools, looks like MODULE_ALIAS needs
   module-init-tools 0.9.10 or later. So change the "Documentation/Changes".

From: Stephen Hemminger <shemminger@osdl.org>

Get rid of warnings (and dead code) if MTRR is compiled without /proc

From: James Cleverdon <jamesclv@us.ibm.com>

Some very large systems overflow the array and corrupt memory.  A BUG_ON will 
at least flag the problem until dynamic irq_vector allocation is added.

From: Oleg Drokin <green@namesys.com>

Fix trucation-induced large file corruption in reiserfs.

From: Jeremy Fitzhardinge <jeremy@goop.org>

I'm resending my patch to fix this problem.  To recap: every task_struct
has its own copy of the thread group's pgrp.  Only the thread group
leader is allowed to change the tgrp's pgrp, but it only updates its own
copy of pgrp, while all the other threads in the tgrp use the old value
they inherited on creation.

This patch simply updates all the other thread's pgrp when the tgrp
leader changes pgrp.  Ulrich has already expressed reservations about
this patch since it is (1) incomplete (it doesn't cover the case of
other ids which have similar problems), (2) racy (it doesn't synchronize
with other threads looking at the task pgrp, so they could see an
inconsistent view) and (3) slow (it takes linear time with respect to
the number of threads in the tgrp).

My reaction is that (1) it fixes the actual bug I'm encountering in a
real program.  (2) doesn't really matter for pgrp, since it is mostly an
issue with respect to the terminal job-control code (which is even more
broken without this patch.  Regarding (3), I think there are very few
programs which have a large number of threads which change process group
id on a regular basis (a heavily multi-threaded job-control shell?).

Ulrich also said he has a (proposed?) much better fix, which I've been
looking forward to.  I'm submitting this patch as a stop-gap fix for a
real bug, and perhaps to prompt the improved patch.

An alternative fix, at least for pgrp, is to change all references to
->pgrp to group_leader->pgrp.  This may be sufficient on its own, but it
would be a reasonably intrusive patch (I count 95 instances in 32 files
in the 2.6.0-test3-mm3 tree).

From: Robert Love <rml@tech9.net>

- Let real-time tasks dip further into the reserves than usual in
  __alloc_pages().  There are a lot of ways to special case this.  This
  patch just cuts z->pages_low in half, before doing the incremental min
  thing, for real-time tasks.  I do not do anything in the low memory slow
  path.  We can be a _lot_ more aggressive if we want.  Right now, we just
  give real-time tasks a little help.

- Never ever call balance_dirty_pages() on a real-time task.  Where and
  how exactly we handle this is up for debate.  We could, for example,
  special case real-time tasks inside balance_dirty_pages().  This would
  allow us to perform some of the work (say, waking up pdflush) but not
  other work (say, the active throttling).  As it stands now, we do the
  per-processor accounting in balance_dirty_pages_ratelimited() but we
  never call balance_dirty_pages().  Lots of approaches work.  What we want
  to do is never engage the real-time task in forced writeback.

From: "Nakajima, Jun" <jun.nakajima@intel.com>

Split the increasingly messy compiler.h file into per-compiler files and also
add support for non-gcc compilers.  

With the current implementation:

  include/linux/compiler.h defines the compiler-dependent abstractions
  which can be overwritten by per-compiler definitions.

  include/linux/compiler-gcc.h contains the common definitions for all gcc
  versions.

  include/linux/compiler-gcc[2,3,+].h contains gcc major version specific
  definitions.

  include/linux/compiler-intel.h contains intel compiler specific
  definitions."

- declarations come first

- fix bizarre coding style.

into home.osdl.org:/home/torvalds/v2.5/linux

The problem was that the semaphore which prevents ds interfering with
the sleepy card initialisation (skt_sem in pccardd) is blocking insmod
of the socket driver.  However, the socket driver is being called with
the PCI bus semaphore held by the driver model.

pccardd in turn discovered a cardbus card (with skt_sem held), so it
is trying to add the PCI devices to the PCI bus, and this requires the
driver model to grab the PCI bus semaphore, but its already locked.

We move the class device register into pccardd so we get a natural
ordering between the ds socket initialisation and pccardd trying to
detect inserted cards.

We also fix a potential use-after-free caused by rmmod'ing the socket
driver before ds has shut down.

into home.osdl.org:/home/torvalds/v2.5/linux

Don't issue a system call from kernel_thread(), but call do_fork()
directly.  This avoids all the unnecessary syscall overhead.

It's bad to make (CLONE_THREAD | CLONE_DETACHED) tasks
be _completely_ hidden. Resource consumption is hard
to track down if a user can hide a task from /bin/ps.

This patch, supported by the procps-3.1.13 release,
gives admins the ability to search for such tasks.
The top-level /proc directory remains uncontaminated.

When I change the setting of CONFIG_EISA, everything rebuilds.  This is
because EISA_bus is declared in <asm/processor.h> which is implicitly
included by just about everything.  This is a silly place to declare it,
so this patch moves it to include/linux/eisa.h.

While I'm at it, I also move the variable definition to
drivers/eisa/eisa-bus.c.  The rest of this patch is fixing up the fallout
from having to include <linux/eisa.h> if you use EISA_bus.

automatically as needed.

Remove duplicate includes, ensure that linux/config.h is included
where necessary, and linux/config.h isn't included where it isn't
needed.

into home.osdl.org:/home/torvalds/v2.5/linux

into home.osdl.org:/home/torvalds/v2.5/linux

* increase length of wait for analog-ready
* fix printk prefix (cosmetic)
* bail out for pure MMIO interfaces, instead of attempting to use it
  via PIO and hanging the system.

into home.osdl.org:/home/torvalds/v2.5/linux

Small clean up, to use current APIs.

this one fixes both drivers. They have been broken since the
reorganization in June. Unfortunately, my major build platform (alpha) had
some issues with later 2.5.X kernels (cache problems causing all kind of
funny behaviour), so i waited until these problems had been resolved by
the alpha gurus :-/...

In the mean time i also upgraded pine. I hope the patch corruption issue
is resolved by now.

Update hamradio/scc for 2.6.0-test5
	- use seq_file for /proc
	- get rid of dev_get()
	- use alloc_netdev

Don't have hardware, but can load/unload the module fine.

This patch converts /proc/net/bondX/info into /proc/net/bonding/bondX
using the seq_file interface.

This is based on Stephen's recent patch, but slightly modified to work
with the propagation patch set and with some locking changes to make it
simpler.

The patch applies both on 2.4 (after the sync set from earlier today)
and on 2.6 (after the propagation set from 2003/11/9).

Amir

sbni.c in 2.6.0-test5 fails to compile with gcc 3.3 with the following
error:

<--  snip  -->

...
  CC      drivers/net/wan/sbni.o
...
drivers/net/wan/sbni.c: In function `calc_crc32':
drivers/net/wan/sbni.c:1568: error: asm-specifier for variable `_crc'
conflicts with asm clobber list
make[3]: *** [drivers/net/wan/sbni.o] Error 1

<--  snip  -->

Below is the patch by Margit Schubert-White to fix this issue (it is
already in 2.4).

cu
Adrian

Rick Lindsley <ricklind@us.ibm.com> wrote:
>
> since it's been out for a while you probably already know, but the patch
> for e1000_main.c has a bug in it.  Looks like it will fail at line 1550 if
> compiled with NETIF_F_TSO defined.
>

So it will.  I blame the gcc developers.

 25-akpm/drivers/net/e1000/e1000_main.c |   13 +++++++++----
 1 files changed, 9 insertions(+), 4 deletions(-)