gpioctl.8: "0x01" given as an example flag, and parsed w/strtonum.
Hi, i don't see how that would work, so before anyone fixes gpioctl to accept base 16, maybe diff below to fix the man page instead..? (came up while adding more [flags] usage to the man page.) -Artturi diff --git usr.sbin/gpioctl/gpioctl.8 usr.sbin/gpioctl/gpioctl.8 index 0b91a2ce4b6..25d0d302ae3 100644 --- usr.sbin/gpioctl/gpioctl.8 +++ usr.sbin/gpioctl/gpioctl.8 @@ -143,7 +143,7 @@ invert output When attaching an I2C device, if the .Ar flag -argument is set to 0x01, +argument is set to 1, the order of the SDA and SCL signals is reversed (see .Xr gpioiic 4 ) .
Re: pair(4) crashes on strict alignment platforms
On Thu, Mar 08, 2018 at 07:44:13PM +0100, Stefan Sperling wrote:
> Running the first set of example commands from the pair(4) man page
> crashes the kernel on at least sparc64 and octeon.
>
> # ifconfig pair1 rdomain 1 10.1.1.1/24 up
> # ifconfig pair2 rdomain 2 10.1.1.2/24 up
> # ifconfig pair1 patch pair2
> # route -T 1 exec ping 10.1.1.2
>
> A netcat<->telnet connection from 10.1.1.1 to 10.1.1.2 works.
>
> It seems the problem only happens with ping, or short packets in general.
> It looks like the crash is happening while processing the icmp echo reply.
> This code in ip_input_if() calls m_pullup() which ends up setting m->m_data
> to an unaligned address:
>
> if (m->m_len < sizeof (struct ip) &&
> (m = *mp = m_pullup(m, sizeof (struct ip))) == NULL) {
> ipstat_inc(ips_toosmall);
> goto bad;
> }
> ip = mtod(m, struct ip *);
> if (ip->ip_v != IPVERSION) { // we crash here because ip is misaligned
>
> Note that pair(4) has dequeued this mbuf from its send queue and doesn't
> modify it except for resetting the packet header if it exists.
>
> Trace from sparc64:
>
> panic: trap type 0x34 (mem address not aligned): pc=11336d4 npc=11336d8
> pstate=44820006
> Stopped at db_enter+0x8: nop
> TIDPIDUID PRFLAGS PFLAGS CPU COMMAND
> *291733 6703 0 0x14000 0x2000 softnet
> trap(40016e6b890, 34, 11336d4, 44820006, 400023ff800, 8848) at trap+0x2e0
> Lslowtrap_reenter(400023ace00, 0, , 1c176d0, 4, 1) at
> Lslowtrap_reenter+0xf8
> ip_input_if(40016e6bb48, 40016e6bb54, 4, 0, 400023ff800, 8848) at
> ip_input_if+0x120
> ipv4_input(400023ff800, 18184e8, , 1c176d0, 4, 1) at
> ipv4_input+0x3c
> ether_input(400023ff800, 400023ace00, 0, 16545e8, , 8848) at
> ether_input+0xc8
> if_input_process(400021607c0, 40016e6bde0, 131cb20, 1c176d0, 4, 0) at
> if_input_process+0x11c
> taskq_thread(4000216c080, 40002142fc0, 1758938, 16545e8, 0, 3b9ac800) at
> taskq_thread+0x6c
> proc_trampoline(0, 0, 0, 0, 0, 0) at proc_trampoline+0x14
> https://www.openbsd.org/ddb.html describes the minimum info required in bug
> reports.
> Insufficient info makes it difficult to find and fix bugs.
>
the diff below fixes the panic.
the problem is m_adj doesn't keep m_data updated when removing all
the data from one mbuf in a chain.
in more detail, when we read the ping packet from userland into
the kernel, it's put at the front of an mbuf, which is properly
aligned for an ip packet. pair is an ethernet interface, so to send
it an ethernet header is prepended. because the ip packet is at the
start of an mbuf we allocate a new one for the ethernet header.
that ends up being 6 bytes at the end of a new mbuf, with the end
of the ethernet header properly aligned for an ip packet.
pair then sends the packet back into the network stack, which m_adjs
the ethernet header off the front of the packet. m_adj never deletes
mbufs, it just sets their lengths to 0 if there's no more data left
in an mbuf. because the ethernet header is all thats in that first
mbuf it sets m_len to 0, but doesn't touch m_data.
the ip stack then tries to access the ip header in the mbuf chain.
because the first mbuf has 0 bytes in it it uses m_pulldown to get
to the ip header. m_pulldown goes to a lot of lengths to maintain
the alignment of the payload in an mbuf. because m_adj left m_data
where an ethernet header is, ie, 6 bytes with the end aligned for
a payload), m_pulldown puts the ip header where the ethernet header
was, which is 2 byte aligned.
netcat works because non-raw ip sockets have their headers allocated
with space at the start for link headers.
this diff makes m_adj update m_data in all paths.
another option could be to have m_pullup skip over mbufs with
m_len == 0 before finding the target alignment. or do both.
Index: uipc_mbuf.c
===
RCS file: /cvs/src/sys/kern/uipc_mbuf.c,v
retrieving revision 1.253
diff -u -p -r1.253 uipc_mbuf.c
--- uipc_mbuf.c 16 Jan 2018 19:44:34 - 1.253
+++ uipc_mbuf.c 9 Mar 2018 01:34:05 -
@@ -812,11 +812,12 @@ m_adj(struct mbuf *mp, int req_len)
while (m != NULL && len > 0) {
if (m->m_len <= len) {
len -= m->m_len;
+ m->m_data += m->m_len; /* move alignment */
m->m_len = 0;
m = m->m_next;
} else {
- m->m_len -= len;
m->m_data += len;
+ m->m_len -= len;
len = 0;
}
}
Re: armv7/sunxi: latest bsd.rd panics during boot.
I think I maybe saw this or a similar fault exactly *once* when I was hunting for alignment bugs on armv7. I think it might be possible that there's still specific link orders that tickle a bug somewhere. Grabbed the bad snapshot and verified that it does crash for me on beaglebone black. Initial analysis: Crash happens in memcpy_fdestul (unaligned destination memcpy) inside cpu_fork(). I believe it is the *pcb = p1->p_addr->u_pcb line. I might try my JTAG interface later and see if I can grab an actual stack and sniff around a bit.
NFS socket use after free during reboot
Hi,
When rebooting the NFS client while the NFS file system is actively
used, the kernel crashes. The socket at 0xd73c2d9c is filled with
dead beef, so it is a use after free. It is an i386 kernel built
today.
bluhm
root@ot2:.../~# find /mount >/dev/null & sleep 5; reboot -q
[1] 9698
syncing disks... uvm_fault(0xd72afc7c, 0x1ff11000, 0, 1) -> e
kernel: page fault trap, code=0
Stopped at sblock+0x12:movl0x4(%eax),%eax
ddb{0}> trace
sblock(d73c2d9c,d73c2df0,1) at sblock+0x12
soreceive(d73c2d9c,0,f548d818,f548d884,0,f548d804,0) at soreceive+0x271
nfs_receive(d7471f7c,f548d87c,f548d884) at nfs_receive+0xb1
nfs_reply(d7471f7c) at nfs_reply+0x62
nfs_request(d6d1f3c4,10,f548d970) at nfs_request+0x24d
nfs_readdirrpc(d6d1f3c4,f548d9f8,d7499120,f548d9ec) at nfs_readdirrpc+0x1dc
nfs_readdir(f548dab0) at nfs_readdir+0x227
VOP_READDIR(d6d1f3c4,f548daf8,d7499120,f548daec) at VOP_READDIR+0x42
sys_getdents(d71372dc,f548db68,f548db60) at sys_getdents+0x118
syscall() at syscall+0x204
--- syscall (number 0) ---
end of kernel
0x78ef0480:
ddb{0}> ps
PID TID PPIDUID S FLAGS WAIT COMMAND
47525 49437 73751 0 2 0x3reboot
* 9698 299089 73751 0 70x13find
73751 193388 1 0 30x10008b pause ksh
26295 320696 1 0 30x100083 ttyin getty
62718 326479 1 0 30x100083 ttyin getty
6755 452271 1 0 30x100083 ttyin getty
62489 430851 1 0 30x100083 ttyin getty
13303 429205 1 0 30x100083 ttyin getty
97097 367369 1 0 30x100098 poll cron
38250 509671 1 99 30x100090 poll sndiod
367 406650 1110 30x100090 poll sndiod
21810 404127 1 0 30x100090 kqreadinetd
98071 120936 58301 95 30x100092 kqreadsmtpd
69756 87980 58301103 30x100092 kqreadsmtpd
36661 383137 58301 95 30x100092 kqreadsmtpd
73070 332826 58301 95 30x100092 kqreadsmtpd
39972 98572 58301 95 30x100092 kqreadsmtpd
79819 455669 58301 95 30x100092 kqreadsmtpd
58301 220916 1 0 30x100080 kqreadsmtpd
45347 311418 1 0 30x80 selectsshd
69335 244689 0 0 3 0x14200 acct acct
78078 383503 0 0 3 0x14280 nfsidlnfsio
67499 120783 0 0 3 0x14280 nfsidlnfsio
6389 67663 0 0 3 0x14280 nfsidlnfsio
96664 329282 0 0 3 0x14280 nfsidlnfsio
89233 98160 1 0 30x100080 poll ntpd
16545 425860 94501 83 30x100092 poll ntpd
94501 456716 1 83 30x100092 poll ntpd
89114 244638 64496 74 30x100092 bpf pflogd
64496 138057 1 0 30x80 netio pflogd
338733141 2011 73 20x100090syslogd
2011 167758 1 0 30x100082 netio syslogd
14968 488435 1 77 30x100090 poll dhclient
20238 513767 1 0 30x80 poll dhclient
99266 92995 75879115 30x100092 kqreadslaacd
12302 94011 75879115 30x100092 kqreadslaacd
75879 477107 1 0 30x80 kqreadslaacd
94668 139960 0 0 3 0x14200 pgzerozerothread
88879 391716 0 0 3 0x14200 aiodoned aiodoned
37996 199474 0 0 3 0x14200 syncerupdate
52467 413889 0 0 3 0x14200 cleaner cleaner
52168 367270 0 0 3 0x14200 reaperreaper
90849 369485 0 0 3 0x14200 pgdaemon pagedaemon
68700 48024 0 0 3 0x14200 bored crynlk
37778 144411 0 0 3 0x14200 bored crypto
31589 214320 0 0 3 0x14200 usbtskusbtask
10880 448964 0 0 3 0x14200 usbatsk usbatsk
66170 108418 0 0 3 0x14200 bored sensors
86508 510965 0 0 3 0x40014200 acpi0 acpi0
41740 521514 0 0 7 0x40014200idle1
42154 396729 0 0 2 0x14200softnet
65803 465644 0 0 3 0x14200 bored systqmp
33651 52515 0 0 3 0x14200 bored systq
44323 189892 0 0 2 0x40014200softclock
25032 280029 0 0 3 0x40014200idle0
4614 206064 0 0 3 0x14200 kmalloc kmthread
1 57612 0 0 30x82 wait init
0 0 -1 0 3 0x10200 scheduler swapper
ddb{0}> x/x 0xd73c2d9c,10
0xd73c2d9c: 1ff118e7
Re: armv7/sunxi: latest bsd.rd panics during boot.
Hi, new snap did work again on both boards, so i guess this was fixed before my report already, thanks. -Artturi
bgpd: EoR marker not sent for all negotiated AF
If both IPv4 and IPv6 address families are (successfully) negotiated during BGP OPEN, bgpd sends only the IPv4 End-of-Rib marker and fails to send the IPv6 EoR marker. If only one address family is negotiated, EoR marker is sent according to the correct address family. End-of-RIB marker is either a withdraw (IPv4) or a MP_UNREACH_NLRI (IPv6) with no routes. EoR is defined in RFC 4724 Setup: - IPv4 & IPv6 address families negotiated in bgp OPEN - no network announced or only IPv6 - heimdall is running -stable - dev is running -current as of 20180302 petrus@dev[0]:~$ bgpctl show nei heimdall BGP neighbor is 2001:678:3cc:2101::1, remote AS 206155 Description: heimdall BGP version 4, remote router-id 212.129.29.29 BGP state = Established, up for 00:02:56 Last read 00:00:26, holdtime 90s, keepalive interval 30s Neighbor capabilities: Multiprotocol extensions: IPv4 unicast, IPv6 unicast< Route Refresh Graceful Restart: Timeout: 90, restarted, IPv4 unicast, IPv6 unicast 4-byte AS numbers Message statistics: Sent Received Opens3 3 Notifications1 1 Updates 4 12 Keepalives 21 21 Route Refresh1 2 Total 30 39 Update statistics: Sent Received Updates 0 0 Withdraws0 0 End-of-Rib 1 1 < Local host: 2001:678:3cc:2101::3, Local port: 30881 Remote host: 2001:678:3cc:2101::1, Remote port: 179 The same on heimdall. logs show only IPv4 EoR: Mar 8 18:16:48 dev bgpd[52065]: neighbor 2001:678:3cc:2101::1 (heimdall): sending IPv4 unicast EOR marker Mar 8 18:16:48 dev bgpd[52065]: neighbor 2001:678:3cc:2101::1 (heimdall): received IPv4 unicast EOR marker Here is a capture from dev of the bgp session establishment: No. Time SourceDestination Protocol Length Info 1 0.00 2001:678:3cc:2101::3 2001:678:3cc:2101::1 TCP 98 42445 → 179 [SYN] Seq=0 Win=16384 Len=0 MSS=1440 SACK_PERM=1 WS=64 TSval=239166748 TSecr=0 2 0.000193 2001:678:3cc:2101::1 2001:678:3cc:2101::3 TCP 94 179 → 42445 [SYN, ACK] Seq=0 Ack=1 Win=16384 Len=0 MSS=1440 WS=64 TSval=2887012390 TSecr=239166748 3 0.000253 2001:678:3cc:2101::3 2001:678:3cc:2101::1 TCP 86 42445 → 179 [ACK] Seq=1 Ack=1 Win=16384 Len=0 TSval=239166748 TSecr=2887012390 4 0.000777 2001:678:3cc:2101::1 2001:678:3cc:2101::3 BGP 149OPEN Message 5 0.001346 2001:678:3cc:2101::3 2001:678:3cc:2101::1 BGP 149OPEN Message 6 0.001568 2001:678:3cc:2101::3 2001:678:3cc:2101::1 BGP 105KEEPALIVE Message 7 0.001701 2001:678:3cc:2101::1 2001:678:3cc:2101::3 TCP 86 179 → 42445 [ACK] Seq=64 Ack=83 Win=17088 Len=0 TSval=2887012390 TSecr=239166748 8 0.001851 2001:678:3cc:2101::1 2001:678:3cc:2101::3 BGP 105KEEPALIVE Message 9 0.002375 2001:678:3cc:2101::3 2001:678:3cc:2101::1 BGP 109UPDATE Message 10 0.014815 2001:678:3cc:2101::1 2001:678:3cc:2101::3 BGP 109UPDATE Message 11 0.211881 2001:678:3cc:2101::3 2001:678:3cc:2101::1 TCP 86 42445 → 179 [ACK] Seq=106 Ack=106 Win=16384 Len=0 TSval=239166749 TSecr=2887012390 No. Time SourceDestination Protocol Length Info 9 0.002375 2001:678:3cc:2101::3 2001:678:3cc:2101::1 BGP 109UPDATE Message Internet Protocol Version 6, Src: 2001:678:3cc:2101::3, Dst: 2001:678:3cc:2101::1 Border Gateway Protocol - UPDATE Message Marker: Length: 23 Type: UPDATE Message (2) Withdrawn Routes Length: 0 Total Path Attribute Length: 0 No. Time SourceDestination Protocol Length Info 10 0.014815 2001:678:3cc:2101::1 2001:678:3cc:2101::3 BGP 109UPDATE Message Internet Protocol Version 6, Src: 2001:678:3cc:2101::1, Dst: 2001:678:3cc:2101::3 Border Gateway Protocol - UPDATE Message Marker: Length: 23 Type: UPDATE Message (2) Withdrawn Routes Length: 0 Total Path Attribute Length: 0 If only IPv6 is negotiated, EoR marker is sent. Here is what it looks like: Border Gateway Protocol - UPDATE Message Marker: Length: 29 Type: UPDATE Message (2) Withdrawn Routes Length: 0 Total Path Attribute Length: 6 Path attributes Path Attribute - MP_UNREACH_NLRI Flags: 0x80, Optional, Non-transitive, Complete Type Code: MP_UNREACH_NLRI (15) Length: 3 Address family identifier (AFI): IPv6 (2) Subsequent address family
pair(4) crashes on strict alignment platforms
Running the first set of example commands from the pair(4) man page
crashes the kernel on at least sparc64 and octeon.
# ifconfig pair1 rdomain 1 10.1.1.1/24 up
# ifconfig pair2 rdomain 2 10.1.1.2/24 up
# ifconfig pair1 patch pair2
# route -T 1 exec ping 10.1.1.2
A netcat<->telnet connection from 10.1.1.1 to 10.1.1.2 works.
It seems the problem only happens with ping, or short packets in general.
It looks like the crash is happening while processing the icmp echo reply.
This code in ip_input_if() calls m_pullup() which ends up setting m->m_data
to an unaligned address:
if (m->m_len < sizeof (struct ip) &&
(m = *mp = m_pullup(m, sizeof (struct ip))) == NULL) {
ipstat_inc(ips_toosmall);
goto bad;
}
ip = mtod(m, struct ip *);
if (ip->ip_v != IPVERSION) { // we crash here because ip is misaligned
Note that pair(4) has dequeued this mbuf from its send queue and doesn't
modify it except for resetting the packet header if it exists.
Trace from sparc64:
panic: trap type 0x34 (mem address not aligned): pc=11336d4 npc=11336d8
pstate=44820006
Stopped at db_enter+0x8: nop
TIDPIDUID PRFLAGS PFLAGS CPU COMMAND
*291733 6703 0 0x14000 0x2000 softnet
trap(40016e6b890, 34, 11336d4, 44820006, 400023ff800, 8848) at trap+0x2e0
Lslowtrap_reenter(400023ace00, 0, , 1c176d0, 4, 1) at
Lslowtrap_reenter+0xf8
ip_input_if(40016e6bb48, 40016e6bb54, 4, 0, 400023ff800, 8848) at
ip_input_if+0x120
ipv4_input(400023ff800, 18184e8, , 1c176d0, 4, 1) at
ipv4_input+0x3c
ether_input(400023ff800, 400023ace00, 0, 16545e8, , 8848) at
ether_input+0xc8
if_input_process(400021607c0, 40016e6bde0, 131cb20, 1c176d0, 4, 0) at
if_input_process+0x11c
taskq_thread(4000216c080, 40002142fc0, 1758938, 16545e8, 0, 3b9ac800) at
taskq_thread+0x6c
proc_trampoline(0, 0, 0, 0, 0, 0) at proc_trampoline+0x14
https://www.openbsd.org/ddb.html describes the minimum info required in bug
reports.
Insufficient info makes it difficult to find and fix bugs.
Re: armv7/sunxi: latest bsd.rd panics during boot.
On Thu, Mar 08, 2018 at 11:23:25AM +0200, Artturi Alm wrote: > Hi, > > OpenBSD 6.2-current (RAMDISK) #165: Sat Feb 3 12:43:25 MST 2018 > dera...@armv7.openbsd.org:/usr/src/sys/arch/armv7/compile/RAMDISK > > was last working RAMDISK i had on the SD which does end up upgrading to > the buggy one below(i haven't tested other sunxi boards yet): > -Artturi > > U-Boot SPL 2017.09-dirty (Nov 11 2017 - 09:06:41) > DRAM: 1024 MiB > CPU: 100800Hz, AXI/AHB/APB: 3/2/2 > Trying to boot from MMC1 > > > U-Boot 2017.09-dirty (Nov 11 2017 - 09:06:41 +0200) Allwinner Technology > > CPU: Allwinner A10 (SUN4I) > Model: Cubietech Cubieboard > I2C: ready > DRAM: 1 GiB > MMC: SUNXI SD/MMC: 0 > *** Warning - bad CRC, using default environment > > In:serial > Out: serial > Err: serial > SCSI: SATA link 0 timeout. > AHCI 0001.0100 32 slots 1 ports 3 Gbps 0x1 impl SATA mode > flags: ncq stag pm led clo only pmp pio slum part ccc apst > Net: eth0: ethernet@01c0b000 > starting USB... > USB0: USB EHCI 1.00 > USB1: USB OHCI 1.0 > USB2: USB EHCI 1.00 > USB3: USB OHCI 1.0 > scanning bus 0 for devices... 1 USB Device(s) found > scanning bus 2 for devices... 1 USB Device(s) found >scanning usb for storage devices... 0 Storage Device(s) found > Hit any key to stop autoboot: 0 > switch to partitions #0, OK > mmc0 is current device > Scanning mmc 0:1... > Found EFI removable media binary efi/boot/bootarm.efi > reading efi/boot/bootarm.efi > 76528 bytes read in 41 ms (1.8 MiB/s) > libfdt fdt_check_header(): FDT_ERR_BADMAGIC > ## Starting EFI application at 4200 ... > Scanning disks on scsi... > Scanning disks on usb... > Scanning disks on mmc... > MMC Device 1 not found > MMC Device 2 not found > MMC Device 3 not found > Found 6 disks > >> OpenBSD/armv7 BOOTARM 1.0 > boot> boot bsd.rd > booting sd0a:bsd.rd: 2655118+8031612+448396 [169220+90+180368+154192]=0xb2170c > > OpenBSD/armv7 booting ... > arg0 0xc0e2170c arg1 0x0 arg2 0x4800 > Allocating page tables > freestart = 0x40e22000, free_pages = 258526 (0x0003f1de) > IRQ stack: p0x40e5 v0xc0e5 > ABT stack: p0x40e51000 v0xc0e51000 > UND stack: p0x40e52000 v0xc0e52000 > SVC stack: p0x40e53000 v0xc0e53000 > Creating L1 page table at 0x40e24000 > Mapping kernel > Constructing L2 page tables > undefined page pmap board type: 0 > Copyright (c) 1982, 1986, 1989, 1991, 1993 > The Regents of the University of California. All rights reserved. > Copyright (c) 1995-2018 OpenBSD. All rights reserved. https://www.OpenBSD.org > > OpenBSD 6.3-beta (RAMDISK) #180: Tue Mar 6 07:40:58 MST 2018 > dera...@armv7.openbsd.org:/usr/src/sys/arch/armv7/compile/RAMDISK > real mem = 1073741824 (1024MB) > avail mem = 1038036992 (989MB) > mainbus0 at root: Cubietech Cubieboard > cpu0 at mainbus0: ARM Cortex-A8 r3p2 (ARMv7) > cpu0: DC enabled IC enabled WB disabled EABT branch prediction enabled > cpu0: 32KB(64b/l,4way) I-cache, 32KB(64b/l,4way) wr-back D-cache > sxiccmu0 at mainbus0 > simplebus0 at mainbus0: "soc" > sxipio0 at simplebus0: 175 pins > sxitimer0 at simplebus0: cntrtimer @ 24000KHz > sxie0 at simplebus0, address 02:11:06:40:a1:20 > rlphy0 at sxie0 phy 1: RTL8201L 10/100 PHY, rev. 1 > sximmc0 at simplebus0 > sdmmc0 at sximmc0: 4-bit, sd high-speed, mmc high-speed, dma > ehci0 at simplebus0 > usb0 at ehci0: USB revision 2.0 > uhub0 at usb0 configuration 1 interface 0 "Generic EHCI root hub" rev > 2.00/1.00 addr 1 > sxiahci0 at simplebus0: AHCI 1.1 > scsibus0 at sxiahci0: 32 targets > ehci1 at simplebus0 > usb1 at ehci1: USB revision 2.0 > uhub1 at usb1 configuration 1 interface 0 "Generic EHCI root hub" rev > 2.00/1.00 addr 1 > sxiintc0 at simplebus0 > sxidog0 at simplebus0 > sxirtc0 at simplebus0 > com0 at simplebus0: ns16550, no working fifo > com0: console > sxitwi0 at simplebus0 > iic0 at sxitwi0 > axppmic0 at iic0 addr 0x34: AXP209 > sxitwi1 at simplebus0 > iic1 at sxitwi1 > gpio0 at sxipio0: 32 pins > gpio1 at sxipio0: 32 pins > gpio2 at sxipio0: 32 pins > gpio3 at sxipio0: 32 pins > gpio4 at sxipio0: 32 pins > gpio5 at sxipio0: 32 pins > gpio6 at sxipio0: 32 pins > gpio7 at sxipio0: 32 pins > gpio8 at sxipio0: 32 pins > > uvm_fault(0xc0d7ad1c, 0, 2, 0) -> e > Fatal kernel mode data abort: 'Translation fault (L1)' > trapframe: 0xc0e54ef8 > DFSR=0805, DFAR=, spsr=2153 > r0 =, r1 =c0e53010, r2 =0138, r3 = > r4 =c0e54fb0, r5 =c0d7afb0, r6 =c63932e0, r7 =c6392dc8 > r8 =, r9 =, r10=0001, r11=c0e54f70 > r12=, ssp=c0e54f4c, slr=40e24000, pc =c044bb2c > > panic: Fatal abort > syncing disks... done > rebooting... > > so this does happen on armv7/omap also, and for it i had working RAMDISK from fri mar 2: U-Boot SPL 2017.11 (Dec 02 2017 - 00:06:03) Trying to boot from MMC1 reading u-boot.img reading u-boot.img U-Boot 2017.11 (Dec 02 2017 - 00:06:03 -0700) CPU : AM335X-GP rev 2.0 I2C: ready DRAM: 512 MiB No match for driver 'omap_hsmmc' No match for driver
armv7/sunxi: latest bsd.rd panics during boot.
Hi, OpenBSD 6.2-current (RAMDISK) #165: Sat Feb 3 12:43:25 MST 2018 dera...@armv7.openbsd.org:/usr/src/sys/arch/armv7/compile/RAMDISK was last working RAMDISK i had on the SD which does end up upgrading to the buggy one below(i haven't tested other sunxi boards yet): -Artturi U-Boot SPL 2017.09-dirty (Nov 11 2017 - 09:06:41) DRAM: 1024 MiB CPU: 100800Hz, AXI/AHB/APB: 3/2/2 Trying to boot from MMC1 U-Boot 2017.09-dirty (Nov 11 2017 - 09:06:41 +0200) Allwinner Technology CPU: Allwinner A10 (SUN4I) Model: Cubietech Cubieboard I2C: ready DRAM: 1 GiB MMC: SUNXI SD/MMC: 0 *** Warning - bad CRC, using default environment In:serial Out: serial Err: serial SCSI: SATA link 0 timeout. AHCI 0001.0100 32 slots 1 ports 3 Gbps 0x1 impl SATA mode flags: ncq stag pm led clo only pmp pio slum part ccc apst Net: eth0: ethernet@01c0b000 starting USB... USB0: USB EHCI 1.00 USB1: USB OHCI 1.0 USB2: USB EHCI 1.00 USB3: USB OHCI 1.0 scanning bus 0 for devices... 1 USB Device(s) found scanning bus 2 for devices... 1 USB Device(s) found scanning usb for storage devices... 0 Storage Device(s) found Hit any key to stop autoboot: 0 switch to partitions #0, OK mmc0 is current device Scanning mmc 0:1... Found EFI removable media binary efi/boot/bootarm.efi reading efi/boot/bootarm.efi 76528 bytes read in 41 ms (1.8 MiB/s) libfdt fdt_check_header(): FDT_ERR_BADMAGIC ## Starting EFI application at 4200 ... Scanning disks on scsi... Scanning disks on usb... Scanning disks on mmc... MMC Device 1 not found MMC Device 2 not found MMC Device 3 not found Found 6 disks >> OpenBSD/armv7 BOOTARM 1.0 boot> boot bsd.rd booting sd0a:bsd.rd: 2655118+8031612+448396 [169220+90+180368+154192]=0xb2170c OpenBSD/armv7 booting ... arg0 0xc0e2170c arg1 0x0 arg2 0x4800 Allocating page tables freestart = 0x40e22000, free_pages = 258526 (0x0003f1de) IRQ stack: p0x40e5 v0xc0e5 ABT stack: p0x40e51000 v0xc0e51000 UND stack: p0x40e52000 v0xc0e52000 SVC stack: p0x40e53000 v0xc0e53000 Creating L1 page table at 0x40e24000 Mapping kernel Constructing L2 page tables undefined page pmap board type: 0 Copyright (c) 1982, 1986, 1989, 1991, 1993 The Regents of the University of California. All rights reserved. Copyright (c) 1995-2018 OpenBSD. All rights reserved. https://www.OpenBSD.org OpenBSD 6.3-beta (RAMDISK) #180: Tue Mar 6 07:40:58 MST 2018 dera...@armv7.openbsd.org:/usr/src/sys/arch/armv7/compile/RAMDISK real mem = 1073741824 (1024MB) avail mem = 1038036992 (989MB) mainbus0 at root: Cubietech Cubieboard cpu0 at mainbus0: ARM Cortex-A8 r3p2 (ARMv7) cpu0: DC enabled IC enabled WB disabled EABT branch prediction enabled cpu0: 32KB(64b/l,4way) I-cache, 32KB(64b/l,4way) wr-back D-cache sxiccmu0 at mainbus0 simplebus0 at mainbus0: "soc" sxipio0 at simplebus0: 175 pins sxitimer0 at simplebus0: cntrtimer @ 24000KHz sxie0 at simplebus0, address 02:11:06:40:a1:20 rlphy0 at sxie0 phy 1: RTL8201L 10/100 PHY, rev. 1 sximmc0 at simplebus0 sdmmc0 at sximmc0: 4-bit, sd high-speed, mmc high-speed, dma ehci0 at simplebus0 usb0 at ehci0: USB revision 2.0 uhub0 at usb0 configuration 1 interface 0 "Generic EHCI root hub" rev 2.00/1.00 addr 1 sxiahci0 at simplebus0: AHCI 1.1 scsibus0 at sxiahci0: 32 targets ehci1 at simplebus0 usb1 at ehci1: USB revision 2.0 uhub1 at usb1 configuration 1 interface 0 "Generic EHCI root hub" rev 2.00/1.00 addr 1 sxiintc0 at simplebus0 sxidog0 at simplebus0 sxirtc0 at simplebus0 com0 at simplebus0: ns16550, no working fifo com0: console sxitwi0 at simplebus0 iic0 at sxitwi0 axppmic0 at iic0 addr 0x34: AXP209 sxitwi1 at simplebus0 iic1 at sxitwi1 gpio0 at sxipio0: 32 pins gpio1 at sxipio0: 32 pins gpio2 at sxipio0: 32 pins gpio3 at sxipio0: 32 pins gpio4 at sxipio0: 32 pins gpio5 at sxipio0: 32 pins gpio6 at sxipio0: 32 pins gpio7 at sxipio0: 32 pins gpio8 at sxipio0: 32 pins uvm_fault(0xc0d7ad1c, 0, 2, 0) -> e Fatal kernel mode data abort: 'Translation fault (L1)' trapframe: 0xc0e54ef8 DFSR=0805, DFAR=, spsr=2153 r0 =, r1 =c0e53010, r2 =0138, r3 = r4 =c0e54fb0, r5 =c0d7afb0, r6 =c63932e0, r7 =c6392dc8 r8 =, r9 =, r10=0001, r11=c0e54f70 r12=, ssp=c0e54f4c, slr=40e24000, pc =c044bb2c panic: Fatal abort syncing disks... done rebooting...
