1. 04 6月, 2009 1 次提交
  2. 23 4月, 2009 4 次提交
  3. 04 4月, 2009 1 次提交
    • S
      x86, PAT: Remove duplicate memtype reserve in pci mmap · 5a3ae276
      Suresh Siddha 提交于
      pci mmap code was doing memtype reserve for a while now. Recently we
      added memtype tracking in remap_pfn_range, and pci code indirectly calls
      remap_pfn_range. So, we don't need seperate tracking in pci code
      anymore. Which means a patch that removes ~50 lines of code :-).
      
      Also, recently we found out that the pci tracking is not working as we expect
      it to work in some cases. Specifically, userlevel X mmap of pci, with some
      recent version of X, is having a problem with vm_page_prot getting reset.
      The pci tracking uses vm_page_prot to pass on the protection type from parent
      to child during fork.
      a) Parent does a pci mmap
      b) We look at PAT and get either UC_MINUS or WC mapping for parent
      c) Store that mapping type in vma vm_page_prot for future use
      d) This thread does a fork
      e) Fork results in mmap_ops ->open for the child process
      f) We get the vm_page_prot from vma and reserve that type for the child process
      
      But, between c) and e) above, the vma vm_page_prot is getting reset to zero.
      This results in PAT reserve failing at the time of fork as in here.
      http://marc.info/?l=linux-kernel&m=123858163103240&w=2
      
      This cleanup makes the above problem go away as we do not depend on
      vm_page_prot in our PAT code anymore.
      Signed-off-by: NSuresh Siddha <suresh.b.siddha@intel.com>
      Signed-off-by: NVenkatesh Pallipadi <venkatesh.pallipadi@intel.com>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      5a3ae276
  4. 27 3月, 2009 1 次提交
  5. 24 3月, 2009 1 次提交
  6. 21 3月, 2009 3 次提交
  7. 20 3月, 2009 2 次提交
  8. 12 3月, 2009 1 次提交
  9. 18 2月, 2009 1 次提交
  10. 06 2月, 2009 1 次提交
  11. 29 1月, 2009 2 次提交
  12. 28 1月, 2009 1 次提交
  13. 14 1月, 2009 1 次提交
  14. 08 1月, 2009 11 次提交
  15. 30 12月, 2008 1 次提交
  16. 26 11月, 2008 1 次提交
  17. 12 11月, 2008 1 次提交
    • H
      x86: attempt reboot via port CF9 if we have standard PCI ports · 14d7ca5c
      H. Peter Anvin 提交于
      Impact: Changes reboot behavior.
      
      If port CF9 seems to be safe to touch, attempt it before trying the
      keyboard controller.  Port CF9 is not available on all chipsets (a
      significant but decreasing number of modern chipsets don't implement
      it), but port CF9 itself should in general be safe to poke (no ill
      effects if unimplemented) on any system which has PCI Configuration
      Method #1 or #2, as it falls inside the PCI configuration port range
      in both cases.  No chipset without PCI is known to have port CF9,
      either, although an explicit "pci=bios" would mean we miss this and
      therefore don't use port CF9.  An explicit "reboot=pci" can be used to
      force the use of port CF9.
      Signed-off-by: NH. Peter Anvin <hpa@zytor.com>
      14d7ca5c
  18. 21 10月, 2008 2 次提交
  19. 15 9月, 2008 1 次提交
  20. 05 9月, 2008 1 次提交
  21. 04 9月, 2008 2 次提交