1. 02 2月, 2008 10 次提交
    • 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
    • H
      x86: make early_console static in early_printk.c · bb0e1290
      Harvey Harrison 提交于
      Not necessary to expose it, also fixes sparse warning.
      
      arch/x86/kernel/early_printk.c:196:16: warning: symbol 'early_console' was not declared. Should it be static?
      Signed-off-by: NHarvey Harrison <harvey.harrison@gmail.com>
      Signed-off-by: NIngo Molnar <mingo@elte.hu>
      bb0e1290
    • Y
      x86: remove unneeded round_up · 9347e0b0
      Yinghai Lu 提交于
      Signed-off-by: NYinghai Lu <yinghai.lu@sun.com>
      Signed-off-by: NIngo Molnar <mingo@elte.hu>
      9347e0b0
    • S
      x86: fix section mismatch warning in kernel/pci-calgary · 31f3dff6
      Sam Ravnborg 提交于
      Fix following warning:
      WARNING: arch/x86/kernel/built-in.o(.text+0x1eb41): Section mismatch in reference from the function calgary_handle_quirks() to the function .init.text:calgary_set_split_completion_timeout()
      
      calgary_handle_quirks() are only called at
      __init time (in calgary_init_one() via handle_quirks ops).
      So annotate this function and the sister function __init.
      Signed-off-by: NSam Ravnborg <sam@ravnborg.org>
      Signed-off-by: NIngo Molnar <mingo@elte.hu>
      31f3dff6
    • S
      x86: fix section mismatch warning in acpi/boot.c · 009cbadb
      Sam Ravnborg 提交于
      Fix following warning:
      WARNING: o-x86_64/arch/x86/kernel/built-in.o(.text+0x13d15): Section mismatch in reference from the function acpi_map_lsapic() to the function .cpuinit.text:mp_register_lapic()
      
      The function acpi_map_lsapic() is exported and thus not annotated.
      But the sole user is acpi/processor_core.c in a __cpuinit path.
      So create a small wrapper and put back the annotation thus
      avoiding the warning.
      Signed-off-by: NSam Ravnborg <sam@ravnborg.org>
      Signed-off-by: NIngo Molnar <mingo@elte.hu>
      009cbadb
    • S
      x86: fix section mismatch warnings when referencing notifiers · c72258c7
      Sam Ravnborg 提交于
      Fix the following warnings:
      WARNING: arch/x86/kernel/built-in.o(.exit.text+0xf8): Section mismatch in reference from the function msr_exit() to the variable .cpuinit.data:msr_class_cpu_notifier
      WARNING: arch/x86/kernel/built-in.o(.exit.text+0x158): Section mismatch in reference from the function cpuid_exit() to the variable .cpuinit.data:cpuid_class_cpu_notifier
      WARNING: arch/x86/kernel/built-in.o(.exit.text+0x171): Section mismatch in reference from the function microcode_exit() to the variable .cpuinit.data:mc_cpu_notifier
      
      In all three cases there were a function annotated __exit
      that referenced a variable annotated __cpuinitdata.
      
      The fix was to replace the annotation of the notifier
      with __refdata to tell modpost that the reference to
      a _cpuinit function in the notifier are OK.
      The unregister call that references the notifier
      variable will simple delete the function pointer
      so there is no problem ignoring the reference.
      
      Note: This looks like another case where __cpuinit
      has been used as replacement for proper use
      of CONFIG_HOTPLUG_CPU to decide what code are used for
      HOTPLUG_CPU.
      Signed-off-by: NSam Ravnborg <sam@ravnborg.org>
      Cc: "H. Peter Anvin" <hpa@zytor.com>
      Signed-off-by: NIngo Molnar <mingo@elte.hu>
      c72258c7
    • S
      x86: silence section mismatch warning in smpboot_64.c · 69e97c02
      Sam Ravnborg 提交于
      Silence the following warning:
      WARNING: o-x86_64/arch/x86/kernel/built-in.o(.text+0x17cd3): Section mismatch in reference from the function remove_cpu_from_maps() to the variable .cpuinit.data:cpu_initialized
      
      remove_cpu:maps() had a single user: __cpu_disable() so
      mark it static and annotate it with __ref to silence the
      warning from modpost.
      
      _cpu_disable() has a single user in kernel/cpu.c:
       => take_cpu_down()
          which again has a single user in the following call:
          => __stop_machine_run(take_cpu_down, &tcd_param, cpu);
      Here a kthread is created.
      
      So maybe the warning is correct and the right fix is to
      remove the __cpuinitdata annotation of cpu_initialized?
      
      Note: The analysis were disturbed by the fact that we had a variable
            with the same name in cpu/common.c - but this is 32 bit only]
      Note: Should smpboot_64 use cpu_clear()?
      Signed-off-by: NSam Ravnborg <sam@ravnborg.org>
      Cc: "H. Peter Anvin" <hpa@zytor.com>
      Signed-off-by: NIngo Molnar <mingo@elte.hu>
      69e97c02
    • Y
      x86: fix comments in vmlinux_64.lds · 32ed937d
      Yinghai Lu 提交于
      for bzImage, the vmlinux_64.lds still have s32 bit code, and startup_32
      should be 0. fix the comment.
      Signed-off-by: NYinghai Lu <yinghai.lu@sun.com>
      Signed-off-by: NIngo Molnar <mingo@elte.hu>
      32ed937d
    • Y
      x86_64: make bootmap_start page align v6 · 24a5da73
      Yinghai Lu 提交于
      boot oopses when a system has 64 or 128 GB of RAM installed:
      
      Calling initcall 0xffffffff80bc33b6: sctp_init+0x0/0x711()
      BUG: unable to handle kernel NULL pointer dereference at 000000000000005f
      IP: [<ffffffff802bfe55>] proc_register+0xe7/0x10f
      PGD 0
      Oops: 0000 [1] SMP
      CPU 0
      Modules linked in:
      Pid: 1, comm: swapper Not tainted 2.6.24-smp-g5a514e21-dirty #6
      RIP: 0010:[<ffffffff802bfe55>]  [<ffffffff802bfe55>] proc_register+0xe7/0x10f
      RSP: 0000:ffff810824c57e60  EFLAGS: 00010246
      RAX: 000000000000d7d7 RBX: ffff811024c5fa80 RCX: ffff810824c57e08
      RDX: 0000000000000000 RSI: 0000000000000195 RDI: ffffffff80cc2460
      RBP: ffffffffffffffff R08: 0000000000000000 R09: ffff811024c5fa80
      R10: 0000000000000000 R11: 0000000000000002 R12: ffff810824c57e6c
      R13: 0000000000000000 R14: ffff810824c57ee0 R15: 00000006abd25bee
      FS:  0000000000000000(0000) GS:ffffffff80b4d000(0000) knlGS:0000000000000000
      CS:  0010 DS: 0018 ES: 0018 CR0: 000000008005003b
      CR2: 000000000000005f CR3: 0000000000201000 CR4: 00000000000006e0
      DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
      DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
      Process swapper (pid: 1, threadinfo ffff810824c56000, task ffff812024c52000)
      Stack:  ffffffff80a57348 0000019500000000 ffff811024c5fa80 0000000000000000
       00000000ffffff97 ffffffff802bfef0 0000000000000000 ffffffffffffffff
       0000000000000000 ffffffff80bc3b4b ffff810824c57ee0 ffffffff80bc34a5
      Call Trace:
       [<ffffffff802bfef0>] ? create_proc_entry+0x73/0x8a
       [<ffffffff80bc3b4b>] ? sctp_snmp_proc_init+0x1c/0x34
       [<ffffffff80bc34a5>] ? sctp_init+0xef/0x711
       [<ffffffff80b976e3>] ? kernel_init+0x175/0x2e1
       [<ffffffff8020ccf8>] ? child_rip+0xa/0x12
       [<ffffffff80b9756e>] ? kernel_init+0x0/0x2e1
       [<ffffffff8020ccee>] ? child_rip+0x0/0x12
      
      Code: 1e 48 83 7b 38 00 75 08 48 c7 43 38 f0 e8 82 80 48 83 7b 30 00 75 08 48 c7 43 30 d0 e9 82 80 48 c7 c7 60 24 cc 80 e8 bd 5a 54 00 <48> 8b 45 60 48 89 6b 58 48 89 5d 60 48 89 43 50 fe 05 f5 25 a0
      RIP  [<ffffffff802bfe55>] proc_register+0xe7/0x10f
       RSP <ffff810824c57e60>
      CR2: 000000000000005f
      ---[ end trace 02c2d78def82877a ]---
      Kernel panic - not syncing: Attempted to kill init!
      
      it turns out some variables near end of bss are corrupted already.
      
      in System.map we have
      ffffffff80d40420 b rsi_table
      ffffffff80d40620 B krb5_seq_lock
      ffffffff80d40628 b i.20437
      ffffffff80d40630 b xprt_rdma_inline_write_padding
      ffffffff80d40638 b sunrpc_table_header
      ffffffff80d40640 b zero
      ffffffff80d40644 b min_memreg
      ffffffff80d40648 b rpcrdma_tk_lock_g
      ffffffff80d40650 B sctp_assocs_id_lock
      ffffffff80d40658 B proc_net_sctp
      ffffffff80d40660 B sctp_assocs_id
      ffffffff80d40680 B sysctl_sctp_mem
      ffffffff80d40690 B sysctl_sctp_rmem
      ffffffff80d406a0 B sysctl_sctp_wmem
      ffffffff80d406b0 b sctp_ctl_socket
      ffffffff80d406b8 b sctp_pf_inet6_specific
      ffffffff80d406c0 b sctp_pf_inet_specific
      ffffffff80d406c8 b sctp_af_v4_specific
      ffffffff80d406d0 b sctp_af_v6_specific
      ffffffff80d406d8 b sctp_rand.33270
      ffffffff80d406dc b sctp_memory_pressure
      ffffffff80d406e0 b sctp_sockets_allocated
      ffffffff80d406e4 b sctp_memory_allocated
      ffffffff80d406e8 b sctp_sysctl_header
      ffffffff80d406f0 b zero
      ffffffff80d406f4 A __bss_stop
      ffffffff80d406f4 A _end
      
      and setup_node_bootmem() will use that page 0xd40000 for bootmap
      Bootmem setup node 0 0000000000000000-0000000828000000
        NODE_DATA [000000000008a485 - 0000000000091484]
        bootmap [0000000000d406f4 -  0000000000e456f3] pages 105
      Bootmem setup node 1 0000000828000000-0000001028000000
        NODE_DATA [0000000828000000 - 0000000828006fff]
        bootmap [0000000828007000 -  0000000828106fff] pages 100
      Bootmem setup node 2 0000001028000000-0000001828000000
        NODE_DATA [0000001028000000 - 0000001028006fff]
        bootmap [0000001028007000 -  0000001028106fff] pages 100
      Bootmem setup node 3 0000001828000000-0000002028000000
        NODE_DATA [0000001828000000 - 0000001828006fff]
        bootmap [0000001828007000 -  0000001828106fff] pages 100
      
      setup_node_bootmem() makes NODE_DATA cacheline aligned,
      and bootmap is page-aligned.
      
      the patch updates find_e820_area() to make sure we can meet
      the alignment constraints.
      Signed-off-by: NYinghai Lu <yinghai.lu@sun.com>
      Signed-off-by: NIngo Molnar <mingo@elte.hu>
      24a5da73
    • Y
      x86_64: add debug name for early_res · 25eff8d4
      Yinghai Lu 提交于
      helps debugging problems in this rather murky area of code.
      Signed-off-by: NYinghai Lu <yinghai.lu@sun.com>
      Signed-off-by: NIngo Molnar <mingo@elte.hu>
      25eff8d4
  2. 01 2月, 2008 30 次提交