1. 08 5月, 2009 1 次提交
  2. 23 3月, 2009 1 次提交
    • J
      x86: e820 fix various signedness issues in setup.c and e820.c · ba639039
      Jaswinder Singh Rajput 提交于
      Impact: cleanup
      
      This fixed various signedness issues in setup.c and e820.c:
      arch/x86/kernel/setup.c:455:53: warning: incorrect type in argument 3 (different signedness)
      arch/x86/kernel/setup.c:455:53:    expected int *pnr_map
      arch/x86/kernel/setup.c:455:53:    got unsigned int extern [toplevel] *<noident>
      arch/x86/kernel/setup.c:639:53: warning: incorrect type in argument 3 (different signedness)
      arch/x86/kernel/setup.c:639:53:    expected int *pnr_map
      arch/x86/kernel/setup.c:639:53:    got unsigned int extern [toplevel] *<noident>
      arch/x86/kernel/setup.c:820:54: warning: incorrect type in argument 3 (different signedness)
      arch/x86/kernel/setup.c:820:54:    expected int *pnr_map
      arch/x86/kernel/setup.c:820:54:    got unsigned int extern [toplevel] *<noident>
      
      arch/x86/kernel/e820.c:670:53: warning: incorrect type in argument 3 (different signedness)
      arch/x86/kernel/e820.c:670:53:    expected int *pnr_map
      arch/x86/kernel/e820.c:670:53:    got unsigned int [toplevel] *<noident>
      Signed-off-by: NJaswinder Singh Rajput <jaswinderrajput@gmail.com>
      ba639039
  3. 15 3月, 2009 1 次提交
  4. 14 3月, 2009 1 次提交
  5. 13 3月, 2009 2 次提交
    • Y
      x86: fix e820_update_range() · 773e673d
      Yinghai Lu 提交于
      Impact: fix left range size on head
      
      | commit 5c0e6f03
      |    x86: fix code paths used by update_mptable
      |    Impact: fix crashes under Xen due to unrobust e820 code
      
      fixes one e820 bug, but introduces another bug.
      
      Need to update size for left range at first in case it is header.
      
      also add __e820_add_region take more parameter.
      Signed-off-by: NYinghai Lu <yinghai@kernel.org>
      Cc: jbeulich@novell.com
      LKML-Reference: <49B9E286.502@kernel.org>
      Signed-off-by: NIngo Molnar <mingo@elte.hu>
      773e673d
    • J
      x86: fix code paths used by update_mptable · 5c0e6f03
      Jan Beulich 提交于
      Impact: fix crashes under Xen due to unrobust e820 code
      
      find_e820_area_size() must return a properly distinguishable and
      out-of-bounds value when it fails, and -1UL does not meet that
      criteria on i386/PAE. Additionally, callers of the function must
      check against that value.
      
      early_reserve_e820() should be prepared for the region found to be
      outside of the addressable range on 32-bits.
      
      e820_update_range_map() should not blindly update e820, but should do
      all it work on the map it got a pointer passed for (which in 50% of the
      cases is &e820_saved). It must also not call e820_add_region(), as that
      again acts on e820 unconditionally.
      
      The issues were found when trying to make this option work in our Xen
      kernel (i.e. where some of the silent assumptions made in the code
      would not hold).
      Signed-off-by: NJan Beulich <jbeulich@novell.com>
      LKML-Reference: <49B9171B.76E4.0078.0@novell.com>
      Signed-off-by: NIngo Molnar <mingo@elte.hu>
      5c0e6f03
  6. 25 2月, 2009 1 次提交
    • Y
      x86: check range in reserve_early() · 46cb27f5
      Yinghai Lu 提交于
      Impact: cleanup
      
      one 32-bit system reports:
      
      BIOS-provided physical RAM map:
       BIOS-e820: 0000000000000000 - 000000000009fc00 (usable)
       BIOS-e820: 000000000009fc00 - 00000000000a0000 (reserved)
       BIOS-e820: 00000000000f0000 - 0000000000100000 (reserved)
       BIOS-e820: 0000000000100000 - 000000001c000000 (usable)
       BIOS-e820: 00000000ffff0000 - 0000000100000000 (reserved)
      DMI 2.0 present.
      last_pfn = 0x1c000 max_arch_pfn = 0x100000
      kernel direct mapping tables up to 1c000000 @ 7000-c000
      ..
      RAMDISK: 1bc69000 - 1bfef4fa
      ..
      0MB HIGHMEM available.
      448MB LOWMEM available.
        mapped low ram: 0 - 1c000000
        low ram: 00000000 - 1c000000
        bootmap 00002000 - 00005800
      (9 early reservations) ==> bootmem [0000000000 - 001c000000]
        #0 [0000000000 - 0000001000]   BIOS data page ==> [0000000000 - 0000001000]
        #1 [0000001000 - 0000002000]    EX TRAMPOLINE ==> [0000001000 - 0000002000]
        #2 [0000006000 - 0000007000]       TRAMPOLINE ==> [0000006000 - 0000007000]
        #3 [0000400000 - 00009ed14c]    TEXT DATA BSS ==> [0000400000 - 00009ed14c]
        #4 [001bc69000 - 001bfef4fa]          RAMDISK ==> [001bc69000 - 001bfef4fa]
        #5 [00009ee000 - 00009f2000]    INIT_PG_TABLE ==> [00009ee000 - 00009f2000]
        #6 [000009f400 - 0000100000]    BIOS reserved ==> [000009f400 - 0000100000]
        #7 [0000007000 - 0000007000]          PGTABLE
        #8 [0000002000 - 0000006000]          BOOTMAP ==> [0000002000 - 0000006000]
      
      Notice the strange blank PGTABLE entry.
      
      The reason is init_pg_table is big enough, and zero range is called
      with init_memory_mapping/reserve_early().
      
      So try to check the range in reserve_early()
      
      v2: fix the reversed compare
      Signed-off-by: NYinghai Lu <yinghai@kernel.org>
      Cc: nickpiggin@yahoo.com.au
      Cc: ink@jurassic.park.msu.ru
      Signed-off-by: NIngo Molnar <mingo@elte.hu>
      46cb27f5
  7. 19 12月, 2008 1 次提交
  8. 08 12月, 2008 1 次提交
    • R
      x86: change static allocation of trampoline area · 3e1e9002
      Rafael J. Wysocki 提交于
      Impact: fix trampoline sizing bug, save space
      
      While debugging a suspend-to-RAM related issue it occured to me that
      if the trampoline code had grown past 4 KB, we would have been
      allocating too little memory for it, since the 4 KB size of the
      trampoline is hardcoded into arch/x86/kernel/e820.c .  Change that
      by making the kernel compute the trampoline size and allocate as much
      memory as necessary.
      Signed-off-by: NRafael J. Wysocki <rjw@sisk.pl>
      Signed-off-by: NIngo Molnar <mingo@elte.hu>
      3e1e9002
  9. 02 11月, 2008 1 次提交
    • L
      x86: Clean up late e820 resource allocation · 1f987577
      Linus Torvalds 提交于
      This makes the late e820 resources use 'insert_resource_expand_to_fit()'
      instead of doing a 'reserve_region_with_split()', and also avoids
      marking them as IORESOURCE_BUSY.
      
      This results in us being perfectly happy to use pre-existing PCI
      resources even if they were marked as being in a reserved region, while
      still avoiding any _new_ allocations in the reserved regions.  It also
      makes for a simpler and more accurate resource tree.
      
      Example resource allocation from Jonathan Corbet, who has firmware that
      has an e820 reserved entry that covered a big range (e0000000-fed003ff),
      and that had various PCI resources in it set up by firmware.
      
      With old kernels, the reserved range would force us to re-allocate all
      pre-existing PCI resources, and his reserved range would end up looking
      like this:
      
      	e0000000-fed003ff : reserved
      	  fec00000-fec00fff : IOAPIC 0
      	  fed00000-fed003ff : HPET 0
      
      where only the pre-allocated special regions (IOAPIC and HPET) were kept
      around.
      
      With 2.6.28-rc2, which uses 'reserve_region_with_split()', Jonathan's
      resource tree looked like this:
      
      	e0000000-fe7fffff : reserved
      	fe800000-fe8fffff : PCI Bus 0000:01
      	 fe800000-fe8fffff : reserved
      	fe900000-fe9d9aff : reserved
      	fe9d9b00-fe9d9bff : 0000:00:1f.3
      	 fe9d9b00-fe9d9bff : reserved
      	fe9d9c00-fe9d9fff : 0000:00:1a.7
      	 fe9d9c00-fe9d9fff : reserved
      	fe9da000-fe9dafff : 0000:00:03.3
      	 fe9da000-fe9dafff : reserved
      	fe9db000-fe9dbfff : 0000:00:19.0
      	 fe9db000-fe9dbfff : reserved
      	fe9dc000-fe9dffff : 0000:00:1b.0
      	 fe9dc000-fe9dffff : reserved
      	fe9e0000-fe9fffff : 0000:00:19.0
      	 fe9e0000-fe9fffff : reserved
      	fea00000-fea7ffff : 0000:00:02.0
      	 fea00000-fea7ffff : reserved
      	fea80000-feafffff : 0000:00:02.1
      	 fea80000-feafffff : reserved
      	feb00000-febfffff : 0000:00:02.0
      	 feb00000-febfffff : reserved
      	fec00000-fed003ff : reserved
      	 fec00000-fec00fff : IOAPIC 0
      	 fed00000-fed003ff : HPET 0
      
      and because the reserved entry had been split and moved into the
      individual resources, and because it used the IORESOURCE_BUSY flag, the
      drivers that actually wanted to _use_ those resources couldn't actually
      attach to them:
      
      	e1000e 0000:00:19.0: BAR 0: can't reserve mem region [0xfe9e0000-0xfe9fffff]
      	HDA Intel 0000:00:1b.0: BAR 0: can't reserve mem region [0xfe9dc000-0xfe9dffff]
      
      with this patch, the resource tree instead becomes
      
      	e0000000-fed003ff : reserved
      	  fe800000-fe8fffff : PCI Bus 0000:01
      	  fe9d9b00-fe9d9bff : 0000:00:1f.3
      	  fe9d9c00-fe9d9fff : 0000:00:1a.7
      	    fe9d9c00-fe9d9fff : ehci_hcd
      	  fe9da000-fe9dafff : 0000:00:03.3
      	  fe9db000-fe9dbfff : 0000:00:19.0
      	    fe9db000-fe9dbfff : e1000e
      	  fe9dc000-fe9dffff : 0000:00:1b.0
      	    fe9dc000-fe9dffff : ICH HD audio
      	  fe9e0000-fe9fffff : 0000:00:19.0
      	    fe9e0000-fe9fffff : e1000e
      	  fea00000-fea7ffff : 0000:00:02.0
      	  fea80000-feafffff : 0000:00:02.1
      	  feb00000-febfffff : 0000:00:02.0
      	  fec00000-fec00fff : IOAPIC 0
      	  fed00000-fed003ff : HPET 0
      
      ie the one reserved region now ends up surrounding all the PCI resources
      that were allocated inside of it by firmware, and because it is not
      marked BUSY, drivers have no problem attaching to the pre-allocated
      resources.
      Reported-and-tested-by: NJonathan Corbet <corbet@lwn.net>
      Cc: Yinghai Lu <yinghai@kernel.org>
      Cc: Ingo Molnar <mingo@elte.hu>
      Cc: Robert Hancock <hancockr@shaw.ca>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      1f987577
  10. 14 9月, 2008 1 次提交
  11. 10 9月, 2008 1 次提交
    • P
      x86: fix memmap=exactmap boot argument · d6be118a
      Prarit Bhargava 提交于
      When using kdump modifying the e820 map is yielding strange results.
      
      For example starting with
      
       BIOS-provided physical RAM map:
       BIOS-e820: 0000000000000100 - 0000000000093400 (usable)
       BIOS-e820: 0000000000093400 - 00000000000a0000 (reserved)
       BIOS-e820: 0000000000100000 - 000000003fee0000 (usable)
       BIOS-e820: 000000003fee0000 - 000000003fef3000 (ACPI data)
       BIOS-e820: 000000003fef3000 - 000000003ff80000 (ACPI NVS)
       BIOS-e820: 000000003ff80000 - 0000000040000000 (reserved)
       BIOS-e820: 00000000e0000000 - 00000000f0000000 (reserved)
       BIOS-e820: 00000000fec00000 - 00000000fec10000 (reserved)
       BIOS-e820: 00000000fee00000 - 00000000fee01000 (reserved)
       BIOS-e820: 00000000ff000000 - 0000000100000000 (reserved)
      
      and booting with args
      
      memmap=exactmap memmap=640K@0K memmap=5228K@16384K memmap=125188K@22252K memmap=76K#1047424K memmap=564K#1047500K
      
      resulted in:
      
       user-defined physical RAM map:
       user: 0000000000000000 - 0000000000093400 (usable)
       user: 0000000000093400 - 00000000000a0000 (reserved)
       user: 0000000000100000 - 000000003fee0000 (usable)
       user: 000000003fee0000 - 000000003fef3000 (ACPI data)
       user: 000000003fef3000 - 000000003ff80000 (ACPI NVS)
       user: 000000003ff80000 - 0000000040000000 (reserved)
       user: 00000000e0000000 - 00000000f0000000 (reserved)
       user: 00000000fec00000 - 00000000fec10000 (reserved)
       user: 00000000fee00000 - 00000000fee01000 (reserved)
       user: 00000000ff000000 - 0000000100000000 (reserved)
      
      But should have resulted in:
      
       user-defined physical RAM map:
       user: 0000000000000000 - 00000000000a0000 (usable)
       user: 0000000001000000 - 000000000151b000 (usable)
       user: 00000000015bb000 - 0000000008ffc000 (usable)
       user: 000000003fee0000 - 000000003ff80000 (ACPI data)
      
      This is happening because of an improper usage of strcmp() in the
      e820 parsing code.  The strcmp() always returns !0 and never resets the
      value for e820.nr_map and returns an incorrect user-defined map.
      
      This patch fixes the problem.
      Signed-off-by: NPrarit Bhargava <prarit@redhat.com>
      Signed-off-by: NIngo Molnar <mingo@elte.hu>
      d6be118a
  12. 05 9月, 2008 1 次提交
  13. 04 9月, 2008 2 次提交
  14. 21 8月, 2008 1 次提交
  15. 20 7月, 2008 2 次提交
  16. 19 7月, 2008 1 次提交
  17. 13 7月, 2008 1 次提交
  18. 11 7月, 2008 3 次提交
  19. 10 7月, 2008 1 次提交
  20. 09 7月, 2008 5 次提交
  21. 08 7月, 2008 11 次提交