1. 17 12月, 2009 1 次提交
    • Y
      x86: Fix checking of SRAT when node 0 ram is not from 0 · 32996250
      Yinghai Lu 提交于
      Found one system that boot from socket1 instead of socket0, SRAT get rejected...
      
      [    0.000000] SRAT: Node 1 PXM 0 0-a0000
      [    0.000000] SRAT: Node 1 PXM 0 100000-80000000
      [    0.000000] SRAT: Node 1 PXM 0 100000000-2080000000
      [    0.000000] SRAT: Node 0 PXM 1 2080000000-4080000000
      [    0.000000] SRAT: Node 2 PXM 2 4080000000-6080000000
      [    0.000000] SRAT: Node 3 PXM 3 6080000000-8080000000
      [    0.000000] SRAT: Node 4 PXM 4 8080000000-a080000000
      [    0.000000] SRAT: Node 5 PXM 5 a080000000-c080000000
      [    0.000000] SRAT: Node 6 PXM 6 c080000000-e080000000
      [    0.000000] SRAT: Node 7 PXM 7 e080000000-10080000000
      ...
      [    0.000000] NUMA: Allocated memnodemap from 500000 - 701040
      [    0.000000] NUMA: Using 20 for the hash shift.
      [    0.000000] Adding active range (0, 0x2080000, 0x4080000) 0 entries of 3200 used
      [    0.000000] Adding active range (1, 0x0, 0x96) 1 entries of 3200 used
      [    0.000000] Adding active range (1, 0x100, 0x7f750) 2 entries of 3200 used
      [    0.000000] Adding active range (1, 0x100000, 0x2080000) 3 entries of 3200 used
      [    0.000000] Adding active range (2, 0x4080000, 0x6080000) 4 entries of 3200 used
      [    0.000000] Adding active range (3, 0x6080000, 0x8080000) 5 entries of 3200 used
      [    0.000000] Adding active range (4, 0x8080000, 0xa080000) 6 entries of 3200 used
      [    0.000000] Adding active range (5, 0xa080000, 0xc080000) 7 entries of 3200 used
      [    0.000000] Adding active range (6, 0xc080000, 0xe080000) 8 entries of 3200 used
      [    0.000000] Adding active range (7, 0xe080000, 0x10080000) 9 entries of 3200 used
      [    0.000000] SRAT: PXMs only cover 917504MB of your 1048566MB e820 RAM. Not used.
      [    0.000000] SRAT: SRAT not used.
      
      the early_node_map is not sorted because node0 with non zero start come first.
      
      so try to sort it right away after all regions are registered.
      
      also fixs refression by 8716273c (x86: Export srat physical topology)
      
      -v2: make it more solid to handle cross node case like node0 [0,4g), [8,12g) and node1 [4g, 8g), [12g, 16g)
      -v3: update comments.
      Reported-and-tested-by: NJens Axboe <jens.axboe@oracle.com>
      Signed-off-by: NYinghai Lu <yinghai@kernel.org>
      LKML-Reference: <4B2579D2.3010201@kernel.org>
      Signed-off-by: NH. Peter Anvin <hpa@zytor.com>
      32996250
  2. 06 9月, 2009 1 次提交
  3. 06 5月, 2009 1 次提交
  4. 14 8月, 2008 1 次提交
  5. 17 7月, 2008 1 次提交
  6. 08 7月, 2008 3 次提交
  7. 10 6月, 2008 1 次提交
  8. 09 6月, 2008 1 次提交
  9. 06 6月, 2008 1 次提交
    • I
      x86, 32-bit: SRAT fix · ea57a5a6
      Ingo Molnar 提交于
      we were adding reserved BIOS ranges as general memory as well => not good.
      
      solves this crash:
      
      [   20.068075] hostname used greatest stack depth: 6464 bytes left
      [   20.121404] BUG: unable to handle kernel <1>BUG: unable to handle kernel NULL pointer dereference at 00000b8c
      [   20.121404] IP: [<c01160ae>] kmap_atomic_prot+0x2d/0x1c3
      [   20.121404] *pdpt = 00000000367eb001 *pde = 0000000000000000
      [   20.121404] Oops: 0000 [#1] PREEMPT SMP DEBUG_PAGEALLOC
      [   20.121404]
      [   20.121404] Pid: 2061, comm: rc.sysinit Not tainted (2.6.26-rc3 #2440)
      [   20.121404] EIP: 0060:[<c01160ae>] EFLAGS: 00010206 CPU: 0
      [   20.121404] EIP is at kmap_atomic_prot+0x2d/0x1c3
      Signed-off-by: NIngo Molnar <mingo@elte.hu>
      ea57a5a6
  10. 04 6月, 2008 1 次提交
  11. 31 5月, 2008 1 次提交
    • Y
      x86: 32bit numa srat fix early_ioremap leak · 9a73aa81
      Yinghai Lu 提交于
      on two node system (16g RAM) with numa config I got this crash:
      
      get_memcfg_from_srat: assigning address to rsdp
      RSD PTR  v0 [ACPIAM]
      ACPI: Too big length in RSDT: 92
      failed to get NUMA memory information from SRAT table
      NUMA - single node, flat memory mode
      Node: 0, start_pfn: 0, end_pfn: 153
       Setting physnode_map array to node 0 for pfns:
       0
      ...
      Pid: 0, comm: swapper Not tainted 2.6.26-rc4 #4
       [<80b41289>] hlt_loop+0x0/0x3
       [<8011efa0>] ? alloc_remap+0x50/0x70
       [<8079e32e>] alloc_node_mem_map+0x5e/0xa0
       [<8012e77b>] ? printk+0x1b/0x20
       [<80b590f6>] free_area_init_node+0xc6/0x470
       [<80b588fc>] ? __alloc_bootmem_node+0x2c/0x50
       [<80b58ad8>] ? find_min_pfn_for_node+0x38/0x70
       [<8012e77b>] ? printk+0x1b/0x20
       [<80b597c4>] free_area_init_nodes+0x254/0x2d0
       [<80b544d7>] zone_sizes_init+0x97/0xa0
       [<80b48a03>] setup_arch+0x383/0x530
       [<8012e77b>] ? printk+0x1b/0x20
       [<80b41aa4>] start_kernel+0x64/0x350
       [<80b412d8>] i386_start_kernel+0x8/0x10
       =======================
      
      this patch increases the acpi table limit to 32.
      Also match early_ioremap() with early_iounmap().
      Signed-off-by: NYinghai Lu <yhlu.kernel@gmail.com>
      Signed-off-by: NIngo Molnar <mingo@elte.hu>
      9a73aa81
  12. 17 4月, 2008 1 次提交
  13. 30 1月, 2008 2 次提交
  14. 14 12月, 2007 1 次提交
    • L
      ACPI: tables: complete searching upon RSDP w/ bad checksum. · 239665a3
      Len Brown 提交于
      ACPI tables follow a tree structure in memory.
      The root of the tree is the RSDP (Root System Description Pointer).
      
      To find the RSDP, the OS searches for the signature "RSD PTR "
      in well known physical memory locations.  Then the OS computes
      a table checksum to verify that the signature is really part
      of a valid table header.
      
      Some systems have a proper signature but an invalid checksum;
      followed elsewhere by a proper signature with valid checksum.
      
      http://bugzilla.kernel.org/show_bug.cgi?id=9444
      
      The Linux RSDP scanning code bailed out on those systems
      and as a result they booted with ACPI disabled.
      
      Fix this by deleting the Linux RSDP scanning code and
      plugging in the ACPICA RSDP scanning code.
      Signed-off-by: NLen Brown <len.brown@intel.com>
      239665a3
  15. 11 10月, 2007 2 次提交
  16. 03 2月, 2007 1 次提交
  17. 30 9月, 2006 1 次提交
    • K
      [PATCH] convert i386 Summit subarch to use SRAT info for apicid_to_node calls · 3b08606d
      keith mannthey 提交于
      Convert the i386 summit subarch apicid_to_node to use node information
      provided by the SRAT.  It was discussed a little on LKML a few weeks ago
      and was seen as an acceptable fix.  The current way of obtaining the nodeid
      
       static inline int apicid_to_node(int logical_apicid)
       {
         return logical_apicid >> 5;
       }
      
      is just not correct for all summit systems/bios.  Assuming the apicid
      matches the Linux node number require a leap of faith that the bios mapped
      out the apicids a set way.  Modern summit HW (IBM x460) does not layout its
      bios in the manner for various reasons and is unable to boot i386 numa.
      
      The best way to get the correct apicid to node information is from the SRAT
      table during boot.  It lays out what apicid belongs to what node.  I use
      this information to create a table for use at run time.
      Signed-off-by: NKeith Mannthey <kmannth@us.ibm.com>
      Cc: Andi Kleen <ak@suse.de>
      Signed-off-by: NAndrew Morton <akpm@osdl.org>
      Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
      3b08606d
  18. 27 9月, 2006 1 次提交
  19. 26 9月, 2006 1 次提交
  20. 01 7月, 2006 1 次提交
  21. 23 6月, 2006 1 次提交
  22. 15 11月, 2005 1 次提交
  23. 31 10月, 2005 1 次提交
  24. 13 9月, 2005 1 次提交
  25. 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