into nuts.ninka.net:/home/davem/src/BK/sparc-2.5

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

Note the cdc-ether.c driver does NOT work properly now, someone who 
understands the interface mess in that driver needs to fix it up.

This adds the requirement that the usb-serial drivers call 
usb_register() and usb_unregister() themselves, instead of having
the usbserial.c file do it.  Step one in moving the usbserial.c 
code to being a "class"  :)

 Update the ov511 driver to version 1.62:
 o Update email address
 o Remove some dead code and fix some harmless typos
 o New device: Alpha Vision Tech. AlphaCam SE
 o Fix assignment of ov->proc_button->owner to not cause
   NULL pointer deref (credit: Oleg K.)
 o Support I2C read/write ioctl()s via V4L (credit: Oleg K.)
 o Add OV518-specific register dump code
 o New snapshot reset sequence; old one was causing
   erroneous I2C writes (credit: Oleg K.)
 o OV6630 needs different register 0x14 settings than OV6620
 o Don't print palette errors by default
 o Detect OV518 cameras that have packet numbering enabled
   by default and set ov->packet_numbering accordingly. This
   should fix the problems some users were having with babble
   (USB error -75) and cameras not working at all.

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

I noticed a kluge had been put into 2.5.35, to cover up *one* of the
errors caused by a particular bug that was introduced when Patrick
Mochel split up arch/i386/kernel/setup.c: he incorrectly thought the
AMD-defined CPUID levels were AMD-specific; they're not -- every other
x86 vendors *including* Intel uses them as well.

This also adds the "i686" hack for TM5xxx that was added in 2.4 recently.

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

