Date: Thu, 01 Aug 2013 04:29:46 +0200 From: Mattia Rossi <mattia.rossi.mate@gmail.com> To: Ian Lepore <ian@FreeBSD.org> Cc: freebsd-arm@FreeBSD.org Subject: Re: Kernel Panic on DREAMPLUG: Alignment Fault 1 Message-ID: <51F9C81A.7000106@gmail.com> In-Reply-To: <1375309907.45247.185.camel@revolution.hippie.lan> References: <51F92F79.9010809@gmail.com> <1375309907.45247.185.camel@revolution.hippie.lan>
index | next in thread | previous in thread | raw e-mail
On 01/08/13 00:31, Ian Lepore wrote: > 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: <Marvell device bus> on fdtbus0 >> simplebus0: <Flattened device tree simple bus> on fdtbus0 >> ic0: <Marvell Integrated Interrupt Controller> mem 0xf1020200-0xf102023b >> on sim0 >> timer0: <Marvell CPU Timer> mem 0xf1020300-0xf102032f irq 1 on simplebus0 >> Event timer "CPUTimer0" frequency 200000000 Hz quality 1000 >> Timecounter "CPUTimer1" frequency 200000000 Hz quality 1000 >> gpio0: <Marvell Integrated GPIO Controller> mem 0xf1010100-0xf101011f >> irq 35,360 >> rtc0: <Marvell Integrated RTC> mem 0xf1010300-0xf1010307 on simplebus0 >> twsi0: <Marvell Integrated I2C Bus Controller> mem 0xf1011000-0xf101101f >> irq 430 >> iicbus0: <Philips I2C bus> on twsi0 >> iic0: <I2C generic I/O> on iicbus0 >> mge0: <Marvell Gigabit Ethernet controller> mem 0xf1072000-0xf1073fff >> irq 12,130 >> mge0: Ethernet address: f0:ad:4e:00:84:c7 >> miibus0: <MII bus> on mge0 >> e1000phy0: <Marvell 88E1116R Gigabit PHY> PHY 0 on miibus0 >> e1000phy0: none, 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, >> 1000baseT, 10o >> mge1: <Marvell Gigabit Ethernet controller> mem 0xf1076000-0xf1077fff >> irq 16,170 >> mge1: Ethernet address: f0:ad:4e:00:84:c8 >> miibus1: <MII bus> on mge1 >> e1000phy1: <Marvell 88E1116R Gigabit PHY> 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: <Marvell Cryptographic Engine and Security Accelerator> mem >> 0xf1030000-00 >> ehci0: <Marvell Integrated USB 2.0 controller> mem 0xf1050000-0xf1050fff >> irq 480 >> usbus0: EHCI version 1.0 >> usbus0: set host controller mode >> usbus0 on ehci0 >> mvs0: <Marvell 88F6281 SATA controller> mem 0xf1080000-0xf1085fff irq 21 >> on sim0 >> mvs0: Gen-IIe, 2 3Gbps ports, Port Multiplier supported with FBS >> mvsch0: <Marvell SATA channel> at channel 0 on mvs0 >> mvsch1: <Marvell SATA channel> at channel 1 on mvs0 >> cryptosoft0: <software crypto> >> 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: <Marvell> at usbus0 >> uhub0: <Marvell EHCI root HUB, class 9/0, rev 2.00/1.00, addr 1> on usbus0 >> WARNING: DIAGNOSTIC option enabled, expect reduced performance. >> uhub0: 1 port with 1 removable, self powered >> Root mount waiting for: usbus0 >> ugen0.2: <vendor 0x1a40> at usbus0 >> uhub1: <vendor 0x1a40 USB 2.0 Hub, class 9/0, rev 2.00/1.11, addr 2> 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: <vendor 0x05e3> at usbus0 >> umass0: <vendor 0x05e3 USB Storage, class 0/0, rev 2.00/99.10, addr 3> >> on usbus0 >> da0 at umass-sim0 bus 0 scbus2 target 0 lun 0 >> da0: <Generic STORAGE DEVICE 9910> Removable Direct Access SCSI-0 device >> da0: 40.000MB/s transfers >> da0: 1876MB (3842048 512 byte sectors: 255H 63S/T 239C) >> da0: quirks=0x3<NO_SYNC_CACHE,NO_6_BYTE> >> da1 at umass-sim0 bus 0 scbus2 target 0 lun 1 >> da1: <Generic STORAGE DEVICE 9910> Removable Direct Access SCSI-0 device >> da1: 40.000MB/s transfers >> da1: 974MB (1995264 512 byte sectors: 64H 32S/T 974C) >> da1: quirks=0x3<NO_SYNC_CACHE,NO_6_BYTE> >> Root mount waiting for: usbus0 >> ugen0.4: <USBest Technology> at usbus0 >> umass1: <USBest Technology USB Mass Storage Device, class 0/0, rev >> 2.00/1.00, a0 >> da2 at umass-sim1 bus 1 scbus3 target 0 lun 0 >> da2: <USB USB2FlashStorage 0.00> Removable Direct Access SCSI-2 device >> da2: 40.000MB/s transfers >> da2: 1967MB (4030463 512 byte sectors: 255H 63S/T 250C) >> da2: quirks=0x2<NO_6_BYTE> >> ugen0.5: <vendor 0x0d8c> 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 Hi Ian, sorry, forgot to add that contrary to the WLI-UC-GNM problem, I'm still compiling using gcc on FreeBSD 9.1 The abort is completely reproducible each time at the same place... I've tried to recompile the kernel a few times, also changing the root device, but it gets stuck there and aborts.. I actually have no clue on what's going on here. Any hints on how to get more information about this? Cheers, Mathelp
Want to link to this message? Use this
URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?51F9C81A.7000106>