On Tue, Sep 26, 2017 at 01:19:04PM -0400, Daniel Wilkins wrote: > On Tue, Sep 26, 2017 at 02:21:34AM -0700, Mike Larkin wrote: > > On Tue, Sep 26, 2017 at 01:26:47AM -0400, Daniel Wilkins wrote: > > > On Mon, Sep 25, 2017 at 10:16:21PM -0700, Mike Larkin wrote: > > > > Please define "enough times". > > > > > > > > -ml > > > > > > Sadly it's not consistent. I think I got to 7 boots this time today or so; > > > 5-10 seems like a good estimate to me. Pretty sure I've had it happen > > > after 3 > > > boots, think I got to 11 or 12 once. Since I don't recall whether I > > > brought > > > it up on the original email the OS is irrelevant as far as I can tell, > > > I've > > > had Linux trigger it, had OpenBSD trigger it, had Plan9 trigger it, I > > > think > > > I triggered it once when I was seeing if I could get a DOS running in > > > there. > > > > > > > Please provide your vm.conf or equivalent vmctl start command line, and the > > vmd -dv log output (pkill -9 vmd && vmd -dv and then vmctl log verbose) > > when the issue occurs. > > > > -ml > > > > I've attached vm.conf (whether or not I have it is irrelevant though) and a > script > session with the commands asked to make sure I didn't miss anything. The > vmctl start > was the most minimal that triggers it, which is literally just "put it on an > image that > wants a bios". vmd.log looks like the vm stuff somehow gets into a state > where an interrupt > is messed up that seabios triggers?
> startup > vm_opentty: vm lottie tty /dev/ttyp5 uid 0 gid 4 mode 620 > lottie: started vm 12 successfully, tty /dev/ttyp5 > loadfile_bios: loaded BIOS image > run_vm: initializing hardware for vm lottie > run_vm: starting vcpu threads for vm lottie > vcpu_reset: resetting vcpu 0 for vm 12 > run_vm: waiting on events for VM lottie > i8259_write_datareg: master pic, reset IRQ vector to 0x8 > i8259_write_datareg: slave pic, reset IRQ vector to 0x70 > virtio_blk_io: device reset > i8259_nonspecific_eoi: master pic nonspecific eoi not supported > Script started on Tue Sep 26 13:11:04 2017 > # pkill -9 vmd > # cd lottie > # # vmd -dv 2> vmd.log & > [1] 98067 > # vmctl log verbose > # vmctl start lottie -d lottie.img > > > > > # vmctl start lottie -d lottie.img -c > vmctl: starting without network interfaces > Connected to /dev/ttyp5 (speed 9600) > Changing serial settings was 0/0 now 3/0 > SeaBIOS (version 1.10.2p2-OpenBSD-vmm) This is slightly downlevel. Probably not the issue but you might want to fw_update anyway. IIRC your machine is a Westmere. I have one of those too and I ran through about 20 or 30 vmm+seabios boots just now without any problem. I'm wondering if it's a leak of some sort, since my machine has more memory than yours. Do you get more boots if you reduce the memory on each vmm boot to 128MB or 256MB? -ml > BUILD: gcc: (GCC) 4.2.1 20070719 binutils: 2.17 > enabling shadow ram > Unable to unlock ram - bridge not found > RamSize: 0x20000000 [cmos] > malloc preinit > malloc init > init ivt > init bda > init bios32 > init keyboard > init pic > math cp init > pci setup > === PCI bus & bridge init === > PCI: pci_bios_init_bus_rec bus = 0x0 > === PCI device probing === > PCI probe > Found 4 PCI devices (max PCI bus is 00) > === PCI new allocation pass #1 === > PCI: check devices > === PCI new allocation pass #2 === > PCI: IO: c000 - efff > PCI: 32: 0000000020000000 - 00000000fec00000 > PCI: map device bdf=00:01.0 bar 0, addr 0000c000, size 00001000 [io] > PCI: map device bdf=00:02.0 bar 0, addr 0000d000, size 00001000 [io] > PCI: map device bdf=00:03.0 bar 0, addr 0000e000, size 00001000 [io] > PCI: map device bdf=00:00.0 bar 6, addr febfc000, size 00001000 [mem] > PCI: map device bdf=00:01.0 bar 6, addr febfd000, size 00001000 [mem] > PCI: map device bdf=00:02.0 bar 6, addr febfe000, size 00001000 [mem] > PCI: map device bdf=00:03.0 bar 6, addr febff000, size 00001000 [mem] > PCI: init bdf=00:00.0 id=0b5d:0666 > PCI: init bdf=00:01.0 id=1af4:1005 > PCI: init bdf=00:02.0 id=1af4:1001 > PCI: init bdf=00:03.0 id=0b5d:0777 > PCI: No VGA devices found > No apic - only the main cpu is present. > init timer > init virtio-blk > found virtio-blk at 00:02.0 > pci dev 00:02.0 using legacy (0.9.5) virtio mode > virtio-blk 00:02.0 blksize=512 sectors=104857600 > Registering bootable: Virtio disk PCI:00:02.0 (type:2 prio:9999 data:f1f70) > init serial > Found 1 serial ports > Searching bootorder for: HALT > Mapping hd drive 0x000f1f70 to 0 > drive 0x000f1f70: PCHS=0/0/0 translation=lba LCHS=1024/255/63 s=104857600 > malloc finalize > Space available for UMB: c0000-ef000, f0000-f1f70 > Returned 253952 bytes of ZoneHigh > e820 map has 6 items: > 0: 0000000000000000 - 000000000009fc00 = 1 RAM > 1: 000000000009fc00 - 00000000000a0000 = 2 RESERVED > 2: 00000000000f0000 - 0000000000100000 = 2 RESERVED > 3: 0000000000100000 - 000000001fffe000 = 1 RAM > 4: 000000001fffe000 - 0000000020000000 = 2 RESERVED > 5: 00000000fffc0000 - 0000000100000000 = 2 RESERVED > locking shadow ram > Unable to lock ram - bridge not found > Jump to int19 > enter handle_19: > NULL > enter handle_18: > NULL > invalid handle_legacy_disk:729: > a=00000201 b=00000000 c=00000001 d=00000000 ds=0000 es=07c0 ss=0000 > si=00000000 di=00000000 bp=00000000 sp=000066dc cs=f000 ip=d9bf f=0202 > enter handle_18: > NULL > > [EOT] > # exit > > Script done on Tue Sep 26 13:12:19 2017
