1. 09 1月, 2009 4 次提交
  2. 12 12月, 2008 1 次提交
  3. 09 12月, 2008 1 次提交
  4. 05 12月, 2008 3 次提交
  5. 30 8月, 2008 2 次提交
  6. 29 8月, 2008 5 次提交
  7. 25 8月, 2008 2 次提交
  8. 01 8月, 2008 1 次提交
    • D
      sparc64: Kill __show_regs(). · dbf3e950
      David S. Miller 提交于
      The story is that what we used to do when we actually used
      smp_report_regs() is that if you specifically only wanted to have the
      current cpu's registers dumped you would call "__show_regs()"
      otherwise you would call show_regs() which also invoked
      smp_report_regs().
      
      Now that we killed off smp_report_regs() there is no longer any
      reason to have these two routines, just show_regs() is sufficient.
      
      Also kill off a stray declaration of show_regs() in sparc64_ksym.c
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      dbf3e950
  9. 18 7月, 2008 1 次提交
  10. 01 7月, 2008 1 次提交
    • I
      fix "ftrace: store mcount address in rec->ip" · 760378e1
      Ingo Molnar 提交于
      Alexander Beregalov reported this build failure:
      
      $ make CROSS_COMPILE=sparc64-unknown-linux-gnu- image modules && sudo
      make modules_install
        CHK     include/linux/version.h
        CHK     include/linux/utsrelease.h
        CALL    scripts/checksyscalls.sh
        CHK     include/linux/compile.h
      dnsdomainname: Unknown host
        CC      arch/sparc64/kernel/sparc64_ksyms.o
      arch/sparc64/kernel/sparc64_ksyms.c:116: error: '_mcount' undeclared
      here (not in a function)
      cc1: warnings being treated as errors
      arch/sparc64/kernel/sparc64_ksyms.c:116: error: type defaults to 'int'
      in declaration of '_mcount'
      
      And bisected it back to:
      
      | commit 395a59d0
      | Author: Abhishek Sagar <sagar.abhishek@gmail.com>
      | Date:   Sat Jun 21 23:47:27 2008 +0530
      |
      |     ftrace: store mcount address in rec->ip
      
      the mcount prototype is only available under CONFIG_FTRACE,
      extend it to CONFIG_MCOUNT as well.
      Reported-and-bisected-by: NAlexander Beregalov <a.beregalov@gmail.com>
      Signed-off-by: NIngo Molnar <mingo@elte.hu>
      760378e1
  11. 24 6月, 2008 1 次提交
  12. 27 4月, 2008 1 次提交
  13. 24 4月, 2008 1 次提交
  14. 22 4月, 2008 1 次提交
  15. 17 4月, 2008 1 次提交
  16. 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
  17. 09 2月, 2008 1 次提交
  18. 07 2月, 2008 1 次提交
    • E
      get rid of NR_OPEN and introduce a sysctl_nr_open · 9cfe015a
      Eric Dumazet 提交于
      NR_OPEN (historically set to 1024*1024) actually forbids processes to open
      more than 1024*1024 handles.
      
      Unfortunatly some production servers hit the not so 'ridiculously high
      value' of 1024*1024 file descriptors per process.
      
      Changing NR_OPEN is not considered safe because of vmalloc space potential
      exhaust.
      
      This patch introduces a new sysctl (/proc/sys/fs/nr_open) wich defaults to
      1024*1024, so that admins can decide to change this limit if their workload
      needs it.
      
      [akpm@linux-foundation.org: export it for sparc64]
      Signed-off-by: NEric Dumazet <dada1@cosmosbay.com>
      Cc: Alan Cox <alan@lxorguk.ukuu.org.uk>
      Cc: Richard Henderson <rth@twiddle.net>
      Cc: Ivan Kokshaysky <ink@jurassic.park.msu.ru>
      Cc: "David S. Miller" <davem@davemloft.net>
      Cc: Ralf Baechle <ralf@linux-mips.org>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      9cfe015a
  19. 01 11月, 2007 1 次提交
  20. 09 8月, 2007 1 次提交
  21. 22 7月, 2007 1 次提交
  22. 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
  23. 16 7月, 2007 2 次提交
    • D
      [SPARC64]: More sensible udelay implementation. · 8b99cfb8
      David S. Miller 提交于
      Take a page from the powerpc folks and just calculate the
      delay factor directly.
      
      Since frequency scaling chips use a system-tick register,
      the value is going to be the same system-wide.
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      8b99cfb8
    • D
      [SPARC64]: Initial LDOM cpu hotplug support. · 4f0234f4
      David S. Miller 提交于
      Only adding cpus is supports at the moment, removal
      will come next.
      
      When new cpus are configured, the machine description is
      updated.  When we get the configure request we pass in a
      cpu mask of to-be-added cpus to the mdesc CPU node parser
      so it only fetches information for those cpus.  That code
      also proceeds to update the SMT/multi-core scheduling bitmaps.
      
      cpu_up() does all the work and we return the status back
      over the DS channel.
      
      CPUs via dr-cpu need to be booted straight out of the
      hypervisor, and this requires:
      
      1) A new trampoline mechanism.  CPUs are booted straight
         out of the hypervisor with MMU disabled and running in
         physical addresses with no mappings installed in the TLB.
      
         The new hvtramp.S code sets up the critical cpu state,
         installs the locked TLB mappings for the kernel, and
         turns the MMU on.  It then proceeds to follow the logic
         of the existing trampoline.S SMP cpu bringup code.
      
      2) All calls into OBP have to be disallowed when domaining
         is enabled.  Since cpus boot straight into the kernel from
         the hypervisor, OBP has no state about that cpu and therefore
         cannot handle being invoked on that cpu.
      
         Luckily it's only a handful of interfaces which can be called
         after the OBP device tree is obtained.  For example, rebooting,
         halting, powering-off, and setting options node variables.
      
      CPU removal support will require some infrastructure changes
      here.  Namely we'll have to process the requests via a true
      kernel thread instead of in a workqueue.  workqueues run on
      a per-cpu thread, but when unconfiguring we might need to
      force the thread to execute on another cpu if the current cpu
      is the one being removed.  Removal of a cpu also causes the kernel
      to destroy that cpu's workqueue running thread.
      
      Another issue on removal is that we may have interrupts still
      pointing to the cpu-to-be-removed.  So new code will be needed
      to walk the active INO list and retarget those cpus as-needed.
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      4f0234f4
  24. 08 6月, 2007 1 次提交
  25. 26 4月, 2007 1 次提交
  26. 13 2月, 2007 2 次提交
  27. 22 7月, 2006 1 次提交