- 30 Sep, 2014 24 commits
-
-
Gavin Shan authored
It should have been part of commit 1ad7a72c ("powerpc/eeh: Report frozen parent PE prior to child PE"). There are 2 ways to report EEH errors: proactively polling because of 0xFF's returned from PCI config or IO read, or interrupt driven event. We missed to report and handle parent frozen PE prior to child frozen PE for the later case on PowerNV platform. Signed-off-by:
Gavin Shan <gwshan@linux.vnet.ibm.com> Signed-off-by:
Michael Ellerman <mpe@ellerman.id.au>
-
Gavin Shan authored
The PEs can be organized as nested. Current implementation doesn't dump PCI config space for subordinate devices of child PEs. However, the frozen PE could be caused by those subordinate devices of its child PEs. The patch dumps PCI config space for all subordinate devices of the problematic PE. Signed-off-by:
-
Gavin Shan authored
When enabling EEH functionality on passed through devices (PE) with VFIO, the devices in the PE would be removed permanently from guest side. In that case, the PE remains frozen state. When returning PE to host, or restarting the guest again, we had mechanism unfreezing the PE by clearing PESTA/B frozen bits. However, that's not enough for some adapters, which are indicated as following "lspci" shows. Those adapters require hot reset on the parent bus to bring their firmware back to workable state. Otherwise, those adaptrs won't be operative and the host (for returning case) or the guest will fail to load the drivers for those adapters without exception. 0000:01:00.0 Ethernet controller: Emulex Corporation OneConnect \ 10Gb NIC (be3) (rev 02) 0000:01:00.0 0200: 19a2:0710 (rev 02) 0001:03:00.0 Ethernet controller: Emulex Corporation OneConnect \ NIC (Lancer) (rev 10) 0001:03:00.0 0200: 10df:e220 (rev 10) The patch adds mechanism to emulate EEH recovery (for hot reset on parent PCI bus) on 3 gates to fix the issue: open/release one adapter of the PE, enable EEH functionality on one adapter of the PE. Reported-by:Murilo Fossa Vicentini <muvic@br.ibm.com> Signed-off-by:
-
Gavin Shan authored
PE would be owned by userland, which probably request PE reset done in host side. During the reset, we should drop the PCI config accesses to the PE with help of flag EEH_PE_RESET. Signed-off-by:
-
Gavin Shan authored
The names of PCI reset scopes aren't sychronized with firmware. The patch fixes it. Signed-off-by:
-
Gavin Shan authored
As Anton suggested, the patch decreases the message level on EEH initialization to avoid unnecessary messages if required. Also, we have unified hint if any of needful RTAS calls is missed, and then we can check /proc/device-tree to figure out the missed RTAS calls. Suggested-by:
Anton Blanchard <anton@samba.org> Signed-off-by:
-
Gavin Shan authored
Function pcibios_set_pcie_reset_state() can be used to do PCI reset. PCI config access during the reset usually causes EEH errors unexpectedly. In order to avoid the EEH error, the patch blocks PCI config access during reset with the help of flag EEH_PE_RESET, which is similar to what we did in EEH PE reset path. Signed-off-by:
-
Gavin Shan authored
The patch uses eeh_unfreeze_pe() to replace the logic clearing frozen IO and DMA, in order to simplify the code. Signed-off-by:
-
Gavin Shan authored
When passing through PE to guest, that's possibly in frozen state. The driver for the pass-through devices on guest side can't be loaded successfully as reported. We already had one gate in eeh_dev_open() to clear PE frozen state accordingly, but that's not enough because the function is only called at QEMU startup for once. The patch adds another gate in eeh_pe_set_option() so that the PE frozen state can be cleared at QEMU restart time. Signed-off-by:
-
Gavin Shan authored
The function eeh_pci_enable() is called to apply various requests to one particular PE: Enabling EEH, Disabling EEH, Enabling IO, Enabling DMA, Freezing PE. When enabling IO or DMA on one specific PE, we need check that IO or DMA isn't enabled previously. But the condition used to do the check isn't completely correct because one PE would be in DMA frozen state with workable IO path, or vice versa. The patch fixes the improper condition. Signed-off-by:
-
Gavin Shan authored
The problem was reported by Carol: In the scenario of passing mlx4 adapter to guest, EEH error could be recovered successfully. When returning the device back to host, the driver (mlx4_core.ko) couldn't be loaded successfully because of error number -5 (-EIO) returned from mlx4_get_ownership(), which hits offlined PCI device. The root cause is that we missed to put the affected devices into normal state on clearing PE isolated state right after PE reset. The patch fixes above issue by putting the affected devices to normal state when clearing PE isolated state in eeh_pe_state_clear(). Cc: stable@vger.kernel.org Reported-by:
Carol L. Soto <clsoto@us.ibm.com> Signed-off-by:
-
Gavin Shan authored
The frozen state on one specific PE is probably caused by error injection, which is done with help of PAPR error injection registers. According to the hardware spec, those registers should be cleared automatically after one-shot frozen PE. However, that's not always true, at least on P7IOC of Firebird-L. So we have to clear them before doing PE reset to avoid recursive EEH errors at recovery stage. Signed-off-by:
-
Mike Qiu authored
The patch adds debugfs file (/sys/kernel/debug/powerpc/PCIxxxx/ err_injct), which accepts following formated string, to support error injection. It will be used to support userland utility "errinjct" in future. "pe_no:0:function:address:mask" - 32-bits PCI errors "pe_no:1:function:address:mask" - 64-bits PCI errors Signed-off-by:
Mike Qiu <qiudayu@linux.vnet.ibm.com> Signed-off-by:
-
Gavin Shan authored
The patch introduces eeh_ops::err_inject(), which allows to inject specified errors to indicated PE for testing purpose. The functionality isn't support on pSeries platform. On PowerNV, the functionality relies on OPAL API opal_pci_err_inject(). Signed-off-by:
-
Gavin Shan authored
The patch synchronizes firmware header file (opal.h) for PCI error injection. Signed-off-by:
-
Gavin Shan authored
When passing through device, its PE might have been put into frozen state. One obvious example would be: the passed PE is forced to be offline because of hitting maximal allowed EEH errors in userland. In that case, the frozen state won't be cleared and then the PE is returned back to host, which might not have chance detecting and recovering from it. The patch adds more check when passing through device and clear the PE frozen state if necessary. Signed-off-by:
-
Gavin Shan authored
The PCI devices that have been passed through are enabled before reset, we need restore to the enabled state after reset. Otherwise, MMIO access might be issued to disabled devices after reset and causes exceptional recursive EEH error. Signed-off-by:
-
Gavin Shan authored
The patch adds one more option (EEH_OPT_FREEZE_PE) to set_option() method to proactively freeze PE, which will be issued before resetting pass-throughed PE to drop MMIO access during reset because it's always contributing to recursive EEH error. Signed-off-by:
-
Gavin Shan authored
The patch adds sysfs entry "eeh_pe_state". Reading on it returns the PE's state while writing to it clears the frozen state. It's used to check or clear the PE frozen state from userland for debugging purpose. The patch also replaces printk(KERN_WARNING ...) with pr_warn() in eeh_sysfs.c Signed-off-by:
-
Gavin Shan authored
eeh_check_failure() is used to check frozen state of the PE which owns the indicated I/O address. The argument "val" of the function isn't used. The patch drops it and return the frozen state of the PE as expected. Cc: Vishal Mansur <vmansur@linux.vnet.ibm.com> Signed-off-by:
-
Anton Blanchard authored
Enable on DCACHE_WORD_ACCESS on ppc64le. It should work on ppc64 and ppc32 but we need to do some testing first. A somewhat reasonable testcase used to show the performance improvement - a repeated stat of a 33 byte filename that doesn't exist: #include <sys/types.h> #include <sys/stat.h> #include <unistd.h> #define ITERATIONS 10000000 #define PATH "123456781234567812345678123456781" int main(void) { unsigned long i; struct stat buf; for (i = 0; i < ITERATIONS; i++) stat(PATH, &buf); return 0; } runs 27% faster on POWER8. Signed-off-by: -
Anton Blanchard authored
Use cmpb which compares each byte in two 64 bit values and for each matching byte places 0xff in the target and 0x00 otherwise. A simple hash_name microbenchmark: http://ozlabs.org/~anton/junkcode/hash_name_bench.c shows this version to be 10-20% faster than running the x86 version on POWER8, depending on the length. Signed-off-by:
-
Michael Ellerman authored
It is a rarely exercised case, so we want to have a test to ensure it works as required. Signed-off-by:
-
Anton Blanchard authored
Implement a bi-arch and bi-endian version of load_unaligned_zeropad. Since the fallback case is so rare, a userspace test harness was used to test this on ppc64le, ppc64 and ppc32: http://ozlabs.org/~anton/junkcode/test_load_unaligned_zeropad.c It uses mprotect to force a SEGV across a page boundary, and a SEGV handler to lookup the exception tables and run the fixup routine. It also compares the result against a normal load. Signed-off-by:
-
- 25 Sep, 2014 16 commits
-
-
Joe Perches authored
No need for 3 functions when a single one will do. Modify the function declaring macros to call the single function. Reduces object code size a little: $ size arch/powerpc/platforms/powernv/pci-ioda.o* text data bss dec hex filename 22303 1073 6680 30056 7568 arch/powerpc/platforms/powernv/pci-ioda.o.new 22840 1121 6776 30737 7811 arch/powerpc/platforms/powernv/pci-ioda.o.old Signed-off-by:
Joe Perches <joe@perches.com> Signed-off-by:
-
Joe Perches authored
The return value is unnecessary and unused, so make the functions void instead of int. Signed-off-by:
-
Wei Yang authored
When doing vfio passthrough a VF, the kernel will crash with following message: [ 442.656459] Unable to handle kernel paging request for data at address 0x00000060 [ 442.656593] Faulting instruction address: 0xc000000000038b88 [ 442.656706] Oops: Kernel access of bad area, sig: 11 [#1] [ 442.656798] SMP NR_CPUS=1024 NUMA PowerNV [ 442.656890] Modules linked in: vfio_pci mlx4_core nf_conntrack_netbios_ns nf_conntrack_broadcast ipt_MASQUERADE ip6t_REJECT xt_conntrack bnep bluetooth rfkill ebtable_nat ebtable_broute bridge stp llc ebtable_filter ebtables ip6table_nat nf_conntrack_ipv6 nf_defrag_ipv6 nf_nat_ipv6 ip6table_mangle ip6table_security ip6table_raw ip6table_filter ip6_tables iptable_nat nf_conntrack_ipv4 nf_defrag_ipv4 nf_nat_ipv4 nf_nat nf_conntrack iptable_mangle iptable_security iptable_raw tg3 nfsd be2net nfs_acl ses lockd ptp enclosure pps_core kvm_hv kvm_pr shpchp binfmt_misc kvm sunrpc uinput lpfc scsi_transport_fc ipr scsi_tgt [last unloaded: mlx4_core] [ 442.658152] CPU: 40 PID: 14948 Comm: qemu-system-ppc Not tainted 3.10.42yw-pkvm+ #37 [ 442.658219] task: c000000f7e2a9a00 ti: c000000f6dc3c000 task.ti: c000000f6dc3c000 [ 442.658287] NIP: c000000000038b88 LR: c0000000004435a8 CTR: c000000000455bc0 [ 442.658352] REGS: c000000f6dc3f580 TRAP: 0300 Not tainted (3.10.42yw-pkvm+) [ 442.658419] MSR: 9000000000009032 <SF,HV,EE,ME,IR,DR,RI> CR: 28004882 XER: 20000000 [ 442.658577] CFAR: c00000000000908c DAR: 0000000000000060 DSISR: 40000000 SOFTE: 1 GPR00: c0000000004435a8 c000000f6dc3f800 c0000000012b1c10 c00000000da24000 GPR04: 0000000000000003 0000000000001004 00000000000015b3 000000000000ffff GPR08: c00000000127f5d8 0000000000000000 000000000000ffff 0000000000000000 GPR12: c000000000068078 c00000000fdd6800 000001003c320c80 000001003c3607f0 GPR16: 0000000000000001 00000000105480c8 000000001055aaa8 000001003c31ab18 GPR20: 000001003c10fb40 000001003c360ae8 000000001063bcf0 000000001063bdb0 GPR24: 000001003c15ed70 0000000010548f40 c000001fe5514c88 c000001fe5514cb0 GPR28: c00000000da24000 0000000000000000 c00000000da24000 0000000000000003 [ 442.659471] NIP [c000000000038b88] .pcibios_set_pcie_reset_state+0x28/0x130 [ 442.659530] LR [c0000000004435a8] .pci_set_pcie_reset_state+0x28/0x40 [ 442.659585] Call Trace: [ 442.659610] [c000000f6dc3f800] [00000000000719e0] 0x719e0 (unreliable) [ 442.659677] [c000000f6dc3f880] [c0000000004435a8] .pci_set_pcie_reset_state+0x28/0x40 [ 442.659757] [c000000f6dc3f900] [c000000000455bf8] .reset_fundamental+0x38/0x80 [ 442.659835] [c000000f6dc3f980] [c0000000004562a8] .pci_dev_specific_reset+0xa8/0xf0 [ 442.659913] [c000000f6dc3fa00] [c0000000004448c4] .__pci_dev_reset+0x44/0x430 [ 442.659980] [c000000f6dc3fab0] [c000000000444d5c] .pci_reset_function+0x7c/0xc0 [ 442.660059] [c000000f6dc3fb30] [d00000001c141ab8] .vfio_pci_open+0xe8/0x2b0 [vfio_pci] [ 442.660139] [c000000f6dc3fbd0] [c000000000586c30] .vfio_group_fops_unl_ioctl+0x3a0/0x630 [ 442.660219] [c000000f6dc3fc90] [c000000000255fbc] .do_vfs_ioctl+0x4ec/0x7c0 [ 442.660286] [c000000f6dc3fd80] [c000000000256364] .SyS_ioctl+0xd4/0xf0 [ 442.660354] [c000000f6dc3fe30] [c000000000009e54] syscall_exit+0x0/0x98 [ 442.660420] Instruction dump: [ 442.660454] 4bfffce9 4bfffee4 7c0802a6 fbc1fff0 fbe1fff8 f8010010 f821ff81 7c7e1b78 [ 442.660566] 7c9f2378 60000000 60000000 e93e02c8 <e8690060> 2fa30000 41de00c4 2b9f0002 [ 442.660679] ---[ end trace a64ac9546bcf0328 ]--- [ 442.660724] The reason is current VF is not EEH enabled. This patch introduces a macro to convert eeh_dev to eeh_pe. By doing so, it will prevent converting with NULL pointer. Signed-off-by:
Wei Yang <weiyang@linux.vnet.ibm.com> Acked-by:
-
Michael Ellerman authored
We can unindent the bulk of htab_dt_scan_page_sizes() by returning early if the property is not found. That is nice in and of itself, but also has the advantage of making it clear that we always return success once we have found the ibm,segment-page-sizes property. Signed-off-by: -
Michael Ellerman authored
"Helps debug funky firmware issues". After: Starting Linux PPC64 #108 SMP Wed Aug 6 19:04:51 EST 2014 ----------------------------------------------------- ppc64_pft_size = 0x1a phys_mem_size = 0x200000000 cpu_features = 0x17fc7a6c18500249 possible = 0x1fffffff18700649 always = 0x0000000000000040 cpu_user_features = 0xdc0065c2 0xee000000 mmu_features = 0x5a000001 firmware_features = 0x00000001405a440b htab_hash_mask = 0x7ffff ----------------------------------------------------- Signed-off-by:Benjamin Herrenschmidt <benh@kernel.crashing.org> Signed-off-by:
-
Michael Ellerman authored
At boot we display a bunch of low level settings which can be useful to know, and can help to spot bugs when things are fundamentally misconfigured. At the moment they are very widely spaced, so that we can accommodate the line: ppc64_caches.dcache_line_size = 0xYY But we only print that line when the cache line size is not 128, ie. almost never, so it just makes the display look odd usually. The ppc64_caches prefix is redundant so remove it, which means we can align things a bit closer for the common case. While we're there replace the last use of camelCase (physicalMemorySize), and use phys_mem_size. Before: Starting Linux PPC64 #104 SMP Wed Aug 6 18:41:34 EST 2014 ----------------------------------------------------- ppc64_pft_size = 0x1a physicalMemorySize = 0x200000000 ppc64_caches.dcache_line_size = 0xf0 ppc64_caches.icache_line_size = 0xf0 htab_address = 0xdeadbeef htab_hash_mask = 0x7ffff physical_start = 0xf000bar ----------------------------------------------------- After: Starting Linux PPC64 #103 SMP Wed Aug 6 18:38:04 EST 2014 ----------------------------------------------------- ppc64_pft_size = 0x1a phys_mem_size = 0x200000000 dcache_line_size = 0xf0 icache_line_size = 0xf0 htab_address = 0xdeadbeef htab_hash_mask = 0x7ffff physical_start = 0xf000bar ----------------------------------------------------- This patch is final, no bike shedding ;) Signed-off-by: -
Pranith Kumar authored
We are enabling USB unconditionally which results in following build failure drivers/built-in.o: In function `tb_drom_read': (.text+0x1b62b70): undefined reference to `usb_speed_string' make: *** [vmlinux] Error Enable USB only if USB_SUPPORT is set to avoid such failures Signed-off-by:
Pranith Kumar <bobby.prani@gmail.com> Acked-by:
Alistair Popple <alistair@popple.id.au> Signed-off-by:
-
Pranith Kumar authored
Fix the following build failure drivers/built-in.o: In function `nhi_init': nhi.c:(.init.text+0x63390): undefined reference to `ehci_init_driver' by adding a dependency on USB_EHCI_HCD which supplies the ehci_init_driver(). Also we need to depend on USB_OHCI_HCD similarly Signed-off-by:
-
Li Zhong authored
this patches changes some error handling logics in numa_setup_cpu(), when cpu node is not found, so: if the cpu is possible, but not present, -1 is kept in numa_cpu_lookup_table, so later, if the cpu is added, we could set correct numa information for it. if the cpu is present, then we set the first online node to numa_cpu_lookup_table instead of 0 ( in case 0 might not be an online node? ) Cc: Nishanth Aravamudan <nacc@linux.vnet.ibm.com> Cc: Nathan Fontenot <nfont@linux.vnet.ibm.com> Signed-off-by:
Li Zhong <zhong@linux.vnet.ibm.com> Acked-by:
Nishanth Aravamudan <nacc@linux.vnet.ibm.com> Signed-off-by:
-
Li Zhong authored
As Nish suggested, it makes more sense to init the numa node informatiion for present cpus at boottime, which could also avoid WARN_ON(1) in numa_setup_cpu(). With this change, we also need to change the smp_prepare_cpus() to set up numa information only on present cpus. For those possible, but not present cpus, their numa information will be set up after they are started, as the original code did before commit 2fabf084. Cc: Nishanth Aravamudan <nacc@linux.vnet.ibm.com> Cc: Nathan Fontenot <nfont@linux.vnet.ibm.com> Signed-off-by:
Cyril Bur <cyril.bur@au1.ibm.com> Signed-off-by:
-
Li Zhong authored
With commit 2fabf084 ("powerpc: reorder per-cpu NUMA information's initialization"), during boottime, cpu_numa_callback() is called earlier(before their online) for each cpu, and verify_cpu_node_mapping() uses cpu_to_node() to check whether siblings are in the same node. It skips the checking for siblings that are not online yet. So the only check done here is for the bootcpu, which is online at that time. But the per-cpu numa_node cpu_to_node() uses hasn't been set up yet (which will be set up in smp_prepare_cpus()). So I saw something like following reported: [ 0.000000] CPU thread siblings 1/2/3 and 0 don't belong to the same node! As we don't actually do the checking during this early stage, so maybe we could directly call numa_setup_cpu() in do_init_bootmem(). Cc: Nishanth Aravamudan <nacc@linux.vnet.ibm.com> Cc: Nathan Fontenot <nfont@linux.vnet.ibm.com> Signed-off-by:
-
Paul Mackerras authored
The size field of the op.type word is now the total number of bytes to be loaded or stored. Signed-off-by:
Paul Mackerras <paulus@samba.org> Signed-off-by:
-
Paul Mackerras authored
This extends the instruction emulation done by analyse_instr() and emulate_step() to handle a few more instructions that are found in the kernel. Signed-off-by:
-
Paul Mackerras authored
This splits out the instruction analysis part of emulate_step() into a separate analyse_instr() function, which decodes the instruction, but doesn't execute any load or store instructions. It does execute integer instructions and branches which can be executed purely by updating register values in the pt_regs struct. For other instructions, it returns the instruction type and other details in a new instruction_op struct. emulate_step() then uses that information to execute loads, stores, cache operations, mfmsr, mtmsr[d], and (on 64-bit) sc instructions. The reason for doing this is so that the KVM code can use it instead of having its own separate instruction emulation code. Possibly the alignment interrupt handler could also use this. Signed-off-by:
-
Michael Ellerman authored
In commit e6a6928c "of/fdt: Convert FDT functions to use libfdt", the kernel stopped supporting old flat device tree formats. The minimum supported version is now 0x10. There was a checking function added, early_init_dt_verify(), but it's not called on powerpc. The result is, if you boot with an old flat device tree, the kernel will fail to parse it correctly, think you have no memory etc. and hilarity ensues. We can't really fix it, but we can at least catch the fact that the device tree is in an unsupported format and panic(). We can't call BUG(), it's too early. Signed-off-by:
-
Paul Mackerras authored
On PowerNV platforms, when a CPU is offline, we put it into nap mode. It's possible that the CPU wakes up from nap mode while it is still offline due to a stray IPI. A misdirected device interrupt could also potentially cause it to wake up. In that circumstance, we need to clear the interrupt so that the CPU can go back to nap mode. In the past the clearing of the interrupt was accomplished by briefly enabling interrupts and allowing the normal interrupt handling code (do_IRQ() etc.) to handle the interrupt. This has the problem that this code calls irq_enter() and irq_exit(), which call functions such as account_system_vtime() which use RCU internally. Use of RCU is not permitted on offline CPUs and will trigger errors if RCU checking is enabled. To avoid calling into any generic code which might use RCU, we adopt a different method of clearing interrupts on offline CPUs. Since we are on the PowerNV platform, we know that the system interrupt controller is a XICS being driven directly (i.e. not via hcalls) by the kernel. Hence this adds a new icp_native_flush_interrupt() function to the native-mode XICS driver and arranges to call that when an offline CPU is woken from nap. This new function reads the interrupt from the XICS. If it is an IPI, it clears the IPI; if it is a device interrupt, it prints a warning and disables the source. Then it does the end-of-interrupt processing for the interrupt. The other thing that briefly enabling interrupts did was to check and clear the irq_happened flag in this CPU's PACA. Therefore, after flushing the interrupt from the XICS, we also clear all bits except the PACA_IRQ_HARD_DIS (interrupts are hard disabled) bit from the irq_happened flag. The PACA_IRQ_HARD_DIS flag is set by power7_nap() and is left set to indicate that interrupts are hard disabled. This means we then have to ignore that flag in power7_nap(), which is reasonable since it doesn't indicate that any interrupt event needs servicing. Signed-off-by:
-
