1. 19 2月, 2008 11 次提交
  2. 15 2月, 2008 4 次提交
    • H
      x86: include proper prototypes for rodata_test · 7bfeab9a
      Harvey Harrison 提交于
      extern should not appear in C files.  Also, the definitions
      do not match the prototype currently, not sure what way you
      want to go with this, I've switched the prototype to return
      int, but I can see going to the void return as well.
      Signed-off-by: NHarvey Harrison <harvey.harrison@gmail.com>
      Signed-off-by: NIngo Molnar <mingo@elte.hu>
      7bfeab9a
    • I
      x86: fix gart_iommu_init() · 184652eb
      Ingo Molnar 提交于
      When the GART table is unmapped from the kernel direct mappings
      during early bootup, make sure we have no leftover cachelines in it.
      
      Note: the clflush done by set_memory_np() was not enough, because
      clflush does not work on unmapped pages.
      Signed-off-by: NIngo Molnar <mingo@elte.hu>
      Signed-off-by: NThomas Gleixner <tglx@linutronix.de>
      184652eb
    • I
      x86: EFI set_memory_x()/set_memory_uc() fixes · 3223f59f
      Ingo Molnar 提交于
      The EFI-runtime mapping code changed a larger memory area than it
      should have, due to a pages/bytes parameter mixup.
      
      noticed by Andi Kleen.
      Signed-off-by: NIngo Molnar <mingo@elte.hu>
      3223f59f
    • I
      x86: fix "BUG: sleeping function called from invalid context" in print_vma_addr() · e8bff74a
      Ingo Molnar 提交于
      Jiri Kosina reported the following deadlock scenario with
      show_unhandled_signals enabled:
      
       [   68.379022] gnome-settings-[2941] trap int3 ip:3d2c840f34
       sp:7fff36f5d100 error:0<3>BUG: sleeping function called from invalid
       context at kernel/rwsem.c:21
       [   68.379039] in_atomic():1, irqs_disabled():0
       [   68.379044] no locks held by gnome-settings-/2941.
       [   68.379050] Pid: 2941, comm: gnome-settings- Not tainted 2.6.25-rc1 #30
       [   68.379054]
       [   68.379056] Call Trace:
       [   68.379061]  <#DB>  [<ffffffff81064883>] ? __debug_show_held_locks+0x13/0x30
       [   68.379109]  [<ffffffff81036765>] __might_sleep+0xe5/0x110
       [   68.379123]  [<ffffffff812f2240>] down_read+0x20/0x70
       [   68.379137]  [<ffffffff8109cdca>] print_vma_addr+0x3a/0x110
       [   68.379152]  [<ffffffff8100f435>] do_trap+0xf5/0x170
       [   68.379168]  [<ffffffff8100f52b>] do_int3+0x7b/0xe0
       [   68.379180]  [<ffffffff812f4a6f>] int3+0x9f/0xd0
       [   68.379203]  <<EOE>>
       [   68.379229]  in libglib-2.0.so.0.1505.0[3d2c800000+dc000]
      
      and tracked it down to:
      
        commit 03252919
        Author: Andi Kleen <ak@suse.de>
        Date:   Wed Jan 30 13:33:18 2008 +0100
      
            x86: print which shared library/executable faulted in segfault etc. messages
      
      the problem is that we call down_read() from an atomic context.
      
      Solve this by returning from print_vma_addr() if the preempt count is
      elevated. Update preempt_conditional_sti / preempt_conditional_cli to
      unconditionally lift the preempt count even on !CONFIG_PREEMPT.
      Reported-by: NJiri Kosina <jkosina@suse.cz>
      Signed-off-by: NIngo Molnar <mingo@elte.hu>
      e8bff74a
  3. 14 2月, 2008 1 次提交
  4. 13 2月, 2008 4 次提交
  5. 12 2月, 2008 1 次提交
    • M
      Use proper abstractions in quirk_intel_irqbalance · 9585ca02
      Matthew Wilcox 提交于
      Since we may not have a pci_dev for the device we need to access, we can't
      use pci_read_config_word.  But raw_pci_read is an internal implementation
      detail; it's better to use the architected pci_bus_read_config_word
      interface.  Using PCI_DEVFN instead of a mysterious constant helps
      reassure everyone that we really do intend to access device 8.
      
      [ Thanks to Grant Grundler for pointing out to me that this is exactly
        what the write immediately above this is doing -- enabling device 8 to
        respond to config space cycles.
      					- Matthew
      
        Grant also says:
      
      	"Can you also add a comment which points at the Intel
      	 documentation?
      
      	 The 'Intel E7320 Memory Controller Hub (MCH) Datasheet' at
      
      	  http://download.intel.com/design/chipsets/datashts/30300702.pdf
      
      	 Page 69 documents register F4h (DEVPRES1).
      
      	 And I just doubled checked that the 0xf4 register value is
      	 restored later in the quirk (obvious when you look at the code
      	 but not from the patch"
      
        so here it is.
      					 - Linus ]
      Signed-off-by: NMatthew Wilcox <willy@linux.intel.com>
      Acked-by: NGrant Grundler <grundler@parisc-linux.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      9585ca02
  6. 11 2月, 2008 1 次提交
  7. 10 2月, 2008 14 次提交
  8. 09 2月, 2008 3 次提交
  9. 08 2月, 2008 1 次提交