* Re: Fw: 2.6.16 crashes when running numastat on p575
From: Paul Jackson @ 2006-04-04 0:25 UTC (permalink / raw)
To: Christoph Lameter; +Cc: akpm, linuxppc-dev, ak, ntl, linux-kernel
In-Reply-To: <Pine.LNX.4.64.0604031104110.20903@schroedinger.engr.sgi.com>
Christoph wrote:
> There may be some complicated interactions with cpusets.
Hopefully not, but it's possible. I did my best not to assume that
cpus or memory nodes stayed online, and to build in fallbacks if one
of them disappeared out from under me.
But the code has never been tested to these assumptions, nor even
carefully reviewed to them.
So something will likely break somewhere, though quite possibly not
in the cpuset code itself, but in the scheduler or allocator code
that depends on selecting an online cpu or memory for some purpose.
Someone from the hotplug side will have to look at this, with an
understanding of how the coming and going of cpus and memory nodes
can affect the scheduler and allocators.
Look at the callers of cpuset_cpus_allowed(), cpuset_mems_allowed(),
cpuset_update_task_memory_state(), and cpuset_zone_allowed() to see
the likely hot spots for interaction between cpusets and hotplug.
The callers of these routines are important hooks into the scheduler
and allocator, and the question needs to be asked what happens if
a cpu or memory node goes offline after one of these cpuset_*()
routines is called before the scheduler or allocator finishes doing
what it is doing with what it thought was a usable cpu or node.
Also, there is currently no hotplug aware code that I know of in
the kernel/cpuset.c code, so each of the references to the globals
cpu_online_map and node_online_map therein are suspect. Presumably as
anywhere else in the kernel these appear, or the for_each_online_*()
macros appear, the code needs to be examined for perhaps needing some
sort of guard.
So, in sum, the kernel needs to be inspected at the location of at
least each of the following calls or references, for possible problems
if the cpus or nodes online change unexpectedly:
any_online_node()
cpu_online_map
cpu_present()
cpu_present_map
cpuset_cpus_allowed()
cpuset_mems_allowed()
cpuset_update_task_memory_state()
cpuset_zone_allowed()
for_each_online_cpu()
for_each_online_node()
for_each_present_cpu()
node_online_map
num_online_cpus()
num_online_nodes()
num_present_cpus()
--
I won't rest till it's the best ...
Programmer, Linux Scalability
Paul Jackson <pj@sgi.com> 1.925.600.0401
^ permalink raw reply
* Re: _machine removal breaks kexec?
From: Kumar Gala @ 2006-04-04 0:43 UTC (permalink / raw)
To: Segher Boessenkool; +Cc: paulus, linuxppc-dev
In-Reply-To: <58ACDA01-2AD5-494C-9325-F8FF68620491@kernel.crashing.org>
On Apr 3, 2006, at 6:16 PM, Segher Boessenkool wrote:
>>> I suppose kexec needs to look for /rtas/hypertas or such ..
>>
>> uugh, can we make kexec not depend on something that embedded systems
>> would also have.
>
> You have embedded systems with a hypervisor? And, a /hypertas node
> even?
no and no. However, I dont see any reason kexec should be available
on embedded PPCs.
- k
^ permalink raw reply
* platinumfb broken in 2.6.16
From: Bob Brose @ 2006-04-04 2:09 UTC (permalink / raw)
To: linuxppc-dev
Worked in 2.6.14:
platinumfb: Found Apple Platinum video hardware
platinumfb: Total VRAM = 2MB (0011)
platinumfb: DACula type 0x3c
platinumfb: Monitor sense value = 0x62b, platinumfb: Using video mode 6 and col
or mode 2.
line_length: a20
Console: switching to colour frame buffer device 80x30
fb0: Apple Platinum frame buffer device
Macintosh non-volatile memory driver v1.1
This is all I get in 2.6.16:
Platinumfb: Found Apple Platinum video hardware
Macintosh non-volatile memory driver v1.1
The screen has the boot params on it but is otherwise blank.
Everything else works as normal.
^ permalink raw reply
* of_platform bus?
From: Li Yang-r58472 @ 2006-04-04 3:52 UTC (permalink / raw)
To: linuxppc-embedded
I noticed that there is a new bus type of_platform_bus added. Current ppc embedded systems are using platform_device, and are changing to use OF flat device tree structure. Does it mean that current drivers need to be switched from platform_bus to of_platform_bus?
--
Regards,
Leo
^ permalink raw reply
* Re: of_platform bus?
From: Kumar Gala @ 2006-04-04 4:14 UTC (permalink / raw)
To: Li Yang-r58472; +Cc: linuxppc-embedded
In-Reply-To: <9FCDBA58F226D911B202000BDBAD4673081427@zch01exm40.ap.freescale.net>
On Apr 3, 2006, at 10:52 PM, Li Yang-r58472 wrote:
> I noticed that there is a new bus type of_platform_bus added.
> Current ppc embedded systems are using platform_device, and are
> changing to use OF flat device tree structure. Does it mean that
> current drivers need to be switched from platform_bus to
> of_platform_bus?
At some point we may look at that. However, since drivers are shared
between arch/ppc and arch/powerpc we will continue to use
platform_device.
- k
^ permalink raw reply
* Re: [PATCH] Add 85xx CDS to arch/powerpc
From: Kumar Gala @ 2006-04-04 4:27 UTC (permalink / raw)
To: Jon Loeliger; +Cc: linuxppc-dev, Paul Mackerras, linuxppc-embedded
In-Reply-To: <E1FQBs8-00061K-BI@jdl.com>
On Sun, 2 Apr 2006, Jon Loeliger wrote:
> So, like, the other day Arnd Bergmann mumbled:
> > [MPIC]
> >
> > Shouldn't all this come from the device tree?
> >
> > ...
> >
> > > +/* PCI interrupt controller */
> > > +#define PIRQ0A MPC85xx_IRQ_EXT0
> > > +#define PIRQ0B MPC85xx_IRQ_EXT1
> > > +#define PIRQ0C MPC85xx_IRQ_EXT2
> > > +#define PIRQ0D MPC85xx_IRQ_EXT3
> > > +#define PIRQ1A MPC85xx_IRQ_EXT11
> >
> > And these as well, more importantly?
>
> Yep. In time they will. However, the parsing of the
> PIC nodes hasn't been added to the 85xx (uh, nor 83xx)
> as of yet.
>
> It is on "the list".
>
> We should defer to Kumar to accepting these at this stage
> or not.
As Jon stated its on the list. We need to work up something like what we
have for parsing memory addresses for irqs. Ben has some ideas, until
then we make forward progress using the old style of things.
- k
^ permalink raw reply
* [PATCH] powerpc: iSeries has only 256 IRQs
From: Stephen Rothwell @ 2006-04-04 4:56 UTC (permalink / raw)
To: paulus; +Cc: ppc-dev
[-- Attachment #1: Type: text/plain, Size: 5167 bytes --]
The iSeries Hypervisor only allows us to specify IRQ numbers up to 255 (it
has a u8 field to pass it in). This patch allows platforms to specify a
maximum to the virtual IRQ numbers we will use and has iSeries set that
to 255. If not set, the maximum is NR_IRQS - 1 (as before).
Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
---
arch/powerpc/kernel/irq.c | 36 ++++++++++++++++++++------------
arch/powerpc/platforms/iseries/setup.c | 7 ++++++
include/asm-powerpc/irq.h | 7 ++++++
3 files changed, 36 insertions(+), 14 deletions(-)
This has been booted on iSeries partitions that have hardware that would
have previously tried to use IRQ numbers above 255.
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
7d01c880856bae31502095bc68784c1518a680cb
diff --git a/arch/powerpc/kernel/irq.c b/arch/powerpc/kernel/irq.c
index bb5c950..57d560c 100644
--- a/arch/powerpc/kernel/irq.c
+++ b/arch/powerpc/kernel/irq.c
@@ -272,18 +272,26 @@ unsigned int virt_irq_to_real_map[NR_IRQ
* Don't use virtual irqs 0, 1, 2 for devices.
* The pcnet32 driver considers interrupt numbers < 2 to be invalid,
* and 2 is the XICS IPI interrupt.
- * We limit virtual irqs to 17 less than NR_IRQS so that when we
- * offset them by 16 (to reserve the first 16 for ISA interrupts)
- * we don't end up with an interrupt number >= NR_IRQS.
+ * We limit virtual irqs to __irq_offet_value less than virt_irq_max so
+ * that when we offset them we don't end up with an interrupt
+ * number > virt_irq_max.
*/
#define MIN_VIRT_IRQ 3
-#define MAX_VIRT_IRQ (NR_IRQS - NUM_ISA_INTERRUPTS - 1)
-#define NR_VIRT_IRQS (MAX_VIRT_IRQ - MIN_VIRT_IRQ + 1)
+
+unsigned int virt_irq_max;
+static unsigned int max_virt_irq;
+static unsigned int nr_virt_irqs;
void
virt_irq_init(void)
{
int i;
+
+ if ((virt_irq_max == 0) || (virt_irq_max > (NR_IRQS - 1)))
+ virt_irq_max = NR_IRQS - 1;
+ max_virt_irq = virt_irq_max - __irq_offset_value;
+ nr_virt_irqs = max_virt_irq - MIN_VIRT_IRQ + 1;
+
for (i = 0; i < NR_IRQS; i++)
virt_irq_to_real_map[i] = UNDEFINED_IRQ;
}
@@ -308,17 +316,17 @@ int virt_irq_create_mapping(unsigned int
return real_irq;
}
- /* map to a number between MIN_VIRT_IRQ and MAX_VIRT_IRQ */
+ /* map to a number between MIN_VIRT_IRQ and max_virt_irq */
virq = real_irq;
- if (virq > MAX_VIRT_IRQ)
- virq = (virq % NR_VIRT_IRQS) + MIN_VIRT_IRQ;
+ if (virq > max_virt_irq)
+ virq = (virq % nr_virt_irqs) + MIN_VIRT_IRQ;
/* search for this number or a free slot */
first_virq = virq;
while (virt_irq_to_real_map[virq] != UNDEFINED_IRQ) {
if (virt_irq_to_real_map[virq] == real_irq)
return virq;
- if (++virq > MAX_VIRT_IRQ)
+ if (++virq > max_virt_irq)
virq = MIN_VIRT_IRQ;
if (virq == first_virq)
goto nospace; /* oops, no free slots */
@@ -330,8 +338,8 @@ int virt_irq_create_mapping(unsigned int
nospace:
if (!warned) {
printk(KERN_CRIT "Interrupt table is full\n");
- printk(KERN_CRIT "Increase NR_IRQS (currently %d) "
- "in your kernel sources and rebuild.\n", NR_IRQS);
+ printk(KERN_CRIT "Increase virt_irq_max (currently %d) "
+ "in your kernel sources and rebuild.\n", virt_irq_max);
warned = 1;
}
return NO_IRQ;
@@ -349,8 +357,8 @@ unsigned int real_irq_to_virt_slowpath(u
virq = real_irq;
- if (virq > MAX_VIRT_IRQ)
- virq = (virq % NR_VIRT_IRQS) + MIN_VIRT_IRQ;
+ if (virq > max_virt_irq)
+ virq = (virq % nr_virt_irqs) + MIN_VIRT_IRQ;
first_virq = virq;
@@ -360,7 +368,7 @@ unsigned int real_irq_to_virt_slowpath(u
virq++;
- if (virq >= MAX_VIRT_IRQ)
+ if (virq >= max_virt_irq)
virq = 0;
} while (first_virq != virq);
diff --git a/arch/powerpc/platforms/iseries/setup.c b/arch/powerpc/platforms/iseries/setup.c
index 6ce8a40..a6fd9be 100644
--- a/arch/powerpc/platforms/iseries/setup.c
+++ b/arch/powerpc/platforms/iseries/setup.c
@@ -54,6 +54,7 @@
#include <asm/iseries/hv_lp_event.h>
#include <asm/iseries/lpar_map.h>
#include <asm/udbg.h>
+#include <asm/irq.h>
#include "naca.h"
#include "setup.h"
@@ -684,6 +685,12 @@ static int __init iseries_probe(void)
powerpc_firmware_features |= FW_FEATURE_ISERIES;
powerpc_firmware_features |= FW_FEATURE_LPAR;
+ /*
+ * The Hypervisor only allows us up to 256 interrupt
+ * sources (the irq number is passed in a u8).
+ */
+ virt_irq_max = 255;
+
return 1;
}
diff --git a/include/asm-powerpc/irq.h b/include/asm-powerpc/irq.h
index 51f87d9..7bc6d73 100644
--- a/include/asm-powerpc/irq.h
+++ b/include/asm-powerpc/irq.h
@@ -54,6 +54,13 @@
*/
extern unsigned int virt_irq_to_real_map[NR_IRQS];
+/* The maximum virtual IRQ number that we support. This
+ * can be set by the platform and will be reduced by the
+ * value of __irq_offset_value. It defaults to and is
+ * capped by (NR_IRQS - 1).
+ */
+extern unsigned int virt_irq_max;
+
/* Create a mapping for a real_irq if it doesn't already exist.
* Return the virtual irq as a convenience.
*/
--
1.2.4
[-- Attachment #2: Type: application/pgp-signature, Size: 191 bytes --]
^ permalink raw reply related
* Re: _machine removal breaks kexec?
From: Michael Ellerman @ 2006-04-04 5:40 UTC (permalink / raw)
To: Haren Myneni; +Cc: linuxppc-dev, paulus
In-Reply-To: <44316705.1040202@us.ibm.com>
On Mon, 2006-04-03 at 11:18 -0700, Haren Myneni wrote:
> Basically, kexec-tools looks the platform property to determine whether
> to read tce-base, tce-size and htab-* properties. The attached patch
> find out the platform info based on /proc/device-tree/chosen/htab-base
> property. Not tested yet.
Why don't we get rid of the platform variable entirely in kexec-ppc64.c,
if the tce-* and htab-* properties are there, then we read them, if not
we don't.
There's also:
if (platform == PLATFORM_PSERIES) {
if (rmo_top > 0x30000000UL)
rmo_top = 0x30000000UL;
}
I'm not sure where that number comes from, perhaps we need to export the
RMO value like we do for the htab?
While we're there that code could use a function to read
a /proc/device-tree file and do error handling, there's a lot of
duplicate code at the moment.
cheers
--
Michael Ellerman
IBM OzLabs
wwweb: http://michael.ellerman.id.au
phone: +61 2 6212 1183 (tie line 70 21183)
We do not inherit the earth from our ancestors,
we borrow it from our children. - S.M.A.R.T Person
^ permalink raw reply
* Re: _machine removal breaks kexec?
From: Haren Myneni @ 2006-04-04 6:15 UTC (permalink / raw)
To: Michael Ellerman; +Cc: linuxppc-dev, paulus
In-Reply-To: <1144129248.29756.7.camel@localhost.localdomain>
[-- Attachment #1: Type: text/plain, Size: 1794 bytes --]
linuxppc-dev-bounces+hbabu=us.ibm.com@ozlabs.org wrote on 04/03/2006
10:40:48 PM:
> On Mon, 2006-04-03 at 11:18 -0700, Haren Myneni wrote:
> > Basically, kexec-tools looks the platform property to determine
whether
> > to read tce-base, tce-size and htab-* properties. The attached patch
> > find out the platform info based on /proc/device-tree/chosen/htab-base
> > property. Not tested yet.
>
> Why don't we get rid of the platform variable entirely in kexec-ppc64.c,
> if the tce-* and htab-* properties are there, then we read them, if not
> we don't.
>
> There's also:
>
> if (platform == PLATFORM_PSERIES) {
> if (rmo_top > 0x30000000UL)
> rmo_top = 0x30000000UL;
> }
>
> I'm not sure where that number comes from, perhaps we need to export the
> RMO value like we do for the htab?
Yes, we can remove this PLATFORM_* and read these properties if exists. I
believe, this large number is copied from prom_init.c. I am not sure
whether exporting rmo_top is needed since it is always the size of first
memory node unless the size is greater than 0x30000000UL. PLATFORM_PSERIES
is not needed anyway for this comparison.
>
> While we're there that code could use a function to read
> a /proc/device-tree file and do error handling, there's a lot of
> duplicate code at the moment.
>
Yes, there is some cleanup needed in kexec-tools.
Thanks
Haren
> cheers
>
> --
> Michael Ellerman
> IBM OzLabs
>
> wwweb: http://michael.ellerman.id.au
> phone: +61 2 6212 1183 (tie line 70 21183)
>
> We do not inherit the earth from our ancestors,
> we borrow it from our children. - S.M.A.R.T Person
>
> _______________________________________________
> Linuxppc-dev mailing list
> Linuxppc-dev@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-dev
[-- Attachment #2: Type: text/html, Size: 2432 bytes --]
^ permalink raw reply
* [RFC/PATCH] powerpc: Use rtas query-cpu-stopped-state in smp spinup
From: Michael Ellerman @ 2006-04-04 11:24 UTC (permalink / raw)
To: Paul Mackerras; +Cc: linuxppc-dev, Arnd Bergmann
Currently we use a cpumask called of_spin_map to keep track of which threads
have been spun up. We basically guess that OF has spun up all even numbered
threads, and so all the odd numbered threads need to be brought up.
That's a bit of a dicey assumption at best, and is totally incorrect for
kexec. Luckily we have an rtas call which can tell us whether a cpu is up
or not, so let's use it?
I notice this code is duplicated in platforms/cell, do we want to move it into
kernel/rtas_smp.c or something?
Signed-off-by: Michael Ellerman <michael@ellerman.id.au>
---
arch/powerpc/platforms/pseries/smp.c | 48 +++++++----------------------------
1 file changed, 10 insertions(+), 38 deletions(-)
Index: to-merge/arch/powerpc/platforms/pseries/smp.c
===================================================================
--- to-merge.orig/arch/powerpc/platforms/pseries/smp.c
+++ to-merge/arch/powerpc/platforms/pseries/smp.c
@@ -57,16 +57,6 @@
#define DBG(fmt...)
#endif
-/*
- * The primary thread of each non-boot processor is recorded here before
- * smp init.
- */
-static cpumask_t of_spin_map;
-
-extern void pSeries_secondary_smp_init(unsigned long);
-
-#ifdef CONFIG_HOTPLUG_CPU
-
/* Get state of physical CPU.
* Return codes:
* 0 - The processor is in the RTAS stopped state
@@ -93,6 +83,8 @@ static int query_cpu_stopped(unsigned in
return cpu_status;
}
+#ifdef CONFIG_HOTPLUG_CPU
+
static int pSeries_cpu_disable(void)
{
int cpu = smp_processor_id();
@@ -269,22 +261,23 @@ static struct notifier_block pSeries_smp
*/
static inline int __devinit smp_startup_cpu(unsigned int lcpu)
{
- int status;
+ extern void pSeries_secondary_smp_init(unsigned long);
unsigned long start_here = __pa((u32)*((unsigned long *)
pSeries_secondary_smp_init));
unsigned int pcpu;
- int start_cpu;
-
- if (cpu_isset(lcpu, of_spin_map))
- /* Already started by OF and sitting in spin loop */
- return 1;
+ int start_cpu, status;
pcpu = get_hard_smp_processor_id(lcpu);
+ if (query_cpu_stopped(pcpu) == 0) {
+ DBG("CPU %d (%d) already running.\n", lcpu, pcpu);
+ return 1;
+ }
+
/* Fixup atomic count: it exited inside IRQ handler. */
task_thread_info(paca[lcpu].__current)->preempt_count = 0;
- /*
+ /*
* If the RTAS start-cpu token does not exist then presume the
* cpu is already spinning.
*/
@@ -339,9 +332,6 @@ static void __devinit smp_xics_setup_cpu
if (firmware_has_feature(FW_FEATURE_SPLPAR))
vpa_init(cpu);
-
- cpu_clear(cpu, of_spin_map);
-
}
#endif /* CONFIG_XICS */
@@ -419,8 +409,6 @@ static struct smp_ops_t pSeries_xics_smp
/* This is called very early */
void __init smp_init_pSeries(void)
{
- int i;
-
DBG(" -> smp_init_pSeries()\n");
switch (ppc64_interrupt_controller) {
@@ -447,22 +435,6 @@ void __init smp_init_pSeries(void)
pSeries_reconfig_notifier_register(&pSeries_smp_nb);
#endif
- /* Mark threads which are still spinning in hold loops. */
- if (cpu_has_feature(CPU_FTR_SMT)) {
- for_each_present_cpu(i) {
- if (i % 2 == 0)
- /*
- * Even-numbered logical cpus correspond to
- * primary threads.
- */
- cpu_set(i, of_spin_map);
- }
- } else {
- of_spin_map = cpu_present_map;
- }
-
- cpu_clear(boot_cpuid, of_spin_map);
-
/* Non-lpar has additional take/give timebase */
if (rtas_token("freeze-time-base") != RTAS_UNKNOWN_SERVICE) {
smp_ops->give_timebase = pSeries_give_timebase;
^ permalink raw reply
* [PATCH] powerpc: Disable and EOI interrupts in machine_crash_shutdown()
From: Michael Ellerman @ 2006-04-04 11:43 UTC (permalink / raw)
To: Paul Mackerras, linuxppc-dev; +Cc: Milton Miller
We've seen several bugs caused by interrupt weirdness in the kdump kernel.
Panicking from an interrupt handler means we fail to EOI the interrupt, and
so the second kernel never gets that interrupt ever again. We also see hangs
on JS20 where we take interrupts in the second kernel early during boot.
This patch fixes both those problems, and although it adds more code to the
crash path I think it is the best solution.
Signed-off-by: Michael Ellerman <michael@ellerman.id.au>
---
arch/powerpc/kernel/crash.c | 13 +++++++++++++
1 file changed, 13 insertions(+)
Index: kdump/arch/powerpc/kernel/crash.c
===================================================================
--- kdump.orig/arch/powerpc/kernel/crash.c
+++ kdump/arch/powerpc/kernel/crash.c
@@ -22,6 +22,7 @@
#include <linux/elf.h>
#include <linux/elfcore.h>
#include <linux/init.h>
+#include <linux/irq.h>
#include <linux/types.h>
#include <asm/processor.h>
@@ -174,6 +175,8 @@ static void crash_kexec_prepare_cpus(voi
void default_machine_crash_shutdown(struct pt_regs *regs)
{
+ unsigned int irq;
+
/*
* This function is only called after the system
* has paniced or is otherwise in a critical state.
@@ -186,6 +189,16 @@ void default_machine_crash_shutdown(stru
*/
local_irq_disable();
+ for_each_irq(irq) {
+ struct irq_desc *desc = irq_descp(irq);
+
+ if (desc->status & IRQ_INPROGRESS)
+ desc->handler->end(irq);
+
+ if (!(desc->status & IRQ_DISABLED))
+ desc->handler->disable(irq);
+ }
+
if (ppc_md.kexec_cpu_down)
ppc_md.kexec_cpu_down(1, 0);
^ permalink raw reply
* Re: _machine removal breaks kexec?
From: Benjamin Herrenschmidt @ 2006-04-04 12:04 UTC (permalink / raw)
To: Kumar Gala; +Cc: linuxppc-dev, paulus
In-Reply-To: <1078253E-4B9E-4432-86E3-82B01A4B68D1@kernel.crashing.org>
> uugh, can we make kexec not depend on something that embedded systems
> would also have.
Embedded systems will have hypertas ? ugh ..
Ben.
^ permalink raw reply
* Re: _machine removal breaks kexec?
From: Benjamin Herrenschmidt @ 2006-04-04 12:05 UTC (permalink / raw)
To: Haren Myneni; +Cc: linuxppc-dev, paulus
In-Reply-To: <44316705.1040202@us.ibm.com>
> Basically, kexec-tools looks the platform property to determine whether
> to read tce-base, tce-size and htab-* properties. The attached patch
> find out the platform info based on /proc/device-tree/chosen/htab-base
> property. Not tested yet.
You should just test if the properties exist ...
> Kumar, kexec-tools completely depends on device-tree. Not sure whether
> the embedded system exports the device-tree.
With arch=powerpc, they do
^ permalink raw reply
* Re: [RFC/PATCH] powerpc: Use rtas query-cpu-stopped-state in smp spinup
From: Anton Blanchard @ 2006-04-04 12:42 UTC (permalink / raw)
To: Michael Ellerman; +Cc: linuxppc-dev, Paul Mackerras, Arnd Bergmann
In-Reply-To: <20060404112459.C9170679EB@ozlabs.org>
Hi,
> Currently we use a cpumask called of_spin_map to keep track of which threads
> have been spun up. We basically guess that OF has spun up all even numbered
> threads, and so all the odd numbered threads need to be brought up.
>
> That's a bit of a dicey assumption at best, and is totally incorrect for
> kexec. Luckily we have an rtas call which can tell us whether a cpu is up
> or not, so let's use it?
I have a bad feeling its broken on some older (POWER3) machines.
Anton
^ permalink raw reply
* Re: [RFC/PATCH] powerpc: Use rtas query-cpu-stopped-state in smp spinup
From: Michael Ellerman @ 2006-04-04 12:46 UTC (permalink / raw)
To: Anton Blanchard; +Cc: linuxppc-dev, Paul Mackerras, Arnd Bergmann
In-Reply-To: <20060404124248.GA26436@krispykreme>
[-- Attachment #1: Type: text/plain, Size: 1032 bytes --]
On Tue, 2006-04-04 at 22:42 +1000, Anton Blanchard wrote:
> Hi,
>
> > Currently we use a cpumask called of_spin_map to keep track of which threads
> > have been spun up. We basically guess that OF has spun up all even numbered
> > threads, and so all the odd numbered threads need to be brought up.
> >
> > That's a bit of a dicey assumption at best, and is totally incorrect for
> > kexec. Luckily we have an rtas call which can tell us whether a cpu is up
> > or not, so let's use it?
>
> I have a bad feeling its broken on some older (POWER3) machines.
Ok, we'll have to see _how_ it's broken. But if it falsely reports that
the thread is started that will suck. I haven't been able to test on my
Power3 because of another breakage *cough benh cough*. I'll try it
sometime.
cheers
--
Michael Ellerman
IBM OzLabs
wwweb: http://michael.ellerman.id.au
phone: +61 2 6212 1183 (tie line 70 21183)
We do not inherit the earth from our ancestors,
we borrow it from our children. - S.M.A.R.T Person
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 191 bytes --]
^ permalink raw reply
* RE: Can't get serial SMC1 and SMC2 working together
From: Björn Östby @ 2006-04-04 13:34 UTC (permalink / raw)
To: Kenneth Poole, linuxppc-embedded
>
>>I'm using a TQM823L board, ELDK and Linux 2.4.25 (from denx). My=20
>>problem is that i can't use both SMC1 and SMC2 at the same time when I =
>>disable the console (console=3Dnull).
>
>Serial port interactions can result from incorrect mapping of the baud
>rate generators (BRGs) to the ports. I'm looking at source from 2.4.19,
>and this may have changed, but the serial driver init function =
(rs_8xx_init)
>calls m8xx_cpm_setbrg() with 'baud_idx' as the argument that selects =
which
>BRG. 'baud_idx' is set in serial_console_setup(). If you don't =
configure
>a console, 'baud_idx' may not be initialized.
>
>In any event, make sure that the BRGs are mapped to the ports as=20
>required for your specific board.
>
>Ken Poole
>MRV Communications, INC.
>
I had the same problem with a custom 823 based card a few weeks ago. =
Turned=20
out smc1 and smc2 indeed became wired to the same BRG when =
console=3D....=20
was passed as argument. My solution was a fast bypass hack in uart.c and =
no console=3D argument_
long __init console_8xx_init(long kmem_start, long kmem_end)
{
/* register_console(&sercons); */
sercons.setup(&sercons, NULL);
return kmem_start;
}
A very static and ugly solution since time was of big essence, but that=20
could possibly help you.
Regards,
Bj=F6rn =D6stby
_______________________________________________
Linuxppc-embedded mailing list
Linuxppc-embedded@ozlabs.org =
https://ozlabs.org/mailman/listinfo/linuxppc-embedded
^ permalink raw reply
* Re: [PATCH] powerpc: iSeries has only 256 IRQs
From: Olaf Hering @ 2006-04-04 13:36 UTC (permalink / raw)
To: Stephen Rothwell; +Cc: ppc-dev, paulus
In-Reply-To: <20060404145620.00697fff.sfr@canb.auug.org.au>
On Tue, Apr 04, Stephen Rothwell wrote:
> The iSeries Hypervisor only allows us to specify IRQ numbers up to 255 (it
> has a u8 field to pass it in). This patch allows platforms to specify a
> maximum to the virtual IRQ numbers we will use and has iSeries set that
> to 255. If not set, the maximum is NR_IRQS - 1 (as before).
I tried this patch, and the partition dies that way:
vio_register_driver: driver iseries_veth registering
iseries_veth: eth0 attached to iSeries vlan 0 (LPAR map = 0x0005)
Emulex LightPulse Fibre Channel SCSI driver 8.1.4
Copyright(c) 2004-2006 Emulex. All rights reserved.
PCI: Enabling device: (0000:18:12.0), cmd 3
scsi0 : on PCI bus 18 device 90 irq 212
PCI: RDL: Device 0x0018:90 I/O Error( 1): 0x0101
PCI: RDL: Device 0x0018:90 I/O Error( 2): 0x0102
PCI: RDL: Device 0x0018:90 I/O Error( 3): 0x0102
PCI: RDL: Device 0x0018:90 I/O Error( 4): 0x0102
Kernel panic - not syncing: PCI: Hardware I/O Error, SRC B6000103, Automatic Reboot Disabled.
<3>Badness in smp_call_function at arch/powerpc/kernel/smp.c:228
Call Trace:
[C00000000F836E50] [C00000000000E444] .show_stack+0x68/0x1b0 (unreliable)
[C00000000F836EF0] [C000000000264FDC] .program_check_exception+0x1cc/0x5a8
[C00000000F836FC0] [C000000000004A70] program_check_common+0xf0/0x100
--- Exception: 700 at .smp_call_function+0x34/0x1d8
LR = .smp_call_function+0x28/0x1d8
[C00000000F8372B0] [C000000000334800] zone_names+0x818/0xf18 (unreliable)
[C00000000F837360] [C0000000000376F4] .panic+0xa0/0x194
[C00000000F837400] [C00000000002C354] .CheckReturnCode+0xac/0xc4
[C00000000F837480] [C00000000002CEB0] .iSeries_Read_Long+0x160/0x19c
[C00000000F837530] [D00000000021F5A0] .lpfc_sli_brdrestart+0xc8/0x1c0 [lpfc]
[C00000000F8375D0] [D00000000021F70C] .lpfc_sli_hba_setup+0x74/0x3e0 [lpfc]
[C00000000F837680] [D0000000002328C4] .lpfc_pci_probe_one+0x650/0xa7c [lpfc]
[C00000000F837740] [C0000000001970C4] .pci_device_probe+0x80/0xc4
[C00000000F8377D0] [C0000000001B0DE8] .driver_probe_device+0xa0/0x15c
[C00000000F837870] [C0000000001B1078] .__driver_attach+0xdc/0x164
[C00000000F837900] [C0000000001B051C] .bus_for_each_dev+0x7c/0xd4
[C00000000F8379C0] [C0000000001B0C8C] .driver_attach+0x28/0x40
[C00000000F837A40] [C0000000001AFFBC] .bus_add_driver+0x90/0x170
[C00000000F837AE0] [C0000000001B14A8] .driver_register+0xbc/0xd8
[C00000000F837B70] [C000000000196EA0] .__pci_register_driver+0x8c/0xd8
[C00000000F837C10] [D00000000023C028] .lpfc_init+0x60/0x2828 [lpfc]
[C00000000F837CA0] [C00000000005C564] .sys_init_module+0x1898/0x1bc4
[C00000000F837E30] [C000000000008534] syscall_exit+0x0/0x40
...
Before, it just did not find the card:
...
vio_register_driver: driver iseries_veth registering
iseries_veth: eth0 attached to iSeries vlan 0 (LPAR map = 0x0005)
Emulex LightPulse Fibre Channel SCSI driver 8.1.4
Copyright(c) 2004-2006 Emulex. All rights reserved.
PCI: Enabling device: (0000:18:12.0), cmd 3
scsi0 : on PCI bus 18 device 90 irq 235
lpfc 0000:18:12.0: 0:0451 Enable interrupt handler failed
lpfc: probe of 0000:18:12.0 failed with error -38
...
So, there is likely more breakage.
^ permalink raw reply
* Re: [PATCH] powerpc: iSeries has only 256 IRQs
From: Stephen Rothwell @ 2006-04-04 13:43 UTC (permalink / raw)
To: Olaf Hering; +Cc: linuxppc-dev, paulus
In-Reply-To: <20060404133614.GA24210@suse.de>
[-- Attachment #1: Type: text/plain, Size: 641 bytes --]
On Tue, 4 Apr 2006 15:36:14 +0200 Olaf Hering <olh@suse.de> wrote:
>
> On Tue, Apr 04, Stephen Rothwell wrote:
>
> > The iSeries Hypervisor only allows us to specify IRQ numbers up to 255 (it
> > has a u8 field to pass it in). This patch allows platforms to specify a
> > maximum to the virtual IRQ numbers we will use and has iSeries set that
> > to 255. If not set, the maximum is NR_IRQS - 1 (as before).
>
> I tried this patch, and the partition dies that way:
Thanks for the test, I will have a further look.
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/
[-- Attachment #2: Type: application/pgp-signature, Size: 191 bytes --]
^ permalink raw reply
* Re: [PATCH] powerpc: iSeries has only 256 IRQs
From: Stephen Rothwell @ 2006-04-04 15:08 UTC (permalink / raw)
To: Olaf Hering; +Cc: linuxppc-dev, paulus
In-Reply-To: <20060404133614.GA24210@suse.de>
[-- Attachment #1: Type: text/plain, Size: 824 bytes --]
Hi Olaf,
On Tue, 4 Apr 2006 15:36:14 +0200 Olaf Hering <olh@suse.de> wrote:
>
> On Tue, Apr 04, Stephen Rothwell wrote:
>
> > The iSeries Hypervisor only allows us to specify IRQ numbers up to 255 (it
> > has a u8 field to pass it in). This patch allows platforms to specify a
> > maximum to the virtual IRQ numbers we will use and has iSeries set that
> > to 255. If not set, the maximum is NR_IRQS - 1 (as before).
>
> I tried this patch, and the partition dies that way:
If you have time, can you try (without this patch) just changing NR_IRQS in
include/asm-powerpc/irq.h from 512 to 256 and see if that kernel will boot
and what changes (if any) you get to the boot messages.
Thanks.
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/
[-- Attachment #2: Type: application/pgp-signature, Size: 191 bytes --]
^ permalink raw reply
* Re: snd-aoa: new apple sound driver
From: Johannes Berg @ 2006-04-04 15:51 UTC (permalink / raw)
To: linuxppc-dev; +Cc: debian-powerpc, Alastair Poole
In-Reply-To: <1143547826.13615.24.camel@localhost>
[-- Attachment #1: Type: text/plain, Size: 359 bytes --]
On Tue, 2006-03-28 at 14:10 +0200, Johannes Berg wrote:
> I'm going to write a snd-aoa-codec-tas3004 soon, so
> that I can use the new code here on both of my machines.
somewhat done, but I suggest you use it only on powerbook5,6 now where I
confirmed that it works (before I add more error checking, proper
handling of some cases etc.)
johannes
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 793 bytes --]
^ permalink raw reply
* Re: [RFC/PATCH] powerpc: Use rtas query-cpu-stopped-state in smp spinup
From: Nathan Lynch @ 2006-04-04 17:25 UTC (permalink / raw)
To: Michael Ellerman; +Cc: linuxppc-dev, Paul Mackerras, Arnd Bergmann
In-Reply-To: <20060404112459.C9170679EB@ozlabs.org>
Michael Ellerman wrote:
> Currently we use a cpumask called of_spin_map to keep track of which threads
> have been spun up. We basically guess that OF has spun up all even numbered
> threads, and so all the odd numbered threads need to be brought up.
>
> That's a bit of a dicey assumption at best, and is totally incorrect for
> kexec.
>
> Luckily we have an rtas call which can tell us whether a cpu is up
> or not, so let's use it?
1. query-cpu-stopped-state isn't available on all RTAS systems (I
believe it's required only on systems that support cpu offline).
2. I've tried it before. Hope I'm remembering this correctly, but I
think my experience was that query-cpu-stopped-state reported
nonsense for cpus that were started by OF. This was on Power5,
btw.
3. This isn't how query-cpu-stopped-state was intended to be used.
It's meant to be used by the OS to determine when a thread has
stopped itself using the stop-self method. Which might partially
explain (2).
I'm fine with getting rid of the assumptions about thread numbering,
but I don't think this is gonna work, sorry.
^ permalink raw reply
* Re: [PATCH] powerpc: iSeries has only 256 IRQs
From: Olaf Hering @ 2006-04-04 18:34 UTC (permalink / raw)
To: Stephen Rothwell; +Cc: linuxppc-dev, paulus
In-Reply-To: <20060405010818.7e992a66.sfr@canb.auug.org.au>
On Wed, Apr 05, Stephen Rothwell wrote:
> If you have time, can you try (without this patch) just changing NR_IRQS in
> include/asm-powerpc/irq.h from 512 to 256 and see if that kernel will boot
> and what changes (if any) you get to the boot messages.
This results in a different irq:
vio_register_driver: driver iseries_veth registering
iseries_veth: eth0 attached to iSeries vlan 0 (LPAR map = 0x0005)
Emulex LightPulse Fibre Channel SCSI driver 8.1.4
Copyright(c) 2004-2006 Emulex. All rights reserved.
PCI: Enabling device: (0000:18:12.0), cmd 3
scsi0 : on PCI bus 18 device 90 irq 55
PCI: RDL: Device 0x0018:90 I/O Error( 1): 0x0101
PCI: RDL: Device 0x0018:90 I/O Error( 2): 0x0102
PCI: RDL: Device 0x0018:90 I/O Error( 3): 0x0102
PCI: RDL: Device 0x0018:90 I/O Error( 4): 0x0102
Kernel panic - not syncing: PCI: Hardware I/O Error, SRC B6000103, Automatic Reboot Disabled.
<3>Badness in smp_call_function at /usr/src/linux-2.6.16-8/arch/powerpc/kernel/smp.c:228
Call Trace:
[C00000003E8DAF40] [C00000000000E3E4] .show_stack+0x68/0x1b0 (unreliable)
[C00000003E8DAFE0] [C000000000264BF4] .program_check_exception+0x1cc/0x5a8
[C00000003E8DB0B0] [C000000000004A70] program_check_common+0xf0/0x100
--- Exception: 700 at .smp_call_function+0x34/0x1d8
LR = .smp_call_function+0x28/0x1d8
[C00000003E8DB3A0] [C000000000330000] zone_names+0x818/0xf18 (unreliable)
[C00000003E8DB450] [C0000000000371EC] .panic+0xa0/0x194
[C00000003E8DB4F0] [C00000000002BF48] .CheckReturnCode+0xac/0xc4
[C00000003E8DB570] [C00000000002CAA4] .iSeries_Read_Long+0x160/0x19c
[C00000003E8DB620] [D0000000002215A0] .lpfc_sli_brdrestart+0xc8/0x1c0 [lpfc]
[C00000003E8DB6C0] [D00000000022170C] .lpfc_sli_hba_setup+0x74/0x3e0 [lpfc]
[C00000003E8DB770] [D0000000002348C0] .lpfc_pci_probe_one+0x650/0xa7c [lpfc]
[C00000003E8DB830] [C000000000196D00] .pci_device_probe+0x80/0xc4
[C00000003E8DB8C0] [C0000000001B0A24] .driver_probe_device+0xa0/0x15c
[C00000003E8DB960] [C0000000001B0CB4] .__driver_attach+0xdc/0x164
[C00000003E8DB9F0] [C0000000001B0158] .bus_for_each_dev+0x7c/0xd4
[C00000003E8DBAB0] [C0000000001B08C8] .driver_attach+0x28/0x40
[C00000003E8DBB30] [C0000000001AFBF8] .bus_add_driver+0x90/0x170
[C00000003E8DBBD0] [C0000000001B10E4] .driver_register+0xbc/0xd8
[C00000003E8DBC60] [C000000000196ADC] .__pci_register_driver+0x8c/0xd8
[C00000003E8DBD00] [D00000000023E024] .lpfc_init+0x60/0x282c [lpfc]
[C00000003E8DBD90] [C00000000005C5E4] .sys_init_module+0x1e4/0x448
Great news is that 2.6.5 does it that way:
nst-sys:/ # modprobe -v lpfc
insmod /lib/modules/2.6.5-override-iseries64/initrd/scsi_transport_fc.ko
insmod /lib/modules/2.6.5-override-iseries64/initrd/lpfc.ko
Kernel panic: PCI: Hardware I/O Error, SRC B6000103, Automatic Reboot Disabled.
^ permalink raw reply
* Re: [PATCH] powerpc: iSeries has only 256 IRQs
From: Olaf Hering @ 2006-04-04 19:02 UTC (permalink / raw)
To: Doug Maxey; +Cc: Stephen Rothwell, paulus, linuxppc-dev
In-Reply-To: <200604041855.k34ItP00022551@falcon10.austin.ibm.com>
On Tue, Apr 04, Doug Maxey wrote:
> What firmware level?
Of the card? No idea. At some point I had to upgrade it to make it
usable with lpfc in SLES9 SP2. But right now I couldnt upgrade it, kind
of chicken/egg problem. Driver has to be loaded to upgrade the firmware.
I will try to put that card into another box to upgrade the firmware.
I think the irq change itself is not the cause for the crash here.
^ permalink raw reply
* Re: [PATCH] powerpc: iSeries has only 256 IRQs
From: Doug Maxey @ 2006-04-04 19:08 UTC (permalink / raw)
To: Olaf Hering; +Cc: Stephen Rothwell, paulus, linuxppc-dev
In-Reply-To: <20060404190211.GA26830@suse.de>
On Tue, 04 Apr 2006 21:02:11 +0200, Olaf Hering wrote:
> On Tue, Apr 04, Doug Maxey wrote:
>
>> What firmware level?
>
>Of the card? No idea. At some point I had to upgrade it to make it
Both the card and the system level please. Sorry if missed the info.
>usable with lpfc in SLES9 SP2. But right now I couldnt upgrade it, kind
>of chicken/egg problem. Driver has to be loaded to upgrade the firmware.
>I will try to put that card into another box to upgrade the firmware.
>
>I think the irq change itself is not the cause for the crash here.
>
^ permalink raw reply
* Re: [PATCH] powerpc: iSeries has only 256 IRQs
From: Doug Maxey @ 2006-04-04 18:55 UTC (permalink / raw)
To: Olaf Hering; +Cc: Stephen Rothwell, paulus, linuxppc-dev
In-Reply-To: <20060404183442.GA25986@suse.de>
On Tue, 04 Apr 2006 20:34:42 +0200, Olaf Hering wrote:
>Great news is that 2.6.5 does it that way:
>
>nst-sys:/ # modprobe -v lpfc
>insmod /lib/modules/2.6.5-override-iseries64/initrd/scsi_transport_fc.ko
>insmod /lib/modules/2.6.5-override-iseries64/initrd/lpfc.ko
>Kernel panic: PCI: Hardware I/O Error, SRC B6000103, Automatic Reboot Disabled.
>
What firmware level?
++doug
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox