- Dec 05, 2009
-
-
Kenji Kaneshige authored
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:
Alex Chiang <achiang@hp.com> Tested-by:
Kenji Kaneshige <kaneshige.kenji@jp.fujitsu.com> Signed-off-by:
Jesse Barnes <jbarnes@virtuousgeek.org>
-
Andrew Patterson authored
The pci_cleanup_aer_correct_error_status() function has been #if 0'd out since 2.6.25. Time to remove the dead code. Signed-off-by:
Andrew Patterson <andrew.patterson@hp.com> Signed-off-by:
-
Andrew Patterson authored
The current implementation of pci_cleanup_aer_uncorrect_error_status only clears either fatal or non-fatal error status bits depending on the state of the I/O channel. This implementation will then often leave some bits set after PCI error recovery completes. The uncleared bit settings will then be falsely reported the next time an AER interrupt is generated for that hierarchy. An easy way to illustrate this issue is to use the aer-inject module to simultaneously inject both an uncorrectable non-fatal and uncorrectable fatal error. One of the errors will not be cleared. This patch resolves this issue by unconditionally clearing all bits in the AER uncorrectable status register. All settings and corrective action strategies are saved and determined before pci_cleanup_aer_uncorrect_error_status is called, so this change should not affect errory handling functionality. Signed-off-by:
-
Yinghai Lu authored
This allows us to use the BIOS SR-IOV allocations rather than assigning our own later on. Signed-off-by:
Yinghai Lu <yinghai@kernel.org> Signed-off-by:
-
Kenji Kaneshige authored
Remove unnecessary definitions from portdrv.h and use generic definitions instead. Signed-off-by:
-
Kenji Kaneshige authored
Remove 'port_type' field in struct pcie_port_data(), because we can get port type information from struct pci_dev. With this change, this patch also does followings: - Remove struct pcie_port_data because it no longer has any field. - Remove portdrv private definitions about port type (PCIE_RC_PORT, PCIE_SW_UPSTREAM_PORT and PCIE_SW_DOWNSTREAM_PORT), and use generic definitions instead. Signed-off-by:
-
Kenji Kaneshige authored
Minor cleanups for pcie_port_device_register(). Signed-off-by:
-
Kenji Kaneshige authored
Add missing service irqs cleanup in the error code path of pcie_port_device_register(). Signed-off-by:
-
Kenji Kaneshige authored
Call pci_enable_device() before initializing service irqs, because legacy interrupt is initialized in pci_enable_device() on some architectures. Signed-off-by:
-
Kenji Kaneshige authored
This patch cleans up the service irqs initialization as follows: - Remove 'irq_mode' field in pcie_port_data and related definitions, which is not needed because we can get the same information from 'is_msix', 'is_msi' and 'pin' fields in struct pci_dev. - Change the name of 'vectors' argument of assign_interrupt_mode() to 'irqs' because it holds irq numbers actually. People might confuse it with CPU vector or MSI/MSI-X vector. - Change function name assign_interrupt_mode() to init_service_irqs() becasuse we no longer have 'irq_mode' data structure, and new name is more straightforward (IMO). Signed-off-by:
-
Kenji Kaneshige authored
Move capability check capability to the beginning of pcie_port_device_register() prevents redundant execution path. Signed-off-by:
-
Kenji Kaneshige authored
No reason to check PME capability outside get_port_device_capability(). Do it in get_port_device_capability(). Signed-off-by:
-
Kenji Kaneshige authored
PCIe port type is already stored in 'pcie_type' field of struct pci_dev. So we don't need to get it from pci configuration space. Signed-off-by:
-
Kenji Kaneshige authored
In the current port bus driver implementation, pcie_device allocation, initialization and registration are done in separated functions. Doing those in one function make the code simple and easier to read. Signed-off-by:
-
Kenji Kaneshige authored
We don't need pcie_port_device_probe() because we can get pci device/port type using pci_is_pcie() and 'pcie_type' fields in struct pci_dev. Remove pcie_port_device_probe(). Signed-off-by:
-
Alex Williamson authored
Prior to 1f82de10 we always initialized the upper 32bits of the prefetchable memory window, regardless of the address range used. Now we only touch it for a >32bit address, which means the upper32 registers remain whatever the BIOS initialized them too. It's valid for the BIOS to set the upper32 base/limit to 0xffffffff/0x00000000, which makes us program prefetchable ranges like 0xffffffffabc00000 - 0x00000000abc00000 Revert the chunk of 1f82de10 that made this conditional so we always write the upper32 registers and remove now unused pref_mem64 variable. Signed-off-by:
Alex Williamson <alex.williamson@hp.com> Signed-off-by:
-
Shmulik Ravid authored
The pcie_flr routine writes the device control register with the FLR bit set clearing all other fields for the FLR duration. Among other fields, the Max_Payload_Size is also cleared which can cause errors if there are transactions lurking in the HW pipeline. The patch replaces the blank write with read-modify-write of the control register keeping the other fields intact. Signed-off-by:
Shmulik Ravid <shmulikr@broadcom.com> Signed-off-by:
-
Yinghai Lu authored
So we can catch if the driver sets an incorrect dma_mask. Reviewed-by:
Grant Grundler <grundler@google.com> Signed-off-by:
-
Yinghai Lu authored
This allows us to find out what DMA mask is used for each PCI device at boot time; useful for debugging. After the patch: ehci_hcd 0000:00:02.1: using 31bit consistent DMA mask e1000 0000:0b:01.0: using 64bit DMA mask e1000 0000:0b:01.0: using 64bit consistent DMA mask e1000e 0000:04:00.0: using 64bit DMA mask e1000e 0000:04:00.0: using 64bit consistent DMA mask ixgb 0000:0c:01.0: using 64bit DMA mask ixgb 0000:0c:01.0: using 64bit consistent DMA mask aacraid 0000:86:00.0: using 32bit DMA mask aacraid 0000:86:00.0: using 32bit consistent DMA mask aacraid 0000:86:00.0: using 64bit DMA mask aacraid 0000:86:00.0: using 64bit consistent DMA mask qla2xxx 0000:0c:02.0: using 64bit consistent DMA mask qla2xxx 0000:0c:02.1: using 64bit consistent DMA mask lpfc 0000:06:00.0: using 64bit DMA mask lpfc 0000:06:00.1: using 64bit DMA mask pata_amd 0000:00:06.0: using 32bit DMA mask pata_amd 0000:00:06.0: using 32bit consistent DMA mask mptsas 0000:0c:04.0: using 64bit DMA mask mptsas 0000:0c:04.0: using 64bit consistent DMA mask forcedeth 0000:00:08.0: using 39bit DMA mask forcedeth 0000:00:08.0: using 39bit consistent DMA mask niu 0000:02:00.0: using 44bit DMA mask niu 0000:02:00.0: using 44bit consistent DMA mask sata_nv 0000:00:05.0: using 32bit DMA mask sata_nv 0000:00:05.0: using 32bit consistent DMA mask ib_mthca 0000:03:00.0: using 64bit DMA mask ib_mthca 0000:03:00.0: using 64bit consistent DMA mask Reviewed-by:
-
Jesse Barnes authored
If we stop the kthread, we may end up up'ing the sem twice, which seems unintended. Reported-by:
Dan Carpenter <error27@gmail.com> Signed-off-by:
-
- Nov 25, 2009
-
-
Bjorn Helgaas authored
This patch factors out the search for an MMCONFIG region, which was previously implemented in both mmconfig_32 and mmconfig_64. No functional change. Reviewed-by:
Bjorn Helgaas <bjorn.helgaas@hp.com> Signed-off-by:
-
Bjorn Helgaas authored
No functional change; just tidy up printks and make them more consistent with the rest of PCI. Reviewed-by:
-
Bjorn Helgaas authored
This is only used internally now, but eventually will be used in the hot-remove path to remove the MMCONFIG region associated with a host bridge. Reviewed-by:
-
Bjorn Helgaas authored
This changes pci_mmcfg_region from a table to a list, to make it easier to add and remove MMCONFIG regions for PCI host bridge hotplug. Reviewed-by:
-
Bjorn Helgaas authored
This replaces "typeof(pci_mmcfg_config[0])" with the actual type because I plan to convert pci_mmcfg_config to a list, and then "pci_mmcfg_config[0]" won't mean anything. Reviewed-by:
-
Bjorn Helgaas authored
The virtual address is only used for x86_64, but it's so much simpler to manage it as part of the pci_mmcfg_region that I think it's worth wasting a pointer per MMCONFIG region on x86_32. Reviewed-by:
-
Bjorn Helgaas authored
Since pci_mmcfg_region contains the struct resource, no need to pass the pci_mmcfg_region *and* the resource start/size. Reviewed-by:
-
Bjorn Helgaas authored
This patch adds a resource and corresponding name to the MMCONFIG structure. This makes allocation simpler (we can allocate the resource and name at the same time we allocate the pci_mmcfg_region), and gives us a way to hang onto the resource after inserting it. This will be needed so we can release and free it when hot-removing a host bridge. Reviewed-by:
-
Bjorn Helgaas authored
No functional change, but simplifies a future patch to convert the table to a list. Reviewed-by:
-
Bjorn Helgaas authored
This only renames the struct pci_mmcfg_region members; no functional change. Reviewed-by:
-
Bjorn Helgaas authored
This adds a struct pci_mmcfg_region with a little more information than the struct acpi_mcfg_allocation used previously. The acpi_mcfg structure is defined by the spec, so we can't change it. To begin with, struct pci_mmcfg_region is basically the same as the ACPI MCFG version, but future patches will add more information. Reviewed-by:
-
Bjorn Helgaas authored
This factors out the common "bus << 20" expression used when computing the MMCONFIG address. Reviewed-by:
-
Bjorn Helgaas authored
Since all MMCONFIG regions go through pci_mmconfig_add(), we can test the address once there. If the caller supplies an address of zero, we never insert it in the pci_mmcfg_config[] table, so no need to test it elsewhere. Reviewed-by:
-
Bjorn Helgaas authored
We never set pci_mmcfg_config unless we increment pci_mmcfg_config_num, so there's no need to test both pci_mmcfg_config_num and pci_mmcfg_config. Reviewed-by:
-
Bjorn Helgaas authored
This patch encapsulate pci_mmcfg_config[] updates. All alloc/free is now done in pci_mmconfig_add() and free_all_mcfg(), so all updates to pci_mmcfg_config[] and pci_mmcfg_config_num are in those two functions. This replaces the previous sequence of extend_mmcfg(), fill_one_mmcfg() with the single pci_mmconfig_add() interface. This interface is currently static but will eventually be used in the host bridge hot-add path. Reviewed-by:
-
Bjorn Helgaas authored
Step through the ACPI MCFG table, not pci_mmcfg_config[]. No functional change, but simplifies future patches that encapsulate pci_mmcfg_config[]. Reviewed-by:
-
Bjorn Helgaas authored
Use a local variable, not pci_mmcfg_config_num, to count MCFG entries. No functional change, but simplifies future changes. Reviewed-by:
-
Bjorn Helgaas authored
Reviewed-by:
-
Yinghai Lu authored
Those functions are used by intel_bus.c so seperate them to another file. and make amd_bus a bit smaller. Signed-off-by:
-
Jiri Kosina authored
Signed-off-by:
André Goddard Rosa <andre.goddard@gmail.com> Signed-off-by:
Jiri Kosina <jkosina@suse.cz> Signed-off-by:
-
