1. 29 Sep, 2002 17 commits
    • Kai Germaschewski's avatar
      kbuild: Fix typo for 'tags' target · 8c83fc55
      Kai Germaschewski authored
      by Aristeu Sergio Rozanski Filho
      8c83fc55
    • Kai Germaschewski's avatar
      kbuild: Make scripts/Configure follow the definition of 'int' · 46887fa2
      Kai Germaschewski authored
      Currently, scripts/Configure has code for the 'int' verb to take a
      min/max.  This violates the spec described in
      Documentation/kbuild/config-language.txt.  It also requires that if a
      default is outside of +/- 10,000,000 that defaults be provided, or
      'config' and 'oldconfig' will get stuck.  The following removes the
      support for a min/max from scripts/Configure.
      
      (by Tom Rini)
      46887fa2
    • Dominik Brodowski's avatar
      [PATCH] CPUfreq i386 drivers update · 1673f3b4
      Dominik Brodowski authored
      This add-on patch is needed to abort on Dell Inspiron 8000 / 8100 which
      would lock up during speedstep.c and to resolve an oops (thanks to Hu Gang
      for reporting this)
      1673f3b4
    • Dominik Brodowski's avatar
      [PATCH] (5/5) CPUfreq /proc/sys/cpu/ add-on patch · a82b282f
      Dominik Brodowski authored
      CPUFreq 24-API add-on patch for 2.5.39:
      kernel/cpufreq.c	cpufreq-24-API
      include/linux/cpufreq.h	cpufreq-24-API
      arch/i386/config.in	Transmeta LongRun does not work well with cpufreq-24-API
      arch/i386/Config.help	help text for CONFIG_CPU_FREQ_24_API
      a82b282f
    • Dominik Brodowski's avatar
      [PATCH] (4/5) CPUfreq Documentation · 427f9384
      Dominik Brodowski authored
      CPUFreq documentation for 2.5.39:
      CREDITS			one further CREDIT entry
      Documentation/cpufreq	documentation of CPU frequency and voltage scaling
      	support in the Linux kernel.
      MAINTAINERS		one further MAINTAINERS entry
      arch/i386/Config.help	Config.help texts for i386 CPUFreq drivers
      427f9384
    • Dominik Brodowski's avatar
      [PATCH] (3/5) CPUfreq i386 drivers · 0ed1fce0
      Dominik Brodowski authored
      CPUFreq i386 drivers for 2.5.39:
      arch/i386/config.in				Necessary config options
      arch/i386/kernel/cpu/Makefile			allow for compilation of the CPUFreq subdirectory
      arch/i386/kernel/cpu/cpufreq/Makefile		Makefile for CPUFreq drivers
      arch/i386/kernel/cpu/cpufreq/elanfreq.c		CPUFreq driver for AMD Elan processors
      arch/i386/kernel/cpu/cpufreq/longhaul.c		CPUFreq driver for VIA Longhaul processors
      arch/i386/kernel/cpu/cpufreq/longrun.c		CPUFreq driver for Transmeta Crusoe processors
      arch/i386/kernel/cpu/cpufreq/p4-clockmod.c	CPUFreq driver for Pentium 4 Xeon processors (using clock modulation)
      arch/i386/kernel/cpu/cpufreq/powernow-k6.c	CPUFreq driver for mobile AMD K6-2+ and mobile AMD K6-3+ processors
      arch/i386/kernel/cpu/cpufreq/speedstep.c	CPUFreq drivers for ICH2-M and ICH3-M chipsets and Intel Pentium 3-M and 4-M processors.
      0ed1fce0
    • Dominik Brodowski's avatar
      [PATCH] (2/5) CPUfreq i386 core · 6ea7844f
      Dominik Brodowski authored
      CPUFreq i386 core for 2.5.39:
      arch/i386/kernel/i386_ksyms.c	export cpu_khz
      arch/i386/kernel/time.c		update various i386 values on frequency
      				changes
      include/asm-i386/msr.h		add Transmeta MSR defines
      6ea7844f
    • Dominik Brodowski's avatar
      [PATCH] (1/5) CPUfreq core · e9b92d00
      Dominik Brodowski authored
      CPUFreq core for 2.5.39
      include/linux/cpufreq.h		CPUFreq header
      kernel/Makefile			add cpufreq.c if necessary
      kernel/cpufreq.c		CPUFreq core
      e9b92d00
    • Peter Wächtler's avatar
      [PATCH] oss sound cli cleanup · 18e131d1
      Peter Wächtler authored
      More cleanups for the OSS sound modules
      18e131d1
    • Ingo Molnar's avatar
      [PATCH] smptimers, old BH removal, tq-cleanup · dd140c87
      Ingo Molnar authored
      This is the smptimers patch plus the removal of old BHs and a rewrite of
      task-queue handling.
      
      Basically with the removal of TIMER_BH i think the time is right to get
      rid of old BHs forever, and to do a massive cleanup of all related
      fields.  The following five basic 'execution context' abstractions are
      supported by the kernel:
      
        - hardirq
        - softirq
        - tasklet
        - keventd-driven task-queues
        - process contexts
      
      I've done the following cleanups/simplifications to task-queues:
      
       - removed the ability to define your own task-queue, what can be done is
         to schedule_task() a given task to keventd, and to flush all pending
         tasks.
      
      This is actually a quite easy transition, since 90% of all task-queue
      users in the kernel used BH_IMMEDIATE - which is very similar in
      functionality to keventd.
      
      I believe task-queues should not be removed from the kernel altogether.
      It's true that they were written as a candidate replacement for BHs
      originally, but they do make sense in a different way: it's perhaps the
      easiest interface to do deferred processing from IRQ context, in
      performance-uncritical code areas.  They are easier to use than
      tasklets.
      
      code that cares about performance should convert to tasklets - as the
      timer code and the serial subsystem has done already. For extreme
      performance softirqs should be used - the net subsystem does this.
      
      and we can do this for 2.6 - there are only a couple of areas left after
      fixing all the BH_IMMEDIATE places.
      
      i have moved all the taskqueue handling code into kernel/context.c, and
      only kept the basic 'queue a task' definitions in include/linux/tqueue.h.
      I've converted three of the most commonly used BH_IMMEDIATE users:
      tty_io.c, floppy.c and random.c. [random.c might need more thought
      though.]
      
      i've also cleaned up kernel/timer.c over that of the stock smptimers
      patch: privatized the timer-vec definitions (nothing needs it,
      init_timer() used it mistakenly) and cleaned up the code. Plus i've moved
      some code around that does not belong into timer.c, and within timer.c
      i've organized data and functions along functionality and further
      separated the base timer code from the NTP bits.
      
      net_bh_lock: i have removed it, since it would synchronize to nothing. The
      old protocol handlers should still run on UP, and on SMP the kernel prints
      a warning upon use. Alexey, is this approach fine with you?
      
      scalable timers: i've further improved the patch ported to 2.5 by wli and
      Dipankar. There is only one pending issue i can see, the question of
      whether to migrate timers in mod_timer() or not. I'm quite convinced that
      they should be migrated, but i might be wrong. It's a 10 lines change to
      switch between migrating and non-migrating timers, we can do performance
      tests later on. The current, more complex migration code is pretty fast
      and has been stable under extremely high networking loads in the past 2
      years, so we can immediately switch to the simpler variant if someone
      proves it improves performance. (I'd say if non-migrating timers improve
      Apache performance on one of the bigger NUMA boxes then the point is
      proven, no further though will be needed.)
      dd140c87
    • Ingo Molnar's avatar
      [PATCH] atomic-thread-signals · 5a5ec729
      Ingo Molnar authored
      Avoid racing on signal delivery with thread signal blocking in thread
      groups.
      
      The method to do this is to eliminate the per-thread sigmask_lock, and
      use the per-group (per 'process') siglock for all signal related
      activities.  This immensely simplified some of the locking interactions
      within signal.c, and enabled the fixing of the above category of signal
      delivery races.
      
      This became possible due to the former thread-signal patch, which made
      siglock an irq-safe thing.  (it used to be a process-context-only
      spinlock.) And this is even a speedup for non-threaded applications:
      only one lock is used.
      
      I fixed all places within the kernel except the non-x86 arch sections.
      Even for them the transition is very straightforward, in almost every
      case the following is sufficient in arch/*/kernel/signal.c:
      
      		:1,$s/->sigmask_lock/->sig->siglock/g
      5a5ec729
    • Ingo Molnar's avatar
      [PATCH] thread-group SIGSTOP handling · 5360ccf4
      Ingo Molnar authored
      Fix thread-group SIGSTOP handling - the SIGSTOP notification was not
      propagated to the parent of the thread group leader.  Now Ctrl-Z-ing of
      thread groups works again.
      5360ccf4
    • Ingo Molnar's avatar
      [PATCH] signal delivery to thread groups bugfix · 8c739876
      Ingo Molnar authored
      Fix thread group signal sending
      8c739876
    • Ingo Molnar's avatar
      [PATCH] futex-fix-2.5.39-A1 · aa016b08
      Ingo Molnar authored
      This fixes one more race left in the new futex hashing code, which
      triggers if a futex waiter gets a signal after it has been woken up but
      before it actually wakes up.
      aa016b08
    • Ingo Molnar's avatar
      [PATCH] sigfix-2.5.39-A1 · 6e21ad7b
      Ingo Molnar authored
      This fixes the bug reported by David Mosberger, force_sig_info() dropped
      the siginfo structure, which broke things like SIGFPU or alignment-error
      exceptions.  This bug was introduced by the threading signal changes.
      (The patch also fixes signal declaration whitespaces in sched.h.)
      6e21ad7b
    • Jeff Garzik's avatar
    • Jeff Garzik's avatar
  2. 28 Sep, 2002 17 commits
  3. 27 Sep, 2002 6 commits