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.

In a test where some memory corruption happened, I noticed an
oops (null pointer exception in_irq) that's avoidable.  Here's
a patch that avoids it ... anyone seeing the err() is likely
to hang some process, but that's better than the alternative.
(Also inlines some used-once routines, saving a bit of space
to make up for the new diagnostic.)

In doing some more extensive testing of the urb queueing behavior,
I noticed that (a) IOC wasn't always being set for each urb, while
for now it needs to be set; (b) a qh patchup wasn't done quite
where it should be.  This resolves those two issues, as well
as making it a bit less noisy to unlink lots of urbs at the once.

This has minor usbcore cleanups:

DOC:
    - the changes passing a usb_interface to driver probe() and disconnect()
      weren't reflected in their adjacent docs.  likewise they still said
      it was possible to get a null usb_device_id (no more).

    - the (root) hub API restrictions from rmk's ARM patch weren't
      flagged

    - mention the non-dma-coherent cache issue for usb_buffer_alloc()

    - mention disconnect() cleanup issue with usb_{control,bulk}_msg()
      [ you can't cancel those urbs from disconnect() ]

CODE
    - make driver ioctl() use 'usb_interface' too ... this update
      also resolves an old 'one instance per device' bad assumption

    - module locking on driver->ioctl() was goofy, kept BKL way too
      long and didn't try_inc_mod_count() like the rest of usbcore

    - hcd unlink code treated iso inappropriately like interrupt;
      only interrupt still wants that automagic mode

    - move iso init out of ohci into shared submit_urb logic

    - remove interrupt transfer length restriction; hcds that don't
      handle packetization (just like bulk :) should be updated,
      but device drivers won't care for now.

/sbin/hotplug is now called when any device is added or removed from the
system.

QDIO_BH was never actually used anyway, and won't do much good now BHs
are gone.

Beginning of proper refcounting.  New helpers introduced, several drivers
switched to using them for dynamic allocation of gendisks.  Once everything
is switched (and that will be way easier than per-drive gendisks series)
we will be able to add sane reference counts on gendisk, at which point
we can safely put pointer to gendisk in struct block_device / struct request
and we had pretty much won - from that point it's pretty straightforward
crapectomy in drivers.

char *major_name replaced with char disk_name[16];  All uses of ->major_name
replaced with those of ->disk_name and (obviously) simplified big way.  Bunch
of arrays, kmallocs, etc. is gone.

... now it can be done.  We also drop almost all arguments - there is only
one caller and everything is determined by the first argument.

Cleans the handling of partitioning up.  More or less the same story as with
other drivers...

corrected handling of sizes.  Ugh.

get_gendisk() now takes dev_t (instead of kdev_t) and gets an additional
argument - int *part.  Set to 0 for non-partitioned, partition number
for partititoned.  Callers updated.  Yes, I hate passing return values
that way ;-/  We need that since old "minor(dev) - disk->first_minor"
doesn't work for stuff with non-trivial numbers (e.g. floppy) and
get_gendisk() really has to return both gendisk and partition number.
Fortunately, amount of callers of gendisk() is about to drop RSN big way...

The list used to generate /proc/partitions turned into list_head one;
we also restore the old order of elements (originally we added to the end
of list; recent changes had reverted that, now we are back to original
order).

Make IDE set the dma mask to full 32-bit dma.

Just for niceness, loop should clear queue queuedata when it exits.

These days we only require a clear of BIO_UPTODATE on -EIO, we don't set
it on success. This breaks raid5. It appears to clear BIO_UPTODATE fine
but doesn't start out with it set.

This makes loop honor the queue restrictions by basically stacking all
of those, and mirroring the merge_bvec_fn() on the target queue. It also
switches loop to use per-loop device queues, since that is the only sane
way to do this from a performance POV. Also, in principle I find it to
be much nicer if every distinct block device has its own queue.

There's really no reason to BUG() out on a bio that is too big, the
gentleman thing to do would be to print a warning and just end the bio
with -EIO quietly.

Add a function to set queue merge_bvec_fn to mimic the rest of the api,
and also add documentation for that and blk_queue_prep_rq().

The might_sleep() thing caught ide, which calls request_irq() with a
lock held. It can be argued that this is a bad thing, however I think it
can also validly be argued that requesting an irq should not be a
blocking operation. This might even remove some driver bugs where usage
count is not incremented during init...

It can also be argued, that the very first irq requests cannot be
blocking for io anyways, for good reason :-)

Too trivial to see the first time when debugging on weekends ;-))

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

into uml.karaya.com:/home/jdike/linux/2.5/highmem-2.5

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

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

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

This fixes a procfs crash noticed by Anton Blanchard.

The procfs code can have a reference even to an already exited task, so
it needs to follow special rules accessing p->sig.  The atomic-signals
patch made this bug happen at a much higher frequency, but procfs i
believe was buggy ever since, it potentially used the freed signal
structure - which just did not result in a crash like it does today.

The proper fix is to take the tasklist read-lock in
collect_sigign_sigcatch(), this excludes __exit_sighand() freeing the
signal structure prematurely.

due to synchronize_irq() becoming a no-op when !CONFIG_SMP.

uml.ld.S.