On Thu, Aug 02, 2018 at 05:59:41PM +0000, Bill Zissimopoulos wrote: > Mike, thank you for your response. > > On 8/2/18, 9:07 AM, Mike Larkin wrote: > > 1. We've seen this message before (usually on APUs), but only a single > time (eg, > just one of the signal lines gets displayed). And IIRC it was a different > signal. > > The only other instance of this message that I have found online is here: > > https://github.com/yellowman/flashrd/issues/30 > > 2. In your case, the stream of messages seems to stop after some time and > boot > proceeds normally after that. > > You are right. Although I believe that I have seen it print the message > endlessly as well. > > 3. When I built the image using your script, on the second boot, I saw no > messages. > > I'm not sure what's causing the problem, can you try with 6.3 release? > (I'm > assuming you are using -current here? that's what I tested also) > > The problem happens for me with the 6.3 release (install63.iso). I have not > tested other releases. > > (I believe I tried the 6.2 release at some point, but did not complete my > testing because it needed extensive changes to the expect script.) > > 4. in my test the default install location came up as http, so your > script's > pressing of "enter" for install path hung. I had to change the default > location > in the script to be cd. > > That does not happen for me, perhaps because of the install image I use > (install63.iso). > > 5. Your customization step at the end should probably fixup /etc/ttys or > you won't be able to log in to the machine via serial (since no getty will > be spawned there). I sat there waiting for a while in qemu only to realize > the getty was waiting on the vga console, not serial. YMMV. > > You are right. I have not managed to fix serial access for OpenBSD yet, > because I focused on resolving the discussed issue first. > > My understanding is that the instructions at the following link should get > serial access fully working: > > https://www.openbsd.org/faq/faq7.html#SerCon > > Bill > > >
Unfortunately, I don't have any other ideas for you as to how to stop the segvs. It is not seen on real hardware, so I'm at a loss to explain why qemu exhibits this behaviour. Perhaps try changing the cpu type with -cpu XXXX ?
