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 ?
No comments:
Post a Comment