Wind River Support Network

HomeDefectsLIN5-19376
Fixed

LIN5-19376 : gdb can't work: BUG: using smp_processor_id() in preemptible

Created: Sep 3, 2014    Updated: Dec 19, 2017
Resolved Date: Sep 4, 2014
Found In Version: 5.0.1
Severity: Severe
Applicable for: Wind River Linux 5
Component/s: BSP

Description

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.

Steps to Reproduce

The following is the original report on WR6, and we can reproduce same problem on WR5 with bcm-xlp BSP.


1. customer configure project with the following options :
/WindRiver/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.

Other Downloads


Live chat
Online