1. 22 9月, 2008 1 次提交
  2. 16 9月, 2008 3 次提交
    • I
      x86: add X86_RESERVE_LOW_64K · fc381519
      Ingo Molnar 提交于
      This bugzilla:
      
        http://bugzilla.kernel.org/show_bug.cgi?id=11237
      
      Documents a wide range of systems where the BIOS utilizes the first
      64K of physical memory during suspend/resume and other hardware events.
      
      Currently we reserve this memory on all AMI and Phoenix BIOS systems.
      Life is too short to hunt subtle memory corruption problems like this,
      so we try to be robust by default.
      
      Still, allow this to be overriden: allow users who want that first 64K
      of memory to be available to the kernel disable the quirk, via
      CONFIG_X86_RESERVE_LOW_64K=n.
      
      Also, allow the early reservation to overlap with other
      early reservations.
      Signed-off-by: NIngo Molnar <mingo@elte.hu>
      fc381519
    • I
      x86: reserve low 64K on AMI and Phoenix BIOS boxen · 1e22436e
      Ingo Molnar 提交于
      there's multiple reports about suspend/resume related low memory
      corruption in this bugzilla:
      
        http://bugzilla.kernel.org/show_bug.cgi?id=11237
      
      the common pattern is that the corruption is caused by the BIOS,
      and that it affects some portion of the first 64K of physical RAM.
      
      So add a DMI quirk
      
      This will waste 64K RAM on 'good' systems too, but without knowing
      the exact nature of this BIOS memory corruption this is the safest
      approach.
      
      This might as well solve a wide range of suspend/resume breakages
      under Linux.
      Signed-off-by: NIngo Molnar <mingo@elte.hu>
      1e22436e
    • I
      x86: add DMI quirk for AMI BIOS which corrupts address 0xc000 during resume · 5649b7c3
      Ingo Molnar 提交于
      Alan Jenkins and Andy Wettstein reported a suspend/resume memory
      corruption bug and extensively documented it here:
      
         http://bugzilla.kernel.org/show_bug.cgi?id=11237
      
      The bug is that the BIOS overwrites 1K of memory at 0xc000 physical,
      without registering it in e820 as reserved or giving the kernel any
      idea about this.
      
      Detect AMI BIOSen and reserve that 1K.
      
      We paint this bug around with a very broad brush (reserving that 1K on all
      AMI BIOS systems), as the bug was extremely hard to find and needed several
      weeks and lots of debugging and patching.
      
      The bug was found via the CONFIG_X86_CHECK_BIOS_CORRUPTION=y debug feature,
      if similar bugs are suspected then this feature can be enabled on other
      systems as well to scan low memory for corrupted memory.
      Reported-by: NAlan Jenkins <alan-jenkins@tuffmail.co.uk>
      Reported-by: NAndy Wettstein <ajw1980@gmail.com>
      Signed-off-by: NIngo Molnar <mingo@elte.hu>
      5649b7c3
  3. 10 9月, 2008 2 次提交
    • 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
    • J
      lib: Correct printk %pF to work on all architectures · deac93df
      James Bottomley 提交于
      It was introduced by "vsprintf: add support for '%pS' and '%pF' pointer
      formats" in commit 0fe1ef24.  However,
      the current way its coded doesn't work on parisc64.  For two reasons: 1)
      parisc isn't in the #ifdef and 2) parisc has a different format for
      function descriptors
      
      Make dereference_function_descriptor() more accommodating by allowing
      architecture overrides.  I put the three overrides (for parisc64, ppc64
      and ia64) in arch/kernel/module.c because that's where the kernel
      internal linker which knows how to deal with function descriptors sits.
      Signed-off-by: NJames Bottomley <James.Bottomley@HansenPartnership.com>
      Acked-by: NBenjamin Herrenschmidt <benh@kernel.crashing.org>
      Acked-by: NTony Luck <tony.luck@intel.com>
      Acked-by: NKyle McMartin <kyle@mcmartin.ca>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      deac93df
  4. 09 9月, 2008 4 次提交
  5. 08 9月, 2008 2 次提交
    • H
      powerpc: Fix rare boot build breakage · 4ff23fa9
      Hugh Dickins 提交于
      A make -j20 powerpc kernel build broke a couple of months ago saying:
      In file included from arch/powerpc/boot/gunzip_util.h:13,
                       from arch/powerpc/boot/prpmc2800.c:21:
      arch/powerpc/boot/zlib.h:85: error: expected ‘:’, ‘,’, ‘;’, ‘}’ or ‘__attribute__’ before ‘*’ token
      arch/powerpc/boot/zlib.h:630: warning: type defaults to ‘int’ in declaration of ‘Byte’
      arch/powerpc/boot/zlib.h:630: error: expected ‘;’, ‘,’ or ‘)’ before ‘*’ token
      
      It happened again yesterday: too rare for me to confirm the fix, but
      it looks like the list of dependants on gunzip_util.h was incomplete.
      Signed-off-by: NHugh Dickins <hugh@veritas.com>
      Signed-off-by: NPaul Mackerras <paulus@samba.org>
      4ff23fa9
    • A
      powerpc/spufs: Fix possible scheduling of a context to multiple SPEs · b2e601d1
      Andre Detsch 提交于
      We currently have a race when scheduling a context to a SPE -
      after we have found a runnable context in spusched_tick, the same
      context may have been scheduled by spu_activate().
      
      This may result in a panic if we try to unschedule a context that has
      been freed in the meantime.
      
      This change exits spu_schedule() if the context has already been
      scheduled, so we don't end up scheduling it twice.
      Signed-off-by: NAndre Detsch <adetsch@br.ibm.com>
      Signed-off-by: NJeremy Kerr <jk@ozlabs.org>
      b2e601d1
  6. 07 9月, 2008 7 次提交
  7. 06 9月, 2008 14 次提交
  8. 05 9月, 2008 6 次提交
  9. 04 9月, 2008 1 次提交