* 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: [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: 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: 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: [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: [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: _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: _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
* [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
* [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
* 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
* 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
* [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: [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
* 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
* 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
* 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
* 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
* 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: Segher Boessenkool @ 2006-04-03 23:16 UTC (permalink / raw)
To: Kumar Gala; +Cc: paulus, linuxppc-dev
In-Reply-To: <1078253E-4B9E-4432-86E3-82B01A4B68D1@kernel.crashing.org>
>> 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?
Segher
^ permalink raw reply
* Re: where do applications get loaded in virtual memory on a 4xx?
From: Eugene Surovegin @ 2006-04-03 22:17 UTC (permalink / raw)
To: Ralph Blach; +Cc: Linuxppc-embedded
In-Reply-To: <b06339d40604030546u4d6192faubca0c63cbaaef741@mail.gmail.com>
On Mon, Apr 03, 2006 at 08:46:13AM -0400, Ralph Blach wrote:
> I would like to know where in virtual memory application get loaded.
> I can do an NM and see the address in an a.out file? How do these address
> actually translate to 4xx virtual address?
There is nothing 4xx specific here.
cat /proc/<pid>/maps
--
Eugene
^ permalink raw reply
* Can't get serial SMC1 and SMC2 working together
From: Kenneth Poole @ 2006-04-03 21:05 UTC (permalink / raw)
To: linuxppc-embedded
>I'm using a TQM823L board, ELDK and Linux 2.4.25 (from denx). My
>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
required for your specific board.
Ken Poole
MRV Communications, INC.
^ permalink raw reply
* Re: Fw: 2.6.16 crashes when running numastat on p575
From: Andrew Morton @ 2006-04-03 21:18 UTC (permalink / raw)
To: Christoph Lameter; +Cc: linuxppc-dev, pj, ntl, ak, linux-kernel
In-Reply-To: <Pine.LNX.4.64.0604031104110.20903@schroedinger.engr.sgi.com>
Christoph Lameter <clameter@sgi.com> wrote:
>
> On Mon, 3 Apr 2006, Nathan Lynch wrote:
>
> > > There are many other for_each_*_cpu loops in the kernel that do not have
> > > any of the instrumentation you suggest. I suggest you come up with a
> > > general solution and then go through all of them and fix this. Please be
> > > aware that many of these loops are performance critical.
> >
> > But this one isn't, right?
>
> Right. One could use more expensive processing here.
Hopefully none of the for_each_foo() loops are performance-critical - those
things are expensive.
> > And I'm afraid there's a misunderstanding here -- only
> > for_each_online_cpu (or accessing the cpu online map in general) has
> > such restrictions -- for_each_possible_cpu doesn't require any locking
> > or preempt tricks since cpu_possible_map must not change after boot.
for_each_present_cpu() presumably has the same problems.
> Correct. We may want to audit the kernel and check that each
> for_each_possible_cpu or for_each_cpu is really correct.
A fair bit of that has been happening in recent weeks.
But yes, we should be protecting these things with rcu_read_lock() if
possible, lock_cpu_hotplug() otherwise.
(rcu_read_lock() might not be the appropriate name for this operation -
maybe it should be an open-coded preempt_disable(). Or some other suitably
named alias; dunno).
^ permalink raw reply
* Re: _machine removal breaks kexec?
From: Haren Myneni @ 2006-04-03 18:18 UTC (permalink / raw)
To: Kumar Gala; +Cc: paulus, linuxppc-dev
In-Reply-To: <1078253E-4B9E-4432-86E3-82B01A4B68D1@kernel.crashing.org>
[-- Attachment #1: Type: text/plain, Size: 1466 bytes --]
Kumar Gala wrote:
>On Apr 3, 2006, at 11:16 AM, Benjamin Herrenschmidt wrote:
>
>
>
>>On Mon, 2006-04-03 at 11:40 +1000, Anton Blanchard wrote:
>>
>>
>>>Hi,
>>>
>>>It looks like the _machine removal broke kexec:
>>>
>>> # kexec -l vmlinux
>>> /proc/device-tree/chosen/linux,platform: No such file or directory
>>>
>>>The kexec tools seem to want the linux,platform property:
>>>
>>> /* if LPAR, no need to read any more from /chosen */
>>> if (platform != PLATFORM_PSERIES) {
>>> closedir(cdir);
>>> continue;
>>> }
>>>
>>>
>>Damn.... the platform numbers are gone, we need to fix that. (And
>>nobody
>>complained when I posted the patch twice over the past couple of
>>monthes
>>btw).
>>
>>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.
>
>
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.
Kumar, kexec-tools completely depends on device-tree. Not sure whether
the embedded system exports the device-tree.
Thanks
Haren
>- k
>_______________________________________________
>Linuxppc-dev mailing list
>Linuxppc-dev@ozlabs.org
>https://ozlabs.org/mailman/listinfo/linuxppc-dev
>
>
[-- Attachment #2: ppc64-kexec-tools-rm-platform-fix.patch --]
[-- Type: text/x-patch, Size: 1621 bytes --]
--- ./kexec-tools-1.101/kexec/arch/ppc64/kexec-ppc64.c.orig 2006-04-07 17:39:08.000000000 -0700
+++ ./kexec-tools-1.101/kexec/arch/ppc64/kexec-ppc64.c 2006-04-07 17:36:34.000000000 -0700
@@ -40,7 +40,7 @@
static struct exclude_range exclude_range[MAX_MEMORY_RANGES];
static unsigned long long rmo_top;
-static unsigned int platform;
+static unsigned int platform = PLATFORM_PSERIES_LPAR;
static struct memory_range memory_range[MAX_MEMORY_RANGES];
static struct memory_range base_memory_range[MAX_MEMORY_RANGES];
unsigned long long memory_max = 0;
@@ -179,8 +179,13 @@ static int get_devtree_details(unsigned
DIR *dir, *cdir;
FILE *file;
struct dirent *dentry;
+ struct stat sbuf;
+
int n, i = 0;
+ if (!stat("/proc/device-tree/chosen/linux,htab-base", &sbuf))
+ platform = PLATFORM_PSERIES;
+
if ((dir = opendir(device_tree)) == NULL) {
perror(device_tree);
return -1;
@@ -201,26 +206,6 @@ static int get_devtree_details(unsigned
}
if (strncmp(dentry->d_name, "chosen", 6) == 0) {
- /* get platform details from /chosen node */
- strcat(fname, "/linux,platform");
- if ((file = fopen(fname, "r")) == NULL) {
- perror(fname);
- closedir(cdir);
- closedir(dir);
- return -1;
- }
- if (fread(&platform, sizeof(int), 1, file) != 1) {
- perror(fname);
- fclose(file);
- closedir(cdir);
- closedir(dir);
- return -1;
- }
- fclose(file);
-
- memset(fname, 0, sizeof(fname));
- strcpy(fname, device_tree);
- strcat(fname, dentry->d_name);
strcat(fname, "/linux,kernel-end");
if ((file = fopen(fname, "r")) == NULL) {
perror(fname);
^ permalink raw reply
* Re: Fw: 2.6.16 crashes when running numastat on p575
From: Christoph Lameter @ 2006-04-03 18:08 UTC (permalink / raw)
To: Nathan Lynch; +Cc: akpm, linuxppc-dev, pj, ak, linux-kernel
In-Reply-To: <20060403180131.GD25663@localdomain>
On Mon, 3 Apr 2006, Nathan Lynch wrote:
> > There are many other for_each_*_cpu loops in the kernel that do not have
> > any of the instrumentation you suggest. I suggest you come up with a
> > general solution and then go through all of them and fix this. Please be
> > aware that many of these loops are performance critical.
>
> But this one isn't, right?
Right. One could use more expensive processing here.
> And I'm afraid there's a misunderstanding here -- only
> for_each_online_cpu (or accessing the cpu online map in general) has
> such restrictions -- for_each_possible_cpu doesn't require any locking
> or preempt tricks since cpu_possible_map must not change after boot.
Correct. We may want to audit the kernel and check that each
for_each_possible_cpu or for_each_cpu is really correct. Developers
frequently assume that all processors are up. There may be some
complicated interactions with cpusets. Adding Paul to this.
However, note that I am not interested hotplug functionality. It is going
to be a difficult task to make the kernel shutdown processors correctly. I
can give you feedback but I am not going to do this work.
^ 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