* Re: [PATCH v3 7/12] Use stop machine to update cpu maps
From: Nathan Fontenot @ 2013-04-23 18:58 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: linuxppc-dev
In-Reply-To: <1366676688.2886.5.camel@pasglop>
On 04/22/2013 07:24 PM, Benjamin Herrenschmidt wrote:
> On Mon, 2013-04-22 at 13:41 -0500, Nathan Fontenot wrote:
>> From: Jesse Larrew <jlarrew@linux.vnet.ibm.com>
>>
>> Platform events such as partition migration or the new PRRN firmware
>> feature can cause the NUMA characteristics of a CPU to change, and these
>> changes will be reflected in the device tree nodes for the affected
>> CPUs.
>>
>> This patch registers a handler for Open Firmware device tree updates
>> and reconfigures the CPU and node maps whenever the associativity
>> changes. Currently, this is accomplished by marking the affected CPUs in
>> the cpu_associativity_changes_mask and allowing
>> arch_update_cpu_topology() to retrieve the new associativity information
>> using hcall_vphn().
>>
>> Protecting the NUMA cpu maps from concurrent access during an update
>> operation will be addressed in a subsequent patch in this series.
>
> I see no more mention of stop_machine() ... is the patch subject stale ?
>
Nope, just me mistakenly putting the wrong subject for this patch. I'll
correct it in the next version.
-Nathan
^ permalink raw reply
* Re: [PATCH v3 5/12] Update firmware_has_feature() to check architecture bits
From: Nathan Fontenot @ 2013-04-23 18:56 UTC (permalink / raw)
To: Stephen Rothwell; +Cc: linuxppc-dev
In-Reply-To: <20130423115002.3d321e6a69ed97d134127a2b@canb.auug.org.au>
On 04/22/2013 08:50 PM, Stephen Rothwell wrote:
> Hi Nathan,
>
> On Mon, 22 Apr 2013 13:38:47 -0500 Nathan Fontenot <nfont@linux.vnet.ibm.com> wrote:
>>
>> -/* Option vector 5: PAPR/OF options supported */
>> -#define OV5_LPAR 0x80 /* logical partitioning supported */
>> -#define OV5_SPLPAR 0x40 /* shared-processor LPAR supported */
>> +/* Option vector 5: PAPR/OF options supported
>> + * Thses bits are also used for the platform_has_feature() call so
> ^^^^^
> typo
will fix.
>
>> + * we encode the vector index in the define and use the OV5_FEAT()
>> + * and OV5_INDX() macros to extract the desired information.
>> + */
>> +#define OV5_FEAT(x) ((x) & 0xff)
>> +#define OV5_INDX(x) ((x) >> 8)
>> +#define OV5_LPAR 0x0280 /* logical partitioning supported */
>> +#define OV5_SPLPAR 0x0240 /* shared-processor LPAR supported */
>
> Wouldn't it be clearer to say
>
> #define OV5_LPAR (OV5_INDX(0x2) | OV5_FEAT(0x80))
The defines won't work the way you used them, they were designed to take the
combined value, i.e. 0x0280, and parse out the index and the feature.
I do think having macros to create the actual values as your example does is easier
to read. We could do something like...
#define OV5_FEAT(x) ((x) & 0xff)
#define OV5_SETINDX(x) ((x) << 8)
#define OV5_GETINDX(x) ((x) >> 8)
#define OV5_LPAR (OV5_SETINDX(0x2) | OV5_FEAT(0x80))
Thoughts?
>
> etc?
>
>> @@ -145,6 +141,7 @@
>> * followed by # option vectors - 1, followed by the option vectors.
>> */
>> extern unsigned char ibm_architecture_vec[];
>> +bool platform_has_feature(unsigned int);
>
> "extern", please (if nothing else, for consistency).
>
That shouldn't really be there, its an artifact from a previous patch. I'll remove it.
>> +static __initdata struct vec5_fw_feature
>> +vec5_fw_features_table[FIRMWARE_MAX_FEATURES] = {
>
> Why make this array FIRMWARE_MAX_FEATURES (63) long? You could just
> restrict the for loop below to ARRAY_SIZE(vec5_fw_features_table).
>
>> + {FW_FEATURE_TYPE1_AFFINITY, OV5_TYPE1_AFFINITY},
>> +};
>> +
>> +void __init fw_vec5_feature_init(const char *vec5, unsigned long len)
>> +{
>> + unsigned int index, feat;
>> + int i;
>> +
>> + pr_debug(" -> fw_vec5_feature_init()\n");
>> +
>> + for (i = 0; i < FIRMWARE_MAX_FEATURES; i++) {
>> + if (!vec5_fw_features_table[i].feature)
>> + continue;
>
> And this test could go away.
>
> I realise that you have just copied the existing code, but you should not
> do that blindly. Maybe you could even add an (earlier) patch that fixes
> the existing code.
I think that could be done easily enough.
Thanks for looking,
-Nathan
^ permalink raw reply
* Re: [PATCH v3 1/12] Create a powerpc update_devicetree interface
From: Nathan Fontenot @ 2013-04-23 18:46 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: linuxppc-dev
In-Reply-To: <1366676147.2886.2.camel@pasglop>
On 04/22/2013 07:15 PM, Benjamin Herrenschmidt wrote:
> On Mon, 2013-04-22 at 13:30 -0500, Nathan Fontenot wrote:
>
>> This patch exposes a method for updating the device tree via
>> ppc_md.update_devicetree that takes a single 32-bit value as a parameter.
>> For pseries platforms this is the existing pseries_devicetree_update routine
>> which is updated to take the new parameter which is a scope value
>> to indicate the the reason for making the rtas calls. This parameter is
>> required by the ibm,update-nodes/ibm,update-properties RTAS calls, and
>> the appropriate value is contained within the RTAS event for PRRN
>> notifications. In pseries_devicetree_update() it was previously
>> hard-coded to 1, the scope value for partition migration.
>
> I think that's too much abstraction.... (see below)
>
> Also you add this helper:
>
>> Index: powerpc/arch/powerpc/kernel/rtas.c
>> ===================================================================
>> --- powerpc.orig/arch/powerpc/kernel/rtas.c 2013-03-08 19:23:06.000000000 -0600
>> +++ powerpc/arch/powerpc/kernel/rtas.c 2013-04-17 13:02:29.000000000 -0500
>> @@ -1085,3 +1085,13 @@
>> timebase = 0;
>> arch_spin_unlock(&timebase_lock);
>> }
>> +
>> +int update_devicetree(s32 scope)
>> +{
>> + int rc = 0;
>> +
>> + if (ppc_md.update_devicetree)
>> + rc = ppc_md.update_devicetree(scope);
>> +
>> + return rc;
>> +}
>
> But then don't use it afaik (you call directly ppc_md.update_... from
> prrn_work_fn().
>
> In the end, the caller (PRRN stuff), while in rtasd, is really pseries
> specific and the resulting update_device_tree() as well, so I don't
> think we need the ppc_md. hook in the middle with that "oddball" scope
> parameter which is not defined outside of pseries specific areas.
>
> In this case, it might be better to make sure the PRRN related stuff in
> rtasd is inside an ifdef CONFIG_PPC_PSERIES and have it call directly
> into pseries_update_devicetree().
>
> It makes the code somewhat easier to follow and I doubt anybody else
> will ever use that specific hook, at least not in its current form. If
> we need an abstraction later, we can add one then.
>
ok, good. I was not crazy about using ppc_md to do this and if you're fine
with putting the pseries specific stuff in ifdef CONFIG_PPC_PSERIES I'll
update the code to do that.
Question concerning rtas code. There is quite a bit of pseries specific
pieces in the general powerpc/kernel directory. Has there been, or should
there be, any effort to move that to the pseries directory?
-Nathan
^ permalink raw reply
* Re: PROBLEM: Only 2 of 4 cores used on IBM Cell blades and no threads shown in spufs
From: Dennis Schridde @ 2013-04-23 18:13 UTC (permalink / raw)
To: Michael Ellerman; +Cc: cbe-oss-dev, linuxppc-dev, arnd
In-Reply-To: <20130423132436.GB1078@concordia>
[-- Attachment #1: Type: text/plain, Size: 460 bytes --]
Am Dienstag, 23. April 2013, 23:24:36 schrieb Michael Ellerman:
> On Mon, Apr 22, 2013 at 06:44:13PM +0200, Dennis Schridde wrote:
> > [1.] One line summary of the problem:
> > .. no threads shown in spufs
>
> So I think I've got this one fixed, this works for me, can you test it
> please?
Patch works - spu-top outputs threads and there are directories in /spu now.
Please also backport this to 3.8, just like the IRQ and NUMA patches. :)
Thanks!
--Dennis
[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 198 bytes --]
^ permalink raw reply
* Re: [PATCH 5/5] powerpc/powernv: TCE invalidation for PHB3
From: Benjamin Herrenschmidt @ 2013-04-23 15:25 UTC (permalink / raw)
To: Gavin Shan; +Cc: linuxppc-dev
In-Reply-To: <1366715034-24594-6-git-send-email-shangw@linux.vnet.ibm.com>
On Tue, 2013-04-23 at 19:03 +0800, Gavin Shan wrote:
> * of flags if that becomes the case
> */
> if (tbl->it_type & TCE_PCI_SWINV_CREATE)
> - pnv_tce_invalidate(tbl, tces, tcep - 1);
> + phb->dma_tce_invalidate(tbl, tces, tcep - 1);
>
> return 0;
> }
TCE invalidate is very performance sensitive, we might be better off
doing the if (ioda_type == PNV_PHB_IODA1) ... else ... here (which
the CPU can generally predict) rather than a function pointer call
which can be more tricky.
Cheers,
Ben.
^ permalink raw reply
* RE: [PATCH 2/3 v14] iommu/fsl: Add additional iommu attributes required by the PAMU driver.
From: Yoder Stuart-B08248 @ 2013-04-23 15:26 UTC (permalink / raw)
To: Joerg Roedel, Sethi Varun-B16395
Cc: Wood Scott-B07421, linux-kernel@vger.kernel.org,
iommu@lists.linux-foundation.org, linuxppc-dev@lists.ozlabs.org
In-Reply-To: <20130423133837.GG17148@8bytes.org>
> -----Original Message-----
> From: Joerg Roedel [mailto:joro@8bytes.org]
> Sent: Tuesday, April 23, 2013 8:39 AM
> To: Sethi Varun-B16395
> Cc: iommu@lists.linux-foundation.org; linuxppc-dev@lists.ozlabs.org; linu=
x-kernel@vger.kernel.org;
> galak@kernel.crashing.org; benh@kernel.crashing.org; Yoder Stuart-B08248;=
Wood Scott-B07421
> Subject: Re: [PATCH 2/3 v14] iommu/fsl: Add additional iommu attributes r=
equired by the PAMU driver.
>=20
> On Tue, Apr 23, 2013 at 10:05:25AM +0530, Varun Sethi wrote:
> > Added the following domain attributes for the FSL PAMU driver:
> > 1. Added new iommu stash attribute, which allows setting of the
> > LIODN specific stash id parameter through IOMMU API.
> > 2. Added an attribute for enabling/disabling DMA to a particular
> > memory window.
> > 3. Added domain attribute to check for PAMUV1 specific constraints.
> >
> > Signed-off-by: Varun Sethi <Varun.Sethi@freescale.com>
> > ---
> > v14 changes:
> > - Add FSL prefix to PAMU attributes.
> > v13 changes:
> > - created a new file include/linux/fsl_pamu_stash.h for stash
> > attributes.
> > v12 changes:
> > - Moved PAMU specifc stash ids and structures to PAMU header file.
> > - no change in v11.
> > - no change in v10.
> > include/linux/fsl_pamu_stash.h | 39 ++++++++++++++++++++++++++++++++=
+++++++
>=20
> Isn't asm/ for your architecture a better place for that header?
The PAMU isn't strictly tied to Power architecture, although
that is where it is implemented now. It could be implemented
on ARM for example.
Stuart
^ permalink raw reply
* Re: [PATCH 4/5] powerpc/powernv: Patch MSI EOI handler on P8
From: Benjamin Herrenschmidt @ 2013-04-23 15:21 UTC (permalink / raw)
To: Gavin Shan; +Cc: linuxppc-dev
In-Reply-To: <1366715034-24594-5-git-send-email-shangw@linux.vnet.ibm.com>
On Tue, 2013-04-23 at 19:03 +0800, Gavin Shan wrote:
>
> +static int pnv_pci_ioda_msi_eoi(struct pnv_phb *phb, unsigned int hw_irq)
> +{
> + u8 p_bit = 1, q_bit = 1;
> + long rc;
> +
> + while (p_bit || q_bit) {
> + rc = opal_pci_get_xive_reissue(phb->opal_id,
> + hw_irq - phb->msi_base, &p_bit, &q_bit);
> + if (rc) {
> + pr_warning("%s: Failed to get P/Q bits of IRQ#%d "
> + "on PHB#%d, rc=%ld\n", __func__, hw_irq,
> + phb->hose->global_number, rc);
> + return -EIO;
> + }
> + if (!p_bit && !q_bit)
> + break;
> +
> + rc = opal_pci_set_xive_reissue(phb->opal_id,
> + hw_irq - phb->msi_base, p_bit, q_bit);
> + if (rc) {
> + pr_warning("%s: Failed to clear P/Q (%01d/%01d) of "
> + "IRQ#%d on PHB#%d, rc=%ld\n", __func__,
> + p_bit, q_bit, hw_irq,
> + phb->hose->global_number, rc);
> + return -EIO;
> + }
> + }
> +
> + return 0;
> +}
Can you turn that into a single opal_pci_msi_eoi() ? This means that a
single MSI will trigger only one OPAL call rather than two which is
better for performances.
We will later implement an "optimized" variant using direct MMIO based
on knowing specifically the HW type but not now.
Cheers,
Ben.
^ permalink raw reply
* Re: [PATCH 1/5] powerpc/powernv: Supports PHB3
From: Benjamin Herrenschmidt @ 2013-04-23 15:19 UTC (permalink / raw)
To: Gavin Shan; +Cc: linuxppc-dev
In-Reply-To: <1366715034-24594-2-git-send-email-shangw@linux.vnet.ibm.com>
On Tue, 2013-04-23 at 19:03 +0800, Gavin Shan wrote:
> -/* Fixup wrong class code in p7ioc root complex */
> +/* Fixup wrong class code in p7ioc and p8 root complex */
> static void pnv_p7ioc_rc_quirk(struct pci_dev *dev)
> {
> dev->class = PCI_CLASS_BRIDGE_PCI << 8;
> }
> DECLARE_PCI_FIXUP_EARLY(PCI_VENDOR_ID_IBM, 0x3b9, pnv_p7ioc_rc_quirk);
> +DECLARE_PCI_FIXUP_EARLY(PCI_VENDOR_ID_IBM, 0x2da, pnv_p7ioc_rc_quirk);
>
This can go away from the normal patch, it is only necessary to work
around a problem in the simulator. The real PHB3 doesn't need the
workaround (p7ioc still does).
Cheers,
Ben.
^ permalink raw reply
* arch/powerpc/mm/mmap_64.c on 32bit systems?
From: Daniel Walker @ 2013-04-23 14:55 UTC (permalink / raw)
To: linuxppc-dev
Hi all,
I was looking at this file, and it looks like it could be used on 32bit
systems. There's patches in the history to add stuff accounting for both
32bits and 64bits .. My assumption was that it's not used because there
are many people who want it on 32bits, and so it hasn't been tested..
Can anyone shed some light on why it's not used for 32bit systems?
Thanks,
Daniel
^ permalink raw reply
* RE: [PATCH] powerpc/fsl-pci:fix incorrect iounmap pci hose->private_data
From: Zang Roy-R61911 @ 2013-04-23 14:54 UTC (permalink / raw)
To: Kumar Gala; +Cc: linuxppc-dev@lists.ozlabs.org, Chen Yuanquan-B41889
In-Reply-To: <5347FD51-61BF-44E7-A773-ACD8CAF44138@kernel.crashing.org>
> -----Original Message-----
> From: Linuxppc-dev [mailto:linuxppc-dev-bounces+tie-
> fei.zang=3Dfreescale.com@lists.ozlabs.org] On Behalf Of Kumar Gala
> Sent: Tuesday, April 23, 2013 10:29 PM
> To: Zang Roy-R61911
> Cc: linuxppc-dev@lists.ozlabs.org; Chen Yuanquan-B41889
> Subject: Re: [PATCH] powerpc/fsl-pci:fix incorrect iounmap pci hose-
> >private_data
>=20
>=20
> On Apr 23, 2013, at 12:44 AM, Zang Roy-R61911 wrote:
>=20
> >
> >
> >> -----Original Message-----
> >> From: Zang Roy-R61911
> >> Sent: Tuesday, April 23, 2013 2:36 AM
> >> To: linuxppc-dev@lists.ozlabs.org
> >> Cc: galak@kernel.crashing.org; Zang Roy-R61911; Chen Yuanquan-B41889
> >> Subject: [PATCH] powerpc/fsl-pci:fix incorrect iounmap pci hose-
> >>> private_data
> >>
> >> pci hose->private_data will be used by other function, for example,
> >> fsl_pcie_check_link(), so do not iounmap it.
> >>
> >> fix the kerenl crash on T4240:
> >>
> >> Unable to handle kernel paging request for data at address
> >> 0x8000080080060f14
> >> Faulting instruction address: 0xc000000000032554
> >> Oops: Kernel access of bad area, sig: 11 [#1] SMP NR_CPUS=3D24 T4240
> >> QDS Modules linked in:
> >> NIP: c000000000032554 LR: c00000000003254c CTR: c00000000001e5c0
> >> REGS: c000000179143440 TRAP: 0300 Not tainted
> >> (3.8.8-rt2-00754-g951f064-dirt)
> >> MSR: 0000000080029000 <CE,EE,ME> CR: 24adbe22 XER: 00000000
> >> SOFTE: 0
> >> DEAR: 8000080080060f14, ESR: 0000000000000000 TASK =3D
> >> c00000017913d2c0[1] 'swapper/0' THREAD: c000000179140000 CPU: 2
> >> GPR00: c00000000003254c c0000001791436c0 c000000000ae2998
> >> 0000000000000027
> >> GPR04: 0000000000000000 00000000000005a5 0000000000000000
> >> 0000000000000002
> >> GPR08: 3030303038303038 c000000000a2d4d0 c000000000aebeb8
> >> c000000000af2998
> >> GPR12: 0000000024adbe22 c00000000fffa800 c000000000001be0
> >> 0000000000000000
> >> GPR16: 0000000000000000 0000000000000000 0000000000000000
> >> 0000000000000000
> >> GPR20: 0000000000000000 0000000000000000 0000000000000000
> >> c0000000009ddf70
> >> GPR24: c0000000009e8d40 c000000000af2998 c000000000b1529c
> >> c000000179143b40
> >> GPR28: c0000001799b4000 c000000179143c00 8000080080060000
> >> c000000000727ec8
> >> NIP [c000000000032554] .fsl_pcie_check_link+0x104/0x150 LR
> >> [c00000000003254c] .fsl_pcie_check_link+0xfc/0x150 Call Trace:
> >> [c0000001791436c0] [c00000000003254c] .fsl_pcie_check_link+0xfc/0x150
> >> (unreliab)
> >> [c000000179143a30] [c0000000000325d4]
> >> .fsl_indirect_read_config+0x34/0xb0
> >> [c000000179143ad0] [c0000000002c7ee8]
> >> .pci_bus_read_config_byte+0x88/0xd0
> >> [c000000179143b90] [c0000000009c0528]
> >> .pci_apply_final_quirks+0x9c/0x18c
> >> [c000000179143c40] [c00000000000142c] .do_one_initcall+0x5c/0x1f0
> >> [c000000179143cf0] [c0000000009a0bb4]
> >> .kernel_init_freeable+0x180/0x264 [c000000179143db0]
> >> [c000000000001bfc] .kernel_init+0x1c/0x420 [c000000179143e30]
> >> [c0000000000008b4] .ret_from_kernel_thread+0x64/0xb0 Instruction dump:
> >> 60000000 4bffffa0 ebc301d0 3fe2ffc4 3c62ffe0 3bff5530 38638a78
> >> 7fe4fb78
> >> 7fc5f378 486ea77d 60000000 7c0004ac <801e0f14> 0c000000 4c00012c
> >> 3c62ffe0 ---[ end trace f841fbc03c9d2e1b ]---
> >>
> >> Kernel panic - not syncing: Attempted to kill init!
> >> exitcode=3D0x0000000b
> >>
> >> Rebooting in 180 seconds..
> >>
> >> Signed-off-by: Yuanquan Chen <Yuanquan.Chen@freescale.com>
> >> Signed-off-by: Roy Zang <tie-fei.zang@freescale.com>
> >> ---
> >> based on Kumar's next branch.
> >> tested on P3041 and T4240.
> > Please ignore this patch, I will send a v2 version.
> > Thanks.
> > Roy
>=20
> Ok, did you see this patch:
>=20
> http://patchwork.ozlabs.org/patch/236293/
Kevin remaindered me after I sent the v2 version.
You can pick up that one.
I add a ack to that patch.
Roy
^ permalink raw reply
* Re: [PATCH] powerpc/fsl-pci:fix incorrect iounmap pci hose->private_data
From: Kumar Gala @ 2013-04-23 14:29 UTC (permalink / raw)
To: Zang Roy-R61911; +Cc: linuxppc-dev@lists.ozlabs.org, Chen Yuanquan-B41889
In-Reply-To: <3E027F8168735B46AC006B1D0C7BB0020B1B3930@039-SN2MPN1-013.039d.mgd.msft.net>
On Apr 23, 2013, at 12:44 AM, Zang Roy-R61911 wrote:
>
>
>> -----Original Message-----
>> From: Zang Roy-R61911
>> Sent: Tuesday, April 23, 2013 2:36 AM
>> To: linuxppc-dev@lists.ozlabs.org
>> Cc: galak@kernel.crashing.org; Zang Roy-R61911; Chen Yuanquan-B41889
>> Subject: [PATCH] powerpc/fsl-pci:fix incorrect iounmap pci hose-
>>> private_data
>>
>> pci hose->private_data will be used by other function, for example,
>> fsl_pcie_check_link(), so do not iounmap it.
>>
>> fix the kerenl crash on T4240:
>>
>> Unable to handle kernel paging request for data at address
>> 0x8000080080060f14
>> Faulting instruction address: 0xc000000000032554
>> Oops: Kernel access of bad area, sig: 11 [#1] SMP NR_CPUS=24 T4240 QDS
>> Modules linked in:
>> NIP: c000000000032554 LR: c00000000003254c CTR: c00000000001e5c0
>> REGS: c000000179143440 TRAP: 0300 Not tainted
>> (3.8.8-rt2-00754-g951f064-dirt)
>> MSR: 0000000080029000 <CE,EE,ME> CR: 24adbe22 XER: 00000000
>> SOFTE: 0
>> DEAR: 8000080080060f14, ESR: 0000000000000000 TASK = c00000017913d2c0[1]
>> 'swapper/0' THREAD: c000000179140000 CPU: 2
>> GPR00: c00000000003254c c0000001791436c0 c000000000ae2998
>> 0000000000000027
>> GPR04: 0000000000000000 00000000000005a5 0000000000000000
>> 0000000000000002
>> GPR08: 3030303038303038 c000000000a2d4d0 c000000000aebeb8
>> c000000000af2998
>> GPR12: 0000000024adbe22 c00000000fffa800 c000000000001be0
>> 0000000000000000
>> GPR16: 0000000000000000 0000000000000000 0000000000000000
>> 0000000000000000
>> GPR20: 0000000000000000 0000000000000000 0000000000000000
>> c0000000009ddf70
>> GPR24: c0000000009e8d40 c000000000af2998 c000000000b1529c
>> c000000179143b40
>> GPR28: c0000001799b4000 c000000179143c00 8000080080060000
>> c000000000727ec8
>> NIP [c000000000032554] .fsl_pcie_check_link+0x104/0x150 LR
>> [c00000000003254c] .fsl_pcie_check_link+0xfc/0x150 Call Trace:
>> [c0000001791436c0] [c00000000003254c] .fsl_pcie_check_link+0xfc/0x150
>> (unreliab)
>> [c000000179143a30] [c0000000000325d4]
>> .fsl_indirect_read_config+0x34/0xb0
>> [c000000179143ad0] [c0000000002c7ee8]
>> .pci_bus_read_config_byte+0x88/0xd0
>> [c000000179143b90] [c0000000009c0528] .pci_apply_final_quirks+0x9c/0x18c
>> [c000000179143c40] [c00000000000142c] .do_one_initcall+0x5c/0x1f0
>> [c000000179143cf0] [c0000000009a0bb4] .kernel_init_freeable+0x180/0x264
>> [c000000179143db0] [c000000000001bfc] .kernel_init+0x1c/0x420
>> [c000000179143e30] [c0000000000008b4] .ret_from_kernel_thread+0x64/0xb0
>> Instruction dump:
>> 60000000 4bffffa0 ebc301d0 3fe2ffc4 3c62ffe0 3bff5530 38638a78 7fe4fb78
>> 7fc5f378 486ea77d 60000000 7c0004ac <801e0f14> 0c000000 4c00012c 3c62ffe0
>> ---[ end trace f841fbc03c9d2e1b ]---
>>
>> Kernel panic - not syncing: Attempted to kill init! exitcode=0x0000000b
>>
>> Rebooting in 180 seconds..
>>
>> Signed-off-by: Yuanquan Chen <Yuanquan.Chen@freescale.com>
>> Signed-off-by: Roy Zang <tie-fei.zang@freescale.com>
>> ---
>> based on Kumar's next branch.
>> tested on P3041 and T4240.
> Please ignore this patch, I will send a v2 version.
> Thanks.
> Roy
Ok, did you see this patch:
http://patchwork.ozlabs.org/patch/236293/
- k
^ permalink raw reply
* [PATCH v2 2/2] powerpc/rtas_flash: New return code to indicate FW entitlement expiry
From: Vasant Hegde @ 2013-04-23 14:22 UTC (permalink / raw)
To: linuxppc-dev
In-Reply-To: <20130423141958.25932.5791.stgit@hegdevasant>
Add new return code to rtas_flash to indicate firmware entitlement
expiry. Strictly we don't need this update. But to keep it in sync
with PAPR, this was added.
Signed-off-by: Ananth N Mavinakayanahalli <ananth@in.ibm.com>
Signed-off-by: Vasant Hegde <hegdevasant@linux.vnet.ibm.com>
---
arch/powerpc/kernel/rtas_flash.c | 5 +++++
1 file changed, 5 insertions(+)
diff --git a/arch/powerpc/kernel/rtas_flash.c b/arch/powerpc/kernel/rtas_flash.c
index bc97a21..a3e4034 100644
--- a/arch/powerpc/kernel/rtas_flash.c
+++ b/arch/powerpc/kernel/rtas_flash.c
@@ -77,6 +77,11 @@
* T side will be updated with a downlevel image
*/
#define VALIDATE_TMP_UPDATE_DL 6
+/*
+ * The candidate image's release date is later than the system's firmware
+ * service entitlement date - service warranty period has expired
+ */
+#define VALIDATE_OUT_OF_WRNTY 7
/* ibm,manage-flash-image operation tokens */
#define RTAS_REJECT_TMP_IMG 0
^ permalink raw reply related
* [PATCH v2 1/2] powerpc/rtas_flash: Update return token comments
From: Vasant Hegde @ 2013-04-23 14:20 UTC (permalink / raw)
To: linuxppc-dev
Add proper comment to ibm,validate-flash-image RTAS call
update result tokens.
Note: Only comment section is modified, no code change.
Signed-off-by: Vasant Hegde <hegdevasant@linux.vnet.ibm.com>
Signed-off-by: Ananth N Mavinakayanahalli <ananth@in.ibm.com>
---
arch/powerpc/kernel/rtas_flash.c | 27 ++++++++++++++++++++-------
1 file changed, 20 insertions(+), 7 deletions(-)
diff --git a/arch/powerpc/kernel/rtas_flash.c b/arch/powerpc/kernel/rtas_flash.c
index a7020d2..bc97a21 100644
--- a/arch/powerpc/kernel/rtas_flash.c
+++ b/arch/powerpc/kernel/rtas_flash.c
@@ -57,13 +57,26 @@
#define VALIDATE_READY -1001 /* Firmware image ready for validation */
#define VALIDATE_PARAM_ERR -3 /* RTAS Parameter Error */
#define VALIDATE_HW_ERR -1 /* RTAS Hardware Error */
-#define VALIDATE_TMP_UPDATE 0 /* Validate Return Status */
-#define VALIDATE_FLASH_AUTH 1 /* Validate Return Status */
-#define VALIDATE_INVALID_IMG 2 /* Validate Return Status */
-#define VALIDATE_CUR_UNKNOWN 3 /* Validate Return Status */
-#define VALIDATE_TMP_COMMIT_DL 4 /* Validate Return Status */
-#define VALIDATE_TMP_COMMIT 5 /* Validate Return Status */
-#define VALIDATE_TMP_UPDATE_DL 6 /* Validate Return Status */
+
+/* ibm,validate-flash-image update result tokens */
+#define VALIDATE_TMP_UPDATE 0 /* T side will be updated */
+#define VALIDATE_FLASH_AUTH 1 /* Partition does not have authority */
+#define VALIDATE_INVALID_IMG 2 /* Candidate image is not valid */
+#define VALIDATE_CUR_UNKNOWN 3 /* Current fixpack level is unknown */
+/*
+ * Current T side will be committed to P side before being replace with new
+ * image, and the new image is downlevel from current image
+ */
+#define VALIDATE_TMP_COMMIT_DL 4
+/*
+ * Current T side will be committed to P side before being replaced with new
+ * image
+ */
+#define VALIDATE_TMP_COMMIT 5
+/*
+ * T side will be updated with a downlevel image
+ */
+#define VALIDATE_TMP_UPDATE_DL 6
/* ibm,manage-flash-image operation tokens */
#define RTAS_REJECT_TMP_IMG 0
^ permalink raw reply related
* [RFC, PATCH] powerpc/prom: Scan reserved-ranges node for memory reservations
From: Jeremy Kerr @ 2013-04-23 14:19 UTC (permalink / raw)
To: linuxppc-dev
Based on benh's proposal at
https://lists.ozlabs.org/pipermail/linuxppc-dev/2012-September/101237.html,
this change provides support for reserving memory from the
reserved-ranges node at the root of the device tree.
We just call memblock_reserve on these ranges for now.
Signed-off-by: Jeremy Kerr <jk@ozlabs.org>
---
arch/powerpc/kernel/prom.c | 36 ++++++++++++++++++++++++++++++++++++
1 file changed, 36 insertions(+)
diff --git a/arch/powerpc/kernel/prom.c b/arch/powerpc/kernel/prom.c
index 8b6f7a9..1208c8f 100644
--- a/arch/powerpc/kernel/prom.c
+++ b/arch/powerpc/kernel/prom.c
@@ -559,6 +559,34 @@ void __init early_init_dt_setup_initrd_arch(unsigned long start,
}
#endif
+static bool __init early_reserve_mem_dt(void)
+{
+ unsigned long i, len, dt_root;
+ const __be32 *prop;
+
+ dt_root = ((unsigned long)initial_boot_params) +
+ be32_to_cpu(initial_boot_params->off_dt_struct);
+
+ prop = of_get_flat_dt_prop(dt_root, "reserved-ranges", &len);
+
+ if (!prop)
+ return false;
+
+ /* Each reserved range is an (address,size) pair, 2 cells each */
+ for (i = 0; i < len / sizeof(*prop);
+ i += dt_root_addr_cells + dt_root_size_cells) {
+ u64 base, size;
+
+ base = of_read_number(prop + (i * 4), 2);
+ size = of_read_number(prop + (i * 4) + 2, 2);
+
+ if (size)
+ memblock_reserve(base, size);
+ }
+
+ return true;
+}
+
static void __init early_reserve_mem(void)
{
u64 base, size;
@@ -574,6 +602,14 @@ static void __init early_reserve_mem(void)
self_size = initial_boot_params->totalsize;
memblock_reserve(self_base, self_size);
+ /*
+ * Try looking for reserved-regions property in the DT first; if
+ * it's present, it'll contain all of the necessary reservation
+ * info
+ */
+ if (early_reserve_mem_dt())
+ return;
+
#ifdef CONFIG_BLK_DEV_INITRD
/* then reserve the initrd, if any */
if (initrd_start && (initrd_end > initrd_start))
^ permalink raw reply related
* RE: [PATCH 2/3 v14] iommu/fsl: Add additional iommu attributes required by the PAMU driver.
From: Sethi Varun-B16395 @ 2013-04-23 14:10 UTC (permalink / raw)
To: Joerg Roedel
Cc: Wood Scott-B07421, linux-kernel@vger.kernel.org,
Yoder Stuart-B08248, iommu@lists.linux-foundation.org,
linuxppc-dev@lists.ozlabs.org
In-Reply-To: <20130423133837.GG17148@8bytes.org>
> -----Original Message-----
> From: Joerg Roedel [mailto:joro@8bytes.org]
> Sent: Tuesday, April 23, 2013 7:09 PM
> To: Sethi Varun-B16395
> Cc: iommu@lists.linux-foundation.org; linuxppc-dev@lists.ozlabs.org;
> linux-kernel@vger.kernel.org; galak@kernel.crashing.org;
> benh@kernel.crashing.org; Yoder Stuart-B08248; Wood Scott-B07421
> Subject: Re: [PATCH 2/3 v14] iommu/fsl: Add additional iommu attributes
> required by the PAMU driver.
>=20
> On Tue, Apr 23, 2013 at 10:05:25AM +0530, Varun Sethi wrote:
> > Added the following domain attributes for the FSL PAMU driver:
> > 1. Added new iommu stash attribute, which allows setting of the
> > LIODN specific stash id parameter through IOMMU API.
> > 2. Added an attribute for enabling/disabling DMA to a particular
> > memory window.
> > 3. Added domain attribute to check for PAMUV1 specific constraints.
> >
> > Signed-off-by: Varun Sethi <Varun.Sethi@freescale.com>
> > ---
> > v14 changes:
> > - Add FSL prefix to PAMU attributes.
> > v13 changes:
> > - created a new file include/linux/fsl_pamu_stash.h for stash
> > attributes.
> > v12 changes:
> > - Moved PAMU specifc stash ids and structures to PAMU header file.
> > - no change in v11.
> > - no change in v10.
> > include/linux/fsl_pamu_stash.h | 39
> +++++++++++++++++++++++++++++++++++++++
>=20
> Isn't asm/ for your architecture a better place for that header?
>=20
I think it's fine to have the header under linux, actually I also the intel=
-iommu header under linux.
-Varun
^ permalink raw reply
* Re: [PATCH 2/3 v14] iommu/fsl: Add additional iommu attributes required by the PAMU driver.
From: Joerg Roedel @ 2013-04-23 13:38 UTC (permalink / raw)
To: Varun Sethi; +Cc: stuart.yoder, linux-kernel, iommu, scottwood, linuxppc-dev
In-Reply-To: <1366691726-9023-2-git-send-email-Varun.Sethi@freescale.com>
On Tue, Apr 23, 2013 at 10:05:25AM +0530, Varun Sethi wrote:
> Added the following domain attributes for the FSL PAMU driver:
> 1. Added new iommu stash attribute, which allows setting of the
> LIODN specific stash id parameter through IOMMU API.
> 2. Added an attribute for enabling/disabling DMA to a particular
> memory window.
> 3. Added domain attribute to check for PAMUV1 specific constraints.
>
> Signed-off-by: Varun Sethi <Varun.Sethi@freescale.com>
> ---
> v14 changes:
> - Add FSL prefix to PAMU attributes.
> v13 changes:
> - created a new file include/linux/fsl_pamu_stash.h for stash
> attributes.
> v12 changes:
> - Moved PAMU specifc stash ids and structures to PAMU header file.
> - no change in v11.
> - no change in v10.
> include/linux/fsl_pamu_stash.h | 39 +++++++++++++++++++++++++++++++++++++++
Isn't asm/ for your architecture a better place for that header?
Joerg
^ permalink raw reply
* Re: [PATCH] powerpc/cell: Only iterate over online nodes in cbe_init_pm_irq()
From: Dennis Schridde @ 2013-04-23 13:29 UTC (permalink / raw)
To: Michael Ellerman; +Cc: linuxppc-dev
In-Reply-To: <20130423130218.GD27200@concordia>
[-- Attachment #1: Type: text/plain, Size: 1409 bytes --]
Hello!
Please find an up-to-date dmesg log attached. It was created from a Linux
3.8.8 kernel with these two patches applied:
- for_each_node(node) {
+ for_each_online_node(node) {
- return distance;
+ return ((a == b) ? LOCAL_DISTANCE : REMOTE_DISTANCE);
More information on the setup (incl. config and lspci) can be found in:
Subject: PROBLEM: Only 2 of 4 cores used on IBM Cell blades and no threads
shown in spufs
Message-ID: <1470334.YUWOQ37ijW@ernie>
Am Dienstag, 23. April 2013, 23:02:19 schrieb Michael Ellerman:
> On Tue, Apr 23, 2013 at 02:45:50PM +0200, Dennis Schridde wrote:
> This is probably not good, but I'll have to compare to an old kernel to
> be sure. Have you noticed that PCI is broken in any way?
How do I find out?
The only thing I noticed (and someone else, who has been contacting me about
cellminer questions recently) is that there might be something weird going on
with the network.
For example, on RHEL5 we had issues with NFS loosing connection to the server
(the x86-64 server directly in the same rack).
And now me and the other guy notice that the connection to the Eligius bitcoin
mining pool is a bit flakey - apparently not transmitting all our work.
But this might also be caused by bugs in cellminer or Ruby - and the RHEL5
issue is very certainly not related, since now on Gentoo/Linux, with a current
kernel, the problem is gone.
--Dennis
[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 198 bytes --]
^ permalink raw reply
* Re: PROBLEM: Only 2 of 4 cores used on IBM Cell blades and no threads shown in spufs
From: Michael Ellerman @ 2013-04-23 13:24 UTC (permalink / raw)
To: Dennis Schridde; +Cc: cbe-oss-dev, linuxppc-dev, arnd
In-Reply-To: <1470334.YUWOQ37ijW@ernie>
On Mon, Apr 22, 2013 at 06:44:13PM +0200, Dennis Schridde wrote:
> Hello!
>
>
> [1.] One line summary of the problem:
> .. no threads shown in spufs
So I think I've got this one fixed, this works for me, can you test it
please?
I'll send a proper patch in the morning.
cheers
diff --git a/arch/powerpc/platforms/cell/spufs/inode.c b/arch/powerpc/platforms/cell/spufs/inode.c
index 3f3bb4c..35f77a4 100644
--- a/arch/powerpc/platforms/cell/spufs/inode.c
+++ b/arch/powerpc/platforms/cell/spufs/inode.c
@@ -99,6 +99,7 @@ spufs_new_inode(struct super_block *sb, umode_t mode)
if (!inode)
goto out;
+ inode->i_ino = get_next_ino();
inode->i_mode = mode;
inode->i_uid = current_fsuid();
inode->i_gid = current_fsgid();
^ permalink raw reply related
* Re: PROBLEM: Only 2 of 4 cores used on IBM Cell blades and no threads shown in spufs
From: Michael Ellerman @ 2013-04-23 13:19 UTC (permalink / raw)
To: Dennis Schridde; +Cc: cbe-oss-dev, linuxppc-dev, arnd
In-Reply-To: <3242341.cjDFP0lvB2@ernie>
On Tue, Apr 23, 2013 at 03:16:53PM +0200, Dennis Schridde wrote:
> Hello!
>
> Am Dienstag, 23. April 2013, 13:51:55 schrieb Dennis Schridde:
> > Am Tue, 23 Apr 2013 19:12:47 +1000
> > schrieb Michael Ellerman <michael@ellerman.id.au>:
> > > On Mon, Apr 22, 2013 at 06:44:13PM +0200, Dennis Schridde wrote:
> > > For me it is fixed by applying the following patch, it should be in
> > > v3.10:
> > I am currently compiling the patched kernel. Will report back with the
> > results later.
>
> Thanks! The patch has the intended result on my Linux 3.8.8 kernel. All 4 CPU
> cores are now being used and the cellminer hashrate went up from 42Mh/s to
> 62Mh/s (with 2 PPE and 16 SPE threads, just as before).
Excellent.
> Could it be backported, especially to 3.8?
Yes we'll send it to stable.
cheers
^ permalink raw reply
* Re: PROBLEM: Only 2 of 4 cores used on IBM Cell blades and no threads shown in spufs
From: Dennis Schridde @ 2013-04-23 13:16 UTC (permalink / raw)
To: Michael Ellerman; +Cc: cbe-oss-dev, linuxppc-dev, arnd
In-Reply-To: <20130423135155.7b307094@samson>
[-- Attachment #1: Type: text/plain, Size: 712 bytes --]
Hello!
Am Dienstag, 23. April 2013, 13:51:55 schrieb Dennis Schridde:
> Am Tue, 23 Apr 2013 19:12:47 +1000
> schrieb Michael Ellerman <michael@ellerman.id.au>:
> > On Mon, Apr 22, 2013 at 06:44:13PM +0200, Dennis Schridde wrote:
> > For me it is fixed by applying the following patch, it should be in
> > v3.10:
> I am currently compiling the patched kernel. Will report back with the
> results later.
Thanks! The patch has the intended result on my Linux 3.8.8 kernel. All 4 CPU
cores are now being used and the cellminer hashrate went up from 42Mh/s to
62Mh/s (with 2 PPE and 16 SPE threads, just as before).
Could it be backported, especially to 3.8?
Again - thanks for your work and quick reply,
Dennis
[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 198 bytes --]
^ permalink raw reply
* RE: [PATCH 1/3 v2] iommu: Move swap_pci_ref function to pci.h.
From: Sethi Varun-B16395 @ 2013-04-23 13:02 UTC (permalink / raw)
To: Joerg Roedel
Cc: Wood Scott-B07421, linux-kernel@vger.kernel.org,
Yoder Stuart-B08248, iommu@lists.linux-foundation.org,
linuxppc-dev@lists.ozlabs.org
In-Reply-To: <20130423125827.GD2589@8bytes.org>
Thanks.
> -----Original Message-----
> From: iommu-bounces@lists.linux-foundation.org [mailto:iommu-
> bounces@lists.linux-foundation.org] On Behalf Of Joerg Roedel
> Sent: Tuesday, April 23, 2013 6:32 PM
> To: Sethi Varun-B16395
> Cc: galak@kernel.crashing.org; benh@kernel.crashing.org; Yoder Stuart-
> B08248; linux-kernel@vger.kernel.org; iommu@lists.linux-foundation.org;
> Wood Scott-B07421; linuxppc-dev@lists.ozlabs.org
> Subject: Re: [PATCH 1/3 v2] iommu: Move swap_pci_ref function to pci.h.
>=20
> On Tue, Apr 23, 2013 at 10:05:24AM +0530, Varun Sethi wrote:
> > +#ifndef __PCI_H
> > +#define __PCI_H
>=20
> Using __PCI_H is not a wise choice, it has certainly a high risk of a
> collision. Anyway, I changed it to __IOMMU_PCI_H and applied the patch.
>=20
>=20
> Joerg
>=20
>=20
> _______________________________________________
> iommu mailing list
> iommu@lists.linux-foundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/iommu
^ permalink raw reply
* Re: [PATCH] powerpc/cell: Only iterate over online nodes in cbe_init_pm_irq()
From: Michael Ellerman @ 2013-04-23 13:02 UTC (permalink / raw)
To: Dennis Schridde; +Cc: linuxppc-dev
In-Reply-To: <2343936.gRCKd0qRgh@ernie>
On Tue, Apr 23, 2013 at 02:45:50PM +0200, Dennis Schridde wrote:
> Hello everyone!
>
> I have been testing this patch (given to me by Grant Likely
> <grant.likely@secretlab.ca>) with various kernel versions (3.6.2, 3.6.11,
> 3.8.6, 3.8.8) since November and can confirm that it solves part of the IRQ
> mapping issue on Cell (namely the one Michael mentioned) and does not cause
> any additional noticable problems.
>
> Some problems remain after this patch, as can be seen in the attached
> dmesg.log. If further information is required to debug this, or you need some
> help in testing more patches, please contact me.
..
This one below I really don't understand.
It's saying that the domain->ops->map() returned -22.
But as far as I can see all the map routines we have on cell return
success unconditionally. So something strange is going on. I'll have to
dig into a bit more.
> [ 0.490734] irq: irq-93==>hwirq-0x5d mapping failed: -22
> [ 0.522130] ------------[ cut here ]------------
> [ 0.549706] WARNING: at /usr/src/linux-3.8.6-aufs/kernel/irq/irqdomain.c:467
> [ 0.591895] Modules linked in:
> [ 0.610126] NIP: c0000000000bdeac LR: c0000000000bdea8 CTR: c000000000025670
> [ 0.652317] REGS: c0000000fe667190 TRAP: 0700 Not tainted (3.8.6-aufs)
> [ 0.692940] MSR: 9000000000029032 <SF,HV,EE,ME,IR,DR,RI> CR: 44000024 XER: 00000000
> [ 0.739817] SOFTE: 1
> [ 0.752840] TASK = c0000000fe668000[1] 'swapper/0' THREAD: c0000000fe664000 CPU: 0
> GPR00: c0000000000bdea8 c0000000fe667410 c000000000699cb0 000000000000002c
> GPR04: 0000000000000000 0000000078e26d37 0000000000000008 0000000000000000
> GPR08: 0000000078eef1c4 0000000000000000 0000000000000000 0000000000000000
> GPR12: d000070000000000 c00000000fffb000 c00000000000a460 0000000000000000
> GPR16: 0000000000000000 0000000000000000 0000000000000000 0000000000000000
> GPR20: 0000000000000000 0000000000000000 c0000000fe006078 000000000000005e
> GPR24: 0000000000000174 000000000000005d 000000000000005d c0000000fe65fc00
> GPR28: c0000000fe006060 000000000000005d c000000000643be0 000000000000005d
> [ 1.119009] NIP [c0000000000bdeac] .irq_domain_associate_many+0x264/0x290
> [ 1.159628] LR [c0000000000bdea8] .irq_domain_associate_many+0x260/0x290
> [ 1.199731] Call Trace:
> [ 1.214318] [c0000000fe667410] [c0000000000bdea8] .irq_domain_associate_many+0x260/0x290 (unreliable)
> [ 1.269528] [c0000000fe6674e0] [c0000000000be928] .irq_create_mapping+0xc8/0x1d0
> [ 1.313801] [c0000000fe667580] [c0000000000bead8] .irq_create_of_mapping+0xa8/0x170
> [ 1.359639] [c0000000fe667630] [c000000000290c30] .irq_of_parse_and_map+0x40/0x58
> [ 1.404429] [c0000000fe6676c0] [c000000000290df0] .of_irq_count+0x30/0x58
> [ 1.445057] [c0000000fe667750] [c00000000029182c] .of_device_alloc+0x1ec/0x288
> [ 1.488287] [c0000000fe667850] [c00000000029191c] .of_platform_device_create_pdata+0x54/0xf8
> [ 1.538810] [c0000000fe6678f0] [c000000000291b04] .of_platform_bus_create+0x144/0x1e0
> [ 1.585687] [c0000000fe6679e0] [c000000000291b60] .of_platform_bus_create+0x1a0/0x1e0
> [ 1.632564] [c0000000fe667ad0] [c000000000291d50] .of_platform_bus_probe+0xd0/0x140
> [ 1.678404] [c0000000fe667b70] [c0000000004109e4] .__machine_initcall_cell_cell_publish_devices+0x54/0x1b0
> [ 1.736219] [c0000000fe667c40] [c000000000009e70] .do_one_initcall+0x168/0x1d0
> [ 1.779445] [c0000000fe667d00] [c0000000003ffb6c] .kernel_init_freeable+0x14c/0x21c
> [ 1.825281] [c0000000fe667db0] [c00000000000a47c] .kernel_init+0x1c/0x108
> [ 1.865907] [c0000000fe667e30] [c000000000008cd8] .ret_from_kernel_thread+0x64/0x8c
> [ 1.911738] Instruction dump:
> [ 1.929448] 7fa4eb78 7ca507b4 4828c965 60000000 0fe00000 3860ffea 4bffff80 e87e8020
> [ 1.975803] 7fa4eb78 7fe5fb78 4828c945 60000000 <0fe00000> 39200000 7f83e378 7f44d378
> [ 2.023213] ---[ end trace 093b23e74665976f ]---
...
> [ 23.270411] Setting up PCI bus /axon@30000000000/plb5/pciex@a00000a000000000
> [ 23.312464] PCI host bridge /axon@30000000000/plb5/pciex@a00000a000000000 ranges:
> [ 23.357765] IO 0x000003a100000000..0x000003a10000ffff -> 0x0000000000000000
> [ 23.400470] MEM 0x000003c080000000..0x000003c0bfffffff -> 0x0000000080000000
> [ 23.443702] MEM 0x000003c0c0000000..0x000003c0ffffffff -> 0x00000000c0000000 Prefetch
> [ 23.491188] of-pci D38000002400.pciex: PCI host bridge to bus 0004:00
> [ 23.529643] pci_bus 0004:00: root bus resource [io 0x54000-0x63fff] (bus address [0x0000-0xffff])
> [ 23.583289] pci_bus 0004:00: root bus resource [mem 0x3c080000000-0x3c0bfffffff] (bus address [0x80000000-0xbfffffff])
> [ 23.647356] pci_bus 0004:00: root bus resource [mem 0x3c0c0000000-0x3c0ffffffff pref] (bus address [0xc0000000-0xffffffff])
> [ 23.714024] pci_bus 0004:00: root bus resource [bus 00-ff]
> [ 23.746836] pci_bus 0004:00: busn_res: [bus 00-ff] end is updated to ff
> [ 23.746935] pci 0004:00:00.0: [1014:032c] type 01 class 0x060400
> [ 23.747035] pci 0004:00:00.0: reg 10: [mem 0x00000000-0x7fffffff 64bit pref]
> [ 23.747093] pci 0004:00:00.0: reg 38: [mem 0x3c0ffff8000-0x3c0ffffffff pref]
> [ 23.747163] PCI: Hiding resources on Axon PCIE RC 0004:00:00.0
> [ 23.747409] pci 0004:00:00.0: supports D1 D2
> [ 23.747416] pci 0004:00:00.0: PME# supported from D0 D1 D2 D3hot D3cold
> [ 23.747563] irq: no irq domain found for /axon@30000000000/plb5/pciex-utl@a00000a000004000 !
This is probably not good, but I'll have to compare to an old kernel to
be sure. Have you noticed that PCI is broken in any way?
> [ 24.386274] iommu: missing iommu for <no-node> (node -1)
> [ 24.423030] iommu: missing iommu for <no-node> (node -1)
This is probably bad but I'll have to dig to be sure.
cheers
^ permalink raw reply
* Re: [PATCH 1/3 v2] iommu: Move swap_pci_ref function to pci.h.
From: Joerg Roedel @ 2013-04-23 13:01 UTC (permalink / raw)
To: Varun Sethi; +Cc: stuart.yoder, linux-kernel, iommu, scottwood, linuxppc-dev
In-Reply-To: <1366691726-9023-1-git-send-email-Varun.Sethi@freescale.com>
On Tue, Apr 23, 2013 at 10:05:24AM +0530, Varun Sethi wrote:
> +#ifndef __PCI_H
> +#define __PCI_H
Using __PCI_H is not a wise choice, it has certainly a high risk of a
collision. Anyway, I changed it to __IOMMU_PCI_H and applied the patch.
Joerg
^ permalink raw reply
* Re: PROBLEM: Only 2 of 4 cores used on IBM Cell blades and no threads shown in spufs
From: Michael Ellerman @ 2013-04-23 12:53 UTC (permalink / raw)
To: Dennis Schridde; +Cc: cbe-oss-dev, linuxppc-dev, arnd
In-Reply-To: <2626925.UsNZfo6Rvj@ernie>
On Tue, Apr 23, 2013 at 02:41:18PM +0200, Dennis Schridde wrote:
> Am Dienstag, 23. April 2013, 22:16:21 schrieb Michael Ellerman:
> > On Tue, Apr 23, 2013 at 02:01:16PM +0200, Dennis Schridde wrote:
> > > I applied following patch by Grant Likely
> > > <grant.likely@secretlab.ca> to fix some IRQ mapping problems:
> > Ah yes, I forgot I also have basically the same patch. I've just sent it
> > to the list.
> >
> > We appear to have a number of problems with the irq mapping on cell,
> > that patch fixes the worst of them but there are more.
>
> Yes, and it would be great if that patch could actually be merged (I have been
> using it since November, but Grant apparently never merged it) and maybe the
> other problems could be solved, too. I am willing to assist in debugging and
> testing.
Yeah, it's not really Grant's patch to merge, so that's our fault. Ben
will merge it this cycle via the powerpc tree.
I'll reply to your other mail on the other issues.
cheers
^ permalink raw reply
* Re: PROBLEM: Only 2 of 4 cores used on IBM Cell blades and no threads shown in spufs
From: Dennis Schridde @ 2013-04-23 12:41 UTC (permalink / raw)
To: Michael Ellerman; +Cc: cbe-oss-dev, linuxppc-dev, arnd
In-Reply-To: <20130423121620.GB27200@concordia>
[-- Attachment #1: Type: text/plain, Size: 719 bytes --]
Am Dienstag, 23. April 2013, 22:16:21 schrieb Michael Ellerman:
> On Tue, Apr 23, 2013 at 02:01:16PM +0200, Dennis Schridde wrote:
> > I applied following patch by Grant Likely
> > <grant.likely@secretlab.ca> to fix some IRQ mapping problems:
> Ah yes, I forgot I also have basically the same patch. I've just sent it
> to the list.
>
> We appear to have a number of problems with the irq mapping on cell,
> that patch fixes the worst of them but there are more.
Yes, and it would be great if that patch could actually be merged (I have been
using it since November, but Grant apparently never merged it) and maybe the
other problems could be solved, too. I am willing to assist in debugging and
testing.
--Dennis
[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 198 bytes --]
^ 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