> Date: Sun, 28 Jan 2018 07:27:49 +0100
> From: Sebastien Marie <[email protected]>
> 
> Hi,
> 
> I recently installed latest -current snapshot of arm64 using
> qemu-system-aarch64 -M virt.
> 
> $ doas what /bsd
> /bsd
>         OpenBSD 6.2-current (GENERIC) #160: Wed Jan 24 18:26:59 MST 2018
> 
> But the system is relatively unstable due to random segfaults/abort on
> almost any userland program (triggered on: sshd, smtpd, tmux, ksh,
> clang, make, perl, rsync, ...)
> 
> Error types are:
> - Segfaults
>       # rcctl ls failed
>       Segmentation fault (core dumped)
> 
> - Some are abort from libc:
>       $ cc ...
>       cc(19957) in free(): use after free 0x127e4b2f60
>       Abort trap
> 
>       (during boot)
>       kvm_mkdb(90892) in free(): bogus pointer (double free?) 
> 0xffffffffffffffff
> 
> - Random ssh connect problems (could be sshd segfault):
>       amd64$ ssh qaarch64
>       ssh_dispatch_run_fatal: Connection to 192.168.92.18 port 4422: 
> incorrect signature
>       amd64$ ssh qaarch64
>       ssh_exchange_identification: Connection closed by remote host
> 
> - Things that looks like memory corruption ?
>       $ doas rcctl enable accounting
>       /usr/sbin/rcctl: 89{m_base_accounting}: not found
>       /usr/sbin/rcctl[613]: YEL
>                                : bad number
> 
>       $ cc ...
>       cc: error: no such file or directory: 'œôÉÕG'-hB/src/lib/libc'
> 
>       (and re-running the command make it works)
> 
> - memory related kernel messages:
>       uvn_flush: obj=0x0, offset=0x10056b000.  error during pageout.
>       uvn_flush: WARNING: changes to page may be lost!
> 
>       (note: the system showed a serie of such message with changed
>       offset, and next was usable. In doubt, I rebooted)
> 
> 
> Does the snapshot has know problem ? or it should be problem inside
> qemu ?
> 
> Due to the ubiquious nature of the problem, it seems to me it could be
> inside:
>   - qemu
>   - kernel
>   - libc
> 
> dmesg below (I disabled psci to avoid a panic at boot - jsg@ has
> provided a proper bug report).

Did OpenBSD/arm64 ever run properly in qemu?  I certainly never tried
it.  Things are fairly stable on real hardware, but on the overdrive
3000 we see random segfaults as well.

What happens if you tell qemu to emulate a Cortex-A53 by passing -cpu
cortex-a53?

> OpenBSD 6.2-current (GENERIC) #160: Wed Jan 24 18:26:59 MST 2018
>     [email protected]:/usr/src/sys/arch/arm64/compile/GENERIC
> real mem  = 2091143168 (1994MB)
> avail mem = 2002989056 (1910MB)
> User Kernel Config
> UKC> disable psci
> 141 psci* disabled
> UKC> exit
> Continuing...
> mainbus0 at root: unknown model
> cpu0 at mainbus0: ARM Cortex-A57 r1p0
> efi0 at mainbus0: UEFI 2.6
> efi0: EDK II rev 0x10000
> simplebus0 at mainbus0: "platform"
> virtio0 at mainbus0: Virtio Unknown (0) Device
> virtio1 at mainbus0: Virtio Unknown (0) Device
> virtio2 at mainbus0: Virtio Unknown (0) Device
> virtio3 at mainbus0: Virtio Unknown (0) Device
> virtio4 at mainbus0: Virtio Unknown (0) Device
> virtio5 at mainbus0: Virtio Unknown (0) Device
> virtio6 at mainbus0: Virtio Unknown (0) Device
> virtio7 at mainbus0: Virtio Unknown (0) Device
> virtio8 at mainbus0: Virtio Unknown (0) Device
> virtio9 at mainbus0: Virtio Unknown (0) Device
> virtio10 at mainbus0: Virtio Unknown (0) Device
> virtio11 at mainbus0: Virtio Unknown (0) Device
> virtio12 at mainbus0: Virtio Unknown (0) Device
> virtio13 at mainbus0: Virtio Unknown (0) Device
> virtio14 at mainbus0: Virtio Unknown (0) Device
> virtio15 at mainbus0: Virtio Unknown (0) Device
> virtio16 at mainbus0: Virtio Unknown (0) Device
> virtio17 at mainbus0: Virtio Unknown (0) Device
> virtio18 at mainbus0: Virtio Unknown (0) Device
> virtio19 at mainbus0: Virtio Unknown (0) Device
> virtio20 at mainbus0: Virtio Unknown (0) Device
> virtio21 at mainbus0: Virtio Unknown (0) Device
> virtio22 at mainbus0: Virtio Unknown (0) Device
> virtio23 at mainbus0: Virtio Unknown (0) Device
> virtio24 at mainbus0: Virtio Unknown (0) Device
> virtio25 at mainbus0: Virtio Unknown (0) Device
> virtio26 at mainbus0: Virtio Unknown (0) Device
> virtio27 at mainbus0: Virtio Unknown (0) Device
> virtio28 at mainbus0: Virtio Unknown (0) Device
> virtio29 at mainbus0: Virtio Unknown (0) Device
> virtio30 at mainbus0: Virtio Block Device
> vioblk0 at virtio30
> scsibus0 at vioblk0: 2 targets
> sd0 at scsibus0 targ 0 lun 0: <VirtIO, Block Device, > SCSI3 0/direct fixed
> sd0: 15359MB, 512 bytes/sector, 31455272 sectors
> virtio31 at mainbus0: Virtio Entropy Device
> viornd0 at virtio31
> pciecam0 at mainbus0
> pci0 at pciecam0
> "Red Hat Host" rev 0x00 at pci0 dev 0 function 0 not configured
> virtio32 at pci0 dev 1 function 0 "Qumranet Virtio Network" rev 0x00
> vio0 at virtio32: address 52:54:00:00:ff:66
> virtio32: irq
> pluart0 at mainbus0: console
> ampintc0 at mainbus0 nirq 288, ncpu 1: "intc"
> ampintcmsi0 at ampintc0: nspi 64
> agtimer0 at mainbus0: tick rate 62500 KHz
> vscsi0 at root
> scsibus1 at vscsi0: 256 targets
> softraid0 at root
> scsibus2 at softraid0: 256 targets
> bootfile: sd0a:/bsd
> boot device: sd0
> root on sd0a (9bab94372acbda1b.a) swap on sd0b dump on sd0b
> 
> 

Reply via email to