BBB triggered trap when disconnecting uart
Ian Lepore
ian at FreeBSD.org
Tue Oct 15 18:28:25 UTC 2013
On Wed, 2013-10-16 at 02:18 +0800, Jia-Shiun Li wrote:
> I originally thought it hanged when I unplug my USB-serial dongle (a
> PL2303-based one on Windows). But looking closely I found it was
> actually dropping to ddb, because if pressed Enter in terminal window
> it will continue. And I got the following back trace. Is it possible
> the USB-serial chip or term (putty) sent garbage chars to trigger it,
> or simply because something went wrong in uart_intr?
>
> The behavior is reproducible. Also happens when I suspend/resume PC.
> And system is
>
> FreeBSD beaglebone 10.0-ALPHA4 FreeBSD 10.0-ALPHA4 #0 r256041: Fri Oct
> 4 16:13:26 CST 2013
> jsli at 4cbsd:/root/crochet-freebsd/work/obj/arm.armv6/usr/src/sys/BEAGLEBONE
> arm
>
>
> ---- 9< --------- 9< --------- 9< -----
> t
> Tracing pid 65332 tid 100108 td 0xc4d9f960
> db_trace_self() at db_trace_self
> pc = 0xc052f8fc lr = 0xc022c128 (db_stack_trace+0xf4)
> sp = 0xde9467a0 fp = 0xde9467b8
> r10 = 0xc0626900
> db_stack_trace() at db_stack_trace+0xf4
> pc = 0xc022c128 lr = 0xc022ba94 (db_command+0x264)
> sp = 0xde9467c0 fp = 0xde946860
> r4 = 0x00000000 r5 = 0x00000000
> r6 = 0xc059b343
> db_command() at db_command+0x264
> pc = 0xc022ba94 lr = 0xc022b804 (db_command_loop+0x60)
> sp = 0xde946868 fp = 0xde946878
> r4 = 0xc0571596 r5 = 0xc058b91b
> r6 = 0xc07ccbb0 r7 = 0xde946a48
> r8 = 0xc4d9f960 r9 = 0xc0669a04
> r10 = 0xc0626b70
> db_command_loop() at db_command_loop+0x60
> pc = 0xc022b804 lr = 0xc022e204 (db_trap+0xdc)
> sp = 0xde946880 fp = 0xde9469a0
> r4 = 0x00000000 r5 = 0xde946888
> r6 = 0xc0669a30
> db_trap() at db_trap+0xdc
> pc = 0xc022e204 lr = 0xc038f5bc (kdb_trap+0xd4)
> sp = 0xde9469a8 fp = 0xde9469c8
> r4 = 0x00000000 r5 = 0x00000001
> r6 = 0xc0669a30 r7 = 0xde946a48
> kdb_trap() at kdb_trap+0xd4
> pc = 0xc038f5bc lr = 0xc0541e70 (undefinedinstruction+0x2b0)
> sp = 0xde9469d0 fp = 0xde946a40
> r4 = 0x00000000 r5 = 0xc0541b1c
> r6 = 0x00000000 r7 = 0xe7ffffff
> r8 = 0xc4d9f960 r9 = 0xde946a48
> r10 = 0xc038ee34
> undefinedinstruction() at undefinedinstruction+0x2b0
> pc = 0xc0541e70 lr = 0xc0531134 (exception_exit)
> sp = 0xde946a48 fp = 0xde946aa0
> r4 = 0x00000001 r5 = 0xc27d4a00
> r6 = 0x00060000 r7 = 0xc062ba1c
> r8 = 0xc27d4b74 r9 = 0x0000ff7f
> r10 = 0x00000000
> exception_exit() at exception_exit
> pc = 0xc0531134 lr = 0xc038ee24 (kdb_break+0x50)
> sp = 0xde946a9c fp = 0xde946aa0
> r0 = 0xc0669a14 r1 = 0xc057168a
> r2 = 0x00000000 r3 = 0x60000193
> r4 = 0x00000001 r5 = 0xc27d4a00
> r6 = 0x00060000 r7 = 0xc062ba1c
> r8 = 0xc27d4b74 r9 = 0x0000ff7f
> r10 = 0x00000000 r12 = 0x00000000
> $a() at $a
> pc = 0xc038ee38 lr = 0xc025df78 (uart_intr+0xa4)
> sp = 0xde946aa8 fp = 0xde946ae8
> r4 = 0xc264ed00
> uart_intr() at uart_intr+0xa4
> pc = 0xc025df78 lr = 0xc032b594 (intr_event_handle+0x84)
> sp = 0xde946af0 fp = 0xde946b18
> r4 = 0xc264ed00 r5 = 0xde946b38
> r6 = 0xc4d9f960 r7 = 0xc0585a55
> r8 = 0xc0585a2e r9 = 0x00000000
> r10 = 0xc27c2bc0
> intr_event_handle() at intr_event_handle+0x84
> pc = 0xc032b594 lr = 0xc0532350 (arm_handler_execute+0x50)
> sp = 0xde946b20 fp = 0xde946b30
> r4 = 0xde946b38 r5 = 0x00000048
> r6 = 0xc0652420 r7 = 0xc07ca0d8
> r8 = 0x20a87000 r9 = 0x00000000
> r10 = 0x00000953
> arm_handler_execute() at arm_handler_execute+0x50
> pc = 0xc0532350 lr = 0xc054fcc8 (irq_entry+0x6c)
> sp = 0xde946b38 fp = 0xde946bc8
> r4 = 0xc09b7a30 r5 = 0xc05afd2b
> r6 = 0xc05afd2b r7 = 0xc09b7a30
> irq_entry() at irq_entry+0x6c
> pc = 0xc054fcc8 lr = 0xc0360970 (_sx_sunlock+0x74)
> sp = 0xde946b8c fp = 0xde946bc8
> r0 = 0x00000000 r1 = 0x00000000
> r2 = 0xc05afd2b r3 = 0x00000fe2
> r4 = 0xc09b7a30 r5 = 0xc05afd2b
> r6 = 0xc05afd2b r7 = 0xc09b7a30
> r8 = 0x20a87000 r9 = 0x00000000
> r10 = 0x00000953 r12 = 0x000000c0
> witness_unlock() at witness_unlock+0x48
> pc = 0xc03a9bf0 lr = 0xc0360970 (_sx_sunlock+0x74)
> sp = 0xde946bd0 fp = 0xde946bf0
> r4 = 0xc09b7a30 r5 = 0x00000fe2
> r6 = 0xc05afd2b r7 = 0xc09b7a40
> r8 = 0x20a87000 r9 = 0x00000000
> r10 = 0x00000953
> _sx_sunlock() at _sx_sunlock+0x74
> pc = 0xc0360970 lr = 0xc05108c0 (vm_map_lookup_done+0x44)
> sp = 0xde946bf8 fp = 0xde946bf8
> r4 = 0xde946d10 r5 = 0x00000000
> r6 = 0xc3fa1280 r7 = 0x20a88000
> vm_map_lookup_done() at vm_map_lookup_done+0x44
> pc = 0xc05108c0 lr = 0xc05062cc (unlock_and_deallocate+0xc8)
> sp = 0xde946c00 fp = 0xde946c10
> unlock_and_deallocate() at unlock_and_deallocate+0xc8
> pc = 0xc05062cc lr = 0xc0506180 ($a+0xfc)
> sp = 0xde946c18 fp = 0xde946d88
> r4 = 0xc05af61a r5 = 0x00000000
> r6 = 0xc3fa1280 r7 = 0x20a88000
> $a() at $a+0xfc
> pc = 0xc0506180 lr = 0xc0504580 (vm_fault+0x88)
> sp = 0xde946d90 fp = 0xde946db0
> r4 = 0xc09b79e0 r5 = 0x00000002
> r6 = 0xc4d9f960 r7 = 0x20a87000
> r8 = 0x00000000 r9 = 0x00000002
> r10 = 0xc07d0b88
> vm_fault() at vm_fault+0x88
> pc = 0xc0504580 lr = 0xc054089c (data_abort_handler+0x2a8)
> sp = 0xde946db8 fp = 0xde946e58
> r4 = 0xc4d9b000 r5 = 0xc4d9f960
> r6 = 0xc05b5d32 r7 = 0xc4d9b0ac
> r8 = 0xde946e60 r9 = 0xde946eb0
> r10 = 0xc09b79e0
> data_abort_handler() at data_abort_handler+0x2a8
> pc = 0xc054089c lr = 0xc0531134 (exception_exit)
> sp = 0xde946e60 fp = 0xbfffdeb0
> r4 = 0x20a87000 r5 = 0x00001000
> r6 = 0x204000c0 r7 = 0x00000138
> r8 = 0x00000000 r9 = 0x204000c8
> r10 = 0x20848080
> exception_exit() at exception_exit
> pc = 0xc0531134 lr = 0x000c5fc8 (0xc5fc8)
> sp = 0xde946eb4 fp = 0xbfffdeb0
> r0 = 0x20a87000 r1 = 0x00000f80
> r2 = 0xa5a5a5a5 r3 = 0xa5a5a5a5
> r4 = 0x20a87000 r5 = 0x00001000
> r6 = 0x204000c0 r7 = 0x00000138
> r8 = 0x00000000 r9 = 0x204000c8
> r10 = 0x20848080 r12 = 0x20a87000
> Unable to unwind into user mode
> db>
Is the usb adapter you're talking about your console cable? If so, I
wonder if unplugging it is sending an rs232 break (a long string of 0
bits) and that's dropping into the debugger? If that's the case, you
should be able to type "continue" at the db> prompt and everything will
resume running.
It used to be possible to disable an rs232 break but enable the
alt-break sequence. I'm not sure if that's still the case (too busy to
go code-spelunking at the moment).
-- Ian
More information about the freebsd-arm
mailing list