Skip to content
Snippets Groups Projects
  1. Jun 02, 2014
  2. May 06, 2014
  3. May 03, 2014
    • Dave Young's avatar
      x86/efi: earlyprintk=efi,keep fix · 5f35eb0e
      Dave Young authored
      
      earlyprintk=efi,keep will cause kernel hangs while freeing initmem like
      below:
      
        VFS: Mounted root (ext4 filesystem) readonly on device 254:2.
        devtmpfs: mounted
        Freeing unused kernel memory: 880K (ffffffff817d4000 - ffffffff818b0000)
      
      It is caused by efi earlyprintk use __init function which will be freed
      later.  Such as early_efi_write is marked as __init, also it will use
      early_ioremap which is init function as well.
      
      To fix this issue, I added early initcall early_efi_map_fb which maps
      the whole efi fb for later use. OTOH, adding a wrapper function
      early_efi_map which calls early_ioremap before ioremap is available.
      
      With this patch applied efi boot ok with earlyprintk=efi,keep console=efi
      
      Signed-off-by: default avatarDave Young <dyoung@redhat.com>
      Signed-off-by: default avatarMatt Fleming <matt.fleming@intel.com>
      5f35eb0e
  4. May 02, 2014
    • Dave Young's avatar
      x86/efi: earlyprintk=efi,keep fix · 34f51147
      Dave Young authored
      
      earlyprintk=efi,keep will cause kernel hangs while freeing initmem like
      below:
      
        VFS: Mounted root (ext4 filesystem) readonly on device 254:2.
        devtmpfs: mounted
        Freeing unused kernel memory: 880K (ffffffff817d4000 - ffffffff818b0000)
      
      It is caused by efi earlyprintk use __init function which will be freed
      later.  Such as early_efi_write is marked as __init, also it will use
      early_ioremap which is init function as well.
      
      To fix this issue, I added early initcall early_efi_map_fb which maps
      the whole efi fb for later use. OTOH, adding a wrapper function
      early_efi_map which calls early_ioremap before ioremap is available.
      
      With this patch applied efi boot ok with earlyprintk=efi,keep console=efi
      
      Signed-off-by: default avatarDave Young <dyoung@redhat.com>
      Signed-off-by: default avatarMatt Fleming <matt.fleming@intel.com>
      34f51147
  5. Mar 17, 2014
  6. Mar 05, 2014
    • Borislav Petkov's avatar
      x86/efi: Quirk out SGI UV · a5d90c92
      Borislav Petkov authored
      
      Alex reported hitting the following BUG after the EFI 1:1 virtual
      mapping work was merged,
      
       kernel BUG at arch/x86/mm/init_64.c:351!
       invalid opcode: 0000 [#1] SMP
       Call Trace:
        [<ffffffff818aa71d>] init_extra_mapping_uc+0x13/0x15
        [<ffffffff818a5e20>] uv_system_init+0x22b/0x124b
        [<ffffffff8108b886>] ? clockevents_register_device+0x138/0x13d
        [<ffffffff81028dbb>] ? setup_APIC_timer+0xc5/0xc7
        [<ffffffff8108b620>] ? clockevent_delta2ns+0xb/0xd
        [<ffffffff818a3a92>] ? setup_boot_APIC_clock+0x4a8/0x4b7
        [<ffffffff8153d955>] ? printk+0x72/0x74
        [<ffffffff818a1757>] native_smp_prepare_cpus+0x389/0x3d6
        [<ffffffff818957bc>] kernel_init_freeable+0xb7/0x1fb
        [<ffffffff81535530>] ? rest_init+0x74/0x74
        [<ffffffff81535539>] kernel_init+0x9/0xff
        [<ffffffff81541dfc>] ret_from_fork+0x7c/0xb0
        [<ffffffff81535530>] ? rest_init+0x74/0x74
      
      Getting this thing to work with the new mapping scheme would need more
      work, so automatically switch to the old memmap layout for SGI UV.
      
      Acked-by: default avatarRuss Anderson <rja@sgi.com>
      Cc: Alex Thorlton <athorlton@sgi.com
      Signed-off-by: default avatarBorislav Petkov <bp@suse.de>
      Signed-off-by: default avatarMatt Fleming <matt.fleming@intel.com>
      a5d90c92
  7. Mar 04, 2014
  8. Feb 27, 2014
  9. Feb 14, 2014
  10. Feb 06, 2014
    • Matt Fleming's avatar
      x86/efi: Allow mapping BGRT on x86-32 · 081cd62a
      Matt Fleming authored
      CONFIG_X86_32 doesn't map the boot services regions into the EFI memory
      map (see commit 70087011 ("x86, efi: Don't map Boot Services on
      i386")), and so efi_lookup_mapped_addr() will fail to return a valid
      address. Executing the ioremap() path in efi_bgrt_init() causes the
      following warning on x86-32 because we're trying to ioremap() RAM,
      
       WARNING: CPU: 0 PID: 0 at arch/x86/mm/ioremap.c:102 __ioremap_caller+0x2ad/0x2c0()
       Modules linked in:
       CPU: 0 PID: 0 Comm: swapper/0 Not tainted 3.13.0-0.rc5.git0.1.2.fc21.i686 #1
       Hardware name: DellInc. Venue 8 Pro 5830/09RP78, BIOS A02 10/17/2013
        00000000 00000000 c0c0df08 c09a5196 00000000 c0c0df38 c0448c1e c0b41310
        00000000 00000000 c0b37bc1 00000066 c043bbfd c043bbfd 00e7dfe0 00073eff
        00073eff c0c0df48 c0448ce2 00000009 00000000 c0c0df9c c043bbfd 00078d88
       Call Trace:
        [<c09a5196>] dump_stack+0x41/0x52
        [<c0448c1e>] warn_slowpath_common+0x7e/0xa0
        [<c043bbfd>] ? __ioremap_caller+0x2ad/0x2c0
        [<c043bbfd>] ? __ioremap_caller+0x2ad/0x2c0
        [<c0448ce2>] warn_slowpath_null+0x22/0x30
        [<c043bbfd>] __ioremap_caller+0x2ad/0x2c0
        [<c0718f92>] ? acpi_tb_verify_table+0x1c/0x43
        [<c0719c78>] ? acpi_get_table_with_size+0x63/0xb5
        [<c087cd5e>] ? efi_lookup_mapped_addr+0xe/0xf0
        [<c043bc2b>] ioremap_nocache+0x1b/0x20
        [<c0cb01c8>] ? efi_bgrt_init+0x83/0x10c
        [<c0cb01c8>] efi_bgrt_init+0x83/0x10c
        [<c0cafd82>] efi_late_init+0x8/0xa
        [<c0c9bab2>] start_kernel+0x3ae/0x3c3
        [<c0c9b53b>] ? repair_env_string+0x51/0x51
        [<c0c9b378>] i386_start_kernel+0x12e/0x131
      
      Switch to using early_memremap(), which won't trigger this warning, and
      has the added benefit of more accurately conveying what we're trying to
      do - map a chunk of memory.
      
      This patch addresses the following bug report,
      
        https://bugzilla.kernel.org/show_bug.cgi?id=67911
      
      
      
      Reported-by: default avatarAdam Williamson <awilliam@redhat.com>
      Cc: Josh Triplett <josh@joshtriplett.org>
      Cc: Matthew Garrett <mjg59@srcf.ucam.org>
      Cc: Rafael J. Wysocki <rjw@rjwysocki.net>
      Signed-off-by: default avatarMatt Fleming <matt.fleming@intel.com>
      081cd62a
  11. Jan 29, 2014
  12. Jan 25, 2014
  13. Jan 22, 2014
  14. Jan 17, 2014
  15. Jan 15, 2014
  16. Jan 13, 2014
    • Peter Zijlstra's avatar
      sched/clock, x86: Rewrite cyc2ns() to avoid the need to disable IRQs · 20d1c86a
      Peter Zijlstra authored
      
      Use a ring-buffer like multi-version object structure which allows
      always having a coherent object; we use this to avoid having to
      disable IRQs while reading sched_clock() and avoids a problem when
      getting an NMI while changing the cyc2ns data.
      
                              MAINLINE   PRE        POST
      
          sched_clock_stable: 1          1          1
          (cold) sched_clock: 329841     331312     257223
          (cold) local_clock: 301773     310296     309889
          (warm) sched_clock: 38375      38247      25280
          (warm) local_clock: 100371     102713     85268
          (warm) rdtsc:       27340      27289      24247
          sched_clock_stable: 0          0          0
          (cold) sched_clock: 382634     372706     301224
          (cold) local_clock: 396890     399275     399870
          (warm) sched_clock: 38194      38124      25630
          (warm) local_clock: 143452     148698     129629
          (warm) rdtsc:       27345      27365      24307
      
      Signed-off-by: default avatarPeter Zijlstra <peterz@infradead.org>
      Cc: Linus Torvalds <torvalds@linux-foundation.org>
      Cc: Andrew Morton <akpm@linux-foundation.org>
      Link: http://lkml.kernel.org/n/tip-s567in1e5ekq2nlyhn8f987r@git.kernel.org
      
      
      Signed-off-by: default avatarIngo Molnar <mingo@kernel.org>
      20d1c86a
Loading