1. 02 2月, 2008 2 次提交
    • 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. 30 1月, 2008 21 次提交
  3. 20 10月, 2007 1 次提交
    • M
      x86: convert cpu_to_apicid to be a per cpu variable · 71fff5e6
      Mike Travis 提交于
      This patch converts the x86_cpu_to_apicid array to be a per cpu
      variable. This saves sizeof(apicid) * NR unused cpus.  Access is mostly
      from startup and CPU HOTPLUG functions.
      
      MP_processor_info() is one of the functions that require access to the
      x86_cpu_to_apicid array before the per_cpu data area is setup.  For this
      case, a pointer to the __initdata array is initialized in setup_arch()
      and removed in smp_prepare_cpus() after the per_cpu data area is
      initialized.
      
      A second change is included to change the initial array value of ARCH
      i386 from 0xff to BAD_APICID to be consistent with ARCH x86_64.
      Signed-off-by: NMike Travis <travis@sgi.com>
      Cc: Andi Kleen <ak@suse.de>
      Cc: Christoph Lameter <clameter@sgi.com>
      Cc: "Siddha, Suresh B" <suresh.b.siddha@intel.com>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NIngo Molnar <mingo@elte.hu>
      Signed-off-by: NThomas Gleixner <tglx@linutronix.de>
      71fff5e6
  4. 18 10月, 2007 2 次提交
    • M
      x86: fix cpu_to_node references · 98c9e27a
      Mike Travis 提交于
      In x86_64 and i386 architectures most arrays that are sized using
      NR_CPUS lay in local memory on node 0.  Not only will most (99%?) of the
      systems not use all the slots in these arrays, particularly when NR_CPUS
      is increased to accommodate future very high cpu count systems, but a
      number of cache lines are passed unnecessarily on the system bus when
      these arrays are referenced by cpus on other nodes.
      
      Typically, the values in these arrays are referenced by the cpu
      accessing it's own values, though when passing IPI interrupts, the cpu
      does access the data relevant to the targeted cpu/node.  Of course, if
      the referencing cpu is not on node 0, then the reference will still
      require cross node exchanges of cache lines.  A common use of this is
      for an interrupt service routine to pass the interrupt to other cpus
      local to that node.
      
      Ideally, all the elements in these arrays should be moved to the per_cpu
      data area.  In some cases (such as x86_cpu_to_apicid) the array is
      referenced before the per_cpu data areas are setup.  In this case, a
      static array is declared in the __initdata area and initialized by the
      booting cpu (BSP).  The values are then moved to the per_cpu area after
      it is initialized and the original static array is freed with the rest
      of the __initdata.
      
      This patch:
      
      Fix four instances where cpu_to_node is referenced by array instead of
      via the cpu_to_node macro.  This is preparation to moving it to the
      per_cpu data area.
      Signed-off-by: NMike Travis <travis@sgi.com>
      Cc: Andi Kleen <ak@suse.de>
      Cc: Christoph Lameter <clameter@sgi.com>
      Cc: "Siddha, Suresh B" <suresh.b.siddha@intel.com>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NIngo Molnar <mingo@elte.hu>
      Signed-off-by: NThomas Gleixner <tglx@linutronix.de>
      98c9e27a
    • Y
      x86: 0 -> NULL, for arch/x86_64 · 83e83d54
      Yoann Padioleau 提交于
      When comparing a pointer, it's clearer to compare it to NULL than to 0.
      
      [ tglx: arch/x86 adaptation ]
      Signed-off-by: NYoann Padioleau <padator@wanadoo.fr>
      Signed-off-by: NAndi Kleen <ak@suse.de>
      Cc: ak@suse.de
      Cc: discuss@x86-64.org
      Cc: akpm@linux-foundation.org
      Signed-off-by: NIngo Molnar <mingo@elte.hu>
      Signed-off-by: NThomas Gleixner <tglx@linutronix.de>
      83e83d54
  5. 11 10月, 2007 2 次提交
  6. 22 7月, 2007 3 次提交
  7. 03 5月, 2007 4 次提交
    • S
      [PATCH] x86-64: set node_possible_map at runtime - try 2 · e3f1caee
      Suresh Siddha 提交于
      Set the node_possible_map at runtime on x86_64.  On a non NUMA system,
      num_possible_nodes() will now say '1'.
      Signed-off-by: NSuresh Siddha <suresh.b.siddha@intel.com>
      Signed-off-by: NAndi Kleen <ak@suse.de>
      Cc: Andi Kleen <andi@firstfloor.org>
      Cc: Eric Dumazet <dada1@cosmosbay.com>
      Cc: David Rientjes <rientjes@google.com>
      Cc: Christoph Lameter <clameter@engr.sgi.com>
      e3f1caee
    • D
      [PATCH] x86-64: fixed size remaining fake nodes · 382591d5
      David Rientjes 提交于
      Extends the numa=fake x86_64 command-line option to split the remaining system
      memory into nodes of fixed size.  Any leftover memory is allocated to a final
      node unless the command-line ends with a comma.
      
      For example:
        numa=fake=2*512,*128	gives two 512M nodes and the remaining system
      			memory is split into nodes of 128M each.
      
      This is beneficial for systems where the exact size of RAM is unknown or not
      necessarily relevant, but the size of the remaining nodes to be allocated is
      known based on their capacity for resource management.
      
      Cc: Andi Kleen <ak@suse.de>
      Signed-off-by: NDavid Rientjes <rientjes@google.com>
      Signed-off-by: NAndi Kleen <ak@suse.de>
      Cc: Paul Jackson <pj@sgi.com>
      Cc: Christoph Lameter <clameter@engr.sgi.com>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      382591d5
    • D
      [PATCH] x86-64: split remaining fake nodes equally · 14694d73
      David Rientjes 提交于
      Extends the numa=fake x86_64 command-line option to split the remaining
      system memory into equal-sized nodes.
      
      For example:
      numa=fake=2*512,4*	gives two 512M nodes and the remaining system
      			memory is split into four approximately equal
      			chunks.
      
      This is beneficial for systems where the exact size of RAM is unknown or not
      necessarily relevant, but the granularity with which nodes shall be allocated
      is known.
      
      Cc: Andi Kleen <ak@suse.de>
      Signed-off-by: NDavid Rientjes <rientjes@google.com>
      Signed-off-by: NAndi Kleen <ak@suse.de>
      Cc: Paul Jackson <pj@sgi.com>
      Cc: Christoph Lameter <clameter@engr.sgi.com>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      14694d73
    • D
      [PATCH] x86-64: configurable fake numa node sizes · 8b8ca80e
      David Rientjes 提交于
      Extends the numa=fake x86_64 command-line option to allow for configurable
      node sizes.  These nodes can be used in conjunction with cpusets for coarse
      memory resource management.
      
      The old command-line option is still supported:
        numa=fake=32	gives 32 fake NUMA nodes, ignoring the NUMA setup of the
      		actual machine.
      
      But now you may configure your system for the node sizes of your choice:
        numa=fake=2*512,1024,2*256
      		gives two 512M nodes, one 1024M node, two 256M nodes, and
      		the rest of system memory to a sixth node.
      
      The existing hash function is maintained to support the various node sizes
      that are possible with this implementation.
      
      Each node of the same size receives roughly the same amount of available
      pages, regardless of any reserved memory with its address range.  The total
      available pages on the system is calculated and divided by the number of equal
      nodes to allocate.  These nodes are then dynamically allocated and their
      borders extended until such time as their number of available pages reaches
      the required size.
      
      Configurable node sizes are recommended when used in conjunction with cpusets
      for memory control because it eliminates the overhead associated with scanning
      the zonelists of many smaller full nodes on page_alloc().
      
      Cc: Andi Kleen <ak@suse.de>
      Signed-off-by: NDavid Rientjes <rientjes@google.com>
      Signed-off-by: NAndi Kleen <ak@suse.de>
      Cc: Paul Jackson <pj@sgi.com>
      Cc: Christoph Lameter <clameter@engr.sgi.com>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      8b8ca80e
  8. 13 2月, 2007 4 次提交
  9. 12 10月, 2006 1 次提交
    • M
      [PATCH] mm: use symbolic names instead of indices for zone initialisation · 6391af17
      Mel Gorman 提交于
      Arch-independent zone-sizing is using indices instead of symbolic names to
      offset within an array related to zones (max_zone_pfns).  The unintended
      impact is that ZONE_DMA and ZONE_NORMAL is initialised on powerpc instead
      of ZONE_DMA and ZONE_HIGHMEM when CONFIG_HIGHMEM is set.  As a result, the
      the machine fails to boot but will boot with CONFIG_HIGHMEM turned off.
      
      The following patch properly initialises the max_zone_pfns[] array and uses
      symbolic names instead of indices in each architecture using
      arch-independent zone-sizing.  Two users have successfully booted their
      powerpcs with it (one an ibook G4).  It has also been boot tested on x86,
      x86_64, ppc64 and ia64.  Please merge for 2.6.19-rc2.
      
      Credit to Benjamin Herrenschmidt for identifying the bug and rolling the
      first fix.  Additional credit to Johannes Berg and Andreas Schwab for
      reporting the problem and testing on powerpc.
      Signed-off-by: NMel Gorman <mel@csn.ul.ie>
      Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
      Signed-off-by: NAndrew Morton <akpm@osdl.org>
      Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
      6391af17