Skip to content

K
Kernel

openeuler / Kernel
接近 2 年 前同步成功

通知 8
Star 0
Fork 0
K
Kernel
切换分支/标签
  1. 29 8月, 2009 2 次提交
  3. 11 7月, 2009 1 次提交
    • Y
      x86/pci: insert ioapic resource before assigning unassigned resources · 857fdc53
      由 Yinghai Lu 提交于 
      Stephen reported that his DL585 G2 needed noapic after 2.6.22 (?)

Dann bisected it down to:
  commit 30a18d6c
  Date:   Tue Feb 19 03:21:20 2008 -0800

      x86: multi pci root bus with different io resource range, on
      64-bit

It turns out that:
  1. that AMD-based systems have two HT chains.
  2. BIOS doesn't allocate resources for BAR 6 of devices under 8132 etc
  3. that multi-peer-root patch will try to split root resources to peer
     root resources according to PCI conf of NB
  4. PCI core assigns unassigned resources, but they overlap with BARs
     that are used by ioapic addr of io4 and 8132.

The reason: at that point ioapic address are not inserted yet.  Solution
is to insert ioapic resources into the tree a bit earlier.
Reported-by: NStephen Frost <sfrost@snowman.net>
Reported-and-Tested-by: Ndann frazier <dannf@hp.com>
Signed-off-by: NYinghai Lu <yinghai@kernel.org>
Cc: stable@kernel.org
Signed-off-by: NJesse Barnes <jbarnes@jbarnes-g45.(none)>
      857fdc53
  5. 01 7月, 2009 2 次提交
  7. 25 6月, 2009 1 次提交
  9. 18 6月, 2009 1 次提交
  11. 17 6月, 2009 1 次提交
    • G
      x86/ACPI: Correct maximum allowed _CRS returned resources and warn if exceeded · f9cde5ff
      由 Gary Hade 提交于 
      Issue a warning if _CRS returns too many resource descriptors to be
accommodated by the fixed size resource array instances.  If there is no
transparent bridge on the root bus "too many" is the
PCI_BUS_NUM_RESOURCES size of the resource array.  Otherwise, the last 3
slots of the resource array must be excluded making the maximum
(PCI_BUS_NUM_RESOURCES - 3).

The current code:
 - is silent when _CRS returns too many resource descriptors and
 - incorrectly allows use of the last 3 slots of the resource array
   for a root bus with a transparent bridge
Signed-off-by: NGary Hade <garyhade@us.ibm.com>
Signed-off-by: NJesse Barnes <jbarnes@virtuousgeek.org>
      f9cde5ff
  13. 13 6月, 2009 1 次提交
  15. 12 6月, 2009 1 次提交
  17. 04 6月, 2009 1 次提交
  19. 18 5月, 2009 1 次提交
    • Y
      x86, apic: introduce io_apic_irq_attr · e5198075
      由 Yinghai Lu 提交于 
      according to Ingo, io_apic irq-setup related functions have too many
parameters with a repetitive signature.

So reduce related funcs to get less params by passing a pointer
to a newly defined io_apic_irq_attr structure.

v2: io_apic_irq ==> irq_attr
    triggering ==> trigger

v3: add set_io_apic_irq_attr

[ Impact: cleanup ]
Signed-off-by: NYinghai Lu <yinghai@kernel.org>
Cc: Andrew Morton <akpm@linux-foundation.org>
Cc: Jesse Barnes <jbarnes@virtuousgeek.org>
Cc: Len Brown <lenb@kernel.org>
LKML-Reference: <4A08ACD3.2070401@kernel.org>
Signed-off-by: NIngo Molnar <mingo@elte.hu>
      e5198075
  21. 11 5月, 2009 2 次提交
  23. 23 4月, 2009 4 次提交
  25. 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
  27. 27 3月, 2009 1 次提交
  29. 24 3月, 2009 1 次提交
  31. 21 3月, 2009 3 次提交
  33. 20 3月, 2009 2 次提交
  35. 12 3月, 2009 1 次提交
  37. 18 2月, 2009 1 次提交
  39. 06 2月, 2009 1 次提交
  41. 29 1月, 2009 2 次提交
  43. 28 1月, 2009 1 次提交
  45. 14 1月, 2009 1 次提交
  47. 08 1月, 2009 7 次提交