From owner-freebsd-arm@FreeBSD.ORG Wed Jul 31 19:46:08 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 94CD29E1; Wed, 31 Jul 2013 19:46:08 +0000 (UTC) (envelope-from hans.petter.selasky@bitfrost.no) Received: from mta.bitpro.no (mta.bitpro.no [92.42.64.202]) by mx1.freebsd.org (Postfix) with ESMTP id 16CE024AA; Wed, 31 Jul 2013 19:46:07 +0000 (UTC) Received: from mail.lockless.no (mail.lockless.no [46.29.221.38]) by mta.bitpro.no (Postfix) with ESMTP id 3B7477A13E; Wed, 31 Jul 2013 21:46:07 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by mail.lockless.no (Postfix) with ESMTP id 0129C8F0EC1; Wed, 31 Jul 2013 21:46:13 +0200 (CEST) X-Virus-Scanned: by amavisd-new-2.6.4 (20090625) (Debian) at lockless.no Received: from mail.lockless.no ([127.0.0.1]) by localhost (mail.lockless.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VuCmYRxCY3fA; Wed, 31 Jul 2013 21:46:12 +0200 (CEST) Received: from mail.lockless.no (localhost [127.0.0.1]) by mail.lockless.no (Postfix) with ESMTP id 0DCD88F0EC0; Wed, 31 Jul 2013 21:46:12 +0200 (CEST) Subject: RE: My WLI-UC-GNM up crash From: =?utf-8?Q?Hans_Petter_Selasky?= To: =?utf-8?Q?Adrian_Chadd?= , =?utf-8?Q?Ian_Lepore?= Date: Wed, 31 Jul 2013 21:46:11 +0200 Mime-Version: 1.0 In-Reply-To: References: X-Priority: 3 (Normal) X-Mailer: Zarafa 7.1.4-41394 Message-Id: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.14 Cc: =?utf-8?Q?freebsd-arm?= , =?utf-8?Q?freebsd-wireless=40freebsd=2Eorg?= 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: Wed, 31 Jul 2013 19:46:08 -0000 Hi,=0D=0A=0D=0ATypically this means the USB firmware died, or some comman= d needs to be re-transmitted.=0D=0A=0D=0ASee:=0D=0A=0D=0Ausbdump -i usbus= X -s 65536=0D=0A=0D=0AWhat is really going on.=0D=0A=0D=0A--HPS=0D=0A=20=0D= =0A=20=0D=0A-----Original message-----=0D=0A> From:Adrian Chadd >=0D=0A> Sent: Wednesday 31st July= 2013 20:03=0D=0A> To: Ian Lepore >=0D=0A> Cc: freebsd-arm >; freebsd-wireless@freebsd.org ; Hans Petter Selasky >=0D=0A> Subject: Re: My WLI-UC-GNM up c= rash=0D=0A>=20=0D=0A> No idea about the device disconnect, sorry. is it a= power draw problem=3F=0D=0A>=20=0D=0A>=20=0D=0A> -adrian=0D=0A>=20=0D=0A= > On 31 July 2013 06:41, Ian Lepore > wrote:=0D=0A> > On Wed, 2013-07-31 at 16:28 +0800, XiaoQI Ge wrote= :=0D=0A> >> Last night, I use the latest FreeBSD source (r253827) and=0D=0A= > >> crochet-freebsd compile img=0D=0A> >> My WLI-UC-GNM will be disconne= cted after a period of operation=0D=0A> >>=0D=0A> >> run0: device timeout= =0D=0A> >> run0: at uhub0, port 1, addr 2 (disconnected)=0D=0A> >>=0D=0A>= >> Another log prompted=0D=0A> >> ti_mmchs0: Error: current cmd NULL, al= ready done=3F=0D=0A> >>=0D=0A> >> My BB-Black broken=3F=0D=0A> >=0D=0A> >= The ti_mmchs0 error is not new. My old BBW has done that for months.=0D= =0A> > I'm not sure it's totally harmless, but it's not related to the ru= n0=0D=0A> > timeouts.=0D=0A> >=0D=0A> > -- Ian=0D=0A> >=0D=0A> > ________= _______________________________________=0D=0A> > freebsd-arm@freebsd.org = mailing list=0D=0A> > http://lists.free= bsd.org/mailman/listinfo/freebsd-arm =20=0D=0A> > To unsubscribe, send any mail to "freebsd= -arm-unsubscribe@freebsd.org = "=0D=0A> _______________________________________________=0D=0A> freebsd-= arm@freebsd.org mailing list=0D=0A> htt= p://lists.freebsd.org/mailman/listinfo/freebsd-arm =20=0D=0A> To unsubscribe, send any mail= to "freebsd-arm-unsubscribe@freebsd.org "=0D=0A>=20=0D=0A=0D=0A From owner-freebsd-arm@FreeBSD.ORG Wed Jul 31 22:31:58 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 AAFB0285 for ; Wed, 31 Jul 2013 22:31:58 +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 6D5BA2A7A for ; Wed, 31 Jul 2013 22:31:57 +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 1V4evu-0003aQ-Iv; Wed, 31 Jul 2013 22:31:51 +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 r6VMVluu020476; Wed, 31 Jul 2013 16:31:47 -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: U2FsdGVkX19h+xsOjdxGvlD2UeNw/jjw Subject: Re: Kernel Panic on DREAMPLUG: Alignment Fault 1 From: Ian Lepore To: Mattia Rossi In-Reply-To: <51F92F79.9010809@gmail.com> References: <51F92F79.9010809@gmail.com> Content-Type: text/plain; charset="us-ascii" Date: Wed, 31 Jul 2013 16:31:47 -0600 Message-ID: <1375309907.45247.185.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: Wed, 31 Jul 2013 22:31:58 -0000 On Wed, 2013-07-31 at 17:38 +0200, Mattia Rossi wrote: > Hi all, > > this might be related to the WLI-UC-GNM Alignment Fault, but definitely > has nothing to do with Wireless LAN. > It rather seems that there's a problem with the USB subsystem. > > See dmesg an backtrace below. > > ## Starting application at 0x00900000 ... > KDB: debugger backends: ddb > KDB: current backend: ddb > Copyright (c) 1992-2013 The FreeBSD Project. > Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 > The Regents of the University of California. All rights reserved. > FreeBSD is a registered trademark of The FreeBSD Foundation. > FreeBSD 10.0-CURRENT #9 r253846M: Wed Jul 31 17:24:31 CEST 2013 > root@freebsd9.1-base:/usr/obj/arm.arm/usr/devel/dreamplug/sys/DREAMPLUG-100m > FreeBSD clang version 3.3 (tags/RELEASE_33/final 183502) 20130610 > WARNING: DIAGNOSTIC option enabled, expect reduced performance. > CPU: Feroceon 88FR131 rev 1 (Marvell core) > Little-endian DC enabled IC enabled WA disabled DC streaming enabled > BTB disabled L2 enabled L2 prefetch enabled > WB enabled EABT branch prediction enabled > 16KB/32B 4-way instruction cache > 16KB/32B 4-way write-back-locking-C data cache > real memory = 536870912 (512 MB) > avail memory = 510828544 (487 MB) > SOC: Marvell 88F6281 rev A1, TClock 200MHz > Instruction cache prefetch disabled, data cache prefetch disabled > 256KB 4-way set-associative write-through unified L2 cache > random device not loaded; using insecure entropy > localbus0: on fdtbus0 > simplebus0: on fdtbus0 > ic0: mem 0xf1020200-0xf102023b > on sim0 > timer0: mem 0xf1020300-0xf102032f irq 1 on simplebus0 > Event timer "CPUTimer0" frequency 200000000 Hz quality 1000 > Timecounter "CPUTimer1" frequency 200000000 Hz quality 1000 > gpio0: mem 0xf1010100-0xf101011f > irq 35,360 > rtc0: mem 0xf1010300-0xf1010307 on simplebus0 > twsi0: mem 0xf1011000-0xf101101f > irq 430 > iicbus0: on twsi0 > iic0: on iicbus0 > mge0: mem 0xf1072000-0xf1073fff > irq 12,130 > mge0: Ethernet address: f0:ad:4e:00:84:c7 > miibus0: on mge0 > e1000phy0: PHY 0 on miibus0 > e1000phy0: none, 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, > 1000baseT, 10o > mge1: mem 0xf1076000-0xf1077fff > irq 16,170 > mge1: Ethernet address: f0:ad:4e:00:84:c8 > miibus1: on mge1 > e1000phy1: PHY 1 on miibus1 > e1000phy1: none, 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, > 1000baseT, 10o > uart0: <16550 or compatible> mem 0xf1012000-0xf101201f irq 33 on simplebus0 > uart0: console (1056,n,8,1) > uart1: <16550 or compatible> mem 0xf1012100-0xf101211f irq 34 on simplebus0 > cesa0: mem > 0xf1030000-00 > ehci0: mem 0xf1050000-0xf1050fff > irq 480 > usbus0: EHCI version 1.0 > usbus0: set host controller mode > usbus0 on ehci0 > mvs0: mem 0xf1080000-0xf1085fff irq 21 > on sim0 > mvs0: Gen-IIe, 2 3Gbps ports, Port Multiplier supported with FBS > mvsch0: at channel 0 on mvs0 > mvsch1: at channel 1 on mvs0 > cryptosoft0: > Timecounters tick every 10.000 msec > IPsec: Initialized Security Association Processing. > ipfw2 (+ipv6) initialized, divert enabled, nat enabled, default to > accept, loggd > DUMMYNET 0 with IPv6 initialized (100409) > load_dn_sched dn_sched FIFO loaded > load_dn_sched dn_sched PRIO loaded > load_dn_sched dn_sched QFQ loaded > load_dn_sched dn_sched RR loaded > load_dn_sched dn_sched WF2Q+ loaded > usbus0: 480Mbps High Speed USB v2.0 > Fatal kernel mode data abort: 'Alignment Fault 1' > trapframe: 0xde472b48 > FSR=00000001, FAR=de472bc4, spsr=60000093 > r0 =001e48e5, r1 =ffffffff, r2 =0000001c, r3 =001e48e5 > r4 =de472bbc, r5 =de472bc4, r6 =c3598c80, r7 =c0e7c830 > r8 =798ee230, r9 =00000015, r10=00000001, r11=de472bb4 > r12=c0d240e8, ssp=de472b94, slr=c0d44c6c, pc =c0ab8264 > > [ thread pid 5 tid 100036 ] > Stopped at binuptime+0x70: und 0xe1c500d0 > db> bt > Tracing pid 5 tid 100036 td 0xc3598c80 > db_trace_self() at db_trace_self > pc = 0xc0d2807c lr = 0xc0941d84 (db_hex2dec+0x4d8) > sp = 0xde472840 fp = 0xde472858 > r10 = 0xc0e59e60 > db_hex2dec() at db_hex2dec+0x4d8 > pc = 0xc0941d84 lr = 0xc09416f4 (db_command_loop+0x2f4) > sp = 0xde472860 fp = 0xde472900 > r4 = 0x00000000 r5 = 0x00000000 > r6 = 0xc0d9e9fc > db_command_loop() at db_command_loop+0x2f4 > pc = 0xc09416f4 lr = 0xc0941450 (db_command_loop+0x50) > sp = 0xde472908 fp = 0xde472918 > r4 = 0xc0d7bae3 r5 = 0xc0d98378 > r6 = 0xc0ebbdb8 r7 = 0xde472b48 > r8 = 0xde472b48 r9 = 0xc0eb0614 > r10 = 0xc0e5a0d0 > db_command_loop() at db_command_loop+0x50 > pc = 0xc0941450 lr = 0xc0943e68 (X_db_symbol_values+0x254) > sp = 0xde472920 fp = 0xde472a40 > r4 = 0x00000000 r5 = 0xde472928 > r6 = 0xc0eb0638 > X_db_symbol_values() at X_db_symbol_values+0x254 > pc = 0xc0943e68 lr = 0xc0adf580 (kdb_trap+0xd4) > sp = 0xde472a48 fp = 0xde472a68 > r4 = 0x00000000 r5 = 0x00000001 > r6 = 0xc0eb0638 r7 = 0xde472b48 > kdb_trap() at kdb_trap+0xd4 > pc = 0xc0adf580 lr = 0xc0d38810 (data_abort_handler+0x640) > sp = 0xde472a70 fp = 0xde472a88 > r4 = 0xde472b48 r5 = 0x600000d3 > r6 = 0xde472bc4 r7 = 0x00000001 > r8 = 0xde472b48 r9 = 0xde472bc4 > r10 = 0x00000001 > data_abort_handler() at data_abort_handler+0x640 > pc = 0xc0d38810 lr = 0xc0d39208 (swi_handler+0x548) > sp = 0xde472a90 fp = 0xde472a98 > r4 = 0x00000001 r5 = 0xc3598c80 > r6 = 0xc3598c80 r7 = 0xc0d39194 > swi_handler() at swi_handler+0x548 > pc = 0xc0d39208 lr = 0xc0d3854c (data_abort_handler+0x37c) > sp = 0xde472aa0 fp = 0xde472b40 > data_abort_handler() at data_abort_handler+0x37c > pc = 0xc0d3854c lr = 0xc0d29924 (exception_exit) > sp = 0xde472b48 fp = 0xde472bb4 > r4 = 0xffffffff r5 = 0xffff1004 > r6 = 0xc3598c80 r7 = 0xc0e7c830 > r8 = 0x798ee230 r9 = 0x00000015 > r10 = 0x00000001 > exception_exit() at exception_exit > pc = 0xc0d29924 lr = 0xc0d44c6c (DELAY+0x764) > sp = 0xde472b94 fp = 0xde472bb4 > r0 = 0x001e48e5 r1 = 0xffffffff > r2 = 0x0000001c r3 = 0x001e48e5 > r4 = 0xde472bbc r5 = 0xde472bc4 > r6 = 0xc3598c80 r7 = 0xc0e7c830 > r8 = 0x798ee230 r9 = 0x00000015 > r10 = 0x00000001 r12 = 0xc0d240e8 > binuptime() at binuptime+0x74 > pc = 0xc0ab8268 lr = 0xc0d503ec (cpu_initclocks_bsp+0x41c) > sp = 0xde472bbc fp = 0xde472bd4 > r4 = 0x00000003 r5 = 0x00033940 > r6 = 0xc3598c80 r7 = 0xc0d92761 > r8 = 0xc0d9273a r9 = 0x00000000 > r10 = 0xc3586ac0 > cpu_initclocks_bsp() at cpu_initclocks_bsp+0x41c > pc = 0xc0d503ec lr = 0xc0d44af8 (DELAY+0x5f0) > sp = 0xde472bdc fp = 0xde472be4 > r4 = 0xc352d400 r5 = 0xde472c34 > DELAY() at DELAY+0x5f0 > pc = 0xc0d44af8 lr = 0xc0a82468 (intr_event_handle+0x88) > sp = 0xde472bec fp = 0xde472c14 > r4 = 0xc341e400 > intr_event_handle() at intr_event_handle+0x88 > pc = 0xc0a82468 lr = 0xc0d2acac (arm_handler_execute+0x54) > sp = 0xde472c1c fp = 0xde472c2c > r4 = 0xde472c34 r5 = 0x00000001 > r6 = 0xc0e97c40 r7 = 0xc0eb90d8 > r8 = 0xc352c200 r9 = 0xc37a1000 > r10 = 0xc37a1000 > arm_handler_execute() at arm_handler_execute+0x54 > pc = 0xc0d2acac lr = 0xc0d3e2dc (irq_entry+0x94) > sp = 0xde472c34 fp = 0xde472c90 > r4 = 0x00000000 r5 = 0xffff1004 > r6 = 0xc0ebbc50 r7 = 0x00004c5f > irq_entry() at irq_entry+0x94 > pc = 0xc0d3e2dc lr = 0xc0d3e2dc (irq_entry+0x94) > sp = 0xde472c34 fp = 0xde472c90 > Unwind failure (no registers changed) > db> > > > Usually this is the USB bit that follows the usbus0 line: > > ugen0.1: at usbus0 > uhub0: on usbus0 > WARNING: DIAGNOSTIC option enabled, expect reduced performance. > uhub0: 1 port with 1 removable, self powered > Root mount waiting for: usbus0 > ugen0.2: at usbus0 > uhub1: on > usbus0 > Root mount waiting for: usbus0 > uhub1: 4 ports with 4 removable, self powered > Root mount waiting for: usbus0 > Root mount waiting for: usbus0 > ugen0.3: at usbus0 > umass0: > on usbus0 > da0 at umass-sim0 bus 0 scbus2 target 0 lun 0 > da0: Removable Direct Access SCSI-0 device > da0: 40.000MB/s transfers > da0: 1876MB (3842048 512 byte sectors: 255H 63S/T 239C) > da0: quirks=0x3 > da1 at umass-sim0 bus 0 scbus2 target 0 lun 1 > da1: Removable Direct Access SCSI-0 device > da1: 40.000MB/s transfers > da1: 974MB (1995264 512 byte sectors: 64H 32S/T 974C) > da1: quirks=0x3 > Root mount waiting for: usbus0 > ugen0.4: at usbus0 > umass1: 2.00/1.00, a0 > da2 at umass-sim1 bus 1 scbus3 target 0 lun 0 > da2: Removable Direct Access SCSI-2 device > da2: 40.000MB/s transfers > da2: 1967MB (4030463 512 byte sectors: 255H 63S/T 250C) > da2: quirks=0x2 > ugen0.5: at usbus0 > > Currently trying to find where the issue could be. > > Mat This is a strange abort, and if it's usb-related that's only accidental I think. It says it's an alignment fault, but the fault address reg has a 32-bit aligned value in it. That makes me think it must be an ldrd/strd instruction (requires 64-bit alignment) that's faulting. Is this compiled with clang? I think it emits such instructions and gcc doesn't. Except I don't think clang should use those instructions on armv5, because of the alignment requirements. -- Ian