1. 17 12月, 2009 1 次提交
  2. 05 12月, 2009 1 次提交
    • K
      PCI: fix BUG_ON triggered by logical PCIe root port removal · b26a34aa
      Kenji Kaneshige 提交于
      This problem happened when removing PCIe root port using PCI logical
      hotplug operation.
      
      The immediate cause of this problem is that the pointer to invalid
      data structure is passed to pcie_update_aspm_capable() by
      pcie_aspm_exit_link_state(). When pcie_aspm_exit_link_state() received
      a pointer to root port link, it unconfigures the root port link and
      frees its data structure at first. At this point, there are not links
      to configure under the root port and the data structure for root port
      link is already freed. So pcie_aspm_exit_link_state() must not call
      pcie_update_aspm_capable() and pcie_config_aspm_path().
      
      This patch fixes the problem by changing pcie_aspm_exit_link_state()
      not to call pcie_update_aspm_capable() and pcie_config_aspm_path() if
      the specified link is root port link.
      
      ------------[ cut here ]------------
      kernel BUG at drivers/pci/pcie/aspm.c:606!
      invalid opcode: 0000 [#1] SMP DEBUG_PAGEALLOC
      last sysfs file: /sys/devices/pci0000:40/0000:40:13.0/remove
      CPU 1
      Modules linked in: shpchp
      Pid: 9345, comm: sysfsd Not tainted 2.6.32-rc5 #98 ProLiant DL785 G6
      RIP: 0010:[<ffffffff811df69b>]  [<ffffffff811df69b>] pcie_update_aspm_capable+0x15/0xbe
      RSP: 0018:ffff88082a2f5ca0  EFLAGS: 00010202
      RAX: 0000000000000e77 RBX: ffff88182cc3e000 RCX: ffff88082a33d006
      RDX: 0000000000000001 RSI: ffffffff811dff4a RDI: ffff88182cc3e000
      RBP: ffff88082a2f5cc0 R08: ffff88182cc3e000 R09: 0000000000000000
      R10: ffff88182fc00180 R11: ffff88182fc00198 R12: ffff88182cc3e000
      R13: 0000000000000000 R14: ffff88182cc3e000 R15: ffff88082a2f5e20
      FS:  00007f259a64b6f0(0000) GS:ffff880864600000(0000) knlGS:0000000000000000
      CS:  0010 DS: 0018 ES: 0018 CR0: 000000008005003b
      CR2: 00007feb53f73da0 CR3: 000000102cc94000 CR4: 00000000000006e0
      DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
      DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
      Process sysfsd (pid: 9345, threadinfo ffff88082a2f4000, task ffff88082a33cf00)
      Stack:
       ffff88182cc3e000 ffff88182cc3e000 0000000000000000 ffff88082a33cf00
      <0> ffff88082a2f5cf0 ffffffff811dff52 ffff88082a2f5cf0 ffff88082c525168
      <0> ffff88402c9fd2f8 ffff88402c9fd2f8 ffff88082a2f5d20 ffffffff811d7db2
      Call Trace:
       [<ffffffff811dff52>] pcie_aspm_exit_link_state+0xf5/0x11e
       [<ffffffff811d7db2>] pci_stop_bus_device+0x76/0x7e
       [<ffffffff811d7d67>] pci_stop_bus_device+0x2b/0x7e
       [<ffffffff811d7e4f>] pci_remove_bus_device+0x15/0xb9
       [<ffffffff811dcb8c>] remove_callback+0x29/0x3a
       [<ffffffff81135aeb>] sysfs_schedule_callback_work+0x15/0x6d
       [<ffffffff81072790>] worker_thread+0x19d/0x298
       [<ffffffff8107273b>] ? worker_thread+0x148/0x298
       [<ffffffff81135ad6>] ? sysfs_schedule_callback_work+0x0/0x6d
       [<ffffffff810765c0>] ? autoremove_wake_function+0x0/0x38
       [<ffffffff810725f3>] ? worker_thread+0x0/0x298
       [<ffffffff8107629e>] kthread+0x7d/0x85
       [<ffffffff8102eafa>] child_rip+0xa/0x20
       [<ffffffff8102e4bc>] ? restore_args+0x0/0x30
       [<ffffffff81076221>] ? kthread+0x0/0x85
       [<ffffffff8102eaf0>] ? child_rip+0x0/0x20
      Code: 89 e5 8a 50 48 31 c0 c0 ea 03 83 e2 07 e8 b2 de fe ff c9 48 98 c3 55 48 89 e5 41 56 49 89 fe 41 55 41 54 53 48 83 7f 10 00 74 04 <0f> 0b eb fe 48 8b 05 da 7d 63 00 4c 8d 60 e8 4c 89 e1 eb 24 4c
      RIP  [<ffffffff811df69b>] pcie_update_aspm_capable+0x15/0xbe
       RSP <ffff88082a2f5ca0>
      ---[ end trace 6ae0f65bdeab8555 ]---
      Reported-by: NAlex Chiang <achiang@hp.com>
      Tested-by: NAlex Chiang <achiang@hp.com>
      Signed-off-by: NKenji Kaneshige <kaneshige.kenji@jp.fujitsu.com>
      Signed-off-by: NJesse Barnes <jbarnes@virtuousgeek.org>
      b26a34aa
  3. 25 11月, 2009 2 次提交
  4. 07 11月, 2009 1 次提交
    • K
      PCI ASPM: fix oops on root port removal · 761434a3
      Kenji Kaneshige 提交于
      Fix the following BUG_ON() problem reported by Alex Chiang.
      
      This problem happened when removing PCIe root port using PCI logical
      hotplug operation.
      
      The immediate cause of this problem is that the pointer to invalid
      data structure is passed to pcie_update_aspm_capable() by
      pcie_aspm_exit_link_state(). When pcie_aspm_exit_link_state() received
      a pointer to root port link, it unconfigures the root port link and
      frees its data structure at first. At this point, there are not links
      to configure under the root port and the data structure for root port
      link is already freed. So pcie_aspm_exit_link_state() must not call
      pcie_update_aspm_capable() and pcie_config_aspm_path().
      
      This patch fixes the problem by changing pcie_aspm_exit_link_state()
      not to call pcie_update_aspm_capable() and pcie_config_aspm_path() if
      the specified link is root port link.
      
      ------------[ cut here ]------------
      kernel BUG at drivers/pci/pcie/aspm.c:606!
      invalid opcode: 0000 [#1] SMP DEBUG_PAGEALLOC
      last sysfs file: /sys/devices/pci0000:40/0000:40:13.0/remove
      CPU 1
      Modules linked in: shpchp
      Pid: 9345, comm: sysfsd Not tainted 2.6.32-rc5 #98 ProLiant DL785 G6
      RIP: 0010:[<ffffffff811df69b>]  [<ffffffff811df69b>] pcie_update_aspm_capable+0x15/0xbe
      RSP: 0018:ffff88082a2f5ca0  EFLAGS: 00010202
      RAX: 0000000000000e77 RBX: ffff88182cc3e000 RCX: ffff88082a33d006
      RDX: 0000000000000001 RSI: ffffffff811dff4a RDI: ffff88182cc3e000
      RBP: ffff88082a2f5cc0 R08: ffff88182cc3e000 R09: 0000000000000000
      R10: ffff88182fc00180 R11: ffff88182fc00198 R12: ffff88182cc3e000
      R13: 0000000000000000 R14: ffff88182cc3e000 R15: ffff88082a2f5e20
      FS:  00007f259a64b6f0(0000) GS:ffff880864600000(0000) knlGS:0000000000000000
      CS:  0010 DS: 0018 ES: 0018 CR0: 000000008005003b
      CR2: 00007feb53f73da0 CR3: 000000102cc94000 CR4: 00000000000006e0
      DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
      DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
      Process sysfsd (pid: 9345, threadinfo ffff88082a2f4000, task ffff88082a33cf00)
      Stack:
       ffff88182cc3e000 ffff88182cc3e000 0000000000000000 ffff88082a33cf00
      <0> ffff88082a2f5cf0 ffffffff811dff52 ffff88082a2f5cf0 ffff88082c525168
      <0> ffff88402c9fd2f8 ffff88402c9fd2f8 ffff88082a2f5d20 ffffffff811d7db2
      Call Trace:
       [<ffffffff811dff52>] pcie_aspm_exit_link_state+0xf5/0x11e
       [<ffffffff811d7db2>] pci_stop_bus_device+0x76/0x7e
       [<ffffffff811d7d67>] pci_stop_bus_device+0x2b/0x7e
       [<ffffffff811d7e4f>] pci_remove_bus_device+0x15/0xb9
       [<ffffffff811dcb8c>] remove_callback+0x29/0x3a
       [<ffffffff81135aeb>] sysfs_schedule_callback_work+0x15/0x6d
       [<ffffffff81072790>] worker_thread+0x19d/0x298
       [<ffffffff8107273b>] ? worker_thread+0x148/0x298
       [<ffffffff81135ad6>] ? sysfs_schedule_callback_work+0x0/0x6d
       [<ffffffff810765c0>] ? autoremove_wake_function+0x0/0x38
       [<ffffffff810725f3>] ? worker_thread+0x0/0x298
       [<ffffffff8107629e>] kthread+0x7d/0x85
       [<ffffffff8102eafa>] child_rip+0xa/0x20
       [<ffffffff8102e4bc>] ? restore_args+0x0/0x30
       [<ffffffff81076221>] ? kthread+0x0/0x85
       [<ffffffff8102eaf0>] ? child_rip+0x0/0x20
      Code: 89 e5 8a 50 48 31 c0 c0 ea 03 83 e2 07 e8 b2 de fe ff c9 48 98 c3 55 48 89 e5 41 56 49 89 fe 41 55 41 54 53 48 83 7f 10 00 74 04 <0f> 0b eb fe 48 8b 05 da 7d 63 00 4c 8d 60 e8 4c 89 e1 eb 24 4c
      RIP  [<ffffffff811df69b>] pcie_update_aspm_capable+0x15/0xbe
       RSP <ffff88082a2f5ca0>
      ---[ end trace 6ae0f65bdeab8555 ]---
      Reported-by: NAlex Chiang <achiang@hp.com>
      Signed-off-by: NKenji Kaneshige <kaneshige.kenji@jp.fujitsu.com>
      Tested-by: NAlex Chiang <achiang@hp.com>
      Signed-off-by: NJesse Barnes <jbarnes@virtuousgeek.org>
      761434a3
  5. 18 9月, 2009 1 次提交
    • K
      PCI ASPM: support L1 only · 7557b5d6
      Kenji Kaneshige 提交于
      The definition of the ASPM support field in the Link Capabilities
      Register had been changed by the "ASPM optionality ECN" as follows:
      
      <Before>
      	00b	Reserved
      	01b	L0s Supported
      	10b	Reserved
      	11b	L0s and L1 Supported
      
      <After>
      	00b	No ASPM Support
      	01b	L0s Supported
      	10b	L1 Supported
      	11b	L0s and L1 Supported
      
      Current linux ASPM driver doesn't enable ASPM if the support field is
      00b or 10b. So there is no impact about 00b. But current linux ASPM
      driver doesn't enable L1 if the support field is 10b. With this patch,
      10b (L1 support) is handled properly.
      Signed-off-by: NKenji Kaneshige <kaneshige.kenji@jp.fujitsu.com>
      Signed-off-by: NJesse Barnes <jbarnes@virtuousgeek.org>
      7557b5d6
  6. 10 9月, 2009 7 次提交
  7. 19 6月, 2009 14 次提交
  8. 12 6月, 2009 1 次提交
  9. 05 2月, 2009 1 次提交
    • A
      PCI: properly clean up ASPM link state on device remove · 3419c75e
      Alex Chiang 提交于
      We only want to disable ASPM when the last function is removed from
      the parent's device list. We determine this by checking to see if
      the parent's device list is completely empty.
      
      Unfortunately, we never hit that code because the parent is considered
      an upstream port, and never had an ASPM link_state associated with it.
      
      The early check for !link_state causes us to return early, we never
      discover that our device list is empty, and thus we never remove the
      downstream ports' link_state nodes.
      
      Instead of checking to see if the parent's device list is empty, we can
      check to see if we are the last device on the list, and if so, then we
      know that we can clean up properly.
      
      Cc: Shaohua Li <shaohua.li@intel.com>
      Signed-off-by: NAlex Chiang <achiang@hp.com>
      Signed-off-by: NJesse Barnes <jbarnes@virtuousgeek.org>
      3419c75e
  10. 08 1月, 2009 3 次提交
  11. 10 12月, 2008 1 次提交
  12. 21 10月, 2008 1 次提交
    • V
      PCI: probing debug message uniformization · f393d9b1
      Vincent Legoll 提交于
      This patch uniformizes PCI probing debug boot messages with dev_printk()
      intead of manual printk()
      
      It changes adress range output from [%llx, %llx] to [%#llx-%#llx], like
      in pci_request_region().
      
      For example, it goes from the mixed-style:
      
      PCI: 0000:00:1b.0 reg 10 64bit mmio: [f4280000, f4283fff]
      pci 0000:00:1b.0: PME# supported from D0 D3hot D3cold
      
      to uniform:
      
      pci 0000:00:1b.0: reg 10 64bit mmio: [0xf4280000-0xf4283fff]
      pci 0000:00:1b.0: PME# supported from D0 D3hot D3cold
      
      This patch has been runtime tested, boot log messages diffed, everything
      looks OK.
      Acked-by: NBjorn Helgaas <bjorn.helgaas@hp.com>
      Signed-off-by: NVincent Legoll <vincent.legoll@gmail.com>
      Signed-off-by: NJesse Barnes <jbarnes@virtuousgeek.org>
      f393d9b1
  13. 17 9月, 2008 1 次提交
  14. 29 7月, 2008 3 次提交
  15. 22 5月, 2008 1 次提交
  16. 21 4月, 2008 1 次提交
    • S
      PCI: add PCI Express ASPM support · 7d715a6c
      Shaohua Li 提交于
      PCI Express ASPM defines a protocol for PCI Express components in the D0
      state to reduce Link power by placing their Links into a low power state
      and instructing the other end of the Link to do likewise. This
      capability allows hardware-autonomous, dynamic Link power reduction
      beyond what is achievable by software-only controlled power management.
      However, The device should be configured by software appropriately.
      Enabling ASPM will save power, but will introduce device latency.
      
      This patch adds ASPM support in Linux. It introduces a global policy for
      ASPM, a sysfs file /sys/module/pcie_aspm/parameters/policy can control
      it. The interface can be used as a boot option too. Currently we have
      below setting:
              -default, BIOS default setting
              -powersave, highest power saving mode, enable all available ASPM
      state and clock power management
              -performance, highest performance, disable ASPM and clock power
      management
      By default, the 'default' policy is used currently.
      
      In my test, power difference between powersave mode and performance mode
      is about 1.3w in a system with 3 PCIE links.
      
      Note: some devices might not work well with aspm, either because chipset
      issue or device issue. The patch provide API (pci_disable_link_state),
      driver can disable ASPM for specific device.
      Signed-off-by: NShaohua Li <shaohua.li@intel.com>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>
      7d715a6c