Project

General

Profile

Bug #1857

"No SOF interrupts have been received..USB UHCI is unusable" under KVM

Added by Yakov Zaytsev almost 8 years ago. Updated 5 months ago.

Status:
New
Priority:
Normal
Assignee:
-
Category:
-
Start date:
2011-12-05
Due date:
% Done:

0%

Estimated time:
Difficulty:
Medium
Tags:
needs-triage

Description

Sunplus Innovation Technology USB to Serial-ATA bridge does not work under Fedora 16 KVM

$ dmesg | grep -i sof
Dec  5 21:20:39 oi usba: [ID 691482 kern.warning] WARNING: /pci@0,0/pci1af4,1100@1,2 (uhci1): No SOF interrupts have been received, this USB UHCI host controller is unusable
Dec  5 21:32:04 oi usba: [ID 691482 kern.warning] WARNING: /pci@0,0/pci1af4,1100@1,2 (uhci1): No SOF interrupts have been received, this USB UHCI host controller is unusable
Dec  5 21:32:20 oi usba: [ID 691482 kern.warning] WARNING: /pci@0,0/pci1af4,1100@1,2 (uhci1): No SOF interrupts have been received, this USB UHCI host controller is unusable
Dec  5 21:32:30 oi usba: [ID 691482 kern.warning] WARNING: /pci@0,0/pci1af4,1100@1,2 (uhci1): No SOF interrupts have been received, this USB UHCI host controller is unusable

Files

dmesg (19 KB) dmesg Michal Nowak, 2019-05-05 11:53 AM

History

#1

Updated by Rich Lowe almost 8 years ago

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?

#2

Updated by Richard Yao over 7 years ago

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

#3

Updated by Jakub Žitný over 7 years ago

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.

#4

Updated by Jakub Žitný over 7 years ago

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.

#5

Updated by Yuri Pankov over 6 years ago

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

#6

Updated by Jan Kalina over 1 year ago

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/

#7

Updated by Yuri Pankov over 1 year ago

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?

#8

Updated by Gary Mills over 1 year ago

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

#9

Updated by Yuri Pankov over 1 year ago

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.

#10

Updated by Michal Nowak 5 months ago

Recently I started seeing several of these warnings in VirtualBox 6.0.6 on OpenIndiana while uptodate OpenIndiana is booting: WARNING: /pci@0,0/pci8086,265c@b (ehci0): No SOF interrupts have been received, this USB EHCI hostcontroller is unusable.

Also available in: Atom PDF