1. 26 Jul, 2002 24 commits
  2. 25 Jul, 2002 16 commits
    • Oleg Nesterov's avatar
      [PATCH] irqlock fixes · b0ab8396
      Oleg Nesterov authored
      Add irq_enter/exit to smp_call_function_interrupt():
      arch/i386/kernel/microcode.c:do_microcode_update() calls
      smp_call_function(do_update_one).  do_update_one() does
      spin_lock/unlock.
      
      Remove unneeded GET_THREAD_INFO(%ebx) in device_not_available() trap in
      entry.S
      b0ab8396
    • Linus Torvalds's avatar
      Remove (broken) parport locking, add comment on fixing it. · 27a25d32
      Linus Torvalds authored
      At least it compiles now.
      27a25d32
    • Linus Torvalds's avatar
      Remove unnecessary (and now nonworking) "sti()" in parport · ef27791d
      Linus Torvalds authored
      interrupt probing
      ef27791d
    • Linus Torvalds's avatar
      cmd640 IDE driver internal spinlocks for config etc accesses. · e5066df3
      Linus Torvalds authored
      This is no better or worse than the cli/sti the cmd640 driver
      used to have, but at least it compiles and works in the new
      scheme of things.
      
      Perfection can wait. Especially since that probably involves
      removing the PCI-related code, and just trusting the native
      Linux direct PCI accesses.
      e5066df3
    • Linus Torvalds's avatar
      Merge penguin.transmeta.com:/home/penguin/torvalds/repositories/kernel/tls-tree · 116eb9a8
      Linus Torvalds authored
      into penguin.transmeta.com:/home/penguin/torvalds/repositories/kernel/linux
      116eb9a8
    • Ingo Molnar's avatar
      [PATCH] Thread-Local Storage (TLS) support · 0bbed3be
      Ingo Molnar authored
      the following patch implements proper x86 TLS support in the Linux kernel,
      via a new system-call, sys_set_thread_area():
      
         http://redhat.com/~mingo/tls-patches/tls-2.5.28-C6
      
      a TLS test utility can be downloaded from:
      
          http://redhat.com/~mingo/tls-patches/tls_test.c
      
      what is TLS? Thread Local Storage is a concept used by threading
      abstractions - fast an efficient way to store per-thread local (but not
      on-stack local) data. The __thread extension is already supported by gcc.
      
      proper TLS support in compilers (and glibc/pthreads) is a bit problematic
      on the x86 platform. There's only 8 general purpose registers available,
      so on x86 we have to use segments to access the TLS. The approach used by
      glibc so far was to set up a per-thread LDT entry to describe the TLS.
      Besides the generic unrobustness of LDTs, this also introduced a limit:
      the maximum number of LDT entries is 8192, so the maximum number of
      threads per application is 8192.
      
      this patch does it differently - the kernel keeps a specific per-thread
      GDT entry that can be set up and modified by each thread:
      
           asmlinkage int sys_set_thread_area(unsigned int base,
                     unsigned int limit, unsigned int flags)
      
      the kernel, upon context-switch, modifies this GDT entry to match that of
      the thread's TLS setting. This way user-space threaded code can access
      per-thread data via this descriptor - by using the same, constant %gs (or
      %gs) selector. The number of TLS areas is unlimited, and there is no
      additional allocation overhead associated with TLS support.
      
      
      the biggest problem preventing the introduction of this concept was
      Linux's global shared GDT on SMP systems. The patch fixes this by
      implementing a per-CPU GDT, which is also a nice context-switch speedup,
      2-task lat_ctx context-switching got faster by about 5% on a dual Celeron
      testbox. [ Could it be that a shared GDT is fundamentally suboptimal on
      SMP? perhaps updating the 'accessed' bit in the DS/CS descriptors causes
      some sort locked memory cycle overhead? ]
      
      the GDT layout got simplified:
      
       *   0 - null
       *   1 - Thread-Local Storage (TLS) segment
       *   2 - kernel code segment
       *   3 - kernel data segment
       *   4 - user code segment              <==== new cacheline
       *   5 - user data segment
       *   6 - TSS
       *   7 - LDT
       *   8 - APM BIOS support               <==== new cacheline
       *   9 - APM BIOS support
       *  10 - APM BIOS support
       *  11 - APM BIOS support
       *  12 - PNPBIOS support                <==== new cacheline
       *  13 - PNPBIOS support
       *  14 - PNPBIOS support
       *  15 - PNPBIOS support
       *  16 - PNPBIOS support                <==== new cacheline
       *  17 - not used
       *  18 - not used
       *  19 - not used
      
      set_thread_area() currently recognizes the following flags:
      
        #define TLS_FLAG_LIMIT_IN_PAGES         0x00000001
        #define TLS_FLAG_WRITABLE               0x00000002
        #define TLS_FLAG_CLEAR                  0x00000004
      
      - in theory we could avoid the 'limit in pages' bit, but i wanted to
        preserve the flexibility to potentially enable the setting of
        byte-granularity stack segments for example. And unlimited segments
        (granularity = pages, limit = 0xfffff) might have a performance
        advantage on some CPUs. We could also automatically figure out the best
        possible granularity for a given limit - but i wanted to avoid this kind
        of guesswork. Some CPUs might have a plus for page-limit segments - who
        knows.
      
      - The 'writable' flag is straightforward and could be useful to some
        applications.
      
      - The 'clear' flag clears the TLS. [note that a base 0 limit 0 TLS is in
        fact legal, it's a single-byte segment at address 0.]
      
      (the system-call does not expose any other segment options to user-space,
      priviledge level is 3, the segment is 32-bit, etc. - it's using safe and
      sane defaults.)
      
      NOTE: the interface does not allow the changing of the TLS of another
      thread on purpose - that would just complicate the interface (and
      implementation) unnecesserily. Is there any good reason to allow the
      setting of another thread's TLS?
      
      NOTE2: non-pthreads glibc applications can call set_thread_area() to set
      up a GDT entry just below the end of stack. We could use some sort of
      default TLS area as well, but that would hard-code a given segment.
      0bbed3be
    • Greg Kroah-Hartman's avatar
      [PATCH] USB: fixed the interface names to have the proper bus id. · 47f16341
      Greg Kroah-Hartman authored
      Thanks to David Brownell for pointing out where my previous patch was wrong.
      47f16341
    • Sam Ravnborg's avatar
      [PATCH] Remove docgen + gen-all-syms targets · f7822c6b
      Sam Ravnborg authored
      Removed unused targets to CHMOD_FILES in scripts
      
      This allow a fresh kernel to start the build process without
      bailing about docgen.
      f7822c6b
    • Andy Grover's avatar
      resolve merge of Dom's patch · 26cffe4a
      Andy Grover authored
      26cffe4a
    • Andy Grover's avatar
      Last little bit of C99 init fixes · dda0273d
      Andy Grover authored
      Fix panic in EC driver (Dom B)
      Add a some more sanity checking (Richard Schaal)
      dda0273d
    • Andy Grover's avatar
      Use C99 initializers (Rusty Russell) · 4916e118
      Andy Grover authored
      4916e118
    • Andy Grover's avatar
      Interpreter update · 6050790e
      Andy Grover authored
      6050790e
    • Dominik Brodowski's avatar
      [PATCH] resolve ACPI lockup · cc6baa4f
      Dominik Brodowski authored
      A much needed (and widely tested) ACPI bugfix for kernel 2.5.28:
      An u8 was casted into an u32, then all 32 bits were zeroed. This can cause
      other values, e.g. "unsigned long flags" to be corrupted. When these
      flags==0 are "restored", the system locks hard.
      cc6baa4f
    • Patrick Mochel's avatar
      Merge osdl.org:/home/mochel/src/kernel/devel/linux-2.5-virgin · 173d4827
      Patrick Mochel authored
      into osdl.org:/home/mochel/src/kernel/devel/linux-2.5-driverfs-rewrite
      173d4827
    • Adam Polkosnik's avatar
      [PATCH] new USB scanner IDs · ebff966a
      Adam Polkosnik authored
      just a couple of extra IDs for Canon USB Scanners
      ebff966a
    • David Brownell's avatar
      [PATCH] ohci unlink cleanups · 4ff8e934
      David Brownell authored
      Attached is a patch that cleans up a few more issues in the OHCI unlink
      code.
      
      There may still be an ISO-IN data problem, I'll look at that separately
      since it seems unrelated to unlink issues.
      
      - Simplify/correct ED lifecycle
      	* UNLINK is now for real: descheduled and waiting for SOF
      	* finish_unlinks() expects descheduled EDs (may reschedule)
      	* only ed_deschedule() turns off hardware schedule processing
      	* no more NEW state
      	* no more ED_URB_DEL flag (it added extra states)
      	* new IDLE state, "not scheduled" (replaces previous UNLINKing)
      - Bugfixes
      	* ed_get(), potential memleak is now gone
      	* urb_enqueue(), won't submit to dead/sleeping hc
      	* free_config(), rescans after SOF when needed
      	* ed_schedule(), use wmb()
      	* ed_schedule() and finish_unlinks(), more thorough about
      	  restarting control or bulk processing
      	* finish_unlinks(), more cautious about reentering
      - General:
      	* ed->ed_rm_list renamed ed_next; to be used more later
      	* slightly shrink object code
      	* rename some functions
      
      This leaves one notable issue in the unlink paths:  the driver never waits
      for SOF after descheduling (empty) EDs.  That's racey in most cases, though
      there are a few light-traffic cases where that's correct (in part because
      the ED is empty).  Easy to fix once the rest of this is known to behave.
      4ff8e934