* Re: KGDB panics on p2020 target
From: "“tiejun.chen”" @ 2014-01-21 6:36 UTC (permalink / raw)
To: Arun Chandran; +Cc: linuxppc-dev
In-Reply-To: <CAFdej02vx3DDYUqG=4mO=B1fFw4apsnUtmjCcYoXDmfGdtNWPQ@mail.gmail.com>
On 01/21/2014 02:04 PM, Arun Chandran wrote:
> On Mon, Jan 20, 2014 at 1:55 PM, "�tiejun.chen�"
> <tiejun.chen@windriver.com>wrote:
>
>> On 01/17/2014 03:52 PM, Arun Chandran wrote:
>>
>>> Hi,
>>>
>>> I am testing kgdb on freescale p2020 target.
>>>
>>> In target
>>> ------------
>>>
>>> 1)
>>> root@freescale-p2020ds:~# uname -a
>>> Linux freescale-p2020ds 3.10.20-rt14+ #9 SMP Thu Jan 16 16:32:15 IST 2014
>>> ppc GNU/Linux
>>>
>>> 2)
>>> root@freescale-p2020ds:~# cat /proc/cpuinfo
>>> processor : 0
>>> cpu : e500v2
>>> clock : 999.990008MHz
>>> revision : 4.0 (pvr 8021 1040)
>>> bogomips : 124.99
>>>
>>> processor : 1
>>> cpu : e500v2
>>> clock : 999.990008MHz
>>> revision : 4.0 (pvr 8021 1040)
>>> bogomips : 124.99
>>>
>>> total bogomips : 249.99
>>> timebase : 62499376
>>> platform : P2020 DS
>>> model : fsl,P2020DS
>>> Memory : 768 MB
>>>
>>> 3)
>>> freescale-p2020ds:~# echo "ttyS1,115200" >
>>> /sys/module/kgdboc/parameters/kgdoc
>>>
>>> 4) I set up host (settings given below); Then I send "SysRq : DEBUG"
>>>
>>> In host
>>> ----------
>>> (gdb) target remote /dev/ttyS0
>>> Remote debugging using /dev/ttyS0
>>> kgdb_breakpoint () at kernel/debug/debug_core.c:1013
>>> 1013 arch_kgdb_breakpoint();
>>> (gdb) b sys_sync
>>> Breakpoint 1 at 0xc0167288: file fs/sync.c, line 103.
>>> (gdb) c
>>> Continuing.
>>>
>>> I am able to take control in host; after that I am setting breakpoint at
>>> "sys_sync"
>>>
>>> In target
>>> ------------
>>> root@freescale-p2020ds:~# for i in 1 2 3 4 5 6 7 8 9
>>>
>>>> do
>>>> sync
>>>> done
>>>>
>>>
>>> In host
>>> ----------
>>> Breakpoint 1, sys_sync () at fs/sync.c:103
>>> 103 {
>>> (gdb) c
>>> Continuing.
>>>
>>> Breakpoint is hit only one time instead of 9 times; after that target
>>> hangs.
>>>
>>
>> I recommend you try upstream to take a further look at this, instead of
>> that Freescale distribution. As I recall currently KGDB works well in 85xx
>> case in ML.
>
>
> Many thanks for your suggestion.
>
> I tested the same thing on linux-3.12.y (
> https://git.kernel.org/cgit/linux/kernel/git/stable/linux-stable.git/log/?id=refs%2Ftags%2Fv3.12.8&h=linux-3.12.y
> ).
>
Please go powerpc tree,
git clone git://git.kernel.org/pub/scm/linux/kernel/git/benh/powerpc.git
git checkout next
>
> root@p2020ds:~# uname -a
> Linux freescale-p2020ds 3.12.8 #136 SMP Tue Jan 21 11:14:13 IST 2014 ppc
> GNU/Linux
>
>
> The breakpoint I placed at "sys_sync" is hit only once. After that my gdb
> command "continue" does not make further
> hits. And the target is hung. It is not even responding to my further
> sending of "SysRq : DEBUG"
>
> I have attached my .config
>
>
>>
>>
>>
>>> Then i tried to send "SysRq : DEBUG" in target kernel panics.
>>>
>>> I have pasted the panic below.
>>>
>>> #########################################
>>> SysRq : DEBUG
>>> Kernel panic - not syncing: Recursive entry to debugger
>>>
>>
>> The kernel already trap into kgdb_handle_exception() with the debug
>> exception while triggering that break point, but again you trigger another
>> debug exception by SysRq. Actually KGDB can't handle such this recursive
>> behavior, so KGDB always call kgdb_reenter_check() to prevent this scenario
>> with this call trace.
>>
>>
> I am doing it because the target is hung after the initial breakpoint is
> hit.
This is just what I mean. Although looks your kernel is hung, actually your
kernel is already in kgdb exception handler previously. So after you send break
by SysRq to debug, its not allowed by current kgdb scheme as I said. The
following call trace also show this path explicitly.
Tiejun
>
>
>> static int kgdb_reenter_check(struct kgdb_state *ks)
>> {
>> unsigned long addr;
>>
>> if (atomic_read(&kgdb_active) != raw_smp_processor_id())
>> return 0;
>> ...
>>
>> if (exception_level > 1) {
>> dump_stack();
>> panic("Recursive entry to debugger");
>> }
>>
>>
>> Tiejun
>>
>> CPU: 1 PID: 2266 Comm: cron Not tainted 3.10.20-rt14+ #6
>>> Call Trace:
>>> [effe5d10] [c0008060] show_stack+0x4c/0x168 (unreliable)
>>> [effe5d50] [c0588878] panic+0xe4/0x224
>>> [effe5da0] [c00b2cbc] kgdb_handle_exception+0x1d4/0x1f8
>>> [effe5df0] [c0010038] kgdb_handle_breakpoint+0x4c/0x80
>>> [effe5e00] [c057e7e0] program_check_exception+0x10c/0x264
>>> [effe5e10] [c000f660] ret_from_except_full+0x0/0x4c
>>> --- Exception: 700 at sysrq_handle_dbg+0x3c/0xc8
>>> LR = __handle_sysrq+0x154/0x1cc
>>> [effe5ed0] [c033df5c] __handle_sysrq+0x140/0x1cc (unreliable)
>>> [effe5f00] [c0353ef8] serial8250_rx_chars+0xe8/0x218
>>> [effe5f30] [c0359644] fsl8250_handle_irq+0xac/0x174
>>> [effe5f50] [c0352f9c] serial8250_interrupt+0x40/0xe8
>>> [effe5f70] [c00b5500] handle_irq_event_percpu+0xcc/0x2a8
>>> [effe5fc0] [c00b5720] handle_irq_event+0x44/0x74
>>> [effe5fe0] [c00b8e14] handle_fasteoi_irq+0xd0/0x17c
>>> [effe5ff0] [c000d58c] call_handle_irq+0x18/0x28
>>> [c4f91b10] [c0004f60] do_IRQ+0x150/0x224
>>> [c4f91b40] [c000f6ac] ret_from_except+0x0/0x18
>>> --- Exception: 501 at rpcauth_lookup_credcache+0x138/0x2a4
>>> LR = rpcauth_lookup_credcache+0xb8/0x2a4
>>> [c4f91c00] [24002424] 0x24002424 (unreliable)
>>> [c4f91c50] [c055cb84] rpcauth_lookupcred+0x64/0xac
>>> [c4f91c80] [c055ce2c] rpcauth_refreshcred+0x11c/0x124
>>> [c4f91cc0] [c055ac80] __rpc_execute+0x8c/0x330
>>> [c4f91d10] [c05540b8] rpc_run_task+0x9c/0xc4
>>> [c4f91d20] [c0554204] rpc_call_sync+0x50/0xb8
>>> [c4f91d50] [c0257164] nfs_proc_getattr+0x48/0x5c
>>> [c4f91d70] [c024aaa4] __nfs_revalidate_inode+0xa8/0x168
>>> [c4f91d90] [c024ac1c] nfs_revalidate_mapping+0xb8/0x194
>>> [c4f91da0] [c0251f00] nfs_follow_link+0x24/0xc8
>>> [c4f91dc0] [c0145280] path_lookupat+0x2f4/0x824
>>> [c4f91e10] [c01457dc] filename_lookup.isra.33+0x2c/0x8c
>>> [c4f91e30] [c0147a74] user_path_at_empty+0x58/0x9c
>>> [c4f91eb0] [c013d5bc] vfs_fstatat+0x54/0xb4
>>> [c4f91ee0] [c013d93c] SyS_stat64+0x1c/0x44
>>> [c4f91f40] [c000eec0] ret_from_syscall+0x0/0x3c
>>> --- Exception: c01 at 0xff08a98
>>> LR = 0xfed53e8
>>> CPU: 1 PID: 2266 Comm: cron Not tainted 3.10.20-rt14+ #6
>>> Call Trace:
>>> [effe5bb0] [c0008060] show_stack+0x4c/0x168 (unreliable)
>>> [effe5bf0] [c00b2cac] kgdb_handle_exception+0x1c4/0x1f8
>>> [effe5c40] [c0010038] kgdb_handle_breakpoint+0x4c/0x80
>>> [effe5c50] [c057e7e0] program_check_exception+0x10c/0x264
>>> [effe5c60] [c000f660] ret_from_except_full+0x0/0x4c
>>> --- Exception: 700 at kgdb_panic_event+0x1c/0x3c
>>> LR = notifier_call_chain+0x60/0xb0
>>> [effe5d20] [00000000] (nil) (unreliable)
>>> [effe5d40] [c05819dc] __atomic_notifier_call_chain+0x14/0x24
>>> [effe5d50] [c05888a8] panic+0x114/0x224
>>> [effe5da0] [c00b2cbc] kgdb_handle_exception+0x1d4/0x1f8
>>> [effe5df0] [c0010038] kgdb_handle_breakpoint+0x4c/0x80
>>> [effe5e00] [c057e7e0] program_check_exception+0x10c/0x264
>>> [effe5e10] [c000f660] ret_from_except_full+0x0/0x4c
>>> --- Exception: 700 at sysrq_handle_dbg+0x3c/0xc8
>>> LR = __handle_sysrq+0x154/0x1cc
>>> [effe5ed0] [c033df5c] __handle_sysrq+0x140/0x1cc (unreliable)
>>> [effe5f00] [c0353ef8] serial8250_rx_chars+0xe8/0x218
>>> [effe5f30] [c0359644] fsl8250_handle_irq+0xac/0x174
>>> [effe5f50] [c0352f9c] serial8250_interrupt+0x40/0xe8
>>> [effe5f70] [c00b5500] handle_irq_event_percpu+0xcc/0x2a8
>>> [effe5fc0] [c00b5720] handle_irq_event+0x44/0x74
>>> [effe5fe0] [c00b8e14] handle_fasteoi_irq+0xd0/0x17c
>>> [effe5ff0] [c000d58c] call_handle_irq+0x18/0x28
>>> [c4f91b10] [c0004f60] do_IRQ+0x150/0x224
>>> [c4f91b40] [c000f6ac] ret_from_except+0x0/0x18
>>> --- Exception: 501 at rpcauth_lookup_credcache+0x138/0x2a4
>>> LR = rpcauth_lookup_credcache+0xb8/0x2a4
>>> [c4f91c00] [24002424] 0x24002424 (unreliable)
>>> [c4f91c50] [c055cb84] rpcauth_lookupcred+0x64/0xac
>>> [c4f91c80] [c055ce2c] rpcauth_refreshcred+0x11c/0x124
>>> [c4f91cc0] [c055ac80] __rpc_execute+0x8c/0x330
>>> [c4f91d10] [c05540b8] rpc_run_task+0x9c/0xc4
>>> [c4f91d20] [c0554204] rpc_call_sync+0x50/0xb8
>>> [c4f91d50] [c0257164] nfs_proc_getattr+0x48/0x5c
>>> [c4f91d70] [c024aaa4] __nfs_revalidate_inode+0xa8/0x168
>>> [c4f91d90] [c024ac1c] nfs_revalidate_mapping+0xb8/0x194
>>> [c4f91da0] [c0251f00] nfs_follow_link+0x24/0xc8
>>> [c4f91dc0] [c0145280] path_lookupat+0x2f4/0x824
>>> [c4f91e10] [c01457dc] filename_lookup.isra.33+0x2c/0x8c
>>> [c4f91e30] [c0147a74] user_path_at_empty+0x58/0x9c
>>> [c4f91eb0] [c013d5bc] vfs_fstatat+0x54/0xb4
>>> [c4f91ee0] [c013d93c] SyS_stat64+0x1c/0x44
>>> [c4f91f40] [c000eec0] ret_from_syscall+0x0/0x3c
>>> --- Exception: c01 at 0xff08a98
>>> LR = 0xfed53e8
>>>
>>>
>>> ########################################################
>>>
>>> Could you please share your thoughts on this issue?
>>>
>>> I have also attached my kernel .config.
>>>
>>> Regards,
>>> Arun C
>>>
>>>
>>>
>>> _______________________________________________
>>> Linuxppc-dev mailing list
>>> Linuxppc-dev@lists.ozlabs.org
>>> https://lists.ozlabs.org/listinfo/linuxppc-dev
>>>
>>>
>>
>
^ permalink raw reply
* [v2 PATCH] powerpc: hugetlb: replace __get_cpu_var with get_cpu_var
From: Tiejun Chen @ 2014-01-21 7:16 UTC (permalink / raw)
To: scottwood; +Cc: linuxppc-dev
Replace __get_cpu_var safely with get_cpu_var to avoid
the following call trace:
[ 7253.637591] BUG: using smp_processor_id() in preemptible [00000000 00000000]
code: hugemmap01/9048
[ 7253.637601] caller is free_hugepd_range.constprop.25+0x88/0x1a8
[ 7253.637605] CPU: 1 PID: 9048 Comm: hugemmap01 Not tainted 3.10.20-rt14+ #114
[ 7253.637606] Call Trace:
[ 7253.637617] [cb049d80] [c0007ea4] show_stack+0x4c/0x168 (unreliable)
[ 7253.637624] [cb049dc0] [c031c674] debug_smp_processor_id+0x114/0x134
[ 7253.637628] [cb049de0] [c0016d28] free_hugepd_range.constprop.25+0x88/0x1a8
[ 7253.637632] [cb049e00] [c001711c] hugetlb_free_pgd_range+0x6c/0x168
[ 7253.637639] [cb049e40] [c0117408] free_pgtables+0x12c/0x150
[ 7253.637646] [cb049e70] [c011ce38] unmap_region+0xa0/0x11c
[ 7253.637671] [cb049ef0] [c011f03c] do_munmap+0x224/0x3bc
[ 7253.637676] [cb049f20] [c011f2e0] vm_munmap+0x38/0x5c
[ 7253.637682] [cb049f40] [c000ef88] ret_from_syscall+0x0/0x3c
[ 7253.637686] --- Exception: c01 at 0xff16004
Signed-off-by: Tiejun Chen <tiejun.chen@windriver.com>
---
v2:
Just fix some style problems.
arch/powerpc/mm/hugetlbpage.c | 5 ++++-
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/arch/powerpc/mm/hugetlbpage.c b/arch/powerpc/mm/hugetlbpage.c
index 90bb6d9..0e9eff8 100644
--- a/arch/powerpc/mm/hugetlbpage.c
+++ b/arch/powerpc/mm/hugetlbpage.c
@@ -472,12 +472,13 @@ static void hugepd_free(struct mmu_gather *tlb, void *hugepte)
{
struct hugepd_freelist **batchp;
- batchp = &__get_cpu_var(hugepd_freelist_cur);
+ batchp = &get_cpu_var(hugepd_freelist_cur);
if (atomic_read(&tlb->mm->mm_users) < 2 ||
cpumask_equal(mm_cpumask(tlb->mm),
cpumask_of(smp_processor_id()))) {
kmem_cache_free(hugepte_cache, hugepte);
+ put_cpu_var(hugepd_freelist_cur);
return;
}
@@ -491,6 +492,8 @@ static void hugepd_free(struct mmu_gather *tlb, void *hugepte)
call_rcu_sched(&(*batchp)->rcu, hugepd_free_rcu_callback);
*batchp = NULL;
}
+
+ put_cpu_var(hugepd_freelist_cur);
}
#endif
--
1.7.9.5
^ permalink raw reply related
* [PATCH v2] powernv: kvm: make _PAGE_NUMA take effect
From: Liu Ping Fan @ 2014-01-21 8:15 UTC (permalink / raw)
To: linuxppc-dev, kvm-ppc, kvm
Cc: Paul Mackerras, Alexander Graf, Aneesh Kumar K.V
To make sure that on host, the pages marked with _PAGE_NUMA result in a fault
when guest access them, we should force the checking when guest uses hypercall
to setup hpte.
Signed-off-by: Liu Ping Fan <pingfank@linux.vnet.ibm.com>
---
v2:
It should be the reply to "[PATCH 2/4] powernv: kvm: make _PAGE_NUMA take effect"
And I imporve the changelog according to Aneesh's suggestion.
---
arch/powerpc/kvm/book3s_hv_rm_mmu.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/powerpc/kvm/book3s_hv_rm_mmu.c b/arch/powerpc/kvm/book3s_hv_rm_mmu.c
index 9c51544..af8602d 100644
--- a/arch/powerpc/kvm/book3s_hv_rm_mmu.c
+++ b/arch/powerpc/kvm/book3s_hv_rm_mmu.c
@@ -232,7 +232,7 @@ long kvmppc_do_h_enter(struct kvm *kvm, unsigned long flags,
/* Look up the Linux PTE for the backing page */
pte_size = psize;
pte = lookup_linux_pte(pgdir, hva, writing, &pte_size);
- if (pte_present(pte)) {
+ if (pte_present(pte) && !pte_numa(pte)) {
if (writing && !pte_write(pte))
/* make the actual HPTE be read-only */
ptel = hpte_make_readonly(ptel);
--
1.8.1.4
^ permalink raw reply related
* Re: Build regressions/improvements in v3.13
From: Geert Uytterhoeven @ 2014-01-21 8:41 UTC (permalink / raw)
To: linux-kernel@vger.kernel.org; +Cc: linuxppc-dev@lists.ozlabs.org, Linux-sh list
In-Reply-To: <1390291850-17849-1-git-send-email-geert@linux-m68k.org>
On Tue, Jan 21, 2014 at 9:10 AM, Geert Uytterhoeven
<geert@linux-m68k.org> wrote:
> JFYI, when comparing v3.13[1] to v3.13-rc8[3], the summaries are:
> - build errors: +22/-3
+ /scratch/kisskb/src/arch/sh/drivers/superhyway/ops-sh4-202.c:
error: (near initialization for 'dmac_resource.end'): => 87:2
+ /scratch/kisskb/src/arch/sh/drivers/superhyway/ops-sh4-202.c:
error: (near initialization for 'dmac_resource.start'): => 86:2
+ /scratch/kisskb/src/arch/sh/drivers/superhyway/ops-sh4-202.c:
error: (near initialization for 'epbr_resources[0].end'): => 69:3
+ /scratch/kisskb/src/arch/sh/drivers/superhyway/ops-sh4-202.c:
error: (near initialization for 'epbr_resources[0].start'): => 68:3
+ /scratch/kisskb/src/arch/sh/drivers/superhyway/ops-sh4-202.c:
error: (near initialization for 'epbr_resources[1].end'): => 74:3
+ /scratch/kisskb/src/arch/sh/drivers/superhyway/ops-sh4-202.c:
error: (near initialization for 'epbr_resources[1].start'): => 73:3
+ /scratch/kisskb/src/arch/sh/drivers/superhyway/ops-sh4-202.c:
error: (near initialization for 'femi_resources[0].end'): => 50:3
+ /scratch/kisskb/src/arch/sh/drivers/superhyway/ops-sh4-202.c:
error: (near initialization for 'femi_resources[0].start'): => 49:3
+ /scratch/kisskb/src/arch/sh/drivers/superhyway/ops-sh4-202.c:
error: (near initialization for 'femi_resources[1].end'): => 55:3
+ /scratch/kisskb/src/arch/sh/drivers/superhyway/ops-sh4-202.c:
error: (near initialization for 'femi_resources[1].start'): => 54:3
+ /scratch/kisskb/src/arch/sh/drivers/superhyway/ops-sh4-202.c:
error: (near initialization for 'pbr_resources[0].end'): => 100:3
+ /scratch/kisskb/src/arch/sh/drivers/superhyway/ops-sh4-202.c:
error: (near initialization for 'pbr_resources[0].start'): => 99:3
+ /scratch/kisskb/src/arch/sh/drivers/superhyway/ops-sh4-202.c:
error: (near initialization for 'pbr_resources[1].end'): => 105:3
+ /scratch/kisskb/src/arch/sh/drivers/superhyway/ops-sh4-202.c:
error: (near initialization for 'pbr_resources[1].start'): => 104:3
+ /scratch/kisskb/src/arch/sh/drivers/superhyway/ops-sh4-202.c:
error: braced-group within expression allowed only inside a function:
=> 30:12, 73:12, 31:10, 99:12, 68:12, 36:10, 86:11, 54:12, 74:10,
55:10, 104:12, 49:12, 69:10, 87:9, 105:10, 35:12, 50:10, 100:10
+ /scratch/kisskb/src/arch/sh/drivers/superhyway/ops-sh4-202.c:
error: initializer element is not constant: => 74:3, 86:2, 55:3,
105:3, 73:3, 68:3, 100:3, 104:3, 99:3, 87:2, 50:3, 69:3, 49:3, 54:3
+ /scratch/kisskb/src/arch/sh/mm/cache-sh4.c: error:
'cached_to_uncached' undeclared (first use in this function): =>
99:17
+ /scratch/kisskb/src/arch/sh/mm/cache-sh4.c: error: implicit
declaration of function 'cpu_context'
[-Werror=implicit-function-declaration]: => 192:2
+ /scratch/kisskb/src/kernel/bounds.c: error: -mcall-aixdesc must be
big endian: => 1:0
sh-randconfig
+ /scratch/kisskb/src/scripts/mod/devicetable-offsets.c: error:
-mcall-aixdesc must be big endian: => 1:0
+ /scratch/kisskb/src/scripts/mod/empty.c: error: -mcall-aixdesc
must be big endian: => 1:0
+ <stdin>: error: -mcall-aixdesc must be big endian: => 1:0
powerpc-randconfig
> [1] http://kisskb.ellerman.id.au/kisskb/head/7082/ (119 out of 120 configs)
> [3] http://kisskb.ellerman.id.au/kisskb/head/7056/ (119 out of 120 configs)
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
^ permalink raw reply
* Re: [PATCH 0/4] powernv: kvm: numa fault improvement
From: Liu ping fan @ 2014-01-21 9:07 UTC (permalink / raw)
To: Aneesh Kumar K.V; +Cc: Paul Mackerras, linuxppc-dev, Alexander Graf, kvm-ppc
In-Reply-To: <87ob36ypc0.fsf@linux.vnet.ibm.com>
On Tue, Jan 21, 2014 at 11:40 AM, Aneesh Kumar K.V
<aneesh.kumar@linux.vnet.ibm.com> wrote:
> Liu ping fan <kernelfans@gmail.com> writes:
>
>> On Mon, Jan 20, 2014 at 11:45 PM, Aneesh Kumar K.V
>> <aneesh.kumar@linux.vnet.ibm.com> wrote:
>>> Liu ping fan <kernelfans@gmail.com> writes:
>>>
>>>> On Thu, Jan 9, 2014 at 8:08 PM, Alexander Graf <agraf@suse.de> wrote:
>>>>>
>>>>> On 11.12.2013, at 09:47, Liu Ping Fan <kernelfans@gmail.com> wrote:
>>>>>
>>>>>> This series is based on Aneesh's series "[PATCH -V2 0/5] powerpc: mm: Numa faults support for ppc64"
>>>>>>
>>>>>> For this series, I apply the same idea from the previous thread "[PATCH 0/3] optimize for powerpc _PAGE_NUMA"
>>>>>> (for which, I still try to get a machine to show nums)
>>>>>>
>>>>>> But for this series, I think that I have a good justification -- the fact of heavy cost when switching context between guest and host,
>>>>>> which is well known.
>>>>>
>>>>> This cover letter isn't really telling me anything. Please put a proper description of what you're trying to achieve, why you're trying to achieve what you're trying and convince your readers that it's a good idea to do it the way you do it.
>>>>>
>>>> Sorry for the unclear message. After introducing the _PAGE_NUMA,
>>>> kvmppc_do_h_enter() can not fill up the hpte for guest. Instead, it
>>>> should rely on host's kvmppc_book3s_hv_page_fault() to call
>>>> do_numa_page() to do the numa fault check. This incurs the overhead
>>>> when exiting from rmode to vmode. My idea is that in
>>>> kvmppc_do_h_enter(), we do a quick check, if the page is right placed,
>>>> there is no need to exit to vmode (i.e saving htab, slab switching)
>>>
>>> Can you explain more. Are we looking at hcall from guest and
>>> hypervisor handling them in real mode ? If so why would guest issue a
>>> hcall on a pte entry that have PAGE_NUMA set. Or is this about
>>> hypervisor handling a missing hpte, because of host swapping this page
>>> out ? In that case how we end up in h_enter ? IIUC for that case we
>>> should get to kvmppc_hpte_hv_fault.
>>>
>> After setting _PAGE_NUMA, we should flush out all hptes both in host's
>> htab and guest's. So when guest tries to access memory, host finds
>> that there is not hpte ready for guest in guest's htab. And host
>> should raise dsi to guest.
>
> Now guest receive that fault, removes the PAGE_NUMA bit and do an
> hpte_insert. So before we do an hpte_insert (or H_ENTER) we should have
> cleared PAGE_NUMA bit.
>
>>This incurs that guest ends up in h_enter.
>> And you can see in current code, we also try this quick path firstly.
>> Only if fail, we will resort to slow path -- kvmppc_hpte_hv_fault.
>
> hmm ? hpte_hv_fault is the hypervisor handling the fault.
>
After we discuss in irc. I think we should also do the fast check in
kvmppc_hpte_hv_fault() for the case of HPTE_V_ABSENT,
and let H_ENTER take care of the rest case i.e. no hpte when pte_mknuma. Right?
Thanks and regards,
Fan
> -aneesh
>
^ permalink raw reply
* Re: [PATCH 0/4] powernv: kvm: numa fault improvement
From: Liu ping fan @ 2014-01-21 9:11 UTC (permalink / raw)
To: Aneesh Kumar K.V; +Cc: Paul Mackerras, linuxppc-dev, Alexander Graf, kvm-ppc
In-Reply-To: <CAFgQCTuUz-=2Uhi3Zj001-yzSCDe9skCTPkORjCuLW0XSNhjow@mail.gmail.com>
On Tue, Jan 21, 2014 at 5:07 PM, Liu ping fan <kernelfans@gmail.com> wrote:
> On Tue, Jan 21, 2014 at 11:40 AM, Aneesh Kumar K.V
> <aneesh.kumar@linux.vnet.ibm.com> wrote:
>> Liu ping fan <kernelfans@gmail.com> writes:
>>
>>> On Mon, Jan 20, 2014 at 11:45 PM, Aneesh Kumar K.V
>>> <aneesh.kumar@linux.vnet.ibm.com> wrote:
>>>> Liu ping fan <kernelfans@gmail.com> writes:
>>>>
>>>>> On Thu, Jan 9, 2014 at 8:08 PM, Alexander Graf <agraf@suse.de> wrote:
>>>>>>
>>>>>> On 11.12.2013, at 09:47, Liu Ping Fan <kernelfans@gmail.com> wrote:
>>>>>>
>>>>>>> This series is based on Aneesh's series "[PATCH -V2 0/5] powerpc: mm: Numa faults support for ppc64"
>>>>>>>
>>>>>>> For this series, I apply the same idea from the previous thread "[PATCH 0/3] optimize for powerpc _PAGE_NUMA"
>>>>>>> (for which, I still try to get a machine to show nums)
>>>>>>>
>>>>>>> But for this series, I think that I have a good justification -- the fact of heavy cost when switching context between guest and host,
>>>>>>> which is well known.
>>>>>>
>>>>>> This cover letter isn't really telling me anything. Please put a proper description of what you're trying to achieve, why you're trying to achieve what you're trying and convince your readers that it's a good idea to do it the way you do it.
>>>>>>
>>>>> Sorry for the unclear message. After introducing the _PAGE_NUMA,
>>>>> kvmppc_do_h_enter() can not fill up the hpte for guest. Instead, it
>>>>> should rely on host's kvmppc_book3s_hv_page_fault() to call
>>>>> do_numa_page() to do the numa fault check. This incurs the overhead
>>>>> when exiting from rmode to vmode. My idea is that in
>>>>> kvmppc_do_h_enter(), we do a quick check, if the page is right placed,
>>>>> there is no need to exit to vmode (i.e saving htab, slab switching)
>>>>
>>>> Can you explain more. Are we looking at hcall from guest and
>>>> hypervisor handling them in real mode ? If so why would guest issue a
>>>> hcall on a pte entry that have PAGE_NUMA set. Or is this about
>>>> hypervisor handling a missing hpte, because of host swapping this page
>>>> out ? In that case how we end up in h_enter ? IIUC for that case we
>>>> should get to kvmppc_hpte_hv_fault.
>>>>
>>> After setting _PAGE_NUMA, we should flush out all hptes both in host's
>>> htab and guest's. So when guest tries to access memory, host finds
>>> that there is not hpte ready for guest in guest's htab. And host
>>> should raise dsi to guest.
>>
>> Now guest receive that fault, removes the PAGE_NUMA bit and do an
>> hpte_insert. So before we do an hpte_insert (or H_ENTER) we should have
>> cleared PAGE_NUMA bit.
>>
>>>This incurs that guest ends up in h_enter.
>>> And you can see in current code, we also try this quick path firstly.
>>> Only if fail, we will resort to slow path -- kvmppc_hpte_hv_fault.
>>
>> hmm ? hpte_hv_fault is the hypervisor handling the fault.
>>
> After we discuss in irc. I think we should also do the fast check in
> kvmppc_hpte_hv_fault() for the case of HPTE_V_ABSENT,
> and let H_ENTER take care of the rest case i.e. no hpte when pte_mknuma. Right?
>
Or we can delay the quick fix in H_ENTER, and let the host fault
again, so do the fix in kvmppc_hpte_hv_fault()
> Thanks and regards,
> Fan
>> -aneesh
>>
^ permalink raw reply
* Re: [PATCH v2] powernv: kvm: make _PAGE_NUMA take effect
From: Aneesh Kumar K.V @ 2014-01-21 9:42 UTC (permalink / raw)
To: Liu Ping Fan, linuxppc-dev, kvm-ppc, kvm; +Cc: Paul Mackerras, Alexander Graf
In-Reply-To: <1390292129-15871-1-git-send-email-pingfank@linux.vnet.ibm.com>
Liu Ping Fan <kernelfans@gmail.com> writes:
> To make sure that on host, the pages marked with _PAGE_NUMA result in a fault
> when guest access them, we should force the checking when guest uses hypercall
> to setup hpte.
>
> Signed-off-by: Liu Ping Fan <pingfank@linux.vnet.ibm.com>
Reviewed-by: Aneesh Kumar K.V <aneesh.kumar@linux.vnet.ibm.com>
When we mark pte with _PAGE_NUMA we already call mmu_notifier_invalidate_range_start and
mmu_notifier_invalidate_range_end, which will mark existing guest hpte
entry as HPTE_V_ABSENT. Now we need to do that when we are inserting new
guest hpte entries. This patch does that.
> ---
> v2:
> It should be the reply to "[PATCH 2/4] powernv: kvm: make _PAGE_NUMA take effect"
> And I imporve the changelog according to Aneesh's suggestion.
> ---
> arch/powerpc/kvm/book3s_hv_rm_mmu.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/arch/powerpc/kvm/book3s_hv_rm_mmu.c b/arch/powerpc/kvm/book3s_hv_rm_mmu.c
> index 9c51544..af8602d 100644
> --- a/arch/powerpc/kvm/book3s_hv_rm_mmu.c
> +++ b/arch/powerpc/kvm/book3s_hv_rm_mmu.c
> @@ -232,7 +232,7 @@ long kvmppc_do_h_enter(struct kvm *kvm, unsigned long flags,
> /* Look up the Linux PTE for the backing page */
> pte_size = psize;
> pte = lookup_linux_pte(pgdir, hva, writing, &pte_size);
> - if (pte_present(pte)) {
> + if (pte_present(pte) && !pte_numa(pte)) {
> if (writing && !pte_write(pte))
> /* make the actual HPTE be read-only */
> ptel = hpte_make_readonly(ptel);
> --
> 1.8.1.4
^ permalink raw reply
* Re: [PATCH 0/4] powernv: kvm: numa fault improvement
From: Paul Mackerras @ 2014-01-21 11:22 UTC (permalink / raw)
To: Alexander Graf; +Cc: linuxppc-dev, kvm-ppc, Liu ping fan, Aneesh Kumar K.V
In-Reply-To: <62DB3340-5AF7-4DA4-A790-77EE00696F57@suse.de>
On Mon, Jan 20, 2014 at 03:48:36PM +0100, Alexander Graf wrote:
>
> On 15.01.2014, at 07:36, Liu ping fan <kernelfans@gmail.com> wrote:
>
> > On Thu, Jan 9, 2014 at 8:08 PM, Alexander Graf <agraf@suse.de> wrote:
> >>
> >> On 11.12.2013, at 09:47, Liu Ping Fan <kernelfans@gmail.com> wrote:
> >>
> >>> This series is based on Aneesh's series "[PATCH -V2 0/5] powerpc: mm: Numa faults support for ppc64"
> >>>
> >>> For this series, I apply the same idea from the previous thread "[PATCH 0/3] optimize for powerpc _PAGE_NUMA"
> >>> (for which, I still try to get a machine to show nums)
> >>>
> >>> But for this series, I think that I have a good justification -- the fact of heavy cost when switching context between guest and host,
> >>> which is well known.
> >>
> >> This cover letter isn't really telling me anything. Please put a proper description of what you're trying to achieve, why you're trying to achieve what you're trying and convince your readers that it's a good idea to do it the way you do it.
> >>
> > Sorry for the unclear message. After introducing the _PAGE_NUMA,
> > kvmppc_do_h_enter() can not fill up the hpte for guest. Instead, it
> > should rely on host's kvmppc_book3s_hv_page_fault() to call
> > do_numa_page() to do the numa fault check. This incurs the overhead
> > when exiting from rmode to vmode. My idea is that in
> > kvmppc_do_h_enter(), we do a quick check, if the page is right placed,
> > there is no need to exit to vmode (i.e saving htab, slab switching)
> >
> >>> If my suppose is correct, will CCing kvm@vger.kernel.org from next version.
> >>
> >> This translates to me as "This is an RFC"?
> >>
> > Yes, I am not quite sure about it. I have no bare-metal to verify it.
> > So I hope at least, from the theory, it is correct.
>
> Paul, could you please give this some thought and maybe benchmark it?
OK, once I get Aneesh to tell me how I get to have ptes with
_PAGE_NUMA set in the first place. :)
Paul.
^ permalink raw reply
* Re: KGDB panics on p2020 target
From: Arun Chandran @ 2014-01-21 13:15 UTC (permalink / raw)
To: “tiejun.chen”; +Cc: linuxppc-dev
In-Reply-To: <52DE1559.3010806@windriver.com>
[-- Attachment #1: Type: text/plain, Size: 10074 bytes --]
On Tue, Jan 21, 2014 at 12:06 PM, "“tiejun.chen”" <tiejun.chen@windriver.com
> wrote:
> On 01/21/2014 02:04 PM, Arun Chandran wrote:
>
>> On Mon, Jan 20, 2014 at 1:55 PM, "�tiejun.chen�"
>> <tiejun.chen@windriver.com>wrote:
>>
>> On 01/17/2014 03:52 PM, Arun Chandran wrote:
>>>
>>> Hi,
>>>>
>>>> I am testing kgdb on freescale p2020 target.
>>>>
>>>> In target
>>>> ------------
>>>>
>>>> 1)
>>>> root@freescale-p2020ds:~# uname -a
>>>> Linux freescale-p2020ds 3.10.20-rt14+ #9 SMP Thu Jan 16 16:32:15 IST
>>>> 2014
>>>> ppc GNU/Linux
>>>>
>>>> 2)
>>>> root@freescale-p2020ds:~# cat /proc/cpuinfo
>>>> processor : 0
>>>> cpu : e500v2
>>>> clock : 999.990008MHz
>>>> revision : 4.0 (pvr 8021 1040)
>>>> bogomips : 124.99
>>>>
>>>> processor : 1
>>>> cpu : e500v2
>>>> clock : 999.990008MHz
>>>> revision : 4.0 (pvr 8021 1040)
>>>> bogomips : 124.99
>>>>
>>>> total bogomips : 249.99
>>>> timebase : 62499376
>>>> platform : P2020 DS
>>>> model : fsl,P2020DS
>>>> Memory : 768 MB
>>>>
>>>> 3)
>>>> freescale-p2020ds:~# echo "ttyS1,115200" >
>>>> /sys/module/kgdboc/parameters/kgdoc
>>>>
>>>> 4) I set up host (settings given below); Then I send "SysRq : DEBUG"
>>>>
>>>> In host
>>>> ----------
>>>> (gdb) target remote /dev/ttyS0
>>>> Remote debugging using /dev/ttyS0
>>>> kgdb_breakpoint () at kernel/debug/debug_core.c:1013
>>>> 1013 arch_kgdb_breakpoint();
>>>> (gdb) b sys_sync
>>>> Breakpoint 1 at 0xc0167288: file fs/sync.c, line 103.
>>>> (gdb) c
>>>> Continuing.
>>>>
>>>> I am able to take control in host; after that I am setting breakpoint at
>>>> "sys_sync"
>>>>
>>>> In target
>>>> ------------
>>>> root@freescale-p2020ds:~# for i in 1 2 3 4 5 6 7 8 9
>>>>
>>>> do
>>>>> sync
>>>>> done
>>>>>
>>>>>
>>>> In host
>>>> ----------
>>>> Breakpoint 1, sys_sync () at fs/sync.c:103
>>>> 103 {
>>>> (gdb) c
>>>> Continuing.
>>>>
>>>> Breakpoint is hit only one time instead of 9 times; after that target
>>>> hangs.
>>>>
>>>>
>>> I recommend you try upstream to take a further look at this, instead of
>>> that Freescale distribution. As I recall currently KGDB works well in
>>> 85xx
>>> case in ML.
>>>
>>
>>
>> Many thanks for your suggestion.
>>
>> I tested the same thing on linux-3.12.y (
>> https://git.kernel.org/cgit/linux/kernel/git/stable/linux-
>> stable.git/log/?id=refs%2Ftags%2Fv3.12.8&h=linux-3.12.y
>> ).
>>
>>
> Please go powerpc tree,
>
> git clone git://git.kernel.org/pub/scm/linux/kernel/git/benh/powerpc.git
>
> git checkout next
>
>
Yes It works fine on that tree.. Seems my problem is solved by commit
https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/arch/powerpc/kernel/kgdb.c?id=8258e268c15a29c09d7c88d91a948bdf729433d8
Thank you for the help.
>
>
>> root@p2020ds:~# uname -a
>> Linux freescale-p2020ds 3.12.8 #136 SMP Tue Jan 21 11:14:13 IST 2014 ppc
>> GNU/Linux
>>
>>
>> The breakpoint I placed at "sys_sync" is hit only once. After that my gdb
>> command "continue" does not make further
>> hits. And the target is hung. It is not even responding to my further
>> sending of "SysRq : DEBUG"
>>
>> I have attached my .config
>>
>>
>>
>>>
>>>
>>> Then i tried to send "SysRq : DEBUG" in target kernel panics.
>>>>
>>>> I have pasted the panic below.
>>>>
>>>> #########################################
>>>> SysRq : DEBUG
>>>> Kernel panic - not syncing: Recursive entry to debugger
>>>>
>>>>
>>> The kernel already trap into kgdb_handle_exception() with the debug
>>> exception while triggering that break point, but again you trigger
>>> another
>>> debug exception by SysRq. Actually KGDB can't handle such this recursive
>>> behavior, so KGDB always call kgdb_reenter_check() to prevent this
>>> scenario
>>> with this call trace.
>>>
>>>
>>> I am doing it because the target is hung after the initial breakpoint is
>> hit.
>>
>
> This is just what I mean. Although looks your kernel is hung, actually
> your kernel is already in kgdb exception handler previously. So after you
> send break by SysRq to debug, its not allowed by current kgdb scheme as I
> said. The following call trace also show this path explicitly.
>
> Tiejun
>
>
>
>>
>> static int kgdb_reenter_check(struct kgdb_state *ks)
>>> {
>>> unsigned long addr;
>>>
>>> if (atomic_read(&kgdb_active) != raw_smp_processor_id())
>>> return 0;
>>> ...
>>>
>>> if (exception_level > 1) {
>>> dump_stack();
>>> panic("Recursive entry to debugger");
>>> }
>>>
>>>
>>> Tiejun
>>>
>>> CPU: 1 PID: 2266 Comm: cron Not tainted 3.10.20-rt14+ #6
>>>
>>>> Call Trace:
>>>> [effe5d10] [c0008060] show_stack+0x4c/0x168 (unreliable)
>>>> [effe5d50] [c0588878] panic+0xe4/0x224
>>>> [effe5da0] [c00b2cbc] kgdb_handle_exception+0x1d4/0x1f8
>>>> [effe5df0] [c0010038] kgdb_handle_breakpoint+0x4c/0x80
>>>> [effe5e00] [c057e7e0] program_check_exception+0x10c/0x264
>>>> [effe5e10] [c000f660] ret_from_except_full+0x0/0x4c
>>>> --- Exception: 700 at sysrq_handle_dbg+0x3c/0xc8
>>>> LR = __handle_sysrq+0x154/0x1cc
>>>> [effe5ed0] [c033df5c] __handle_sysrq+0x140/0x1cc (unreliable)
>>>> [effe5f00] [c0353ef8] serial8250_rx_chars+0xe8/0x218
>>>> [effe5f30] [c0359644] fsl8250_handle_irq+0xac/0x174
>>>> [effe5f50] [c0352f9c] serial8250_interrupt+0x40/0xe8
>>>> [effe5f70] [c00b5500] handle_irq_event_percpu+0xcc/0x2a8
>>>> [effe5fc0] [c00b5720] handle_irq_event+0x44/0x74
>>>> [effe5fe0] [c00b8e14] handle_fasteoi_irq+0xd0/0x17c
>>>> [effe5ff0] [c000d58c] call_handle_irq+0x18/0x28
>>>> [c4f91b10] [c0004f60] do_IRQ+0x150/0x224
>>>> [c4f91b40] [c000f6ac] ret_from_except+0x0/0x18
>>>> --- Exception: 501 at rpcauth_lookup_credcache+0x138/0x2a4
>>>> LR = rpcauth_lookup_credcache+0xb8/0x2a4
>>>> [c4f91c00] [24002424] 0x24002424 (unreliable)
>>>> [c4f91c50] [c055cb84] rpcauth_lookupcred+0x64/0xac
>>>> [c4f91c80] [c055ce2c] rpcauth_refreshcred+0x11c/0x124
>>>> [c4f91cc0] [c055ac80] __rpc_execute+0x8c/0x330
>>>> [c4f91d10] [c05540b8] rpc_run_task+0x9c/0xc4
>>>> [c4f91d20] [c0554204] rpc_call_sync+0x50/0xb8
>>>> [c4f91d50] [c0257164] nfs_proc_getattr+0x48/0x5c
>>>> [c4f91d70] [c024aaa4] __nfs_revalidate_inode+0xa8/0x168
>>>> [c4f91d90] [c024ac1c] nfs_revalidate_mapping+0xb8/0x194
>>>> [c4f91da0] [c0251f00] nfs_follow_link+0x24/0xc8
>>>> [c4f91dc0] [c0145280] path_lookupat+0x2f4/0x824
>>>> [c4f91e10] [c01457dc] filename_lookup.isra.33+0x2c/0x8c
>>>> [c4f91e30] [c0147a74] user_path_at_empty+0x58/0x9c
>>>> [c4f91eb0] [c013d5bc] vfs_fstatat+0x54/0xb4
>>>> [c4f91ee0] [c013d93c] SyS_stat64+0x1c/0x44
>>>> [c4f91f40] [c000eec0] ret_from_syscall+0x0/0x3c
>>>> --- Exception: c01 at 0xff08a98
>>>> LR = 0xfed53e8
>>>> CPU: 1 PID: 2266 Comm: cron Not tainted 3.10.20-rt14+ #6
>>>> Call Trace:
>>>> [effe5bb0] [c0008060] show_stack+0x4c/0x168 (unreliable)
>>>> [effe5bf0] [c00b2cac] kgdb_handle_exception+0x1c4/0x1f8
>>>> [effe5c40] [c0010038] kgdb_handle_breakpoint+0x4c/0x80
>>>> [effe5c50] [c057e7e0] program_check_exception+0x10c/0x264
>>>> [effe5c60] [c000f660] ret_from_except_full+0x0/0x4c
>>>> --- Exception: 700 at kgdb_panic_event+0x1c/0x3c
>>>> LR = notifier_call_chain+0x60/0xb0
>>>> [effe5d20] [00000000] (nil) (unreliable)
>>>> [effe5d40] [c05819dc] __atomic_notifier_call_chain+0x14/0x24
>>>> [effe5d50] [c05888a8] panic+0x114/0x224
>>>> [effe5da0] [c00b2cbc] kgdb_handle_exception+0x1d4/0x1f8
>>>> [effe5df0] [c0010038] kgdb_handle_breakpoint+0x4c/0x80
>>>> [effe5e00] [c057e7e0] program_check_exception+0x10c/0x264
>>>> [effe5e10] [c000f660] ret_from_except_full+0x0/0x4c
>>>> --- Exception: 700 at sysrq_handle_dbg+0x3c/0xc8
>>>> LR = __handle_sysrq+0x154/0x1cc
>>>> [effe5ed0] [c033df5c] __handle_sysrq+0x140/0x1cc (unreliable)
>>>> [effe5f00] [c0353ef8] serial8250_rx_chars+0xe8/0x218
>>>> [effe5f30] [c0359644] fsl8250_handle_irq+0xac/0x174
>>>> [effe5f50] [c0352f9c] serial8250_interrupt+0x40/0xe8
>>>> [effe5f70] [c00b5500] handle_irq_event_percpu+0xcc/0x2a8
>>>> [effe5fc0] [c00b5720] handle_irq_event+0x44/0x74
>>>> [effe5fe0] [c00b8e14] handle_fasteoi_irq+0xd0/0x17c
>>>> [effe5ff0] [c000d58c] call_handle_irq+0x18/0x28
>>>> [c4f91b10] [c0004f60] do_IRQ+0x150/0x224
>>>> [c4f91b40] [c000f6ac] ret_from_except+0x0/0x18
>>>> --- Exception: 501 at rpcauth_lookup_credcache+0x138/0x2a4
>>>> LR = rpcauth_lookup_credcache+0xb8/0x2a4
>>>> [c4f91c00] [24002424] 0x24002424 (unreliable)
>>>> [c4f91c50] [c055cb84] rpcauth_lookupcred+0x64/0xac
>>>> [c4f91c80] [c055ce2c] rpcauth_refreshcred+0x11c/0x124
>>>> [c4f91cc0] [c055ac80] __rpc_execute+0x8c/0x330
>>>> [c4f91d10] [c05540b8] rpc_run_task+0x9c/0xc4
>>>> [c4f91d20] [c0554204] rpc_call_sync+0x50/0xb8
>>>> [c4f91d50] [c0257164] nfs_proc_getattr+0x48/0x5c
>>>> [c4f91d70] [c024aaa4] __nfs_revalidate_inode+0xa8/0x168
>>>> [c4f91d90] [c024ac1c] nfs_revalidate_mapping+0xb8/0x194
>>>> [c4f91da0] [c0251f00] nfs_follow_link+0x24/0xc8
>>>> [c4f91dc0] [c0145280] path_lookupat+0x2f4/0x824
>>>> [c4f91e10] [c01457dc] filename_lookup.isra.33+0x2c/0x8c
>>>> [c4f91e30] [c0147a74] user_path_at_empty+0x58/0x9c
>>>> [c4f91eb0] [c013d5bc] vfs_fstatat+0x54/0xb4
>>>> [c4f91ee0] [c013d93c] SyS_stat64+0x1c/0x44
>>>> [c4f91f40] [c000eec0] ret_from_syscall+0x0/0x3c
>>>> --- Exception: c01 at 0xff08a98
>>>> LR = 0xfed53e8
>>>>
>>>>
>>>> ########################################################
>>>>
>>>> Could you please share your thoughts on this issue?
>>>>
>>>> I have also attached my kernel .config.
>>>>
>>>> Regards,
>>>> Arun C
>>>>
>>>>
>>>>
>>>> _______________________________________________
>>>> Linuxppc-dev mailing list
>>>> Linuxppc-dev@lists.ozlabs.org
>>>> https://lists.ozlabs.org/listinfo/linuxppc-dev
>>>>
>>>>
>>>>
>>>
>>
>
[-- Attachment #2: Type: text/html, Size: 13648 bytes --]
^ permalink raw reply
* Re: [PATCH] powerpc: set the correct ksp_limit on ppc32 when switching to irq stack
From: Guenter Roeck @ 2014-01-21 16:14 UTC (permalink / raw)
To: Kevin Hao; +Cc: linuxppc
In-Reply-To: <1389932728-25178-1-git-send-email-haokexin@gmail.com>
On Fri, Jan 17, 2014 at 12:25:28PM +0800, Kevin Hao wrote:
> Guenter Roeck has got the following call trace on a p2020 board:
> Kernel stack overflow in process eb3e5a00, r1=eb79df90
> CPU: 0 PID: 2838 Comm: ssh Not tainted 3.13.0-rc8-juniper-00146-g19eca00 #4
> task: eb3e5a00 ti: c0616000 task.ti: ef440000
> NIP: c003a420 LR: c003a410 CTR: c0017518
> REGS: eb79dee0 TRAP: 0901 Not tainted (3.13.0-rc8-juniper-00146-g19eca00)
> MSR: 00029000 <CE,EE,ME> CR: 24008444 XER: 00000000
> GPR00: c003a410 eb79df90 eb3e5a00 00000000 eb05d900 00000001 65d87646 00000000
> GPR08: 00000000 020b8000 00000000 00000000 44008442
> NIP [c003a420] __do_softirq+0x94/0x1ec
> LR [c003a410] __do_softirq+0x84/0x1ec
> Call Trace:
> [eb79df90] [c003a410] __do_softirq+0x84/0x1ec (unreliable)
> [eb79dfe0] [c003a970] irq_exit+0xbc/0xc8
> [eb79dff0] [c000cc1c] call_do_irq+0x24/0x3c
> [ef441f20] [c00046a8] do_IRQ+0x8c/0xf8
> [ef441f40] [c000e7f4] ret_from_except+0x0/0x18
> --- Exception: 501 at 0xfcda524
> LR = 0x10024900
> Instruction dump:
> 7c781b78 3b40000a 3a73b040 543c0024 3a800000 3b3913a0 7ef5bb78 48201bf9
> 5463103a 7d3b182e 7e89b92e 7c008146 <3ba00000> 7e7e9b78 48000014 57fff87f
> Kernel panic - not syncing: kernel stack overflow
> CPU: 0 PID: 2838 Comm: ssh Not tainted 3.13.0-rc8-juniper-00146-g19eca00 #4
> Call Trace:
>
> The reason is that we have used the wrong register to calculate the
> ksp_limit in commit cbc9565ee826 (powerpc: Remove ksp_limit on ppc64).
> Just fix it.
>
> As suggested by Benjamin Herrenschmidt, also add the C prototype of the
> function in the comment in order to avoid such kind of errors in the
> future.
>
Was this patch accepted, or are there any problems with it ?
I didn't see any comments, and it still isn't upstream nor in linux-next.
Thanks,
Guenter
^ permalink raw reply
* Re: [PATCH RFC] powerpc/mpc85xx: add support for the kmp204x reference board
From: Valentin Longchamp @ 2014-01-21 16:34 UTC (permalink / raw)
To: Scott Wood; +Cc: linuxppc-dev@lists.ozlabs.org
In-Reply-To: <1390257432.24905.329.camel@snotra.buserror.net>
On 01/20/2014 11:37 PM, Scott Wood wrote:
> On Mon, 2014-01-20 at 17:38 +0100, Valentin Longchamp wrote:
>> On 01/17/2014 10:48 PM, Scott Wood wrote:
>>> On Fri, 2014-01-17 at 13:51 +0100, Valentin Longchamp wrote:
>>>> Hi Scott,
>>>>
>>>> Thanks for you feedback.
>>>>
>>>> On 01/17/2014 12:35 AM, Scott Wood wrote:
>>>>> On Thu, 2014-01-16 at 14:38 +0100, Valentin Longchamp wrote:
>>>>>> This patch introduces the support for Keymile's kmp204x reference
>>>>>> design. This design is based on Freescale's P2040/P2041 SoC.
>>>>>>
>>>>>> The peripherals used by this design are:
>>>>>> - SPI NOR Flash as bootloader medium
>>>>>> - NAND Flash with a ubi partition
>>>>>> - 2 PCIe busses (hosts 1 and 3)
>>>>>> - 3 FMAN Ethernet devices (FMAN1 DTSEC1/2/5)
>>>>>> - 4 Local Bus windows, with one dedicated to the QRIO reset/power mgmt
>>>>>> FPGA
>>>>>> - 2 HW I2C busses
>>>>>> - last but not least, the mandatory serial port
>>>>>>
>>>>>> The patch also adds a defconfig file for this reference design and a DTS
>>>>>> file for the kmcoge4 board which is the first one based on this
>>>>>> reference design.
>>>>>>
>>>>>> To try to avoid code duplication, the support was added directly to the
>>>>>> corenet_generic.c file.
>>>>>>
>>>>>> Signed-off-by: Valentin Longchamp <valentin.longchamp@keymile.com>
>>>>>> ---
>>>>>> arch/powerpc/boot/dts/kmcoge4.dts | 165 ++++++++++++++++++
>>>>>> arch/powerpc/configs/85xx/kmp204x_defconfig | 231 ++++++++++++++++++++++++++
>>>>>> arch/powerpc/platforms/85xx/Kconfig | 14 ++
>>>>>> arch/powerpc/platforms/85xx/Makefile | 1 +
>>>>>> arch/powerpc/platforms/85xx/corenet_generic.c | 52 ++++++
>>>>>> 5 files changed, 463 insertions(+)
>>>>>> create mode 100644 arch/powerpc/boot/dts/kmcoge4.dts
>>>>>> create mode 100644 arch/powerpc/configs/85xx/kmp204x_defconfig
>>>>>>
>>>>>> diff --git a/arch/powerpc/boot/dts/kmcoge4.dts b/arch/powerpc/boot/dts/kmcoge4.dts
>>>>>> new file mode 100644
>>>>>> index 0000000..c10df6d
>>>>>> --- /dev/null
>>>>>> +++ b/arch/powerpc/boot/dts/kmcoge4.dts
>>>>>> @@ -0,0 +1,165 @@
>>>>>> +/*
>>>>>> + * Keymile kmcoge4 Device Tree Source, based on the P2041RDB DTS
>>>>>> + *
>>>>>> + * (C) Copyright 2014
>>>>>> + * Valentin Longchamp, Keymile AG, valentin.longchamp@keymile.com
>>>>>> + *
>>>>>> + * Copyright 2011 Freescale Semiconductor Inc.
>>>>>> + *
>>>>>> + * This program is free software; you can redistribute it and/or modify it
>>>>>> + * under the terms of the GNU General Public License as published by the
>>>>>> + * Free Software Foundation; either version 2 of the License, or (at your
>>>>>> + * option) any later version.
>>>>>> + */
>>>>>> +
>>>>>> +/include/ "fsl/p2041si-pre.dtsi"
>>>>>> +
>>>>>> +/ {
>>>>>> + model = "keymile,kmcoge4";
>>>>>> + compatible = "keymile,kmp204x";
>>>>>
>>>>> Don't put wildcards in compatible.
>>>>
>>>> Well it's a wildcard in the sense that we support both the p2040 and the p2041,
>>>> but it's also the name of the plaftorm, similarly to names like '85xx' or 'tqm85xx'.
>>>
>>> Names like 85xx are not allowed in device trees.
>>>
>>> With "p204x", what would happen if a p2042 were introduced, that were
>>> not compatible?
>>
>> What would you suggest as a generic name for the architecture that supports both ?
>>
>>>
>>> Why isn't the compatible "keymile,kmcoge4", like the model?
>>
>> Because kmcoge4 is the board that is based on the kmp204x architecture/design.
>> We expect other boards (kmcoge7 for instance) based on the same kmp204x design.
>
> The top-level compatible isn't for the "architecture" or the "design".
> It's for the board. Surely there's something different about kmcoge7
> versus kmcoge4 -- is it visible to software?
There should only be a few differences in the dts between the two boards.
Reading the ePAPR my understanding was that compatible is the "programming
model" and that's what I have named above design/architecture while model is the
exact model of the device in this case the exact board name.
>
>> You would prefer that I have the model and compatible stricly the same and add
>> any future board into the compatible boards[] from corenet_generic ?
>
> That's how it's usually done. Or, at least provide the board
> architecture name as a secondary compatible after the board name.
>
>> If possible I would like to be able to see the boards that are based on a
>> similar design, that's what I wanted to achieve with this kmp204x name.
>
> Is "kmp204x" an official name of the architecture, rather than a
> generalization of "kmp2040" and "kmp2041"? If there were a p2042, and
> you made a board for it, is there any chance it would be called kmp204x
> even if it were very different from the p2040/p2041 board?
It's the name we have picked up, but it's not official. We also use km83xx,
km82xx and it was derived from that.
If the hypothetical p2042 board was different it would then have another name.
>
>>>>>> + zl30343@1 {
>>>>>> + compatible = "gen,spidev";
>>>>>
>>>>> Node names are supposed to be generic. Compatibles are supposed to be
>>>>> specific.
>>>>
>>>> That's a very specific device for which we only have a userspace driver and for
>>>> which we must use the generic kernel spidev driver.
>>>
>>> The device tree describes the hardware, not what driver you want to use.
>>>
>>> Plus, I don't see any driver that matches "gen,spidev" nor any binding
>>> for it, and "gen" doesn't make sense as a vendor prefix. The only
>>> instance of that string I can find in the Linux tree is in mgcoge.dts.
>>
>> Well it comes from mgcoge and that's why I have used this
>>
>> It's for usage with the spidev driver (driver/spi/spidev.c). I agree that the
>> gen brings nothing. Would
>>
>> spidev@1 {
>> compatible = "spidev";
>>
>> make more sense ?
>
> It doesn't address any of the other comments.
Can you please explicitly tell me how I should build this node ? What other
comments ? Must I be more generic with the name ?
Something like :
spi@1 {
compatible = "zarlink,30343", "spidev";
>
>>>>>> + lbc: localbus@ffe124000 {
>>>>>> + reg = <0xf 0xfe124000 0 0x1000>;
>>>>>> + ranges = <0 0 0xf 0xffa00000 0x00040000 /* LB 0 */
>>>>>> + 1 0 0xf 0xfb000000 0x00010000 /* LB 1 */
>>>>>> + 2 0 0xf 0xd0000000 0x10000000 /* LB 2 */
>>>>>> + 3 0 0xf 0xe0000000 0x10000000>; /* LB 3 */
>>>>>> +
>>>>>> + nand@0,0 {
>>>>>> + #address-cells = <1>;
>>>>>> + #size-cells = <1>;
>>>>>> + compatible = "fsl,elbc-fcm-nand";
>>>>>> + reg = <0 0 0x40000>;
>>>>>> +
>>>>>> + partition@0 {
>>>>>> + label = "ubi0";
>>>>>> + reg = <0x0 0x8000000>;
>>>>>> + };
>>>>>> + };
>>>>>> + };
>>>>>
>>>>> No nodes for those other chipselects?
>>>>
>>>> Well, there are nodes, but they are internally developed FPGAs and the drivers
>>>> are not mainlined that's why I removed the nodes.
>>>
>>> The device tree describes the hardware, not what drivers are currently
>>> mainlined in Linux.
>>
>> What do you want me to do: add the nodes for which there are no bindings ?
>
> No, ideally you'd add bindings and nodes. I'm not going to insist on it
> if bindings aren't ready, but please don't leave things out only because
> there's no driver.
Ideally we would add the bindings yes. But in the real world it's impossible for
a company like us with limited resources to port the drivers of our FPGAs and
their bindings to mainline. I will see what I can extract from the node and put
them back.
Valentin
^ permalink raw reply
* Re: [PATCH RFC] powerpc/mpc85xx: add support for the kmp204x reference board
From: Scott Wood @ 2014-01-21 17:01 UTC (permalink / raw)
To: Valentin Longchamp; +Cc: linuxppc-dev@lists.ozlabs.org
In-Reply-To: <52DEA179.9090607@keymile.com>
On Tue, 2014-01-21 at 17:34 +0100, Valentin Longchamp wrote:
> On 01/20/2014 11:37 PM, Scott Wood wrote:
> > On Mon, 2014-01-20 at 17:38 +0100, Valentin Longchamp wrote:
> >> On 01/17/2014 10:48 PM, Scott Wood wrote:
> >>> Why isn't the compatible "keymile,kmcoge4", like the model?
> >>
> >> Because kmcoge4 is the board that is based on the kmp204x architecture/design.
> >> We expect other boards (kmcoge7 for instance) based on the same kmp204x design.
> >
> > The top-level compatible isn't for the "architecture" or the "design".
> > It's for the board. Surely there's something different about kmcoge7
> > versus kmcoge4 -- is it visible to software?
>
> There should only be a few differences in the dts between the two boards.
>
> Reading the ePAPR my understanding was that compatible is the "programming
> model" and that's what I have named above design/architecture while model is the
> exact model of the device in this case the exact board name.
In practice, model is more for human consumption (e.g. there may be many
variants that all look identical to software). The "programming model"
for an entire board includes everything on it.
> >> You would prefer that I have the model and compatible stricly the same and add
> >> any future board into the compatible boards[] from corenet_generic ?
> >
> > That's how it's usually done. Or, at least provide the board
> > architecture name as a secondary compatible after the board name.
> >
> >> If possible I would like to be able to see the boards that are based on a
> >> similar design, that's what I wanted to achieve with this kmp204x name.
> >
> > Is "kmp204x" an official name of the architecture, rather than a
> > generalization of "kmp2040" and "kmp2041"? If there were a p2042, and
> > you made a board for it, is there any chance it would be called kmp204x
> > even if it were very different from the p2040/p2041 board?
>
> It's the name we have picked up, but it's not official. We also use km83xx,
> km82xx and it was derived from that.
>
> If the hypothetical p2042 board was different it would then have another name.
In that case, I don't object to it being listed in compatible, though
the specific board name should come first.
> >>> The device tree describes the hardware, not what driver you want to use.
> >>>
> >>> Plus, I don't see any driver that matches "gen,spidev" nor any binding
> >>> for it, and "gen" doesn't make sense as a vendor prefix. The only
> >>> instance of that string I can find in the Linux tree is in mgcoge.dts.
> >>
> >> Well it comes from mgcoge and that's why I have used this
> >>
> >> It's for usage with the spidev driver (driver/spi/spidev.c). I agree that the
> >> gen brings nothing. Would
> >>
> >> spidev@1 {
> >> compatible = "spidev";
> >>
> >> make more sense ?
> >
> > It doesn't address any of the other comments.
>
> Can you please explicitly tell me how I should build this node ? What other
> comments ? Must I be more generic with the name ?
>
> Something like :
>
> spi@1 {
> compatible = "zarlink,30343", "spidev";
Remove "spidev". Any nodes under the SPI controller node will be SPI
devices, right? So it doesn't add anything regarding hardware
description.
-Scott
^ permalink raw reply
* Re: [PATCH 1/2][v5] driver/memory:Move Freescale IFC driver to a common driver
From: Kumar Gala @ 2014-01-21 17:11 UTC (permalink / raw)
To: Prabhakar Kushwaha; +Cc: Scott Wood, linuxppc-dev, linux-kernel
In-Reply-To: <1390026091-25111-1-git-send-email-prabhakar@freescale.com>
On Jan 18, 2014, at 12:21 AM, Prabhakar Kushwaha =
<prabhakar@freescale.com> wrote:
> Freescale IFC controller has been used for mpc8xxx. It will be used
> for ARM-based SoC as well. This patch moves the driver to =
driver/memory
> and fix the header file includes.
>=20
> Also remove module_platform_driver() and instead call
> platform_driver_register() from subsys_initcall() to make sure this =
module
> has been loaded before MTD partition parsing starts.
>=20
> Signed-off-by: Prabhakar Kushwaha <prabhakar@freescale.com>
> Acked-by: Arnd Bergmann <arnd@arndb.de>
> ---
> Changes for v2:
> - Move fsl_ifc in driver/memory
>=20
> Changes for v3:
> - move device tree bindings to memory
>=20
> Changes for v4: Rebased to=20
> =
git://git.kernel.org/pub/scm/linux/kernel/git/scottwood/linux.git
>=20
> Changes for v5:=20
> - Moved powerpc/Kconfig option to driver/memory
>=20
>=20
> .../{powerpc =3D> memory-controllers}/fsl/ifc.txt | 0
> arch/powerpc/Kconfig | 4 ----
> arch/powerpc/sysdev/Makefile | 1 -
> drivers/memory/Kconfig | 4 ++++
> drivers/memory/Makefile | 1 +
> {arch/powerpc/sysdev =3D> drivers/memory}/fsl_ifc.c | 8 ++++++--
> drivers/mtd/nand/fsl_ifc_nand.c | 2 +-
> .../include/asm =3D> include/linux}/fsl_ifc.h | 0
> 8 files changed, 12 insertions(+), 8 deletions(-)
> rename Documentation/devicetree/bindings/{powerpc =3D> =
memory-controllers}/fsl/ifc.txt (100%)
> rename {arch/powerpc/sysdev =3D> drivers/memory}/fsl_ifc.c (98%)
> rename {arch/powerpc/include/asm =3D> include/linux}/fsl_ifc.h (100%)
>=20
> diff --git a/Documentation/devicetree/bindings/powerpc/fsl/ifc.txt =
b/Documentation/devicetree/bindings/memory-controllers/fsl/ifc.txt
> similarity index 100%
> rename from Documentation/devicetree/bindings/powerpc/fsl/ifc.txt
> rename to =
Documentation/devicetree/bindings/memory-controllers/fsl/ifc.txt
> diff --git a/arch/powerpc/Kconfig b/arch/powerpc/Kconfig
> index b44b52c..83fb8b3 100644
> --- a/arch/powerpc/Kconfig
> +++ b/arch/powerpc/Kconfig
> @@ -725,10 +725,6 @@ config FSL_LBC
> controller. Also contains some common code used by
> drivers for specific local bus peripherals.
>=20
> -config FSL_IFC
> - bool
> - depends on FSL_SOC
> -
> config FSL_GTM
> bool
> depends on PPC_83xx || QUICC_ENGINE || CPM2
> diff --git a/arch/powerpc/sysdev/Makefile =
b/arch/powerpc/sysdev/Makefile
> index f67ac90..afbcc37 100644
> --- a/arch/powerpc/sysdev/Makefile
> +++ b/arch/powerpc/sysdev/Makefile
> @@ -21,7 +21,6 @@ obj-$(CONFIG_FSL_SOC) +=3D fsl_soc.o =
fsl_mpic_err.o
> obj-$(CONFIG_FSL_PCI) +=3D fsl_pci.o $(fsl-msi-obj-y)
> obj-$(CONFIG_FSL_PMC) +=3D fsl_pmc.o
> obj-$(CONFIG_FSL_LBC) +=3D fsl_lbc.o
> -obj-$(CONFIG_FSL_IFC) +=3D fsl_ifc.o
> obj-$(CONFIG_FSL_GTM) +=3D fsl_gtm.o
> obj-$(CONFIG_FSL_85XX_CACHE_SRAM) +=3D fsl_85xx_l2ctlr.o =
fsl_85xx_cache_sram.o
> obj-$(CONFIG_SIMPLE_GPIO) +=3D simple_gpio.o
> diff --git a/drivers/memory/Kconfig b/drivers/memory/Kconfig
> index 29a11db..b33bb0e 100644
> --- a/drivers/memory/Kconfig
> +++ b/drivers/memory/Kconfig
> @@ -50,4 +50,8 @@ config TEGRA30_MC
> analysis, especially for IOMMU/SMMU(System Memory Management
> Unit) module.
>=20
> +config FSL_IFC
> + bool
> + depends on FSL_SOC
> +
I think this should be user selectable like all the other Kconfig =
options in drivers/memory
Also add a help description.
> endif
[ snip ]
- k
^ permalink raw reply
* [PATCH 11/73] powerpc: book3s KVM can be modular so it should use module.h
From: Paul Gortmaker @ 2014-01-21 21:22 UTC (permalink / raw)
To: linux-kernel
Cc: linux-arch, kvm, Gleb Natapov, Alexander Graf, kvm-ppc,
Paul Gortmaker, Paul Mackerras, Paolo Bonzini, linuxppc-dev
In-Reply-To: <1390339396-3479-1-git-send-email-paul.gortmaker@windriver.com>
Even though KVM is bool, KVM_BOOK3S_32 and KVM_BOOK3S_64 are declared
as Kconfig tristate, so this file really should be including
module.h instead of export.h -- it only works currently because
module_init is currently (mis)placed in init.h -- but we are
intending to clean that up and relocate it to module.h
Cc: Gleb Natapov <gleb@kernel.org>
Cc: Paolo Bonzini <pbonzini@redhat.com>
Cc: Alexander Graf <agraf@suse.de>
Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Cc: Paul Mackerras <paulus@samba.org>
Cc: kvm@vger.kernel.org
Cc: kvm-ppc@vger.kernel.org
Cc: linuxppc-dev@lists.ozlabs.org
Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>
---
arch/powerpc/kvm/book3s.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/powerpc/kvm/book3s.c b/arch/powerpc/kvm/book3s.c
index 8912608..279459e 100644
--- a/arch/powerpc/kvm/book3s.c
+++ b/arch/powerpc/kvm/book3s.c
@@ -16,7 +16,7 @@
#include <linux/kvm_host.h>
#include <linux/err.h>
-#include <linux/export.h>
+#include <linux/module.h>
#include <linux/slab.h>
#include <asm/reg.h>
--
1.8.4.1
^ permalink raw reply related
* [PATCH 12/73] powerpc: kvm e500/44x is not modular, so don't use module_init
From: Paul Gortmaker @ 2014-01-21 21:22 UTC (permalink / raw)
To: linux-kernel
Cc: linux-arch, kvm, Gleb Natapov, Alexander Graf, kvm-ppc,
Paul Gortmaker, Paul Mackerras, Paolo Bonzini, linuxppc-dev
In-Reply-To: <1390339396-3479-1-git-send-email-paul.gortmaker@windriver.com>
In powerpc, CONFIG_KVM is bool, and so are these three subarch
options, for the 44x and e500 variants. This means that any
module_exit() calls and functions used by them such as the
kvmppc_booke_exit() are dead code. Here we remove them.
In addition, rather than use module_init, which is just
__initcall for non-modules, we update those as well.
Note that direct use of __initcall is discouraged, vs. one
of the priority categorized subgroups. As __initcall gets
mapped onto device_initcall, our use of subsys_initcall (which
seems to make sense for netfilter code) will thus change this
registration from level 6-device to level 4-subsys (i.e. slightly
earlier).
However no impact of that small difference is expected,
since the arch independent kvm code doesn't trigger any init;
it is the arch initcalls here which actually call kvm_init.
Cc: Gleb Natapov <gleb@kernel.org>
Cc: Paolo Bonzini <pbonzini@redhat.com>
Cc: Alexander Graf <agraf@suse.de>
Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Cc: Paul Mackerras <paulus@samba.org>
Cc: kvm@vger.kernel.org
Cc: kvm-ppc@vger.kernel.org
Cc: linuxppc-dev@lists.ozlabs.org
Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>
---
arch/powerpc/include/asm/kvm_ppc.h | 1 -
arch/powerpc/kvm/44x.c | 10 +---------
arch/powerpc/kvm/booke.c | 6 ------
arch/powerpc/kvm/e500.c | 10 +---------
arch/powerpc/kvm/e500mc.c | 10 +---------
5 files changed, 3 insertions(+), 34 deletions(-)
diff --git a/arch/powerpc/include/asm/kvm_ppc.h b/arch/powerpc/include/asm/kvm_ppc.h
index c8317fb..8466df5 100644
--- a/arch/powerpc/include/asm/kvm_ppc.h
+++ b/arch/powerpc/include/asm/kvm_ppc.h
@@ -109,7 +109,6 @@ extern void kvmppc_core_flush_tlb(struct kvm_vcpu *vcpu);
extern int kvmppc_core_check_requests(struct kvm_vcpu *vcpu);
extern int kvmppc_booke_init(void);
-extern void kvmppc_booke_exit(void);
extern void kvmppc_core_destroy_mmu(struct kvm_vcpu *vcpu);
extern int kvmppc_kvm_pv(struct kvm_vcpu *vcpu);
diff --git a/arch/powerpc/kvm/44x.c b/arch/powerpc/kvm/44x.c
index 93221e8..2129fc1 100644
--- a/arch/powerpc/kvm/44x.c
+++ b/arch/powerpc/kvm/44x.c
@@ -222,12 +222,4 @@ static int __init kvmppc_44x_init(void)
err_out:
return r;
}
-
-static void __exit kvmppc_44x_exit(void)
-{
- kvmppc_pr_ops = NULL;
- kvmppc_booke_exit();
-}
-
-module_init(kvmppc_44x_init);
-module_exit(kvmppc_44x_exit);
+subsys_initcall(kvmppc_44x_init);
diff --git a/arch/powerpc/kvm/booke.c b/arch/powerpc/kvm/booke.c
index 0591e05..49dffa2 100644
--- a/arch/powerpc/kvm/booke.c
+++ b/arch/powerpc/kvm/booke.c
@@ -1995,9 +1995,3 @@ int __init kvmppc_booke_init(void)
#endif /* !BOOKE_HV */
return 0;
}
-
-void __exit kvmppc_booke_exit(void)
-{
- free_pages(kvmppc_booke_handlers, VCPU_SIZE_ORDER);
- kvm_exit();
-}
diff --git a/arch/powerpc/kvm/e500.c b/arch/powerpc/kvm/e500.c
index 497b142..115ef12 100644
--- a/arch/powerpc/kvm/e500.c
+++ b/arch/powerpc/kvm/e500.c
@@ -564,12 +564,4 @@ static int __init kvmppc_e500_init(void)
err_out:
return r;
}
-
-static void __exit kvmppc_e500_exit(void)
-{
- kvmppc_pr_ops = NULL;
- kvmppc_booke_exit();
-}
-
-module_init(kvmppc_e500_init);
-module_exit(kvmppc_e500_exit);
+subsys_initcall(kvmppc_e500_init);
diff --git a/arch/powerpc/kvm/e500mc.c b/arch/powerpc/kvm/e500mc.c
index 4132cd2..612c216 100644
--- a/arch/powerpc/kvm/e500mc.c
+++ b/arch/powerpc/kvm/e500mc.c
@@ -382,12 +382,4 @@ static int __init kvmppc_e500mc_init(void)
err_out:
return r;
}
-
-static void __exit kvmppc_e500mc_exit(void)
-{
- kvmppc_pr_ops = NULL;
- kvmppc_booke_exit();
-}
-
-module_init(kvmppc_e500mc_init);
-module_exit(kvmppc_e500mc_exit);
+subsys_initcall(kvmppc_e500mc_init);
--
1.8.4.1
^ permalink raw reply related
* [PATCH 14/73] powerpc: don't use module_init for non-modular core hugetlb code
From: Paul Gortmaker @ 2014-01-21 21:22 UTC (permalink / raw)
To: linux-kernel; +Cc: linux-arch, Paul Gortmaker, Paul Mackerras, linuxppc-dev
In-Reply-To: <1390339396-3479-1-git-send-email-paul.gortmaker@windriver.com>
The hugetlbpage.o is obj-y (always built in). It will never
be modular, so using module_init as an alias for __initcall is
somewhat misleading.
Fix this up now, so that we can relocate module_init from
init.h into module.h in the future. If we don't do this, we'd
have to add module.h to obviously non-modular code, and that
would be a worse thing.
Note that direct use of __initcall is discouraged, vs. one
of the priority categorized subgroups. As __initcall gets
mapped onto device_initcall, our use of arch_initcall (which
makes sense for arch code) will thus change this registration
from level 6-device to level 3-arch (i.e. slightly earlier).
However no observable impact of that small difference has
been observed during testing, or is expected.
Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Cc: Paul Mackerras <paulus@samba.org>
Cc: linuxppc-dev@lists.ozlabs.org
Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>
---
arch/powerpc/mm/hugetlbpage.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/powerpc/mm/hugetlbpage.c b/arch/powerpc/mm/hugetlbpage.c
index 90bb6d9..d25c202 100644
--- a/arch/powerpc/mm/hugetlbpage.c
+++ b/arch/powerpc/mm/hugetlbpage.c
@@ -911,7 +911,7 @@ static int __init hugetlbpage_init(void)
return 0;
}
#endif
-module_init(hugetlbpage_init);
+arch_initcall(hugetlbpage_init);
void flush_dcache_icache_hugepage(struct page *page)
{
--
1.8.4.1
^ permalink raw reply related
* [PATCH 13/73] powerpc: use subsys_initcall for Freescale Local Bus
From: Paul Gortmaker @ 2014-01-21 21:22 UTC (permalink / raw)
To: linux-kernel
Cc: linux-arch, Paul Gortmaker, Paul Mackerras, Scott Wood,
linuxppc-dev
In-Reply-To: <1390339396-3479-1-git-send-email-paul.gortmaker@windriver.com>
The FSL_SOC option is bool, and hence this code is either
present or absent. It will never be modular, so using
module_init as an alias for __initcall is rather misleading.
Fix this up now, so that we can relocate module_init from
init.h into module.h in the future. If we don't do this, we'd
have to add module.h to obviously non-modular code, and that
would be a worse thing.
Note that direct use of __initcall is discouraged, vs. one
of the priority categorized subgroups. As __initcall gets
mapped onto device_initcall, our use of subsys_initcall (which
makes sense for bus code) will thus change this registration
from level 6-device to level 4-subsys (i.e. slightly earlier).
However no observable impact of that small difference has
been observed during testing, or is expected.
Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Cc: Paul Mackerras <paulus@samba.org>
Cc: Scott Wood <scottwood@freescale.com>
Acked-by: Scott Wood <scottwood@freescale.com>
Cc: Kumar Gala <galak@kernel.crashing.org>
Cc: linuxppc-dev@lists.ozlabs.org
Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>
---
arch/powerpc/sysdev/fsl_lbc.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/powerpc/sysdev/fsl_lbc.c b/arch/powerpc/sysdev/fsl_lbc.c
index d631022..38138cf 100644
--- a/arch/powerpc/sysdev/fsl_lbc.c
+++ b/arch/powerpc/sysdev/fsl_lbc.c
@@ -407,4 +407,4 @@ static int __init fsl_lbc_init(void)
{
return platform_driver_register(&fsl_lbc_ctrl_driver);
}
-module_init(fsl_lbc_init);
+subsys_initcall(fsl_lbc_init);
--
1.8.4.1
^ permalink raw reply related
* [PATCH 15/73] powerpc: don't use module_init in non-modular 83xx suspend code
From: Paul Gortmaker @ 2014-01-21 21:22 UTC (permalink / raw)
To: linux-kernel; +Cc: linux-arch, Paul Gortmaker, Paul Mackerras, linuxppc-dev
In-Reply-To: <1390339396-3479-1-git-send-email-paul.gortmaker@windriver.com>
The suspend.o is built for SUSPEND -- which is bool, and hence
this code is either present or absent. It will never be modular,
so using module_init as an alias for __initcall can be somewhat
misleading.
Fix this up now, so that we can relocate module_init from
init.h into module.h in the future. If we don't do this, we'd
have to add module.h to obviously non-modular code, and that
would be a worse thing.
Note that direct use of __initcall is discouraged, vs. one
of the priority categorized subgroups. As __initcall gets
mapped onto device_initcall, our use of device_initcall
directly in this change means that the runtime impact is
zero -- it will remain at level 6 in initcall ordering.
Cc: Kumar Gala <galak@kernel.crashing.org>
Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Cc: Paul Mackerras <paulus@samba.org>
Cc: linuxppc-dev@lists.ozlabs.org
Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>
---
arch/powerpc/platforms/83xx/suspend.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/arch/powerpc/platforms/83xx/suspend.c b/arch/powerpc/platforms/83xx/suspend.c
index 4b4c081..e9f07c6 100644
--- a/arch/powerpc/platforms/83xx/suspend.c
+++ b/arch/powerpc/platforms/83xx/suspend.c
@@ -446,5 +446,4 @@ static int pmc_init(void)
{
return platform_driver_register(&pmc_driver);
}
-
-module_init(pmc_init);
+device_initcall(pmc_init);
--
1.8.4.1
^ permalink raw reply related
* [PATCH RFC 00/73] tree-wide: clean up some no longer required #include <linux/init.h>
From: Paul Gortmaker @ 2014-01-21 21:22 UTC (permalink / raw)
To: linux-kernel
Cc: linux-arch, linux-mips, linux-m68k, rusty, linux-ia64, kvm,
linux-s390, netdev, x86, gregkh, Paul Gortmaker, torvalds,
linux-alpha, sparclinux, sfr, akpm, linuxppc-dev,
linux-arm-kernel
TL;DR - We removed cpuinit and devinit, which left ~2000 instances of
include <linux/init.h> that were no longer needed. To fully enable
this removal/cleanup, we relocate module_init() from init.h into
module.h. Multi arch/multi config build testing on linux-next has
been used to find and fix any implicit header dependencies prior to
deploying the actual init.h --> module.h move, to preserve bisection.
Additional details beyond TL;DR:
module_init/module_exit and friends moved to module.h
=====================================================
Aside from enabling this init.h cleanup to extend into modular files,
it actually does make sense. For all modules will use some form of
our initfunc processing/categorization, but not all initfunc users
will be necessarily using modular functionality. So we move these
module related macros to module.h and ensure module.h sources init.h
module_init in non modular code:
================================
This series uncovered that we are enabling people to use module_init
in non-modular code. While that works fine, there are at least three
reasons why it probably should not be encouraged:
1) it makes a casual reader of the code assume the code is modular
even though it is obj-y (builtin) or controlled by a bool Kconfig.
2) it makes it too easy to add dead code in a function that is handed
to module_exit() -- [more on that below]
3) it breaks our ability to use priority sorted initcalls properly
[more on that below.]
After this change, a new coder who tries to make use of module_init in
non modular code would find themselves also needing to include the
module.h header. At which point the odds are greater that they would
ask themselves "Am I doing this right? I shouldn't need this."
Note that existing non-modular code that already includes module.h and
uses module_init doesn't get fixed here, since they already build w/o
errors triggered by this change; we'll have to hunt them down later.
module_init and initcall ordering:
==================================
We have a group of about ten priority sorted initcalls, that are
called in init/main.c after most of the hard coded/direct calls
have been processed. These serve the purpose of avoiding everyone
poking at init/main.c to hook in their init sequence. The bins are:
pure_initcall 0
core_initcall 1
postcore_initcall 2
arch_initcall 3
subsys_initcall 4
fs_initcall 5
device_initcall 6
late_initcall 7
These are meant to eventually replace users of the non specific
priority "__initcall" which currently maps onto device_initcall.
This is of interest, because in non-modular code, cpp does this:
module_init --> __initcall --> device_initcall
So all module_init() land in the device_initcall bucket, rather late
in the sequence. That makes sense, since if it was a module, the init
could be real late (days, weeks after boot). But now imagine you add
support for some non-modular bus/arch/infrastructure (say for e.g. PCI)
and you use module_init for it. That means anybody else who wants
to use your subsystem can't do so if they use an initcall of 0 --> 5
priority. For a real world example of this, see patch #1 in this series:
https://lkml.org/lkml/2014/1/14/809
We don't want to force code that is clearly arch or subsys or fs
specific to have to use the device_initcall just because something
else has been mistakenly put (or left) in that bucket. So a couple of
changes do actually change the initcall level where it is inevitably
appropriate to do so. Those are called out explicitly in their
respective commit logs.
module_exit and dead code
=========================
Built in code will never have an opportunity to call functions that
are registered with module_exit(), so any cases of that uncovered in
this series delete that dead code. Note that any built-in code that
was already including module.h and using module_exit won't have shown
up as breakage on the build coverage of this series, so we'll have to
find those independently later. It looks like there may be quite a
few that are invisibly created via module_platform_driver -- a macro
that creates module_init and module_exit automatically. We may want
to consider relocating module_platform_driver into module.h later...
cpuinit
=======
To finalize the removal of cpuinit, which was done several releases
ago, we remove the remaining stub functions from init.h in this
series. We've seen one or two "users" try to creep back in, so this
will close the door on that chapter and prevent creep.
When, what and where?
=====================
When: Ideally, barring any objections or massive oversights on my
part, this will go in at or around rc1, i.e. in about 2wks. In the
meantime I will continue daily re-test on linux-next across ~10 different
arch, using allyesconfig, allmodconfig and arch specific defconfigs
for things like mips/arm/powerpc; as I have been doing for a while.
Where: This work exists as a queue of patches that I apply to
linux-next; since the changes are fixing some things that currently
can only be found there. The patch series can be found at:
http://git.kernel.org/cgit/linux/kernel/git/paulg/init.git
git://git.kernel.org/pub/scm/linux/kernel/git/paulg/init.git
The patches are not in strict chronological order, since when I've
found a header change causes a build regression that is due to an
implicit dependency/inclusion, I place the dependency fix before the
header change that caused it, so that bisection is preserved.
I've avoided annoying Stephen with another queue of patches for
linux-next while the development content was in flux, but now that
the merge window has opened, and new additions are fewer, perhaps he
wouldn't mind tacking it on the end... Stephen?
In order to reduce the size of the overall queue here, I have already
put some dependency-free changes through maintainer trees after
re-testing them on whatever their development baseline was. That made
sense for the larger ones (drivers/[net,usb,input] some arch trees...)
and for the kernel/ mm/ and fs/ ones where the changes were less
trivial and an earlier review was desired. But that independent treatment
doesn't scale for handling all the commits -- hence ~1400 of the
full ~2k of init.h removals remain here in this series.
What: The audit for removal of extra init.h lines has covered
drivers/, all of the main architectures (and some of the more fringe
ones), and core dirs like mm/ fs/ and kernel/ too. The removals from
include/ itself are probably the most valuable, in terms of reducing
the amount of stuff we needlessly feed CPP. There is probably more
fringe ones to be found, but this covers the majority of them.
Additional ones can be fed in later (through the trivial tree perhaps)
as desired.
Build coverage (from memory) has included, but is not limited to:
allyesconfig, allmodconfig:
x86, x86_64, ia64, s390, arm, mips, sparc, powerpc
arch specifc arch/<name>/config/*config files:
arm, mips, powerpc
defconfig:
(all of the above), c6x, parisc, uml, tile, c6x, blackfin, ...
and it will continue to take place for the next ~2wks, until I can
reliably apply the queue to master and submit a pull request.
Thanks for reading this far, and thanks to those who have merged init.h
cleanup commits already! Additional comments, reviews and acks welcomed.
Paul.
---
Cc: linux-alpha@vger.kernel.org
Cc: linux-arch@vger.kernel.org
Cc: linux-arm-kernel@lists.infradead.org
Cc: linux-ia64@vger.kernel.org
Cc: linux-m68k@lists.linux-m68k.org
Cc: linux-mips@linux-mips.org
Cc: linuxppc-dev@lists.ozlabs.org
Cc: linux-s390@vger.kernel.org
Cc: sparclinux@vger.kernel.org
Cc: x86@kernel.org
Cc: netdev@vger.kernel.org
Cc: kvm@vger.kernel.org
Cc: sfr@canb.auug.org.au
Cc: rusty@rustcorp.com.au
Cc: gregkh@linuxfoundation.org
Cc: akpm@linux-foundation.org
Cc: torvalds@linux-foundation.org
Paul Gortmaker (73):
init: delete the __cpuinit related stubs
mm: replace module_init usages with subsys_initcall in nommu.c
fs/notify: don't use module_init for non-modular inotify_user code
netfilter: don't use module_init/exit in core IPV4 code
x86: don't use module_init in non-modular intel_mid_vrtc.c
x86: don't use module_init for non-modular core bootflag code
x86: replace __init_or_module with __init in non-modular vsmp_64.c
drivers/tty/hvc: don't use module_init in non-modular hyp. console code
staging: don't use module_init in non-modular ion_dummy_driver.c
powerpc: use device_initcall for registering rtc devices
powerpc: book3s KVM can be modular so it should use module.h
powerpc: kvm e500/44x is not modular, so don't use module_init
powerpc: use subsys_initcall for Freescale Local Bus
powerpc: don't use module_init for non-modular core hugetlb code
powerpc: don't use module_init in non-modular 83xx suspend code
arm: include module.h in drivers/bus/omap_l3_smx.c
arm: fix implicit module.h use in mach-at91 gpio.h
arm: fix implicit #include <linux/init.h> in entry asm.
arm: mach-s3c64xx mach-crag6410-module.c is not modular
arm: use subsys_initcall in non-modular pl320 IPC code
arm: don't use module_init in non-modular mach-vexpress/spc.c code
alpha: don't use module_init for non-modular core code
sparc: don't use module_init in non-modular pci.c code
m68k: don't use module_init in non-modular mvme16x/rtc.c code
ia64: don't use module_init for non-modular core kernel/mca.c code
ia64: don't use module_init in non-modular sim/simscsi.c code
drivers/clk: don't use module_init in clk-nomadik.c which is non-modular
cpuidle: don't use modular platform register in non-modular ARM drivers
drivers/platform: don't use modular register in non-modular pdev_bus.c
drivers/i2c: busses/i2c-acorn.c is tristate and should use module.h
module: relocate module_init from init.h to module.h
logo: emit "#include <linux/init.h> in autogenerated C file
arm: delete non-required instances of include <linux/init.h>
mips: delete non-required instances of include <linux/init.h>
sparc: delete non-required instances of include <linux/init.h>
s390: delete non-required instances of include <linux/init.h>
alpha: delete non-required instances of <linux/init.h>
blackfin: delete non-required instances of <linux/init.h>
powerpc: delete another unrequired instance of <linux/init.h>
watchdog: delete non-required instances of include <linux/init.h>
video: delete non-required instances of include <linux/init.h>
rtc: delete non-required instances of include <linux/init.h>
scsi: delete non-required instances of include <linux/init.h>
spi: delete non-required instances of include <linux/init.h>
acpi: delete non-required instances of include <linux/init.h>
drivers/power: delete non-required instances of include <linux/init.h>
drivers/media: delete non-required instances of include <linux/init.h>
drivers/ata: delete non-required instances of include <linux/init.h>
drivers/mtd: delete non-required instances of include <linux/init.h>
drivers/hwmon: delete non-required instances of include <linux/init.h>
drivers/i2c: delete non-required instances of include <linux/init.h>
drivers/pinctrl: delete non-required instances of include <linux/init.h>
drivers/isdn: delete non-required instances of include <linux/init.h>
drivers/leds: delete non-required instances of include <linux/init.h>
drivers/pcmcia: delete non-required instances of include <linux/init.h>
drivers/char: delete non-required instances of include <linux/init.h>
drivers/infiniband: delete non-required instances of include <linux/init.h>
drivers/mfd: delete non-required instances of include <linux/init.h>
drivers/gpio: delete non-required instances of include <linux/init.h>
drivers/bluetooth: delete non-required instances of include <linux/init.h>
drivers/mmc: delete non-required instances of include <linux/init.h>
drivers/crypto: delete non-required instances of include <linux/init.h>
drivers/platform: delete non-required instances of include <linux/init.h>
drivers/misc: delete non-required instances of include <linux/init.h>
drivers/edac: delete non-required instances of include <linux/init.h>
drivers/macintosh: delete non-required instances of include <linux/init.h>
drivers/base: delete non-required instances of include <linux/init.h>
drivers/cpufreq: delete non-required instances of <linux/init.h>
drivers/pci: delete non-required instances of <linux/init.h>
drivers/dma: delete non-required instances of <linux/init.h>
drivers/gpu: delete non-required instances of <linux/init.h>
drivers: delete remaining non-required instances of <linux/init.h>
include: remove needless instances of <linux/init.h>
arch/alpha/kernel/err_ev6.c | 1 -
arch/alpha/kernel/irq.c | 1 -
arch/alpha/kernel/srmcons.c | 3 +-
arch/alpha/kernel/traps.c | 1 -
arch/alpha/oprofile/op_model_ev4.c | 1 -
arch/alpha/oprofile/op_model_ev5.c | 1 -
arch/alpha/oprofile/op_model_ev6.c | 1 -
arch/alpha/oprofile/op_model_ev67.c | 1 -
arch/arm/common/dmabounce.c | 1 -
arch/arm/firmware/trusted_foundations.c | 1 -
arch/arm/include/asm/arch_timer.h | 1 -
arch/arm/kernel/entry-armv.S | 2 +
arch/arm/kernel/entry-header.S | 1 -
arch/arm/kernel/hyp-stub.S | 1 -
arch/arm/kernel/suspend.c | 1 -
arch/arm/kernel/unwind.c | 1 -
arch/arm/mach-at91/include/mach/gpio.h | 1 +
arch/arm/mach-cns3xxx/pm.c | 1 -
arch/arm/mach-exynos/headsmp.S | 1 -
arch/arm/mach-footbridge/personal.c | 1 -
arch/arm/mach-imx/headsmp.S | 1 -
arch/arm/mach-imx/iomux-v3.c | 1 -
[.... snip ~1300 lines ...]
drivers/watchdog/stmp3xxx_rtc_wdt.c | 1 -
drivers/watchdog/wdt_pci.c | 1 -
drivers/xen/xen-stub.c | 1 -
fs/notify/inotify/inotify_user.c | 4 +-
include/drm/drmP.h | 2 +-
include/linux/fb.h | 1 -
include/linux/ide.h | 1 -
include/linux/init.h | 77 ----------------------
include/linux/kdb.h | 1 -
include/linux/linux_logo.h | 3 -
include/linux/lsm_audit.h | 1 -
include/linux/module.h | 72 ++++++++++++++++++++
include/linux/moduleparam.h | 1 -
include/linux/netfilter.h | 1 -
include/linux/nls.h | 2 +-
include/linux/percpu_ida.h | 1 -
include/linux/profile.h | 1 -
include/linux/pstore_ram.h | 1 -
include/linux/usb/gadget.h | 1 -
include/linux/zorro.h | 1 -
include/xen/xenbus.h | 1 -
mm/nommu.c | 4 +-
net/ipv4/netfilter.c | 9 +--
scripts/pnmtologo.c | 1 +
scripts/tags.sh | 2 +-
1254 files changed, 131 insertions(+), 1431 deletions(-)
mode change 100755 => 100644 scripts/tags.sh
--
1.8.4.1
^ permalink raw reply
* [PATCH 39/73] powerpc: delete another unrequired instance of <linux/init.h>
From: Paul Gortmaker @ 2014-01-21 21:22 UTC (permalink / raw)
To: linux-kernel; +Cc: linux-arch, Paul Gortmaker, Paul Mackerras, linuxppc-dev
In-Reply-To: <1390339396-3479-1-git-send-email-paul.gortmaker@windriver.com>
Most were already deleted in the 1st pass audit; this instance
showed up more recently.
Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Cc: Paul Mackerras <paulus@samba.org>
Cc: linuxppc-dev@lists.ozlabs.org
Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>
---
arch/powerpc/sysdev/indirect_pci.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/arch/powerpc/sysdev/indirect_pci.c b/arch/powerpc/sysdev/indirect_pci.c
index 1f6c570..66f5fd1 100644
--- a/arch/powerpc/sysdev/indirect_pci.c
+++ b/arch/powerpc/sysdev/indirect_pci.c
@@ -13,7 +13,6 @@
#include <linux/pci.h>
#include <linux/delay.h>
#include <linux/string.h>
-#include <linux/init.h>
#include <asm/io.h>
#include <asm/prom.h>
--
1.8.4.1
^ permalink raw reply related
* [PATCH 66/73] drivers/macintosh: delete non-required instances of include <linux/init.h>
From: Paul Gortmaker @ 2014-01-21 21:23 UTC (permalink / raw)
To: linux-kernel; +Cc: linux-arch, Paul Gortmaker, linuxppc-dev
In-Reply-To: <1390339396-3479-1-git-send-email-paul.gortmaker@windriver.com>
None of these files are actually using any __init type directives
and hence don't need to include <linux/init.h>. Most are just a
left over from __devinit and __cpuinit removal, or simply due to
code getting copied from one driver to the next.
Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Cc: linuxppc-dev@lists.ozlabs.org
Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>
---
drivers/macintosh/adb-iop.c | 1 -
drivers/macintosh/ams/ams-input.c | 1 -
drivers/macintosh/macio-adb.c | 1 -
drivers/macintosh/via-macii.c | 1 -
drivers/macintosh/via-pmu68k.c | 1 -
drivers/macintosh/windfarm_ad7417_sensor.c | 1 -
drivers/macintosh/windfarm_fcu_controls.c | 1 -
drivers/macintosh/windfarm_lm75_sensor.c | 1 -
drivers/macintosh/windfarm_max6690_sensor.c | 1 -
drivers/macintosh/windfarm_smu_sat.c | 1 -
10 files changed, 10 deletions(-)
diff --git a/drivers/macintosh/adb-iop.c b/drivers/macintosh/adb-iop.c
index f5f4da3..2c242f7 100644
--- a/drivers/macintosh/adb-iop.c
+++ b/drivers/macintosh/adb-iop.c
@@ -16,7 +16,6 @@
#include <linux/kernel.h>
#include <linux/mm.h>
#include <linux/delay.h>
-#include <linux/init.h>
#include <linux/proc_fs.h>
#include <asm/macintosh.h>
diff --git a/drivers/macintosh/ams/ams-input.c b/drivers/macintosh/ams/ams-input.c
index 2edae7d..b1bdd48 100644
--- a/drivers/macintosh/ams/ams-input.c
+++ b/drivers/macintosh/ams/ams-input.c
@@ -14,7 +14,6 @@
#include <linux/types.h>
#include <linux/errno.h>
-#include <linux/init.h>
#include <linux/delay.h>
#include "ams.h"
diff --git a/drivers/macintosh/macio-adb.c b/drivers/macintosh/macio-adb.c
index 87de8d9..c8fcac0 100644
--- a/drivers/macintosh/macio-adb.c
+++ b/drivers/macintosh/macio-adb.c
@@ -14,7 +14,6 @@
#include <asm/pgtable.h>
#include <asm/hydra.h>
#include <asm/irq.h>
-#include <linux/init.h>
#include <linux/ioport.h>
struct preg {
diff --git a/drivers/macintosh/via-macii.c b/drivers/macintosh/via-macii.c
index 3725f08..fd27da3 100644
--- a/drivers/macintosh/via-macii.c
+++ b/drivers/macintosh/via-macii.c
@@ -30,7 +30,6 @@
#include <linux/delay.h>
#include <linux/adb.h>
#include <linux/interrupt.h>
-#include <linux/init.h>
#include <asm/macintosh.h>
#include <asm/macints.h>
#include <asm/mac_via.h>
diff --git a/drivers/macintosh/via-pmu68k.c b/drivers/macintosh/via-pmu68k.c
index a00ee41..d2e252e 100644
--- a/drivers/macintosh/via-pmu68k.c
+++ b/drivers/macintosh/via-pmu68k.c
@@ -25,7 +25,6 @@
#include <linux/miscdevice.h>
#include <linux/blkdev.h>
#include <linux/pci.h>
-#include <linux/init.h>
#include <linux/interrupt.h>
#include <linux/adb.h>
diff --git a/drivers/macintosh/windfarm_ad7417_sensor.c b/drivers/macintosh/windfarm_ad7417_sensor.c
index 7c28b71..76715a7 100644
--- a/drivers/macintosh/windfarm_ad7417_sensor.c
+++ b/drivers/macintosh/windfarm_ad7417_sensor.c
@@ -11,7 +11,6 @@
#include <linux/kernel.h>
#include <linux/delay.h>
#include <linux/slab.h>
-#include <linux/init.h>
#include <linux/wait.h>
#include <linux/i2c.h>
#include <asm/prom.h>
diff --git a/drivers/macintosh/windfarm_fcu_controls.c b/drivers/macintosh/windfarm_fcu_controls.c
index 0226b79..50ba619 100644
--- a/drivers/macintosh/windfarm_fcu_controls.c
+++ b/drivers/macintosh/windfarm_fcu_controls.c
@@ -12,7 +12,6 @@
#include <linux/kernel.h>
#include <linux/delay.h>
#include <linux/slab.h>
-#include <linux/init.h>
#include <linux/wait.h>
#include <linux/i2c.h>
#include <asm/prom.h>
diff --git a/drivers/macintosh/windfarm_lm75_sensor.c b/drivers/macintosh/windfarm_lm75_sensor.c
index 590214b..704dd2e 100644
--- a/drivers/macintosh/windfarm_lm75_sensor.c
+++ b/drivers/macintosh/windfarm_lm75_sensor.c
@@ -12,7 +12,6 @@
#include <linux/kernel.h>
#include <linux/delay.h>
#include <linux/slab.h>
-#include <linux/init.h>
#include <linux/wait.h>
#include <linux/i2c.h>
#include <asm/prom.h>
diff --git a/drivers/macintosh/windfarm_max6690_sensor.c b/drivers/macintosh/windfarm_max6690_sensor.c
index 87e439b..a3504d3 100644
--- a/drivers/macintosh/windfarm_max6690_sensor.c
+++ b/drivers/macintosh/windfarm_max6690_sensor.c
@@ -8,7 +8,6 @@
#include <linux/types.h>
#include <linux/errno.h>
#include <linux/kernel.h>
-#include <linux/init.h>
#include <linux/slab.h>
#include <linux/i2c.h>
#include <asm/prom.h>
diff --git a/drivers/macintosh/windfarm_smu_sat.c b/drivers/macintosh/windfarm_smu_sat.c
index ad6223e..b6d70d2 100644
--- a/drivers/macintosh/windfarm_smu_sat.c
+++ b/drivers/macintosh/windfarm_smu_sat.c
@@ -10,7 +10,6 @@
#include <linux/errno.h>
#include <linux/kernel.h>
#include <linux/slab.h>
-#include <linux/init.h>
#include <linux/wait.h>
#include <linux/i2c.h>
#include <linux/mutex.h>
--
1.8.4.1
^ permalink raw reply related
* [PATCH 10/73] powerpc: use device_initcall for registering rtc devices
From: Paul Gortmaker @ 2014-01-21 21:22 UTC (permalink / raw)
To: linux-kernel
Cc: linux-arch, Geoff Levand, Paul Gortmaker, Paul Mackerras,
linuxppc-dev
In-Reply-To: <1390339396-3479-1-git-send-email-paul.gortmaker@windriver.com>
Currently these two RTC devices are in core platform code
where it is not possible for them to be modular. It will
never be modular, so using module_init as an alias for
__initcall can be somewhat misleading.
Fix this up now, so that we can relocate module_init from
init.h into module.h in the future. If we don't do this, we'd
have to add module.h to obviously non-modular code, and that
would be a worse thing.
Note that direct use of __initcall is discouraged, vs. one
of the priority categorized subgroups. As __initcall gets
mapped onto device_initcall, our use of device_initcall
directly in this change means that the runtime impact is
zero -- they will remain at level 6 in initcall ordering.
Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Cc: Paul Mackerras <paulus@samba.org>
Cc: Geoff Levand <geoff@infradead.org>
Cc: linuxppc-dev@lists.ozlabs.org
Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>
---
arch/powerpc/kernel/time.c | 2 +-
arch/powerpc/platforms/ps3/time.c | 3 +--
2 files changed, 2 insertions(+), 3 deletions(-)
diff --git a/arch/powerpc/kernel/time.c b/arch/powerpc/kernel/time.c
index b3dab20..63b34fc 100644
--- a/arch/powerpc/kernel/time.c
+++ b/arch/powerpc/kernel/time.c
@@ -1064,4 +1064,4 @@ static int __init rtc_init(void)
return PTR_ERR_OR_ZERO(pdev);
}
-module_init(rtc_init);
+device_initcall(rtc_init);
diff --git a/arch/powerpc/platforms/ps3/time.c b/arch/powerpc/platforms/ps3/time.c
index ce73ce8..791c614 100644
--- a/arch/powerpc/platforms/ps3/time.c
+++ b/arch/powerpc/platforms/ps3/time.c
@@ -92,5 +92,4 @@ static int __init ps3_rtc_init(void)
return PTR_ERR_OR_ZERO(pdev);
}
-
-module_init(ps3_rtc_init);
+device_initcall(ps3_rtc_init);
--
1.8.4.1
^ permalink raw reply related
* [PATCH] powerpc: Fix endian issues in kexec and crash dump code
From: Anton Blanchard @ 2014-01-21 21:40 UTC (permalink / raw)
To: benh, paulus; +Cc: linuxppc-dev
We expose a number of OF properties in the kexec and crash dump code
and these need to be big endian.
Cc: stable@vger.kernel.org # v3.13
Signed-off-by: Anton Blanchard <anton@samba.org>
--
diff --git a/arch/powerpc/kernel/machine_kexec.c b/arch/powerpc/kernel/machine_kexec.c
index 75d4f73..015ae55 100644
--- a/arch/powerpc/kernel/machine_kexec.c
+++ b/arch/powerpc/kernel/machine_kexec.c
@@ -196,7 +196,9 @@ int overlaps_crashkernel(unsigned long start, unsigned long size)
/* Values we need to export to the second kernel via the device tree. */
static phys_addr_t kernel_end;
+static phys_addr_t crashk_base;
static phys_addr_t crashk_size;
+static unsigned long long mem_limit;
static struct property kernel_end_prop = {
.name = "linux,kernel-end",
@@ -207,7 +209,7 @@ static struct property kernel_end_prop = {
static struct property crashk_base_prop = {
.name = "linux,crashkernel-base",
.length = sizeof(phys_addr_t),
- .value = &crashk_res.start,
+ .value = &crashk_base
};
static struct property crashk_size_prop = {
@@ -219,9 +221,11 @@ static struct property crashk_size_prop = {
static struct property memory_limit_prop = {
.name = "linux,memory-limit",
.length = sizeof(unsigned long long),
- .value = &memory_limit,
+ .value = &mem_limit,
};
+#define cpu_to_be_ulong __PASTE(cpu_to_be, BITS_PER_LONG)
+
static void __init export_crashk_values(struct device_node *node)
{
struct property *prop;
@@ -237,8 +241,9 @@ static void __init export_crashk_values(struct device_node *node)
of_remove_property(node, prop);
if (crashk_res.start != 0) {
+ crashk_base = cpu_to_be_ulong(crashk_res.start),
of_add_property(node, &crashk_base_prop);
- crashk_size = resource_size(&crashk_res);
+ crashk_size = cpu_to_be_ulong(resource_size(&crashk_res));
of_add_property(node, &crashk_size_prop);
}
@@ -246,6 +251,7 @@ static void __init export_crashk_values(struct device_node *node)
* memory_limit is required by the kexec-tools to limit the
* crash regions to the actual memory used.
*/
+ mem_limit = cpu_to_be_ulong(memory_limit);
of_update_property(node, &memory_limit_prop);
}
@@ -264,7 +270,7 @@ static int __init kexec_setup(void)
of_remove_property(node, prop);
/* information needed by userspace when using default_machine_kexec */
- kernel_end = __pa(_end);
+ kernel_end = cpu_to_be_ulong(__pa(_end));
of_add_property(node, &kernel_end_prop);
export_crashk_values(node);
diff --git a/arch/powerpc/kernel/machine_kexec_64.c b/arch/powerpc/kernel/machine_kexec_64.c
index be4e6d6..59d229a 100644
--- a/arch/powerpc/kernel/machine_kexec_64.c
+++ b/arch/powerpc/kernel/machine_kexec_64.c
@@ -369,6 +369,7 @@ void default_machine_kexec(struct kimage *image)
/* Values we need to export to the second kernel via the device tree. */
static unsigned long htab_base;
+static unsigned long htab_size;
static struct property htab_base_prop = {
.name = "linux,htab-base",
@@ -379,7 +380,7 @@ static struct property htab_base_prop = {
static struct property htab_size_prop = {
.name = "linux,htab-size",
.length = sizeof(unsigned long),
- .value = &htab_size_bytes,
+ .value = &htab_size,
};
static int __init export_htab_values(void)
@@ -403,8 +404,9 @@ static int __init export_htab_values(void)
if (prop)
of_remove_property(node, prop);
- htab_base = __pa(htab_address);
+ htab_base = cpu_to_be64(__pa(htab_address));
of_add_property(node, &htab_base_prop);
+ htab_size = cpu_to_be64(htab_size_bytes);
of_add_property(node, &htab_size_prop);
of_node_put(node);
^ permalink raw reply related
* Re: [PATCH] powerpc: set the correct ksp_limit on ppc32 when switching to irq stack
From: Benjamin Herrenschmidt @ 2014-01-21 21:48 UTC (permalink / raw)
To: Guenter Roeck; +Cc: linuxppc, Kevin Hao
In-Reply-To: <20140121161450.GA3311@roeck-us.net>
On Tue, 2014-01-21 at 08:14 -0800, Guenter Roeck wrote:
> On Fri, Jan 17, 2014 at 12:25:28PM +0800, Kevin Hao wrote:
> > Guenter Roeck has got the following call trace on a p2020 board:
> > Kernel stack overflow in process eb3e5a00, r1=eb79df90
> > CPU: 0 PID: 2838 Comm: ssh Not tainted 3.13.0-rc8-juniper-00146-g19eca00 #4
> > task: eb3e5a00 ti: c0616000 task.ti: ef440000
> > NIP: c003a420 LR: c003a410 CTR: c0017518
> > REGS: eb79dee0 TRAP: 0901 Not tainted (3.13.0-rc8-juniper-00146-g19eca00)
> > MSR: 00029000 <CE,EE,ME> CR: 24008444 XER: 00000000
> > GPR00: c003a410 eb79df90 eb3e5a00 00000000 eb05d900 00000001 65d87646 00000000
> > GPR08: 00000000 020b8000 00000000 00000000 44008442
> > NIP [c003a420] __do_softirq+0x94/0x1ec
> > LR [c003a410] __do_softirq+0x84/0x1ec
> > Call Trace:
> > [eb79df90] [c003a410] __do_softirq+0x84/0x1ec (unreliable)
> > [eb79dfe0] [c003a970] irq_exit+0xbc/0xc8
> > [eb79dff0] [c000cc1c] call_do_irq+0x24/0x3c
> > [ef441f20] [c00046a8] do_IRQ+0x8c/0xf8
> > [ef441f40] [c000e7f4] ret_from_except+0x0/0x18
> > --- Exception: 501 at 0xfcda524
> > LR = 0x10024900
> > Instruction dump:
> > 7c781b78 3b40000a 3a73b040 543c0024 3a800000 3b3913a0 7ef5bb78 48201bf9
> > 5463103a 7d3b182e 7e89b92e 7c008146 <3ba00000> 7e7e9b78 48000014 57fff87f
> > Kernel panic - not syncing: kernel stack overflow
> > CPU: 0 PID: 2838 Comm: ssh Not tainted 3.13.0-rc8-juniper-00146-g19eca00 #4
> > Call Trace:
> >
> > The reason is that we have used the wrong register to calculate the
> > ksp_limit in commit cbc9565ee826 (powerpc: Remove ksp_limit on ppc64).
> > Just fix it.
> >
> > As suggested by Benjamin Herrenschmidt, also add the C prototype of the
> > function in the comment in order to avoid such kind of errors in the
> > future.
> >
> Was this patch accepted, or are there any problems with it ?
> I didn't see any comments, and it still isn't upstream nor in linux-next.
It will be merged when I come back from vacation. It was too late for
3.13 so I'll send it to Linus next week and will CC -stable.
Cheers,
Ben.
^ permalink raw reply
* Re: [PATCH 12/73] powerpc: kvm e500/44x is not modular, so don't use module_init
From: Paul Gortmaker @ 2014-01-21 22:23 UTC (permalink / raw)
To: linux-kernel
Cc: linux-arch, kvm, Gleb Natapov, Alexander Graf, kvm-ppc,
Paul Gortmaker, Paul Mackerras, Paolo Bonzini, linuxppc-dev
In-Reply-To: <1390339396-3479-13-git-send-email-paul.gortmaker@windriver.com>
On 14-01-21 04:22 PM, Paul Gortmaker wrote:
> In powerpc, CONFIG_KVM is bool, and so are these three subarch
> options, for the 44x and e500 variants. This means that any
> module_exit() calls and functions used by them such as the
> kvmppc_booke_exit() are dead code. Here we remove them.
>
> In addition, rather than use module_init, which is just
> __initcall for non-modules, we update those as well.
>
> Note that direct use of __initcall is discouraged, vs. one
> of the priority categorized subgroups. As __initcall gets
> mapped onto device_initcall, our use of subsys_initcall (which
> seems to make sense for netfilter code) will thus change this
I've fixed the above -- s/netfilter/PPC KVM/
The risks of recycling commit logs...
Paul.
--
> registration from level 6-device to level 4-subsys (i.e. slightly
> earlier).
>
> However no impact of that small difference is expected,
> since the arch independent kvm code doesn't trigger any init;
> it is the arch initcalls here which actually call kvm_init.
>
> Cc: Gleb Natapov <gleb@kernel.org>
> Cc: Paolo Bonzini <pbonzini@redhat.com>
> Cc: Alexander Graf <agraf@suse.de>
> Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
> Cc: Paul Mackerras <paulus@samba.org>
> Cc: kvm@vger.kernel.org
> Cc: kvm-ppc@vger.kernel.org
> Cc: linuxppc-dev@lists.ozlabs.org
> Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>
> ---
> arch/powerpc/include/asm/kvm_ppc.h | 1 -
> arch/powerpc/kvm/44x.c | 10 +---------
> arch/powerpc/kvm/booke.c | 6 ------
> arch/powerpc/kvm/e500.c | 10 +---------
> arch/powerpc/kvm/e500mc.c | 10 +---------
> 5 files changed, 3 insertions(+), 34 deletions(-)
>
> diff --git a/arch/powerpc/include/asm/kvm_ppc.h b/arch/powerpc/include/asm/kvm_ppc.h
> index c8317fb..8466df5 100644
> --- a/arch/powerpc/include/asm/kvm_ppc.h
> +++ b/arch/powerpc/include/asm/kvm_ppc.h
> @@ -109,7 +109,6 @@ extern void kvmppc_core_flush_tlb(struct kvm_vcpu *vcpu);
> extern int kvmppc_core_check_requests(struct kvm_vcpu *vcpu);
>
> extern int kvmppc_booke_init(void);
> -extern void kvmppc_booke_exit(void);
>
> extern void kvmppc_core_destroy_mmu(struct kvm_vcpu *vcpu);
> extern int kvmppc_kvm_pv(struct kvm_vcpu *vcpu);
> diff --git a/arch/powerpc/kvm/44x.c b/arch/powerpc/kvm/44x.c
> index 93221e8..2129fc1 100644
> --- a/arch/powerpc/kvm/44x.c
> +++ b/arch/powerpc/kvm/44x.c
> @@ -222,12 +222,4 @@ static int __init kvmppc_44x_init(void)
> err_out:
> return r;
> }
> -
> -static void __exit kvmppc_44x_exit(void)
> -{
> - kvmppc_pr_ops = NULL;
> - kvmppc_booke_exit();
> -}
> -
> -module_init(kvmppc_44x_init);
> -module_exit(kvmppc_44x_exit);
> +subsys_initcall(kvmppc_44x_init);
> diff --git a/arch/powerpc/kvm/booke.c b/arch/powerpc/kvm/booke.c
> index 0591e05..49dffa2 100644
> --- a/arch/powerpc/kvm/booke.c
> +++ b/arch/powerpc/kvm/booke.c
> @@ -1995,9 +1995,3 @@ int __init kvmppc_booke_init(void)
> #endif /* !BOOKE_HV */
> return 0;
> }
> -
> -void __exit kvmppc_booke_exit(void)
> -{
> - free_pages(kvmppc_booke_handlers, VCPU_SIZE_ORDER);
> - kvm_exit();
> -}
> diff --git a/arch/powerpc/kvm/e500.c b/arch/powerpc/kvm/e500.c
> index 497b142..115ef12 100644
> --- a/arch/powerpc/kvm/e500.c
> +++ b/arch/powerpc/kvm/e500.c
> @@ -564,12 +564,4 @@ static int __init kvmppc_e500_init(void)
> err_out:
> return r;
> }
> -
> -static void __exit kvmppc_e500_exit(void)
> -{
> - kvmppc_pr_ops = NULL;
> - kvmppc_booke_exit();
> -}
> -
> -module_init(kvmppc_e500_init);
> -module_exit(kvmppc_e500_exit);
> +subsys_initcall(kvmppc_e500_init);
> diff --git a/arch/powerpc/kvm/e500mc.c b/arch/powerpc/kvm/e500mc.c
> index 4132cd2..612c216 100644
> --- a/arch/powerpc/kvm/e500mc.c
> +++ b/arch/powerpc/kvm/e500mc.c
> @@ -382,12 +382,4 @@ static int __init kvmppc_e500mc_init(void)
> err_out:
> return r;
> }
> -
> -static void __exit kvmppc_e500mc_exit(void)
> -{
> - kvmppc_pr_ops = NULL;
> - kvmppc_booke_exit();
> -}
> -
> -module_init(kvmppc_e500mc_init);
> -module_exit(kvmppc_e500mc_exit);
> +subsys_initcall(kvmppc_e500mc_init);
>
^ 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