23 Sep, 2008
1 commit
-
Just like in the arch/sparc64/kernel/of_device.c code fix commit
071d7f4c3b411beae08d27656e958070c43b78b4 ("sparc64: Fix SMP bootup
with CONFIG_STACK_DEBUG or ftrace.") we have to check the OF device
node name for "pci" instead of relying upon the 'device_type' property
being there on all PCI bridges.Tested by Meelis Roos, and confirmed to make the PCI QFE devices
reappear on the E3500 system.Signed-off-by: David S. Miller
21 Sep, 2008
1 commit
-
Based upon a bug report by Meelis Roos.
The OF device layer builds properties by matching bus types and
applying 'range' properties as appropriate, up to the root.The match for "PCI" busses is looking at the 'device_type' property,
and this does work %99 of the time.But on an E3500 system with a PCI QFE card, the DEC 21153 bridge
sitting above the QFE network interface devices has a 'name' of "pci",
but it completely lacks a 'device_type' property. So we don't match
it as a PCI bus, and subsequently we end up with no resource values at
all for the devices sitting under that DEC bridge.Signed-off-by: David S. Miller
17 Sep, 2008
2 commits
-
Based upon a report by Meelis Roos.
Any function call can try to access the current
thread register via the _mcount hooks when the kernel
is built with -pg (via ftrace or STACK_DEBUG).That can't be setup properly very early on during
the bootup of other cpus for sun4u and some early
sun4v systems.So add notrace markers to these specific functions, so
that _mcount doesn't get invoked too early.Signed-off-by: David S. Miller
-
We no longer put the top-level PCI controller device into the
PCI layer device list. So pbm->pci_bus->self is always NULL.Therefore, use direct PCI config space accesses to get at
the PCI controller's PCI_STATUS register.Tested by Meelis Roos.
Signed-off-by: David S. Miller
13 Sep, 2008
2 commits
-
As noticed by Russell King, we were not setting this properly
to the number of entries, but rather the total size.This results in the core dumping code allocating waayyyy too
much memory.Signed-off-by: David S. Miller
-
We need to pass IRQF_SHARED, otherwise we get things like:
IRQ handler type mismatch for IRQ 33
current handler: PSYCHO_UE
Call Trace:
[000000000048394c] request_irq+0xac/0x120
[00000000007c5f6c] psycho_scan_bus+0x98/0x158
[00000000007c2bc0] pcibios_init+0xdc/0x12c
[0000000000426a5c] do_one_initcall+0x1c/0x160
[00000000007c0180] kernel_init+0x9c/0xfc
[0000000000427050] kernel_thread+0x30/0x60
[00000000006ae1d0] rest_init+0x10/0x60on e3500 and similar systems.
On a single board, the UE interrupts of two Psycho nodes
are funneled through the same interrupt, from of_debug=3
dump:/pci@b,4000: direct translate 2ee --> 21
...
/pci@b,2000: direct translate 2ee --> 21Decimal "33" mentioned above is the hex "21" mentioned here.
Thanks to Meelis Roos for dumps and testing.
Signed-off-by: David S. Miller
11 Sep, 2008
1 commit
-
Use the IMAP offset calculation for OBIO devices as documented in the
programmer's manual. Which is "0x10000 + ((ino & 0x1f) << 3)"Signed-off-by: David S. Miller
09 Sep, 2008
1 commit
-
When a CPU is offlined, we leave the timer interrupts disabled
because fixup_irqs() does not explicitly take care of that case.Fix this by invoking tick_ops->disable_irq().
Based upon analysis done by Paul E. McKenney.
Signed-off-by: David S. Miller
03 Sep, 2008
2 commits
-
Make sparc64 refrain from clearing a given to-be-offlined CPU's bit in the
cpu_online_mask until it has processed pending irqs. This change
prevents other CPUs from being blindsided by an apparently offline CPU
nevertheless changing globally visible state.Signed-off-by: Paul E. McKenney
Signed-off-by: David S. Miller -
When I switched sparc64 over to the generic helpers for
smp_call_function(), I didn't convert the dinky call_lock
we had.Use ipi_call_lock() and ipi_call_unlock().
Signed-off-by: David S. Miller
30 Aug, 2008
1 commit
-
Signed-off-by: David S. Miller
29 Aug, 2008
1 commit
-
When a device is under an EBUS or ISA bus, the resource flags
don't get set properly.Fix this by re-evaluating the resource flags at each level of
bus as we apply ranges on the way to the root. And let PCI
override any existing flags setting, but don't let the
default flags calculator make such overrides.Signed-off-by: David S. Miller
25 Aug, 2008
1 commit
-
Signed-off-by: David S. Miller
14 Aug, 2008
3 commits
-
First, lmb_enforce_memory_limit() interprets it's argument
(mostly, heh) as a size limit not an address limit. So pass
the raw cmdline_memory_size value into it. And we don't
need to check it against zero, lmb_enforce_memory_limit() does
that for us.Next, free_initmem() needs special handling when the kernel
command line trims the available memory. The problem case is
if the trimmed out memory is where the kernel image itself
resides.When that memory is trimmed out, we don't add those physical
ram areas to the sparsemem active ranges, amongst other things.
Which means that this free_initmem() code will free up invalid
page structs, resulting in either crashes or hangs.Just quick fix this by not freeing initmem at all if "mem="
was given on the boot command line.Signed-off-by: David S. Miller
-
If 'start' does not begin on a page boundary, we can overshoot
past 'end'.Signed-off-by: David S. Miller
-
Things like lockdep can try to do stack backtraces before
the irqstack blocks have been setup. So don't try to match
their ranges so early on.Also, remove unused variable in save_stack_trace().
Signed-off-by: David S. Miller
13 Aug, 2008
1 commit
-
Signed-off-by: David S. Miller
12 Aug, 2008
1 commit
-
The calls down into prom_printf() when we detect an overflowed stack
can recurse again since the overflow stack will be "below" the current
kernel stack limit.Prevent this by just returning straight if we are on the stack
overflow safe stack already.Signed-off-by: David S. Miller
10 Aug, 2008
1 commit
-
Based upon a report and initial patch by Friedrich Oslage.
The intention is to provide this facility for
__trigger_all_cpu_backtrace even if MAGIC_SYSRQ is not set.The only part that should have MAGIC_SYSRQ ifdef protection is the
sparc_globalreg_op sysrq regitration and immediate code.Signed-off-by: David S. Miller
08 Aug, 2008
2 commits
-
Bug reported by Alexander Beregalov.
Before we dereference the stack frame or try to peek at the
pt_regs magic value, make sure the entire object is within
the kernel stack bounds.Signed-off-by: David S. Miller
-
Use linux/of_device.h instead.
Signed-off-by: Stephen Rothwell
Signed-off-by: David S. Miller
07 Aug, 2008
1 commit
-
Noticed by Adrian Bunk.
Signed-off-by: David S. Miller
05 Aug, 2008
14 commits
-
All of the xcall delivery implementation is cpumask agnostic, so
we can pass around pointers to const cpumask_t objects everywhere.The sad remaining case is the argument to arch_send_call_function_ipi().
Signed-off-by: David S. Miller
-
It can eat up a lot of stack space when NR_CPUS is large.
We retain some of it's functionality by reporting at least one
of the cpu's which are seen in error state.Signed-off-by: David S. Miller
-
Then modify all of the xcall dispatch implementations get passed and
use this information.Now all of the xcall dispatch implementations do not need to be mindful
of details such as "is current cpu in the list?" and "is cpu online?"Signed-off-by: David S. Miller
-
Signed-off-by: David S. Miller
-
This just facilitates the next changeset where we'll be building
the cpu list and mondo block in this helper function.Signed-off-by: David S. Miller
-
The idea is that we'll use this cpu list array and mondo block
even for non-hypervisor platforms.Signed-off-by: David S. Miller
-
Ideally this could be simplified further such that we could pass
the pointer down directly into the xcall_deliver() implementation.But if we do that we need to do the "cpu_online(cpu)" and
"cpu != self" checks down in those functions.Signed-off-by: David S. Miller
-
We know the cpu is online and not the current cpu here.
Signed-off-by: David S. Miller
-
For these cases the callers make sure:
1) The cpus indicated are online.
2) The current cpu is not in the list of indicated cpus.
Therefore we can pass a pointer to the mask directly.
One of the motivations in this transformation is to make use of
"&cpumask_of_cpu(cpu)" which evaluates to a pointer to constant
data in the kernel and thus takes up no stack space.Hopefully someone in the future will change the interface of
arch_send_call_function_ipi() such that it passes a const cpumask_t
pointer so that this will optimize ever further.Signed-off-by: David S. Miller
-
Signed-off-by: David S. Miller
-
There remained some spots still vectoring to the appropriate
*_xcall_deliver() function manually.Signed-off-by: David S. Miller
-
Initialize it using the smp_setup_processor_id() hook.
Signed-off-by: David S. Miller
-
Removed duplicated #include in
arch/sparc64/kernel/signal.c.Signed-off-by: Huang Weiyi
Signed-off-by: David S. Miller -
Based upon a bug report by Mariusz Kozlowski
It uses smp_call_function_masked() now, which has a preemption-disabled
requirement.Signed-off-by: David S. Miller
01 Aug, 2008
2 commits
-
That's the userland thread register, so we should never try to change
it like this.Based upon glibc bug nptl/6577 and suggestions by Jakub Jelinek.
Signed-off-by: David S. Miller
-
The story is that what we used to do when we actually used
smp_report_regs() is that if you specifically only wanted to have the
current cpu's registers dumped you would call "__show_regs()"
otherwise you would call show_regs() which also invoked
smp_report_regs().Now that we killed off smp_report_regs() there is no longer any
reason to have these two routines, just show_regs() is sufficient.Also kill off a stray declaration of show_regs() in sparc64_ksym.c
Signed-off-by: David S. Miller
31 Jul, 2008
2 commits
-
All the call sites are #if 0'd out and we have a much more
useful global cpu dumping facility these days. smp_report_regs()
is way too verbose to be usable.Signed-off-by: David S. Miller
-
It just clutters everything up and even though I wrote that hack I
can't remember having used it in the last 5 years or so.Signed-off-by: David S. Miller