Re: [PATCH] ARM: reinsert ARCH_MULTI_V4 Kconfig option
On 9 April 2014 18:01, Russell King - ARM Linux wrote: > It would be useful to see the register state from the undefined > instruction exception. That needs this patch, CONFIG_DEBUG_USER in the > kernel config enabled, and user_debug=1 passed on the kernel command > line. I have done two tests, one with user_debug=1, and one with user_debug=31, since I expected more information on user_debug=1. As Arnd pointed out, this is booting into a non-thumb userspace, built with gcc version 4.9.0 20140316 and buildroot 2014.02. Buildroot config: https://code.google.com/p/mkrom-uc7112lx/source/browse/configs/buildroot-2014-02_eglibc-2.17_binutils-2.22_external-toolchain.config Results: user_debug=1 ( https://bitbucket.org/Kasreyn/linux-next/commits/3a32b929d7a399751c6397f0c973b356c6c9a71d ): Uncompressing Linux... done, booting the kernel. [0.00] Booting Linux on physical CPU 0x0 [0.00] Linux version 3.14.0-next-20140409+ (i@Ildjarn) (gcc version 4.9.0 20140316 (experimental) (crosstool-NG 1.19.0) ) #2431 PREEMPT Thu Apr 10 09:12:35 CEST 2014 .. [0.00] Kernel command line: console=ttyS0,115200n8 earlyprintk root=/dev/mmcblk0p1 rw rootwait debug user_debug=1 .. [2.70] Freeing unused kernel memory: 104K (c02f4000 - c030e000) [3.38] Kernel panic - not syncing: Attempted to kill init! exitcode=0x000b [3.38] [3.38] CPU: 0 PID: 1 Comm: init Not tainted 3.14.0-next-20140409+ #2431 [3.38] [] (unwind_backtrace) from [] (show_stack+0x10/0x14) [3.38] [] (show_stack) from [] (panic+0x98/0x1f4) [3.38] [] (panic) from [] (do_exit+0x908/0x938) [3.38] [] (do_exit) from [] (do_group_exit+0x4c/0xe8) [3.38] [] (do_group_exit) from [] (get_signal_to_deliver+0x218/0x5f0) [3.38] [] (get_signal_to_deliver) from [] (do_signal+0x100/0x48c) [3.38] [] (do_signal) from [] (do_work_pending+0xd4/0xe4) [3.38] [] (do_work_pending) from [] (work_pending+0xc/0x20) [3.38] Rebooting in 10 seconds.. user_debug=31 ( https://bitbucket.org/Kasreyn/linux-next/commits/8ed2db951baca29c6254de328765873fe5457727 ): [0.00] Booting Linux on physical CPU 0x0 [0.00] Linux version 3.14.0-next-20140409+ (i@Ildjarn) (gcc version 4.9.0 20140316 (experimental) (crosstool-NG 1.19.0) ) #2431 PREEMPT Thu Apr 10 09:12:35 CEST 2014 [0.00] CPU: FA526 [66015261] revision 1 (ARMv4), cr=397f [0.00] CPU: VIVT data cache, VIVT instruction cache [0.00] Machine model: MOXA UC-7112-LX [0.00] bootconsole [earlycon0] enabled [0.00] Memory policy: Data cache writeback [0.00] On node 0 totalpages: 8192 [0.00] free_area_init_node: node 0, pgdat c0322324, node_mem_map c1fba000 [0.00] Normal zone: 64 pages used for memmap [0.00] Normal zone: 0 pages reserved [0.00] Normal zone: 8192 pages, LIFO batch:0 [0.00] pcpu-alloc: s0 r0 d32768 u32768 alloc=1*32768 [0.00] pcpu-alloc: [0] 0 [0.00] Built 1 zonelists in Zone order, mobility grouping on. Total pages: 8128 [0.00] Kernel command line: console=ttyS0,115200n8 earlyprintk root=/dev/mmcblk0p1 rw rootwait debug user_debug=31 [0.00] PID hash table entries: 128 (order: -3, 512 bytes) [0.00] Dentry cache hash table entries: 4096 (order: 2, 16384 bytes) [0.00] Inode-cache hash table entries: 2048 (order: 1, 8192 bytes) [0.00] Memory: 29092K/32768K available (2542K kernel code, 74K rwdata, 448K rodata, 104K init, 116K bss, 3676K reserved) [0.00] Virtual kernel memory layout: [0.00] vector : 0x - 0x1000 ( 4 kB) [0.00] fixmap : 0xfff0 - 0xfffe ( 896 kB) [0.00] vmalloc : 0xc280 - 0xff00 ( 968 MB) [0.00] lowmem : 0xc000 - 0xc200 ( 32 MB) [0.00] .text : 0xc0008000 - 0xc02f3d80 (2992 kB) [0.00] .init : 0xc02f4000 - 0xc030e36c ( 105 kB) [0.00] .data : 0xc031 - 0xc0322aa0 ( 75 kB) [0.00].bss : 0xc0322aac - 0xc033fbc0 ( 117 kB) [0.00] SLUB: HWalign=32, Order=0-3, MinObjects=0, CPUs=1, Nodes=1 [0.00] Preemptible hierarchical RCU implementation. [0.00] NR_IRQS:16 nr_irqs:16 16 [0.00] sched_clock: 32 bits at 100 Hz, resolution 1000ns, wraps every 2147483648000ns [0.01] Calibrating delay loop... 146.84 BogoMIPS (lpj=734208) [0.10] pid_max: default: 4096 minimum: 301 [0.10] Mount-cache hash table entries: 1024 (order: 0, 4096 bytes) [0.11] Mountpoint-cache hash table entries: 1024 (order: 0, 4096 bytes) [0.12] CPU: Testing write buffer coherency: ok [0.13] Setting up static
Re: [PATCH] ARM: reinsert ARCH_MULTI_V4 Kconfig option
On 9 April 2014 18:01, Russell King - ARM Linux li...@arm.linux.org.uk wrote: It would be useful to see the register state from the undefined instruction exception. That needs this patch, CONFIG_DEBUG_USER in the kernel config enabled, and user_debug=1 passed on the kernel command line. I have done two tests, one with user_debug=1, and one with user_debug=31, since I expected more information on user_debug=1. As Arnd pointed out, this is booting into a non-thumb userspace, built with gcc version 4.9.0 20140316 and buildroot 2014.02. Buildroot config: https://code.google.com/p/mkrom-uc7112lx/source/browse/configs/buildroot-2014-02_eglibc-2.17_binutils-2.22_external-toolchain.config Results: user_debug=1 ( https://bitbucket.org/Kasreyn/linux-next/commits/3a32b929d7a399751c6397f0c973b356c6c9a71d ): Uncompressing Linux... done, booting the kernel. [0.00] Booting Linux on physical CPU 0x0 [0.00] Linux version 3.14.0-next-20140409+ (i@Ildjarn) (gcc version 4.9.0 20140316 (experimental) (crosstool-NG 1.19.0) ) #2431 PREEMPT Thu Apr 10 09:12:35 CEST 2014 .. [0.00] Kernel command line: console=ttyS0,115200n8 earlyprintk root=/dev/mmcblk0p1 rw rootwait debug user_debug=1 .. [2.70] Freeing unused kernel memory: 104K (c02f4000 - c030e000) [3.38] Kernel panic - not syncing: Attempted to kill init! exitcode=0x000b [3.38] [3.38] CPU: 0 PID: 1 Comm: init Not tainted 3.14.0-next-20140409+ #2431 [3.38] [c000d4e0] (unwind_backtrace) from [c000bcbc] (show_stack+0x10/0x14) [3.38] [c000bcbc] (show_stack) from [c0268f74] (panic+0x98/0x1f4) [3.38] [c0268f74] (panic) from [c0016bcc] (do_exit+0x908/0x938) [3.38] [c0016bcc] (do_exit) from [c0016c70] (do_group_exit+0x4c/0xe8) [3.38] [c0016c70] (do_group_exit) from [c0022098] (get_signal_to_deliver+0x218/0x5f0) [3.38] [c0022098] (get_signal_to_deliver) from [c000b358] (do_signal+0x100/0x48c) [3.38] [c000b358] (do_signal) from [c000b8ac] (do_work_pending+0xd4/0xe4) [3.38] [c000b8ac] (do_work_pending) from [c000933c] (work_pending+0xc/0x20) [3.38] Rebooting in 10 seconds.. user_debug=31 ( https://bitbucket.org/Kasreyn/linux-next/commits/8ed2db951baca29c6254de328765873fe5457727 ): [0.00] Booting Linux on physical CPU 0x0 [0.00] Linux version 3.14.0-next-20140409+ (i@Ildjarn) (gcc version 4.9.0 20140316 (experimental) (crosstool-NG 1.19.0) ) #2431 PREEMPT Thu Apr 10 09:12:35 CEST 2014 [0.00] CPU: FA526 [66015261] revision 1 (ARMv4), cr=397f [0.00] CPU: VIVT data cache, VIVT instruction cache [0.00] Machine model: MOXA UC-7112-LX [0.00] bootconsole [earlycon0] enabled [0.00] Memory policy: Data cache writeback [0.00] On node 0 totalpages: 8192 [0.00] free_area_init_node: node 0, pgdat c0322324, node_mem_map c1fba000 [0.00] Normal zone: 64 pages used for memmap [0.00] Normal zone: 0 pages reserved [0.00] Normal zone: 8192 pages, LIFO batch:0 [0.00] pcpu-alloc: s0 r0 d32768 u32768 alloc=1*32768 [0.00] pcpu-alloc: [0] 0 [0.00] Built 1 zonelists in Zone order, mobility grouping on. Total pages: 8128 [0.00] Kernel command line: console=ttyS0,115200n8 earlyprintk root=/dev/mmcblk0p1 rw rootwait debug user_debug=31 [0.00] PID hash table entries: 128 (order: -3, 512 bytes) [0.00] Dentry cache hash table entries: 4096 (order: 2, 16384 bytes) [0.00] Inode-cache hash table entries: 2048 (order: 1, 8192 bytes) [0.00] Memory: 29092K/32768K available (2542K kernel code, 74K rwdata, 448K rodata, 104K init, 116K bss, 3676K reserved) [0.00] Virtual kernel memory layout: [0.00] vector : 0x - 0x1000 ( 4 kB) [0.00] fixmap : 0xfff0 - 0xfffe ( 896 kB) [0.00] vmalloc : 0xc280 - 0xff00 ( 968 MB) [0.00] lowmem : 0xc000 - 0xc200 ( 32 MB) [0.00] .text : 0xc0008000 - 0xc02f3d80 (2992 kB) [0.00] .init : 0xc02f4000 - 0xc030e36c ( 105 kB) [0.00] .data : 0xc031 - 0xc0322aa0 ( 75 kB) [0.00].bss : 0xc0322aac - 0xc033fbc0 ( 117 kB) [0.00] SLUB: HWalign=32, Order=0-3, MinObjects=0, CPUs=1, Nodes=1 [0.00] Preemptible hierarchical RCU implementation. [0.00] NR_IRQS:16 nr_irqs:16 16 [0.00] sched_clock: 32 bits at 100 Hz, resolution 1000ns, wraps every 2147483648000ns [0.01] Calibrating delay loop... 146.84 BogoMIPS (lpj=734208) [0.10] pid_max: default: 4096 minimum: 301 [0.10] Mount-cache hash table entries: 1024 (order: 0, 4096 bytes) [0.11] Mountpoint-cache
Re: [PATCH] ARM: reinsert ARCH_MULTI_V4 Kconfig option
On Wed, Apr 09, 2014 at 05:50:57PM +0200, Arnd Bergmann wrote:
> On Wednesday 09 April 2014 16:27:11 Russell King - ARM Linux wrote:
> > If it's called from ARM code, then \reg will contain a 4-byte aligned
> > address. If it's called from Thumb code, \reg will contain a 2-byte
> > aligned address with bit 0 *always* set.
>
> Right, that is the assumption.
>
> > So, with the code originally quoted above, if the helper is called from
> > thumb code, and CONFIG_CPU_32v4 is enabled, then we end up falling past
> > the moveq to the "b ." and entering an infinite loop.
>
> As Uwe said, that "b ." was not meant to be in the patch used for
> submission, it was to check what goes wrong when running this code
> on ARMv4 -- either crash user space or hang in an infinite loop.
> I forgot what the result of that experiment was.
>
> The trouble is that this code:
>
>.macro usr_ret, reg
> #ifdef CONFIG_ARM_THUMB
> #ifdef CONFIG_CPU_32v4
> tst \reg, #3
> moveq pc, \reg
> #endif
> bx \reg
> #else
> mov pc, \reg
> #endif
> .endm
>
> for some reason does the wrong thing running on ARMv4 (fa526) with non-thumb
> user space when both CONFIG_CPU_32v4 and CONFIG_ARM_THUMB are enabled:
> it still tries to do the 'bx' and triggers an invalid opcode exception.
I assume this has been discussed in off-list (maybe on some irc channel
somewhere), because there's nothing on-list apart from these emails...
So, let's repeat the debugging which probably has already occured, but
this time on-list...
It would be useful to see the register state from the undefined
instruction exception. That needs this patch, CONFIG_DEBUG_USER in the
kernel config enabled, and user_debug=1 passed on the kernel command
line.
diff --git a/arch/arm/kernel/traps.c b/arch/arm/kernel/traps.c
index 172ee18ff124..abd2fc067736 100644
--- a/arch/arm/kernel/traps.c
+++ b/arch/arm/kernel/traps.c
@@ -445,6 +445,7 @@ asmlinkage void __exception do_undefinstr(struct pt_regs
*regs)
if (user_debug & UDBG_UNDEFINED) {
printk(KERN_INFO "%s (%d): undefined instruction: pc=%p\n",
current->comm, task_pid_nr(current), pc);
+ __show_regs(regs);
dump_instr(KERN_INFO, regs);
}
#endif
--
FTTC broadband for 0.8mile line: now at 9.7Mbps down 460kbps up... slowly
improving, and getting towards what was expected from it.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] ARM: reinsert ARCH_MULTI_V4 Kconfig option
On Wednesday 09 April 2014 16:27:11 Russell King - ARM Linux wrote: > On Wed, Apr 09, 2014 at 05:13:26PM +0200, Uwe Kleine-König wrote: > > On Wed, Apr 09, 2014 at 04:06:40PM +0100, Russell King - ARM Linux wrote: > > > On Wed, Apr 09, 2014 at 04:54:16PM +0200, Jonas Jensen wrote: > > > > On 13 December 2013 12:39, Russell King - ARM Linux > > > > wrote: > > > > diff --git a/arch/arm/kernel/entry-armv.S b/arch/arm/kernel/entry-armv.S > > > > index 1879e8d..de15bfd 100644 > > > > --- a/arch/arm/kernel/entry-armv.S > > > > +++ b/arch/arm/kernel/entry-armv.S > > > > @@ -739,6 +739,18 @@ ENDPROC(__switch_to) > > > > > > > > .macro usr_ret, reg > > > > #ifdef CONFIG_ARM_THUMB > > > > + /* > > > > +* Having CONFIG_ARM_THUMB isn't a guarantee that the cpu has > > > > support > > > > +* for Thumb and so the bx instruction. Use a mov if the > > > > address to > > > > +* jump to is 32 bit aligned. (Note that this code is compiled > > > > in ARM > > > > +* mode, so this is the right test.) > > > > +*/ > > > > +#if defined(CONFIG_CPU_32v4) > > > > + tst \reg, #3 > > > > + moveq pc, \reg > > > > + b . > > > > +#endif > > > > + > > > > bx \reg > > > > > > What's wrong with: > > > tst \reg, #3 > > > moveq pc, \reg > > > bx \reg > > > > > > rather than ending in an infinite loop? > > The added b . was a test to check if the machine then hangs instead of > > crashing. (And yes, that was the case, so it was tried to return to a > > non-aligned address.) > > If it's called from ARM code, then \reg will contain a 4-byte aligned > address. If it's called from Thumb code, \reg will contain a 2-byte > aligned address with bit 0 *always* set. Right, that is the assumption. > So, with the code originally quoted above, if the helper is called from > thumb code, and CONFIG_CPU_32v4 is enabled, then we end up falling past > the moveq to the "b ." and entering an infinite loop. As Uwe said, that "b ." was not meant to be in the patch used for submission, it was to check what goes wrong when running this code on ARMv4 -- either crash user space or hang in an infinite loop. I forgot what the result of that experiment was. The trouble is that this code: .macro usr_ret, reg #ifdef CONFIG_ARM_THUMB #ifdef CONFIG_CPU_32v4 tst \reg, #3 moveq pc, \reg #endif bx \reg #else mov pc, \reg #endif .endm for some reason does the wrong thing running on ARMv4 (fa526) with non-thumb user space when both CONFIG_CPU_32v4 and CONFIG_ARM_THUMB are enabled: it still tries to do the 'bx' and triggers an invalid opcode exception. Arnd -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] ARM: reinsert ARCH_MULTI_V4 Kconfig option
On Wed, Apr 09, 2014 at 05:13:26PM +0200, Uwe Kleine-König wrote: > Hello Russell, > > On Wed, Apr 09, 2014 at 04:06:40PM +0100, Russell King - ARM Linux wrote: > > On Wed, Apr 09, 2014 at 04:54:16PM +0200, Jonas Jensen wrote: > > > On 13 December 2013 12:39, Russell King - ARM Linux > > > wrote: > > > > I see what's causing this: the kuser helpers are using "bx lr" to return > > > > which will be undefined on non-Thumb CPUs. We generally cope fine with > > > > non-Thumb CPUs, conditionalising where necessary on HWCAP_THUMB or the > > > > T bit in the PSR being set. > > > > > > > > However, it looks like the kuser helpers got missed. As a check, please > > > > look at arch/arm/kernel/entry-armv.S, find the line with: > > > > > > > > .macro usr_ret, reg > > > > > > > > and ensure that the mov pc, \reg case always gets used. Please report > > > > back. > > > > > > Uwe and Arnd came up with a solution except it doesn't work when I test > > > it. > > > > > > The suggested patch is: > > > > > > diff --git a/arch/arm/kernel/entry-armv.S b/arch/arm/kernel/entry-armv.S > > > index 1879e8d..de15bfd 100644 > > > --- a/arch/arm/kernel/entry-armv.S > > > +++ b/arch/arm/kernel/entry-armv.S > > > @@ -739,6 +739,18 @@ ENDPROC(__switch_to) > > > > > > .macro usr_ret, reg > > > #ifdef CONFIG_ARM_THUMB > > > + /* > > > +* Having CONFIG_ARM_THUMB isn't a guarantee that the cpu has > > > support > > > +* for Thumb and so the bx instruction. Use a mov if the address > > > to > > > +* jump to is 32 bit aligned. (Note that this code is compiled in > > > ARM > > > +* mode, so this is the right test.) > > > +*/ > > > +#if defined(CONFIG_CPU_32v4) > > > + tst \reg, #3 > > > + moveq pc, \reg > > > + b . > > > +#endif > > > + > > > bx \reg > > > > What's wrong with: > > tst \reg, #3 > > moveq pc, \reg > > bx \reg > > > > rather than ending in an infinite loop? > The added b . was a test to check if the machine then hangs instead of > crashing. (And yes, that was the case, so it was tried to return to a > non-aligned address.) If it's called from ARM code, then \reg will contain a 4-byte aligned address. If it's called from Thumb code, \reg will contain a 2-byte aligned address with bit 0 *always* set. So, with the code originally quoted above, if the helper is called from thumb code, and CONFIG_CPU_32v4 is enabled, then we end up falling past the moveq to the "b ." and entering an infinite loop. -- FTTC broadband for 0.8mile line: now at 9.7Mbps down 460kbps up... slowly improving, and getting towards what was expected from it. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] ARM: reinsert ARCH_MULTI_V4 Kconfig option
Hello Russell, On Wed, Apr 09, 2014 at 04:06:40PM +0100, Russell King - ARM Linux wrote: > On Wed, Apr 09, 2014 at 04:54:16PM +0200, Jonas Jensen wrote: > > On 13 December 2013 12:39, Russell King - ARM Linux > > wrote: > > > I see what's causing this: the kuser helpers are using "bx lr" to return > > > which will be undefined on non-Thumb CPUs. We generally cope fine with > > > non-Thumb CPUs, conditionalising where necessary on HWCAP_THUMB or the > > > T bit in the PSR being set. > > > > > > However, it looks like the kuser helpers got missed. As a check, please > > > look at arch/arm/kernel/entry-armv.S, find the line with: > > > > > > .macro usr_ret, reg > > > > > > and ensure that the mov pc, \reg case always gets used. Please report > > > back. > > > > Uwe and Arnd came up with a solution except it doesn't work when I test it. > > > > The suggested patch is: > > > > diff --git a/arch/arm/kernel/entry-armv.S b/arch/arm/kernel/entry-armv.S > > index 1879e8d..de15bfd 100644 > > --- a/arch/arm/kernel/entry-armv.S > > +++ b/arch/arm/kernel/entry-armv.S > > @@ -739,6 +739,18 @@ ENDPROC(__switch_to) > > > > .macro usr_ret, reg > > #ifdef CONFIG_ARM_THUMB > > + /* > > +* Having CONFIG_ARM_THUMB isn't a guarantee that the cpu has > > support > > +* for Thumb and so the bx instruction. Use a mov if the address to > > +* jump to is 32 bit aligned. (Note that this code is compiled in > > ARM > > +* mode, so this is the right test.) > > +*/ > > +#if defined(CONFIG_CPU_32v4) > > + tst \reg, #3 > > + moveq pc, \reg > > + b . > > +#endif > > + > > bx \reg > > What's wrong with: > tst \reg, #3 > moveq pc, \reg > bx \reg > > rather than ending in an infinite loop? The added b . was a test to check if the machine then hangs instead of crashing. (And yes, that was the case, so it was tried to return to a non-aligned address.) Best regards Uwe -- Pengutronix e.K. | Uwe Kleine-König| Industrial Linux Solutions | http://www.pengutronix.de/ | -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] ARM: reinsert ARCH_MULTI_V4 Kconfig option
On Wed, Apr 09, 2014 at 05:04:48PM +0200, Uwe Kleine-König wrote: > On Wed, Apr 09, 2014 at 04:54:16PM +0200, Jonas Jensen wrote: > > On 13 December 2013 12:39, Russell King - ARM Linux > > wrote: > > > I see what's causing this: the kuser helpers are using "bx lr" to return > > > which will be undefined on non-Thumb CPUs. We generally cope fine with > > > non-Thumb CPUs, conditionalising where necessary on HWCAP_THUMB or the > > > T bit in the PSR being set. > > > > > > However, it looks like the kuser helpers got missed. As a check, please > > > look at arch/arm/kernel/entry-armv.S, find the line with: > > > > > > .macro usr_ret, reg > > > > > > and ensure that the mov pc, \reg case always gets used. Please report > > > back. > > > > Uwe and Arnd came up with a solution except it doesn't work when I test it. > > > > The suggested patch is: > > > > diff --git a/arch/arm/kernel/entry-armv.S b/arch/arm/kernel/entry-armv.S > > index 1879e8d..de15bfd 100644 > > --- a/arch/arm/kernel/entry-armv.S > > +++ b/arch/arm/kernel/entry-armv.S > > @@ -739,6 +739,18 @@ ENDPROC(__switch_to) > > > > .macro usr_ret, reg > > #ifdef CONFIG_ARM_THUMB > > + /* > > +* Having CONFIG_ARM_THUMB isn't a guarantee that the cpu has > > support > > +* for Thumb and so the bx instruction. Use a mov if the address to > > +* jump to is 32 bit aligned. (Note that this code is compiled in > > ARM > > +* mode, so this is the right test.) > > +*/ > > +#if defined(CONFIG_CPU_32v4) > > + tst \reg, #3 > > + moveq pc, \reg > > + b . > > +#endif > > + > > bx \reg > > #else > > mov pc, \reg > > > > > > With this applied, and the following two possibilities in next-20140403: > > > > [1] ARCH_MULTI_V4 only (no CONFIG_ARM_THUMB) > > CONFIG_CPU_32v4=y > > > > [2] ARCH_MULTI_V4 and ARCH_MULTI_V4T > > CONFIG_ARM_THUMB=y > > CONFIG_CPU_32v4=y > > CONFIG_CPU_32v4T=y > > > > > > Booting a kernel with either option [1] or [2] yield the following results: > > > > [1] works > > [2] hangs after "[2.73] Freeing unused kernel memory: 104K > > (c02f5000 - c030f000)" > > > > > > Any help why the moveq doesn't work would be much appreciated. > doing s/moveq/mov/ does the trick on the machine in question, but this > is obviously not an option for mainline. But it means that even on this > non-Thumb capable machine \reg contains an address that is not aligned. > > Where does \reg come from? Is it provided by userspace? If so, is it a > userspace bug? Well, in case (2), if usr_ret is returning to a caller running thumb code, it will lock up - because the register will not be aligned, so moveq will fail, and the next instruction is a branch which only ever branches to itself. -- FTTC broadband for 0.8mile line: now at 9.7Mbps down 460kbps up... slowly improving, and getting towards what was expected from it. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] ARM: reinsert ARCH_MULTI_V4 Kconfig option
On Wed, Apr 09, 2014 at 04:54:16PM +0200, Jonas Jensen wrote: > On 13 December 2013 12:39, Russell King - ARM Linux > wrote: > > I see what's causing this: the kuser helpers are using "bx lr" to return > > which will be undefined on non-Thumb CPUs. We generally cope fine with > > non-Thumb CPUs, conditionalising where necessary on HWCAP_THUMB or the > > T bit in the PSR being set. > > > > However, it looks like the kuser helpers got missed. As a check, please > > look at arch/arm/kernel/entry-armv.S, find the line with: > > > > .macro usr_ret, reg > > > > and ensure that the mov pc, \reg case always gets used. Please report > > back. > > Uwe and Arnd came up with a solution except it doesn't work when I test it. > > The suggested patch is: > > diff --git a/arch/arm/kernel/entry-armv.S b/arch/arm/kernel/entry-armv.S > index 1879e8d..de15bfd 100644 > --- a/arch/arm/kernel/entry-armv.S > +++ b/arch/arm/kernel/entry-armv.S > @@ -739,6 +739,18 @@ ENDPROC(__switch_to) > > .macro usr_ret, reg > #ifdef CONFIG_ARM_THUMB > + /* > +* Having CONFIG_ARM_THUMB isn't a guarantee that the cpu has support > +* for Thumb and so the bx instruction. Use a mov if the address to > +* jump to is 32 bit aligned. (Note that this code is compiled in ARM > +* mode, so this is the right test.) > +*/ > +#if defined(CONFIG_CPU_32v4) > + tst \reg, #3 > + moveq pc, \reg > + b . > +#endif > + > bx \reg What's wrong with: tst \reg, #3 moveq pc, \reg bx \reg rather than ending in an infinite loop? -- FTTC broadband for 0.8mile line: now at 9.7Mbps down 460kbps up... slowly improving, and getting towards what was expected from it. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] ARM: reinsert ARCH_MULTI_V4 Kconfig option
On Wed, Apr 09, 2014 at 04:54:16PM +0200, Jonas Jensen wrote: > On 13 December 2013 12:39, Russell King - ARM Linux > wrote: > > I see what's causing this: the kuser helpers are using "bx lr" to return > > which will be undefined on non-Thumb CPUs. We generally cope fine with > > non-Thumb CPUs, conditionalising where necessary on HWCAP_THUMB or the > > T bit in the PSR being set. > > > > However, it looks like the kuser helpers got missed. As a check, please > > look at arch/arm/kernel/entry-armv.S, find the line with: > > > > .macro usr_ret, reg > > > > and ensure that the mov pc, \reg case always gets used. Please report > > back. > > Uwe and Arnd came up with a solution except it doesn't work when I test it. > > The suggested patch is: > > diff --git a/arch/arm/kernel/entry-armv.S b/arch/arm/kernel/entry-armv.S > index 1879e8d..de15bfd 100644 > --- a/arch/arm/kernel/entry-armv.S > +++ b/arch/arm/kernel/entry-armv.S > @@ -739,6 +739,18 @@ ENDPROC(__switch_to) > > .macro usr_ret, reg > #ifdef CONFIG_ARM_THUMB > + /* > +* Having CONFIG_ARM_THUMB isn't a guarantee that the cpu has support > +* for Thumb and so the bx instruction. Use a mov if the address to > +* jump to is 32 bit aligned. (Note that this code is compiled in ARM > +* mode, so this is the right test.) > +*/ > +#if defined(CONFIG_CPU_32v4) > + tst \reg, #3 > + moveq pc, \reg > + b . > +#endif > + > bx \reg > #else > mov pc, \reg > > > With this applied, and the following two possibilities in next-20140403: > > [1] ARCH_MULTI_V4 only (no CONFIG_ARM_THUMB) > CONFIG_CPU_32v4=y > > [2] ARCH_MULTI_V4 and ARCH_MULTI_V4T > CONFIG_ARM_THUMB=y > CONFIG_CPU_32v4=y > CONFIG_CPU_32v4T=y > > > Booting a kernel with either option [1] or [2] yield the following results: > > [1] works > [2] hangs after "[2.73] Freeing unused kernel memory: 104K > (c02f5000 - c030f000)" > > > Any help why the moveq doesn't work would be much appreciated. doing s/moveq/mov/ does the trick on the machine in question, but this is obviously not an option for mainline. But it means that even on this non-Thumb capable machine \reg contains an address that is not aligned. Where does \reg come from? Is it provided by userspace? If so, is it a userspace bug? Best regards Uwe -- Pengutronix e.K. | Uwe Kleine-König| Industrial Linux Solutions | http://www.pengutronix.de/ | -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] ARM: reinsert ARCH_MULTI_V4 Kconfig option
On 13 December 2013 12:39, Russell King - ARM Linux wrote: > I see what's causing this: the kuser helpers are using "bx lr" to return > which will be undefined on non-Thumb CPUs. We generally cope fine with > non-Thumb CPUs, conditionalising where necessary on HWCAP_THUMB or the > T bit in the PSR being set. > > However, it looks like the kuser helpers got missed. As a check, please > look at arch/arm/kernel/entry-armv.S, find the line with: > > .macro usr_ret, reg > > and ensure that the mov pc, \reg case always gets used. Please report > back. Uwe and Arnd came up with a solution except it doesn't work when I test it. The suggested patch is: diff --git a/arch/arm/kernel/entry-armv.S b/arch/arm/kernel/entry-armv.S index 1879e8d..de15bfd 100644 --- a/arch/arm/kernel/entry-armv.S +++ b/arch/arm/kernel/entry-armv.S @@ -739,6 +739,18 @@ ENDPROC(__switch_to) .macro usr_ret, reg #ifdef CONFIG_ARM_THUMB + /* +* Having CONFIG_ARM_THUMB isn't a guarantee that the cpu has support +* for Thumb and so the bx instruction. Use a mov if the address to +* jump to is 32 bit aligned. (Note that this code is compiled in ARM +* mode, so this is the right test.) +*/ +#if defined(CONFIG_CPU_32v4) + tst \reg, #3 + moveq pc, \reg + b . +#endif + bx \reg #else mov pc, \reg With this applied, and the following two possibilities in next-20140403: [1] ARCH_MULTI_V4 only (no CONFIG_ARM_THUMB) CONFIG_CPU_32v4=y [2] ARCH_MULTI_V4 and ARCH_MULTI_V4T CONFIG_ARM_THUMB=y CONFIG_CPU_32v4=y CONFIG_CPU_32v4T=y Booting a kernel with either option [1] or [2] yield the following results: [1] works [2] hangs after "[2.73] Freeing unused kernel memory: 104K (c02f5000 - c030f000)" Any help why the moveq doesn't work would be much appreciated. The commit where this was tested: https://bitbucket.org/Kasreyn/linux-next/commits/48320cbe0d5a1fb6ada52cea9efd87c7712367cb Regards, Jonas -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] ARM: reinsert ARCH_MULTI_V4 Kconfig option
On 13 December 2013 12:39, Russell King - ARM Linux li...@arm.linux.org.uk wrote: I see what's causing this: the kuser helpers are using bx lr to return which will be undefined on non-Thumb CPUs. We generally cope fine with non-Thumb CPUs, conditionalising where necessary on HWCAP_THUMB or the T bit in the PSR being set. However, it looks like the kuser helpers got missed. As a check, please look at arch/arm/kernel/entry-armv.S, find the line with: .macro usr_ret, reg and ensure that the mov pc, \reg case always gets used. Please report back. Uwe and Arnd came up with a solution except it doesn't work when I test it. The suggested patch is: diff --git a/arch/arm/kernel/entry-armv.S b/arch/arm/kernel/entry-armv.S index 1879e8d..de15bfd 100644 --- a/arch/arm/kernel/entry-armv.S +++ b/arch/arm/kernel/entry-armv.S @@ -739,6 +739,18 @@ ENDPROC(__switch_to) .macro usr_ret, reg #ifdef CONFIG_ARM_THUMB + /* +* Having CONFIG_ARM_THUMB isn't a guarantee that the cpu has support +* for Thumb and so the bx instruction. Use a mov if the address to +* jump to is 32 bit aligned. (Note that this code is compiled in ARM +* mode, so this is the right test.) +*/ +#if defined(CONFIG_CPU_32v4) + tst \reg, #3 + moveq pc, \reg + b . +#endif + bx \reg #else mov pc, \reg With this applied, and the following two possibilities in next-20140403: [1] ARCH_MULTI_V4 only (no CONFIG_ARM_THUMB) CONFIG_CPU_32v4=y [2] ARCH_MULTI_V4 and ARCH_MULTI_V4T CONFIG_ARM_THUMB=y CONFIG_CPU_32v4=y CONFIG_CPU_32v4T=y Booting a kernel with either option [1] or [2] yield the following results: [1] works [2] hangs after [2.73] Freeing unused kernel memory: 104K (c02f5000 - c030f000) Any help why the moveq doesn't work would be much appreciated. The commit where this was tested: https://bitbucket.org/Kasreyn/linux-next/commits/48320cbe0d5a1fb6ada52cea9efd87c7712367cb Regards, Jonas -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] ARM: reinsert ARCH_MULTI_V4 Kconfig option
On Wed, Apr 09, 2014 at 04:54:16PM +0200, Jonas Jensen wrote: On 13 December 2013 12:39, Russell King - ARM Linux li...@arm.linux.org.uk wrote: I see what's causing this: the kuser helpers are using bx lr to return which will be undefined on non-Thumb CPUs. We generally cope fine with non-Thumb CPUs, conditionalising where necessary on HWCAP_THUMB or the T bit in the PSR being set. However, it looks like the kuser helpers got missed. As a check, please look at arch/arm/kernel/entry-armv.S, find the line with: .macro usr_ret, reg and ensure that the mov pc, \reg case always gets used. Please report back. Uwe and Arnd came up with a solution except it doesn't work when I test it. The suggested patch is: diff --git a/arch/arm/kernel/entry-armv.S b/arch/arm/kernel/entry-armv.S index 1879e8d..de15bfd 100644 --- a/arch/arm/kernel/entry-armv.S +++ b/arch/arm/kernel/entry-armv.S @@ -739,6 +739,18 @@ ENDPROC(__switch_to) .macro usr_ret, reg #ifdef CONFIG_ARM_THUMB + /* +* Having CONFIG_ARM_THUMB isn't a guarantee that the cpu has support +* for Thumb and so the bx instruction. Use a mov if the address to +* jump to is 32 bit aligned. (Note that this code is compiled in ARM +* mode, so this is the right test.) +*/ +#if defined(CONFIG_CPU_32v4) + tst \reg, #3 + moveq pc, \reg + b . +#endif + bx \reg #else mov pc, \reg With this applied, and the following two possibilities in next-20140403: [1] ARCH_MULTI_V4 only (no CONFIG_ARM_THUMB) CONFIG_CPU_32v4=y [2] ARCH_MULTI_V4 and ARCH_MULTI_V4T CONFIG_ARM_THUMB=y CONFIG_CPU_32v4=y CONFIG_CPU_32v4T=y Booting a kernel with either option [1] or [2] yield the following results: [1] works [2] hangs after [2.73] Freeing unused kernel memory: 104K (c02f5000 - c030f000) Any help why the moveq doesn't work would be much appreciated. doing s/moveq/mov/ does the trick on the machine in question, but this is obviously not an option for mainline. But it means that even on this non-Thumb capable machine \reg contains an address that is not aligned. Where does \reg come from? Is it provided by userspace? If so, is it a userspace bug? Best regards Uwe -- Pengutronix e.K. | Uwe Kleine-König| Industrial Linux Solutions | http://www.pengutronix.de/ | -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] ARM: reinsert ARCH_MULTI_V4 Kconfig option
On Wed, Apr 09, 2014 at 04:54:16PM +0200, Jonas Jensen wrote: On 13 December 2013 12:39, Russell King - ARM Linux li...@arm.linux.org.uk wrote: I see what's causing this: the kuser helpers are using bx lr to return which will be undefined on non-Thumb CPUs. We generally cope fine with non-Thumb CPUs, conditionalising where necessary on HWCAP_THUMB or the T bit in the PSR being set. However, it looks like the kuser helpers got missed. As a check, please look at arch/arm/kernel/entry-armv.S, find the line with: .macro usr_ret, reg and ensure that the mov pc, \reg case always gets used. Please report back. Uwe and Arnd came up with a solution except it doesn't work when I test it. The suggested patch is: diff --git a/arch/arm/kernel/entry-armv.S b/arch/arm/kernel/entry-armv.S index 1879e8d..de15bfd 100644 --- a/arch/arm/kernel/entry-armv.S +++ b/arch/arm/kernel/entry-armv.S @@ -739,6 +739,18 @@ ENDPROC(__switch_to) .macro usr_ret, reg #ifdef CONFIG_ARM_THUMB + /* +* Having CONFIG_ARM_THUMB isn't a guarantee that the cpu has support +* for Thumb and so the bx instruction. Use a mov if the address to +* jump to is 32 bit aligned. (Note that this code is compiled in ARM +* mode, so this is the right test.) +*/ +#if defined(CONFIG_CPU_32v4) + tst \reg, #3 + moveq pc, \reg + b . +#endif + bx \reg What's wrong with: tst \reg, #3 moveq pc, \reg bx \reg rather than ending in an infinite loop? -- FTTC broadband for 0.8mile line: now at 9.7Mbps down 460kbps up... slowly improving, and getting towards what was expected from it. -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] ARM: reinsert ARCH_MULTI_V4 Kconfig option
On Wed, Apr 09, 2014 at 05:04:48PM +0200, Uwe Kleine-König wrote: On Wed, Apr 09, 2014 at 04:54:16PM +0200, Jonas Jensen wrote: On 13 December 2013 12:39, Russell King - ARM Linux li...@arm.linux.org.uk wrote: I see what's causing this: the kuser helpers are using bx lr to return which will be undefined on non-Thumb CPUs. We generally cope fine with non-Thumb CPUs, conditionalising where necessary on HWCAP_THUMB or the T bit in the PSR being set. However, it looks like the kuser helpers got missed. As a check, please look at arch/arm/kernel/entry-armv.S, find the line with: .macro usr_ret, reg and ensure that the mov pc, \reg case always gets used. Please report back. Uwe and Arnd came up with a solution except it doesn't work when I test it. The suggested patch is: diff --git a/arch/arm/kernel/entry-armv.S b/arch/arm/kernel/entry-armv.S index 1879e8d..de15bfd 100644 --- a/arch/arm/kernel/entry-armv.S +++ b/arch/arm/kernel/entry-armv.S @@ -739,6 +739,18 @@ ENDPROC(__switch_to) .macro usr_ret, reg #ifdef CONFIG_ARM_THUMB + /* +* Having CONFIG_ARM_THUMB isn't a guarantee that the cpu has support +* for Thumb and so the bx instruction. Use a mov if the address to +* jump to is 32 bit aligned. (Note that this code is compiled in ARM +* mode, so this is the right test.) +*/ +#if defined(CONFIG_CPU_32v4) + tst \reg, #3 + moveq pc, \reg + b . +#endif + bx \reg #else mov pc, \reg With this applied, and the following two possibilities in next-20140403: [1] ARCH_MULTI_V4 only (no CONFIG_ARM_THUMB) CONFIG_CPU_32v4=y [2] ARCH_MULTI_V4 and ARCH_MULTI_V4T CONFIG_ARM_THUMB=y CONFIG_CPU_32v4=y CONFIG_CPU_32v4T=y Booting a kernel with either option [1] or [2] yield the following results: [1] works [2] hangs after [2.73] Freeing unused kernel memory: 104K (c02f5000 - c030f000) Any help why the moveq doesn't work would be much appreciated. doing s/moveq/mov/ does the trick on the machine in question, but this is obviously not an option for mainline. But it means that even on this non-Thumb capable machine \reg contains an address that is not aligned. Where does \reg come from? Is it provided by userspace? If so, is it a userspace bug? Well, in case (2), if usr_ret is returning to a caller running thumb code, it will lock up - because the register will not be aligned, so moveq will fail, and the next instruction is a branch which only ever branches to itself. -- FTTC broadband for 0.8mile line: now at 9.7Mbps down 460kbps up... slowly improving, and getting towards what was expected from it. -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] ARM: reinsert ARCH_MULTI_V4 Kconfig option
Hello Russell, On Wed, Apr 09, 2014 at 04:06:40PM +0100, Russell King - ARM Linux wrote: On Wed, Apr 09, 2014 at 04:54:16PM +0200, Jonas Jensen wrote: On 13 December 2013 12:39, Russell King - ARM Linux li...@arm.linux.org.uk wrote: I see what's causing this: the kuser helpers are using bx lr to return which will be undefined on non-Thumb CPUs. We generally cope fine with non-Thumb CPUs, conditionalising where necessary on HWCAP_THUMB or the T bit in the PSR being set. However, it looks like the kuser helpers got missed. As a check, please look at arch/arm/kernel/entry-armv.S, find the line with: .macro usr_ret, reg and ensure that the mov pc, \reg case always gets used. Please report back. Uwe and Arnd came up with a solution except it doesn't work when I test it. The suggested patch is: diff --git a/arch/arm/kernel/entry-armv.S b/arch/arm/kernel/entry-armv.S index 1879e8d..de15bfd 100644 --- a/arch/arm/kernel/entry-armv.S +++ b/arch/arm/kernel/entry-armv.S @@ -739,6 +739,18 @@ ENDPROC(__switch_to) .macro usr_ret, reg #ifdef CONFIG_ARM_THUMB + /* +* Having CONFIG_ARM_THUMB isn't a guarantee that the cpu has support +* for Thumb and so the bx instruction. Use a mov if the address to +* jump to is 32 bit aligned. (Note that this code is compiled in ARM +* mode, so this is the right test.) +*/ +#if defined(CONFIG_CPU_32v4) + tst \reg, #3 + moveq pc, \reg + b . +#endif + bx \reg What's wrong with: tst \reg, #3 moveq pc, \reg bx \reg rather than ending in an infinite loop? The added b . was a test to check if the machine then hangs instead of crashing. (And yes, that was the case, so it was tried to return to a non-aligned address.) Best regards Uwe -- Pengutronix e.K. | Uwe Kleine-König| Industrial Linux Solutions | http://www.pengutronix.de/ | -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] ARM: reinsert ARCH_MULTI_V4 Kconfig option
On Wed, Apr 09, 2014 at 05:13:26PM +0200, Uwe Kleine-König wrote: Hello Russell, On Wed, Apr 09, 2014 at 04:06:40PM +0100, Russell King - ARM Linux wrote: On Wed, Apr 09, 2014 at 04:54:16PM +0200, Jonas Jensen wrote: On 13 December 2013 12:39, Russell King - ARM Linux li...@arm.linux.org.uk wrote: I see what's causing this: the kuser helpers are using bx lr to return which will be undefined on non-Thumb CPUs. We generally cope fine with non-Thumb CPUs, conditionalising where necessary on HWCAP_THUMB or the T bit in the PSR being set. However, it looks like the kuser helpers got missed. As a check, please look at arch/arm/kernel/entry-armv.S, find the line with: .macro usr_ret, reg and ensure that the mov pc, \reg case always gets used. Please report back. Uwe and Arnd came up with a solution except it doesn't work when I test it. The suggested patch is: diff --git a/arch/arm/kernel/entry-armv.S b/arch/arm/kernel/entry-armv.S index 1879e8d..de15bfd 100644 --- a/arch/arm/kernel/entry-armv.S +++ b/arch/arm/kernel/entry-armv.S @@ -739,6 +739,18 @@ ENDPROC(__switch_to) .macro usr_ret, reg #ifdef CONFIG_ARM_THUMB + /* +* Having CONFIG_ARM_THUMB isn't a guarantee that the cpu has support +* for Thumb and so the bx instruction. Use a mov if the address to +* jump to is 32 bit aligned. (Note that this code is compiled in ARM +* mode, so this is the right test.) +*/ +#if defined(CONFIG_CPU_32v4) + tst \reg, #3 + moveq pc, \reg + b . +#endif + bx \reg What's wrong with: tst \reg, #3 moveq pc, \reg bx \reg rather than ending in an infinite loop? The added b . was a test to check if the machine then hangs instead of crashing. (And yes, that was the case, so it was tried to return to a non-aligned address.) If it's called from ARM code, then \reg will contain a 4-byte aligned address. If it's called from Thumb code, \reg will contain a 2-byte aligned address with bit 0 *always* set. So, with the code originally quoted above, if the helper is called from thumb code, and CONFIG_CPU_32v4 is enabled, then we end up falling past the moveq to the b . and entering an infinite loop. -- FTTC broadband for 0.8mile line: now at 9.7Mbps down 460kbps up... slowly improving, and getting towards what was expected from it. -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] ARM: reinsert ARCH_MULTI_V4 Kconfig option
On Wednesday 09 April 2014 16:27:11 Russell King - ARM Linux wrote: On Wed, Apr 09, 2014 at 05:13:26PM +0200, Uwe Kleine-König wrote: On Wed, Apr 09, 2014 at 04:06:40PM +0100, Russell King - ARM Linux wrote: On Wed, Apr 09, 2014 at 04:54:16PM +0200, Jonas Jensen wrote: On 13 December 2013 12:39, Russell King - ARM Linux li...@arm.linux.org.uk wrote: diff --git a/arch/arm/kernel/entry-armv.S b/arch/arm/kernel/entry-armv.S index 1879e8d..de15bfd 100644 --- a/arch/arm/kernel/entry-armv.S +++ b/arch/arm/kernel/entry-armv.S @@ -739,6 +739,18 @@ ENDPROC(__switch_to) .macro usr_ret, reg #ifdef CONFIG_ARM_THUMB + /* +* Having CONFIG_ARM_THUMB isn't a guarantee that the cpu has support +* for Thumb and so the bx instruction. Use a mov if the address to +* jump to is 32 bit aligned. (Note that this code is compiled in ARM +* mode, so this is the right test.) +*/ +#if defined(CONFIG_CPU_32v4) + tst \reg, #3 + moveq pc, \reg + b . +#endif + bx \reg What's wrong with: tst \reg, #3 moveq pc, \reg bx \reg rather than ending in an infinite loop? The added b . was a test to check if the machine then hangs instead of crashing. (And yes, that was the case, so it was tried to return to a non-aligned address.) If it's called from ARM code, then \reg will contain a 4-byte aligned address. If it's called from Thumb code, \reg will contain a 2-byte aligned address with bit 0 *always* set. Right, that is the assumption. So, with the code originally quoted above, if the helper is called from thumb code, and CONFIG_CPU_32v4 is enabled, then we end up falling past the moveq to the b . and entering an infinite loop. As Uwe said, that b . was not meant to be in the patch used for submission, it was to check what goes wrong when running this code on ARMv4 -- either crash user space or hang in an infinite loop. I forgot what the result of that experiment was. The trouble is that this code: .macro usr_ret, reg #ifdef CONFIG_ARM_THUMB #ifdef CONFIG_CPU_32v4 tst \reg, #3 moveq pc, \reg #endif bx \reg #else mov pc, \reg #endif .endm for some reason does the wrong thing running on ARMv4 (fa526) with non-thumb user space when both CONFIG_CPU_32v4 and CONFIG_ARM_THUMB are enabled: it still tries to do the 'bx' and triggers an invalid opcode exception. Arnd -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] ARM: reinsert ARCH_MULTI_V4 Kconfig option
On Wed, Apr 09, 2014 at 05:50:57PM +0200, Arnd Bergmann wrote:
On Wednesday 09 April 2014 16:27:11 Russell King - ARM Linux wrote:
If it's called from ARM code, then \reg will contain a 4-byte aligned
address. If it's called from Thumb code, \reg will contain a 2-byte
aligned address with bit 0 *always* set.
Right, that is the assumption.
So, with the code originally quoted above, if the helper is called from
thumb code, and CONFIG_CPU_32v4 is enabled, then we end up falling past
the moveq to the b . and entering an infinite loop.
As Uwe said, that b . was not meant to be in the patch used for
submission, it was to check what goes wrong when running this code
on ARMv4 -- either crash user space or hang in an infinite loop.
I forgot what the result of that experiment was.
The trouble is that this code:
.macro usr_ret, reg
#ifdef CONFIG_ARM_THUMB
#ifdef CONFIG_CPU_32v4
tst \reg, #3
moveq pc, \reg
#endif
bx \reg
#else
mov pc, \reg
#endif
.endm
for some reason does the wrong thing running on ARMv4 (fa526) with non-thumb
user space when both CONFIG_CPU_32v4 and CONFIG_ARM_THUMB are enabled:
it still tries to do the 'bx' and triggers an invalid opcode exception.
I assume this has been discussed in off-list (maybe on some irc channel
somewhere), because there's nothing on-list apart from these emails...
So, let's repeat the debugging which probably has already occured, but
this time on-list...
It would be useful to see the register state from the undefined
instruction exception. That needs this patch, CONFIG_DEBUG_USER in the
kernel config enabled, and user_debug=1 passed on the kernel command
line.
diff --git a/arch/arm/kernel/traps.c b/arch/arm/kernel/traps.c
index 172ee18ff124..abd2fc067736 100644
--- a/arch/arm/kernel/traps.c
+++ b/arch/arm/kernel/traps.c
@@ -445,6 +445,7 @@ asmlinkage void __exception do_undefinstr(struct pt_regs
*regs)
if (user_debug UDBG_UNDEFINED) {
printk(KERN_INFO %s (%d): undefined instruction: pc=%p\n,
current-comm, task_pid_nr(current), pc);
+ __show_regs(regs);
dump_instr(KERN_INFO, regs);
}
#endif
--
FTTC broadband for 0.8mile line: now at 9.7Mbps down 460kbps up... slowly
improving, and getting towards what was expected from it.
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] ARM: reinsert ARCH_MULTI_V4 Kconfig option
Boots without panic when bx is removed. Diff and boot log: diff --git a/arch/arm/kernel/entry-armv.S b/arch/arm/kernel/entry-armv.S index b3fb8c9..ad736b3 100644 --- a/arch/arm/kernel/entry-armv.S +++ b/arch/arm/kernel/entry-armv.S @@ -737,8 +737,8 @@ ENDPROC(__switch_to) .macro usr_ret, reg #ifdef CONFIG_ARM_THUMB - bx \reg -#else +# bx \reg +##else mov pc, \reg #endif .endm Uncompressing Linux... done, booting the kernel. [0.00] Booting Linux on physical CPU 0x0 [0.00] Linux version 3.13.0-rc3-next-20131213+ (i@Ildjarn) (gcc version 4.6.3 (crosstool-NG 1.16.0) ) #1346 PREEMPT Fri Dec 13 13:16:00 CET 2013 [0.00] CPU: FA526 [66015261] revision 1 (ARMv4), cr=397f [0.00] CPU: VIVT data cache, VIVT instruction cache [0.00] Machine model: MOXA UC-7112-LX [0.00] bootconsole [earlycon0] enabled [0.00] Memory policy: Data cache writeback [0.00] Built 1 zonelists in Zone order, mobility grouping on. Total pages: 8120 [0.00] Kernel command line: console=ttyS0,115200n8 earlyprintk root=/dev/mmcblk0p1 rw rootwait [0.00] PID hash table entries: 128 (order: -3, 512 bytes) [0.00] Dentry cache hash table entries: 4096 (order: 2, 16384 bytes) [0.00] Inode-cache hash table entries: 2048 (order: 1, 8192 bytes) [0.00] Memory: 23116K/32768K available (2521K kernel code, 108K rwdata, 572K rodata, 150K init, 5884K bss, 9652K reserved) [0.00] Virtual kernel memory layout: [0.00] vector : 0x - 0x1000 ( 4 kB) [0.00] fixmap : 0xfff0 - 0xfffe ( 896 kB) [0.00] vmalloc : 0xc280 - 0xff00 ( 968 MB) [0.00] lowmem : 0xc000 - 0xc200 ( 32 MB) [0.00] .text : 0xc0008000 - 0xc030d914 (3095 kB) [0.00] .init : 0xc030e000 - 0xc0333b30 ( 151 kB) [0.00] .data : 0xc0334000 - 0xc034f160 ( 109 kB) [0.00].bss : 0xc034f16c - 0xc090e378 (5885 kB) [0.00] SLUB: HWalign=32, Order=0-3, MinObjects=0, CPUs=1, Nodes=1 [0.00] Preemptible hierarchical RCU implementation. [0.00] NR_IRQS:16 nr_irqs:16 16 [0.00] sched_clock: 32 bits at 100 Hz, resolution 1000ns, wraps every 2147483648000ns [0.00] Lock dependency validator: Copyright (c) 2006 Red Hat, Inc., Ingo Molnar [0.00] ... MAX_LOCKDEP_SUBCLASSES: 8 [0.00] ... MAX_LOCK_DEPTH: 48 [0.00] ... MAX_LOCKDEP_KEYS:8191 [0.00] ... CLASSHASH_SIZE: 4096 [0.00] ... MAX_LOCKDEP_ENTRIES: 16384 [0.00] ... MAX_LOCKDEP_CHAINS: 32768 [0.00] ... CHAINHASH_SIZE: 16384 [0.00] memory used by lock dependency info: 3695 kB [0.00] per task-struct memory footprint: 1152 bytes [0.00] kmemleak: Kernel memory leak detector disabled [0.00] kmemleak: Early log buffer exceeded (673), please increase DEBUG_KMEMLEAK_EARLY_LOG_SIZE [0.12] Calibrating delay loop... 144.79 BogoMIPS (lpj=723968) [0.20] pid_max: default: 4096 minimum: 301 [0.21] Mount-cache hash table entries: 512 [0.29] CPU: Testing write buffer coherency: ok [0.31] Setting up static identity map for 0x266a60 - 0x266ae8 [0.37] devtmpfs: initialized [0.42] kworker/u2:0 (13) used greatest stack depth: 6296 bytes left [0.43] NET: Registered protocol family 16 [0.46] DMA: preallocated 256 KiB pool for atomic coherent allocations [1.05] bio: create slab at 0 [1.39] DMA-API: preallocated 4096 debug entries [1.39] DMA-API: debugging enabled by kernel config [1.40] Switched to clocksource moxart_timer [1.51] NET: Registered protocol family 2 [1.53] TCP established hash table entries: 1024 (order: 0, 4096 bytes) [1.55] TCP bind hash table entries: 1024 (order: 3, 36864 bytes) [1.56] TCP: Hash tables configured (established 1024 bind 1024) [1.57] TCP: reno registered [1.57] UDP hash table entries: 128 (order: 1, 10240 bytes) [1.58] UDP-Lite hash table entries: 128 (order: 1, 10240 bytes) [1.60] NET: Registered protocol family 1 [1.72] kworker/u2:0 (136) used greatest stack depth: 6196 bytes left [2.33] jffs2: version 2.2. (NAND) © 2001-2006 Red Hat, Inc. [2.37] msgmni has been set to 45 [2.38] io scheduler noop registered [2.38] io scheduler cfq registered (default) [2.43] Serial: 8250/16550 driver, 1 ports, IRQ sharing enabled [2.52] 9820.uart: ttyS0 at MMIO 0x9820 (irq = 21, base_baud = 921600) is a 16550A [2.53] console [ttyS0] enabled [2.53] console [ttyS0] enabled [2.54] bootconsole [earlycon0] disabled [2.54] bootconsole [earlycon0] disabled [2.65] 8000.flash: Found 1 x16 devices at 0x0 in 16-bit bank.
Re: [PATCH] ARM: reinsert ARCH_MULTI_V4 Kconfig option
On Fri, Dec 13, 2013 at 11:51:09AM +0100, Jonas Jensen wrote: > On 13 December 2013 10:56, Russell King - ARM Linux > wrote: > > So, having these symbols enabled (provided the right ones for FA526 are > > also enabled) makes no difference. So I don't buy your explanation. > > The explanation is indeed false, CPU_FA526 and CPU_ARM920T get along just > fine. > That's not where the problem is. > > Panic goes away after removing CONFIG_ARM_THUMB=y. > > I assume this is what should happen on processors without thumb? I see what's causing this: the kuser helpers are using "bx lr" to return which will be undefined on non-Thumb CPUs. We generally cope fine with non-Thumb CPUs, conditionalising where necessary on HWCAP_THUMB or the T bit in the PSR being set. However, it looks like the kuser helpers got missed. As a check, please look at arch/arm/kernel/entry-armv.S, find the line with: .macro usr_ret, reg and ensure that the mov pc, \reg case always gets used. Please report back. Thanks. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] ARM: reinsert ARCH_MULTI_V4 Kconfig option
On 13 December 2013 10:56, Russell King - ARM Linux wrote: > So, having these symbols enabled (provided the right ones for FA526 are > also enabled) makes no difference. So I don't buy your explanation. The explanation is indeed false, CPU_FA526 and CPU_ARM920T get along just fine. That's not where the problem is. Panic goes away after removing CONFIG_ARM_THUMB=y. I assume this is what should happen on processors without thumb? Thanks, Jonas -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] ARM: reinsert ARCH_MULTI_V4 Kconfig option
On Fri, Dec 13, 2013 at 09:09:09AM +0100, Jonas Jensen wrote: > CPU_FA526 lacks thumb state support and doesn't get along with some > of the options enabled by ARCH_MULTI_V4T. > > More specifically it doesn't get along with CPU_ARM920T: > > CPU_ABRT_EV4T > CPU_CACHE_V4WT > CPU_COPY_V4WB > CPU_TLB_V4WBI Having these selected doesn't change how the kernel is compiled or how the kernel uses the code which these provide. These mainly control which files are built. They also control indirectly how the code is called - but the ultimate decision is made by the CPU which is detected and the block in __fa526_proc_info. So, having these symbols enabled (provided the right ones for FA526 are also enabled) makes no difference. So I don't buy your explanation. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] ARM: reinsert ARCH_MULTI_V4 Kconfig option
CPU_FA526 lacks thumb state support and doesn't get along with some of the options enabled by ARCH_MULTI_V4T. More specifically it doesn't get along with CPU_ARM920T: CPU_ABRT_EV4T CPU_CACHE_V4WT CPU_COPY_V4WB CPU_TLB_V4WBI One or a combination of the above cause trouble for userspace, the following happens when kernel tries to exec init: [ 11.79] Kernel panic - not syncing: Attempted to kill init! exitcode=0x0004 [ 11.79] [ 11.79] CPU: 0 PID: 1 Comm: init Not tainted 3.13.0-rc3-next-20131212+ #1332 [ 11.79] [] (unwind_backtrace) from [] (show_stack+0x18/0x1c) [ 11.79] [] (show_stack) from [] (dump_stack+0x20/0x28) [ 11.79] [] (dump_stack) from [] (panic+0x98/0x1ec) [ 11.79] [] (panic) from [] (do_exit+0x80c/0x8e8) [ 11.79] [] (do_exit) from [] (do_group_exit+0x44/0xb8) [ 11.79] [] (do_group_exit) from [] (get_signal_to_deliver+0x2fc/0x5a4) [ 11.79] [] (get_signal_to_deliver) from [] (do_signal+0xac/0x3e0) [ 11.79] [] (do_signal) from [] (do_work_pending+0xcc/0xe8) [ 11.79] [] (do_work_pending) from [] (work_pending+0xc/0x20) Reinsert ARCH_MULTI_V4 so it can be used on platforms with CPU_FA526. Signed-off-by: Jonas Jensen --- Notes: I don't know how to handle this so I'm making it standalone for your feedback (it was broken out from MOXA ART SoC series). This is important for MOXA ART (and other FA526 platforms), please have a look. Applies to next-20131213 arch/arm/Kconfig | 5 + 1 file changed, 5 insertions(+) diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig index b64a8ef..4f88ff3 100644 --- a/arch/arm/Kconfig +++ b/arch/arm/Kconfig @@ -863,6 +863,11 @@ menu "Multiple platform selection" comment "CPU Core family selection" +config ARCH_MULTI_V4 + bool "ARMv4 based platforms (FA526, StrongARM)" + depends on !ARCH_MULTI_V6_V7 + select ARCH_MULTI_V4_V5 + config ARCH_MULTI_V4T bool "ARMv4T based platforms (ARM720T, ARM920T, ...)" depends on !ARCH_MULTI_V6_V7 -- 1.8.2.1 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] ARM: reinsert ARCH_MULTI_V4 Kconfig option
CPU_FA526 lacks thumb state support and doesn't get along with some of the options enabled by ARCH_MULTI_V4T. More specifically it doesn't get along with CPU_ARM920T: CPU_ABRT_EV4T CPU_CACHE_V4WT CPU_COPY_V4WB CPU_TLB_V4WBI One or a combination of the above cause trouble for userspace, the following happens when kernel tries to exec init: [ 11.79] Kernel panic - not syncing: Attempted to kill init! exitcode=0x0004 [ 11.79] [ 11.79] CPU: 0 PID: 1 Comm: init Not tainted 3.13.0-rc3-next-20131212+ #1332 [ 11.79] [c000d620] (unwind_backtrace) from [c000ba54] (show_stack+0x18/0x1c) [ 11.79] [c000ba54] (show_stack) from [c027f498] (dump_stack+0x20/0x28) [ 11.79] [c027f498] (dump_stack) from [c027ce80] (panic+0x98/0x1ec) [ 11.79] [c027ce80] (panic) from [c0016d4c] (do_exit+0x80c/0x8e8) [ 11.79] [c0016d4c] (do_exit) from [c0016ea4] (do_group_exit+0x44/0xb8) [ 11.79] [c0016ea4] (do_group_exit) from [c0022dbc] (get_signal_to_deliver+0x2fc/0x5a4) [ 11.79] [c0022dbc] (get_signal_to_deliver) from [c027ca38] (do_signal+0xac/0x3e0) [ 11.79] [c027ca38] (do_signal) from [c000b460] (do_work_pending+0xcc/0xe8) [ 11.79] [c000b460] (do_work_pending) from [c0009374] (work_pending+0xc/0x20) Reinsert ARCH_MULTI_V4 so it can be used on platforms with CPU_FA526. Signed-off-by: Jonas Jensen jonas.jen...@gmail.com --- Notes: I don't know how to handle this so I'm making it standalone for your feedback (it was broken out from MOXA ART SoC series). This is important for MOXA ART (and other FA526 platforms), please have a look. Applies to next-20131213 arch/arm/Kconfig | 5 + 1 file changed, 5 insertions(+) diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig index b64a8ef..4f88ff3 100644 --- a/arch/arm/Kconfig +++ b/arch/arm/Kconfig @@ -863,6 +863,11 @@ menu Multiple platform selection comment CPU Core family selection +config ARCH_MULTI_V4 + bool ARMv4 based platforms (FA526, StrongARM) + depends on !ARCH_MULTI_V6_V7 + select ARCH_MULTI_V4_V5 + config ARCH_MULTI_V4T bool ARMv4T based platforms (ARM720T, ARM920T, ...) depends on !ARCH_MULTI_V6_V7 -- 1.8.2.1 -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] ARM: reinsert ARCH_MULTI_V4 Kconfig option
On Fri, Dec 13, 2013 at 09:09:09AM +0100, Jonas Jensen wrote: CPU_FA526 lacks thumb state support and doesn't get along with some of the options enabled by ARCH_MULTI_V4T. More specifically it doesn't get along with CPU_ARM920T: CPU_ABRT_EV4T CPU_CACHE_V4WT CPU_COPY_V4WB CPU_TLB_V4WBI Having these selected doesn't change how the kernel is compiled or how the kernel uses the code which these provide. These mainly control which files are built. They also control indirectly how the code is called - but the ultimate decision is made by the CPU which is detected and the block in __fa526_proc_info. So, having these symbols enabled (provided the right ones for FA526 are also enabled) makes no difference. So I don't buy your explanation. -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] ARM: reinsert ARCH_MULTI_V4 Kconfig option
On 13 December 2013 10:56, Russell King - ARM Linux li...@arm.linux.org.uk wrote: So, having these symbols enabled (provided the right ones for FA526 are also enabled) makes no difference. So I don't buy your explanation. The explanation is indeed false, CPU_FA526 and CPU_ARM920T get along just fine. That's not where the problem is. Panic goes away after removing CONFIG_ARM_THUMB=y. I assume this is what should happen on processors without thumb? Thanks, Jonas -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] ARM: reinsert ARCH_MULTI_V4 Kconfig option
On Fri, Dec 13, 2013 at 11:51:09AM +0100, Jonas Jensen wrote: On 13 December 2013 10:56, Russell King - ARM Linux li...@arm.linux.org.uk wrote: So, having these symbols enabled (provided the right ones for FA526 are also enabled) makes no difference. So I don't buy your explanation. The explanation is indeed false, CPU_FA526 and CPU_ARM920T get along just fine. That's not where the problem is. Panic goes away after removing CONFIG_ARM_THUMB=y. I assume this is what should happen on processors without thumb? I see what's causing this: the kuser helpers are using bx lr to return which will be undefined on non-Thumb CPUs. We generally cope fine with non-Thumb CPUs, conditionalising where necessary on HWCAP_THUMB or the T bit in the PSR being set. However, it looks like the kuser helpers got missed. As a check, please look at arch/arm/kernel/entry-armv.S, find the line with: .macro usr_ret, reg and ensure that the mov pc, \reg case always gets used. Please report back. Thanks. -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] ARM: reinsert ARCH_MULTI_V4 Kconfig option
Boots without panic when bx is removed. Diff and boot log: diff --git a/arch/arm/kernel/entry-armv.S b/arch/arm/kernel/entry-armv.S index b3fb8c9..ad736b3 100644 --- a/arch/arm/kernel/entry-armv.S +++ b/arch/arm/kernel/entry-armv.S @@ -737,8 +737,8 @@ ENDPROC(__switch_to) .macro usr_ret, reg #ifdef CONFIG_ARM_THUMB - bx \reg -#else +# bx \reg +##else mov pc, \reg #endif .endm Uncompressing Linux... done, booting the kernel. [0.00] Booting Linux on physical CPU 0x0 [0.00] Linux version 3.13.0-rc3-next-20131213+ (i@Ildjarn) (gcc version 4.6.3 (crosstool-NG 1.16.0) ) #1346 PREEMPT Fri Dec 13 13:16:00 CET 2013 [0.00] CPU: FA526 [66015261] revision 1 (ARMv4), cr=397f [0.00] CPU: VIVT data cache, VIVT instruction cache [0.00] Machine model: MOXA UC-7112-LX [0.00] bootconsole [earlycon0] enabled [0.00] Memory policy: Data cache writeback [0.00] Built 1 zonelists in Zone order, mobility grouping on. Total pages: 8120 [0.00] Kernel command line: console=ttyS0,115200n8 earlyprintk root=/dev/mmcblk0p1 rw rootwait [0.00] PID hash table entries: 128 (order: -3, 512 bytes) [0.00] Dentry cache hash table entries: 4096 (order: 2, 16384 bytes) [0.00] Inode-cache hash table entries: 2048 (order: 1, 8192 bytes) [0.00] Memory: 23116K/32768K available (2521K kernel code, 108K rwdata, 572K rodata, 150K init, 5884K bss, 9652K reserved) [0.00] Virtual kernel memory layout: [0.00] vector : 0x - 0x1000 ( 4 kB) [0.00] fixmap : 0xfff0 - 0xfffe ( 896 kB) [0.00] vmalloc : 0xc280 - 0xff00 ( 968 MB) [0.00] lowmem : 0xc000 - 0xc200 ( 32 MB) [0.00] .text : 0xc0008000 - 0xc030d914 (3095 kB) [0.00] .init : 0xc030e000 - 0xc0333b30 ( 151 kB) [0.00] .data : 0xc0334000 - 0xc034f160 ( 109 kB) [0.00].bss : 0xc034f16c - 0xc090e378 (5885 kB) [0.00] SLUB: HWalign=32, Order=0-3, MinObjects=0, CPUs=1, Nodes=1 [0.00] Preemptible hierarchical RCU implementation. [0.00] NR_IRQS:16 nr_irqs:16 16 [0.00] sched_clock: 32 bits at 100 Hz, resolution 1000ns, wraps every 2147483648000ns [0.00] Lock dependency validator: Copyright (c) 2006 Red Hat, Inc., Ingo Molnar [0.00] ... MAX_LOCKDEP_SUBCLASSES: 8 [0.00] ... MAX_LOCK_DEPTH: 48 [0.00] ... MAX_LOCKDEP_KEYS:8191 [0.00] ... CLASSHASH_SIZE: 4096 [0.00] ... MAX_LOCKDEP_ENTRIES: 16384 [0.00] ... MAX_LOCKDEP_CHAINS: 32768 [0.00] ... CHAINHASH_SIZE: 16384 [0.00] memory used by lock dependency info: 3695 kB [0.00] per task-struct memory footprint: 1152 bytes [0.00] kmemleak: Kernel memory leak detector disabled [0.00] kmemleak: Early log buffer exceeded (673), please increase DEBUG_KMEMLEAK_EARLY_LOG_SIZE [0.12] Calibrating delay loop... 144.79 BogoMIPS (lpj=723968) [0.20] pid_max: default: 4096 minimum: 301 [0.21] Mount-cache hash table entries: 512 [0.29] CPU: Testing write buffer coherency: ok [0.31] Setting up static identity map for 0x266a60 - 0x266ae8 [0.37] devtmpfs: initialized [0.42] kworker/u2:0 (13) used greatest stack depth: 6296 bytes left [0.43] NET: Registered protocol family 16 [0.46] DMA: preallocated 256 KiB pool for atomic coherent allocations [1.05] bio: create slab bio-0 at 0 [1.39] DMA-API: preallocated 4096 debug entries [1.39] DMA-API: debugging enabled by kernel config [1.40] Switched to clocksource moxart_timer [1.51] NET: Registered protocol family 2 [1.53] TCP established hash table entries: 1024 (order: 0, 4096 bytes) [1.55] TCP bind hash table entries: 1024 (order: 3, 36864 bytes) [1.56] TCP: Hash tables configured (established 1024 bind 1024) [1.57] TCP: reno registered [1.57] UDP hash table entries: 128 (order: 1, 10240 bytes) [1.58] UDP-Lite hash table entries: 128 (order: 1, 10240 bytes) [1.60] NET: Registered protocol family 1 [1.72] kworker/u2:0 (136) used greatest stack depth: 6196 bytes left [2.33] jffs2: version 2.2. (NAND) © 2001-2006 Red Hat, Inc. [2.37] msgmni has been set to 45 [2.38] io scheduler noop registered [2.38] io scheduler cfq registered (default) [2.43] Serial: 8250/16550 driver, 1 ports, IRQ sharing enabled [2.52] 9820.uart: ttyS0 at MMIO 0x9820 (irq = 21, base_baud = 921600) is a 16550A [2.53] console [ttyS0] enabled [2.53] console [ttyS0] enabled [2.54] bootconsole [earlycon0] disabled [2.54] bootconsole [earlycon0] disabled [2.65] 8000.flash: Found 1 x16 devices at 0x0 in 16-bit
