From owner-freebsd-arm@FreeBSD.ORG Tue Oct 15 18:28:25 2013 Return-Path: Delivered-To: freebsd-arm@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 28B255C8 for ; Tue, 15 Oct 2013 18:28:25 +0000 (UTC) (envelope-from ian@FreeBSD.org) Received: from mho-01-ewr.mailhop.org (mho-03-ewr.mailhop.org [204.13.248.66]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id E16672DD0 for ; Tue, 15 Oct 2013 18:28:24 +0000 (UTC) Received: from c-24-8-230-52.hsd1.co.comcast.net ([24.8.230.52] helo=damnhippie.dyndns.org) by mho-01-ewr.mailhop.org with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.72) (envelope-from ) id 1VW9Lt-0004DC-6M; Tue, 15 Oct 2013 18:28:17 +0000 Received: from [172.22.42.240] (revolution.hippie.lan [172.22.42.240]) by damnhippie.dyndns.org (8.14.3/8.14.3) with ESMTP id r9FISEO1027264; Tue, 15 Oct 2013 12:28:14 -0600 (MDT) (envelope-from ian@FreeBSD.org) X-Mail-Handler: Dyn Standard SMTP by Dyn X-Originating-IP: 24.8.230.52 X-Report-Abuse-To: abuse@dyndns.com (see http://www.dyndns.com/services/sendlabs/outbound_abuse.html for abuse reporting information) X-MHO-User: U2FsdGVkX196ziBHT0ezr99Tpbx9QUuy Subject: Re: BBB triggered trap when disconnecting uart From: Ian Lepore To: Jia-Shiun Li In-Reply-To: References: Content-Type: text/plain; charset="us-ascii" Date: Tue, 15 Oct 2013 12:28:14 -0600 Message-ID: <1381861694.42859.144.camel@revolution.hippie.lan> Mime-Version: 1.0 X-Mailer: Evolution 2.32.1 FreeBSD GNOME Team Port Content-Transfer-Encoding: 7bit Cc: "freebsd-arm@freebsd.org" X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Oct 2013 18:28:25 -0000 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@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