On Wed, Nov 4, 2015 at 4:50 PM, Amanieu d'Antras wrote:
> One issue that isn't resolved in this series is sending signals between a
> 32-bit
> process and 64-bit process. Sending a si_int will work correctly, but a si_ptr
> value will likely get corrupted due to the different layouts of the 32-bi
On Sat, Nov 7, 2015 at 9:01 PM, Denis Kirjanov wrote:
>> Does Anyone see this calltrace? I see it from 3.19 to 4.3, did not
>> test it on other older release.
>
> http://www.gossamer-threads.com/lists/linux/kernel/2297694
I see this calltrace on 3.19, so it should not related to patch“
[PATCH V
PFs are enumerated on PCI bus, while VFs are created by PF's driver.
In EEH recovery, it has two cases:
1. Device and driver is EEH aware, error handlers are called.
2. Device and driver is not EEH aware, un-plug the device and plug it again
by enumerating it.
The special thing happens on the sec
After PE reset, OPAL API opal_pci_reinit() is called on all devices
contained in the PE to reinitialize them. While skiboot is not aware of
VFs, we have to implement the function in kernel to reinitialize VFs after
reset on PE for VFs.
In this patch, two functions pnv_pci_fixup_vf_mps() and
pnv_ee
PEs for VFs don't have primary bus. So they have to have their own reset
backend, which is used during EEH recovery. The patch implements the reset
backend for VF's PE by issuing FLR or AF FLR to the VFs, which are contained
in the PE.
Signed-off-by: Wei Yang
---
arch/powerpc/include/asm/eeh.h
The patch creates PEs for VFs in the weak function
pcibios_bus_add_device(). Those PEs for VFs are identified with newly
introduced flag EEH_PE_VF so that we handle them differently during EEH
recovery.
Signed-off-by: Wei Yang
---
arch/powerpc/include/asm/eeh.h | 1 +
arch/powerpc
This patchset enables EEH on SRIOV VFs. The general idea is to create proper
VF edev and VF PE and handle them properly.
Different from the Bus PE, VF PE just contain one VF. This introduces the
difference of EEH error handling on a VF PE. Generally, it has several
differences.
First, the VF's re
VFs and their corresponding pci_dn instances are created and released
dynamically as their PF's SRIOV capability is enabled and disabled.
The patch creates and releases EEH devices for VFs when creating and
releasing their pci_dn instances, which means EEH devices and pci_dn
instances have same lif
This restricts the EEH address cache to use only the first 7 BARs. This
makes __eeh_addr_cache_insert_dev() ignore PCI bridge window and IOV BARs.
As the result of this change, eeh_addr_cache_get_dev() will return VFs from
VF's resource addresses instead of parent PFs.
This removes extra check for
As commit ac205b7bb72f ("PCI: make sriov work with hotplug remove")
indicates, VFs which is on the same PCI bus as their PF, should be removed
before the PF. Otherwise, the PCI hot unplugging of PCI devices on the PCI
bus would cause kernel crash.
The patch applies the above pattern to PowerPC PCI
During EEH recovery, hotplug is applied to the devices which don't
have drivers or their drivers don't support EEH. However, the hotplug,
which was implemented based on PCI bus, can't be applied to VF directly.
Rename virtn_{add,remove}() and export them so they can be used in PCI
hotplug during E
Add a weak function pcibios_bus_add_device() for arch dependent code could
do proper setup. For example, powerpc could setup EEH related resources.
Signed-off-by: Wei Yang
Acked-by: Bjorn Helgaas
---
drivers/pci/bus.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/pci/bus.c b/dr
On 11/7/15, Li RongQing wrote:
> Does Anyone see this calltrace? I see it from 3.19 to 4.3, did not
> test it on other older release.
http://www.gossamer-threads.com/lists/linux/kernel/2297694
>
>
> EXT4-fs (hda): recovery complete
> EXT4-fs (hda): mounted filesystem with ordered data mode. Opt
Le 07/11/2015 00:24, Scott Wood a écrit :
> On Fri, 2015-11-06 at 23:22 +0100, Laurent Vivier wrote:
>> Le 06/11/2015 22:09, Scott Wood a écrit :
>>> On Thu, 2015-11-05 at 12:47 +0100, Laurent Vivier wrote:
When I try to cross compile a ppc64 kernel, it generally
fails on the VDSO stage
Le 07/11/2015 00:12, Benjamin Herrenschmidt a écrit :
> On Fri, 2015-11-06 at 15:09 -0600, Scott Wood wrote:
>> On Thu, 2015-11-05 at 12:47 +0100, Laurent Vivier wrote:
>>> When I try to cross compile a ppc64 kernel, it generally
>>> fails on the VDSO stage. This is true for powerpc64 cross-
>>>
Le 07/11/2015 00:32, Segher Boessenkool a écrit :
> On Fri, Nov 06, 2015 at 04:55:49PM -0600, Segher Boessenkool wrote:
>> On Fri, Nov 06, 2015 at 03:09:40PM -0600, Scott Wood wrote:
>>> Why is GCC building ppc64 object files but telling the linker --oformat
>>> elf32-
>>> powerpcle? Are differ
16 matches
Mail list logo
