- 19 May, 2011 30 commits
-
-
Milton Miller authored
I have no idea if the beat hypervisor supports multiple cpus in a partition, but the code has not been touched since these stubs were added in February of 2007 except to move them in April of 2008. These are stubs: start_cpu always returns fail (which is dropped), the message passing and reciving are empty functions, and the top of file comment says "Incomplete". Signed-off-by:
Milton Miller <miltonm@bga.com> Signed-off-by:
Benjamin Herrenschmidt <benh@kernel.crashing.org>
-
Milton Miller authored
Replace all remaining callers of alloc_maybe_bootmem with zalloc_maybe_bootmem. The callsite in pci_dn is followed with a memset to clear the memory, and not zeroing at the other callsites in the celleb fake pci code could lead to following uninitialized memory as pointers or even freeing said pointers on error paths. Signed-off-by:
-
Milton Miller authored
Its unused, and of the three declarations, one is duplicated in pmac.h, the second is static and the third is renamed and static. Signed-off-by:
-
Milton Miller authored
Now that MSG_ALL and MSG_ALL_BUT_SELF have been eliminated, smp_mpic_mesage_pass no longer needs to lookup the cpumask just to have mpic_send_ipi extract part of it and recode it in a NR_CPUS loop by mpic_physmask. Signed-off-by:
-
Milton Miller authored
Now that smp_ops->smp_message_pass is always called with an (online) cpu number for the target remove the checks for MSG_ALL and MSG_ALL_BUT_SELF. Signed-off-by:
-
Milton Miller authored
The only user of MSG_ALL_BUT_SELF in the whole kernel tree is powerpc, and it only uses it to start the debugger. Both debuggers always call smp_send_debugger_break with MSG_ALL_BUT_SELF, and only mpic can do anything more optimal than a loop over all online cpus, but all message passing implementations have to code for this special delivery target. Convert smp_send_debugger_break to take void and loop calling the smp_ops message_pass function for each of the other cpus in the online cpumask. Use raw_smp_processor_id() because we are either entering the debugger or trying to start kdump and the additional warning it not useful were it to trigger. Signed-off-by:
-
Milton Miller authored
mpic_set_affinity is allocating and freeing a cpumask var even though it was breaking the cpumask abstraction when passing the mask to mpic_physmask. It also didn't have any check for allocatin failure. Break the cpumask abstraction earlier and use simple bitwise and of the bits from the mask with the bits of cpu_online_mask. Signed-off-by:
-
Milton Miller authored
mpic_physmask was looping NR_CPUS times over a mask that was passed as a u32. Since mpic is architecturaly limited to 32 physical cpus, clamp the logical cpus to 32 when compiling (we could also clamp at runtime to nr_cpu_ids). Signed-off-by:
-
Milton Miller authored
c1854e00 (powerpc: Set nr_cpu_ids early and use it to free PACAs) copied the formerly static setup_nr_cpu_ids from init/main.c but 34db18a0 (smp: move smp setup functions to kernel/smp.c) moved it to kernel/smp.c with a declaration in include/linux/smp.h, so we can call it instead of replicating it. Signed-off-by:
-
Milton Miller authored
Now that we never set a cpu above nr_cpu_ids possible we can limit our initial paca allocation to nr_cpu_ids. We can then clamp the number of cpus in platforms/iseries/setup.c. Signed-off-by:
-
Milton Miller authored
We should not set cpus above nr_cpu_ids to possible. While we will trigger a warning with CONFIG_CPUMASK_DEBUG, even then the mask initializers will set the bits beyond what the iterators check and cause nr_cpu_ids to increase. Respecting nr_cpu_ids during setup will allow us to use it in our initial paca allocation. It can be reduced from NR_CPUS by the existing early param nr_cpus=, which was added in 2b633e3f (smp: Use nr_cpus= to set nr_cpu_ids early). We already call parse_early_parms between finding the command line and allocating the pacas. Signed-off-by:
-
Milton Miller authored
9cb82f2f (Make iSeries spin on __secondary_hold_spinloop, like pSeries) added a load of current_set but this load was repeated later and we don't even have the paca yet. It also checked __secondary_hold_spinloop with a 32 bit compare instead of a 64 bit compare. b6f6b98a (Don't spin on sync instruction at boot time) missed the copy of the startup code in iseries. 1426d5a3 (Dynamically allocate pacas) doesn't allow for pacas to be less than lppacas and recalculated the paca location from the cpu id in r0 every time through the secondary loop. Various revisions over time made the comments on conditional branches confusing with respect to being a hold loop or forward progress Mostly in-order description of the changes: Replicate the few lines of code saved by the ugly scoped ifdef CONFIG_SMP in the secondary loop between yielding on UP and marking time with the hypervisor on SMP. Always compile the iseries_secondary_yield loop and use it if the cpu id is above nr_cpu_ids. Change all forward progress paths to be forward branches to the next numerical label. Assign a label to all loops. Move all sync instructions from the loops to the forward progress path. Wait to load current_set until paca is set to go. Move the iseries_secondary_smp_loop label to cover the whole spin loop. Add HMT_MEDIUM when we make forward progress. Signed-off-by:
-
Milton Miller authored
Starting with 1426d5a3 (powerpc: Dynamically allocate pacas) the space for pacas beyond cpu_possible is freed, but we failed to update the loop in crash.c. Since c1854e00 (powerpc: Set nr_cpu_ids early and use it to free PACAs) the number of pacas allocated is always nr_cpu_ids. Signed-off-by:
-
Milton Miller authored
Starting with 1426d5a3 (powerpc: Dynamically allocate pacas) we free the memory for pacas beyond cpu_possible, but we failed to update the loop the secondary cpus use to find their paca. If the system has running cpu threads for which the kernel did not allocate a paca for they will search the memory that was freed. For instance this could happen when the device tree for a kdump kernel was not updated after a cpu hotplug, or the kernel is running with more cpus than the kernel was configured. Since c1854e00 (powerpc: Set nr_cpu_ids early and use it to free PACAs) we set nr_cpu_ids before telling the cpus to advance, so use that to limit the search. We can't reference nr_cpu_ids without CONFIG_SMP because it is defined as 1 instead of a memory location, but any extra threads should be sent to kexec_wait in that case anyways, so make that explicit and remove the search loop for UP. Note to stable: The fix also requires c1854e00 (powerpc: Set nr_cpu_ids early and use it to free PACAs) to function. Also 9d07bc84 (Properly handshake CPUs going out of boot spin loop) affects the second chunk, specifically the branch target was 3b before and is 4b after that patch, and there was a blank line before the #ifdef CONFIG_SMP that was removed Cc: <stable@kernel.org> # .34.x: c1854e00 powerpc: Set nr_cpu_ids early Cc: <stable@kernel.org> # .34.x Signed-off-by:
-
Milton Miller authored
Commit 1fc711f7 (powerpc/kexec: Fix race in kexec shutdown) moved the write to signal the cpu had exited the kernel from before the transition to real mode in kexec_smp_wait to kexec_wait. Unfornately it missed that kexec_wait is used both by cpus leaving the kernel and by secondary slave cpus that were not allocated a paca for what ever reason -- they could be beyond nr_cpus or not described in the current device tree for whatever reason (for example, kexec-load was not refreshed after a cpu hotplug operation). Cpus coming through that path they will write to paca[NR_CPUS] which is beyond the space allocated for the paca data and overwrite memory not allocated to pacas but very likely still real mode accessable). Move the write back to kexec_smp_wait, which is used only by cpus that found their paca, but after the transition to real mode. Signed-off-by:
-
Anton Blanchard authored
I have a report of an FWNMI with an r3 value that we think is corrupt, but since we don't print r3 we have no idea what was wrong with it. Signed-off-by:
Anton Blanchard <anton@samba.org> Signed-off-by:
-
Nishanth Aravamudan authored
When we swtich to direct dma ops, we set the dma data union to have the dma offset. When we switch back to iommu table ops because of a later dma_set_mask, we need to restore the iommu table pointer. Without this change, crashes have been observed on kexec where (for reasons still being investigated) we fall back to a 32-bit dma mask on a particular device and then panic because the table pointer is not valid. The easiset way to find this value is to call pci_dma_dev_setup_pSeriesLP which will search up the pci tree until it finds the node with the table. Signed-off-by:
Nishanth Aravamudan <nacc@us.ibm.com> Cc: Milton Miller <miltonm@bga.com> Cc: Paul Mackerras <paulus@samba.org> Cc: Anton Blanchard <anton@samba.org> Cc: linuxppc-dev@lists.ozlabs.org Signed-off-by:
-
Anton Blanchard authored
We have a confusing number of ioremap functions. Make things just a bit simpler by merging ioremap_flags and ioremap_prot. Signed-off-by:
-
Anton Blanchard authored
Add ioremap_wc so drivers can request write combining on kernel mappings. Signed-off-by:
-
Anton Blanchard authored
After looking at our system call path, Mary Brown suggested that we should put all mfspr SRR* instructions before any mtspr SRR*. To test this I used a very simple null syscall (actually getppid) testcase at http://ozlabs.org/~anton/junkcode/null_syscall.c I tested with the following changes against the pseries_defconfig: CONFIG_VIRT_CPU_ACCOUNTING=n CONFIG_AUDIT=n to remove the overhead of virtual CPU accounting and syscall auditing. POWER6: baseline: mean = 757.2 cycles sd = 2.108 modified: mean = 759.1 cycles sd = 2.020 POWER7: baseline: mean = 411.4 cycles sd = 0.138 modified: mean = 404.1 cycles sd = 0.109 So we have 1.77% improvement on POWER7 which looks significant. The POWER6 suggest a 0.25% slowdown, but the results are within 1 standard deviation and may be in the noise. Signed-off-by:
-
Anton Blanchard authored
A static branch hint will override dynamic branch prediction on recent POWER CPUs. Since we are about to use more altivec in the kernel remove the static hint in giveup_altivec that assumes a userspace task is using altivec. Signed-off-by:
-
Anton Blanchard authored
To make it easier to add optimised versions of copy_page, remove the 4kB loop for 64kB pages and just do all the work in copy_page. Signed-off-by:
-
Anton Blanchard authored
Enable iSCSI support for a number of cards. We had the base networking devices enabled but forgot to enable iSCSI. Signed-off-by:
-
Anton Blanchard authored
Enable the Qlogic and Emulex 10Gbit adapters. Signed-off-by:
-
Stratos Psomadakis authored
The variable 'old' is set but not used in the wrprotect functions in arch/powerpc/include/asm/pgtable-ppc64.h, which can trigger a compiler warning. Remove the variable, since it's not used anyway. Signed-off-by:
Stratos Psomadakis <psomas@ece.ntua.gr> Signed-off-by:
-
Nishanth Aravamudan authored
Future releases of fimrware will enforce a requirement that DTL buffers do not cross a 4k boundary. Commit 127493d5 satisfies this requirement for CONFIG_VIRT_CPU_ACCOUNTING=y kernels, but if !CONFIG_VIRT_CPU_ACCOUNTING && CONFIG_DTL=y, the current code will fail at dtl registration time. Fix this by making the kmem cache from 127493d5 visible outside of setup.c and using the same cache in both dtl.c and setup.c. This requires a bit of reorganization to ensure ordering of the kmem cache and buffer allocations. Note: Since firmware now limits the size of the buffer, I made dtl_buf_entries read-only in debugfs. Tested with upcoming firmware with the 4 combinations of CONFIG_VIRT_CPU_ACCOUNTING and CONFIG_DTL. Signed-off-by:
-
Nishanth Aravamudan authored
When we kexec we look for a particular property added by the first kernel, "linux,direct64-ddr-window-info", per-device where we already have set up dynamic dma windows. The current code, though, wasn't initializing the size of this property and thus when we kexec'd, we would find the property but read uninitialized memory resulting in garbage ddw values for the kexec'd kernel and panics. Fix this by setting the size at enable_ddw() time and ensuring that the size of the found property is valid at dupe_ddw_if_kexec() time. Signed-off-by:
-
Michal Marek authored
Signed-off-by:
Michal Marek <mmarek@suse.cz> Signed-off-by:
-
Justin Mattock authored
The patch below removes an unused config variable found by using a kernel cleanup script. Note: I did try to cross compile these but hit erros while doing so.. (gcc is not setup to cross compile) and am unsure if anymore needs to be done. Please have a look if/when anybody has free time. Signed-off-by:
Justin P. Mattock <justinmattock@gmail.com> Signed-off-by:
-
Michal Marek authored
The timestamps recorded in the .gz files add no value. Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org> Cc: Paul Mackerras <paulus@samba.org> Cc: linuxppc-dev@lists.ozlabs.org Signed-off-by:
-
- 06 May, 2011 7 commits
-
-
Jack Miller authored
Signed-off-by:
Jack Miller <jack@codezen.org> Signed-off-by:
Michael Ellerman <michael@ellerman.id.au> Signed-off-by:
-
David Gibson authored
Add a platform for the Wire Speed Processor, based on the PPC A2. This includes code for the ICS & OPB interrupt controllers, as well as a SCOM backend, and SCOM based cpu bringup. Signed-off-by:
David Gibson <david@gibson.dropbear.id.au> Signed-off-by:
Ian Munsie <imunsie@au1.ibm.com> Signed-off-by:
-
Richard A Lary authored
For adapters which have devices under a PCIe switch/bridge it is informative to display information for both the PCIe switch/bridge and the device on which the bus error was detected. rebased to powerpc-next Signed-off-by:
Richard A Lary <rlary@linux.vnet.ibm.com> Signed-off-by:
-
Benjamin Herrenschmidt authored
slb0_limit() wasn't a very descriptive name. This changes it along with a comment explaining what it's used for, and provides a 64-bit BookE implementation. Signed-off-by: -
Tseng-Hui (Frank) Lin authored
This patch adds support for handling IO Event interrupts which come through at the /event-sources/ibm,io-events device tree node. The interrupts come through ibm,io-events device tree node are generated by the firmware to report IO events. The firmware uses the same interrupt to report multiple types of events for multiple devices. Each device may have its own event handler. This patch implements a plateform interrupt handler that is triggered by the IO event interrupts come through ibm,io-events device tree node, pull in the IO events from RTAS and call device event handlers registered in the notifier list. Device event handlers are expected to use atomic_notifier_chain_register() and atomic_notifier_chain_unregister() to register/unregister their event handler in pseries_ioei_notifier_list list with IO event interrupt. Device event handlers are responsible to identify if the event belongs to the device event handler. The device event handle should return NOTIFY_OK after the event is handled if the event belongs to the device event handler, or NOTIFY_DONE otherwise. Signed-off-by:
Tseng-Hui (Frank) Lin <thlin@us.ibm.com> Signed-off-by:
-
Tseng-Hui (Frank) Lin authored
This patch adds definitions of non-IBM specific v6 extended log definitions to rtas.h. Signed-off-by:
Tseng-Hui (Frank) Lin <tsenglin@us.ibm.com> Signed-off-by:
-
Stephen Rothwell authored
Due to a collision between NO_CONTEXT->MMU_NO_CONTEXT change and Anton's patch. Signed-off-by:
Stephen Rothwell <sfr@canb.auug.org.au> Signed-off-by:
-
- 04 May, 2011 3 commits
-
-
Robert P. J. Day authored
Remove the unnecessary initialization of "dev_t bsr_dev" since it's subsequently used in an "alloc_chrdev_region()" call which uses that variable in an output-only fashion. Signed-off-by:
Robert P. J. Day <rpjday@crashcourse.ca> Signed-off-by:
-
Richard A Lary authored
Fundamental reset is an optional reset type supported only by PCIe adapters. Handle the unexpected case where a non-PCIe device has requested a fundamental reset. Try hot-reset as a fallback to handle this case. Signed-off-by:
-
Richard A Lary authored
For multifunction adapters with a PCI bridge or switch as the device at the Partitionable Endpoint(PE), if one or more devices below PE sets dev->needs_freset, that value will be set for the PE device. In other words, if any device below PE requires a fundamental reset the PE will request a fundamental reset. Signed-off-by:
-
