Don't create /proc/interrupts on s390.

Remove call to s390_init_machine_check in init/main.c, the new boot code
on s390 calls it via arch_initcall.

Rework boot sequence on s390:

Traditionally, device detection os s390 is done completely
at a _very_ early stage during bootup (from init_irq(),
i.e. before memory management or the console are there).

This has always been a bad idea, but now it broke even more
since the linux driver model requires devices detection
to take place after the core_initcalls are done.

We now do only a small amount of scanning (probably
less in the future) at the early stage, the bulk of it
is done from a proper subsys_initcall(). This requires
some changes in related areas:

- the machine check handler initialization is split in
  two halves, since we want to catch major machine malfunctions
  as early as possible, but device machine checks can only
  be caught after the channel subsystem is up.

- some functions that are called from the css initialization
  made some assumptions of when to use kmalloc or bootmem_alloc,
  which were broken anyway. We fix this here and hopefully
  can get rid of bootmem_alloc for the css completely in the future.

- the debug logging feature for s390 was not used for functions
  in the initialization before, since it requires the memory
  management to be working. Now that we can be sure that it
  works, some special cases can be removed.

Now that these changes are done, a partial implementation of the
device model for the channel subsystem is possible, but at this
point, none of the device drivers make use of that yet.

Check if defined chpids are available. Some code simplification.

Cleanup s390_process_IRQ a little, the ending_status argument is never
really used.

Remove bogus sanity check from {en,dis}able_sync_isc() and really disable all
interrupt sub classes except isc 7 in wait_cons_dev.

Add 'signal quiesque' feature to s390 hardware console. A signal quiesce
is sent from VM or the service element every time the system should shut
down. We receive the quiesce signal and call ctrl_alt_del(). Finally the
mainframes have ctrl-alt-del as well :-)

Rewrite s390 ptrace code in a more readable and less buggy way. As a part of
this, all psw related definitions are moved into ptrace.h from a number of
different locations.

Cleanup load/store of fpu register on s390.

Remove bogus sanity checks and code cleanup.

Make timer interrupt independent from boot cpu and do several ticks in one
go if a virtual cpu didn't get an interrupt for a period of time > HZ.

Use diag 0x44 on s390x for spinlocks.

Inline csum_partial for s390, the only reason it was out-of-line previously
is that some older compilers could not get the inline version right.

Add support for kernel preemption on s390/s390x.

Use a preprocessed linker script for building vmlinux on s390/s390x.

Fix bug in 31 bit emulation of sys_msgsnd and rename sys32_pread/sys32_pwrite
to sys32_pread64/sys32_pwrite64.

Fix broken bitops for unaligned atomic operations on s390.

Replace IMMEDIATE_BH bottom half by tasklets in 3215, ctc and iucv driver.

Remove reference to xpram_release. Correct calls to bi_end_io and bio_io_error.

Remove some configuration options that don't really make sense.

Correct includes in ibm.c to make it compile.

New system calls: security, async. i/o and sys_exit_group. Add 31 bit emulation
function for sys_futex.

s390 minimal device drivers changes for 2.5.39.

s390 include file changes for 2.5.39.

s390 arch file changes for 2.5.39.

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

into mulgrave.(none):/home/jejb/BK/scsi-for-linus-2.5

Hi!

Since the introduction of USER_HZ the SG_[GS]ET_TIMEOUT ioctls may have
a serious BUG as userspace uses a different HZ from the HZ in kernelspace.

In x86 HZ=1000 and USER_HZ=100, resulting in confusing timouts as the
kernel measures time 10 times as fast as userspace.

This patch is an attempt to fix this by transforming USER_HZ based timing to
HZ based timing before storing it in timeout. To make sure that SG_GET_TIMEOUT
and SG_SET_TIMEOUT behave consistently a field timeout_user is added which
stores the exact value that's passed by SG_SET_TIMEOUT and it's returned on
SG_GET_TIMEOUT.

Rolf Fokkens
fokkensr@fokkensr.vertis.nl

P.S. this is the second post of this patch

But it's called from scsi_add_lun()->scsi_alloc_sdev() before the type
is known.  The type is -1 all the time in scsi_initialise_merge_fn()
and scsi always bounces.

This patch makes it do the right thing - just enable block-highmem for
all scsi devices.

