Re: RPI-B 11.0-ALPHA3 r301815 panic ["when connecting via WiFi"]
On Fri, 17 Jun 2016, Adrian Chadd wrote: Just disable 11n for now. ifconfig wlan0 -ht (and reassociate.) See if it's that. -adrian ... Apparently not. I have the same panic even with 11n disabled. ...keith ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: RPI-B 11.0-ALPHA3 r301815 panic ["when connecting via WiFi"]
On Fri, 2016-06-17 at 12:28 -0400, Keith White wrote: > On Fri, 17 Jun 2016, Ian Lepore wrote: > > > On Fri, 2016-06-17 at 07:52 -0700, Adrian Chadd wrote: > > > Just disable 11n for now. ifconfig wlan0 -ht (and reassociate.) > > > > > > See if it's that. > > > > > > > > > > > > -adrian > > > > > > > You can see from the crash info that it's an alignment fault: > > > > r6 =c21a4876 > > ldmib r6,{r1-r2} > > > > An ldm instruction requires 4-byte alignment. Now the question is > > why > > undefining __NO_STRICT_ALIGNMENT didn't fix the problem. Maybe the > > wifi code doesn't use __NO_STRICT_ALIGNMENT the same way other > > network > > drivers do? > > > > Unfortunately the pasted info lists the nearby symbol as > > $a.17+0x38, > > which doesn't help find the actual code. A stack backtrace might > > help. > > > > -- Ian > > ... > > What do I need to type at the "db> " prompt that would be useful? > I should be able to access the RPI-B in 5 hours. > > Here's the result of a "where" taken from an earlier logged session > (different r6 value): > "where" is a synonym for getting a stack backtrace, that's just what I needed. Now I know what's wrong, but not yet how to fix it. -- Ian ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: RPI-B 11.0-ALPHA3 r301815 panic ["when connecting via WiFi"]
On Fri, 17 Jun 2016, Ian Lepore wrote: On Fri, 2016-06-17 at 07:52 -0700, Adrian Chadd wrote: Just disable 11n for now. ifconfig wlan0 -ht (and reassociate.) See if it's that. -adrian You can see from the crash info that it's an alignment fault: r6 =c21a4876 ldmib r6,{r1-r2} An ldm instruction requires 4-byte alignment. Now the question is why undefining __NO_STRICT_ALIGNMENT didn't fix the problem. Maybe the wifi code doesn't use __NO_STRICT_ALIGNMENT the same way other network drivers do? Unfortunately the pasted info lists the nearby symbol as $a.17+0x38, which doesn't help find the actual code. A stack backtrace might help. -- Ian ... What do I need to type at the "db> " prompt that would be useful? I should be able to access the RPI-B in 5 hours. Here's the result of a "where" taken from an earlier logged session (different r6 value): Fatal kernel mode data abort: 'Alignment Fault' on read trapframe: 0xd3c8c8c0 FSR=0001, FAR=c218607a, spsr=6013 r0 =c07a6548, r1 =0004, r2 =c06059f6, r3 =07b6 r4 =d3c8ca28, r5 =d3c8cb40, r6 =c2186076, r7 =c1dd4ce0 r8 =c1dd4ce0, r9 =c2186076, r10=d3c8cb40, r11=d3c8c988 r12=, ssp=d3c8c950, slr=c1b50370, pc =c0449ff8 [ thread pid 13 tid 100036 ] Stopped at $a.17+0x38: ldmib r6, {r1-r2} db> where Tracing pid 13 tid 100036 td 0xc1b50370 db_trace_self() at db_trace_self pc = 0xc055c774 lr = 0xc0145be4 ($a.19+0xf4) sp = 0xd3c8c5b8 fp = 0xd3c8c5d0 $a.19() at $a.19+0xf4 pc = 0xc0145be4 lr = 0xc0145838 ($a.11+0x250) sp = 0xd3c8c5d8 fp = 0xd3c8c678 r4 = 0x0001 r5 = 0x r6 = 0xc05fb0e7 r10 = 0xc07ab1a8 $a.11() at $a.11+0x250 pc = 0xc0145838 lr = 0xc01455c0 (db_command_loop+0x5c) sp = 0xd3c8c680 fp = 0xd3c8c690 r4 = 0xc05c8ec6 r5 = 0xc05ead58 r6 = 0xc07ab194 r7 = 0xc06b7ea0 r8 = 0xc079ed28 r9 = 0xc079ed2c r10 = 0x db_command_loop() at db_command_loop+0x5c pc = 0xc01455c0 lr = 0xc014872c (db_trap+0xec) sp = 0xd3c8c698 fp = 0xd3c8c7b0 r4 = 0x0001 r5 = 0x r6 = 0xc07ab1a0 r10 = 0x db_trap() at db_trap+0xec pc = 0xc014872c lr = 0xc02f83b0 (kdb_trap+0xb8) sp = 0xd3c8c7b8 fp = 0xd3c8c7d8 r4 = 0x r5 = 0x0001 r6 = 0xc079ed48 r10 = 0x kdb_trap() at kdb_trap+0xb8 pc = 0xc02f83b0 lr = 0xc05770b4 ($a.4+0x1c0) sp = 0xd3c8c7e0 fp = 0xd3c8c800 r4 = 0xd3c8c8c0 r5 = 0x0013 r6 = 0xc218607a r7 = 0x0001 r8 = 0x0001 r9 = 0xc1b50370 r10 = 0x $a.4() at $a.4+0x1c0 pc = 0xc05770b4 lr = 0xc0577190 ($a.7+0x78) sp = 0xd3c8c808 fp = 0xd3c8c820 r4 = 0xc218607a r5 = 0xd3c8c840 r6 = 0x0001 r7 = 0x0001 r8 = 0x0013 r10 = 0x $a.7() at $a.7+0x78 pc = 0xc0577190 lr = 0xc0576eac (abort_handler+0x438) sp = 0xd3c8c828 fp = 0xd3c8c8b8 r4 = 0xd3c8c8c0 r5 = 0xc0577118 abort_handler() at abort_handler+0x438 pc = 0xc0576eac lr = 0xc055eed0 (exception_exit) sp = 0xd3c8c8c0 fp = 0xd3c8c988 r4 = 0xd3c8ca28 r5 = 0xd3c8cb40 r6 = 0xc2186076 r7 = 0xc1dd4ce0 r8 = 0xc1dd4ce0 r9 = 0xc2186076 r10 = 0xd3c8cb40 exception_exit() at exception_exit pc = 0xc055eed0 lr = 0xc1b50370 (0xc1b50370) sp = 0xd3c8c950 fp = 0xd3c8c988 r0 = 0xc07a6548 r1 = 0x0004 r2 = 0xc06059f6 r3 = 0x07b6 r4 = 0xd3c8ca28 r5 = 0xd3c8cb40 r6 = 0xc2186076 r7 = 0xc1dd4ce0 r8 = 0xc1dd4ce0 r9 = 0xc2186076 r10 = 0xd3c8cb40 r12 = 0x $a.17() at $a.17+0x3c pc = 0xc0449ffc lr = 0xc0449068 (syncache_expand+0x10c) sp = 0xd3c8c990 fp = 0xd3c8cad8 r4 = 0xc1dd4cf0 r5 = 0xc23c9000 r6 = 0xc1f65208 r7 = 0xd3c8ca28 r8 = 0xc1dd4ce0 r9 = 0xc2186076 r10 = 0xd3c8cb40 syncache_expand() at syncache_expand+0x10c pc = 0xc0449068 lr = 0xc0438df8 ($a.21+0x100) sp = 0xd3c8cae0 fp = 0xd3c8cbb0 r4 = 0xc0604081 r5 = 0xc23b53a8 r6 = 0xd3c8cb6c r7 = 0xc2186076 r8 = 0xc23b54a4 r9 = 0x r10 = 0xc07ae0d8 $a.21() at $a.21+0x100 pc = 0xc0438df8 lr = 0xc03bf95c (ip_input+0x230) sp = 0xd3c8cbb8 fp = 0xd3c8cbf0 r4 = 0xc2186062 r5 = 0xc1e068e0 r6 = 0x0003 r7 = 0x r8 = 0x r9 = 0xc06ff570 r10 = 0xc07ad790 ip_input() at ip_input+0x230 pc = 0xc03bf95c lr = 0xc039e7dc (netisr_dispatch_src+0xa8) sp = 0xd3c8cbf8 fp = 0xd3c8cc20 r4 = 0x0001 r5 = 0xc07a59b4 r6 = 0x r7 = 0xc07a59b0 r8 = 0xc2102a00 r9 = 0xc05fd75c r10 = 0xc2102a00 netisr_dispatch_src() at netisr_dispatch_src+0xa8 pc = 0xc039e7dc lr = 0xc03996cc (ether
Re: RPI-B 11.0-ALPHA3 r301815 panic ["when connecting via WiFi"]
On Fri, 2016-06-17 at 07:52 -0700, Adrian Chadd wrote: > Just disable 11n for now. ifconfig wlan0 -ht (and reassociate.) > > See if it's that. > > > > -adrian > You can see from the crash info that it's an alignment fault: r6 =c21a4876 ldmib r6,{r1-r2} An ldm instruction requires 4-byte alignment. Now the question is why undefining __NO_STRICT_ALIGNMENT didn't fix the problem. Maybe the wifi code doesn't use __NO_STRICT_ALIGNMENT the same way other network drivers do? Unfortunately the pasted info lists the nearby symbol as $a.17+0x38, which doesn't help find the actual code. A stack backtrace might help. -- Ian > > On 17 June 2016 at 04:19, Keith White wrote: > > On Thu, 16 Jun 2016, Keith White wrote: > > > > > On Wed, 15 Jun 2016, Mark Millard wrote: > > > > > > > https://lists.freebsd.org/pipermail/freebsd-current/2016-June/0 > > > > 61904.html > > > > reports an RPI-B alignment fault for -r301815 (the snapshot) > > > > "when > > > > connecting via WiFi". > > > > > > > > -r301872 ( > > > > https://lists.freebsd.org/pipermail/svn-src-head/2016-June/0883 > > > > 39.html ) has > > > > a fix for networking vs. alignment handling for armv6 contexts > > > > that might be > > > > needed. Quoting: > > > > > > > > > Author: ian > > > > > Date: Mon Jun 13 16:48:27 2016 > > > > > New Revision: 301872 > > > > > URL: > > > > > https://svnweb.freebsd.org/changeset/base/301872 > > > > > > > > ... > > > > > > > > > Thanks for pointing this out! I'll see if a (complete) rebuild > > > at > > > that rev fixes the problem. > > > > > > > Tried that. I still get a panic. > > > > I cross built on an amd64 at r301840, I'll try upgrading that > > machine too. > > > > In the meantime, other suggestions? > > > > FreeBSD 11.0-ALPHA3 #0 r301872: Thu Jun 16 21:11:44 EDT 2016 > > kwhite@freebsd11:/usr/obj/arm.armv6/usr/src/sys/RPI-B arm > > FreeBSD clang version 3.8.0 (tags/RELEASE_380/final 262564) (based > > on LLVM > > 3.8.0) > > VT: init without driver. > > ... > > Starting devd. > > urtwn0: > addr 4> on > > usbus0 > > urtwn0: MAC/BB RTL8188CUS, RF 6052 1T1R > > urtwn0: enabling 11n > > wlan0: Ethernet address: 00:13:ef:74:07:a8 > > Created wlan(4) interfaces: wlan0. > > ... > > > > [ nc rpi-b 22 ] > > Fatal kernel mode data abort: 'Alignment Fault' on read > > trapframe: 0xc18f28c0 > > FSR=0001, FAR=c21a487a, spsr=6013 > > r0 =c07a6548, r1 =0004, r2 =c0605338, r3 =07b6 > > r4 =c18f2a28, r5 =c18f2b40, r6 =c21a4876, r7 =c1ccd240 > > r8 =c1ccd240, r9 =c21a4Stopped at $a.17+0x38: ldmib r6, > > {r1-r2} > > db> > > > > > > ...keith > > ___ > > freebsd-current@freebsd.org mailing list > > https://lists.freebsd.org/mailman/listinfo/freebsd-current > > To unsubscribe, send any mail to " > > freebsd-current-unsubscr...@freebsd.org" > ___ > freebsd-current@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to " > freebsd-current-unsubscr...@freebsd.org" ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: RPI-B 11.0-ALPHA3 r301815 panic ["when connecting via WiFi"]
Just disable 11n for now. ifconfig wlan0 -ht (and reassociate.) See if it's that. -adrian On 17 June 2016 at 04:19, Keith White wrote: > On Thu, 16 Jun 2016, Keith White wrote: > >> On Wed, 15 Jun 2016, Mark Millard wrote: >> >>> https://lists.freebsd.org/pipermail/freebsd-current/2016-June/061904.html >>> reports an RPI-B alignment fault for -r301815 (the snapshot) "when >>> connecting via WiFi". >>> >>> -r301872 ( >>> https://lists.freebsd.org/pipermail/svn-src-head/2016-June/088339.html ) has >>> a fix for networking vs. alignment handling for armv6 contexts that might be >>> needed. Quoting: >>> Author: ian Date: Mon Jun 13 16:48:27 2016 New Revision: 301872 URL: https://svnweb.freebsd.org/changeset/base/301872 >>> >>> ... >> >> >> Thanks for pointing this out! I'll see if a (complete) rebuild at >> that rev fixes the problem. >> > > Tried that. I still get a panic. > > I cross built on an amd64 at r301840, I'll try upgrading that machine too. > > In the meantime, other suggestions? > > FreeBSD 11.0-ALPHA3 #0 r301872: Thu Jun 16 21:11:44 EDT 2016 > kwhite@freebsd11:/usr/obj/arm.armv6/usr/src/sys/RPI-B arm > FreeBSD clang version 3.8.0 (tags/RELEASE_380/final 262564) (based on LLVM > 3.8.0) > VT: init without driver. > ... > Starting devd. > urtwn0: on > usbus0 > urtwn0: MAC/BB RTL8188CUS, RF 6052 1T1R > urtwn0: enabling 11n > wlan0: Ethernet address: 00:13:ef:74:07:a8 > Created wlan(4) interfaces: wlan0. > ... > > [ nc rpi-b 22 ] > Fatal kernel mode data abort: 'Alignment Fault' on read > trapframe: 0xc18f28c0 > FSR=0001, FAR=c21a487a, spsr=6013 > r0 =c07a6548, r1 =0004, r2 =c0605338, r3 =07b6 > r4 =c18f2a28, r5 =c18f2b40, r6 =c21a4876, r7 =c1ccd240 > r8 =c1ccd240, r9 =c21a4Stopped at $a.17+0x38: ldmib r6, {r1-r2} > db> > > > ...keith > ___ > freebsd-current@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org" ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
RE: RPI-B 11.0-ALPHA3 r301815 panic ["when connecting via WiFi"]
On Thu, 16 Jun 2016, Keith White wrote: On Wed, 15 Jun 2016, Mark Millard wrote: https://lists.freebsd.org/pipermail/freebsd-current/2016-June/061904.html reports an RPI-B alignment fault for -r301815 (the snapshot) "when connecting via WiFi". -r301872 ( https://lists.freebsd.org/pipermail/svn-src-head/2016-June/088339.html ) has a fix for networking vs. alignment handling for armv6 contexts that might be needed. Quoting: Author: ian Date: Mon Jun 13 16:48:27 2016 New Revision: 301872 URL: https://svnweb.freebsd.org/changeset/base/301872 ... Thanks for pointing this out! I'll see if a (complete) rebuild at that rev fixes the problem. Tried that. I still get a panic. I cross built on an amd64 at r301840, I'll try upgrading that machine too. In the meantime, other suggestions? FreeBSD 11.0-ALPHA3 #0 r301872: Thu Jun 16 21:11:44 EDT 2016 kwhite@freebsd11:/usr/obj/arm.armv6/usr/src/sys/RPI-B arm FreeBSD clang version 3.8.0 (tags/RELEASE_380/final 262564) (based on LLVM 3.8.0) VT: init without driver. ... Starting devd. urtwn0: on usbus0 urtwn0: MAC/BB RTL8188CUS, RF 6052 1T1R urtwn0: enabling 11n wlan0: Ethernet address: 00:13:ef:74:07:a8 Created wlan(4) interfaces: wlan0. ... [ nc rpi-b 22 ] Fatal kernel mode data abort: 'Alignment Fault' on read trapframe: 0xc18f28c0 FSR=0001, FAR=c21a487a, spsr=6013 r0 =c07a6548, r1 =0004, r2 =c0605338, r3 =07b6 r4 =c18f2a28, r5 =c18f2b40, r6 =c21a4876, r7 =c1ccd240 r8 =c1ccd240, r9 =c21a4Stopped at $a.17+0x38: ldmib r6, {r1-r2} db> ...keith ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
RE: RPI-B 11.0-ALPHA3 r301815 panic ["when connecting via WiFi"]
On Wed, 15 Jun 2016, Mark Millard wrote: https://lists.freebsd.org/pipermail/freebsd-current/2016-June/061904.html reports an RPI-B alignment fault for -r301815 (the snapshot) "when connecting via WiFi". -r301872 ( https://lists.freebsd.org/pipermail/svn-src-head/2016-June/088339.html ) has a fix for networking vs. alignment handling for armv6 contexts that might be needed. Quoting: Author: ian Date: Mon Jun 13 16:48:27 2016 New Revision: 301872 URL: https://svnweb.freebsd.org/changeset/base/301872 ... Thanks for pointing this out! I'll see if a (complete) rebuild at that rev fixes the problem. ...keith ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: RPI-B 11.0-ALPHA3 r301815 panic
On Thu, 16 Jun 2016, Svatopluk Kraus wrote: There was a fix committed in r301872 which should help. Svatopluk Kraus ... Thanks! I'd tried r301932 with the same panic. I'll try again with r301872 and a pristine /usr/obj ...keith ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: RPI-B 11.0-ALPHA3 r301815 panic
There was a fix committed in r301872 which should help. Svatopluk Kraus On Thu, Jun 16, 2016 at 3:48 AM, Keith White wrote: > I get the following panic when connecting via WiFi to an RPI-B > running the r301815 snapshot: > > Fatal kernel mode data abort: 'Alignment Fault' on read > trapframe: 0xc18f28c0 > FSR=0001, FAR=c21a287a, spsr=6013 > r0 =c07a6548, r1 =0004, r2 =c060513d, r3 =07b6 > r4 =c18f2a28, r5 =c18f2b40, r6 =c21a2876, r7 =c1cce3e0 > r8 =c1cce3e0, r9 =c21a2876, r10=c18f2b40, r11=c18f2988 > r12=, ssp=c18f2950, slr=c1a48370, pc =c0449928 > > Suggestions on where to start to track this down? > > > Here's the console output over the serial port from boot to panic: > > U-Boot 2016.01 (Jun 11 2016 - 12:28:01 +) > > DRAM: 224 MiB > RPI Model B (no P5) (0x3) > MMC: bcm2835_sdhci: 0 > reading uboot.env > > ** Unable to read "uboot.env" from mmc0:1 ** > Using default environment > > In:serial > Out: lcd > Err: lcd > Net: Net Initialization Skipped > No ethernet found. > reading uEnv.txt > ** Unable to read file uEnv.txt ** > Hit any key to stop autoboot: 0 starting USB... > USB0: Core Release: 2.80a > scanning bus 0 for devices... 4 USB Device(s) found >scanning usb for storage devices... 0 Storage Device(s) found >scanning usb for ethernet devices... 1 Ethernet Device(s) found > Booting from: mmc 0 ubldr.bin > reading ubldr.bin > 223912 bytes read in 30 ms (7.1 MiB/s) > ## No elf image at address 0x0020 > ## Starting application at 0x0020 ... > Consoles: U-Boot console Compatible U-Boot API signature found @0xdb464d0 > > FreeBSD/armv6 U-Boot loader, Revision 1.2 > (r...@releng2.nyi.freebsd.org, Sat Jun 11 12:55:20 UTC 2016) > > DRAM: 224MB > Number of U-Boot devices: 2 > U-Boot env: loaderdev='mmc 0' > Found U-Boot device: disk > Checking unit=0 slice= partition=... good. > Booting from disk0s2a: > /boot/kernel/kernel data=0x606164+0xfde9c syms=[0x4+0xcaf70+0x4+0x984e7] > > Hit [Enter] to boot immediately, or any other key for command prompt. > Booting [/boot/kernel/kernel]... Using DTB provided by U-Boot at address > 0x100. > Kernel entry at 0x0x400100... > Kernel args: (null) > KDB: debugger backends: ddb > KDB: current backend: ddb > Copyright (c) 1992-2016 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 11.0-ALPHA3 #0 r301815: Sat Jun 11 13:02:45 UTC 2016 > r...@releng2.nyi.freebsd.org:/usr/obj/arm.armv6/usr/src/sys/RPI-B arm > FreeBSD clang version 3.8.0 (tags/RELEASE_380/final 262564) (based on LLVM > 3.8.0) > VT: init without driver. > sema_sysinit > CPU: ARM1176JZ-S rev 7 (ARM11J core) > Supported features: ARM_ISA THUMB2 JAZELLE ARMv4 Security_Ext > WB enabled LABT branch prediction disabled > 16KB/32B 4-way instruction cache > 16KB/32B 4-way write-back-locking-C data cache > real memory = 234876928 (223 MB) > avail memory = 219312128simplebus0: mem > 0x2000-0x20ff on ofwbus0 > cpulist0: on ofwbus0 > cpu0: on cpulist0 > bcm2835_cpufreq0: on cpu0 > intc0: Hz quality 1000 > Timecounter "BCM2835-3" frequency 100 Hz quality 1000 > bcmwd0: mem 0x10001c-0x100027 on simplebus0 > gpio0: mem 0x20-0x2000af on simplebus0 > gpio0: read-only pins: 46-53. > gpio0: reserved pins: 48-53. > gpiobus0: on gpio0 > gpioled0: at pin 16 on gpiobus0 > gpioc0: on gpio0 > iichb0: mem 0x205000-0x20501f on simplebus0 > iicbus0: on iichb0 > iic0: on iicbus0 > iichb1: mem 0x804000-0x80401f on simplebus0 > iicbus1: on iichb1 > iic1: on iicbus1 > spi0: mem 0x204000-0x20401f on simplebus0 > spibus0: on spi0 > bcm_dma0: mem 0x7000-0x7fff,0xe05000-0xe05fff on > simplebus0 > mbox0: mem 0xb880-0xb8bf on simplebus0 > sdhci_bcm0: mem 0x30-0x3000ff on > simplebus0 > mmc0: on sdhci_bcm0 > uart0: mem 0x201000-0x201fff on simplebus0 > uart0: console (115200,n,8,1) > vchiq0: mem 0xb800-0xb84f on simplebus0 > vchiq: local ver 8 (min 3), remote ver 8. > pcm0: on vchiq0 > bcm283x_dwcotg0: mem > 0x98-0x99 on simplebus0 > usbus0 on bcm283x_dwcotg0 > fb0: on ofwbus0 > fbd0 on fb0 > VT: initialize with new VT driver "fb". > fb0: 656x416(656x416@0,0) 24bpp > fb0: fbswap: 1, pitch 1968, base 0x0eaac000, screen_size 818688 > cryptosoft0: > Timecounters tick every 10.000 msec > usbus0: 480Mbps High Speed USB v2.0 > bcm2835_cpufreq0: ARM 700MHz, Core 250MHz, SDRAM 400MHz, Turbo OFF > ugen0.1: at usbus0 > uhub0: removable, self powered > mmcsd0: 2GB at mmc0 > 41.6MHz/4bit/65535-block > Trying to mount root from ufs:/dev/ufs/rootfs [rw]... > warning: no time-of-day clock registered, system time will not be set > accurately > ugen0.2: at usbus0 > uhub1: on > usbus0 > uhub1: MTT enabled > uhub1: 3 ports with 2 removable, self powered > Setting hostuuid: 4af361f9-2fd5-11e6-bfe7-b827ebdc1f36. > Setting hostid: 0xe2d1bb69
RE: RPI-B 11.0-ALPHA3 r301815 panic ["when connecting via WiFi"]
https://lists.freebsd.org/pipermail/freebsd-current/2016-June/061904.html reports an RPI-B alignment fault for -r301815 (the snapshot) "when connecting via WiFi". -r301872 ( https://lists.freebsd.org/pipermail/svn-src-head/2016-June/088339.html ) has a fix for networking vs. alignment handling for armv6 contexts that might be needed. Quoting: > Author: ian > Date: Mon Jun 13 16:48:27 2016 > New Revision: 301872 > URL: > https://svnweb.freebsd.org/changeset/base/301872 > > > Log: > Do not define __NO_STRICT_ALIGNMENT for armv6. While the requirements > are no longer natural-alignment strict, there are still some restrictions. > > FreeBSD network code assumes data is naturally-aligned or is running > on a platform with no restrictions; pointers are not annotated to > indicate the data pointed to may be packed or unaligned. The clang > optimizer can sometimes combine the load or store of a pair of adjacent > 32-bit values into a single doubleword load/store, and that operation > requires at least 4-byte alignment. __NO_STRICT_ALIGNMENT can lead > to tcp headers being only 2-byte aligned. > > Note that alignment faults remain disabled on armv6, this change reverts > only the defining of the symbol which leads to some overly-agressive code > shortcuts when building common/shared drivers and network code for arm. > > Approved by:re(kib) > > Modified: > head/sys/arm/include/_types.h > > Modified: head/sys/arm/include/_types.h > == > --- head/sys/arm/include/_types.h Mon Jun 13 11:19:06 2016 > (r301871) > +++ head/sys/arm/include/_types.h Mon Jun 13 16:48:27 2016 > (r301872) > @@ -43,10 +43,6 @@ > #error this file needs sys/cdefs.h as a prerequisite > #endif > > -#if __ARM_ARCH >= 6 > -#define __NO_STRICT_ALIGNMENT > -#endif > - > /* > * Basic types upon which most other types are built. > */ === Mark Millard markmi at dsl-only.net ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
RPI-B 11.0-ALPHA3 r301815 panic
I get the following panic when connecting via WiFi to an RPI-B running the r301815 snapshot: Fatal kernel mode data abort: 'Alignment Fault' on read trapframe: 0xc18f28c0 FSR=0001, FAR=c21a287a, spsr=6013 r0 =c07a6548, r1 =0004, r2 =c060513d, r3 =07b6 r4 =c18f2a28, r5 =c18f2b40, r6 =c21a2876, r7 =c1cce3e0 r8 =c1cce3e0, r9 =c21a2876, r10=c18f2b40, r11=c18f2988 r12=, ssp=c18f2950, slr=c1a48370, pc =c0449928 Suggestions on where to start to track this down? Here's the console output over the serial port from boot to panic: U-Boot 2016.01 (Jun 11 2016 - 12:28:01 +) DRAM: 224 MiB RPI Model B (no P5) (0x3) MMC: bcm2835_sdhci: 0 reading uboot.env ** Unable to read "uboot.env" from mmc0:1 ** Using default environment In:serial Out: lcd Err: lcd Net: Net Initialization Skipped No ethernet found. reading uEnv.txt ** Unable to read file uEnv.txt ** Hit any key to stop autoboot: 0 starting USB... USB0: Core Release: 2.80a scanning bus 0 for devices... 4 USB Device(s) found scanning usb for storage devices... 0 Storage Device(s) found scanning usb for ethernet devices... 1 Ethernet Device(s) found Booting from: mmc 0 ubldr.bin reading ubldr.bin 223912 bytes read in 30 ms (7.1 MiB/s) ## No elf image at address 0x0020 ## Starting application at 0x0020 ... Consoles: U-Boot console Compatible U-Boot API signature found @0xdb464d0 FreeBSD/armv6 U-Boot loader, Revision 1.2 (r...@releng2.nyi.freebsd.org, Sat Jun 11 12:55:20 UTC 2016) DRAM: 224MB Number of U-Boot devices: 2 U-Boot env: loaderdev='mmc 0' Found U-Boot device: disk Checking unit=0 slice= partition=... good. Booting from disk0s2a: /boot/kernel/kernel data=0x606164+0xfde9c syms=[0x4+0xcaf70+0x4+0x984e7] Hit [Enter] to boot immediately, or any other key for command prompt. Booting [/boot/kernel/kernel]... Using DTB provided by U-Boot at address 0x100. Kernel entry at 0x0x400100... Kernel args: (null) KDB: debugger backends: ddb KDB: current backend: ddb Copyright (c) 1992-2016 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 11.0-ALPHA3 #0 r301815: Sat Jun 11 13:02:45 UTC 2016 r...@releng2.nyi.freebsd.org:/usr/obj/arm.armv6/usr/src/sys/RPI-B arm FreeBSD clang version 3.8.0 (tags/RELEASE_380/final 262564) (based on LLVM 3.8.0) VT: init without driver. sema_sysinit CPU: ARM1176JZ-S rev 7 (ARM11J core) Supported features: ARM_ISA THUMB2 JAZELLE ARMv4 Security_Ext WB enabled LABT branch prediction disabled 16KB/32B 4-way instruction cache 16KB/32B 4-way write-back-locking-C data cache real memory = 234876928 (223 MB) avail memory = 219312128simplebus0: mem 0x2000-0x20ff on ofwbus0 cpulist0: on ofwbus0 cpu0: on cpulist0 bcm2835_cpufreq0: on cpu0 intc0: mem 0x10001c-0x100027 on simplebus0 gpio0: mem 0x20-0x2000af on simplebus0 gpio0: read-only pins: 46-53. gpio0: reserved pins: 48-53. gpiobus0: on gpio0 gpioled0: at pin 16 on gpiobus0 gpioc0: on gpio0 iichb0: mem 0x205000-0x20501f on simplebus0 iicbus0: on iichb0 iic0: on iicbus0 iichb1: mem 0x804000-0x80401f on simplebus0 iicbus1: on iichb1 iic1: on iicbus1 spi0: mem 0x204000-0x20401f on simplebus0 spibus0: on spi0 bcm_dma0: mem 0x7000-0x7fff,0xe05000-0xe05fff on simplebus0 mbox0: mem 0xb880-0xb8bf on simplebus0 sdhci_bcm0: mem 0x30-0x3000ff on simplebus0 mmc0: on sdhci_bcm0 uart0: mem 0x201000-0x201fff on simplebus0 uart0: console (115200,n,8,1) vchiq0: mem 0xb800-0xb84f on simplebus0 vchiq: local ver 8 (min 3), remote ver 8. pcm0: on vchiq0 bcm283x_dwcotg0: mem 0x98-0x99 on simplebus0 usbus0 on bcm283x_dwcotg0 fb0: on ofwbus0 fbd0 on fb0 VT: initialize with new VT driver "fb". fb0: 656x416(656x416@0,0) 24bpp fb0: fbswap: 1, pitch 1968, base 0x0eaac000, screen_size 818688 cryptosoft0: Timecounters tick every 10.000 msec usbus0: 480Mbps High Speed USB v2.0 bcm2835_cpufreq0: ARM 700MHz, Core 250MHz, SDRAM 400MHz, Turbo OFF ugen0.1: at usbus0 uhub0: at mmc0 41.6MHz/4bit/65535-block Trying to mount root from ufs:/dev/ufs/rootfs [rw]... warning: no time-of-day clock registered, system time will not be set accurately ugen0.2: at usbus0 uhub1: on usbus0 uhub1: MTT enabled uhub1: 3 ports with 2 removable, self powered Setting hostuuid: 4af361f9-2fd5-11e6-bfe7-b827ebdc1f36. Setting hostid: 0xe2d1bb69. No suitable dump device was found. Starting file system checks: ugen0.3: at usbus0 smsc0: on usbus0 smsc0: chip 0xec00, rev. 0002 miibus0: on smsc0 ukphy0: PHY 1 on miibus0 ukphy0: none, 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto ue0: on smsc0 ue0: Ethernet address: b8:27:eb:dc/dev/ufs/rootfs: FILE SYSTEM CLEAN; SKIPPING CHECKS /dev/ufs/rootfs: clean, 276308 free (196 frags, 34514 blocks, 0.0% fragmentation) ugen0.4: at usbus0 Mounting local filesystems:. ELF ldconfig path: