1. 03 2月, 2007 1 次提交
  2. 11 1月, 2007 1 次提交
    • V
      [PATCH] i386: cpu hotplug/smpboot misc MODPOST warning fixes · 4a5d107a
      Vivek Goyal 提交于
      o Misc smpboot/cpu hotplug path cleanups. I did those to supress the
        warnings generated by MODPOST. These warnings are visible only
        if CONFIG_RELOCATABLE=y.
      
      o CONFIG_RELOCATABLE compiles the kernel with --emit-relocs option. This
        option retains relocation information in vmlinux file and MODPOST
        is quick to spit out "Section mismatch" warnings.
      
      o This patch fixes some of those warnings. Many of the functions in
        smpboot case are __devinit type and they in turn accesses text/data which
        if of type __cpuinit. Now if CONFIG_HOTPLUG=y and CONFIG_HOTPLUG_CPU=n
        then we end up in cases where a function in .text segment is calling
        another function in .init.text segment and MODPOST emits warning.
      
      WARNING: vmlinux - Section mismatch: reference to .init.text:identify_cpu from .text between 'smp_store_cpu_info' (at offset 0xc011020d) and 'do_boot_cpu'
      WARNING: vmlinux - Section mismatch: reference to .init.text:init_gdt from .text between 'do_boot_cpu' (at offset 0xc01102ca) and '__cpu_up'
      WARNING: vmlinux - Section mismatch: reference to .init.text:print_cpu_info from .text between 'do_boot_cpu' (at offset 0xc01105d0) and '__cpu_up'
      
      o It also fixes the issues where CONFIG_HOTPLUG_CPU=y and start_secondary()
        is calling smp_callin() which in-turn calls synchronize_tsc_ap() which is
        of type __init. This should have meant broken CPU hotplug.
      
      WARNING: vmlinux - Section mismatch: reference to .init.data: from .text between 'start_secondary' (at offset 0xc011603f) and 'initialize_secondary'
      WARNING: vmlinux - Section mismatch: reference to .init.data: from .text between 'MP_processor_info' (at offset 0xc0116a4f) and 'mp_register_lapic'
      WARNING: vmlinux - Section mismatch: reference to .init.data: from .text between 'MP_processor_info' (at offset 0xc0116a4f) and 'mp_register_lapic'
      Signed-off-by: NVivek Goyal <vgoyal@in.ibm.com>
      Signed-off-by: NAndrew Morton <akpm@osdl.org>
      Signed-off-by: NAndi Kleen <ak@suse.de>
      4a5d107a
  3. 07 12月, 2006 1 次提交
  4. 26 9月, 2006 5 次提交
  5. 01 7月, 2006 1 次提交
  6. 09 5月, 2006 1 次提交
    • K
      [PATCH] x86_64: avoid IRQ0 ioapic pin collision · e0c1e9bf
      Kimball Murray 提交于
      The patch addresses a problem with ACPI SCI interrupt entry, which gets
      re-used, and the IRQ is assigned to another unrelated device.  The patch
      corrects the code such that SCI IRQ is skipped and duplicate entry is
      avoided.  Second issue came up with VIA chipset, the problem was caused by
      original patch assigning IRQs starting 16 and up.  The VIA chipset uses
      4-bit IRQ register for internal interrupt routing, and therefore cannot
      handle IRQ numbers assigned to its devices.  The patch corrects this
      problem by allowing PCI IRQs below 16.
      
      Cc: len.brown@intel.com
      
      Signed-off by: Natalie Protasevich <Natalie.Protasevich@unisys.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>
      e0c1e9bf
  7. 11 4月, 2006 2 次提交
    • R
      [PATCH] mpparse: prevent table index out-of-bounds · c0ec31ad
      Randy Dunlap 提交于
      John Z. Bohach <jzb@aexorsyst.com> found this bug:
      
        If the board has more than 32 PCI busses on it, the mptable bus array will
        overwrite its bounds for the PCI busses, and stomp on anything that's after
        it.
      
      Prevent possible table overflow and unknown data corruption.  Code is in an
      __init section so it will be discarded after init.
      Signed-off-by: NRandy Dunlap <rdunlap@xenotime.net>
      Signed-off-by: NAndrew Morton <akpm@osdl.org>
      Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
      c0ec31ad
    • A
      [PATCH] swsusp: don't require bigsmp · 6cf272ac
      Ashok Raj 提交于
      Switching to automatic bigsmp causes a misleading error message, that more
      then 8 cpus are detected, and user needs to select either X86_GENERICARCH
      or X86_BIGSMP to handle.
      
      Reason is we switched to bigsmp to avoid IP race when new cpu is comming
      up.  [bigsmp is nothing but using physical flat mode that can work for 1 ..
       255 cpus] [default is X86_PC, that uses logical flat mode up to 8 CPUs
      max] Current x86_64 code uses bigsmp as default when hotplug is enabled.
      
      It would be preferable to make bigsmp as default, and work the dependencies
      of other related code like SMP_SUSPEND, and some related to memory hotplug
      code for i386.
      
      Current logical flat mode doesnt use shortcuts that cause the race by using
      the send_IPI_mask() instead of shortcuts when HOTPLUG_CPU is enabled.
      
      In the meantime this patch is the path of lease resistance.
      
      We will switch to bigsmp default sometime soon, when we get to work it again.
      Signed-off-by: NAshok Raj <ashok.raj@intel.com>
      Cc: Pavel Machek <pavel@ucw.cz>
      Cc: "Rafael J. Wysocki" <rjw@sisk.pl>
      Cc: Nigel Cunningham <nigel@suspend2.net>
      Signed-off-by: NAndrew Morton <akpm@osdl.org>
      Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
      6cf272ac
  8. 10 4月, 2006 1 次提交
    • A
      [PATCH] i386: Consolidate modern APIC handling · 95d769aa
      Andi Kleen 提交于
      AMD systems have a modern APIC that supports 8 bit IDs, but
      don't have a XAPIC version number.  Add a new "modern_apic"
      subfunction that handles this correctly and use it (nearly)
      everywhere where XAPIC is tested for.
      
      I removed one wart: the code specified that external APICs
      would use an 8bit APIC ID. But I checked a real 82093 data sheet
      and it says clearly that they only use 4bit. So I removed
      this special case since it would a bit awkward to implement now.
      
      I removed the valid APIC tests in mptable parsing completely. On any modern
      system they only check against the full field width (8bit) anyways
      and are no-ops. This also fixes them doing the wrong thing
      on >8 core Opterons.
      
      This makes i386 boot again on 16 core Opterons.
      
      Cc: Ingo Molnar <mingo@elte.hu>
      Signed-off-by: NAndi Kleen <ak@suse.de>
      Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
      95d769aa
  9. 23 3月, 2006 2 次提交
  10. 27 2月, 2006 1 次提交
  11. 21 2月, 2006 1 次提交
  12. 07 1月, 2006 1 次提交
  13. 28 12月, 2005 1 次提交
  14. 21 11月, 2005 1 次提交
  15. 31 10月, 2005 2 次提交
  16. 27 9月, 2005 1 次提交
  17. 10 9月, 2005 1 次提交
  18. 05 9月, 2005 2 次提交
  19. 25 8月, 2005 3 次提交
  20. 30 7月, 2005 1 次提交
    • N
      [PATCH] x86: avoid wasting IRQs patch update · e1afc3f5
      Natalie.Protasevich@unisys.com 提交于
      The patch addresses a problem with ACPI SCI interrupt entry, which gets
      re-used, and the IRQ is assigned to another unrelated device.  The patch
      corrects the code such that SCI IRQ is skipped and duplicate entry is
      avoided.  Second issue came up with VIA chipset, the problem was caused by
      original patch assigning IRQs starting 16 and up.  The VIA chipset uses
      4-bit IRQ register for internal interrupt routing, and therefore cannot
      handle IRQ numbers assigned to its devices.  The patch corrects this
      problem by allowing PCI IRQs below 16.
      
      Signed-off by: Natalie Protasevich <Natalie.Protasevich@unisys.com>
      Signed-off-by: NAndrew Morton <akpm@osdl.org>
      Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
      e1afc3f5
  21. 26 6月, 2005 1 次提交
  22. 24 6月, 2005 2 次提交
  23. 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