* keep watchdog on shorter leash, and just do
   standard irq processing when it barks.  this
   means I can use a somewhat iffy vt8235 mobo.

 * updates to the driverfs debug output, including
   using S_IRUGO so anyone can gawk.

 * some updates, mostly to use a new hcd_to_bus(),
   so this version also compiles on a (slightly
   patched) 2.4.20-pre5 kernel.  (*)

I've been chasing problems on a KT333 based system, with
the 8253 southbridge and EHCI 1.0 (!), and this fixes at
least some of them:

   - locking updates:
      * a few routines weren't protected right
      * less irqsave thrashing for schedule lock

   - adds a watchdog timer that should fire when the
     STS_IAA interrupt seems to be missing.

   - gives ports back to companion UHCI/OHCI on rmmod

   - re-enables faulted QH only after all its completion
     callbacks have done their work

   - removes an oops I've seen when usb-storage unlinks
     stuff.  (it seemed confused about error handling, but
     that's not a reason to oops.)

   - minor cleanup:  deadcode rm, etc

Right now the watchdog just barks, and that mechanism might
go away (or into the shared hcd code).  Sometimes the issue
it reports seems to clear up by itself, but sometimes not...

Two weeks ago I sent this patch to the listed USB storage maintainer
(mdharm-usb@one-eyed-alien.net) and have not yet heard back. The
attached patch adds support for the Lexar USB CF Reader identified by
id_product 0xb002, version 0x0113 (which is the version I have). This
patch is against the 2.4.19 kernel, sorry if this is the wrong address
to send this stuff to. Thanks.

The trace at the end of the message shows the init failure.

This patch has some small UHCI bugfixes

   - on submit error, frees memory and (!) returns error code
   - root hub should disconnect only once
   - pci pool code shouldn't be given GFP_DMA
   - uses del_timer_sync(), which behaves on SMP, not del_timer()

and cleanups:

   - use container_of
   - doesn't replicate so much hcd state
   - no such status -ECONNABORTED
   - uses bus_name in procfs, not "hc0", "hc1" etc

Another UHCI patch.  I'm sending this since Dan said he was going to
start teaching "uhci-hcd" how to do control and interrupt queueing,
and this may help.  Granted it checks out (I didn't test the part
that has a chance to break, though it "looks right"), I think it
should get merged in at some point.  What it does:

   - updates and adds some comments/docs
   - gets rid of a "magic number" calling convention, instead passing
     an explicit flag UHCI_PTR_DEPTH or UHCI_PTR_BREADTH (self-doc :)
   - deletes bits of unused/dead code
   - updates the append-to-qh code:
       * start using list_for_each() ... clearer than handcrafted
         loops, and it prefetches too.  Lots of places should get
         updated to do this, IMO.
       * re-orders some stuff to fix a sequencing problem
       * adds ascii-art to show how the urb queueing is done
         (based on some email Johannes sent me recently)

That sequencing problem is that when splicing a QH between A and B,
it currently splices A-->QH before QH-->B ... so that if the HC is
looking at that chunk of schedule at that time, everything starting
at B will be ignored during the rest of that frame.  (Since the QH
is initted to have UHCI_PTR_TERM next, stopping the schedule scan.)

I said "problem" not "bug" since in the current code it would probably
(what does that "PIIX bug" do??) just reduce control/bulk throughput.
That's because the logic is only appending towards the  end of each
frame's schedule, where the FSBR loopback kicks in.

This removes list_t, which is a gratuitous typedef for a "struct
list_head".  Unless there is good reason, the kernel doesn't usually
typedef, as typedefs cannot be predeclared unlike structs.

Frankly, I'm amazed the kernel worked for long without this.

Every linker script thinks the section is called .data.percpu.
Without this patch, every CPU ends up sharing the same "per-cpu"
variable.

This might explain the wierd per-cpu problem reports from Andrew and
Dave, and also that nagging feeling that I'm an idiot...

 This makes daemonize() call reparent_to_init() itself, as long
suggested for 2.5, and fixes the callers so they don't call it again.
Also fixes callers which set current->tty to NULL themselves (also
no longer neccessary).

This sets child_reaper to the idle thread upon creation, so that
ksoftirqd's reparent_to_init call doesn't get the swapper as parent.

RELOC_HIDE got miscompiled on gcc3.1/x86-64 in the access to softirq.c's per
cpu variables.  This fixes the problem.

Clearly to hide the relocation the addition needs to be done after the
value obfuscation, not before.

I don't know if it triggers on other architectures (x86-64 is especially
stressf here because it has negative kernel addresses), but seems like the
right thing to do.

Teach usb/storage/sddr09.c how to return less than a full page of sense
data.

In sd.c we call MODE SENSE (6) in order to find out whether the
device is write protected. The info we need is in byte 2, the
header of the MODE SENSE answer, but in the request we have to
specify (i) what page(s) we want, and (ii) how many bytes we want.

