* Re: [git pull] Please pull abiv2 branch
From: Philippe Bergheaud @ 2014-04-29 9:38 UTC (permalink / raw)
To: Rusty Russell
Cc: philippe.bergheaud, mikey, amodra, rostedt, ulrich.weigand, mjw,
Anton Blanchard, paulus, linuxppc-dev
In-Reply-To: <877g69t1my.fsf@rustcorp.com.au>
Rusty Russell wrote:
> Philippe Bergheaud <felix@linux.vnet.ibm.com> writes:
>
>>Anton Blanchard wrote:
>>
>>>Here are the ABIv2 patches rebased against 3.15-rc2.
>>
>>After recompiling 3.15-rc2 with the ABIv2 patches,
>>I see the following line in Modules.symvers:
>>
>> 0x00000000 TOC. vmlinux EXPORT_SYMBOL
>>
>>Kernel will not load modules because TOC. has no CRC.
>>Is this expected ? Shouldn't TOC. have a CRC ?
>
>
> What happens when you try to load a module? It should work...
My mistake, sorry: kernel 3.15-rc2 crashes at boot, in the SLES12
Beta5 environment that I am using, before any module load attempt.
The problem happens with the SLES12 kernel of the day 3.12.17,
plus the backported ABIv2 patch set. Boot fails with:
kernel: ibmveth: no symbol version for TOC.
kernel: ibmveth: Unknown symbol TOC. (err -22)
kernel: scsi_mod: no symbol version for TOC.
kernel: scsi_mod: Unknown symbol TOC. (err -22)
In the rescue shell, repeating a plain modprobe fails again:
:/# modprobe scsi_mod
modprobe: ERROR: could not insert 'scsi_mod': Invalid argument
And finally, modprobe succeeds with --force:
:/# modprobe --force scsi_mod
scsi_mod: module has bad taint, not creating trace events
Philippe
^ permalink raw reply
* Re: [PATCH 1/2] powerpc/powernv: reduce multi-hit of iommu_add_device()
From: Wei Yang @ 2014-04-29 9:37 UTC (permalink / raw)
To: Alexey Kardashevskiy; +Cc: Wei Yang, linuxppc-dev, gwshan
In-Reply-To: <535F5B04.5000102@au1.ibm.com>
On Tue, Apr 29, 2014 at 05:55:48PM +1000, Alexey Kardashevskiy wrote:
>On 04/29/2014 04:49 PM, Wei Yang wrote:
>> On Mon, Apr 28, 2014 at 11:35:32PM +1000, Alexey Kardashevskiy wrote:
>>> On 04/23/2014 12:26 PM, Wei Yang wrote:
>>>> During the EEH hotplug event, iommu_add_device() will be invoked three times
>>>> and two of them will trigger warning or error.
>>>>
>>>> The three times to invoke the iommu_add_device() are:
>>>>
>>>> pci_device_add
>>>> ...
>>>> set_iommu_table_base_and_group <- 1st time, fail
>>>> device_add
>>>> ...
>>>> tce_iommu_bus_notifier <- 2nd time, succees
>>>> pcibios_add_pci_devices
>>>> ...
>>>> pcibios_setup_bus_devices <- 3rd time, re-attach
>>>>
>>>> The first time fails, since the dev->kobj->sd is not initialized. The
>>>> dev->kobj->sd is initialized in device_add().
>>>> The third time's warning is triggered by the re-attach of the iommu_group.
>>>>
>>>> After applying this patch, the error
>>>
>>> Nack.
>>>
>>> The patch still seems incorrect and we actually need to remove
>>> tce_iommu_bus_notifier completely as pcibios_setup_bus_devices is called
>>>from another notifier anyway. Could you please test it?
>>>
>>>
>>
>> Hi, Alexey,
>>
>> Nice to see your comment. Let me show what I got fist.
>>
>> Generally, when kernel enumerate on the pci device, following functions will
>> be invoked.
>>
>> pci_device_add
>> pcibios_setup_bus_device
>> ...
>> set_iommu_table_base_and_group
>> device_add
>> ...
>> tce_iommu_bus_notifier
>> pcibios_fixp_bus
>> pcibios_add_pci_devices
>> ...
>> pcibios_setup_bus_devices
>>
>>>From the call flow, we see for a normall pci device, the
>> pcibios_setup_bus_device() will be invoked twice.
>
>
>tce_iommu_bus_notifier should not be called for devices during boot-time
>PCI discovery as the discovery is done from subsys_initcall handler and
>tce_iommu_bus_notifier is registered as subsys_initcall_sync. Are you sure
>this is happening? You should see warnings as for PF's EEH but you do not
>say that.
>
Let me make it clearer. I list the call flow for general purpose to show the
sequence of the call flow.
The tce_iommu_bus_notifier is not invoked at the boot time. And none of them
do real thing at boot time.
I don't understand your last sentence. I see warning and error during EEH
hotplug. If necessary, I will add this in the commit log.
>
>> At the bootup time, none of them succeed to setup the dma, since the PE is not
>> assigned or the tbl is not set. The iommu tbl and group is setup in
>> pnv_pci_ioda_setup_DMA().
>>
>> This call flow maintains the same when EEH error happens on Bus PE, while the
>> behavior is a little different.
>>
>> pci_device_add
>> pcibios_setup_bus_device
>> ...
>> set_iommu_table_base_and_group <- fail, kobj->sd is not initialized
>
>
>Sorry, what is uninitialized? The only kobj here is the one in iommu_group
>and it must have been taken care of before adding a device.
pci_dev->dev->kobj->sd.
I have explained this in previous discussion. This kobj->sd is initialized in
device_add().
>
>
>> device_add
>> ...
>> tce_iommu_bus_notifier <- succeed
>> pcibios_fixp_bus
>> pcibios_add_pci_devices
>> ...
>> pcibios_setup_bus_devices <- warning, re-attach
>
>
>This is why I am suggesting getting rid of tce_iommu_bus_notifier - we will
>avoid the warning.
Then how about the first time's error?
>
>
>> While this call flow will change a little on a VF. For a VF,
>> pcibios_fixp_bus() will not be invoked. Current behavior is this.
>
>
>You meant pcibios_fixup_bus? I would expect it to get called (from
>pci_rescan_bus() or something like that?) and this seems to be the problem
>here.
When EEH happens and hotplug the pci bus, we need to do the pci_scan_bridge()
which will do the pcibios_fixup_bus().
So you suggest to remove it? This is the generic code.
>
>How are VFs added in terms of code flow? Is there any git tree to look at?
>
VF add code flow is a generic code in drivers/pci/iov.c, virtfn_add().
>
>
>> pci_device_add
>> pcibios_setup_bus_device
>> ...
>> set_iommu_table_base_and_group <- fail, kobj->sd is not initialized
>> device_add
>> ...
>> tce_iommu_bus_notifier <- succeed
>>
>> And if an EEH error happens just on a VF, I believe the same call flow should
>> go for recovery. (This is not set down, still under discussion with Gavin.)
>>
>> My conclusion is:
>> 1. remove the tce_iommu_bus_notifier completely will make the VF not work.
>> So I choose to revert the code and attach make the iommu group attachment
>> just happens in one place.
>>
>> BTW, I know my patch is not a perfect one. For a PF, the tbl will still be set
>> twice. I am not sure why we need to invoke pcibios_setup_device() twice on a
>> PF, maybe some platform need to fixup some thing after the pci_bus is added.
>> So I don't remove one of them to solve the problem.
>>
>> If you have a better idea, I am glad to take it.
>>
>
>
>--
>Alexey Kardashevskiy
>IBM OzLabs, LTC Team
>
>e-mail: aik@au1.ibm.com
>notes: Alexey Kardashevskiy/Australia/IBM
--
Richard Yang
Help you, Help me
^ permalink raw reply
* Re: [PATCH V3 2/2] powerpc/pseries: init fault_around_order for pseries
From: Madhavan Srinivasan @ 2014-04-29 9:36 UTC (permalink / raw)
To: Rusty Russell, linux-kernel, linuxppc-dev, linux-mm, linux-arch,
x86
Cc: riel, ak, peterz, dave.hansen, paulus, mgorman, akpm, mingo,
kirill.shutemov
In-Reply-To: <877g686fpb.fsf@rustcorp.com.au>
On Tuesday 29 April 2014 07:48 AM, Rusty Russell wrote:
> Madhavan Srinivasan <maddy@linux.vnet.ibm.com> writes:
>> diff --git a/arch/powerpc/platforms/pseries/setup.c b/arch/powerpc/platforms/pseries/setup.c
>> index 2db8cc6..c87e6b6 100644
>> --- a/arch/powerpc/platforms/pseries/setup.c
>> +++ b/arch/powerpc/platforms/pseries/setup.c
>> @@ -74,6 +74,8 @@ int CMO_SecPSP = -1;
>> unsigned long CMO_PageSize = (ASM_CONST(1) << IOMMU_PAGE_SHIFT_4K);
>> EXPORT_SYMBOL(CMO_PageSize);
>>
>> +extern unsigned int fault_around_order;
>> +
>
> It's considered bad form to do this. Put the declaration in linux/mm.h.
>
ok. Will change it.
Thanks for review
With regards
Maddy
> Thanks,
> Rusty.
> PS. But we're getting there! :)
>
^ permalink raw reply
* Re: [PATCH V3 1/2] mm: move FAULT_AROUND_ORDER to arch/
From: Madhavan Srinivasan @ 2014-04-29 9:35 UTC (permalink / raw)
To: Kirill A. Shutemov
Cc: linux-arch, riel, rusty, dave.hansen, peterz, x86, linux-kernel,
linux-mm, ak, paulus, mgorman, akpm, linuxppc-dev, mingo
In-Reply-To: <20140428093606.95B90E009B@blue.fi.intel.com>
On Monday 28 April 2014 03:06 PM, Kirill A. Shutemov wrote:
> Madhavan Srinivasan wrote:
>> Kirill A. Shutemov with 8c6e50b029 commit introduced
>> vm_ops->map_pages() for mapping easy accessible pages around
>> fault address in hope to reduce number of minor page faults.
>>
>> This patch creates infrastructure to modify the FAULT_AROUND_ORDER
>> value using mm/Kconfig. This will enable architecture maintainers
>> to decide on suitable FAULT_AROUND_ORDER value based on
>> performance data for that architecture. Patch also defaults
>> FAULT_AROUND_ORDER Kconfig element to 4.
>>
>> Signed-off-by: Madhavan Srinivasan <maddy@linux.vnet.ibm.com>
>> ---
>> mm/Kconfig | 8 ++++++++
>> mm/memory.c | 11 ++++-------
>> 2 files changed, 12 insertions(+), 7 deletions(-)
>>
>> diff --git a/mm/Kconfig b/mm/Kconfig
>> index ebe5880..c7fc4f1 100644
>> --- a/mm/Kconfig
>> +++ b/mm/Kconfig
>> @@ -176,6 +176,14 @@ config MOVABLE_NODE
>> config HAVE_BOOTMEM_INFO_NODE
>> def_bool n
>>
>> +#
>> +# Fault around order is a control knob to decide the fault around pages.
>> +# Default value is set to 4 , but the arch can override it as desired.
>> +#
>> +config FAULT_AROUND_ORDER
>> + int
>> + default 4
>> +
>> # eventually, we can have this option just 'select SPARSEMEM'
>> config MEMORY_HOTPLUG
>> bool "Allow for memory hot-add"
>> diff --git a/mm/memory.c b/mm/memory.c
>> index d0f0bef..457436d 100644
>> --- a/mm/memory.c
>> +++ b/mm/memory.c
>> @@ -3382,11 +3382,9 @@ void do_set_pte(struct vm_area_struct *vma, unsigned long address,
>> update_mmu_cache(vma, address, pte);
>> }
>>
>> -#define FAULT_AROUND_ORDER 4
>> +unsigned int fault_around_order = CONFIG_FAULT_AROUND_ORDER;
>>
>> #ifdef CONFIG_DEBUG_FS
>> -static unsigned int fault_around_order = FAULT_AROUND_ORDER;
>> -
>> static int fault_around_order_get(void *data, u64 *val)
>> {
>> *val = fault_around_order;
>> @@ -3395,7 +3393,6 @@ static int fault_around_order_get(void *data, u64 *val)
>>
>> static int fault_around_order_set(void *data, u64 val)
>> {
>> - BUILD_BUG_ON((1UL << FAULT_AROUND_ORDER) > PTRS_PER_PTE);
>> if (1UL << val > PTRS_PER_PTE)
>> return -EINVAL;
>> fault_around_order = val;
>> @@ -3430,14 +3427,14 @@ static inline unsigned long fault_around_pages(void)
>> {
>> unsigned long nr_pages;
>>
>> - nr_pages = 1UL << FAULT_AROUND_ORDER;
>> + nr_pages = 1UL << fault_around_order;
>> BUILD_BUG_ON(nr_pages > PTRS_PER_PTE);
>
> This BUILD_BUG_ON() doesn't make sense any more since compiler usually can't
> prove anything about extern variable.
>
> Drop it or change to VM_BUG_ON() or something.
>
Ok.
>> return nr_pages;
>> }
>>
>> static inline unsigned long fault_around_mask(void)
>> {
>> - return ~((1UL << (PAGE_SHIFT + FAULT_AROUND_ORDER)) - 1);
>> + return ~((1UL << (PAGE_SHIFT + fault_around_order)) - 1);
>
> fault_around_pages() and fault_around_mask() should be moved outside of
> #ifdef CONFIG_DEBUG_FS and consolidated since they are practically identical
> both branches after the changes.
>
Agreed. Will change it.
>> }
>> #endif
>>
>> @@ -3495,7 +3492,7 @@ static int do_read_fault(struct mm_struct *mm, struct vm_area_struct *vma,
>> * if page by the offset is not ready to be mapped (cold cache or
>> * something).
>> */
>> - if (vma->vm_ops->map_pages) {
>> + if ((vma->vm_ops->map_pages) && (fault_around_order)) {
>
> Way too many parentheses.
>
Sure. Will modify it.
Thanks for review
with regards
Maddy
>> pte = pte_offset_map_lock(mm, pmd, address, &ptl);
>> do_fault_around(vma, address, pte, pgoff, flags);
>> if (!pte_same(*pte, orig_pte))
^ permalink raw reply
* Re: [PATCH V3 1/2] mm: move FAULT_AROUND_ORDER to arch/
From: Madhavan Srinivasan @ 2014-04-29 9:33 UTC (permalink / raw)
To: Peter Zijlstra
Cc: linux-arch, riel, rusty, dave.hansen, x86, linux-kernel, linux-mm,
ak, paulus, mgorman, akpm, linuxppc-dev, mingo, kirill.shutemov
In-Reply-To: <20140428090649.GD27561@twins.programming.kicks-ass.net>
On Monday 28 April 2014 02:36 PM, Peter Zijlstra wrote:
> On Mon, Apr 28, 2014 at 02:31:29PM +0530, Madhavan Srinivasan wrote:
>> +unsigned int fault_around_order = CONFIG_FAULT_AROUND_ORDER;
>
> __read_mostly?
>
Agreed. Will add it.
Thanks for review.
With regards
Maddy
^ permalink raw reply
* Re: [PATCH 0/3] Add new ptrace request macros on PowerPC
From: Michael Neuling @ 2014-04-29 8:22 UTC (permalink / raw)
To: Anshuman Khandual; +Cc: Linux PPC dev, linux-kernel, avagin, roland, oleg
In-Reply-To: <535F5BDE.2030309@linux.vnet.ibm.com>
[-- Attachment #1: Type: text/plain, Size: 882 bytes --]
That's not what that patch does. It shouldn't make any user visible changes
to DSCR or PPR.
Over syscall PPR and DSCR may change. Depending on your test case, that may
be your problem.
Mikey
On 29 Apr 2014 18:02, "Anshuman Khandual" <khandual@linux.vnet.ibm.com>
wrote:
> On 04/29/2014 12:36 PM, Michael Neuling wrote:
> > How is it causing the problem?
>
> As mentioned before, what I thought to be a problem is
> something expected behaviour. So it's not a problem any
> more. DSCR value inside the transaction will fall back
> to default as kernel wont let user specified value to
> remain applied for a long time.
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
>
>
[-- Attachment #2: Type: text/html, Size: 1418 bytes --]
^ permalink raw reply
* Re: [PATCH 0/3] Add new ptrace request macros on PowerPC
From: Anshuman Khandual @ 2014-04-29 7:59 UTC (permalink / raw)
To: Michael Neuling; +Cc: Linux PPC dev, linux-kernel, avagin, roland, oleg
In-Reply-To: <CAEjGV6yi5YY95tM-HY4akN4BGXGn4chA8_sCaqvWx3HPSu2V3w@mail.gmail.com>
On 04/29/2014 12:36 PM, Michael Neuling wrote:
> How is it causing the problem?
As mentioned before, what I thought to be a problem is
something expected behaviour. So it's not a problem any
more. DSCR value inside the transaction will fall back
to default as kernel wont let user specified value to
remain applied for a long time.
^ permalink raw reply
* [PATCH] powerpc/eeh: Dump PE location code
From: Gavin Shan @ 2014-04-29 8:00 UTC (permalink / raw)
To: benh; +Cc: linuxppc-dev, Gavin Shan
As Ben suggested, it's meaningful to dump PE's location code
for site engineers when hitting EEH errors. The patch introduces
function eeh_pe_loc_get() to retireve the location code from
dev-tree so that we can output it when hitting EEH errors.
If primary PE bus is root bus, the PHB's dev-node would be tried
prior to root port's dev-node. Otherwise, the upstream bridge's
dev-node of the primary PE bus will be check for the location code
directly.
Signed-off-by: Gavin Shan <gwshan@linux.vnet.ibm.com>
---
arch/powerpc/include/asm/eeh.h | 1 +
arch/powerpc/kernel/eeh.c | 9 ++---
arch/powerpc/kernel/eeh_pe.c | 60 +++++++++++++++++++++++++++++++
arch/powerpc/platforms/powernv/eeh-ioda.c | 27 ++++++++------
4 files changed, 82 insertions(+), 15 deletions(-)
diff --git a/arch/powerpc/include/asm/eeh.h b/arch/powerpc/include/asm/eeh.h
index d12529f..7782056 100644
--- a/arch/powerpc/include/asm/eeh.h
+++ b/arch/powerpc/include/asm/eeh.h
@@ -255,6 +255,7 @@ void *eeh_pe_traverse(struct eeh_pe *root,
void *eeh_pe_dev_traverse(struct eeh_pe *root,
eeh_traverse_func fn, void *flag);
void eeh_pe_restore_bars(struct eeh_pe *pe);
+const char *eeh_pe_loc_get(struct eeh_pe *pe);
struct pci_bus *eeh_pe_bus_get(struct eeh_pe *pe);
void *eeh_dev_init(struct device_node *dn, void *data);
diff --git a/arch/powerpc/kernel/eeh.c b/arch/powerpc/kernel/eeh.c
index 3764fb7..9f8de75 100644
--- a/arch/powerpc/kernel/eeh.c
+++ b/arch/powerpc/kernel/eeh.c
@@ -329,8 +329,8 @@ static int eeh_phb_check_failure(struct eeh_pe *pe)
eeh_pe_state_mark(phb_pe, EEH_PE_ISOLATED);
eeh_serialize_unlock(flags);
- pr_err("EEH: PHB#%x failure detected\n",
- phb_pe->phb->global_number);
+ pr_err("EEH: PHB#%x (%s) failure detected\n",
+ phb_pe->phb->global_number, eeh_pe_loc_get(phb_pe));
dump_stack();
eeh_send_failure_event(phb_pe);
@@ -459,8 +459,9 @@ int eeh_dev_check_failure(struct eeh_dev *edev)
* a stack trace will help the device-driver authors figure
* out what happened. So print that out.
*/
- pr_err("EEH: Frozen PE#%x detected on PHB#%x\n",
- pe->addr, pe->phb->global_number);
+ pr_err("EEH: Frozen PHB#%x-PE#%x (%s) detected\n",
+ pe->phb->global_number, pe->addr,
+ eeh_pe_loc_get(pe));
dump_stack();
eeh_send_failure_event(pe);
diff --git a/arch/powerpc/kernel/eeh_pe.c b/arch/powerpc/kernel/eeh_pe.c
index 995c2a2..fbd01eb 100644
--- a/arch/powerpc/kernel/eeh_pe.c
+++ b/arch/powerpc/kernel/eeh_pe.c
@@ -792,6 +792,66 @@ void eeh_pe_restore_bars(struct eeh_pe *pe)
}
/**
+ * eeh_pe_loc_get - Retrieve location code binding to the given PE
+ * @pe: EEH PE
+ *
+ * Retrieve the location code of the given PE. If the primary PE bus
+ * is root bus, we will grab location code from PHB device tree node
+ * or root port. Otherwise, the upstream bridge's device tree node
+ * of the primary PE bus will be checked for the location code.
+ */
+const char *eeh_pe_loc_get(struct eeh_pe *pe)
+{
+ struct pci_controller *hose;
+ struct pci_bus *bus = eeh_pe_bus_get(pe);
+ struct pci_dev *pdev;
+ struct device_node *dn;
+ const char *loc;
+
+ if (!bus)
+ return "N/A";
+
+ /* PHB PE or root PE ? */
+ if (pci_is_root_bus(bus)) {
+ hose = pci_bus_to_host(bus);
+ loc = of_get_property(hose->dn,
+ "ibm,loc-code", NULL);
+ if (loc)
+ return loc;
+ loc = of_get_property(hose->dn,
+ "ibm,io-base-loc-code", NULL);
+ if (loc)
+ return loc;
+
+ pdev = pci_get_slot(bus, 0x0);
+ } else {
+ pdev = bus->self;
+ }
+
+ if (!pdev) {
+ loc = "N/A";
+ goto out;
+ }
+
+ dn = pci_device_to_OF_node(pdev);
+ if (!dn) {
+ loc = "N/A";
+ goto out;
+ }
+
+ loc = of_get_property(dn, "ibm,loc-code", NULL);
+ if (!loc)
+ loc = of_get_property(dn, "ibm,slot-location-code", NULL);
+ if (!loc)
+ loc = "N/A";
+
+out:
+ if (pci_is_root_bus(bus) && pdev)
+ pci_dev_put(pdev);
+ return loc;
+}
+
+/**
* eeh_pe_bus_get - Retrieve PCI bus according to the given PE
* @pe: EEH PE
*
diff --git a/arch/powerpc/platforms/powernv/eeh-ioda.c b/arch/powerpc/platforms/powernv/eeh-ioda.c
index 79d0cdf..e5b88c5 100644
--- a/arch/powerpc/platforms/powernv/eeh-ioda.c
+++ b/arch/powerpc/platforms/powernv/eeh-ioda.c
@@ -851,18 +851,21 @@ static int ioda_eeh_next_error(struct eeh_pe **pe)
case OPAL_EEH_PHB_ERROR:
if (severity == OPAL_EEH_SEV_PHB_DEAD) {
*pe = phb_pe;
- pr_err("EEH: dead PHB#%x detected\n",
- hose->global_number);
+ pr_err("EEH: dead PHB#%x (%s) detected\n",
+ hose->global_number,
+ eeh_pe_loc_get(phb_pe));
ret = EEH_NEXT_ERR_DEAD_PHB;
} else if (severity == OPAL_EEH_SEV_PHB_FENCED) {
*pe = phb_pe;
- pr_err("EEH: fenced PHB#%x detected\n",
- hose->global_number);
+ pr_err("EEH: Fenced PHB#%x (%s) detected\n",
+ hose->global_number,
+ eeh_pe_loc_get(phb_pe));
ret = EEH_NEXT_ERR_FENCED_PHB;
} else if (severity == OPAL_EEH_SEV_INF) {
- pr_info("EEH: PHB#%x informative error "
+ pr_info("EEH: PHB#%x (%s) informative error "
"detected\n",
- hose->global_number);
+ hose->global_number,
+ eeh_pe_loc_get(phb_pe));
ioda_eeh_phb_diag(hose);
ret = EEH_NEXT_ERR_NONE;
}
@@ -881,16 +884,18 @@ static int ioda_eeh_next_error(struct eeh_pe **pe)
*/
if (ioda_eeh_get_pe(hose, frozen_pe_no, pe)) {
*pe = phb_pe;
- pr_err("EEH: Escalated fenced PHB#%x "
- "detected for PE#%llx\n",
+ pr_err("EEH: Escalated frozen PHB#%x-"
+ "PE#%llx (%s) detected\n",
hose->global_number,
- frozen_pe_no);
+ frozen_pe_no,
+ eeh_pe_loc_get(phb_pe));
ret = EEH_NEXT_ERR_FENCED_PHB;
} else if ((*pe)->state & EEH_PE_ISOLATED) {
ret = EEH_NEXT_ERR_NONE;
} else {
- pr_err("EEH: Frozen PE#%x on PHB#%x detected\n",
- (*pe)->addr, (*pe)->phb->global_number);
+ pr_err("EEH: Frozen PHB#%x-PE#%x (%s) detected\n",
+ (*pe)->phb->global_number, (*pe)->addr,
+ eeh_pe_loc_get(*pe));
ret = EEH_NEXT_ERR_FROZEN_PE;
}
--
1.8.3.2
^ permalink raw reply related
* Re: [PATCH 1/2] powerpc/powernv: reduce multi-hit of iommu_add_device()
From: Alexey Kardashevskiy @ 2014-04-29 7:55 UTC (permalink / raw)
To: Wei Yang; +Cc: linuxppc-dev, gwshan
In-Reply-To: <20140429064955.GA5066@richard>
On 04/29/2014 04:49 PM, Wei Yang wrote:
> On Mon, Apr 28, 2014 at 11:35:32PM +1000, Alexey Kardashevskiy wrote:
>> On 04/23/2014 12:26 PM, Wei Yang wrote:
>>> During the EEH hotplug event, iommu_add_device() will be invoked three times
>>> and two of them will trigger warning or error.
>>>
>>> The three times to invoke the iommu_add_device() are:
>>>
>>> pci_device_add
>>> ...
>>> set_iommu_table_base_and_group <- 1st time, fail
>>> device_add
>>> ...
>>> tce_iommu_bus_notifier <- 2nd time, succees
>>> pcibios_add_pci_devices
>>> ...
>>> pcibios_setup_bus_devices <- 3rd time, re-attach
>>>
>>> The first time fails, since the dev->kobj->sd is not initialized. The
>>> dev->kobj->sd is initialized in device_add().
>>> The third time's warning is triggered by the re-attach of the iommu_group.
>>>
>>> After applying this patch, the error
>>
>> Nack.
>>
>> The patch still seems incorrect and we actually need to remove
>> tce_iommu_bus_notifier completely as pcibios_setup_bus_devices is called
>>from another notifier anyway. Could you please test it?
>>
>>
>
> Hi, Alexey,
>
> Nice to see your comment. Let me show what I got fist.
>
> Generally, when kernel enumerate on the pci device, following functions will
> be invoked.
>
> pci_device_add
> pcibios_setup_bus_device
> ...
> set_iommu_table_base_and_group
> device_add
> ...
> tce_iommu_bus_notifier
> pcibios_fixp_bus
> pcibios_add_pci_devices
> ...
> pcibios_setup_bus_devices
>
>>From the call flow, we see for a normall pci device, the
> pcibios_setup_bus_device() will be invoked twice.
tce_iommu_bus_notifier should not be called for devices during boot-time
PCI discovery as the discovery is done from subsys_initcall handler and
tce_iommu_bus_notifier is registered as subsys_initcall_sync. Are you sure
this is happening? You should see warnings as for PF's EEH but you do not
say that.
> At the bootup time, none of them succeed to setup the dma, since the PE is not
> assigned or the tbl is not set. The iommu tbl and group is setup in
> pnv_pci_ioda_setup_DMA().
>
> This call flow maintains the same when EEH error happens on Bus PE, while the
> behavior is a little different.
>
> pci_device_add
> pcibios_setup_bus_device
> ...
> set_iommu_table_base_and_group <- fail, kobj->sd is not initialized
Sorry, what is uninitialized? The only kobj here is the one in iommu_group
and it must have been taken care of before adding a device.
> device_add
> ...
> tce_iommu_bus_notifier <- succeed
> pcibios_fixp_bus
> pcibios_add_pci_devices
> ...
> pcibios_setup_bus_devices <- warning, re-attach
This is why I am suggesting getting rid of tce_iommu_bus_notifier - we will
avoid the warning.
> While this call flow will change a little on a VF. For a VF,
> pcibios_fixp_bus() will not be invoked. Current behavior is this.
You meant pcibios_fixup_bus? I would expect it to get called (from
pci_rescan_bus() or something like that?) and this seems to be the problem
here.
How are VFs added in terms of code flow? Is there any git tree to look at?
> pci_device_add
> pcibios_setup_bus_device
> ...
> set_iommu_table_base_and_group <- fail, kobj->sd is not initialized
> device_add
> ...
> tce_iommu_bus_notifier <- succeed
>
> And if an EEH error happens just on a VF, I believe the same call flow should
> go for recovery. (This is not set down, still under discussion with Gavin.)
>
> My conclusion is:
> 1. remove the tce_iommu_bus_notifier completely will make the VF not work.
> So I choose to revert the code and attach make the iommu group attachment
> just happens in one place.
>
> BTW, I know my patch is not a perfect one. For a PF, the tbl will still be set
> twice. I am not sure why we need to invoke pcibios_setup_device() twice on a
> PF, maybe some platform need to fixup some thing after the pci_bus is added.
> So I don't remove one of them to solve the problem.
>
> If you have a better idea, I am glad to take it.
>
--
Alexey Kardashevskiy
IBM OzLabs, LTC Team
e-mail: aik@au1.ibm.com
notes: Alexey Kardashevskiy/Australia/IBM
^ permalink raw reply
* [PATCH 1/2] ftrace: PPC, fix obsolete comment
From: Jiri Slaby @ 2014-04-29 7:24 UTC (permalink / raw)
To: rostedt
Cc: jirislaby, linux-kernel, Ingo Molnar, Paul Mackerras,
Frederic Weisbecker, Jiri Slaby, linuxppc-dev
CONFIG_MCOUNT is not defined anymore, the corresponding #ifdef there
is CONFIG_FUNCTION_TRACER.
Signed-off-by: Jiri Slaby <jslaby@suse.cz>
Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Cc: Paul Mackerras <paulus@samba.org>
Cc: <linuxppc-dev@lists.ozlabs.org>
Cc: Steven Rostedt <rostedt@goodmis.org>
Cc: Frederic Weisbecker <fweisbec@gmail.com>
Cc: Ingo Molnar <mingo@redhat.com>
---
arch/powerpc/kernel/entry_32.S | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/powerpc/kernel/entry_32.S b/arch/powerpc/kernel/entry_32.S
index 22b45a4955cd..f1f652a8f395 100644
--- a/arch/powerpc/kernel/entry_32.S
+++ b/arch/powerpc/kernel/entry_32.S
@@ -1457,4 +1457,4 @@ _GLOBAL(return_to_handler)
blr
#endif /* CONFIG_FUNCTION_GRAPH_TRACER */
-#endif /* CONFIG_MCOUNT */
+#endif /* CONFIG_FUNCTION_TRACER */
--
1.9.2
^ permalink raw reply related
* Re: [PATCH V3 2/2] powerpc/pseries: init fault_around_order for pseries
From: Ingo Molnar @ 2014-04-29 7:06 UTC (permalink / raw)
To: Madhavan Srinivasan
Cc: linux-arch, riel, rusty, dave.hansen, peterz, x86, linux-kernel,
linux-mm, ak, paulus, mgorman, Linus Torvalds, akpm, linuxppc-dev,
kirill.shutemov
In-Reply-To: <1398675690-16186-3-git-send-email-maddy@linux.vnet.ibm.com>
* Madhavan Srinivasan <maddy@linux.vnet.ibm.com> wrote:
> Performance data for different FAULT_AROUND_ORDER values from 4 socket
> Power7 system (128 Threads and 128GB memory). perf stat with repeat of 5
> is used to get the stddev values. Test ran in v3.14 kernel (Baseline) and
> v3.15-rc1 for different fault around order values.
>
> FAULT_AROUND_ORDER Baseline 1 3 4 5 8
>
> Linux build (make -j64)
> minor-faults 47,437,359 35,279,286 25,425,347 23,461,275 22,002,189 21,435,836
> times in seconds 347.302528420 344.061588460 340.974022391 348.193508116 348.673900158 350.986543618
> stddev for time ( +- 1.50% ) ( +- 0.73% ) ( +- 1.13% ) ( +- 1.01% ) ( +- 1.89% ) ( +- 1.55% )
> %chg time to baseline -0.9% -1.8% 0.2% 0.39% 1.06%
Probably too noisy.
> Linux rebuild (make -j64)
> minor-faults 941,552 718,319 486,625 440,124 410,510 397,416
> times in seconds 30.569834718 31.219637539 31.319370649 31.434285472 31.972367174 31.443043580
> stddev for time ( +- 1.07% ) ( +- 0.13% ) ( +- 0.43% ) ( +- 0.18% ) ( +- 0.95% ) ( +- 0.58% )
> %chg time to baseline 2.1% 2.4% 2.8% 4.58% 2.85%
Here it looks like a speedup. Optimal value: 5+.
> Binutils build (make all -j64 )
> minor-faults 474,821 371,380 269,463 247,715 235,255 228,337
> times in seconds 53.882492432 53.584289348 53.882773216 53.755816431 53.607824348 53.423759642
> stddev for time ( +- 0.08% ) ( +- 0.56% ) ( +- 0.17% ) ( +- 0.11% ) ( +- 0.60% ) ( +- 0.69% )
> %chg time to baseline -0.55% 0.0% -0.23% -0.51% -0.85%
Probably too noisy, but looks like a potential slowdown?
> Two synthetic tests: access every word in file in sequential/random order.
>
> Sequential access 16GiB file
> FAULT_AROUND_ORDER Baseline 1 3 4 5 8
> 1 thread
> minor-faults 263,148 131,166 32,908 16,514 8,260 1,093
> times in seconds 53.091138345 53.113191672 53.188776177 53.233017218 53.206841347 53.429979442
> stddev for time ( +- 0.06% ) ( +- 0.07% ) ( +- 0.08% ) ( +- 0.09% ) ( +- 0.03% ) ( +- 0.03% )
> %chg time to baseline 0.04% 0.18% 0.26% 0.21% 0.63%
Speedup, optimal value: 8+.
> 8 threads
> minor-faults 2,097,267 1,048,753 262,237 131,397 65,621 8,274
> times in seconds 55.173790028 54.591880790 54.824623287 54.802162211 54.969680503 54.790387715
> stddev for time ( +- 0.78% ) ( +- 0.09% ) ( +- 0.08% ) ( +- 0.07% ) ( +- 0.28% ) ( +- 0.05% )
> %chg time to baseline -1.05% -0.63% -0.67% -0.36% -0.69%
Looks like a regression?
> 32 threads
> minor-faults 8,388,751 4,195,621 1,049,664 525,461 262,535 32,924
> times in seconds 60.431573046 60.669110744 60.485336388 60.697789706 60.077959564 60.588855032
> stddev for time ( +- 0.44% ) ( +- 0.27% ) ( +- 0.46% ) ( +- 0.67% ) ( +- 0.31% ) ( +- 0.49% )
> %chg time to baseline 0.39% 0.08% 0.44% -0.58% 0.25%
Probably too noisy.
> 64 threads
> minor-faults 16,777,409 8,607,527 2,289,766 1,202,264 598,405 67,587
> times in seconds 96.932617720 100.675418760 102.109880836 103.881733383 102.580199555 105.751194041
> stddev for time ( +- 1.39% ) ( +- 1.06% ) ( +- 0.99% ) ( +- 0.76% ) ( +- 1.65% ) ( +- 1.60% )
> %chg time to baseline 3.86% 5.34% 7.16% 5.82% 9.09%
Speedup, optimal value: 4+
> 128 threads
> minor-faults 33,554,705 17,375,375 4,682,462 2,337,245 1,179,007 134,819
> times in seconds 128.766704495 115.659225437 120.353046307 115.291871270 115.450886036 113.991902150
> stddev for time ( +- 2.93% ) ( +- 0.30% ) ( +- 2.93% ) ( +- 1.24% ) ( +- 1.03% ) ( +- 0.70% )
> %chg time to baseline -10.17% -6.53% -10.46% -10.34% -11.47%
Rather significant regression at order 1 already.
> Random access 1GiB file
> FAULT_AROUND_ORDER Baseline 1 3 4 5 8
> 1 thread
> minor-faults 17,155 8,678 2,126 1,097 581 134
> times in seconds 51.904430523 51.658017987 51.919270792 51.560531738 52.354431597 51.976469502
> stddev for time ( +- 3.19% ) ( +- 1.35% ) ( +- 1.56% ) ( +- 0.91% ) ( +- 1.70% ) ( +- 2.02% )
> %chg time to baseline -0.47% 0.02% -0.66% 0.86% 0.13%
Probably too noisy.
> 8 threads
> minor-faults 131,844 70,705 17,457 8,505 4,251 598
> times in seconds 58.162813956 54.991706305 54.952675791 55.323057492 54.755587379 53.376722828
> stddev for time ( +- 1.44% ) ( +- 0.69% ) ( +- 1.23% ) ( +- 2.78% ) ( +- 1.90% ) ( +- 2.91% )
> %chg time to baseline -5.45% -5.52% -4.88% -5.86% -8.22%
Regression.
> 32 threads
> minor-faults 524,437 270,760 67,069 33,414 16,641 2,204
> times in seconds 69.981777072 76.539570015 79.753578505 76.245943618 77.254258344 79.072596831
> stddev for time ( +- 2.81% ) ( +- 1.95% ) ( +- 2.66% ) ( +- 0.99% ) ( +- 2.35% ) ( +- 3.22% )
> %chg time to baseline 9.37% 13.96% 8.95% 10.39% 12.98%
Speedup, optimal value hard to tell due to noise - 3+ or 8+.
> 64 threads
> minor-faults 1,049,117 527,451 134,016 66,638 33,391 4,559
> times in seconds 108.024517536 117.575067996 115.322659914 111.943998437 115.049450815 119.218450840
> stddev for time ( +- 2.40% ) ( +- 1.77% ) ( +- 1.19% ) ( +- 3.29% ) ( +- 2.32% ) ( +- 1.42% )
> %chg time to baseline 8.84% 6.75% 3.62% 6.5% 10.3%
Speedup, optimal value again hard to tell due to noise.
> 128 threads
> minor-faults 2,097,440 1,054,360 267,042 133,328 66,532 8,652
> times in seconds 155.055861167 153.059625968 152.449492156 151.024005282 150.844647770 155.954366718
> stddev for time ( +- 1.32% ) ( +- 1.14% ) ( +- 1.32% ) ( +- 0.81% ) ( +- 0.75% ) ( +- 0.72% )
> %chg time to baseline -1.28% -1.68% -2.59% -2.71% 0.57%
Slowdown for most orders.
> Incase of Kernel compilation, fault around order (fao) of 1 and 3
> provides fast compilation time when compared to a value of 4. On
> closer look, fao of 3 has higher agains. Incase of Sequential access
> synthetic tests fao of 1 has higher gains and in Random access test,
> fao of 3 has marginal gains. Going by compilation time, fao value of
> 3 is suggested in this patch for pseries platform.
So I'm really at loss to understand where you get the optimal value of
'3' from. The data does not seem to match your claim that '1 and 3
provides fast compilation time when compared to a value of 4':
> FAULT_AROUND_ORDER Baseline 1 3 4 5 8
>
> Linux rebuild (make -j64)
> minor-faults 941,552 718,319 486,625 440,124 410,510 397,416
> times in seconds 30.569834718 31.219637539 31.319370649 31.434285472 31.972367174 31.443043580
> stddev for time ( +- 1.07% ) ( +- 0.13% ) ( +- 0.43% ) ( +- 0.18% ) ( +- 0.95% ) ( +- 0.58% )
> %chg time to baseline 2.1% 2.4% 2.8% 4.58% 2.85%
5 and 8, and probably 6, 7 are better than 4.
3 is probably _slower_ than the current default - but it's hard to
tell due to inherent noise.
But the other two build tests were too noisy, and if then they showed
a slowdown.
> Worst case scenario: we touch one page every 16M to demonstrate overhead.
>
> Touch only one page in page table in 16GiB file
> FAULT_AROUND_ORDER Baseline 1 3 4 5 8
> 1 thread
> minor-faults 1,104 1,090 1,071 1,068 1,065 1,063
> times in seconds 0.006583298 0.008531502 0.019733795 0.036033763 0.062300553 0.406857086
> stddev for time ( +- 2.79% ) ( +- 2.42% ) ( +- 3.47% ) ( +- 2.81% ) ( +- 2.01% ) ( +- 1.33% )
> 8 threads
> minor-faults 8,279 8,264 8,245 8,243 8,239 8,240
> times in seconds 0.044572398 0.057211811 0.107606306 0.205626815 0.381679120 2.647979955
> stddev for time ( +- 1.95% ) ( +- 2.98% ) ( +- 1.74% ) ( +- 2.80% ) ( +- 2.01% ) ( +- 1.86% )
> 32 threads
> minor-faults 32,879 32,864 32,849 32,845 32,839 32,843
> times in seconds 0.197659343 0.218486087 0.445116407 0.694235883 1.296894038 9.127517045
> stddev for time ( +- 3.05% ) ( +- 3.05% ) ( +- 4.33% ) ( +- 3.08% ) ( +- 3.75% ) ( +- 0.56% )
> 64 threads
> minor-faults 65,680 65,664 65,646 65,645 65,640 65,647
> times in seconds 0.455537304 0.489688780 0.866490093 1.427393118 2.379628982 17.059295051
> stddev for time ( +- 4.01% ) ( +- 4.13% ) ( +- 2.92% ) ( +- 1.68% ) ( +- 1.79% ) ( +- 0.48% )
> 128 threads
> minor-faults 131,279 131,265 131,250 131,245 131,241 131,254
> times in seconds 1.026880651 1.095327536 1.721728274 2.808233068 4.662729948 31.732848290
> stddev for time ( +- 6.85% ) ( +- 4.09% ) ( +- 1.71% ) ( +- 3.45% ) ( +- 2.40% ) ( +- 0.68% )
There's no '%change' values shown, but the slowdown looks significant,
it's the worst case: for example with 1 thread order 3 looks about
300% slower (3x slowdown) compared to order 0.
All in one, looking at your latest data I don't think the conclusion
from your first version of this optimization patch from a month ago is
true anymore:
> + /* Measured on a 4 socket Power7 system (128 Threads and 128GB memory) */
> + fault_around_order = 3;
As the data is rather conflicting and inconclusive, and if it shows a
sweet spot it's not at order 3. New data should in general trigger
reanalysis of your first optimization value.
I'm starting to suspect that maybe workloads ought to be given a
choice in this matter, via madvise() or such.
Thanks,
Ingo
^ permalink raw reply
* Re: [PATCH 0/3] Add new ptrace request macros on PowerPC
From: Michael Neuling @ 2014-04-29 7:06 UTC (permalink / raw)
To: Anshuman Khandual; +Cc: Linux PPC dev, linux-kernel, avagin, roland, oleg
In-Reply-To: <535F4E10.2020300@linux.vnet.ibm.com>
[-- Attachment #1: Type: text/plain, Size: 3581 bytes --]
How is it causing the problem?
Mikey
On 29 Apr 2014 17:02, "Anshuman Khandual" <khandual@linux.vnet.ibm.com>
wrote:
>
> On 04/02/2014 03:02 PM, Anshuman Khandual wrote:
> > On 04/02/2014 12:32 PM, Anshuman Khandual wrote:
> >> This patch series adds new ELF note sections which are used to
> >> create new ptrace request macros for various transactional memory and
> >> miscellaneous registers on PowerPC. Please find the test case
exploiting
> >> the new ptrace request macros and it's results on a POWER8 system.
> >>
> >> RFC: https://lkml.org/lkml/2014/4/1/292
> >>
> >> ============================== Results ==============================
> >> -------TM specific SPR------
> >> TM TFHAR: 100009dc
> >> TM TEXASR: de000001ac000001
> >> TM TFIAR: c00000000003f386
> >> TM CH ORIG_MSR: 900000050000f032
> >> TM CH TAR: 6
> >> TM CH PPR: c000000000000
> >> TM CH DSCR: 1
> >> -------TM checkpointed GPR-----
> >> TM CH GPR[0]: 1000097c
> >> TM CH GPR[1]: 5
> >> TM CH GPR[2]: 6
> >> TM CH GPR[7]: 1
> >> TM CH NIP: 100009dc
> >> TM CH LINK: 1000097c
> >> TM CH CCR: 22000422
> >> -------TM running GPR-----
> >> TM RN GPR[0]: 1000097c
> >> TM RN GPR[1]: 7
> >> TM RN GPR[2]: 8
> >> TM RN GPR[7]: 5
> >> TM RN NIP: 100009fc
> >> TM RN LINK: 1000097c
> >> TM RN CCR: 2000422
> >> -------TM running FPR-----
> >> TM RN FPR[0]: 1002d3a3780
> >> TM RN FPR[1]: 7
> >> TM RN FPR[2]: 8
> >> TM RN FPSCR: 0
> >> -------TM checkpointed FPR-----
> >> TM CH FPR[0]: 1002d3a3780
> >> TM CH FPR[1]: 5
> >> TM CH FPR[2]: 6
> >> TM CH FPSCR: 0
> >> -------Running miscellaneous registers-------
> > TM RN DSCR: 0
> >
> > There is a problem in here which I forgot to mention. The running DSCR
value
> > comes from thread->dscr component of the target process. While we are
inside the
> > transaction (which is the case here as we are stuck at "b ."
instruction and
> > have not reached TEND) thread->dscr should have the running value of
the DSCR
> > register at that point of time. Here we expect the DSCR value to be 5
instead
> > of 0 as shown in the output above. During the tests when I moved the "b
." after
> > TEND, the thread->dscr gets the value of 5 while all check pointed reg
values are
> > thrown away. I believe there is some problem in the way thread->dscr
context
> > is saved away inside the TM section. Will look into this problem
further and
> > keep informed.
>
> Reason behind this inconsistent DSCR register value is because of the
following commit
> where the kernel reverts the DSCR register into a default value to avoid
running with
> the user set value for a long time, thus preventing any potential
performance degradation.
> Same reason applies to the PPR register as well. So its not a problem but
an expected
> behaviour.
>
> commit e9bdc3d6143d1c4b8d8ce5231fc958268331f983
> Author: Michael Neuling <mikey@neuling.org>
> Date: Thu Sep 26 13:29:09 2013 +1000
>
> powerpc/tm: Switch out userspace PPR and DSCR sooner
>
> When we do a treclaim or trecheckpoint we end up running with
userspace
> PPR and DSCR values. Currently we don't do anything special to avoid
> running with user values which could cause a severe performance
> degradation.
>
> This patch moves the PPR and DSCR save and restore around treclaim and
> trecheckpoint so that we run with user values for a much shorter
period.
> More care is taken with the PPR as it's impact is greater than the
DSCR.
>
> This is similar to user exceptions, where we run HTM_MEDIUM early to
> ensure that we don't run with a userspace PPR values in the kernel.
>
[-- Attachment #2: Type: text/html, Size: 4832 bytes --]
^ permalink raw reply
* Re: [PATCH 0/3] Add new ptrace request macros on PowerPC
From: Anshuman Khandual @ 2014-04-29 7:00 UTC (permalink / raw)
To: Anshuman Khandual; +Cc: mikey, avagin, linux-kernel, oleg, linuxppc-dev, roland
In-Reply-To: <533BD922.4070009@linux.vnet.ibm.com>
On 04/02/2014 03:02 PM, Anshuman Khandual wrote:
> On 04/02/2014 12:32 PM, Anshuman Khandual wrote:
>> This patch series adds new ELF note sections which are used to
>> create new ptrace request macros for various transactional memory and
>> miscellaneous registers on PowerPC. Please find the test case exploiting
>> the new ptrace request macros and it's results on a POWER8 system.
>>
>> RFC: https://lkml.org/lkml/2014/4/1/292
>>
>> ============================== Results ==============================
>> -------TM specific SPR------
>> TM TFHAR: 100009dc
>> TM TEXASR: de000001ac000001
>> TM TFIAR: c00000000003f386
>> TM CH ORIG_MSR: 900000050000f032
>> TM CH TAR: 6
>> TM CH PPR: c000000000000
>> TM CH DSCR: 1
>> -------TM checkpointed GPR-----
>> TM CH GPR[0]: 1000097c
>> TM CH GPR[1]: 5
>> TM CH GPR[2]: 6
>> TM CH GPR[7]: 1
>> TM CH NIP: 100009dc
>> TM CH LINK: 1000097c
>> TM CH CCR: 22000422
>> -------TM running GPR-----
>> TM RN GPR[0]: 1000097c
>> TM RN GPR[1]: 7
>> TM RN GPR[2]: 8
>> TM RN GPR[7]: 5
>> TM RN NIP: 100009fc
>> TM RN LINK: 1000097c
>> TM RN CCR: 2000422
>> -------TM running FPR-----
>> TM RN FPR[0]: 1002d3a3780
>> TM RN FPR[1]: 7
>> TM RN FPR[2]: 8
>> TM RN FPSCR: 0
>> -------TM checkpointed FPR-----
>> TM CH FPR[0]: 1002d3a3780
>> TM CH FPR[1]: 5
>> TM CH FPR[2]: 6
>> TM CH FPSCR: 0
>> -------Running miscellaneous registers-------
> TM RN DSCR: 0
>
> There is a problem in here which I forgot to mention. The running DSCR value
> comes from thread->dscr component of the target process. While we are inside the
> transaction (which is the case here as we are stuck at "b ." instruction and
> have not reached TEND) thread->dscr should have the running value of the DSCR
> register at that point of time. Here we expect the DSCR value to be 5 instead
> of 0 as shown in the output above. During the tests when I moved the "b ." after
> TEND, the thread->dscr gets the value of 5 while all check pointed reg values are
> thrown away. I believe there is some problem in the way thread->dscr context
> is saved away inside the TM section. Will look into this problem further and
> keep informed.
Reason behind this inconsistent DSCR register value is because of the following commit
where the kernel reverts the DSCR register into a default value to avoid running with
the user set value for a long time, thus preventing any potential performance degradation.
Same reason applies to the PPR register as well. So its not a problem but an expected
behaviour.
commit e9bdc3d6143d1c4b8d8ce5231fc958268331f983
Author: Michael Neuling <mikey@neuling.org>
Date: Thu Sep 26 13:29:09 2013 +1000
powerpc/tm: Switch out userspace PPR and DSCR sooner
When we do a treclaim or trecheckpoint we end up running with userspace
PPR and DSCR values. Currently we don't do anything special to avoid
running with user values which could cause a severe performance
degradation.
This patch moves the PPR and DSCR save and restore around treclaim and
trecheckpoint so that we run with user values for a much shorter period.
More care is taken with the PPR as it's impact is greater than the DSCR.
This is similar to user exceptions, where we run HTM_MEDIUM early to
ensure that we don't run with a userspace PPR values in the kernel.
^ permalink raw reply
* Re: [PATCH 1/2] powerpc/powernv: reduce multi-hit of iommu_add_device()
From: Wei Yang @ 2014-04-29 6:49 UTC (permalink / raw)
To: Alexey Kardashevskiy; +Cc: linuxppc-dev, gwshan
In-Reply-To: <535E5924.8040503@au1.ibm.com>
On Mon, Apr 28, 2014 at 11:35:32PM +1000, Alexey Kardashevskiy wrote:
>On 04/23/2014 12:26 PM, Wei Yang wrote:
>> During the EEH hotplug event, iommu_add_device() will be invoked three times
>> and two of them will trigger warning or error.
>>
>> The three times to invoke the iommu_add_device() are:
>>
>> pci_device_add
>> ...
>> set_iommu_table_base_and_group <- 1st time, fail
>> device_add
>> ...
>> tce_iommu_bus_notifier <- 2nd time, succees
>> pcibios_add_pci_devices
>> ...
>> pcibios_setup_bus_devices <- 3rd time, re-attach
>>
>> The first time fails, since the dev->kobj->sd is not initialized. The
>> dev->kobj->sd is initialized in device_add().
>> The third time's warning is triggered by the re-attach of the iommu_group.
>>
>> After applying this patch, the error
>
>Nack.
>
>The patch still seems incorrect and we actually need to remove
>tce_iommu_bus_notifier completely as pcibios_setup_bus_devices is called
>from another notifier anyway. Could you please test it?
>
>
Hi, Alexey,
Nice to see your comment. Let me show what I got fist.
Generally, when kernel enumerate on the pci device, following functions will
be invoked.
pci_device_add
pcibios_setup_bus_device
...
set_iommu_table_base_and_group
device_add
...
tce_iommu_bus_notifier
pcibios_fixp_bus
pcibios_add_pci_devices
...
pcibios_setup_bus_devices
>From the call flow, we see for a normall pci device, the
pcibios_setup_bus_device() will be invoked twice.
At the bootup time, none of them succeed to setup the dma, since the PE is not
assigned or the tbl is not set. The iommu tbl and group is setup in
pnv_pci_ioda_setup_DMA().
This call flow maintains the same when EEH error happens on Bus PE, while the
behavior is a little different.
pci_device_add
pcibios_setup_bus_device
...
set_iommu_table_base_and_group <- fail, kobj->sd is not initialized
device_add
...
tce_iommu_bus_notifier <- succeed
pcibios_fixp_bus
pcibios_add_pci_devices
...
pcibios_setup_bus_devices <- warning, re-attach
While this call flow will change a little on a VF. For a VF,
pcibios_fixp_bus() will not be invoked. Current behavior is this.
pci_device_add
pcibios_setup_bus_device
...
set_iommu_table_base_and_group <- fail, kobj->sd is not initialized
device_add
...
tce_iommu_bus_notifier <- succeed
And if an EEH error happens just on a VF, I believe the same call flow should
go for recovery. (This is not set down, still under discussion with Gavin.)
My conclusion is:
1. remove the tce_iommu_bus_notifier completely will make the VF not work.
So I choose to revert the code and attach make the iommu group attachment
just happens in one place.
BTW, I know my patch is not a perfect one. For a PF, the tbl will still be set
twice. I am not sure why we need to invoke pcibios_setup_device() twice on a
PF, maybe some platform need to fixup some thing after the pci_bus is added.
So I don't remove one of them to solve the problem.
If you have a better idea, I am glad to take it.
--
Richard Yang
Help you, Help me
^ permalink raw reply
* RE: [PATCH] powerpc/fsl-rio: Fix fsl_rio_setup error paths and use-after-unmap
From: Gang.Liu @ 2014-04-29 4:04 UTC (permalink / raw)
To: Scott Wood, linuxppc-dev@lists.ozlabs.org
In-Reply-To: <1398735103-16513-1-git-send-email-scottwood@freescale.com>
> -----Original Message-----
> From: Wood Scott-B07421
> Sent: Tuesday, April 29, 2014 9:32 AM
> To: linuxppc-dev@lists.ozlabs.org
> Cc: Wood Scott-B07421; Liu Gang-B34182
> Subject: [PATCH] powerpc/fsl-rio: Fix fsl_rio_setup error paths and use-
> after-unmap
>=20
> Several of the error paths from fsl_rio_setup are missing error messages.
>=20
> Worse, fsl_rio_setup initializes several global pointers and does not
> NULL them out after freeing/unmapping on error. This caused
> fsl_rio_mcheck_exception() to crash when accessing rio_regs_win which was
> non-NULL but had been unmapped.
>=20
> Signed-off-by: Scott Wood <scottwood@freescale.com>
> Cc: Liu Gang <Gang.Liu@freescale.com>
> ---
> Liu Gang, are you sure all of these error conditions are fatal? Why does
> the rio driver fail if rmu is not present (e.g. on t4240)?
Hi Scott, I think the errors you modified in the patch are serious and shou=
ld
be fixed. Thanks very much!
And in fact, the rio driver can be used just for the submodule of the SRIO:=
RMU.
It should be used with arch/powerpc/sysdev/fsl_rmu.c and there should have =
the
RMU module.
The fsl_rio.c implements some basic and needed works to support the RMU run=
ning well.
In addition, could you please help to apply the following patch:
http://patchwork.ozlabs.org/patch/337810/
Thanks!
Liu Gang =20
> ---
> arch/powerpc/sysdev/fsl_rio.c | 10 +++++++++-
> 1 file changed, 9 insertions(+), 1 deletion(-)
^ permalink raw reply
* Re: [PATCH v2 6/6] powerpc/perf/hv-24x7: catalog version number is be64, not be32
From: Michael Ellerman @ 2014-04-29 3:12 UTC (permalink / raw)
To: Cody P Schafer; +Cc: David.Laight, Linux PPC, LKML, Anton Blanchard
In-Reply-To: <535DE027.5050700@linux.vnet.ibm.com>
On Sun, 2014-04-27 at 21:59 -0700, Cody P Schafer wrote:
> On 04/27/2014 09:47 PM, Benjamin Herrenschmidt wrote:
> > On Tue, 2014-04-15 at 10:10 -0700, Cody P Schafer wrote:
> >> The catalog version number was changed from a be32 (with proceeding
> >> 32bits of padding) to a be64, update the code to treat it as a be64
> >>
> >> Signed-off-by: Cody P Schafer <cody@linux.vnet.ibm.com>
> >> --
> >
> > Have you tested this ?
> >
> > It doesn't build for me:
> >
> > arch/powerpc/perf/hv-24x7.c: In function 'catalog_read':
> > arch/powerpc/perf/hv-24x7.c:223:3: error: format '%d' expects argument of type 'int', but argument 2 has type 'uint64_t' [-Werror=format]
> > cc1: all warnings being treated as errors
>
> I have, and I wasn't initially sure how I managed to miss that
> warning-as-error. On examination: My config (for some reason) has
> CONFIG_PPC_DISABLE_WERROR=y set (probably because it's a variation of a
> distro config).
Please test build with ppc64_defconfig at least.
cheers
^ permalink raw reply
* Re: [PATCH V3 2/2] powerpc/pseries: init fault_around_order for pseries
From: Rusty Russell @ 2014-04-29 2:18 UTC (permalink / raw)
To: Madhavan Srinivasan, linux-kernel, linuxppc-dev, linux-mm,
linux-arch, x86
Cc: riel, ak, peterz, dave.hansen, Madhavan Srinivasan, paulus,
mgorman, akpm, mingo, kirill.shutemov
In-Reply-To: <1398675690-16186-3-git-send-email-maddy@linux.vnet.ibm.com>
Madhavan Srinivasan <maddy@linux.vnet.ibm.com> writes:
> diff --git a/arch/powerpc/platforms/pseries/setup.c b/arch/powerpc/platforms/pseries/setup.c
> index 2db8cc6..c87e6b6 100644
> --- a/arch/powerpc/platforms/pseries/setup.c
> +++ b/arch/powerpc/platforms/pseries/setup.c
> @@ -74,6 +74,8 @@ int CMO_SecPSP = -1;
> unsigned long CMO_PageSize = (ASM_CONST(1) << IOMMU_PAGE_SHIFT_4K);
> EXPORT_SYMBOL(CMO_PageSize);
>
> +extern unsigned int fault_around_order;
> +
It's considered bad form to do this. Put the declaration in linux/mm.h.
Thanks,
Rusty.
PS. But we're getting there! :)
^ permalink raw reply
* [PATCH] powerpc/fsl-rio: Fix fsl_rio_setup error paths and use-after-unmap
From: Scott Wood @ 2014-04-29 1:31 UTC (permalink / raw)
To: linuxppc-dev; +Cc: Scott Wood, Liu Gang
Several of the error paths from fsl_rio_setup are missing error
messages.
Worse, fsl_rio_setup initializes several global pointers and does not
NULL them out after freeing/unmapping on error. This caused
fsl_rio_mcheck_exception() to crash when accessing rio_regs_win which
was non-NULL but had been unmapped.
Signed-off-by: Scott Wood <scottwood@freescale.com>
Cc: Liu Gang <Gang.Liu@freescale.com>
---
Liu Gang, are you sure all of these error conditions are fatal? Why
does the rio driver fail if rmu is not present (e.g. on t4240)?
---
arch/powerpc/sysdev/fsl_rio.c | 10 +++++++++-
1 file changed, 9 insertions(+), 1 deletion(-)
diff --git a/arch/powerpc/sysdev/fsl_rio.c b/arch/powerpc/sysdev/fsl_rio.c
index cf2b084..c04b718 100644
--- a/arch/powerpc/sysdev/fsl_rio.c
+++ b/arch/powerpc/sysdev/fsl_rio.c
@@ -391,8 +391,10 @@ int fsl_rio_setup(struct platform_device *dev)
ops->get_inb_message = fsl_get_inb_message;
rmu_node = of_parse_phandle(dev->dev.of_node, "fsl,srio-rmu-handle", 0);
- if (!rmu_node)
+ if (!rmu_node) {
+ dev_err(&dev->dev, "No valid fsl,srio-rmu-handle property\n");
goto err_rmu;
+ }
rc = of_address_to_resource(rmu_node, 0, &rmu_regs);
if (rc) {
dev_err(&dev->dev, "Can't get %s property 'reg'\n",
@@ -413,6 +415,7 @@ int fsl_rio_setup(struct platform_device *dev)
/*set up doobell node*/
np = of_find_compatible_node(NULL, NULL, "fsl,srio-dbell-unit");
if (!np) {
+ dev_err(&dev->dev, "No fsl,srio-dbell-unit node\n");
rc = -ENODEV;
goto err_dbell;
}
@@ -441,6 +444,7 @@ int fsl_rio_setup(struct platform_device *dev)
/*set up port write node*/
np = of_find_compatible_node(NULL, NULL, "fsl,srio-port-write-unit");
if (!np) {
+ dev_err(&dev->dev, "No fsl,srio-port-write-unit node\n");
rc = -ENODEV;
goto err_pw;
}
@@ -633,14 +637,18 @@ int fsl_rio_setup(struct platform_device *dev)
return 0;
err:
kfree(pw);
+ pw = NULL;
err_pw:
kfree(dbell);
+ dbell = NULL;
err_dbell:
iounmap(rmu_regs_win);
+ rmu_regs_win = NULL;
err_rmu:
kfree(ops);
err_ops:
iounmap(rio_regs_win);
+ rio_regs_win = NULL;
err_rio_regs:
return rc;
}
--
1.9.1
^ permalink raw reply related
* Re: [git pull] Please pull abiv2 branch
From: Rusty Russell @ 2014-04-29 0:33 UTC (permalink / raw)
To: Philippe Bergheaud, Anton Blanchard
Cc: philippe.bergheaud, mikey, amodra, rostedt, ulrich.weigand, mjw,
paulus, linuxppc-dev
In-Reply-To: <535E6804.5050508@linux.vnet.ibm.com>
Philippe Bergheaud <felix@linux.vnet.ibm.com> writes:
> Anton Blanchard wrote:
>> Here are the ABIv2 patches rebased against 3.15-rc2.
>
> After recompiling 3.15-rc2 with the ABIv2 patches,
> I see the following line in Modules.symvers:
>
> 0x00000000 TOC. vmlinux EXPORT_SYMBOL
>
> Kernel will not load modules because TOC. has no CRC.
> Is this expected ? Shouldn't TOC. have a CRC ?
What happens when you try to load a module? It should work...
Cheers,
Rusty.
^ permalink raw reply
* [PATCH 1/1] powerpc: crtsaveres.o needed only when -Os flag is enabled
From: Ram Pai @ 2014-04-29 0:05 UTC (permalink / raw)
To: benh, paulus; +Cc: Ram Pai, linuxppc-dev, hartb, anton, tony
powerpc: crtsaveres.o needed only when -Os flag is enabled
Currently on powerpc arch, out-of-tree module fails to build without
crtsaveres.o, even when the module has no dependency on the symbols
provided by the file; when built without the -Os flag.
BTW: '-Os' flag is enabled when CONFIG_CC_OPTIMIZE_FOR_SIZE is
configured.
This patch fixes that problem.
Signed-off-by: Ram Pai <linuxram@us.ibm.com>
diff --git a/arch/powerpc/Makefile b/arch/powerpc/Makefile
index 4c0cedf..cf12f38 100644
--- a/arch/powerpc/Makefile
+++ b/arch/powerpc/Makefile
@@ -157,7 +157,10 @@ CPP = $(CC) -E $(KBUILD_CFLAGS)
CHECKFLAGS += -m$(CONFIG_WORD_SIZE) -D__powerpc__ -D__powerpc$(CONFIG_WORD_SIZE)__
+ifdef CONFIG_CC_OPTIMIZE_FOR_SIZE
KBUILD_LDFLAGS_MODULE += arch/powerpc/lib/crtsavres.o
+endif
+
# No AltiVec or VSX instructions when building kernel
KBUILD_CFLAGS += $(call cc-option,-mno-altivec)
^ permalink raw reply related
* Re: [git pull] Please pull abiv2 branch
From: Alan Modra @ 2014-04-28 23:46 UTC (permalink / raw)
To: Philippe Bergheaud
Cc: philippe.bergheaud, mikey, rusty, rostedt, ulrich.weigand, paulus,
Anton Blanchard, mjw, linuxppc-dev
In-Reply-To: <535E6804.5050508@linux.vnet.ibm.com>
On Mon, Apr 28, 2014 at 04:39:00PM +0200, Philippe Bergheaud wrote:
> Kernel will not load modules because TOC. has no CRC.
> Is this expected ? Shouldn't TOC. have a CRC ?
TOC. is really .TOC. (The kernel build process strips off a leading
dot from symbol names.) .TOC. is a special symbol giving the toc
base, so no, it shouldn't have a CRC.
--
Alan Modra
Australia Development Lab, IBM
^ permalink raw reply
* [PATCH 1/3][RFC][v1] kconfig: Change COMMAND_LINE_SIZE to a kernel config option, which is now set per architecture.
From: Joseph Salisbury @ 2014-04-28 21:11 UTC (permalink / raw)
To: linux-kernel, benh, paulus; +Cc: linuxppc-dev, anton
In-Reply-To: <cover.1398287636.git.joseph.salisbury@canonical.com>
Having COMMAND_LINE_SIZE a kernel config option is a cleaner way to modify the value if needed. Currently defines need to be changed within the architecture specific header files.
The default COMMAND_LINE_SIZE for asm-generic is still set by a define in include/asm-generic/setup.h.
Signed-off-by: Joseph Salisbury <joseph.salisbury@canonical.com>
---
arch/alpha/Kconfig | 6 ++++++
arch/alpha/include/uapi/asm/setup.h | 4 +++-
arch/arc/Kconfig | 6 ++++++
arch/arc/include/asm/setup.h | 4 +++-
arch/arm/Kconfig | 6 ++++++
arch/arm/include/uapi/asm/setup.h | 4 +++-
arch/arm64/Kconfig | 6 ++++++
arch/arm64/include/uapi/asm/setup.h | 4 +++-
arch/avr32/Kconfig | 6 ++++++
arch/avr32/include/uapi/asm/setup.h | 4 +++-
arch/c6x/Kconfig | 6 ++++++
arch/c6x/include/uapi/asm/setup.h | 4 +++-
arch/cris/Kconfig | 6 ++++++
arch/cris/include/uapi/asm/setup.h | 4 +++-
arch/frv/Kconfig | 6 ++++++
arch/frv/include/uapi/asm/setup.h | 5 +++--
arch/ia64/Kconfig | 6 ++++++
arch/ia64/include/uapi/asm/setup.h | 4 +++-
arch/m32r/Kconfig | 6 ++++++
arch/m32r/include/uapi/asm/setup.h | 5 +++--
arch/m68k/Kconfig | 6 ++++++
arch/m68k/include/uapi/asm/setup.h | 4 +++-
arch/microblaze/Kconfig | 6 ++++++
arch/microblaze/include/uapi/asm/setup.h | 4 +++-
arch/mips/Kconfig | 6 ++++++
arch/mips/include/uapi/asm/setup.h | 5 +++--
arch/mn10300/Kconfig | 6 ++++++
arch/mn10300/include/uapi/asm/param.h | 4 +++-
arch/parisc/Kconfig | 6 ++++++
arch/parisc/include/uapi/asm/setup.h | 4 +++-
arch/powerpc/Kconfig | 6 ++++++
arch/powerpc/boot/ops.h | 5 ++++-
arch/s390/Kconfig | 6 ++++++
arch/s390/include/uapi/asm/setup.h | 4 +++-
arch/score/Kconfig | 6 ++++++
arch/score/include/uapi/asm/setup.h | 5 ++++-
arch/sparc/Kconfig | 7 +++++++
arch/sparc/include/uapi/asm/setup.h | 7 ++-----
arch/tile/Kconfig | 6 ++++++
arch/tile/include/uapi/asm/setup.h | 5 +++--
arch/um/Kconfig.um | 6 ++++++
arch/um/include/asm/setup.h | 4 +++-
arch/x86/Kconfig | 6 ++++++
arch/x86/include/asm/setup.h | 4 +++-
arch/xtensa/Kconfig | 6 ++++++
arch/xtensa/include/uapi/asm/setup.h | 4 +++-
include/uapi/asm-generic/setup.h | 2 +-
47 files changed, 210 insertions(+), 32 deletions(-)
diff --git a/arch/alpha/Kconfig b/arch/alpha/Kconfig
index b7ff9a3..42bd2e7 100644
--- a/arch/alpha/Kconfig
+++ b/arch/alpha/Kconfig
@@ -563,6 +563,12 @@ config HAVE_DEC_LOCK
depends on SMP
default y
+config COMMAND_LINE_SIZE
+ int "Maximum size of the command line"
+ default "256"
+ help
+ This is the per architecture maximum command line size.
+
config NR_CPUS
int "Maximum number of CPUs (2-32)"
range 2 32
diff --git a/arch/alpha/include/uapi/asm/setup.h b/arch/alpha/include/uapi/asm/setup.h
index b50014b..f2956cc 100644
--- a/arch/alpha/include/uapi/asm/setup.h
+++ b/arch/alpha/include/uapi/asm/setup.h
@@ -1,7 +1,9 @@
#ifndef __ALPHA_SETUP_H
#define __ALPHA_SETUP_H
-#define COMMAND_LINE_SIZE 256
+#ifdef CONFIG_COMMAND_LINE_SIZE
+#define COMMAND_LINE_SIZE CONFIG_COMMAND_LINE_SIZE
+#endif
/*
* We leave one page for the initial stack page, and one page for
diff --git a/arch/arc/Kconfig b/arch/arc/Kconfig
index 9596b0a..b9e5351 100644
--- a/arch/arc/Kconfig
+++ b/arch/arc/Kconfig
@@ -141,6 +141,12 @@ config ARC_HAS_REENTRANT_IRQ_LV2
endif
+config COMMAND_LINE_SIZE
+ int "Maximum size of the command line."
+ default "256"
+ help
+ This is the per architecture maximum command line size.
+
config NR_CPUS
int "Maximum number of CPUs (2-4096)"
range 2 4096
diff --git a/arch/arc/include/asm/setup.h b/arch/arc/include/asm/setup.h
index e10f8ce..9708f1a 100644
--- a/arch/arc/include/asm/setup.h
+++ b/arch/arc/include/asm/setup.h
@@ -12,7 +12,9 @@
#include <linux/types.h>
#include <uapi/asm/setup.h>
-#define COMMAND_LINE_SIZE 256
+#ifdef CONFIG_COMMAND_LINE_SIZE
+#define COMMAND_LINE_SIZE CONFIG_COMMAND_LINE_SIZE
+#endif
/*
* Data structure to map a ID to string
diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
index ab438cb..d5fadfa 100644
--- a/arch/arm/Kconfig
+++ b/arch/arm/Kconfig
@@ -1615,6 +1615,12 @@ config PAGE_OFFSET
default 0x80000000 if VMSPLIT_2G
default 0xC0000000
+config COMMAND_LINE_SIZE
+ int "Maximum size of the command line."
+ default "1024"
+ help
+ This is the per architecture maximum command line size.
+
config NR_CPUS
int "Maximum number of CPUs (2-32)"
range 2 32
diff --git a/arch/arm/include/uapi/asm/setup.h b/arch/arm/include/uapi/asm/setup.h
index 979ff40..9cded84 100644
--- a/arch/arm/include/uapi/asm/setup.h
+++ b/arch/arm/include/uapi/asm/setup.h
@@ -16,7 +16,9 @@
#include <linux/types.h>
-#define COMMAND_LINE_SIZE 1024
+#ifdef CONFIG_COMMAND_LINE_SIZE
+#define COMMAND_LINE_SIZE CONFIG_COMMAND_LINE_SIZE
+#endif
/* The list ends with an ATAG_NONE node. */
#define ATAG_NONE 0x00000000
diff --git a/arch/arm64/Kconfig b/arch/arm64/Kconfig
index e6e4d37..528845f 100644
--- a/arch/arm64/Kconfig
+++ b/arch/arm64/Kconfig
@@ -186,6 +186,12 @@ config SCHED_SMT
MultiThreading at a cost of slightly increased overhead in some
places. If unsure say N here.
+config COMMAND_LINE_SIZE
+ int "Maximum size of the command line."
+ default "2048"
+ help
+ This is the per architecture maximum command line size.
+
config NR_CPUS
int "Maximum number of CPUs (2-32)"
range 2 32
diff --git a/arch/arm64/include/uapi/asm/setup.h b/arch/arm64/include/uapi/asm/setup.h
index 9cf2e46..f5ade83 100644
--- a/arch/arm64/include/uapi/asm/setup.h
+++ b/arch/arm64/include/uapi/asm/setup.h
@@ -21,6 +21,8 @@
#include <linux/types.h>
-#define COMMAND_LINE_SIZE 2048
+#ifdef CONFIG_COMMAND_LINE_SIZE
+#define COMMAND_LINE_SIZE CONFIG_COMMAND_LINE_SIZE
+#endif
#endif
diff --git a/arch/avr32/Kconfig b/arch/avr32/Kconfig
index b6878eb..e1ebdd6 100644
--- a/arch/avr32/Kconfig
+++ b/arch/avr32/Kconfig
@@ -233,6 +233,12 @@ config NMI_DEBUGGING
source "kernel/Kconfig.hz"
+config COMMAND_LINE_SIZE
+ int "Maximum size of the command line."
+ default "256"
+ help
+ This is the per architecture maximum command line size.
+
config CMDLINE
string "Default kernel command line"
default ""
diff --git a/arch/avr32/include/uapi/asm/setup.h b/arch/avr32/include/uapi/asm/setup.h
index a654df7..b78cc6d 100644
--- a/arch/avr32/include/uapi/asm/setup.h
+++ b/arch/avr32/include/uapi/asm/setup.h
@@ -11,6 +11,8 @@
#ifndef _UAPI__ASM_AVR32_SETUP_H__
#define _UAPI__ASM_AVR32_SETUP_H__
-#define COMMAND_LINE_SIZE 256
+#ifdef CONFIG_COMMAND_LINE_SIZE
+#define COMMAND_LINE_SIZE CONFIG_COMMAND_LINE_SIZE
+#endif
#endif /* _UAPI__ASM_AVR32_SETUP_H__ */
diff --git a/arch/c6x/Kconfig b/arch/c6x/Kconfig
index 77ea09b..9a91e99 100644
--- a/arch/c6x/Kconfig
+++ b/arch/c6x/Kconfig
@@ -57,6 +57,12 @@ source "kernel/Kconfig.freezer"
config CMDLINE_BOOL
bool "Default bootloader kernel arguments"
+config COMMAND_LINE_SIZE
+ int "Maximum size of the command line."
+ default "1024"
+ help
+ This is the per architecture maximum command line size.
+
config CMDLINE
string "Kernel command line"
depends on CMDLINE_BOOL
diff --git a/arch/c6x/include/uapi/asm/setup.h b/arch/c6x/include/uapi/asm/setup.h
index ad9ac97..73e46d3 100644
--- a/arch/c6x/include/uapi/asm/setup.h
+++ b/arch/c6x/include/uapi/asm/setup.h
@@ -1,6 +1,8 @@
#ifndef _UAPI_ASM_C6X_SETUP_H
#define _UAPI_ASM_C6X_SETUP_H
-#define COMMAND_LINE_SIZE 1024
+#ifdef CONFIG_COMMAND_LINE_SIZE
+#define COMMAND_LINE_SIZE CONFIG_COMMAND_LINE_SIZE
+#endif
#endif /* _UAPI_ASM_C6X_SETUP_H */
diff --git a/arch/cris/Kconfig b/arch/cris/Kconfig
index 52731e2..d4dd8bc 100644
--- a/arch/cris/Kconfig
+++ b/arch/cris/Kconfig
@@ -65,6 +65,12 @@ menu "General setup"
source "fs/Kconfig.binfmt"
+config COMMAND_LINE_SIZE
+ int "Maximum size of the command line."
+ default "256"
+ help
+ This is the per architecture maximum command line size.
+
config ETRAX_CMDLINE
string "Kernel command line"
default "root=/dev/mtdblock3"
diff --git a/arch/cris/include/uapi/asm/setup.h b/arch/cris/include/uapi/asm/setup.h
index b907286..fbad81d 100644
--- a/arch/cris/include/uapi/asm/setup.h
+++ b/arch/cris/include/uapi/asm/setup.h
@@ -1,6 +1,8 @@
#ifndef _CRIS_SETUP_H
#define _CRIS_SETUP_H
-#define COMMAND_LINE_SIZE 256
+#ifdef CONFIG_COMMAND_LINE_SIZE
+#define COMMAND_LINE_SIZE CONFIG_COMMAND_LINE_SIZE
+#endif
#endif
diff --git a/arch/frv/Kconfig b/arch/frv/Kconfig
index 34aa193..6f5b071 100644
--- a/arch/frv/Kconfig
+++ b/arch/frv/Kconfig
@@ -54,6 +54,12 @@ config HZ
int
default 1000
+config COMMAND_LINE_SIZE
+ int "Maximum size of the command line."
+ default "512"
+ help
+ This is the per architecture maximum command line size.
+
source "init/Kconfig"
source "kernel/Kconfig.freezer"
diff --git a/arch/frv/include/uapi/asm/setup.h b/arch/frv/include/uapi/asm/setup.h
index fbf3fc9..c4ed2bf 100644
--- a/arch/frv/include/uapi/asm/setup.h
+++ b/arch/frv/include/uapi/asm/setup.h
@@ -12,7 +12,8 @@
#ifndef _UAPI_ASM_SETUP_H
#define _UAPI_ASM_SETUP_H
-#define COMMAND_LINE_SIZE 512
-
+#ifdef CONFIG_COMMAND_LINE_SIZE
+#define COMMAND_LINE_SIZE CONFIG_COMMAND_LINE_SIZE
+#endif
#endif /* _UAPI_ASM_SETUP_H */
diff --git a/arch/ia64/Kconfig b/arch/ia64/Kconfig
index 12c3afe..92c1754 100644
--- a/arch/ia64/Kconfig
+++ b/arch/ia64/Kconfig
@@ -352,6 +352,12 @@ config SMP
If you don't know what to do here, say N.
+config COMMAND_LINE_SIZE
+ int "Maximum size of the command line."
+ default "2048"
+ help
+ This is the per architecture maximum command line size.
+
config NR_CPUS
int "Maximum number of CPUs (2-4096)"
range 2 4096
diff --git a/arch/ia64/include/uapi/asm/setup.h b/arch/ia64/include/uapi/asm/setup.h
index 8d56458..ecfeea7 100644
--- a/arch/ia64/include/uapi/asm/setup.h
+++ b/arch/ia64/include/uapi/asm/setup.h
@@ -1,7 +1,9 @@
#ifndef __IA64_SETUP_H
#define __IA64_SETUP_H
-#define COMMAND_LINE_SIZE 2048
+#ifdef CONFIG_COMMAND_LINE_SIZE
+#define COMMAND_LINE_SIZE CONFIG_COMMAND_LINE_SIZE
+#endif
extern struct ia64_boot_param {
__u64 command_line; /* physical address of command line arguments */
diff --git a/arch/m32r/Kconfig b/arch/m32r/Kconfig
index 9e44bbd..72c265c 100644
--- a/arch/m32r/Kconfig
+++ b/arch/m32r/Kconfig
@@ -300,6 +300,12 @@ config CHIP_M32700_TS1
depends on (CHIP_M32700 && SMP)
default n
+config COMMAND_LINE_SIZE
+ int "Maximum size of the command line."
+ default "512"
+ help
+ This is the per architecture maximum command line size.
+
config NR_CPUS
int "Maximum number of CPUs (2-32)"
range 2 32
diff --git a/arch/m32r/include/uapi/asm/setup.h b/arch/m32r/include/uapi/asm/setup.h
index 96961a4..a45fbef 100644
--- a/arch/m32r/include/uapi/asm/setup.h
+++ b/arch/m32r/include/uapi/asm/setup.h
@@ -5,7 +5,8 @@
* This is set up by the setup-routine at boot-time
*/
-#define COMMAND_LINE_SIZE 512
-
+#ifdef CONFIG_COMMAND_LINE_SIZE
+#define COMMAND_LINE_SIZE CONFIG_COMMAND_LINE_SIZE
+#endif
#endif /* _UAPI_ASM_M32R_SETUP_H */
diff --git a/arch/m68k/Kconfig b/arch/m68k/Kconfig
index 87b7c75..9f68b97 100644
--- a/arch/m68k/Kconfig
+++ b/arch/m68k/Kconfig
@@ -124,6 +124,12 @@ endmenu
menu "Kernel Features"
+config COMMAND_LINE_SIZE
+ int "Maximum size of the command line."
+ default "256"
+ help
+ This is the per architecture maximum command line size.
+
if COLDFIRE
source "kernel/Kconfig.preempt"
endif
diff --git a/arch/m68k/include/uapi/asm/setup.h b/arch/m68k/include/uapi/asm/setup.h
index 6a6dc63..a96470e 100644
--- a/arch/m68k/include/uapi/asm/setup.h
+++ b/arch/m68k/include/uapi/asm/setup.h
@@ -11,6 +11,8 @@
#ifndef _UAPI_M68K_SETUP_H
#define _UAPI_M68K_SETUP_H
-#define COMMAND_LINE_SIZE 256
+#ifdef CONFIG_COMMAND_LINE_SIZE
+#define COMMAND_LINE_SIZE CONFIG_COMMAND_LINE_SIZE
+#endif
#endif /* _UAPI_M68K_SETUP_H */
diff --git a/arch/microblaze/Kconfig b/arch/microblaze/Kconfig
index 9ae0854..fa409d6 100644
--- a/arch/microblaze/Kconfig
+++ b/arch/microblaze/Kconfig
@@ -91,6 +91,12 @@ comment "Boot options"
config CMDLINE_BOOL
bool "Default bootloader kernel arguments"
+config COMMAND_LINE_SIZE
+ int "Maximum size of the command line."
+ default "256"
+ help
+ This is the per architecture maximum command line size.
+
config CMDLINE
string "Default kernel command string"
depends on CMDLINE_BOOL
diff --git a/arch/microblaze/include/uapi/asm/setup.h b/arch/microblaze/include/uapi/asm/setup.h
index 76bc2ac..5992d0b 100644
--- a/arch/microblaze/include/uapi/asm/setup.h
+++ b/arch/microblaze/include/uapi/asm/setup.h
@@ -11,7 +11,9 @@
#ifndef _UAPI_ASM_MICROBLAZE_SETUP_H
#define _UAPI_ASM_MICROBLAZE_SETUP_H
-#define COMMAND_LINE_SIZE 256
+#ifdef CONFIG_COMMAND_LINE_SIZE
+#define COMMAND_LINE_SIZE CONFIG_COMMAND_LINE_SIZE
+#endif
# ifndef __ASSEMBLY__
diff --git a/arch/mips/Kconfig b/arch/mips/Kconfig
index 5cd695f..1200836 100644
--- a/arch/mips/Kconfig
+++ b/arch/mips/Kconfig
@@ -2247,6 +2247,12 @@ config HW_PERF_EVENTS
source "mm/Kconfig"
+config COMMAND_LINE_SIZE
+ int "Maximum size of the command line."
+ default "4096"
+ help
+ This is the per architecture maximum command line size.
+
config SMP
bool "Multi-Processing support"
depends on SYS_SUPPORTS_SMP
diff --git a/arch/mips/include/uapi/asm/setup.h b/arch/mips/include/uapi/asm/setup.h
index 93f237b..323902a 100644
--- a/arch/mips/include/uapi/asm/setup.h
+++ b/arch/mips/include/uapi/asm/setup.h
@@ -1,7 +1,8 @@
#ifndef _UAPI_MIPS_SETUP_H
#define _UAPI_MIPS_SETUP_H
-#define COMMAND_LINE_SIZE 4096
-
+#ifdef CONFIG_COMMAND_LINE_SIZE
+#define COMMAND_LINE_SIZE CONFIG_COMMAND_LINE_SIZE
+#endif
#endif /* _UAPI_MIPS_SETUP_H */
diff --git a/arch/mn10300/Kconfig b/arch/mn10300/Kconfig
index a648de1..4a940bc 100644
--- a/arch/mn10300/Kconfig
+++ b/arch/mn10300/Kconfig
@@ -199,6 +199,12 @@ config SMP
If you don't know what to do here, say N.
+config COMMAND_LINE_SIZE
+ int "Maximum size of the command line."
+ default "256"
+ help
+ This is the per architecture maximum command line size.
+
config NR_CPUS
int
depends on SMP
diff --git a/arch/mn10300/include/uapi/asm/param.h b/arch/mn10300/include/uapi/asm/param.h
index 02a0ca6..b632f88 100644
--- a/arch/mn10300/include/uapi/asm/param.h
+++ b/arch/mn10300/include/uapi/asm/param.h
@@ -13,6 +13,8 @@
#include <asm-generic/param.h>
-#define COMMAND_LINE_SIZE 256
+#ifdef CONFIG_COMMAND_LINE_SIZE
+#define COMMAND_LINE_SIZE CONFIG_COMMAND_LINE_SIZE
+#endif
#endif /* _ASM_PARAM_H */
diff --git a/arch/parisc/Kconfig b/arch/parisc/Kconfig
index 1faefed..633ab34 100644
--- a/arch/parisc/Kconfig
+++ b/arch/parisc/Kconfig
@@ -295,6 +295,12 @@ config HPUX
bool "Support for HP-UX binaries"
depends on !64BIT
+config COMMAND_LINE_SIZE
+ int "Maximum size of the command line."
+ default "1024"
+ help
+ This is the per architecture maximum command line size.
+
config NR_CPUS
int "Maximum number of CPUs (2-32)"
range 2 32
diff --git a/arch/parisc/include/uapi/asm/setup.h b/arch/parisc/include/uapi/asm/setup.h
index 7da2e5b..c70453f 100644
--- a/arch/parisc/include/uapi/asm/setup.h
+++ b/arch/parisc/include/uapi/asm/setup.h
@@ -1,6 +1,8 @@
#ifndef _PARISC_SETUP_H
#define _PARISC_SETUP_H
-#define COMMAND_LINE_SIZE 1024
+#ifdef CONFIG_COMMAND_LINE_SIZE
+#define COMMAND_LINE_SIZE CONFIG_COMMAND_LINE_SIZE
+#endif
#endif /* _PARISC_SETUP_H */
diff --git a/arch/powerpc/Kconfig b/arch/powerpc/Kconfig
index e099899..3426bdc 100644
--- a/arch/powerpc/Kconfig
+++ b/arch/powerpc/Kconfig
@@ -612,6 +612,12 @@ config PPC_DENORMALISATION
config CMDLINE_BOOL
bool "Default bootloader kernel arguments"
+config COMMAND_LINE_SIZE
+ int "Maximum size of the command line."
+ default "512"
+ help
+ This is the per architecture maximum command line size.
+
config CMDLINE
string "Initial kernel command string"
depends on CMDLINE_BOOL
diff --git a/arch/powerpc/boot/ops.h b/arch/powerpc/boot/ops.h
index b3218ce..8a91edb 100644
--- a/arch/powerpc/boot/ops.h
+++ b/arch/powerpc/boot/ops.h
@@ -15,7 +15,10 @@
#include "types.h"
#include "string.h"
-#define COMMAND_LINE_SIZE 512
+#ifdef CONFIG_COMMAND_LINE_SIZE
+#define COMMAND_LINE_SIZE CONFIG_COMMAND_LINE_SIZE
+#endif
+
#define MAX_PATH_LEN 256
#define MAX_PROP_LEN 256 /* What should this be? */
diff --git a/arch/s390/Kconfig b/arch/s390/Kconfig
index d68fe34..01cfcbb 100644
--- a/arch/s390/Kconfig
+++ b/arch/s390/Kconfig
@@ -348,6 +348,12 @@ config SMP
Even if you don't know what to do here, say Y.
+config COMMAND_LINE_SIZE
+ int "Maximum size of the command line."
+ default "4096"
+ help
+ This is the per architecture maximum command line size.
+
config NR_CPUS
int "Maximum number of CPUs (2-256)"
range 2 256
diff --git a/arch/s390/include/uapi/asm/setup.h b/arch/s390/include/uapi/asm/setup.h
index 5a637e3..23e51e1 100644
--- a/arch/s390/include/uapi/asm/setup.h
+++ b/arch/s390/include/uapi/asm/setup.h
@@ -6,7 +6,9 @@
#ifndef _UAPI_ASM_S390_SETUP_H
#define _UAPI_ASM_S390_SETUP_H
-#define COMMAND_LINE_SIZE 4096
+#ifdef CONFIG_COMMAND_LINE_SIZE
+#define COMMAND_LINE_SIZE CONFIG_COMMAND_LINE_SIZE
+#endif
#define ARCH_COMMAND_LINE_SIZE 896
diff --git a/arch/score/Kconfig b/arch/score/Kconfig
index 4ac8cae..63de4bd 100644
--- a/arch/score/Kconfig
+++ b/arch/score/Kconfig
@@ -58,6 +58,12 @@ config 32BIT
config ARCH_FLATMEM_ENABLE
def_bool y
+config COMMAND_LINE_SIZE
+ int "Maximum size of the command line."
+ default "256"
+ help
+ This is the per architecture maximum command line size.
+
source "mm/Kconfig"
config MEMORY_START
diff --git a/arch/score/include/uapi/asm/setup.h b/arch/score/include/uapi/asm/setup.h
index ab9dbdb..aa59951 100644
--- a/arch/score/include/uapi/asm/setup.h
+++ b/arch/score/include/uapi/asm/setup.h
@@ -1,7 +1,10 @@
#ifndef _UAPI_ASM_SCORE_SETUP_H
#define _UAPI_ASM_SCORE_SETUP_H
-#define COMMAND_LINE_SIZE 256
+#ifdef CONFIG_COMMAND_LINE_SIZE
+#define COMMAND_LINE_SIZE CONFIG_COMMAND_LINE_SIZE
+#endif
+
#define MEMORY_START 0
#define MEMORY_SIZE 0x2000000
diff --git a/arch/sparc/Kconfig b/arch/sparc/Kconfig
index 29f2e98..148114d 100644
--- a/arch/sparc/Kconfig
+++ b/arch/sparc/Kconfig
@@ -329,6 +329,13 @@ config CMDLINE_BOOL
bool "Default bootloader kernel arguments"
depends on SPARC64
+config COMMAND_LINE_SIZE
+ int "Maximum size of the command line."
+ default "256" if SPARC32
+ default "2048" if SPARC64
+ help
+ This is the per architecture maximum command line size.
+
config CMDLINE
string "Initial kernel command string"
depends on CMDLINE_BOOL
diff --git a/arch/sparc/include/uapi/asm/setup.h b/arch/sparc/include/uapi/asm/setup.h
index 5337684..bcf105b 100644
--- a/arch/sparc/include/uapi/asm/setup.h
+++ b/arch/sparc/include/uapi/asm/setup.h
@@ -5,11 +5,8 @@
#ifndef _UAPI_SPARC_SETUP_H
#define _UAPI_SPARC_SETUP_H
-#if defined(__sparc__) && defined(__arch64__)
-# define COMMAND_LINE_SIZE 2048
-#else
-# define COMMAND_LINE_SIZE 256
+#ifdef CONFIG_COMMAND_LINE_SIZE
+#define COMMAND_LINE_SIZE CONFIG_COMMAND_LINE_SIZE
#endif
-
#endif /* _UAPI_SPARC_SETUP_H */
diff --git a/arch/tile/Kconfig b/arch/tile/Kconfig
index 85258ca..6aa6d6a 100644
--- a/arch/tile/Kconfig
+++ b/arch/tile/Kconfig
@@ -336,6 +336,12 @@ config CMDLINE_BOOL
Systems with fully functional boot loaders (e.g. mboot, or
if booting over PCI) should leave this option set to 'N'.
+config COMMAND_LINE_SIZE
+ int "Maximum size of the command line."
+ default "2048"
+ help
+ This is the per architecture maximum command line size.
+
config CMDLINE
string "Built-in kernel command string"
depends on CMDLINE_BOOL
diff --git a/arch/tile/include/uapi/asm/setup.h b/arch/tile/include/uapi/asm/setup.h
index e6f7da2..7e1e7dd 100644
--- a/arch/tile/include/uapi/asm/setup.h
+++ b/arch/tile/include/uapi/asm/setup.h
@@ -15,7 +15,8 @@
#ifndef _UAPI_ASM_TILE_SETUP_H
#define _UAPI_ASM_TILE_SETUP_H
-#define COMMAND_LINE_SIZE 2048
-
+#ifdef CONFIG_COMMAND_LINE_SIZE
+#define COMMAND_LINE_SIZE CONFIG_COMMAND_LINE_SIZE
+#endif
#endif /* _UAPI_ASM_TILE_SETUP_H */
diff --git a/arch/um/Kconfig.um b/arch/um/Kconfig.um
index a7520c9..c0af3f9 100644
--- a/arch/um/Kconfig.um
+++ b/arch/um/Kconfig.um
@@ -119,6 +119,12 @@ config SMP
If you don't know what to do, say N.
+config COMMAND_LINE_SIZE
+ int "Maximum size of the command line."
+ default "4096"
+ help
+ This is the per architecture maximum command line size.
+
config NR_CPUS
int "Maximum number of CPUs (2-32)"
range 2 32
diff --git a/arch/um/include/asm/setup.h b/arch/um/include/asm/setup.h
index 99f0863..ec3c951 100644
--- a/arch/um/include/asm/setup.h
+++ b/arch/um/include/asm/setup.h
@@ -5,6 +5,8 @@
* command line, so this choice is ok.
*/
-#define COMMAND_LINE_SIZE 4096
+#ifdef CONFIG_COMMAND_LINE_SIZE
+#define COMMAND_LINE_SIZE CONFIG_COMMAND_LINE_SIZE
+#endif
#endif /* SETUP_H_INCLUDED */
diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig
index 25d2c6f..67a70ae 100644
--- a/arch/x86/Kconfig
+++ b/arch/x86/Kconfig
@@ -1826,6 +1826,12 @@ config CMDLINE_BOOL
Systems with fully functional boot loaders (i.e. non-embedded)
should leave this option set to 'N'.
+config COMMAND_LINE_SIZE
+ int "Maximum size of the command line."
+ default "2048"
+ help
+ This is the per architecture maximum command line size.
+
config CMDLINE
string "Built-in kernel command string"
depends on CMDLINE_BOOL
diff --git a/arch/x86/include/asm/setup.h b/arch/x86/include/asm/setup.h
index 9264f04..0ab46ee 100644
--- a/arch/x86/include/asm/setup.h
+++ b/arch/x86/include/asm/setup.h
@@ -3,7 +3,9 @@
#include <uapi/asm/setup.h>
-#define COMMAND_LINE_SIZE 2048
+#ifdef CONFIG_COMMAND_LINE_SIZE
+#define COMMAND_LINE_SIZE CONFIG_COMMAND_LINE_SIZE
+#endif
#include <linux/linkage.h>
diff --git a/arch/xtensa/Kconfig b/arch/xtensa/Kconfig
index 02d6d29..00874f8 100644
--- a/arch/xtensa/Kconfig
+++ b/arch/xtensa/Kconfig
@@ -266,6 +266,12 @@ config GENERIC_CALIBRATE_DELAY
config CMDLINE_BOOL
bool "Default bootloader kernel arguments"
+config COMMAND_LINE_SIZE
+ int "Maximum size of the command line."
+ default "256"
+ help
+ This is the per architecture maximum command line size.
+
config CMDLINE
string "Initial kernel command string"
depends on CMDLINE_BOOL
diff --git a/arch/xtensa/include/uapi/asm/setup.h b/arch/xtensa/include/uapi/asm/setup.h
index 9fa8ad9..c320d8e 100644
--- a/arch/xtensa/include/uapi/asm/setup.h
+++ b/arch/xtensa/include/uapi/asm/setup.h
@@ -11,7 +11,9 @@
#ifndef _XTENSA_SETUP_H
#define _XTENSA_SETUP_H
-#define COMMAND_LINE_SIZE 256
+#ifdef CONFIG_COMMAND_LINE_SIZE
+#define COMMAND_LINE_SIZE CONFIG_COMMAND_LINE_SIZE
+#endif
extern void set_except_vector(int n, void *addr);
diff --git a/include/uapi/asm-generic/setup.h b/include/uapi/asm-generic/setup.h
index 6fc26a5..0ec13fc 100644
--- a/include/uapi/asm-generic/setup.h
+++ b/include/uapi/asm-generic/setup.h
@@ -1,6 +1,6 @@
#ifndef __ASM_GENERIC_SETUP_H
#define __ASM_GENERIC_SETUP_H
-#define COMMAND_LINE_SIZE 512
+#define COMMAND_LINE_SIZE 512
#endif /* __ASM_GENERIC_SETUP_H */
--
1.9.1
^ permalink raw reply related
* [PATCH 0/3][RFC][v1] kconfig: powerpc: Make COMMAND_LINE_SIZE a kernel config option. Increase COMMAND_LINE_SIZE for the powerpc architecture.
From: Joseph Salisbury @ 2014-04-28 21:11 UTC (permalink / raw)
To: linux-kernel, benh, paulus; +Cc: linuxppc-dev, anton
I'm sending this out as a RFC to get feedback and see which way folks would like to go. Patch 1 of this patch set makes COMMAND_LINE_SIZE a seperate config option for each architecture. However, an alternative to that would be to create a single default size(Possibly 2048 to satisfy patchs 2 and 3 of this patch set) for COMMAND_LINE_SIZE in ~kernel/Kconfig or ~init/Kconfig and then allow the different architecures to either bump this size up or down if needed.
This set of changes focus on COMMAND_LINE_SIZE. An inital patch was created to increase the size of COMMAND_LINE_SIZE for the powerpc architecture. However, after looking at the code, it appears powerpc does not actually use the define in the ppc headers but uses the common generic default. It seems like having COMMAND_LINE_SIZE a kernel config options is a cleaner way to modify the value, instead of going through and chaning defines. This applies to all architectures and not just powerpc.
The powerpc architecture uses asm-generic to set the value of COMMAND_LINE_SIZE, which should be changed to a kernel config option.
The size of COMMAND_LINE_SIZE for powerpc should be longer than 512 characters, as iscsi targets and cloud-init parameters are passed through the kernel command line.
Joseph Salisbury (3):
kconfig: Change COMMAND_LINE_SIZE to a kernel config option, which is
now set per architecture.
powerpc: Change the powerpc architecture to use Kconfig to set
COMMAND_LINE_SIZE.
powerpc: kconfig: Increase the size of COMMAND_LINE_SIZE to 2048 from
512 for powerpc.
arch/alpha/Kconfig | 6 ++++++
arch/alpha/include/uapi/asm/setup.h | 4 +++-
arch/arc/Kconfig | 6 ++++++
arch/arc/include/asm/setup.h | 4 +++-
arch/arm/Kconfig | 6 ++++++
arch/arm/include/uapi/asm/setup.h | 4 +++-
arch/arm64/Kconfig | 6 ++++++
arch/arm64/include/uapi/asm/setup.h | 4 +++-
arch/avr32/Kconfig | 6 ++++++
arch/avr32/include/uapi/asm/setup.h | 4 +++-
arch/c6x/Kconfig | 6 ++++++
arch/c6x/include/uapi/asm/setup.h | 4 +++-
arch/cris/Kconfig | 6 ++++++
arch/cris/include/uapi/asm/setup.h | 4 +++-
arch/frv/Kconfig | 6 ++++++
arch/frv/include/uapi/asm/setup.h | 5 +++--
arch/ia64/Kconfig | 6 ++++++
arch/ia64/include/uapi/asm/setup.h | 4 +++-
arch/m32r/Kconfig | 6 ++++++
arch/m32r/include/uapi/asm/setup.h | 5 +++--
arch/m68k/Kconfig | 6 ++++++
arch/m68k/include/uapi/asm/setup.h | 4 +++-
arch/microblaze/Kconfig | 6 ++++++
arch/microblaze/include/uapi/asm/setup.h | 4 +++-
arch/mips/Kconfig | 6 ++++++
arch/mips/include/uapi/asm/setup.h | 5 +++--
arch/mn10300/Kconfig | 6 ++++++
arch/mn10300/include/uapi/asm/param.h | 4 +++-
arch/parisc/Kconfig | 6 ++++++
arch/parisc/include/uapi/asm/setup.h | 4 +++-
arch/powerpc/Kconfig | 6 ++++++
arch/powerpc/boot/ops.h | 5 ++++-
arch/powerpc/include/asm/setup.h | 2 --
arch/powerpc/include/uapi/asm/setup.h | 1 -
arch/s390/Kconfig | 6 ++++++
arch/s390/include/uapi/asm/setup.h | 4 +++-
arch/score/Kconfig | 6 ++++++
arch/score/include/uapi/asm/setup.h | 5 ++++-
arch/sparc/Kconfig | 7 +++++++
arch/sparc/include/uapi/asm/setup.h | 7 ++-----
arch/tile/Kconfig | 6 ++++++
arch/tile/include/uapi/asm/setup.h | 5 +++--
arch/um/Kconfig.um | 6 ++++++
arch/um/include/asm/setup.h | 4 +++-
arch/x86/Kconfig | 6 ++++++
arch/x86/include/asm/setup.h | 4 +++-
arch/xtensa/Kconfig | 6 ++++++
arch/xtensa/include/uapi/asm/setup.h | 4 +++-
include/uapi/asm-generic/setup.h | 2 +-
49 files changed, 210 insertions(+), 35 deletions(-)
delete mode 100644 arch/powerpc/include/uapi/asm/setup.h
--
1.9.1
^ permalink raw reply
* [PATCH 2/3][RFC][v1] powerpc: Change the powerpc architecture to use Kconfig to set COMMAND_LINE_SIZE.
From: Joseph Salisbury @ 2014-04-28 21:11 UTC (permalink / raw)
To: linux-kernel, benh, paulus; +Cc: linuxppc-dev, anton
In-Reply-To: <cover.1398287636.git.joseph.salisbury@canonical.com>
The powerpc architecture currently uses asm-generic to set the value of COMMAND_LINE_SIZE. This change will allow the value of COMMAND_LINE_SIZE to be set specifically for powerpc without affecting other architectures that may use asm-generic.
Signed-off-by: Joseph Salisbury <joseph.salisbury@canonical.com>
---
arch/powerpc/include/asm/setup.h | 2 --
arch/powerpc/include/uapi/asm/setup.h | 1 -
2 files changed, 3 deletions(-)
delete mode 100644 arch/powerpc/include/uapi/asm/setup.h
diff --git a/arch/powerpc/include/asm/setup.h b/arch/powerpc/include/asm/setup.h
index 11ba86e..c7b62c3 100644
--- a/arch/powerpc/include/asm/setup.h
+++ b/arch/powerpc/include/asm/setup.h
@@ -1,8 +1,6 @@
#ifndef _ASM_POWERPC_SETUP_H
#define _ASM_POWERPC_SETUP_H
-#include <uapi/asm/setup.h>
-
#ifndef __ASSEMBLY__
extern void ppc_printk_progress(char *s, unsigned short hex);
diff --git a/arch/powerpc/include/uapi/asm/setup.h b/arch/powerpc/include/uapi/asm/setup.h
deleted file mode 100644
index 552df83..0000000
--- a/arch/powerpc/include/uapi/asm/setup.h
+++ /dev/null
@@ -1 +0,0 @@
-#include <asm-generic/setup.h>
--
1.9.1
^ permalink raw reply related
* [PATCH 3/3][RFC][v1] powerpc: kconfig: Increase the size of COMMAND_LINE_SIZE to 2048 from 512 for powerpc.
From: Joseph Salisbury @ 2014-04-28 21:11 UTC (permalink / raw)
To: linux-kernel, benh, paulus; +Cc: linuxppc-dev, anton
In-Reply-To: <cover.1398287636.git.joseph.salisbury@canonical.com>
BugLink: http://bugs.launchpad.net/bugs/1306677
While booting the PPC64EL kernel, the command line gets truncated to 512 characters. This is due to a limit of 512 defined for COMMAND_LINE_SIZE. It would be beneficial to have a command line longer than 512 characters, as iscsi targets and cloud-init parameters are passed through the kernel command line.
Signed-off-by: Joseph Salisbury <joseph.salisbury@canonical.com>
---
arch/powerpc/Kconfig | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/powerpc/Kconfig b/arch/powerpc/Kconfig
index 3426bdc..becee70 100644
--- a/arch/powerpc/Kconfig
+++ b/arch/powerpc/Kconfig
@@ -614,7 +614,7 @@ config CMDLINE_BOOL
config COMMAND_LINE_SIZE
int "Maximum size of the command line."
- default "512"
+ default "2048"
help
This is the per architecture maximum command line size.
--
1.9.1
^ permalink raw reply related
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