Guests running OpenIndiana (and relatives) fail to boot on AMD hardware

Bug #1034423 reported by Owen Tuz
8
This bug affects 1 person
Affects Status Importance Assigned to Milestone
QEMU
Expired
Undecided
Unassigned

Bug Description

First observed with OpenSolaris 2009.06, and also applies to the latest OpenIndiana release.

Version: qemu-kvm 1.1.1

Hardware:

2 x AMD Opteron 6128 8-core processors, 64GB RAM.

These guests boot on equivalent Intel hardware.

To reproduce:

qemu-kvm -nodefaults -m 512 -cpu host -vga cirrus -usbdevice tablet -vnc :99 -monitor stdio -hda drive.img -cdrom oi-dev-151a5-live-x86.iso -boot order=dc

I've tested with "-vga std" and various different emulated CPU types, to no effect.

What happens:

GRUB loads, and offers multiple boot options, but none work. Some kind of kernel panic flies by very fast before restarting the VM, and careful use of the screenshot button reveals that it reads as follows:

panic[cpu0]/thread=fec22de0: BAD TRAP: type=8 (#df Double fault) rp=fec2b48c add r=0

#df Double fault
pid=0, pc=0xault
pid=0, pc=0xfe800377, sp=0xfec40090, eflags=0x202
cr0: 80050011<pg,wp,et,pe> cr4:b8<pge,pae,pse,de>
cr2: 0cr3: ae2f000
              gs: 1b0 fs: 0 es: 160 ds: 160
             edi: 0 esi: 0 ebp: 0 esp: fec2b4c4
             ebx: c0010015 edx: 0 ecx: 0 eax: fec40400
             trp: 8 err: 0 eip: fe800377 cs: 158
             efl: 202 usp: fec40090 ss: 160
tss.tss_link: 0x0
tss.tss_esp0: 0x0
tss.tss_ss0: 0x160
tss.tss_esp1: 0x0
tss.tss_ss1: 0x0
tss.tss esp2: 0x0
tss.tss_ss2: 0x0
tss.tss_cr3: 0xae2f000
tss.tss_eip: 0xfec40400
tss.tss_eflags: 0x202
tss.tss_eax: 0xfec40400
tss.tss_ebx: 0xc0010015
tss.tss_ecx: 0xc0010000
tss.tss_edx: 0x0
tss.tss_esp: 0xfec40090

Warning - stack not written to the dumpbuf
fec2b3c8 unix:due+e4 (8, fec2b48c, 0, 0)
fec2b478 unix:trap+12fa (fec2b48c, 0, 0)
fec2b48c unix:_cmntrap+7c (1b0, 0, 160, 160, 0)

If there's any more, I haven't managed to catch it.

Solaris 11 does not seem to suffer from the same issue, although the first message that appears at boot (after the version info) is "trap: Unkown trap type 8 in user mode". Could be related?

As always, thanks in advance and please let me know if I can help to test, or provide any more information.

Revision history for this message
Thomas Huth (th-huth) wrote :

Triaging old bug tickets ... can you still reproduce this issue with the latest version of QEMU (currently v2.9)?

Changed in qemu:
status: New → Incomplete
Revision history for this message
Owen Tuz (owentuz) wrote : Re: [Bug 1034423] Re: Guests running OpenIndiana (and relatives) fail to boot on AMD hardware
Download full text (3.2 KiB)

This is an old ticket! I had completely forgotten about it, but will test
when I get a chance and let you know.

Cheers,

Owen

On Fri, May 19, 2017 at 11:25 AM, Thomas Huth <email address hidden>
wrote:

> Triaging old bug tickets ... can you still reproduce this issue with the
> latest version of QEMU (currently v2.9)?
>
> ** Changed in: qemu
> Status: New => Incomplete
>
> --
> You received this bug notification because you are subscribed to the bug
> report.
> https://bugs.launchpad.net/bugs/1034423
>
> Title:
> Guests running OpenIndiana (and relatives) fail to boot on AMD
> hardware
>
> Status in QEMU:
> Incomplete
>
> Bug description:
> First observed with OpenSolaris 2009.06, and also applies to the
> latest OpenIndiana release.
>
> Version: qemu-kvm 1.1.1
>
> Hardware:
>
> 2 x AMD Opteron 6128 8-core processors, 64GB RAM.
>
> These guests boot on equivalent Intel hardware.
>
> To reproduce:
>
> qemu-kvm -nodefaults -m 512 -cpu host -vga cirrus -usbdevice tablet
> -vnc :99 -monitor stdio -hda drive.img -cdrom oi-dev-
> 151a5-live-x86.iso -boot order=dc
>
> I've tested with "-vga std" and various different emulated CPU types,
> to no effect.
>
> What happens:
>
> GRUB loads, and offers multiple boot options, but none work. Some kind
> of kernel panic flies by very fast before restarting the VM, and
> careful use of the screenshot button reveals that it reads as follows:
>
> panic[cpu0]/thread=fec22de0: BAD TRAP: type=8 (#df Double fault)
> rp=fec2b48c add r=0
>
> #df Double fault
> pid=0, pc=0xault
> pid=0, pc=0xfe800377, sp=0xfec40090, eflags=0x202
> cr0: 80050011<pg,wp,et,pe> cr4:b8<pge,pae,pse,de>
> cr2: 0cr3: ae2f000
> gs: 1b0 fs: 0 es:
> 160 ds: 160
> edi: 0 esi: 0 ebp:
> 0 esp: fec2b4c4
> ebx: c0010015 edx: 0 ecx: 0 eax:
> fec40400
> trp: 8 err: 0 eip: fe800377
> cs: 158
> efl: 202 usp: fec40090 ss: 160
> tss.tss_link: 0x0
> tss.tss_esp0: 0x0
> tss.tss_ss0: 0x160
> tss.tss_esp1: 0x0
> tss.tss_ss1: 0x0
> tss.tss esp2: 0x0
> tss.tss_ss2: 0x0
> tss.tss_cr3: 0xae2f000
> tss.tss_eip: 0xfec40400
> tss.tss_eflags: 0x202
> tss.tss_eax: 0xfec40400
> tss.tss_ebx: 0xc0010015
> tss.tss_ecx: 0xc0010000
> tss.tss_edx: 0x0
> tss.tss_esp: 0xfec40090
>
> Warning - stack not written to the dumpbuf
> fec2b3c8 unix:due+e4 (8, fec2b48c, 0, 0)
> fec2b478 unix:trap+12fa (fec2b48c, 0, 0)
> fec2b48c unix:_cmntrap+7c (1b0, 0, 160, 160, 0)
>
> If there's any more, I haven't managed to catch it.
>
> Solaris 11 does not seem to suffer from the same issue, although the
> first message that appears at boot (after the version info) is "trap:
> Unkown trap type 8 in user mode". Could be related?
>
> As always, thanks in advance and please let me know if I can help to
> test, or provide any more information.
>
> To manage notifications about this bug go to:...

Read more...

Revision history for this message
Launchpad Janitor (janitor) wrote :

[Expired for QEMU because there has been no activity for 60 days.]

Changed in qemu:
status: Incomplete → Expired
Revision history for this message
Eric Levy (8mabmzqcnyc1g4i7tjyvuprzli-contact-clubl5mz6ldresgvtiayqw6wzb) wrote (last edit ):
Download full text (6.1 KiB)

Despite the age of the report, I am also reproducing the issue.

I am using Qemu 6.2.0 with KVM on Linux kernel 6.0.5 under Linux Mint 21.

The guest is OpenIndiana Hipster 2021.10.

A guest console capture is attached.

The guest is managed using libvirt 8.0.0

The dump of the libvirt domain configuration is as follows:

<domain type='kvm' id='62'>
  <name>openindiana</name>
  <uuid>7a7adcc0-889c-4daf-a73b-21a3fac3d8e7</uuid>
  <metadata>
    <libosinfo:libosinfo xmlns:libosinfo="http://libosinfo.org/xmlns/libvirt/domain/1.0">
      <libosinfo:os id="http://libosinfo.org/linux/2020"/>
    </libosinfo:libosinfo>
  </metadata>
  <memory unit='KiB'>2097152</memory>
  <currentMemory unit='KiB'>2097152</currentMemory>
  <vcpu placement='static'>4</vcpu>
  <resource>
    <partition>/machine</partition>
  </resource>
  <os>
    <type arch='x86_64' machine='pc-i440fx-jammy'>hvm</type>
    <loader readonly='yes' type='pflash'>/usr/share/OVMF/OVMF_CODE_4M.fd</loader>
    <nvram template='/usr/share/OVMF/OVMF_VARS_4M.fd'>/var/lib/libvirt/qemu/nvram/openindiana_VARS.fd</nvram>
  </os>
  <features>
    <acpi/>
    <apic/>
    <vmport state='off'/>
  </features>
  <cpu mode='host-passthrough' check='none' migratable='on'/>
  <clock offset='utc'>
    <timer name='rtc' tickpolicy='catchup'/>
    <timer name='pit' tickpolicy='delay'/>
    <timer name='hpet' present='no'/>
  </clock>
  <on_poweroff>destroy</on_poweroff>
  <on_reboot>restart</on_reboot>
  <on_crash>destroy</on_crash>
  <pm>
    <suspend-to-mem enabled='no'/>
    <suspend-to-disk enabled='no'/>
  </pm>
  <devices>
    <emulator>/usr/bin/qemu-system-x86_64</emulator>
    <disk type='file' device='disk'>
      <driver name='qemu' type='qcow2'/>
      <source file='/srv/vhd/openindiana.qcow2' index='2'/>
      <backingStore/>
      <target dev='sda' bus='sata'/>
      <alias name='sata0-0-0'/>
      <address type='drive' controller='0' bus='0' target='0' unit='0'/>
    </disk>
    <disk type='file' device='cdrom'>
      <driver name='qemu' type='raw'/>
      <source file='/srv/img/OI-hipster-minimal-20211031.iso' index='1'/>
      <backingStore/>
      <target dev='sdb' bus='sata'/>
      <readonly/>
      <boot order='1'/>
      <alias name='sata0-0-1'/>
      <address type='drive' controller='0' bus='0' target='0' unit='1'/>
    </disk>
    <controller type='usb' index='0' model='ich9-ehci1'>
      <alias name='usb'/>
      <address type='pci' domain='0x0000' bus='0x00' slot='0x05' function='0x7'/>
    </controller>
    <controller type='usb' index='0' model='ich9-uhci1'>
      <alias name='usb'/>
      <master startport='0'/>
      <address type='pci' domain='0x0000' bus='0x00' slot='0x05' function='0x0' multifunction='on'/>
    </controller>
    <controller type='usb' index='0' model='ich9-uhci2'>
      <alias name='usb'/>
      <master startport='2'/>
      <address type='pci' domain='0x0000' bus='0x00' slot='0x05' function='0x1'/>
    </controller>
    <controller type='usb' index='0' model='ich9-uhci3'>
      <alias name='usb'/>
      <master startport='4'/>
      <address type='pci' domain='0x0000' bus='0x00' slot='0x05' function='0x2'/>
    </controller>
    <controller type='pci' index='...

Read more...

Revision history for this message
Thomas Huth (th-huth) wrote :

This bug tracker here is not used anymore. Could you please open a new ticket here:

https://gitlab.com/qemu-project/qemu/-/issues

Thanks!

To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.