Long ago we asked for 12 bytes from page 1 (Daniel Roche, 1.3.35).
Matthew Dharm made this 8 bytes from page 3F (all pages), patch-2.4.0-test8.
In patch-2.4.10 the 8 was increased to 255.

I found on the one hand devices that only react to page 0
(the vendor page), and return an error for page 3F.
And on the other hand devices that are unable to handle requests
for more bytes than they actually have.

So, it seems that the cautious way to ask for MODE SENSE data is
to first ask for the header only, see how much is available,
and then ask for everything.

The patch below first separates out the MODE SENSE call,
and then tries it three times: on all pages (3F), only the first
four bytes; on the vendor page (0), only the first four bytes;
on all pages (3F), 255 bytes.

This should be at least as robust as our current code.
I tried it on 8 SCSI devices (of which 2 fail under 2.5.33)
and found no problems.

A patch from Martin Bligh which cleans up the open-coded uses of
mem_map for ia32.  Basically it replaces

mem_map + pagenr

with

pfn_to_page(pagenr)

in lots of places.  Because mem_map[] doesn't work like that with
discontigmem.

It also fixes a bug in bad_range, that happens to work for contig mem
systems, but is incorrect.  Tested both with and without discontigmem
support.

 - All the support macros which assume a linear mem_map[] have been
   wrapped in !CONFIG_DISCONTIGMEM.  pfn_to_page, page_to_pfn,
   page_to_phys, pmd_page, kern_addr_valid.

 - Move some initialsation macros into setup.h so they can be used in
   the i386 discontig.c (INITRD_START, INITRD_SIZE).

 - Alternate version of the bootmem allocator

 - add i386 discontig support and numaq support.

 - Pull the middle out of one_highpage_init() so that the i386 NUMA
   patch can call it on a per-page basis.

 - Move a few lines out of mem_init() into the new
   set_max_mapnr_init(), which the i386 NUMA code requires.

This restructures setup_arch() for i386 to make it easier to include the
i386 numa changes (for CONFIG_DISCONTIGMEM) I've been working on.  It
also makes setup_arch() easier to read.  A version of this patch is the
in 2.4 aa tree.

This does not depend on the other patches I'm submitting today, but my
discontigmem patch does depend on this one.

I've tested this patch on the following configurations: UP, SMP, SMP
PAE, multiquad, multiquad PAE.

I've had ia32-discontigmem under test for a month, uneventfully.  Possibly
because I don't have a machine to test it on....

A major part of this work is a general move to convert the low-level
memory management to consistently use pageframe numbers.  It's a bit
schizo at present..

This patch was written by Martin Bligh.  A version of this patch is in
the 2.4 aa tree.

It changes the unsigned longs node_start_paddr and zone_start_paddr to
page frame numbers.  This is necessary because a PAE address is 36 bits
and cannot be represented in an unsigned long.

 - The per-node physical memory start address node_start_paddr becomes
   a pfn, node_start_pfn.

 - The per-zone physical memory start address zone_start_paddr becomes
   a pfn, zone_start_pfn.

 - free_area_init_node() takes a pfn rather than a physical address.

Patricia has tested this patch on the following configurations: UP,
SMP, SMP PAE, multiquad, multiquad PAE, multiquad DISCONTIGMEM,
multiquad DISCONTIGMEM PAE.

The rmap locking inlines are causing some header file
dependency/ordering problems - move them out of page-flags.h and into
their own header file.

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

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

This adds IBM thinkpads to a list of mainboards that should not be
scanned by i2c sensors during detection phase.

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

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

OK, Linus, you are right... there are enough instances of this we are
not going to find them all (although I suspect Andrew's slab.c fixes
will cover most of the cases).  Further, I think we can should actually
purposely call preempt_schedule() in certain cases after interrupt
reenable to check for reschedules...

Let's just make it a rule "no preemption if interrupts are off" and
enforce that.

This fixes various instances of the interrupt flag variable not being
the proper `unsigned long', most notably kernel/softirq.c ...

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

This is a cleanup of the sigio/sigurg code.

Summary:
  o Removed sk->proc, SIGURG now sent via vfs, credentials checked
    during delivery.
  o SIOCSPGRP etc. ioctls use vfs, and work now for SIGIO as well
    as SIGURG.
  o Removed socket fcntl code.
  o Consolidate lsm file_set_fowner() hooks.
  o Fixed fowner race.
  o Fixed associated mainline memory leak in fcntl_dirnotify().

Kill duplicate declaration of pci_lock

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

contortions instead of just calling "end_that_request_first()" with
the proper sector count.

This was _bad_. Major floppy corruption, and possibly the reason
for other block device corruption for any driver that generated
partial results for a block device request.