1. 26 3月, 2006 3 次提交
    • A
      [PATCH] x86_64: Limit max number of CPUs to 255 · 01d4bed4
      Andi Kleen 提交于
      Because 256 causes overflows in some code that stores them in 8 bit
      fields and the x86 APIC architecture cannot handle more than 255
      anyways.
      Signed-off-by: NAndi Kleen <ak@suse.de>
      Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
      01d4bed4
    • A
      [PATCH] x86_64: Basic reorder infrastructure · 4bdc3b7f
      Arjan van de Ven 提交于
      This patch puts the infrastructure in place to allow for a reordering of
      functions based inside the vmlinux. The general idea is that it is possible
      to put all "common" functions into the first 2Mb of the code, so that they
      are covered by one TLB entry. This as opposed to the current situation where
      a typical vmlinux covers about 3.5Mb (on x86-64) and thus 2 TLB entries.
      
      This is done by enabling the -ffunction-sections flag in gcc, which puts
      each function in its own ELF section, so that the linker can then order them
      in a way defined by the linker script.
      
      As per previous discussions, Linus said he wanted a "static" list for this,
      eg a list provided by the kernel tarbal, so that most people have the same
      ordering at least. A script is provided to create this list based on
      readprofile(1) output. The included list is provisional, and entirely biased
      on my own testbox and me running a few kernel compiles and some other
      things.
      
      I think that to get to a better list we need to invite people to submit
      their own profiles, and somehow add those all up and base the final list on
      that. I'm willing to do that effort if this is ends up being the prefered
      approach. Such an effort probably needs to be repeated like once a year or
      so to adopt to the changing nature of the kernel.
      
      Made it a CONFIG with default n because it increases link times
      dramatically.
      Signed-off-by: NAndi Kleen <ak@suse.de>
      Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
      4bdc3b7f
    • A
      [PATCH] x86_64: Move kernel to 2MB · 04103609
      Andi Kleen 提交于
      As suggested by Andi (and Alan), move the default kernel location
      from 1Mb to 2Mb, to align to the start of a TLB entry.
      Signed-off-by: NArjan van de Ven <arjan@linux.intel.com>
      Signed-off-by: NAndi Kleen <ak@suse.de>
      Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
      04103609
  2. 27 2月, 2006 2 次提交
  3. 17 1月, 2006 2 次提交
  4. 12 1月, 2006 3 次提交
  5. 11 1月, 2006 2 次提交
    • M
      [PATCH] kexec: change CONFIG_PHYSICAL_START dependency · 05970d47
      Maneesh Soni 提交于
      I have heard some complaints about people not finding CONFIG_CRASH_DUMP
      option and also some objections about its dependency on CONFIG_EMBEDDED.
      The following patch ends that dependency.  I thought of hiding it under
      CONFIG_KEXEC, but CONFIG_PHYSICAL_START could also be used for some reasons
      other than kexec/kdump and hence left it visible.  I will also update the
      documentation accordingly.
      
      o Following patch removes the config dependency of CONFIG_PHYSICAL_START
        on CONFIG_EMBEDDED. The reason being CONFIG_CRASH_DUMP option for
        kdump needs CONFIG_PHYSICAL_START which makes CONFIG_CRASH_DUMP depend
        on CONFIG_EMBEDDED. It is not always obvious for kdump users to choose
        CONFIG_EMBEDDED.
      
      o It also shifts the palce where this option appears, to make it closer
        to kexec and kdump options.
      Signed-off-by: NManeesh Soni <maneesh@in.ibm.com>
      Cc: "Eric W. Biederman" <ebiederm@xmission.com>
      Cc: Haren Myneni <haren@us.ibm.com>
      Signed-off-by: NAndrew Morton <akpm@osdl.org>
      Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
      05970d47
    • V
      [PATCH] kdump: x86_64 save cpu registers upon crash · ec9ce0db
      Vivek Goyal 提交于
      - Saving the cpu registers of all cpus before booting in to the crash
        kernel.
      
      - crash_setup_regs will save the registers of the cpu on which panic has
        occured.  One of the concerns ppc64 folks raised is that after capturing the
        register states, one should not pop the current call frame and push new one.
         Hence it has been inlined.  More call frames later get pushed on to stack
        (machine_crash_shutdown() and machine_kexec()), but one will not want to
        backtrace those.
      
      - Not very sure about the CFI annotations.  With this patch I am getting
        decent backtrace with gdb.  Assuming, compiler has generated enough
        debugging information for crash_kexec().  Coding crash_setup_regs() in pure
        assembly makes it tricky because then it can not be inlined and we don't
        want to return back after capturing register states we don't want to pop
        this call frame.
      
      - Saving the non-panicing cpus registers will be done in the NMI handler
        while shooting down them in machine_crash_shutdown.
      
      - Introducing CRASH_DUMP option in Kconfig for x86_64.
      Signed-off-by: NMurali M Chakravarthy <muralim@in.ibm.com>
      Signed-off-by: NVivek Goyal <vgoyal@in.ibm.com>
      Cc: Andi Kleen <ak@muc.de>
      Cc: "Eric W. Biederman" <ebiederm@xmission.com>
      Signed-off-by: NAndrew Morton <akpm@osdl.org>
      Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
      ec9ce0db
  6. 09 1月, 2006 1 次提交
  7. 15 11月, 2005 3 次提交
  8. 07 11月, 2005 1 次提交
  9. 22 9月, 2005 1 次提交
  10. 15 9月, 2005 1 次提交
    • D
      [LIB]: Consolidate _atomic_dec_and_lock() · 4db2ce01
      David S. Miller 提交于
      Several implementations were essentialy a common piece of C code using
      the cmpxchg() macro.  Put the implementation in one spot that everyone
      can share, and convert sparc64 over to using this.
      
      Alpha is the lone arch-specific implementation, which codes up a
      special fast path for the common case in order to avoid GP reloading
      which a pure C version would require.
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      4db2ce01
  11. 08 9月, 2005 2 次提交
    • V
      [PATCH] Kconfig fix (BLK_DEV_FD dependencies) · a08b6b79
      viro@ZenIV.linux.org.uk 提交于
      Sanitized and fixed floppy dependencies: split the messy dependencies for
      BLK_DEV_FD by introducing a new symbol (ARCH_MAY_HAVE_PC_FDC), making
      BLK_DEV_FD depend on that one and taking declarations of ARCH_MAY_HAVE_PC_FDC
      to arch/*/Kconfig.  While we are at it, fixed several obvious cases when
      BLK_DEV_FD should have been excluded (architectures lacking asm/floppy.h
      are *not* going to have floppy.c compile, let alone work).
      
      If you can come up with better name for that ("this architecture might
      have working PC-compatible floppy disk controller"), you are more than
      welcome - just s/ARCH_MAY_HAVE_PC_FDC/your_prefered_name/g in the patch
      below...
      Signed-off-by: NAl Viro <viro@zeniv.linux.org.uk>
      Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
      a08b6b79
    • A
      [PATCH] x86/x86_64: deferred handling of writes to /proc/irqxx/smp_affinity · 54d5d424
      Ashok Raj 提交于
      When handling writes to /proc/irq, current code is re-programming rte
      entries directly. This is not recommended and could potentially cause
      chipset's to lockup, or cause missing interrupts.
      
      CONFIG_IRQ_BALANCE does this correctly, where it re-programs only when the
      interrupt is pending. The same needs to be done for /proc/irq handling as well.
      Otherwise user space irq balancers are really not doing the right thing.
      
      - Changed pending_irq_balance_cpumask to pending_irq_migrate_cpumask for
        lack of a generic name.
      - added move_irq out of IRQ_BALANCE, and added this same to X86_64
      - Added new proc handler for write, so we can do deferred write at irq
        handling time.
      - Display of /proc/irq/XX/smp_affinity used to display CPU_MASKALL, instead
        it now shows only active cpu masks, or exactly what was set.
      - Provided a common move_irq implementation, instead of duplicating
        when using generic irq framework.
      
      Tested on i386/x86_64 and ia64 with CONFIG_PCI_MSI turned on and off.
      Tested UP builds as well.
      
      MSI testing: tbd: I have cards, need to look for a x-over cable, although I
      did test an earlier version of this patch.  Will test in a couple days.
      Signed-off-by: NAshok Raj <ashok.raj@intel.com>
      Acked-by: NZwane Mwaikambo <zwane@holomorphy.com>
      Grudgingly-acked-by: NAndi Kleen <ak@muc.de>
      Signed-off-by: NCoywolf Qi Hunt <coywolf@lovecn.org>
      Signed-off-by: NAshok Raj <ashok.raj@intel.com>
      Signed-off-by: NAndrew Morton <akpm@osdl.org>
      Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
      54d5d424
  12. 05 9月, 2005 1 次提交
  13. 25 8月, 2005 1 次提交
  14. 29 7月, 2005 1 次提交
  15. 12 7月, 2005 1 次提交
    • S
      [NET]: add a top-level Networking menu to *config · d5950b43
      Sam Ravnborg 提交于
      Create a new top-level menu named "Networking" thus moving
      net related options and protocol selection way from the drivers
      menu and up on the top-level where they belong.
      
      To implement this all architectures has to source "net/Kconfig" before
      drivers/*/Kconfig in their Kconfig file. This change has been
      implemented for all architectures.
      
      Device drivers for ordinary NIC's are still to be found
      in the Device Drivers section, but Bluetooth, IrDA and ax25
      are located with their corresponding menu entries under the new
      networking menu item.
      Signed-off-by: NSam Ravnborg <sam@ravnborg.org>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      d5950b43
  16. 26 6月, 2005 4 次提交
  17. 24 6月, 2005 3 次提交
  18. 01 6月, 2005 1 次提交
  19. 27 5月, 2005 1 次提交
    • A
      [PATCH] Note on ACPI build fix · 8aadff7d
      Alexander Nyberg 提交于
      Even after the previous fix you can still set CONFIG_ACPI_BOOT
      indirectly even without CONFIG_ACPI by choosing CONFIG_PCI and
      CONFIG_PCI_MMCONFIG.
      
      That doesn't build very well either.
      
      This makes PCI_MMCONFIG depend on ACPI, fixing that hole.
      
      [ I guess in theory Kconfig could follow the whole chain of dependencies
        for things that get selected, but that sounds insanely complicated, so
        we'll just fix up these things by hand.  --Linus ]
      Signed-off-by: NAlexander Nyberg <alexn@telia.com>
      Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
      8aadff7d
  20. 17 5月, 2005 1 次提交
    • A
      [PATCH] x86_64: Add pmtimer support · 312df5f1
      Andi Kleen 提交于
      There are unfortunately more and more multi processor Opteron systems which
      don't have HPET timer support in the southbridge.  This covers in particular
      Nvidia and VIA chipsets.  They also don't guarantee that the TSCs are
      synchronized between CPUs; and especially with MP powernow the systems are
      nearly unusable because the time gets very inconsistent between CPUs.
      
      The timer code for x86-64 was originally written under the assumption that we
      could fall back to the HPET timer on such systems.  But this doesn't work
      there.
      
      Another alternative is to use the ACPI PM timer as primary time source.  This
      patch does that.  The kernel only uses PM timer when there is no other choice
      because it has some disadvantages.
      
      Ported over from i386.  It should be faster than the i386 version because I
      dropped the "read three times" workaround, but is still considerable slower
      than HPET and also does not work together with vsyscalls which have to be
      disabled.
      
      Cc: <mark.langsdorf@amd.com>
      Signed-off-by: NAndi Kleen <ak@suse.de>
      Signed-off-by: NAndrew Morton <akpm@osdl.org>
      Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
      312df5f1
  21. 04 5月, 2005 1 次提交
    • A
      [PATCH] ISA DMA Kconfig fixes - part 1 · 5cae841b
      Al Viro 提交于
      A bunch of drivers use ISA DMA helpers or their equivalents for
      platforms that have ISA with different DMA controller (a lot of ARM
      boxen).  Currently there is no way to put such dependency in Kconfig -
      CONFIG_ISA is not it (e.g.  it is not set on platforms that have no ISA
      slots, but have on-board devices that pretend to be ISA ones).
      
      New symbol added - ISA_DMA_API.  Set when we have functional
      enable_dma()/set_dma_mode()/etc.  set of helpers.  Next patches in the
      series will add missing dependencies for drivers that need them.
      
      I'm very carefully staying the hell out of the recurring flamefest on
      what exactly CONFIG_ISA would mean in ideal world - added symbol has a
      well-defined meaning and for now I really want to treat it as completely
      independent from the mess around CONFIG_ISA.
      Signed-off-by: NAl Viro <viro@parcelfarce.linux.theplanet.co.uk>
      Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
      5cae841b
  22. 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