Note: This bug is displayed in read-only format because
the product is no longer active in Red Hat Bugzilla.
RHEL Engineering is moving the tracking of its product development work on RHEL 6 through RHEL 9 to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "RHEL project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs in the statuses "NEW", "ASSIGNED", and "POST" are being migrated throughout September 2023. Bugs of Red Hat partners with an assigned Engineering Partner Manager (EPM) are migrated in late September as per pre-agreed dates. Bugs against components "kernel", "kernel-rt", and "kpatch" are only migrated if still in "NEW" or "ASSIGNED". If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "RHEL project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/RHEL-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.
Created attachment 612346[details]
qemu log entry
Description of problem:
Using virt-manager to start guest "jetVM2" with PCI host device: serial card assigned to it, qemu-kvm fails to assign IRQ, and aborts the guest startup
Version-Release number of selected component (if applicable):
Linux jetta 2.6.32-279.5.2.el6.x86_64 #1 SMP Fri Aug 24 01:07:11 UTC 2012 x86_64
qemu-kvm-0.12.1.2-2.295.el6_3.1.x86_64
libvirt-0.9.10-21.el6_3.4.x86_64
How reproducible:
everytime
Steps to Reproduce:
1. create windows 7 guest
2. assign PCI serial card
3. attempt to start guest
Actual results:
Messages to host serial console:
IRQ handler type mismatch for IRQ 16
current handler: uhci_hcd:usb3
IRQ handler type mismatch for IRQ 16
current handler: uhci_hcd:usb3
Expected results:
Sadly, given my luck lately of using PCI device assignment, I sort of expected the system to lock up completely, but that may be coming ...
Additional info:
dmesg has more info:
pci-stub 0000:06:04.0: claimed by stub
device vnet0 entered promiscuous mode
mybr0: port 2(vnet0) entering forwarding state
device vnet1 entered promiscuous mode
mybr1: port 2(vnet1) entering forwarding state
pci-stub 0000:06:04.0: PCI INT A -> GSI 16 (level, low) -> IRQ 16
pci-stub 0000:06:04.0: restoring config space at offset 0xf (was 0x100, writing 0x10b)
pci-stub 0000:06:04.0: restoring config space at offset 0xc (was 0x0, writing 0x1)
pci-stub 0000:06:04.0: restoring config space at offset 0x6 (was 0x0, writing 0xf3de0000)
pci-stub 0000:06:04.0: restoring config space at offset 0x5 (was 0x1, writing 0xbc01)
pci-stub 0000:06:04.0: restoring config space at offset 0x4 (was 0x0, writing 0xf3ddf000)
pci-stub 0000:06:04.0: restoring config space at offset 0x3 (was 0x0, writing 0x4010)
pci-stub 0000:06:04.0: restoring config space at offset 0x1 (was 0x2b00000, writing 0x2b00117)
assign device: host bdf = 6:4:0
IRQ handler type mismatch for IRQ 16
current handler: uhci_hcd:usb3
Pid: 2756, comm: qemu-kvm Not tainted 2.6.32-279.5.2.el6.x86_64 #1
Call Trace:
[<ffffffff810dcb72>] ? __setup_irq+0x382/0x3c0
[<ffffffff810dd2a4>] ? request_threaded_irq+0x154/0x2f0
[<ffffffffa0399610>] ? kvm_assigned_dev_intr+0x0/0xd0 [kvm]
[<ffffffffa039c5cd>] ? kvm_vm_ioctl+0xcfd/0x1060 [kvm]
[<ffffffff8113f447>] ? handle_pte_fault+0xf7/0xb50
[<ffffffff814213bc>] ? pci_mmap_page_range+0x6c/0xa0
[<ffffffff812951a4>] ? pci_mmap_resource+0xd4/0x190
[<ffffffff81421aa3>] ? pci_conf1_read+0xc3/0x120
[<ffffffff81423863>] ? raw_pci_read+0x23/0x40
[<ffffffff814238fc>] ? pci_read+0x2c/0x30
[<ffffffff8128a34c>] ? pci_user_read_config_byte+0x5c/0xa0
[<ffffffffa039d436>] ? kvm_dev_ioctl+0xa6/0x570 [kvm]
[<ffffffff8100bc0e>] ? apic_timer_interrupt+0xe/0x20
[<ffffffff8118e142>] ? vfs_ioctl+0x22/0xa0
[<ffffffff8118e2c0>] ? do_vfs_ioctl+0x60/0x580
[<ffffffff8118e60a>] ? do_vfs_ioctl+0x3aa/0x580
[<ffffffff8117bbaf>] ? vfs_read+0x12f/0x1a0
[<ffffffff8118e861>] ? sys_ioctl+0x81/0xa0
[<ffffffff8100b0f2>] ? system_call_fastpath+0x16/0x1b
deassign device: host bdf = 6:4:0
pci-stub 0000:06:04.0: restoring config space at offset 0xf (was 0x100, writing 0x10b)
pci-stub 0000:06:04.0: restoring config space at offset 0xc (was 0x0, writing 0x1)
pci-stub 0000:06:04.0: restoring config space at offset 0x6 (was 0x0, writing 0xf3de0000)
pci-stub 0000:06:04.0: restoring config space at offset 0x5 (was 0x1, writing 0xbc01)
pci-stub 0000:06:04.0: restoring config space at offset 0x4 (was 0x0, writing 0xf3ddf000)
pci-stub 0000:06:04.0: restoring config space at offset 0x3 (was 0x0, writing 0x4010)
pci-stub 0000:06:04.0: restoring config space at offset 0x1 (was 0x2b00000, writing 0x2b00117)
pci-stub 0000:06:04.0: PCI INT A disabled
mybr0: port 2(vnet0) entering disabled state
device vnet0 left promiscuous mode
mybr0: port 2(vnet0) entering disabled state
mybr1: port 2(vnet1) entering disabled state
device vnet1 left promiscuous mode
mybr1: port 2(vnet1) entering disabled state
nf_conntrack version 0.5.0 (16384 buckets, 65536 max)
I will attach output from lscpi -vv
The host machine is a Dell Precision R5500 rackmount workstation, and the serial card is a PMC card mounted on a PMC-to-PCI carrier card using an Intel 31154 P2P bridge (BDF 05:04.0)
Upon boot, the system reports unsupported PM capability for the serial card:
0000:06:04.0: unsupported PM cap regs version (7)
After power cycle, lspci reports IRQ 11 for the serial card. Is libvirt changing the interrupt to use IRQ 16, where it conflicts with uhci_hcd:usb3 ?
Should I try to start the guest from the qemu CLI?
Today the maker of the serial card helped me fix the version of the Power Management capabilities, and I worked around the conflict with IRQ 16 of the usb device by unbinding that device from the uhci_hcd driver and binding it to pci-stub. The guest VM started up correctly. Next I will install the windows driver and API and test if that software seems to work correctly.
Testing of the serial card (with the added power management support in firmware) in a windows guest went very well.
The problem of IRQ 16 conflicts with a USB port has not appeared on a newer system which was installed from the latest RHEL 6.3 images. The system I was using when I first saw the problem was actually installed as 6.2 and then upgraded to 6.3. so I only need to disable the USB port as a workaround on that system.
Unless further testing is required to follow-up on interrupt assignment fixes, I guess we could just go ahead and close this bug.
Card seems to not support PCI2.3 INTx disable so requires an exclusive interrupt. Closing since this is now working correctly after unbinding conflicting interrupts.
Created attachment 612346 [details] qemu log entry Description of problem: Using virt-manager to start guest "jetVM2" with PCI host device: serial card assigned to it, qemu-kvm fails to assign IRQ, and aborts the guest startup Version-Release number of selected component (if applicable): Linux jetta 2.6.32-279.5.2.el6.x86_64 #1 SMP Fri Aug 24 01:07:11 UTC 2012 x86_64 qemu-kvm-0.12.1.2-2.295.el6_3.1.x86_64 libvirt-0.9.10-21.el6_3.4.x86_64 How reproducible: everytime Steps to Reproduce: 1. create windows 7 guest 2. assign PCI serial card 3. attempt to start guest Actual results: Messages to host serial console: IRQ handler type mismatch for IRQ 16 current handler: uhci_hcd:usb3 IRQ handler type mismatch for IRQ 16 current handler: uhci_hcd:usb3 Expected results: Sadly, given my luck lately of using PCI device assignment, I sort of expected the system to lock up completely, but that may be coming ... Additional info: dmesg has more info: pci-stub 0000:06:04.0: claimed by stub device vnet0 entered promiscuous mode mybr0: port 2(vnet0) entering forwarding state device vnet1 entered promiscuous mode mybr1: port 2(vnet1) entering forwarding state pci-stub 0000:06:04.0: PCI INT A -> GSI 16 (level, low) -> IRQ 16 pci-stub 0000:06:04.0: restoring config space at offset 0xf (was 0x100, writing 0x10b) pci-stub 0000:06:04.0: restoring config space at offset 0xc (was 0x0, writing 0x1) pci-stub 0000:06:04.0: restoring config space at offset 0x6 (was 0x0, writing 0xf3de0000) pci-stub 0000:06:04.0: restoring config space at offset 0x5 (was 0x1, writing 0xbc01) pci-stub 0000:06:04.0: restoring config space at offset 0x4 (was 0x0, writing 0xf3ddf000) pci-stub 0000:06:04.0: restoring config space at offset 0x3 (was 0x0, writing 0x4010) pci-stub 0000:06:04.0: restoring config space at offset 0x1 (was 0x2b00000, writing 0x2b00117) assign device: host bdf = 6:4:0 IRQ handler type mismatch for IRQ 16 current handler: uhci_hcd:usb3 Pid: 2756, comm: qemu-kvm Not tainted 2.6.32-279.5.2.el6.x86_64 #1 Call Trace: [<ffffffff810dcb72>] ? __setup_irq+0x382/0x3c0 [<ffffffff810dd2a4>] ? request_threaded_irq+0x154/0x2f0 [<ffffffffa0399610>] ? kvm_assigned_dev_intr+0x0/0xd0 [kvm] [<ffffffffa039c5cd>] ? kvm_vm_ioctl+0xcfd/0x1060 [kvm] [<ffffffff8113f447>] ? handle_pte_fault+0xf7/0xb50 [<ffffffff814213bc>] ? pci_mmap_page_range+0x6c/0xa0 [<ffffffff812951a4>] ? pci_mmap_resource+0xd4/0x190 [<ffffffff81421aa3>] ? pci_conf1_read+0xc3/0x120 [<ffffffff81423863>] ? raw_pci_read+0x23/0x40 [<ffffffff814238fc>] ? pci_read+0x2c/0x30 [<ffffffff8128a34c>] ? pci_user_read_config_byte+0x5c/0xa0 [<ffffffffa039d436>] ? kvm_dev_ioctl+0xa6/0x570 [kvm] [<ffffffff8100bc0e>] ? apic_timer_interrupt+0xe/0x20 [<ffffffff8118e142>] ? vfs_ioctl+0x22/0xa0 [<ffffffff8118e2c0>] ? do_vfs_ioctl+0x60/0x580 [<ffffffff8118e60a>] ? do_vfs_ioctl+0x3aa/0x580 [<ffffffff8117bbaf>] ? vfs_read+0x12f/0x1a0 [<ffffffff8118e861>] ? sys_ioctl+0x81/0xa0 [<ffffffff8100b0f2>] ? system_call_fastpath+0x16/0x1b deassign device: host bdf = 6:4:0 pci-stub 0000:06:04.0: restoring config space at offset 0xf (was 0x100, writing 0x10b) pci-stub 0000:06:04.0: restoring config space at offset 0xc (was 0x0, writing 0x1) pci-stub 0000:06:04.0: restoring config space at offset 0x6 (was 0x0, writing 0xf3de0000) pci-stub 0000:06:04.0: restoring config space at offset 0x5 (was 0x1, writing 0xbc01) pci-stub 0000:06:04.0: restoring config space at offset 0x4 (was 0x0, writing 0xf3ddf000) pci-stub 0000:06:04.0: restoring config space at offset 0x3 (was 0x0, writing 0x4010) pci-stub 0000:06:04.0: restoring config space at offset 0x1 (was 0x2b00000, writing 0x2b00117) pci-stub 0000:06:04.0: PCI INT A disabled mybr0: port 2(vnet0) entering disabled state device vnet0 left promiscuous mode mybr0: port 2(vnet0) entering disabled state mybr1: port 2(vnet1) entering disabled state device vnet1 left promiscuous mode mybr1: port 2(vnet1) entering disabled state nf_conntrack version 0.5.0 (16384 buckets, 65536 max) I will attach output from lscpi -vv The host machine is a Dell Precision R5500 rackmount workstation, and the serial card is a PMC card mounted on a PMC-to-PCI carrier card using an Intel 31154 P2P bridge (BDF 05:04.0) Upon boot, the system reports unsupported PM capability for the serial card: 0000:06:04.0: unsupported PM cap regs version (7)