1. 06 9月, 2008 2 次提交
    • Y
      x86, cpu init: call early_init_xxx in init_xxx · e3224234
      Yinghai Lu 提交于
      so we:
      
       1. could set some cap to ap
       2. restore some cap after memset in identify_cpu for boot cpu
      
      esp for CONSTANT_TSC this matters, as:
      
      before this patch:
       flags           : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush mmx fxsr sse sse2 ht syscall nx mmxext fxsr_opt pdpe1gb rdtscp lm 3dnowext 3dnow rep_good nopl pni monitor cx16 lahf_lm cmp_legacy svm extapic cr8_legacy abm sse4a misalignsse 3dnowprefetch osvw ibs
      
      after this patch:
       flags           : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush mmx fxsr sse sse2 ht syscall nx mmxext fxsr_opt pdpe1gb rdtscp lm 3dnowext 3dnow constant_tsc rep_good nopl pni monitor cx16 lahf_lm cmp_legacy svm extapic cr8_legacy abm sse4a misalignsse 3dnowprefetch osvw ibs
      
      so constant_tsc is back...
      Signed-off-by: NYinghai Lu <yhlu.kernel@gmail.com>
      Signed-off-by: NIngo Molnar <mingo@elte.hu>
      e3224234
    • Y
      x86: remove duplicated get_model_name() calling · 1b05d60d
      Yinghai Lu 提交于
      Signed-off-by: NYinghai Lu <yhlu.kernel@gmail.com>
      Signed-off-by: NIngo Molnar <mingo@elte.hu>
      1b05d60d
  2. 05 9月, 2008 21 次提交
  3. 19 8月, 2008 1 次提交
  4. 31 7月, 2008 2 次提交
  5. 08 7月, 2008 1 次提交
  6. 25 5月, 2008 1 次提交
    • E
      percpu: introduce DEFINE_PER_CPU_PAGE_ALIGNED() macro · 63cc8c75
      Eric Dumazet 提交于
      While examining holes in percpu section I found this :
      
      c05f5000 D per_cpu__current_task
      c05f5000 D __per_cpu_start
      c05f5004 D per_cpu__cpu_number
      c05f5008 D per_cpu__irq_regs
      c05f500c d per_cpu__cpu_devices
      c05f5040 D per_cpu__cyc2ns
      
      <Big Hole of about 4000 bytes>
      
      c05f6000 d per_cpu__cpuid4_info
      c05f6004 d per_cpu__cache_kobject
      c05f6008 d per_cpu__index_kobject
      
      <Big Hole of about 4000 bytes>
      
      c05f7000 D per_cpu__gdt_page
      
      This is because gdt_page is a percpu variable, defined with
      a page alignement, and linker is doing its job, two times because of .o
      nesting in the build process.
      
      I introduced a new macro DEFINE_PER_CPU_PAGE_ALIGNED() to avoid
      wasting this space. All page aligned variables (only one at this time)
      are put in a separate
      subsection .data.percpu.page_aligned, at the very begining of percpu zone.
      
      Before patch , on a x86_32 machine :
      
      .data.percpu                30232   3227471872
      .data.percpu                22168   3227471872
      
      Thats 8064 bytes saved for each CPU.
      Signed-off-by: NEric Dumazet <dada1@cosmosbay.com>
      Signed-off-by: NIngo Molnar <mingo@elte.hu>
      Signed-off-by: NThomas Gleixner <tglx@linutronix.de>
      63cc8c75
  7. 08 5月, 2008 1 次提交
    • T
      x86: cleanup PAT cpu validation · 8d4a4300
      Thomas Gleixner 提交于
      Move the scattered checks for PAT support to a single function. Its
      moved to addon_cpuid_features.c as this file is shared between 32 and
      64 bit.
      
      Remove the manipulation of the PAT feature bit and just disable PAT in
      the PAT layer, based on the PAT bit provided by the CPU and the
      current CPU version/model white list.
      
      Change the boot CPU check so it works on Voyager somewhere in the
      future as well :) Also panic, when a secondary has PAT disabled but
      the primary one has alrady switched to PAT. We have no way to undo
      that.
      
      The white list is kept for now to ensure that we can rely on known to
      work CPU types and concentrate on the software induced problems
      instead of fighthing CPU erratas and subtle wreckage caused by not yet
      verified CPUs. Once the PAT code has stabilized enough, we can remove
      the white list and open the can of worms.
      Signed-off-by: NThomas Gleixner <tglx@linutronix.de>
      Signed-off-by: NIngo Molnar <mingo@elte.hu>
      8d4a4300
  8. 19 4月, 2008 1 次提交
  9. 17 4月, 2008 6 次提交
  10. 26 2月, 2008 1 次提交
    • M
      x86: fix boot failure on 486 due to TSC breakage · 12c247a6
      Mikael Pettersson 提交于
       > Diffing dmesg between git7 and git8 doesn't sched any light since
       > git8 also removed the printouts of the x86 caps as they were being
       > initialised and updated. I'm currently adding those printouts back
       > in the hope of seeing where and when the caps get broken.
      
      That turned out to be very illuminating:
      
       --- dmesg-2.6.24-git7	2008-02-24 18:01:25.295851000 +0100
       +++ dmesg-2.6.24-git8	2008-02-24 18:01:25.530358000 +0100
       ...
       CPU: After generic identify, caps: 00000003 00000000 00000000 00000000 00000000 00000000 00000000 00000000
      
       CPU: After all inits, caps: 00000003 00000000 00000000 00000000 00000000 00000000 00000000 00000000
      +CPU: After applying cleared_cpu_caps, caps: 00000013 00000000 00000000 00000000 00000000 00000000 00000000 00000000
      
      Notice how the TSC cap bit goes from Off to On.
      
      (The first two lines are printout loops from -git7 forward-ported
      to -git8, the third line is the same printout loop added just after
      the xor-with-cleared_cpu_caps[] loop.)
      
      Here's how the breakage occurs:
      1. arch/x86/kernel/tsc_32.c:tsc_init() sees !cpu_has_tsc,
         so bails and calls setup_clear_cpu_cap(X86_FEATURE_TSC).
      2. include/asm-x86/cpufeature.h:setup_clear_cpu_cap(bit) clears
         the bit in boot_cpu_data and sets it in cleared_cpu_caps
      3. arch/x86/kernel/cpu/common.c:identify_cpu() XORs all caps
         in with cleared_cpu_caps
         HOWEVER, at this point c->x86_capability correctly has TSC
         Off, cleared_cpu_caps has TSC On, so the XOR incorrectly
         sets TSC to On in c->x86_capability, with disastrous results.
      
      The real bug is that clearing bits with XOR only works if the
      bits are known to be 1 prior to the XOR, and that's not true here.
      
      A simple fix is to convert the XOR to AND-NOT instead. The following
      patch does that, and allows my 486 to boot 2.6.25-rc kernels again.
      
      [ mingo@elte.hu: fixed a similar bug in setup_64.c as well. ]
      
      The breakage was introduced via commit 7d851c8d.
      Signed-off-by: NMikael Pettersson <mikpe@it.uu.se>
      Signed-off-by: NIngo Molnar <mingo@elte.hu>
      12c247a6
  11. 07 2月, 2008 1 次提交
  12. 04 2月, 2008 1 次提交
    • H
      x86: add cpu init function defintions to cpu.h · b6d549a2
      Harvey Harrison 提交于
      cpu.h was already included everywhere needed.
      
      Fixes following sparse warnings:
      
      arch/x86/kernel/cpu/amd.c:343:12: warning: symbol 'amd_init_cpu' was not declared. Should it be static?
      arch/x86/kernel/cpu/cyrix.c:444:12: warning: symbol 'cyrix_init_cpu' was not declared. Should it be static?
      arch/x86/kernel/cpu/cyrix.c:456:12: warning: symbol 'nsc_init_cpu' was not declared. Should it be static?
      arch/x86/kernel/cpu/centaur.c:467:12: warning: symbol 'centaur_init_cpu' was not declared. Should it be static?
      arch/x86/kernel/cpu/transmeta.c:112:12: warning: symbol 'transmeta_init_cpu' was not declared. Should it be static?
      arch/x86/kernel/cpu/intel.c:296:12: warning: symbol 'intel_cpu_init' was not declared. Should it be static?
      arch/x86/kernel/cpu/nexgen.c:56:12: warning: symbol 'nexgen_init_cpu' was not declared. Should it be static?
      arch/x86/kernel/cpu/umc.c:22:12: warning: symbol 'umc_init_cpu' was not declared. Should it be static?
      Signed-off-by: NHarvey Harrison <harvey.harrison@gmail.com>
      Signed-off-by: NIngo Molnar <mingo@elte.hu>
      Signed-off-by: NThomas Gleixner <tglx@linutronix.de>
      b6d549a2
  13. 02 2月, 2008 1 次提交
    • H
      x86: fix sparse warnings in cpu/common.c · 4a148513
      Harvey Harrison 提交于
      The casts will always be needed, may as well make them the right
      signedness.  The ebx variables can easily be unsigned, may as well.
      
      arch/x86/kernel/cpu/common.c:261:21: warning: incorrect type in argument 2 (different signedness)
      arch/x86/kernel/cpu/common.c:261:21:    expected unsigned int *eax
      arch/x86/kernel/cpu/common.c:261:21:    got int *<noident>
      arch/x86/kernel/cpu/common.c:262:9: warning: incorrect type in argument 3 (different signedness)
      arch/x86/kernel/cpu/common.c:262:9:    expected unsigned int *ebx
      arch/x86/kernel/cpu/common.c:262:9:    got int *<noident>
      arch/x86/kernel/cpu/common.c:263:9: warning: incorrect type in argument 4 (different signedness)
      arch/x86/kernel/cpu/common.c:263:9:    expected unsigned int *ecx
      arch/x86/kernel/cpu/common.c:263:9:    got int *<noident>
      arch/x86/kernel/cpu/common.c:264:9: warning: incorrect type in argument 5 (different signedness)
      arch/x86/kernel/cpu/common.c:264:9:    expected unsigned int *edx
      arch/x86/kernel/cpu/common.c:264:9:    got int *<noident>
      arch/x86/kernel/cpu/common.c:293:30: warning: incorrect type in argument 3 (different signedness)
      arch/x86/kernel/cpu/common.c:293:30:    expected unsigned int *ebx
      arch/x86/kernel/cpu/common.c:293:30:    got int *<noident>
      arch/x86/kernel/cpu/common.c:350:22: warning: incorrect type in argument 2 (different signedness)
      arch/x86/kernel/cpu/common.c:350:22:    expected unsigned int *eax
      arch/x86/kernel/cpu/common.c:350:22:    got int *<noident>
      arch/x86/kernel/cpu/common.c:351:10: warning: incorrect type in argument 3 (different signedness)
      arch/x86/kernel/cpu/common.c:351:10:    expected unsigned int *ebx
      arch/x86/kernel/cpu/common.c:351:10:    got int *<noident>
      arch/x86/kernel/cpu/common.c:352:10: warning: incorrect type in argument 4 (different signedness)
      arch/x86/kernel/cpu/common.c:352:10:    expected unsigned int *ecx
      arch/x86/kernel/cpu/common.c:352:10:    got int *<noident>
      arch/x86/kernel/cpu/common.c:353:10: warning: incorrect type in argument 5 (different signedness)
      arch/x86/kernel/cpu/common.c:353:10:    expected unsigned int *edx
      arch/x86/kernel/cpu/common.c:353:10:    got int *<noident>
      arch/x86/kernel/cpu/common.c:362:30: warning: incorrect type in argument 3 (different signedness)
      arch/x86/kernel/cpu/common.c:362:30:    expected unsigned int *ebx
      arch/x86/kernel/cpu/common.c:362:30:    got int *<noident>
      Signed-off-by: NHarvey Harrison <harvey.harrison@gmail.com>
      Signed-off-by: NIngo Molnar <mingo@elte.hu>
      4a148513