21 May, 2010
24 commits
-
This is started as swsusp_32.S modifications, but the amount of #ifdefs
made the whole file horribly unreadable, so let's put the support into
its own separate file.The code should be relatively easy to modify to support 44x BookEs as
well, but since I don't have any 44x to test, let's confine the code to
FSL BookE. (The only FSL-specific part so far is 'flush_dcache_L1'.)Signed-off-by: Anton Vorontsov
Acked-by: Scott Wood
Signed-off-by: Kumar Gala -
Most of the MSCR bit assigments are different in e500mc versus
e500, and they are now write-one-to-clear.Some e500mc machine check conditions are made recoverable (as long as
they aren't stuck on), most notably L1 instruction cache parity errors.Signed-off-by: Scott Wood
Signed-off-by: Kumar Gala -
'protect4gb' boot parameter was introduced to avoid allocating dma
space acrossing 4GB boundary in 2007 (the commit
569975591c5530fdc9c7a3c45122e5e46f075a74).In 2008, the IOMMU was fixed to use the boundary_mask parameter per
device properly. So 'protect4gb' workaround was removed (the
383af9525bb27f927511874f6306247ec13f1c28). But somehow I messed the
'protect4gb' boot parameter that was used to enable the
workaround.Signed-off-by: FUJITA Tomonori
Signed-off-by: Benjamin Herrenschmidt -
The e1000e device is becoming more common these days, so let's just
build it in for pseries & ppc64_defconfig.Signed-off-by: Michael Neuling
Signed-off-by: Benjamin Herrenschmidt -
At the moment only the RAS code uses event-sources interrupts (for EPOW
events and internal errors) so request_ras_irqs() (which actually requests
the event-sources interrupts) is found in ras.c and is static.We want to be able to use event-sources interrupts in other pseries code,
so let's rename request_ras_irqs() to request_event_sources_irqs() and
move it to event_sources.c.This will be used in an upcoming patch that adds support for IO Event
interrupts that come through as event sources.Signed-off-by: Mark Nelson
Signed-off-by: Benjamin Herrenschmidt -
I've been told that the architected way to determine we are in form 1
affinity mode is by reading the ibm,architecture-vec-5 property which
mirrors the layout of the fifth vector of the ibm,client-architecture
structure.Eventually we may want to parse the ibm,architecture-vec-5 and create
FW_FEATURE_* bits.Signed-off-by: Anton Blanchard
Signed-off-by: Benjamin Herrenschmidt -
I noticed /proc/sys/vm/zone_reclaim_mode was 0 on a ppc64 NUMA box. It gets
enabled via this:/*
* If another node is sufficiently far away then it is better
* to reclaim pages in a zone before going off node.
*/
if (distance > RECLAIM_DISTANCE)
zone_reclaim_mode = 1;Since we use the default value of 20 for REMOTE_DISTANCE and 20 for
RECLAIM_DISTANCE it never kicks in.The local to remote bandwidth ratios can be quite large on System p
machines so it makes sense for us to reclaim clean pagecache locally before
going off node.The patch below sets a smaller value for RECLAIM_DISTANCE and thus enables
zone reclaim.Signed-off-by: Anton Blanchard
Signed-off-by: Benjamin Herrenschmidt -
Right now if we want to busy loop and not give up any time to the hypervisor
we put a very large value into smt_snooze_delay. This is sometimes useful
when running a single partition and you want to avoid any latencies due
to the hypervisor or CPU power state transitions. While this works, it's a bit
ugly - how big a number is enough now we have NO_HZ and can be idle for a very
long time.The patch below makes smt_snooze_delay signed, and a negative value means loop
forever:echo -1 > /sys/devices/system/cpu/cpu0/smt_snooze_delay
This change shouldn't affect the existing userspace tools (eg ppc64_cpu), but
I'm cc-ing Nathan just to be sure.Signed-off-by: Anton Blanchard
Signed-off-by: Benjamin Herrenschmidt -
I'm not sure why we have code for parsing an ibm,smt-snooze-delay OF
property. Since we have a smt-snooze-delay= boot option and we can
also set it at runtime via sysfs, it should be safe to get rid of
this code.Signed-off-by: Anton Blanchard
Signed-off-by: Benjamin Herrenschmidt -
When we are crashing, the crashing/primary CPU IPIs the secondaries to
turn off IRQs, go into real mode and wait in kexec_wait. While this
is happening, the primary tears down all the MMU maps. Unfortunately
the primary doesn't check to make sure the secondaries have entered
real mode before doing this.On PHYP machines, the secondaries can take a long time shutting down
the IRQ controller as RTAS calls are need. These RTAS calls need to
be serialised which resilts in the secondaries contending in
lock_rtas() and hence taking a long time to shut down.We've hit this on large POWER7 machines, where some secondaries are
still waiting in lock_rtas(), when the primary tears down the HPTEs.This patch makes sure all secondaries are in real mode before the
primary tears down the MMU. It uses the new kexec_state entry in the
paca. It times out if the secondaries don't reach real mode after
10sec.Signed-off-by: Michael Neuling
Signed-off-by: Benjamin Herrenschmidt -
In kexec_prepare_cpus, the primary CPU IPIs the secondary CPUs to
kexec_smp_down(). kexec_smp_down() calls kexec_smp_wait() which sets
the hw_cpu_id() to -1. The primary does this while leaving IRQs on
which means the primary can take a timer interrupt which can lead to
the IPIing one of the secondary CPUs (say, for a scheduler re-balance)
but since the secondary CPU now has a hw_cpu_id = -1, we IPI CPU
-1... Kaboom!We are hitting this case regularly on POWER7 machines.
There is also a second race, where the primary will tear down the MMU
mappings before knowing the secondaries have entered real mode.Also, the secondaries are clearing out any pending IPIs before
guaranteeing that no more will be received.This changes kexec_prepare_cpus() so that we turn off IRQs in the
primary CPU much earlier. It adds a paca flag to say that the
secondaries have entered the kexec_smp_down() IPI and turned off IRQs,
rather than overloading hw_cpu_id with -1. This new paca flag is
again used to in indicate when the secondaries has entered real mode.It also ensures that all CPUs have their IRQs off before we clear out
any pending IPI requests (in kexec_cpu_down()) to ensure there are no
trailing IPIs left unacknowledged.Signed-off-by: Michael Neuling
Signed-off-by: Benjamin Herrenschmidt -
Currently for kexec the PTE tear down on 1TB segment systems normally
requires 3 hcalls for each PTE removal. On a machine with 32GB of
memory it can take around a minute to remove all the PTEs.This optimises the path so that we only remove PTEs that are valid.
It also uses the read 4 PTEs at once HCALL. For the common case where
a PTEs is invalid in a 1TB segment, this turns the 3 HCALLs per PTE
down to 1 HCALL per 4 PTEs.This gives an > 10x speedup in kexec times on PHYP, taking a 32GB
machine from around 1 minute down to a few seconds.Signed-off-by: Michael Neuling
Signed-off-by: Benjamin Herrenschmidt -
This adds plpar_pte_read_4_raw() which can be used read 4 PTEs from
PHYP at a time, while in real mode.It also creates a new hcall9 which can be used in real mode. It's the
same as plpar_hcall9 but minus the tracing hcall statistics which may
require variables outside the RMO.Signed-off-by: Michael Neuling
Signed-off-by: Benjamin Herrenschmidt -
Author: Milton Miller
On large machines we are running out of room below 256MB. In some cases we
only need to ensure the allocation is in the first segment, which may be
256MB or 1TB.Add slb0_limit and use it to specify the upper limit for the irqstack and
emergency stacks.On a large ppc64 box, this fixes a panic at boot when the crashkernel=
option is specified (previously we would run out of memory below 256MB).Signed-off-by: Milton Miller
Signed-off-by: Anton Blanchard
Signed-off-by: Benjamin Herrenschmidt -
I saw this in a kdump kernel:
IOMMU table initialized, virtual merging enabled
Interrupt 155954 (real) is invalid, disabling it.
Interrupt 155953 (real) is invalid, disabling it.ie we took some spurious interrupts. default_machine_crash_shutdown tries
to disable all interrupt sources but uses chip->disable which maps to
the default action of:static void default_disable(unsigned int irq)
{
}If we use chip->shutdown, then we actually mask the IRQ:
static void default_shutdown(unsigned int irq)
{
struct irq_desc *desc = irq_to_desc(irq);desc->chip->mask(irq);
desc->status |= IRQ_MASKED;
}Not sure why we don't implement a ->disable action for xics.c, or why
default_disable doesn't mask the interrupt.Signed-off-by: Anton Blanchard
Signed-off-by: Benjamin Herrenschmidt -
We wrap the crash_shutdown_handles[] calls with longjmp/setjmp, so if any
of them fault we can recover. The problem is we add a hook to the debugger
fault handler hook which calls longjmp unconditionally.This first part of kdump is run before we marshall the other CPUs, so there
is a very good chance some CPU on the box is going to page fault. And when
it does it hits the longjmp code and assumes the context of the oopsing CPU.
The machine gets very confused when it has 10 CPUs all with the same stack,
all thinking they have the same CPU id. I get even more confused trying
to debug it.The patch below adds crash_shutdown_cpu and uses it to specify which cpu is
in the protected region. Since it can only be -1 or the oopsing CPU, we don't
need to use memory barriers since it is only valid on the local CPU - no other
CPU will ever see a value that matches it's local CPU id.Eventually we should switch the order and marshall all CPUs before doing the
crash_shutdown_handles[] calls, but that is a bigger fix.Signed-off-by: Anton Blanchard
Signed-off-by: Benjamin Herrenschmidt -
Signed-off-by: Maxim Uvarov
Signed-off-by: Benjamin Herrenschmidt -
If we take an EEH error early enough, we oops:
Call Trace:
[c000000010483770] [c000000000013ee4] .show_stack+0xd8/0x218 (unreliable)
[c000000010483850] [c000000000658940] .dump_stack+0x28/0x3c
[c0000000104838d0] [c000000000057a68] .eeh_dn_check_failure+0x2b8/0x304
[c000000010483990] [c0000000000259c8] .rtas_read_config+0x120/0x168
[c000000010483a40] [c000000000025af4] .rtas_pci_read_config+0xe4/0x124
[c000000010483af0] [c00000000037af18] .pci_bus_read_config_word+0xac/0x104
[c000000010483bc0] [c0000000008fec98] .pcibios_allocate_resources+0x7c/0x220
[c000000010483c90] [c0000000008feed8] .pcibios_resource_survey+0x9c/0x418
[c000000010483d80] [c0000000008fea10] .pcibios_init+0xbc/0xf4
[c000000010483e20] [c000000000009844] .do_one_initcall+0x98/0x1d8
[c000000010483ed0] [c0000000008f0560] .kernel_init+0x228/0x2e8
[c000000010483f90] [c000000000031a08] .kernel_thread+0x54/0x70
EEH: Detected PCI bus error on device
EEH: This PCI device has failed 1 times in the last hour:
EEH: location=U78A5.001.WIH8464-P1 driver= pci addr=0001:00:01.0
EEH: of node=/pci@800000020000209/usb@1
EEH: PCI device/vendor: 00351033
EEH: PCI cmd/status register: 12100146Unable to handle kernel paging request for data at address 0x00000468
Oops: Kernel access of bad area, sig: 11 [#1]
....
NIP [c000000000057610] .rtas_set_slot_reset+0x38/0x10c
LR [c000000000058724] .eeh_reset_device+0x5c/0x124
Call Trace:
[c00000000bc6bd00] [c00000000005a0e0] .pcibios_remove_pci_devices+0x7c/0xb0 (unreliable)
[c00000000bc6bd90] [c000000000058724] .eeh_reset_device+0x5c/0x124
[c00000000bc6be40] [c0000000000589c0] .handle_eeh_events+0x1d4/0x39c
[c00000000bc6bf00] [c000000000059124] .eeh_event_handler+0xf0/0x188
[c00000000bc6bf90] [c000000000031a08] .kernel_thread+0x54/0x70We called rtas_set_slot_reset while scanning the bus and before the pci_dn
to pcidev mapping has been created. Since we only need the pcidev to work
out the type of reset and that only gets set after the module for the
device loads, lets just do a hot reset if the pcidev is NULL.Signed-off-by: Anton Blanchard
Acked-by: Linas Vepstas
Signed-off-by: Benjamin Herrenschmidt -
We ran into an issue where it looks like we're not properly ignoring a
pci device with a non-good status property when we walk the device tree
and instanciate the Linux side PCI devices.However, the EEH init code does look for the property and disables EEH
on these devices. This leaves us in an inconsistent where we are poking
at a supposedly bad piece of hardware and RTAS will block our config
cycles because EEH isn't enabled anyway.Signed-of-by: Sonny Rao
Signed-off-by: Benjamin Herrenschmidt
-
Switch to use the generic power management helpers.
Signed-off-by: Brian King
Signed-off-by: Benjamin Herrenschmidt -
Subrata Modak reported that building a CONFIG_RELOCATABLE kernel with
CONFIG_ISERIES enabled gives the following warnings:WARNING: 4 bad relocations
c00000000007216e R_PPC64_ADDR16_HIGHEST __ksymtab+0x00000000009dcec8
c000000000072172 R_PPC64_ADDR16_HIGHER __ksymtab+0x00000000009dcec8
c00000000007217a R_PPC64_ADDR16_HI __ksymtab+0x00000000009dcec8
c00000000007217e R_PPC64_ADDR16_LO __ksymtab+0x00000000009dcec8The reason is that decrementer_iSeries_masked is using
LOAD_REG_IMMEDIATE to get the address of a kernel symbol, which
creates relocations that aren't handled by the kernel relocator code.Instead of reading the tb_ticks_per_jiffy variable, we can just set
the decrementer to its maximum value (0x7fffffff) and that will work
just as well. In fact timer_interrupt sets the decrementer to that
value initially anyway, and we are sure to get into timer_interrupt
once interrupts are reenabled because we store 1 to the decrementer
interrupt flag in the lppaca (LPPACADECRINT(r12) here).Reported-by: Subrata Modak
Signed-off-by: Paul Mackerras
Signed-off-by: Benjamin Herrenschmidt -
Configuring a powerpc 32 bit kernel for both SMP and SUSPEND turns on
CPU_HOTPLUG to enable disable_nonboot_cpus to be called by the common
suspend code. Previously the definition of cpu_die for ppc32 was in
the powermac platform code, causing it to be undefined if that platform
as not selected.arch/powerpc/kernel/built-in.o: In function 'cpu_idle':
arch/powerpc/kernel/idle.c:98: undefined reference to 'cpu_die'Move the code from setup_64 to smp.c and rename the power mac
versions to their specific names.Note that this does not setup the cpu_die pointers in either
smp_ops (request a given cpu die) or ppc_md (make this cpu die),
for other platforms but there are generic versions in smp.c.Reported-by: Matt Sealey
Reported-by: Kumar Gala
Signed-off-by: Milton Miller
Signed-off-by: Anton Vorontsov
Signed-off-by: Benjamin Herrenschmidt -
The powerpc strncmp implementation does not correctly handle a zero
length, despite the claim in 0119536cd314ef95553604208c25bc35581f7f0a
(Add hand-coded assembly strcmp).Additionally, all the length arguments are size_t, not int, so use
PPC_LCMPI and eq instead of cmpwi and le throughout.Signed-off-by: Andreas Schwab
Acked-by: Paul Mackerras
Signed-off-by: Benjamin Herrenschmidt -
There appear to be Pegasos systems which have the rtas-event-scan
RTAS tokens, but on which the event scan always fails. They also
have an event-scan-rate property containing 0, which means call
event scan 0 times per minute.So interpret a scan rate of 0 to mean don't scan at all. This fixes
the problem on the Pegasos machines and makes sense as well.Signed-off-by: Michael Ellerman
Signed-off-by: Benjamin Herrenschmidt
17 May, 2010
8 commits
-
When we build with ftrace enabled its possible that loadcam_entry would
have used the stack pointer (even though the code doesn't need it). We
call loadcam_entry in __secondary_start before the stack is setup. To
ensure that loadcam_entry doesn't use the stack pointer the easiest
solution is to just have it in asm code.Signed-off-by: Kumar Gala
-
In CONFIG_PTE_64BIT the PTE format has unique permission bits for user
and supervisor execute. However on !CONFIG_PTE_64BIT we overload the
supervisor bit to imply user execute with _PAGE_USER set. This allows
us to use the same permission check mask for user or supervisor code on
!CONFIG_PTE_64BIT.However, on CONFIG_PTE_64BIT we map _PAGE_EXEC to _PAGE_BAP_UX so we
need a different permission mask based on the fault coming from a kernel
address or user space.Without unique permission masks we see issues like the following with
modules:Unable to handle kernel paging request for instruction fetch
Faulting instruction address: 0xf938d040
Oops: Kernel access of bad area, sig: 11 [#1]Signed-off-by: Li Yang
Signed-off-by: Jin Qing
Signed-off-by: Kumar Gala -
A future version of the MPC8610 HPCD's ASoC DMA driver will probe on individual
DMA channel nodes, so the DMA controller nodes' compatible string must be listed
in mpc8610_ids[] for the probe to work.Also remove the "gianfar" compatible from mpc8610_ids[], since there is no
gianfar (or any other networking device) on the 8610.Signed-off-by: Timur Tabi
Signed-off-by: Kumar Gala -
There are two front-panel LEDs on MPC837xRDB and MPC8315RDB boards: PWR
and HDD. After adding appropriate nodes we can program these LEDs from
kernel and user space.Signed-off-by: Anton Vorontsov
Signed-off-by: Kumar Gala -
Since USB2 is shared with local bus, either local bus or USB2
should be disabled. By default U-Boot enables local bus, so we
have to disable USB2, otherwise kernel hangs:ehci_hcd: USB 2.0 'Enhanced' Host Controller (EHCI) Driver
fsl-ehci fsl-ehci.0: Freescale On-Chip EHCI Host Controller
fsl-ehci fsl-ehci.0: new USB bus registered, assigned bus number 1
fsl-ehci fsl-ehci.0: irq 28, io base 0xffe22000
fsl-ehci fsl-ehci.0: USB 2.0 started, EHCI 1.00
hub 1-0:1.0: USB hub found
hub 1-0:1.0: 1 port detected
fsl-ehci fsl-ehci.1: Freescale On-Chip EHCI Host Controller
fsl-ehci fsl-ehci.1: new USB bus registered, assigned bus number 2
Note that U-Boot doesn't clear 'status' property when it enables
USB2, so we have to comment out the whole node.To enable USB2, one can issue
'setenv hwconfig usb2:dr_mode=' command at the
U-Boot prompt.Signed-off-by: Anton Vorontsov
Signed-off-by: Kumar Gala -
This patch adds support for eTSEC 2.0 as found in P1020.
The changes include introduction of the group nodes for
the etsec nodes.Signed-off-by: Sandeep Gopalpet
Signed-off-by: Anton Vorontsov
Signed-off-by: Kumar Gala -
Technically, whilst SEC v3.3 h/w honours the tls_ssl_stream descriptor
type, it lacks the ARC4 algorithm execution unit required to be able
to execute anything meaningful with it. Change the node to agree with
the documentation that declares that the sec3.3 really doesn't have such
a descriptor type.Reported-by: Haiying Wang
Signed-off-by: Kim Phillips
Signed-off-by: Kumar Gala -
Signed-off-by: Peter Korsgaard
Acked-by: Anton Vorontsov
Signed-off-by: Kumar Gala
07 May, 2010
1 commit
06 May, 2010
7 commits
-
Enable the DEBUG_PER_CPU_MAPS option so we can look for problems with
cpumasks .Signed-off-by: Anton Blanchard
Signed-off-by: Benjamin Herrenschmidt -
Convert to the new cpumask API.
irq_choose_cpu can be simplified by using cpumask_next and cpumask_first.
smp_mpic_message_pass was doing open coded cpumask manipulation and passing an
int for a cpumask into mpic_send_ipi. Since mpic_send_ipi is only used
locally, make it static and convert it to take a cpumask. This allows us
to clean up the mess in smp_mpic_message_pass.Signed-off-by: Anton Blanchard
Signed-off-by: Benjamin Herrenschmidt -
Since the *_map cpumask variants are deprecated, change the comments to
instead refer to *_mask.Signed-off-by: Anton Blanchard
Signed-off-by: Benjamin Herrenschmidt -
Convert NUMA code to new cpumask API. We shift the node to cpumask
setup code until after we complete bootmem allocation so we can
dynamically allocate the cpumasks.Signed-off-by: Anton Blanchard
Signed-off-by: Benjamin Herrenschmidt -
Convert hotplug-cpu code to new cpumask API.
Signed-off-by: Anton Blanchard
Signed-off-by: Benjamin Herrenschmidt -
Dynamically allocate cpu_sibling_map and cpu_core_map cpumasks.
We don't need to set_cpu_online() the boot cpu in smp_prepare_boot_cpu,
init/main.c does it for us.We also postpone setting of the boot cpu in cpu_sibling_map and cpu_core_map
until when the memory allocator is available (smp_prepare_cpus), similar
to x86.Signed-off-by: Anton Blanchard
Signed-off-by: Benjamin Herrenschmidt -
Use new cpumask API in /proc/cpuinfo code.
Signed-off-by: Anton Blanchard
Signed-off-by: Benjamin Herrenschmidt