On Sun, Sep 16, 2018 at 1:15 PM, Johan Huldtgren <johan+openbsd-t...@huldtgren.com> wrote: > On 2018/09/16 10:52, David Higgs wrote: >> On Sun, Sep 16, 2018 at 10:17 AM, David Higgs <hig...@gmail.com> wrote: >>> On Sat, Sep 15, 2018 at 10:05 PM, Philip Guenther <guent...@gmail.com> >>> wrote: >>>> On Sat, Sep 15, 2018 at 11:59 AM David Higgs <hig...@gmail.com> wrote: >>>>> >>>>> I often use VirtualBox (version 5.2.18 on OS X) to familiarize myself >>>>> with new features in snapshots, before upgrading my physical hardware. >>>>> >>>>> This afternoon, I tried updating bsd.rd (amd64, 6.4-beta RAMDISK_CD >>>>> #281) and wasn't able to successfully boot it. I had to rely on the >>>>> video capture ability of VirtualBox to even notice there was a panic >>>>> (typed out below) before it rebooted to the "BIOS" splash screen. >>>> >>>> ... >>>>> >>>>> Also attached is the dmesg from a prior working snapshot. I haven't >>>>> tried updating since this prior snapshot, so I don't have further >>>>> insight into when the issue first appeared. >>>> >>>> >>>> Thank you for the complete and clear report! >>>> >>>> I have a diff in the amd64 snapshots to use the CPU's PCID support in many >>>> cases and this VirtualBox setup found a bug in it. I've generated a new >>>> diff that should fix this, so a future snap should fix this, though when >>>> that'll happend depends on the snap builder's schedule. >>>> >>> >>> Not sure if the fix made it into RAMDISK_CD #282, but this panic is >>> slightly different. I haven't tried reproducing to see if the panic >>> message differs between boots. >>> >>> <snip> >>> root on rd0a swap on rd0b dump on rd0b >>> uvm_fault(0xffffff011f73ac60, 0x208, 0, 1) -> e >>> fatal page fault in supervisor mode >>> trap type 6 code 0 rip ffffffff8135510b cs 8 rflags 10246 cr2 208 cpl >>> 0 rsp ffff800022026c90 >>> gsbase 0xffffffff81870ff0 kgsbase 0x0 >>> panic: trap type 6, code=0, pc=ffffffff8135510b >>> syncing disk... done >>> >>> dump to dev 17,1 not possible >>> rebooting... >>> </snip> >>> >>> Hope this helps. >>> >> >> FWIW, the vbox capture feature is pretty buggy - it doesn't create the >> file when it says it is recording, and it frequently crashes. It is >> possible the panic above is from #281 instead, because I deleted the >> video before I realizing this. >> >> Below is definitely from #282. >> >> <snip> >> Welcome to the OpenBSD/amd64 6.4 installation program. >> fatal protection fault in supervisor mode >> trap type 4 code 0 rip ffffffff810f4244 cs 8 rflags 10286 cr2 6c1fed >> cpl a rsp ffff800022098800 >> gsbase 0xffffffff81870ff0 kgsbase 0x0 >> panic: trap type 4, code 0, pc=0x ffffffff810f4244 >> syncing disks... done >> >> dump to dev 17,1 not possible >> rebooting... >> </snip> >> >> Hope this is actually useful and not another stupid VirtualBox bug. > > I see this an almost identical panic on real hardware too, the only difference > being the string after 'rsp' > > Welcome to the OpenBSD/amd64 6.4 installation program. > fatal protection fault in supervisor mode > trap type 4 code 0 rip ffffffff810f4244 cs 8 rflags 10286 cr2 6c1fed cpl a > rsp ffff8000220ba9e0 > gsbase 0xffffffff81870ff0 kgsbase 0x0 > panic: trap type 4, code 0, pc=ffffffff810f4244 > syncing disks... done > > dump to dev 17,1 not possible > rebooting... > > Below is first the working dmesg snapshot, and then one from booting bsd.rd, > note > the ACPI error about not being able to load tables, that's not there on the > working > snap. That might be the culprit at least in my case? >
FYI - successfully booted with RAMDISK_CD #283 and installed a successfully-booting GENERIC #284 within VirtualBox. Thanks again. --david