This patch removes attempts to clear halts on a control endpoint (think
about it for a minute if you don't see why this is pointless....) and also
adds return-code checks for all places where halts are cleared.

This _should_ be just redundant code, but recent tests suggest that this
is, in fact, not the case.  People should _heavily_ test this patch.  I'm
going to pause here for a while (in the patch stream) until we've got this
sorted out -- initial results on my test setup seem to show some problems
still remain.  Where those problems are (HCD or usb-storage) remains to be
seen.

This patch fixes up some minor compilation problems.

This patch converts all uses of page_addres() to the sg_address() macro.
This will make backporting to 2.4 easier, as well as eliminate lots of
redundant code.

This patch removes tests of urb->status for EINPROGRESS.  As was pointed
out, that's not such a good idea, for a variety of reasons.

In the process, a semaphore became useless.

Here's a very simple patch that can go into the source tree right away.
It just fixes some occurrences of the scsi result code GOOD to GOOD << 1
in isd200.c.

Date:  Mon Sep 16 09:10:25 PDT 2002
Workarea:  jen.americas.sgi.com:/src/lord/xfs-merge.2.5
Author:  lord

The following file(s) were checked into:
  bonnie.engr.sgi.com:/isms/slinx/2.5.x-xfs


Modid:  2.5.x-xfs:slinx:127481a
linux/fs/xfs/linux/xfs_lrw.c - 1.166
linux/fs/xfs/support/time.h - 1.7
linux/fs/xfs/linux/xfs_aops.c - 1.5

Date:  Fri Sep 13 14:59:34 PDT 2002
Workarea:  chuckle.americas.sgi.com:/build/lxfs-cvs/2.5.x-xfs-VER
Author:  cattelan

The following file(s) were checked into:
  bonnie.engr.sgi.com:/isms/slinx/2.5.x-xfs


Modid:  2.5.x-xfs:slinx:127397a
linux/fs/xfs/linux/xfs_version.h - 1.2

into dhcp212.munich.sgi.com:/home/hch/repo/bk/linux-2.5-xfs

This updates the Fusion-MPT driver to the latest stable version.
Changes affect the driver source only.

Major Changes:
Reworked the calls save_flags, cli, restore_flags to 2.5 format.
Modified DV  invocation and to handle illegal bus configuration
Negotiation settings honor NVRAM

Bug Fix: Pushing F/W onto part during driver unload.
Bug Fix: Force F/W reset for 1030 on driver load.
Bug Fix: F/W download algorithm.
Bug Fix: Found a memory leak in mptctl.c
Bug Fix: Forcing data direction for reads and writes (sg issue)
Bug Fix: Wrong mask in Inquiry data ANSI version

Minor Changes:
Modified the debug and logging statements of the driver
Upgraded the MPI include files (lsi/)

This fixes a number of sys_execve() problems:

 - ptrace of thread groups over exec works again.

 - if the exec() is done in a non-leader thread then we must inherit the
   parent links properly - otherwise the shell will see an early
   child-exit notification.

 - if the exec()-ing thread is detached then make it use SIGCHLD like the
   leader thread.

 - wait for the leader thread to become TASK_ZOMBIE properly -
   wait_task_inactive() alone was not enough. This should be a rare
   codepath.

now sys_execve() from thread groups works as expected in every combination
i could test: standalone, from the leader thread, from one of the child
threads, ptraced, non-ptraced, SMP and UP.

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

Syncronizes with our SVN repo. Merged in all changes from your tree.

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

Attribution goes to Petr Vandrovec for finding and solving this one. You
probably read the mail you were cc'ed on, so I'll just mention that this
patch makes sure that the irq disabling and enabling is perfectly
balanced in the probing path. I've also looked at the multiple irq chain
problem you mentioned, and as far as I can see we are never touching the
2nd chain from within the first one. So should be ok.

I'm also including the unexpected interrupt prinkt removal.

elevator_linus is seriously broken wrt accounting. Marcelo recently took
the patch to fix it in 2.4.20-pre, here's the 2.5 equiv.

Right now, we account merges as costly and seeks as not. Only thing that
prevents seek starvation is the aging scan. That is broken, very much
so. This patch fixes that to account merges and inserts differently. A
seek is ELV_LINUS_SEEK_COST more costly than a merge, currently that
define is at '16'. Doing the math on a disk, this sort of makes sense.

Defaults are read latency of 1024, which means 1024 merges or 64 seeks.
Writes are double that.

We are currently wasting ~2MiB on the bio pools. This is ok on systems
with plenty of ram, but it's too much for a 16mb system for instance.

This patch scales the bio_vec mempool sizes a bit. The logic is mainly:

+       megabytes = nr_free_pages() >> (20 - PAGE_SHIFT);
+       if (megabytes <= 16)
+               scale = 0;
+       else if (megabytes <= 32)
+               scale = 1;
+       else if (megabytes <= 64)
+               scale = 2;
+       else if (megabytes <= 96)
+               scale = 3;
+       else if (megabytes <= 128)
+               scale = 4;

and then for mempool setup:

+               if (i >= scale)
+                       pool_entries >>= 1;
+
+               bp->pool = mempool_create(pool_entries, slab_pool_alloc,
                                        slab_pool_free, bp->slab);

So we allocate less and less entries for the bigger sized pools. It
doesn't make too much sense to fill the memory with sg tables for 256
page entries on a 16mb system.

In addition, we select a starting nr_pool_entries point, based on amount
of ram as well:

+       pool_entries = megabytes * 2;
+       if (pool_entries > 256)
+               pool_entries = 256;

The end-result is that on a 128mb system, it looks like:

BIO: pool of 256 setup, 14Kb (56 bytes/bio)
biovec pool[0]:   1 bvecs: 244 entries (12 bytes)
biovec pool[1]:   4 bvecs: 244 entries (48 bytes)
biovec pool[2]:  16 bvecs: 244 entries (192 bytes)
biovec pool[3]:  64 bvecs: 244 entries (768 bytes)
biovec pool[4]: 128 bvecs: 122 entries (1536 bytes)
biovec pool[5]: 256 bvecs:  61 entries (3072 bytes)

ie a total of ~620KiB used. Booting with mem=32m gives us:

BIO: pool of 256 setup, 14Kb (56 bytes/bio)
biovec pool[0]:   1 bvecs:  56 entries (12 bytes)
biovec pool[1]:   4 bvecs:  28 entries (48 bytes)
biovec pool[2]:  16 bvecs:  14 entries (192 bytes)
biovec pool[3]:  64 bvecs:   7 entries (768 bytes)
biovec pool[4]: 128 bvecs:   3 entries (1536 bytes)
biovec pool[5]: 256 bvecs:   1 entries (3072 bytes)

ie a total of ~31KiB. Booting with 512mb makes it:

BIO: pool of 256 setup, 14Kb (56 bytes/bio)
biovec pool[0]:   1 bvecs: 256 entries (12 bytes)
biovec pool[1]:   4 bvecs: 256 entries (48 bytes)
biovec pool[2]:  16 bvecs: 256 entries (192 bytes)
biovec pool[3]:  64 bvecs: 256 entries (768 bytes)
biovec pool[4]: 128 bvecs: 256 entries (1536 bytes)
biovec pool[5]: 256 bvecs: 256 entries (3072 bytes)

which is the same as before. The cut-off point is somewhere a bit over
256mb. Andrew suggested we may want to 'cheat' a bit here, and leave the
busy pools alone. We know that mpage is going to be heavy on the 16
entry pool, so it migh make sense to make such a pool and not scale
that. We can deal with that later, though.