Jens had this to say:

"I guess that block-highmem has been around long enough, that I can
 use the term 'historically' at least in the kernel sense :-)

 This extra check was added for IDE because each device type driver
 (ide-disk, ide-cd, etc) needed to be updated to not assume virtual
 mappings of request data was valid.  I only did that for ide-disk,
 since this is the only one where bounce buffering really hurt
 performance wise.  So while ide-cd and ide-tape etc could have been
 updated, I deemed it uninteresting and not worthwhile.

 Now, this was just carried straight into the scsi counter parts,
 conveniently, because of laziness.  A quick glance at sr shows that it
 too can aviod bouncing easily (no changes needed).  st may need some
 changes, though.  So again, for scsi it was a matter of not impacting
 existing code in 2.4 too much.

 So TYPE_DISK check can be killed in 2.5 if someone does the work of
 checking that it is safe.  I'm not so sure it will make eg your SCSI
 CD-ROM that much faster :-)"

This removes an unused label in fs/devfs/base.c

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

It needs s/malloc.h/slab.h/ .
It also forgets to free some memory on an error exit patch.
Patch for 2.5.39 follows.

Here are the scatterlist primitives there's been mail about before.
Now the code has passed basic sanity testing, and is ready to merge
into Linus' tree to start getting wider use.  Greg, please merge!

To recap, the routines are a utility layer packaging several usb
core facilities to improve system performance.  It's synchronous.
The code uses functionality that drivers could use already, but
generally haven't:

    - Request queueing.  This is a big performance win.  It lets
      device drivers help the hcds avoid wasted i/o bandwidth, by
      eliminating irq and scheduling latencies between requests.  It
      can make a huge difference at high speed, when the latencies
      often exceed the time to handle each i/o request!

    - The new usb_map_sg() primitives, leveraging IOMMU hardware
      if it's there (better than entry-at-a-time mapping).

    - URB_NO_INTERRUPT transfer flag, a hint to hcds that they
      can avoid a 'success irq' for this urb.  Only the urb for
      the last scatterlist entry really needs an IRQ, the others
      can be eliminated or delayed.  (OHCI uses this today, and
      any HCD can safely ignore it.)

The particular functionality in these APIs seemed to meet Matt's
requirements for usb-storage, so I'd hope the 2.5 usb-storage
code will start to use these routines in a while.  (And maybe
those two scanner drivers: hpusbscsi, microtek.)

Brief summary of testing:  this code seems correct for normal
reads and writes, but the fault paths (including cancelation)
haven't been tested yet.  Both EHCI and OHCI seem to be mostly
OK with these more aggressive queued loads, but may need small
updates (like the two I sent yesterday).  Unfortunately I have
to report that UHCI and urb queueing will sometimes lock up my
hardware (PIIX4), so while we're lots better than 2.4 this is
still a bit of a trouble spot for now.

I'll be making some testing software available shortly, which
will help track down remaining HCD level problems by giving the
queuing APIs (and some others!) a more strenuous workout than
most drivers will, in their day-to-day usage.

- Dave

Greg, attached is a patch designed for diagnostic purposes.  Please apply
to the 2.5 tree -- yes, we'll be removing this at some point in the future.

It appears that we have a problem clearing halts.  This patch causes a very
clear message to be printed whenever a usb_stor_clear_halt() manages to
work.  So far, I haven't seen such a thing happen.  And I've seen _lots_ of
STALL conditions.

This problem has likely been around for a while... however, it hasn't been
noticed before because usb-storage was difficult to use because of other
bugs.  Heck, the most recent 'bk pull' is the first one for me in _months_
which let me boot all the way into X11.

I'm going to hold my patch queue until this is resolved.  On my test setup,
it's easy to see this failing.  I've tried with 4 different devices, with
both UHCI and EHCI drivers.  I don't want to confuse this problem with
other patches...

'result' in this function always seems to be -32.  Which is odd, because
control endpoints shouldn't do that.

I'm open to suggestions as to where to look for this bug, but my instincts
are telling me that this is a core or HCD issue, not a usb-storage issue.

On a positive note, this means that the error-recovery system gets a good
workout.

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

into flint.arm.linux.org.uk:/usr/src/linux-bk-2.5/linux-2.5-rmk