Re: [PATCH v2 0/3] ARM: handle imprecise aborts from firmware in common code
Hi Lucas, On 15 October 2015 at 03:32, Lucas Stach <l.st...@pengutronix.de> wrote: > This series implements the handling of a pending imprecise abort left behind > by the bootloader/firmware running before Linux in the common ARM startup > code. > > It turns pending imprecise aborts that may signal during the first unmasking > of such aborts on the boot CPU into a non-faulting event and warns the user > that the firmware of the machine might be buggy. > > Handling this in the common code makes sure that we only ignore already > pending > aborts and not those that may happen later during system boot/usage. It also > allows to remove the custom fault handler from the 3 architectures that are > known to have bad firmware/bootloaders. > > V2 adapts patch 1 to suggestions from Russell and Hauke and drops former > patch 3 (ARM: mvebu: remove the workaround imprecise abort fault handler) > as it has already been applied. I have build and boot tested the three patches in this series on top of next-20151016 with the kernelci.org system[1][2]. It found no new build/boot regressions and also I can confirm it fixes the issue reported here[3]. Tested-by: Tyler Baker <tyler.ba...@linaro.org> Cheers, Tyler [1] http://kernelci.org/boot/all/job/tbaker/kernel/v4.3-rc5-8587-g6890e51b69b2/ [2] http://kernelci.org/build/tbaker/kernel/v4.3-rc5-8587-g6890e51b69b2/ [3] http://www.spinics.net/lists/arm-kernel/msg451280.html -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: n900 in 4.1-rc0
Hi Pavel, On 26 April 2015 at 03:20, Pavel Machek pa...@ucw.cz wrote: Hi! Just tried booting 4.1-rc0 on n900 (commit 34c9a0ffc75ad25b6a60f61e27c4a4b1189b8085) and it is broken. Any ideas? Looks like DT and legacy booting are working fine in our labs. [0][1] Interesting web pages, thanks. No problem. I noticed that legacy booting indicates broken today, but... Is there list of your targets somewhere? It looks to have failed it's boot test on the stable v3.14 based LSK today, however it is booting fine still on the upstream development trees. You can also use a query[0] to refine your view if you would like. The up to date list of targets can be found here[1] and if interested in receiving email reports you can subscribe here[2]. Best regards, Pavel [0] http://kernelci.org/boot/omap3-n900/ [1] http://kernelci.org/boot/omap3-n900,legacy/ -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html Cheers, Tyler [0] http://kernelci.org/boot/?n900fail [1] https://wiki.linaro.org/ProductTechnology/kernelci.org [2] https://lists.linaro.org/mailman/listinfo/kernel-build-reports -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: n900 in 4.1-rc0
On 16 April 2015 at 02:32, Pavel Machek pa...@ucw.cz wrote: Hi! Just tried booting 4.1-rc0 on n900 (commit 34c9a0ffc75ad25b6a60f61e27c4a4b1189b8085) and it is broken. Any ideas? Looks like DT and legacy booting are working fine in our labs. [0][1] Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html ___ linux-arm-kernel mailing list linux-arm-ker...@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel Tyler [0] http://kernelci.org/boot/omap3-n900/ [1] http://kernelci.org/boot/omap3-n900,legacy/ -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Possible regression in next-20150323 due to ARM, arm64: kvm: get rid of the bounce page
On 27 March 2015 at 03:06, Will Deacon will.dea...@arm.com wrote: On Fri, Mar 27, 2015 at 12:25:54AM +, Simon Horman wrote: On Thu, Mar 26, 2015 at 08:29:21AM -0700, Tyler Baker wrote: On 26 March 2015 at 06:36, Will Deacon will.dea...@arm.com wrote: On Thu, Mar 26, 2015 at 12:39:39AM +, Simon Horman wrote: On Tue, Mar 24, 2015 at 11:13:58AM -0500, Nishanth Menon wrote: I think we now have a new error: (seen with omap2plus_defconfig) on next-20150324 : ./arch/arm/kernel/vmlinux.lds:677: undefined symbol `__hyp_idmap_size' referenced in expression make: *** [vmlinux] Error 1 Thanks, I am seeing that too. My armchair suggestion is that the following should be reverted. e60a1fec44a2f (ARM: kvm: implement replacement for ld's LOG2CEIL()) 06f75a1f62000 (ARM, arm64: kvm: get rid of the bounce page) Can you try again with the latest -next please? We've merged an additional patch aimed at sorting this out. Reverting isn't really an option, as there's an awful lot of code that depends on the bounce page removal. Here are the kernelci.org -next results[1], if you click the build status you can dig down into the build failures. next-20150326 has now hit a compiler bug, Arnd mentioned he was looking into this issue. I have confirmed that next-20150326 does not compile without the following reverted: 12eb3e833961 (ARM: kvm: assert on HYP section boundaries not actual code size) e60a1fec44a2 (ARM: kvm: implement replacement for ld's LOG2CEIL()) 06f75a1f6200 (ARM, arm64: kvm: get rid of the bounce page) Thanks for testing this and sorry for the continued breakage. Which toolchain did you say you were using? Ard has some more patches trying to fix this, but none of our toolchains seem to tickle the issue. I am able to reproduce with this toolchain[1]. Will [1] http://releases.linaro.org/12.10/components/toolchain/binaries/gcc-linaro-arm-linux-gnueabihf-4.7-2012.10-20121022_linux.tar.bz2 Tyler -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Possible regression in next-20150323 due to ARM, arm64: kvm: get rid of the bounce page
On 26 March 2015 at 06:36, Will Deacon will.dea...@arm.com wrote: On Thu, Mar 26, 2015 at 12:39:39AM +, Simon Horman wrote: On Tue, Mar 24, 2015 at 11:13:58AM -0500, Nishanth Menon wrote: I think we now have a new error: (seen with omap2plus_defconfig) on next-20150324 : ./arch/arm/kernel/vmlinux.lds:677: undefined symbol `__hyp_idmap_size' referenced in expression make: *** [vmlinux] Error 1 Thanks, I am seeing that too. My armchair suggestion is that the following should be reverted. e60a1fec44a2f (ARM: kvm: implement replacement for ld's LOG2CEIL()) 06f75a1f62000 (ARM, arm64: kvm: get rid of the bounce page) Can you try again with the latest -next please? We've merged an additional patch aimed at sorting this out. Reverting isn't really an option, as there's an awful lot of code that depends on the bounce page removal. Here are the kernelci.org -next results[1], if you click the build status you can dig down into the build failures. next-20150326 has now hit a compiler bug, Arnd mentioned he was looking into this issue. Will ___ linux-arm-kernel mailing list linux-arm-ker...@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel [1] http://kernelci.org/job/next/ Tyler -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [next-20150119]regression (mm)?
On 26 January 2015 at 04:00, Kirill A. Shutemov kir...@shutemov.name wrote: On Fri, Jan 23, 2015 at 10:37:46PM -0600, Nishanth Menon wrote: On 03:13-20150124, Kirill A. Shutemov wrote: On 09:39-20150123, Tyler Baker wrote: [...] I just reviewed the boot logs for next-20150123 and there still seems to be a related issue. I've been boot testing multi_v7_defconfig+CONFIG_ARM_LPAE=y kernel configurations which still seem broken. [...] Okay, proof of concept patch is below. It's going to break every other architecture with FIRST_USER_ADDRESS != 0, but I think it's cleaner way to go. Testing on my end: just ran through this set (+ logs similar to Tyler's from my side): next-20150123 (multi_v7_defconfig == !LPAE) 1:BeagleBoard-X15(am57xx-evm): BOOT: PASS: http://paste.ubuntu.org.cn/2219449 2: dra72x-evm: BOOT: PASS: http://paste.ubuntu.org.cn/2219450 3: dra7xx-evm: BOOT: PASS: http://paste.ubuntu.org.cn/2219451 4: omap5-evm: BOOT: PASS: http://paste.ubuntu.org.cn/2219452 TOTAL = 4 boards, Booted Boards = 4, No Boot boards = 0 next-20150123-LPAE-Logging enabled[1] (multi_v7_defconfig +LPAE) 1:BeagleBoard-X15(am57xx-evm): BOOT: FAIL: http://paste.ubuntu.org.cn/2220938 2: dra72x-evm: BOOT: FAIL: http://paste.ubuntu.org.cn/2220943 3: dra7xx-evm: BOOT: FAIL: http://paste.ubuntu.org.cn/2220947 4: omap5-evm: BOOT: FAIL: http://paste.ubuntu.org.cn/2220955 TOTAL = 4 boards, Booted Boards = 0, No Boot boards = 4 next-20150123-LPAE-new-patch [2] (multi_v7_defconfig + LPAE) 1:BeagleBoard-X15(am57xx-evm): BOOT: PASS: http://paste.ubuntu.org.cn/2221047 2: dra72x-evm: BOOT: PASS: http://paste.ubuntu.org.cn/2221065 3: dra7xx-evm: BOOT: PASS: http://paste.ubuntu.org.cn/2221069 4: omap5-evm: BOOT: PASS: http://paste.ubuntu.org.cn/2221070 TOTAL = 4 boards, Booted Boards = 4, No Boot boards = 0 next-20150123-new-patch[2] (multi_v7_defconfig == !LPAE) 1: am335x-evm: BOOT: PASS: http://paste.ubuntu.org.cn/2221277 2: am335x-sk: BOOT: PASS: http://paste.ubuntu.org.cn/2221278 3: am437x-sk: BOOT: FAIL: http://paste.ubuntu.org.cn/2221279 (unrelated) 4:am43xx-epos: BOOT: PASS: http://paste.ubuntu.org.cn/2221280 5: am43xx-gpevm: BOOT: PASS: http://paste.ubuntu.org.cn/2221281 6:BeagleBoard-X15(am57xx-evm): BOOT: PASS: http://paste.ubuntu.org.cn/2221282 7: BeagleBoard-XM: BOOT: FAIL: http://paste.ubuntu.org.cn/2221283 (unrelated) 8:beagleboard-vanilla: BOOT: PASS: http://paste.ubuntu.org.cn/2221284 9: beaglebone-black: BOOT: PASS: http://paste.ubuntu.org.cn/2221285 10: beaglebone: BOOT: FAIL: http://paste.ubuntu.org.cn/2221286 (unrelated) 11: dra72x-evm: BOOT: PASS: http://paste.ubuntu.org.cn/2221287 12: dra7xx-evm: BOOT: PASS: http://paste.ubuntu.org.cn/2221288 13: omap5-evm: BOOT: PASS: http://paste.ubuntu.org.cn/2221289 14: pandaboard-es: BOOT: PASS: http://paste.ubuntu.org.cn/2221290 15: pandaboard-vanilla: BOOT: PASS: http://paste.ubuntu.org.cn/2221291 16:sdp4430: BOOT: PASS: http://paste.ubuntu.org.cn/2221292 TOTAL = 16 boards, Booted Boards = 13, No Boot boards = 3 next-20150123-new-patch[2] (omap2plus_defconfig) 1: am335x-evm: BOOT: PASS: http://paste.ubuntu.org.cn/2221653 2: am335x-sk: BOOT: PASS: http://paste.ubuntu.org.cn/2221654 3: am437x-sk: BOOT: PASS: http://paste.ubuntu.org.cn/2221656 4:am43xx-epos: BOOT: PASS: http://paste.ubuntu.org.cn/2221659 5: am43xx-gpevm: BOOT: PASS: http://paste.ubuntu.org.cn/2221660 6:BeagleBoard-X15(am57xx-evm): BOOT: PASS: http://paste.ubuntu.org.cn/2221661 7: BeagleBoard-XM: BOOT: PASS: http://paste.ubuntu.org.cn/2221670 8:beagleboard-vanilla: BOOT: PASS: http://paste.ubuntu.org.cn/2221676 9: beaglebone-black: BOOT: PASS: http://paste.ubuntu.org.cn/2221683 10: beaglebone: BOOT: PASS: http://paste.ubuntu.org.cn/2221690 11: dra72x-evm: BOOT: PASS: http://paste.ubuntu.org.cn/2221692 12: dra7xx-evm: BOOT: PASS: http://paste.ubuntu.org.cn/2221695 13: omap5-evm: BOOT: PASS: http://paste.ubuntu.org.cn/2221700 14: pandaboard-es: BOOT: PASS: http://paste.ubuntu.org.cn/2221704 15: pandaboard-vanilla: BOOT: PASS: http://paste.ubuntu.org.cn/2221707 16
Re: [next-20150119]regression (mm)?
Hi, On 23 January 2015 at 09:27, Nishanth Menon n...@ti.com wrote: On 16:05-20150120, Kirill A. Shutemov wrote: [..] Signed-off-by: Kirill A. Shutemov kirill.shute...@linux.intel.com Reported-by: Nishanth Menon n...@ti.com Just to close on this thread: https://github.com/nmenon/kernel-test-logs/tree/next-20150123 looks good and back to old status. Thank you folks for all the help. I just reviewed the boot logs for next-20150123 and there still seems to be a related issue. I've been boot testing multi_v7_defconfig+CONFIG_ARM_LPAE=y kernel configurations which still seem broken. For example here are two boots with exynos5250-arndale, one with multi_v7_defconfig+CONFIG_ARM_LPAE=y [1] and the other with multi_v7_defconfig[2]. You can see the kernel configurations with CONFIG_ARM_LPAE=y show the splat: [ 14.605950] [ cut here ] [ 14.609163] WARNING: CPU: 1 PID: 63 at ../mm/mmap.c:2858 exit_mmap+0x1b8/0x224() [ 14.616548] Modules linked in: [ 14.619553] CPU: 1 PID: 63 Comm: init Not tainted 3.19.0-rc5-next-20150123 #1 [ 14.626713] Hardware name: SAMSUNG EXYNOS (Flattened Device Tree) [ 14.632830] [] (unwind_backtrace) from [] (show_stack+0x10/0x14) [ 14.640473] [] (show_stack) from [] (dump_stack+0x78/0x94) [ 14.647678] [] (dump_stack) from [] (warn_slowpath_common+0x74/0xb0) [ 14.655744] [] (warn_slowpath_common) from [] (warn_slowpath_null+0x1c/0x24) [ 14.664510] [] (warn_slowpath_null) from [] (exit_mmap+0x1b8/0x224) [ 14.672497] [] (exit_mmap) from [] (mmput+0x40/0xf8) [ 14.679180] [] (mmput) from [] (flush_old_exec+0x328/0x604) [ 14.686471] [] (flush_old_exec) from [] (load_elf_binary+0x26c/0x11f4) [ 14.694715] [] (load_elf_binary) from [] (search_binary_handler+0x98/0x244) [ 14.703395] [] (search_binary_handler) from [] (do_execveat_common+0x4dc/0x5bc) [ 14.712421] [] (do_execveat_common) from [] (do_execve+0x28/0x30) [ 14.720235] [] (do_execve) from [] (ret_fast_syscall+0x0/0x34) [ 14.727782] ---[ end trace 5e3ca48b454c7e0a ]--- [ 14.733758] [ cut here ] Has anyone else tested with CONFIG_ARM_LPAE=y that can confirm my findings? -- Regards, Nishanth Menon ___ linux-arm-kernel mailing list linux-arm-ker...@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel [1] http://storage.kernelci.org/next/next-20150123/arm-multi_v7_defconfig+CONFIG_ARM_LPAE=y/lab-tbaker/boot-exynos5250-arndale.html [2] http://storage.kernelci.org/next/next-20150123/arm-multi_v7_defconfig/lab-tbaker/boot-exynos5250-arndale.html Cheers, Tyler -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [next-20150119]regression (mm)?
Hi Kirill,
On 23 January 2015 at 12:22, Kirill A. Shutemov kir...@shutemov.name wrote:
On Fri, Jan 23, 2015 at 12:37:06PM -0600, Nishanth Menon wrote:
On 09:39-20150123, Tyler Baker wrote:
Hi,
On 23 January 2015 at 09:27, Nishanth Menon n...@ti.com wrote:
On 16:05-20150120, Kirill A. Shutemov wrote:
[..]
Signed-off-by: Kirill A. Shutemov kirill.shute...@linux.intel.com
Reported-by: Nishanth Menon n...@ti.com
Just to close on this thread:
https://github.com/nmenon/kernel-test-logs/tree/next-20150123 looks good
and back to old status. Thank you folks for all the help.
I just reviewed the boot logs for next-20150123 and there still seems
to be a related issue. I've been boot testing
multi_v7_defconfig+CONFIG_ARM_LPAE=y kernel configurations which still
seem broken.
For example here are two boots with exynos5250-arndale, one with
multi_v7_defconfig+CONFIG_ARM_LPAE=y [1] and the other with
multi_v7_defconfig[2]. You can see the kernel configurations with
CONFIG_ARM_LPAE=y show the splat:
[ 14.605950] [ cut here ]
[ 14.609163] WARNING: CPU: 1 PID: 63 at ../mm/mmap.c:2858
exit_mmap+0x1b8/0x224()
[ 14.616548] Modules linked in:
[ 14.619553] CPU: 1 PID: 63 Comm: init Not tainted
3.19.0-rc5-next-20150123 #1
[ 14.626713] Hardware name: SAMSUNG EXYNOS (Flattened Device Tree)
[ 14.632830] [] (unwind_backtrace) from [] (show_stack+0x10/0x14)
[ 14.640473] [] (show_stack) from [] (dump_stack+0x78/0x94)
[ 14.647678] [] (dump_stack) from [] (warn_slowpath_common+0x74/0xb0)
[ 14.655744] [] (warn_slowpath_common) from []
(warn_slowpath_null+0x1c/0x24)
[ 14.664510] [] (warn_slowpath_null) from [] (exit_mmap+0x1b8/0x224)
[ 14.672497] [] (exit_mmap) from [] (mmput+0x40/0xf8)
[ 14.679180] [] (mmput) from [] (flush_old_exec+0x328/0x604)
[ 14.686471] [] (flush_old_exec) from [] (load_elf_binary+0x26c/0x11f4)
[ 14.694715] [] (load_elf_binary) from []
(search_binary_handler+0x98/0x244)
[ 14.703395] [] (search_binary_handler) from []
(do_execveat_common+0x4dc/0x5bc)
[ 14.712421] [] (do_execveat_common) from [] (do_execve+0x28/0x30)
[ 14.720235] [] (do_execve) from [] (ret_fast_syscall+0x0/0x34)
[ 14.727782] ---[ end trace 5e3ca48b454c7e0a ]---
[ 14.733758] [ cut here ]
Has anyone else tested with CONFIG_ARM_LPAE=y that can confirm my findings?
Uggh... I missed since i was looking at non LPAE omap2plus_defconfig.
Dual A15 OMAP5432 with multi_v7_defconfig + CONFIG_ARM_LPAE=y
https://github.com/nmenon/kernel-test-logs/blob/next-20150123/multi_lpae_defconfig/omap5-evm.txt
Dual A15 DRA7/AM572x with same configuration as above.
https://raw.githubusercontent.com/nmenon/kernel-test-logs/next-20150123/multi_lpae_defconfig/dra7xx-evm.txt
https://github.com/nmenon/kernel-test-logs/blob/next-20150123/multi_lpae_defconfig/am57xx-evm.txt
Single A15 DRA72 with same configuration as above:
https://raw.githubusercontent.com/nmenon/kernel-test-logs/next-20150123/multi_lpae_defconfig/dra72x-evm.txt
You are right. the issue re-appears with LPAE on :(
Apologies on missing that.
Guys, could you instrument mm_{inc,dec}_nr_pmds() with dump_stack() +
printk() of the counter and add printk() on mmap_exit() then run a simple
program which triggers the issue?
For reference, here is the patch I've applied for testing, mostly
stolen from Felipe's debug patch above in this thread.
diff --git a/include/linux/mm.h b/include/linux/mm.h
index 1fbd0e8..e5b0444 100644
--- a/include/linux/mm.h
+++ b/include/linux/mm.h
@@ -1455,11 +1455,17 @@ static inline unsigned long mm_nr_pmds(struct
mm_struct *mm)
static inline void mm_inc_nr_pmds(struct mm_struct *mm)
{
atomic_long_inc(mm-nr_pmds);
+dump_stack();
+printk(KERN_INFO === %s nr_pmds %ld\n, __func__,
+atomic_long_read(mm-nr_pmds));
}
static inline void mm_dec_nr_pmds(struct mm_struct *mm)
{
atomic_long_dec(mm-nr_pmds);
+dump_stack();
+printk(KERN_INFO === %s nr_pmds %ld\n, __func__,
+atomic_long_read(mm-nr_pmds));
}
#endif
diff --git a/mm/mmap.c b/mm/mmap.c
index 6a7d36d..a16471f 100644
--- a/mm/mmap.c
+++ b/mm/mmap.c
@@ -2809,6 +2809,7 @@ EXPORT_SYMBOL(vm_brk);
/* Release all mmaps. */
void exit_mmap(struct mm_struct *mm)
{
+ printk(KERN_INFO === %s exit_mmap enter\n, __func__);
struct mmu_gather tlb;
struct vm_area_struct *vma;
unsigned long nr_accounted = 0;
I applied this patch to the tip of linux-next, configured for
multi_v7_defconfig and set CONFIG_ARM_LPAE=y. The log for this arndale
boot can be found here [1]. For good measure, I then rebuilt the
kernel with CONFIG_ARM_LPAE=n and booted the same platform again. This
log can be found here [2].
Happy hunting!
--
Kirill A. Shutemov
[1] http://storage.kernelci.org/debug/mm/arndale-lpae-debug-next-20150123.html
[2]
http
Re: [next-20150119]regression (mm)?
On 19 January 2015 at 09:04, Nishanth Menon n...@ti.com wrote: On 01/19/2015 10:59 AM, Tyler Baker wrote: I can confirm, I am observing the same issue in my lab. 15 platforms failed to boot on next-20150119. http://kernelci.org/boot/?next-20150119fail http://kernelci.org/boot/all/job/next/kernel/next-20150119/ I see many platforms succeed in lab-khilman, but fails in your farm as well :( For example: http://storage.kernelci.org/next/next-20150119/arm-imx_v6_v7_defconfig/lab-khilman/boot-imx6q-wandboard.txt has the same errors, but marked success. http://storage.kernelci.org/next/next-20150119/arm-imx_v6_v7_defconfig/lab-tbaker/boot-imx6q-wandboard.txt is marked fail. I suppose this is much worse than the pass status indicates. I agree. I believe this boots were marked as 'passed' because the platforms eventually reached userspace despite the kernel spewing errors. I've re-run a few of my boots, and sometimes the platform reaches userspace, other times it hangs. On Monday, 19 January 2015, Nishanth Menon n...@ti.com mailto:n...@ti.com wrote: Hi, Most platforms seem broken intoday's next tag. https://github.com/nmenon/kernel-test-logs/tree/next-20150119 (defconfig: omap2plus_defconfig) [7.166600] [ cut here ] [7.171676] WARNING: CPU: 0 PID: 54 at mm/mmap.c:2859 exit_mmap+0x1a8/0x21c() [7.179194] Modules linked in: [7.182479] CPU: 0 PID: 54 Comm: init Not tainted 3.19.0-rc5-next-20150119-2-gfdefcded1272 #1 [7.191863] Hardware name: Generic AM33XX (Flattened Device Tree) [7.198318] [c00153f0] (unwind_backtrace) from [c0011a74] (show_stack+0x10/0x14) [7.206528] [c0011a74] (show_stack) from [c0580150] (dump_stack+0x78/0x94) [7.214191] [c0580150] (dump_stack) from [c003d4d0] (warn_slowpath_common+0x7c/0xb4) [7.222751] [c003d4d0] (warn_slowpath_common) from [c003d524] (warn_slowpath_null+0x1c/0x24) [7.232038] [c003d524] (warn_slowpath_null) from [c012de64] (exit_mmap+0x1a8/0x21c) [7.240536] [c012de64] (exit_mmap) from [c003abb8] (mmput+0x44/0xec) [7.247612] [c003abb8] (mmput) from [c0151368] (flush_old_exec+0x300/0x5a4) [7.255357] [c0151368] (flush_old_exec) from [c0195c10] (load_elf_binary+0x2ec/0x1144) [7.264111] [c0195c10] (load_elf_binary) from [c0150ea0] (search_binary_handler+0x88/0x1ac) [7.273311] [c0150ea0] (search_binary_handler) from [c019554c] (load_script+0x260/0x280) [7.282232] [c019554c] (load_script) from [c0150ea0] (search_binary_handler+0x88/0x1ac) [7.291066] [c0150ea0] (search_binary_handler) from [c0151f0c] (do_execveat_common+0x538/0x6c4) [7.300628] [c0151f0c] (do_execveat_common) from [c01520c4] (do_execve+0x2c/0x34) [7.308881] [c01520c4] (do_execve) from [c000e5e0] (ret_fast_syscall+0x0/0x4c) [7.316881] ---[ end trace 3b8a46b1b280f423 ]--- -- Regards, Nishanth Menon ___ linux-arm-kernel mailing list linux-arm-ker...@lists.infradead.org javascript:; http://lists.infradead.org/mailman/listinfo/linux-arm-kernel -- Tyler Baker Tech Lead, LAVA Linaro.org | Open source software for ARM SoCs Follow Linaro: http://www.facebook.com/pages/Linaro http://twitter.com/#!/linaroorg - http://www.linaro.org/linaro-blog -- Regards, Nishanth Menon -- Tyler Baker Tech Lead, LAVA Linaro.org | Open source software for ARM SoCs Follow Linaro: http://www.facebook.com/pages/Linaro http://twitter.com/#!/linaroorg - http://www.linaro.org/linaro-blog -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Serial console not working after waking up from sleep
Sapiens, Rene rene.sapiens at ti.com writes: You can do a telnet to the device... you should be able to work with it but your serial session will show the garbage. Regards, Rene Hello, I am in essentially the same position, but currently working off of the pm-head branch. I am just using an initramfs, and have tried a few variations. With no_console_suspend set, I can trigger a wakeup using the wakeup_timer_seconds. The power usage goes back to the pre-suspend level, and I see text indicating a successful wakeup, but the console never comes back. Without no_console_suspend set, I can trigger the wakeup again with wakeup_timer_seconds, a console prompt comes back, but is unresponsive. I saw Rene's response about using Telnet, but this implies that there is an ethernet interface available. I have a custom board that only has a serial interface for external visibility, so at this point I lose insight into what is happening on the board. I have two questions, if people would be so willing to oblige: 1) Does anyone know why the console doesn't come back after wakeup? Is this something that may work in the future? 2) Does the console freezing mean that the other COM ports also don't work? Would communication on other interfaces continue to work? For example, a GPS plugged into one of the other COM ports? Thanks, Tyler -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
