Fixed
Created: Aug 28, 2014
Updated: Dec 3, 2018
Resolved Date: Sep 10, 2014
Found In Version: 6.0.0.5
Fix Version: 6.0.0.12
Severity: Severe
Applicable for: Wind River Linux 6
Component/s: BSP
Customer use wrlinux6.0.0.5 on XLP208 reference board. When they use target gdb, setting break pont and running the program, the kernel crashed with the following log:
--------------------------------------------------------------------------------------
BUG: using smp_processor_id() in preemptible [00000000] code: gdb/970
caller is ptrace_get_watch_regs+0x158/0x218
CPU: 1 PID: 970 Comm: gdb Not tainted 3.10.19-WR6.0.0.5_standard #3
Stack : c0000000016305a0 0000000000000004 c0000000f3e4fbc8 ffffffffc02f3c88
ffffffffc0c60000 ffffffffc0d605a0 0000000000000004 ffffffffc0d605a0
c0000000f3e4fbf8 ffffffffc0226e9c 0000000000000043 ffffffffc0c60000
c0000000f3e4fc18 ffffffffc022750c 0000000000000000 0000000000000000
0000000000000000 ffffffffc0fb0000 ffffffffc0faae88 ffffffffc0fb0000
ffffffffc0ac5dc0 ffffffffc0c5aad7 ffffffffc0faae88 c0000000f241bae8
00000000000003ca 0000000000000001 ffffffffc0c48320 0000000000000002
c0000000f3e4fc98 c0000000f3e4fba8 c0000000f3e4fcc0 ffffffffc0623b84
c0000000f3e4fcf8 ffffffffc0229058 c0000000f241b748 ffffffffc0ac5dc0
0000000000000001 ffffffffc01f93d0 0000000000000000 0000000000000000
...
Call Trace:
[<ffffffffc01f93d0>] show_stack+0xd8/0xf8
[<ffffffffc0623b84>] debug_smp_processor_id+0xf4/0x110
[<ffffffffc01f6aa8>] ptrace_get_watch_regs+0x158/0x218
[<ffffffffc01f6f40>] arch_ptrace+0x130/0x500
[<ffffffffc02360e0>] SyS_ptrace+0xa0/0x198
[<ffffffffc01ff244>] handle_sys64+0x44/0x68
--------------------------------------------------------------------------------
Customer firstly found this problem on XLP108 board, and then they verified on their XLP764 and XLP208 reference board, all they have the same problem. They use the default rootfs and no their private applications running.
And it don't related with the customer's test application.
They tried to debug other application with gdb, the same problem also happens.
I have tested target gdb on our vlm XLP9 board, I can't reproduce this problem.
I found that on WRlinux6.0 release version, we fixed a similar defect:
LIN6-855.
I talked with Jin Yanjiang about this defect, he send me the patch:
[PATCH] bcm-xlp: implement flush_cache_page
I can see the patch is applied on WRlinux6.0.0.5.
I can't get XLP208 to verify this issue.
Please help to verify if this problem can be reproduced on XLP208 board.
1. customer configure project with the following options :
/wrlinux-6/wrlinux/configure --enable-board=bcm-xlp --enable-build=production --enable-kernel=standard --enable-rootfs=glibc_std --with-template=feature/readonly-root,feature/debug --enable-sdkimage-staticlibs=yes --enable-reconfig=yes --with-rcpl-version=0005
2. Customer just set breakpoint in gdb and run application , the kernel crashed.
----------------------------------------------------------------------------------------
root@localhost:/mnt/sd/gdbtest# gdb
GNU gdb (Wind River Linux Sourcery CodeBench 4.8-30) 7.6
Copyright (C) 2013 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law. Type "show copying"
and "show warranty" for details.
This GDB was configured as "mips64-wrs-linux-gnu".
For bug reporting instructions, please see:
<support@windriver.com>.
(gdb) file uart_test
Reading symbols from /mnt/sd/gdbtest/uart_test...done.
(gdb) b main
Breakpoint 1 at 0x120001d4c: file uart_test.c, line 362.
(gdb) b test_f_port
Breakpoint 2 at 0x1200011a0: file uart_test.c, line 111.
(gdb) run
Starting program: /mnt/sd/gdbtest/uart_test
Program received signal SIGTRAP, Trace/breakpoint trap.
0x00000083cea54348 in ?? () from /lib64/ld.so.1
---------------------------------------------------------------------------
run application in gdb,the following kernel bug log printed:
-------------------------------------------------------------------------------------
BUG: using smp_processor_id() in preemptible [00000000] code: gdb/987
caller is ptrace_get_watch_regs+0x48/0x218
CPU: 2 PID: 987 Comm: gdb Tainted: G O 3.10.19-WR6.0.0.5_standard #13
Stack : c0000000f8e08320 00000000000003db 0000000000000002 00000001205745f0
0000000120649e00 0000000000000038 ffffffffc06b8370 0000000000000001
c0000000ec35fbf8 c0000000ec350000 c0000000ec35fc98 c0000000ec35fc98
ffffffffc09eee1c 000000007400f8e3 0000000000000000 00000258012b6a00
0000000000000000 0000000040808000 ffffffffc09eee1c 0000000000000000
0000000000000000 0000000000000000 0000000000000000 0000000000000000
0000000000000000 0000000000000000 0000000000000000 00000000f0000000
c0000000ec35fc98 c0000000ec35fba8 c0000000ec35fcc0 ffffffffc06616e4
c0000000ec35fcf8 ffffffffc022a668 c0000000f8e07f80 ffffffffc0b16c78
0000000000000002 ffffffffc01fa9d0 0000000000000000 0000000000000000
...
Call Trace:
[<ffffffffc01fa9d0>] show_stack+0xd8/0xf8
[<ffffffffc06616e4>] debug_smp_processor_id+0xf4/0x110
[<ffffffffc01f7f98>] ptrace_get_watch_regs+0x48/0x218
[<ffffffffc01f8540>] arch_ptrace+0x130/0x500
[<ffffffffc02376f0>] SyS_ptrace+0xa0/0x198
[<ffffffffc0200844>] handle_sys64+0x44/0x68
BUG: using smp_processor_id() in preemptible [00000000] code: gdb/987
caller is ptrace_get_watch_regs+0x94/0x218
CPU: 2 PID: 987 Comm: gdb Tainted: G O 3.10.19-WR6.0.0.5_standard #13
Stack : c0000000ec35fbb8 0000000040808000 ffffffffc0228b2c 0000000000000000
0000000000000000 0000000000000000 0000000000000000 0000000000000000
0000000000000000 0000000000000000 0000000000000000 00000000f0000000
c0000000ec35fc18 ffffffffc0228b1c 0000000000000000 0000000000000000
0000000000000000 ffffffffc1010000 ffffffffc100cea8 ffffffffc1010000
ffffffffc0b16c78 ffffffffc0cbaad7 ffffffffc100cea8 c0000000f8e08320
00000000000003db 0000000000000002 ffffffffc0ca8320 0000000120649e00
c0000000ec35fc98 c0000000ec35fba8 c0000000ec35fcc0 ffffffffc06616e4
c0000000ec35fcf8 ffffffffc022a668 c0000000f8e07f80 ffffffffc0b16c78
0000000000000002 ffffffffc01fa9d0 0000000000000000 0000000000000000
...
Call Trace:
[<ffffffffc01fa9d0>] show_stack+0xd8/0xf8
[<ffffffffc06616e4>] debug_smp_processor_id+0xf4/0x110
[<ffffffffc01f7fe4>] ptrace_get_watch_regs+0x94/0x218
[<ffffffffc01f8540>] arch_ptrace+0x130/0x500
[<ffffffffc02376f0>] SyS_ptrace+0xa0/0x198
[<ffffffffc0200844>] handle_sys64+0x44/0x68
-------------------------------------------------------------------------
It seems not related with the customer's test application.
They tried to debug other application with gdb, the same problem also happens.
Attached is customer's application they debug with gdb.
I use this program on XLP9 board in VLM, can't reproduce this problem.
But customer found the problem on XLP108, XLP208 and XLP764 board.
