From patchwork Tue Jun 16 16:47:45 2009 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Markus Armbruster X-Patchwork-Id: 30643 Received: from vger.kernel.org (vger.kernel.org [209.132.176.167]) by demeter.kernel.org (8.14.2/8.14.2) with ESMTP id n5GGlutS029444 for ; Tue, 16 Jun 2009 16:47:56 GMT Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1758353AbZFPQrs (ORCPT ); Tue, 16 Jun 2009 12:47:48 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1755761AbZFPQrs (ORCPT ); Tue, 16 Jun 2009 12:47:48 -0400 Received: from mx2.redhat.com ([66.187.237.31]:54001 "EHLO mx2.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1754066AbZFPQrr (ORCPT ); Tue, 16 Jun 2009 12:47:47 -0400 Received: from int-mx2.corp.redhat.com (int-mx2.corp.redhat.com [172.16.27.26]) by mx2.redhat.com (8.13.8/8.13.8) with ESMTP id n5GGlmlT005740; Tue, 16 Jun 2009 12:47:48 -0400 Received: from ns3.rdu.redhat.com (ns3.rdu.redhat.com [10.11.255.199]) by int-mx2.corp.redhat.com (8.13.1/8.13.1) with ESMTP id n5GGllWF018122; Tue, 16 Jun 2009 12:47:47 -0400 Received: from pike.pond.sub.org (vpn-10-49.str.redhat.com [10.32.10.49]) by ns3.rdu.redhat.com (8.13.8/8.13.8) with ESMTP id n5GGljEQ012943; Tue, 16 Jun 2009 12:47:46 -0400 Received: by pike.pond.sub.org (Postfix, from userid 1000) id 57C3910081; Tue, 16 Jun 2009 18:47:45 +0200 (CEST) To: kvm@vger.kernel.org Cc: hch@lst.de, Marcelo Tosatti Subject: virtio-blk-pci chokes on some PCI slots From: Markus Armbruster Date: Tue, 16 Jun 2009 18:47:45 +0200 Message-ID: <87fxe0t9am.fsf@pike.pond.sub.org> User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/22.3 (gnu/linux) MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.58 on 172.16.27.26 Sender: kvm-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: kvm@vger.kernel.org I'm working on make PCI slots configurable in QEMU. While testing the feature for virtio-blk-pci, I ran into a task hang with Fedora kernel 2.6.27.5-117.fc10. Marcelo tested it with a newer kernel, and will follow up with details. Instead of the full QEMU patch I'm working on, the appended little hack suffices to reproduce the problem. $ QEMU_VIRTIO_BLK=9 qemu foo.qcow2 -drive file=bar.img,if=virtio -serial stdio [...] Loading virtio_pci module ACPI: PCI Interrupt Link [LNKD] enabled at IRQ 11 virtio-pci 0000:00:04.0: PCI INT A -> Link[LNKD] -> GSI 11 (level, low) -> IRQ 11 virtio-pci 0000:00:09.0: can't derive routing for PCI INT A virtio-pci 0000:00:09.0: PCI INT A: no GSI - using IRQ 11 Loading virtio_blk module vda: [tick-tock-tick-tock...] <3>INFO: task modprobe:491 blocked for more than 120 seconds. "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message. modprobe D c04303f1 0 491 1 c6baeae8 00000082 c6baea80 c04303f1 c6bae000 c087667c c0879c00 c0879c00 c0879c00 c6b659b0 c6b65c24 c1108c00 00000000 c1108c00 83a43d86 00000002 c781aaa8 c6baead0 c04418d0 c6b65c24 00004d88 c781aaa8 00004d88 c6baeb3c Call Trace: [] ? irq_exit+0x5f/0x83 [] ? getnstimeofday+0x3c/0xc9 [] ? ktime_get_ts+0x4a/0x4e [] io_schedule+0x52/0x8a [] sync_page+0x46/0x4c [] __wait_on_bit_lock+0x34/0x5e [] ? sync_page+0x0/0x4c [] __lock_page+0x78/0x81 [] ? wake_bit_function+0x0/0x43 [] lock_page+0x2c/0x2f [] read_cache_page_async+0xa4/0xfb [] ? blkdev_readpage+0x0/0x11 [] read_cache_page+0xc/0x3c [] read_dev_sector+0x34/0x6a [] ? efi_partition+0x0/0x676 [] read_lba+0x69/0xc6 [] ? efi_partition+0x84/0x676 [] ? efi_partition+0x0/0x676 [] efi_partition+0xa3/0x676 [] ? vprintk+0x2c8/0x2f3 [] ? iget5_locked+0x33/0x114 [] ? snprintf+0x15/0x17 [] ? efi_partition+0x0/0x676 [] rescan_partitions+0x106/0x242 [] ? need_resched+0x18/0x22 [] ? _cond_resched+0x8/0x32 [] do_open+0x1ff/0x290 [] __blkdev_get+0x71/0x7c [] blkdev_get+0xd/0xf [] register_disk+0xf0/0x141 [] add_disk+0x34/0x89 [] ? exact_match+0x0/0xb [] ? exact_lock+0x0/0x11 [] virtblk_probe+0x275/0x2a8 [virtio_blk] [] virtio_dev_probe+0x89/0xb3 [] driver_probe_device+0xa0/0x136 [] __driver_attach+0x3a/0x59 [] bus_for_each_dev+0x3b/0x63 [] driver_attach+0x14/0x16 [] ? __driver_attach+0x0/0x59 [] bus_add_driver+0x9d/0x1ba [] driver_register+0x81/0xe1 [] ? register_blkdev+0xc8/0xdc [] register_virtio_driver+0x1f/0x21 [] init+0x22/0x24 [virtio_blk] [] _stext+0x3d/0x115 [] ? init+0x0/0x24 [virtio_blk] [] sys_init_module+0x87/0x178 [] syscall_call+0x7/0xb ======================= Some slots work, e.g. 5, some don't, e.g. 6. What's going on here? --- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html diff --git a/hw/pc.c b/hw/pc.c index 143b697..15c44ac 100644 --- a/hw/pc.c +++ b/hw/pc.c @@ -1146,7 +1146,8 @@ static void pc_init1(ram_addr_t ram_size, int unit_id = 0; while ((index = drive_get_index(IF_VIRTIO, 0, unit_id)) != -1) { - pci_create_simple(pci_bus, -1, "virtio-blk-pci"); + char *devfn = getenv("QEMU_VIRTIO_BLK"); + pci_create_simple(pci_bus, devfn ? atoi(devfn) * 8: -1, "virtio-blk-pci"); unit_id++; } }