Skip to content

cloud-kernel
cloud-kernel

openanolis / cloud-kernel
11 个月 前同步成功

通知 150
Star 36
Fork 7
cloud-kernel
cloud-kernel

体验新版 GitCode，发现更多精彩内容 >>

切换分支/标签
  1. 21 5月, 2010 13 次提交
    • M
      powerpc/kexec: Speedup kexec hash PTE tear down · d504bed6
      由 Michael Neuling 提交于 
      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: NMichael Neuling <mikey@neuling.org>
Signed-off-by: NBenjamin Herrenschmidt <benh@kernel.crashing.org>
      d504bed6
    • M
      powerpc/pseries: Add hcall to read 4 ptes at a time in real mode · f90ece28
      由 Michael Neuling 提交于 
      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: NMichael Neuling <mikey@neuling.org>
Signed-off-by: NBenjamin Herrenschmidt <benh@kernel.crashing.org>
      f90ece28
    • A
      powerpc: Use more accurate limit for first segment memory allocations · 095c7965
      由 Anton Blanchard 提交于 
      Author: Milton Miller <miltonm@bga.com>

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: NMilton Miller <miltonm@bga.com>
Signed-off-by: NAnton Blanchard <anton@samba.org>
Signed-off-by: NBenjamin Herrenschmidt <benh@kernel.crashing.org>
      095c7965
    • A
      powerpc/kdump: Use chip->shutdown to disable IRQs · 5d7a8721
      由 Anton Blanchard 提交于 
      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: NAnton Blanchard <anton@samba.org>
Signed-off-by: NBenjamin Herrenschmidt <benh@kernel.crashing.org>
      5d7a8721
    • A
      powerpc/kdump: CPUs assume the context of the oopsing CPU · 06440794
      由 Anton Blanchard 提交于 
      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: NAnton Blanchard <anton@samba.org>
Signed-off-by: NBenjamin Herrenschmidt <benh@kernel.crashing.org>
      06440794
    • M
      powerpc/crashdump: Do not fail on NULL pointer dereferencing · 426b6cb4
      由 Maxim Uvarov 提交于 
      Signed-off-by: NMaxim Uvarov <muvarov@gmail.com>
Signed-off-by: NBenjamin Herrenschmidt <benh@kernel.crashing.org>
      426b6cb4
    • A
      powerpc/eeh: Fix oops when probing in early boot · ce47c1c4
      由 Anton Blanchard 提交于 
      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 <null>
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: 12100146

Unable 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/0x70

We 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: NAnton Blanchard <anton@samba.org>
Acked-by: NLinas Vepstas <linasvepstas@gmail.com>
Signed-off-by: NBenjamin Herrenschmidt <benh@kernel.crashing.org>
      ce47c1c4
    • S
      powerpc/pci: Check devices status property when scanning OF tree · 5b339bdf
      由 Sonny Rao 提交于 
      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: NSonny Rao <sonnyrao@linux.vnet.ibm.com>
Signed-off-by: NBenjamin Herrenschmidt <benh@kernel.crashing.org>
      5b339bdf
    • B
      powerpc/vio: Switch VIO Bus PM to use generic helpers · a1263c71
      由 Brian King 提交于 
      Switch to use the generic power management helpers.
Signed-off-by: NBrian King <brking@linux.vnet.ibm.com>
Signed-off-by: NBenjamin Herrenschmidt <benh@kernel.crashing.org>
      a1263c71
    • P
      powerpc: Avoid bad relocations in iSeries code · e62cee42
      由 Paul Mackerras 提交于 
      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+0x00000000009dcec8

The 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: NSubrata Modak <subrata@linux.vnet.ibm.com>
Signed-off-by: NPaul Mackerras <paulus@samba.org>
Signed-off-by: NBenjamin Herrenschmidt <benh@kernel.crashing.org>
      e62cee42
    • M
      powerpc: Use common cpu_die (fixes SMP+SUSPEND build) · abb17f9c
      由 Milton Miller 提交于 
      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: NMatt Sealey <matt@genesi-usa.com>
Reported-by: NKumar Gala <galak@kernel.crashing.org>
Signed-off-by: NMilton Miller <miltonm@bga.com>
Signed-off-by: NAnton Vorontsov <avorontsov@mvista.com>
Signed-off-by: NBenjamin Herrenschmidt <benh@kernel.crashing.org>
      abb17f9c
    • A
      powerpc: Fix string library functions · ca5d0674
      由 Andreas Schwab 提交于 
      The powerpc strncmp implementation does not correctly handle a zero
length, despite the claim in 0119536c
(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: NAndreas Schwab <schwab@linux-m68k.org>
Acked-by: NPaul Mackerras <paulus@samba.org>
Signed-off-by: NBenjamin Herrenschmidt <benh@kernel.crashing.org>
      ca5d0674
    • M
      powerpc/rtasd: Don't start event scan if scan rate is zero · 7358650e
      由 Michael Ellerman 提交于 
      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: NMichael Ellerman <michael@ellerman.id.au>
Signed-off-by: NBenjamin Herrenschmidt <benh@kernel.crashing.org>
      7358650e
  3. 17 5月, 2010 8 次提交
  5. 07 5月, 2010 1 次提交
  7. 06 5月, 2010 18 次提交