Hi, I've activated Peter Maydell's virtio-mmio changes, and I'm getting this lovely hang: [<c0356ff0>] (__schedule+0x22c/0x5ac) from [<c035796c>] (io_schedule+0x6c/0x9c) [<c035796c>] (io_schedule+0x6c/0x9c) from [<c006aa6c>] (sleep_on_page+0x8/0x10) [<c006aa6c>] (sleep_on_page+0x8/0x10) from [<c0355ec8>] (__wait_on_bit_lock+0x6c/0xb8) [<c0355ec8>] (__wait_on_bit_lock+0x6c/0xb8) from [<c006b548>] (__lock_page+0x94/0x9c) [<c006b548>] (__lock_page+0x94/0x9c) from [<c006b888>] (do_read_cache_page+0x13c/0x15c) [<c006b888>] (do_read_cache_page+0x13c/0x15c) from [<c006cc38>] (read_cache_page_async+0x18/0x20) [<c006cc38>] (read_cache_page_async+0x18/0x20) from [<c006cc74>] (read_cache_page+0x8/0x10) [<c006cc74>] (read_cache_page+0x8/0x10) from [<c018c7f8>] (read_dev_sector+0x2c/0x64) [<c018c7f8>] (read_dev_sector+0x2c/0x64) from [<c018ce68>] (msdos_partition+0x94/0x574) [<c018ce68>] (msdos_partition+0x94/0x574) from [<c018c908>] (check_partition+0xd8/0x1ec) [<c018c908>] (check_partition+0xd8/0x1ec) from [<c018c5a8>] (rescan_partitions+0xb8/0x2dc) [<c018c5a8>] (rescan_partitions+0xb8/0x2dc) from [<c00cbf58>] (__blkdev_get+0x218/0x338) [<c00cbf58>] (__blkdev_get+0x218/0x338) from [<c00cc1d8>] (blkdev_get+0x160/0x2dc) [<c00cc1d8>] (blkdev_get+0x160/0x2dc) from [<c018a32c>] (add_disk+0x340/0x40 [<c018a32c>] (add_disk+0x340/0x400) from [<c034abf8>] (virtblk_probe+0x5a8/0) [<c034abf8>] (virtblk_probe+0x5a8/0x690) from [<c01b6ac8>] (virtio_dev_probe4/0x15c) [<c01b6ac8>] (virtio_dev_probe+0xf4/0x15c) from [<c01f0b2c>] (driver_probe_de+0x70/0x170) [<c01f0b2c>] (driver_probe_device+0x70/0x170) from [<c01f0cb8>] (__driver_at+0x8c/0x90) ---snip--- This comes immediately after virtio-mmio in the kernel sends out a notify, and after virtio_queue_notify and virtio_mmio_update_irq/qemu_set_irq get called in qemu. My question is: qemu is raising an IRQ with n equal to 42. Does that mean that the kernel sees IRQ 42 go up? Because it if does, then that's the wrong irq. Or is it the handler method that actually picks which number IRQ will go up? Alex -------------- next part -------------- An HTML attachment was scrubbed... URL: https://lists.cs.columbia.edu/pipermail/android-virt/attachments/20120329/b75ef07e/attachment-0001.html