It seems these problems were due to unaligned accesses in the kernel sha2 code. In the window where things broke parts of the network stack were switched from using md5 to sha2. And the problem only showed up in kernels without propolice, so ramdisks but not generic kernels. Things should be back to normal with the latest snapshot which was built after changes tedu made to the sha2 code.
On Mon, Dec 29, 2014 at 08:31:55AM -0600, Edwin Amsler wrote: > I was able to get to installing after my 'bus error'. I chose a host name of > '.' which I had to fix after installing was done. > > -- > Edwin (on the move) > > > On Dec 29, 2014, at 2:50 AM, Jonathan Gray <j...@jsg.id.au> wrote: > > > >> On Fri, Dec 26, 2014 at 04:58:51PM -0500, j...@cox.net wrote: > >> On Thu, Dec 25, 2014 at 11:19:34PM -0600, Edwin Amsler said: > >>> I downloaded the december 15th snapshot for the Cubieboard miniroot and > >>> the installer is crashing. The file was from the University of Toronto > >>> mirror, here?s the URL: > >>> http://openbsd.cs.toronto.edu/pub/OpenBSD/snapshots/armv7/miniroot-sunxi-56.fs > >>> > >>> It?s not my AHCI contribution from last month since I?m able to format > >>> and write zeros to the connected laptop drive. The install script is > >>> calling something that?s making the kernel panic. Any tips for > >>> troubleshooting? I?ll probably just dump a bunch of `echo`s in there to > >>> figure out at what point this ?alignment fault? is happening. > >>> > >>> Here?s the console dump: > >>> > >>> (I)nstall, (U)pgrade, (A)utoinstall or (S)hell? i > >>> At any prompt except password prompts you can escape to a shell by > >>> typing '!'. Default answers are shown in []'s and are selected by > >>> pressing RETURN. You can exit this program at any time by pressing > >>> Control-C, but this can leave your system in an inconsistent state. > >>> > >>> Terminal type? [vt220] > >>> System hostname? (short form, e.g. 'foo') Cubieboard > >>> > >>> Fatal kernel mode data abort: 'Alignment Fault 1' > >>> trapframe: 0xd11996bc > >>> DFSR=00000801, DFAR=d1199857, spsr=80000013 > >>> r0 =d1199857, r1 =00009c28, r2 =0000bb05, r3 =6d750000 > >>> r4 =d1199857, r5 =6d759c28, r6 =661cbb05, r7 =0000ffff > >>> r8 =0000ffff, r9 =9c286d75, r10=bb05661c, r11=d1199740 > >>> r12=d1199744, ssp=d1199708, slr=00000008, pc =c0890d9c > >>> > >>> panic: Fatal abort > >>> syncing disks... done > >>> rebooting... > >> > >> I'm getting this on a BeagleBone Black as well from the Dec. 14 snapshot > >> from ftp3.usa.openbsd.org (miniroot-am335x-56.fs). > >> > >> Fatal kernel mode data abort: 'Alignment Fault 1' > >> trapframe: 0xcfb416bc > >> DFSR=00000801, DFAR=cfb41857, spsr=80000013 > >> r0 =cfb41857, r1 =00009b4f, r2 =00008776, r3 =3f5d0000 > >> r4 =cfb41857, r5 =3f5d9b4f, r6 =5a8c8776, r7 =0000ffff > >> r8 =0000ffff, r9 =9b4f3f5d, r10=87765a8c, r11=cfb41740 > >> r12=cfb41744, ssp=cfb41708, slr=00000008, pc =c038fac4 > >> > >> panic: Fatal abort > >> syncing disks... done > >> rebooting... > > > > This also happens with the more recent snapshot that's uploaded now. > > I haven't come across it with GENERIC-OMAP on BBB only RAMDISK-OMAP. > > > > Seems to happen around configure_ifs in the install script. > > If I add "echo entry" to the start of configure_ifs instead of > > an alignment fault I get: > > > > Terminal type? [vt220] > > System hostname? (short form, e.g. 'foo') [armv7] armv7 > > > > entry > > Bus error > > Available network interfaces are: cpsw0. > > Which network interface do you wish to configure? (or 'done') [cpsw0] > > > > I would be interested to hear what happens with the latest > > zaurus snapshot. >
