illumos gate

I've seen this basic symptom a lot on older systems, depending on such things as:

- Whether the BIOS is set to use "Legacy" USB or not
- The devices connected to that (USB) bus
- Seemingly random chance

The "SOF interrupt" referred to is the USB start of frame interrupt, we expect to receive one within an interval I've forgotten of enabling them. If we don't, as you see, we log a message and "give up" (in practice, we try several more times).

I remember looking through other operating system to see whether they bothered to wait for the SOF, and I think came to the conclusion that they didn't, and that perhaps we were being overly conservative. I remember reading the USB spec too, but I don't remember what, if anything, it said.

Either way, it's perhaps worth the time to check all of this out. Most directly, what happens if we don't treat the lack of an initial SOF as fatal?

I can reproduce this in qemu-kvm on Linux:

qemu-system-x86_64 -enable-kvm -vnc :1 -net nic,model=rtl8139,macaddr=52:54:00:00:ff:02 -net user -M pc-1.0 -cpu phenom,+wdt,+skinit,+osvw,+3dnowprefetch,+misalignsse,+sse4a,+abm,+cr8legacy,+extapic,+cmp_legacy,+lahf_lm,+rdtscp,+pdpe1gb,+popcnt,+cx16,+ht,+vme -enable-kvm -m 1024 -smp 6,sockets=1,cores=6,threads=1 -name OpenIndiana -rtc base=utc -drive file=/dev/zvol/rpool/KVM/openindiana,if=ide,format=raw -drive file=/mnt/backup/oi-dev-151a-x86.iso,if=ide,media=cdrom,readonly=on,format=raw -boot d -device piix4-usb-uhci -usbdevice tablet

The same problem in virsh with qemu-kvm on Linux.

My domain looks like this. It's relatively the same as above.

<domain type="kvm">
   <name>oi</name>
   <vcpu>2</vcpu>
   <memory>2129920</memory>
   <os>
     <type>hvm</type>
     <boot dev="hd"/>
   </os>
   <features>
     <pae/>
     <acpi/>
   </features>
   <devices>
     <emulator>/usr/bin/kvm</emulator>
     <console type="pty" tty="/dev/pts/2">
       <source path="/dev/pts/2"/>
       <target port="1"/>
     </console>
     <serial type="pty" tty="/dev/pts/2">
       <source path="/dev/pts/2"/>
       <target port="1"/>
     </serial>
     <graphics type="vnc" listen="0.0.0.0" port="-1" />
     <interface type="bridge">
       <source bridge="br0"/>
       <mac address="54:52:00:65:26:89"/>
     </interface>
     <disk type="file" device="cdrom">
         <readonly/>
         <target dev="hdc"/>
         <source file="/root/openindiana/oi.iso"/>
     </disk>
     <disk type="file" device="disk">
       <driver name="qemu" type="qcow2" cache="none"/>
       <target dev="hda"/>
       <source file="/root/openindiana/oi.qcow2"/>
     </disk>
   </devices>
 </domain>

I'll try to look into it.

So the -usb parameter in qemu is responsible for this.

Qemu and Qemu-kvm have both problems with hot-plugging devices. They have (or had) some funcionality with hotplugging cpus, memory, interfaces and disks. USB, raw and qcow2 disks are ellible to be hotplugged on linux systems and memory balloning too. According to this we could disable the uhci controller (i think) and the "No SOF interrupts have been received..USB UHCI is unusable" messages will disappear. Following command will do it:

rem_drv uhci

I tried this on OpenIndiana 151a server version in virsh using qemu. Everything works fine. And the whole quest system starts faster. Probably this is definitely not anu illumos bug, but the qemu problem.

More on pci/uhci/ehci driver problems in Solaris and derivatives:
http://docs.oracle.com/cd/E19253-01/816-5177/6mbbc4g4l/index.html
http://198.62.75.4/opt/sun_docs/C/solaris_10/SUNWaman/hman7d/ehci.7d.html.

Same problem on xen (no wonder as it uses qemu for the hvm stuff). I'll try what Rich proposed in [1].

This warning (and DHCP under solaris) can be resolved by disabling x2APIC in KVM configuration:

sudo virsh edit MyVirtualMachine
<cpu ...>...
    <model...
    <feature policy='disable' name='x2apic'/>
</cpu>

More about this problem: https://liquidat.wordpress.com/2016/01/08/howto-solaris-11-on-kvm/

Seeing the same with ehci on HPE ProLiant DL380 Gen10. Removing the check as suggested by Rich allowed me to boot the installation media from virtual (USB) CD with working virtual (USB) keyboard, both not working previously because of "No SOF interrupts have been received". So may be this check is actually harmful as apparently it's not done by other OSes and we should simply remove it?

Have you tried disabling HPET support in the BIOS? That solves the problem on real hardware.

Gary Mills wrote:

Have you tried disabling HPET support in the BIOS? That solves the problem on real hardware.

Yes, doesn't help on this system.

This looks like UHCI variant of #14287.