[#4440] start kgdb through uart1 sometimes would make kernel panic

Document created by Aaronwu Employee on Aug 29, 2013
Version 1Show Document
  • View in full screen mode

[#4440] start kgdb through uart1 sometimes would make kernel panic

Submitted By: Mingquan Pan

Open Date

2008-09-24 03:21:12     Close Date

2008-12-03 05:06:53

Priority:

Medium     Assignee:

Sonic Zhang

Status:

Closed     Fixed In Release:

N/A

Found In Release:

N/A     Release:

Category:

N/A     Board:

N/A

Processor:

N/A     Silicon Revision:

Is this bug repeatable?:

Yes     Resolution:

Fixed

Uboot version or rev.:

    Toolchain version or rev.:

trunk Sep 21

App binary format:

N/A     

Summary: start kgdb through uart1 sometimes would make kernel panic

Details:

 

start kgdb through uart1 sometimes would make kernel panic.

 

test@uclinux50-bf537-stamp-cf:~/work/cruise/checkouts/uclinux-dist/testsuites/kgdb> /opt/uClinux/bfin-uclinux/bin/bfin-uclinux-gdb ../../linux-2.6.x/vmlinux

GNU gdb 6.6

Copyright (C) 2006 Free Software Foundation, Inc.

GDB is free software, covered by the GNU General Public License, and you are

welcome to change it and/or distribute copies of it under certain conditions.

Type "show copying" to see the conditions.

There is absolutely no warranty for GDB.  Type "show warranty" for details.

This GDB was configured as "--host=i686-pc-linux-gnu --target=bfin-uclinux"...

(gdb) set remotebaud 57600

(gdb) target remote /dev/ttyUSB0

Remote debugging using /dev/ttyUSB0

 

 

Ignoring packet error, continuing...

warning: unrecognized item "timeout" in "qSupported" response

Ignoring packet error, continuing...

 

 

On target:

 

BusyBox v1.11.1 (2008-09-21 04:20:39 CST) built-in shell (msh)

Enter 'help' for a list of built-in commands.

 

root:/> SysRq : GDB

Entering KGDB

 

root:/> init: /bin/watchdogd respawning too fast

NULL pointer access

Kernel OOPS in progress

Deferred Exception context

 

No Valid process in current context

return address: [0x000a3d00]; contents of:

0x000a3ce0:  e10a  5a88  9111  e428  001c  0801  18a2  0000

0x000a3cf0:  0000  0000  ae28  60f0  5403  565a  57c8  4827

0x000a3d00: [9105] 1c1c  e52a  0014  e428  0012  6408  e628

0x000a3d10:  0012  0c42  180d  0000  0000  0000  e551  0015

 

SEQUENCER STATUS:               Not tainted

SEQSTAT: 00060027  IPEND: 8430  SYSCFG: 0006

  EXCAUSE   : 0x27

  physical IVG10 asserted : <0xffa00e10> { _evt_evt10 + 0x0 }

  physical IVG15 asserted : <0xffa00e40> { _evt_system_call + 0x0 }

  logical irq   6 mapped  : <0xffa00388> { _timer_interrupt + 0x0 }

  logical irq  10 mapped  : <0x000b5cec> { _bfin_rtc_interrupt + 0x0 }

  logical irq  18 mapped  : <0x000a3c94> { _bfin_serial_rx_int + 0x0 }

  logical irq  19 mapped  : <0x000a3ee4> { _bfin_serial_tx_int + 0x0 }

  logical irq  20 mapped  : <0x000a3c94> { _bfin_serial_rx_int + 0x0 }

  logical irq  21 mapped  : <0x000a3ee4> { _bfin_serial_tx_int + 0x0 }

  logical irq  24 mapped  : <0x000acba4> { _bfin_mac_interrupt + 0x0 }

RETE: <0x00000000> { _run_init_process + 0xfffff000 }

RETN: <0x00189e00> /* kernel dynamic memory */

RETX: <0x00000480> /* Maybe fixed code section */

RETS: <0x00031a4e> { _handle_IRQ_event + 0x3a }

PC  : <0x000a3d00> { _bfin_serial_rx_int + 0x6c }

DCPLB_FAULT_ADDR: <0x00000000> { _run_init_process + 0xfffff000 }

ICPLB_FAULT_ADDR: <0x0000001f> /* Maybe null pointer? */

 

PROCESSOR STATE:

R0 : 00000000    R1 : 00000061    R2 : 00000000    R3 : 00000061

R4 : 00000000    R5 : 00000014    R6 : 00000024    R7 : 00000061

P0 : 00000000    P1 : ffc02000    P2 : 0016e52c    P3 : 00164d60

P4 : 00000014    P5 : 001759fc    FP : 00189e14    SP : 00189d24

LB0: ffa018f0    LT0: ffa018ee    LC0: 00000000

LB1: 00190a9f    LT1: 00190a9e    LC1: 00000000

B0 : 00000000    L0 : 00000000    M0 : 00000000    I0 : 0019605c

B1 : 00000000    L1 : 00000000    M1 : 00000000    I1 : 00000000

B2 : 00000000    L2 : 00000000    M2 : 00000000    I2 : 00000000

B3 : 00000000    L3 : 00000000    M3 : 00000000    I3 : 00000000

A0.w: 000fffff   A0.x: 00000000   A1.w: 00000290   A1.x: 00000000

USP : 0018a000  ASTAT: 02002020

 

Hardware Trace:

 

Kernel Stack

Stack info:

SP: [0x00189f38] <0x00189f38> /* kernel dynamic memory */

FP: (0x00189f90)

Memory from 0x00189f30 to 0018a000

00189f30: 00000000  00000000 [00000000] 00000000  0019605c  0018a000  00189f90  ffa00258

00189f50: 00188000  00164d60  0017a668  00188000  ffa009e8  001644c4  0017a668  00000000

00189f70: 00000000  00000065  0000001f  00000002  0000ffff  0000ffff  ffa009e8  00000006

00189f90:(00189fa4)<ffa0023c><0010e018> 0017401c  001a2d7c (00189fc4)<0010e01c> 0017401c

00189fb0: 001a2d7c  001644d0  00000004  00040000  00189fe4 (00189fe4) 0018a8a2  00000000

00189fd0: 001a2d7c  00164350  00000011  0018a108  001a4dd4 (0018a000) 001983c6  00000000

00189ff0: 00000000  00000000  ffb00000  00000000 (00000044)

Return addresses in stack:

   frame  1 : <0xffa0023c> { _cpu_idle + 0x20 }

    address : <0x0010e018> { _rest_init + 0x50 }

   frame  2 : <0x0010e01c> { _rest_init + 0x54 }

Modules linked in:

Kernel panic - not syncing: Kernel exception

 

 

Follow-ups

 

--- Sonic Zhang                                              2008-09-25 05:02:10

Fixed.

 

--- Mingquan Pan                                             2008-12-03 05:06:53

Yeah, it is not seen now.Close.

 

 

 

    Files

    Changes

    Commits

    Dependencies

    Duplicates

    Associations

    Tags

 

File Name     File Type     File Size     Posted By

No Files Were Found

Attachments

    Outcomes