I broke part of the udsl_decode_rawcell logic in a previous patch, leading to
possible hangs on startup/shutdown.  I've attached the 2.4 and 2.5 versions.
Thanks to Subodh Srivastava and Ted Phelps for their bug reports.  Here is the
2.5 patch included inline for reference:

So here's the EHCI implementation of that new callback,
morphed/simplified from the old "free_config" one (which
is now gone).  It looks almost identical to the OHCI
version, except the dummy TDs work a bit differently.

Again, drivers that clean themselves up in disconnect()
shouldn't notice this change.  I didn't re-test this;
I don't have devices with the other kind of driver.  You
should do so with one of yours (high speed hub and TT).

There are still about half a dozen places in usbcore
and the HCDs that would benefit from using this new
callback, FWIW.  I'd call them non-critical bugfixes
that should wait a bit, while this batch shakes out.

This patch fixes the endpoint numbers. They were numbered from 1 to n
but that assumption is not correct in all cases.

remove duplicated word, fix an unclear implication.

Attached, find a patch that "ought to" teach OHCI how to do that
cleanup, by implementing the new callback.  (And the first half
is the patch you applied, with that irqsave tweak -- so you should
already have it.)

Here's a streamlined version:  doesn't require the unlink
cleanup, and expects the *hci-hcd updates later.  Smaller,
and sanity checked against all three major HCDs.

  - reverts that unlink() patch: disconnect() callbacks
    can continue to act like they always have.

  - adds new "disable that endpoint" support, necessary
    for safely changing configurations or altsettings
    as well as physical disconnect (which is almost the
    same as setting config to zero, except for ep0).

  - NEW BEHAVIOUR:  usbcore cleans up after drivers that
    return from disconnect() with urbs still linked, by
    using the new "disable that endpoint" support.

Because it doesn't have any *hci-hcd updates, the hardware
synch needed by EHCI and OHCI (not UHCI) still gets done
through the bus->deallocate(dev) call ... not where we've
ever needed it, but 2.3-compatible (and finally fixable).

That gets rid of some problematic disconnect scenarios, and
other fixes can be phased in over time:  the *hci-hcd updates
to relocate the hardware synch point so it always happens in
a task context, and disabling endpoints before their configs
change (invalidating all HC state).

From: Trond Myklebust <trond.myklebust@fys.uio.no>

The patch fixes some problems with NFS under heavy writeout.

NFS pages can be in a clean but unreclaimable state.  They are unreclaimable
because the server has not yet acked the write - we may need to "redirty"
them if the server crashes.

These are referred to as "unstable" pages.  We need to count them alongside
dirty and writeback pages when making flushing and throttling decisions.
Otherwise the machine can be flooded with these pages and the VM has
problems.

The MCE code is setting up a timer whose handler uses the workqueue code
before workqueue is initialised.  If you boot slowly it oopses.

Convert the MCE code to use an initcall.

From: george anzinger <george@mvista.com>

The MAJOR problem was a hang in the kernel if a user tried to delete a
repeating timer that had a signal delivery pending. I was putting the
task in a loop waiting for that same task to pick up the signal. OUCH!

A minor issue relates to the need by the glibc folks, to specify a
particular thread to get the signal.  I had this code in all along,
but somewhere in 2.5 the signal code was made POSIX compliant, i.e.
deliver to the first thread that doesn't have it masked out.

This now uses the code from the above mentioned clean up.  Most
signals go to the group delivery signal code, however, those
specifying THREAD_ID (an extension to the POSIX standard) are sent to
the specified thread.  That thread MUST be in the same thread group as
the thread that creates the timer.

drivers/md/xor.c needs kernel_fpu_begin() for the mmx checksumming functions.
 So export that to GPL modules.

use `unsigned long' for a jiffies-holding type.

use-after-free races have been seen due to the workqueue timer in the tty
structure going off after the tty was freed.

Fix that up by using cancel_scheduled_work() and flush_scheduled_work().

The workqueue code currently has a notion of a per-cpu queue being "busy".
flush_scheduled_work()'s responsibility is to wait for a queue to be not busy.

Problem is, flush_scheduled_work() can easily hang up.

- The workqueue is deemed "busy" when there are pending delayed
  (timer-based) works.  But if someone repeatedly schedules new delayed work
  in the callback, the queue will never fall idle, and flush_scheduled_work()
  will not terminate.

- If someone reschedules work (not delayed work) in the work function, that
  too will cause the queue to never go idle, and flush_scheduled_work() will
  not terminate.

So what this patch does is:

- Create a new "cancel_delayed_work()" which will try to kill off any
  timer-based delayed works.

- Change flush_scheduled_work() so that it is immune to people re-adding
  work in the work callout handler.

  We can do this by recognising that the caller does *not* want to wait
  until the workqueue is "empty".  The caller merely wants to wait until all
  works which were pending at the time flush_scheduled_work() was called have
  completed.

  The patch uses a couple of sequence numbers for that.

So now, if someone wants to reliably remove delayed work they should do:


	/*
	 * Make sure that my work-callback will no longer schedule new work
	 */
	my_driver_is_shutting_down = 1;

	/*
	 * Kill off any pending delayed work
	 */
	cancel_delayed_work(&my_work);

	/*
	 * OK, there will be no new works scheduled.  But there may be one
	 * currently queued or in progress.  So wait for that to complete.
	 */
	flush_scheduled_work();


The patch also changes the flush_workqueue() sleep to be uninterruptible.
We cannot legally bale out if a signal is delivered anyway.

From: Philippe Elie <phil.el@wanadoo.fr>

- oprofile is currently only profiling one sibling.  Fix that with
  appropriate register settings.

- fix an oops which could occur if the userspace driver were to request a
  non-existent resource.

- in NMI handler counter_config[i].event is accessible from user space so
  user can change the event during profiling by echo xxx >
  /dev/oprofile/event

- event mask was wrong, the bit field is 6 bits length not 5, events
  SSE_INPUT_ASSIST and X87_SIMD_MOVES_UOP was affected by masking high bit of
  event number.

A few places were missing the rwlock->spinlock conversion.

macro argument, so that portability issues will be found in
a timely manner.

This fixes oopses when it and the hid core are compiled into the kernel.

Amiga Gayle IDE fixes: Set hwif->mmio to 2 to prevent the generic IDE core from
messing with our resources

Amiga keyboard: fix default keyboard mappings:
  - Map the parentheses keys on the numeric keypad to KPLEFTPAREN and
    KPRIGHTPAREN (was: NUMLOCK and SCROLLLOCK)
  - Map the Help key to HELP (was: F11)
  - Map the Amiga keys to LEFTMETA and RIGHTMETA (was: RESERVED)

IDE: Print IRQ number in decimal on m68k

M68k: Add module support (from Roman Zippel)

Atyfb fixes for Atari:
  - Add missing allocation of default_par
  - Kill warnings in assignments

function actually exists.

architecture is now just a 64-bit configuration option of the
basic s390 architecture.

Merge s390x and s390 to one architecture.

Merge s390x and s390 to one architecture.

Merge s390x and s390 to one architecture.

Merge s390x and s390 to one architecture.

Merge s390x and s390 to one architecture.

Merge s390x and s390 to one architecture.

Merge s390x and s390 to one architecture.