1. 19 2月, 2008 1 次提交
    • D
      [SPARC]: Kill 'prom_palette'. · 667bc389
      David S. Miller 提交于
      The idea of this thing is we could save/restore the firmware's
      palette when breaking in and out of the firmware prompt.
      
      Only one driver implemented this (atyfb) and it's value is
      questionable.  If you're just debugging you don't really
      care that the characters end up being purple or whatever.
      
      And we can provide better debugging and firmware command
      facilities with minimal in-kernel console I/O drivers.
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      667bc389
  2. 09 2月, 2008 2 次提交
  3. 27 10月, 2007 1 次提交
  4. 21 7月, 2007 1 次提交
    • D
      [SPARC]: Fix serial console device detection. · c73fcc84
      David S. Miller 提交于
      The current scheme works on static interpretation of text names, which
      is wrong.
      
      The output-device setting, for example, must be resolved via an alias
      or similar to a full path name to the console device.
      
      Paths also contain an optional set of 'options', which starts with a
      colon at the end of the path.  The option area is used to specify
      which of two serial ports ('a' or 'b') the path refers to when a
      device node drives multiple ports.  'a' is assumed if the option
      specification is missing.
      
      This was caught by the UltraSPARC-T1 simulator.  The 'output-device'
      property was set to 'ttya' and we didn't pick upon the fact that this
      is an OBP alias set to '/virtual-devices/console'.  Instead we saw it
      as the first serial console device, instead of the hypervisor console.
      
      The infrastructure is now there to take advantage of this to resolve
      the console correctly even in multi-head situations in fbcon too.
      
      Thanks to Greg Onufer for the bug report.
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      c73fcc84
  5. 12 5月, 2007 1 次提交
  6. 09 5月, 2007 1 次提交
  7. 13 3月, 2007 1 次提交
  8. 31 1月, 2007 1 次提交
  9. 01 7月, 2006 1 次提交
  10. 08 2月, 2006 1 次提交
  11. 13 1月, 2006 2 次提交
  12. 09 11月, 2005 2 次提交
    • N
      [PATCH] sched: resched and cpu_idle rework · 64c7c8f8
      Nick Piggin 提交于
      Make some changes to the NEED_RESCHED and POLLING_NRFLAG to reduce
      confusion, and make their semantics rigid.  Improves efficiency of
      resched_task and some cpu_idle routines.
      
      * In resched_task:
      - TIF_NEED_RESCHED is only cleared with the task's runqueue lock held,
        and as we hold it during resched_task, then there is no need for an
        atomic test and set there. The only other time this should be set is
        when the task's quantum expires, in the timer interrupt - this is
        protected against because the rq lock is irq-safe.
      
      - If TIF_NEED_RESCHED is set, then we don't need to do anything. It
        won't get unset until the task get's schedule()d off.
      
      - If we are running on the same CPU as the task we resched, then set
        TIF_NEED_RESCHED and no further action is required.
      
      - If we are running on another CPU, and TIF_POLLING_NRFLAG is *not* set
        after TIF_NEED_RESCHED has been set, then we need to send an IPI.
      
      Using these rules, we are able to remove the test and set operation in
      resched_task, and make clear the previously vague semantics of
      POLLING_NRFLAG.
      
      * In idle routines:
      - Enter cpu_idle with preempt disabled. When the need_resched() condition
        becomes true, explicitly call schedule(). This makes things a bit clearer
        (IMO), but haven't updated all architectures yet.
      
      - Many do a test and clear of TIF_NEED_RESCHED for some reason. According
        to the resched_task rules, this isn't needed (and actually breaks the
        assumption that TIF_NEED_RESCHED is only cleared with the runqueue lock
        held). So remove that. Generally one less locked memory op when switching
        to the idle thread.
      
      - Many idle routines clear TIF_POLLING_NRFLAG, and only set it in the inner
        most polling idle loops. The above resched_task semantics allow it to be
        set until before the last time need_resched() is checked before going into
        a halt requiring interrupt wakeup.
      
        Many idle routines simply never enter such a halt, and so POLLING_NRFLAG
        can be always left set, completely eliminating resched IPIs when rescheduling
        the idle task.
      
        POLLING_NRFLAG width can be increased, to reduce the chance of resched IPIs.
      Signed-off-by: NNick Piggin <npiggin@suse.de>
      Cc: Ingo Molnar <mingo@elte.hu>
      Cc: Con Kolivas <kernel@kolivas.org>
      Signed-off-by: NAndrew Morton <akpm@osdl.org>
      Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
      64c7c8f8
    • N
      [PATCH] sched: disable preempt in idle tasks · 5bfb5d69
      Nick Piggin 提交于
      Run idle threads with preempt disabled.
      
      Also corrected a bugs in arm26's cpu_idle (make it actually call schedule()).
      How did it ever work before?
      
      Might fix the CPU hotplugging hang which Nigel Cunningham noted.
      
      We think the bug hits if the idle thread is preempted after checking
      need_resched() and before going to sleep, then the CPU offlined.
      
      After calling stop_machine_run, the CPU eventually returns from preemption and
      into the idle thread and goes to sleep.  The CPU will continue executing
      previous idle and have no chance to call play_dead.
      
      By disabling preemption until we are ready to explicitly schedule, this bug is
      fixed and the idle threads generally become more robust.
      
      From: alexs <ashepard@u.washington.edu>
      
        PPC build fix
      
      From: Yoichi Yuasa <yuasa@hh.iij4u.or.jp>
      
        MIPS build fix
      Signed-off-by: NNick Piggin <npiggin@suse.de>
      Signed-off-by: NYoichi Yuasa <yuasa@hh.iij4u.or.jp>
      Signed-off-by: NAndrew Morton <akpm@osdl.org>
      Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
      5bfb5d69
  13. 27 7月, 2005 1 次提交
  14. 06 5月, 2005 1 次提交
  15. 25 4月, 2005 1 次提交
  16. 17 4月, 2005 1 次提交
    • L
      Linux-2.6.12-rc2 · 1da177e4
      Linus Torvalds 提交于
      Initial git repository build. I'm not bothering with the full history,
      even though we have it. We can create a separate "historical" git
      archive of that later if we want to, and in the meantime it's about
      3.2GB when imported into git - space that would just make the early
      git days unnecessarily complicated, when we don't have a lot of good
      infrastructure for it.
      
      Let it rip!
      1da177e4