Hi, here is the patch. Can you please give it a try?
From 41039df3174fa46477c4faf93d13eab360dccc22 Mon Sep 17 00:00:00 2001
Message-Id:
41039df3174fa46477c4faf93d13eab360dccc22.1312196365.git.yamah...@valinux.co.jp
From: Isaku Yamahata yamah...@valinux.co.jp
Date: Mon, 1 Aug 2011 19:56:42
Am 01.08.2011 13:00, schrieb Isaku Yamahata:
Hi, here is the patch. Can you please give it a try?
From 41039df3174fa46477c4faf93d13eab360dccc22 Mon Sep 17 00:00:00 2001
Message-Id:
41039df3174fa46477c4faf93d13eab360dccc22.1312196365.git.yamah...@valinux.co.jp
From: Isaku Yamahata
Am 19.07.2011 04:39, schrieb Isaku Yamahata:
Thank you for addressing this. Similar patches were proposed and
weren't merged unfortunately.
The reason why the qdev_register_reset() in vl.c is to keep the reset order.
The reset for main_system_bus shouldn't registered by qbus_create_inplace().
On Tue, Jul 19, 2011 at 07:56:41AM +0200, Stefan Weil wrote:
Am 19.07.2011 04:39, schrieb Isaku Yamahata:
Thank you for addressing this. Similar patches were proposed and
weren't merged unfortunately.
The reason why the qdev_register_reset() in vl.c is to keep the reset order.
The reset for
qbus_reset_all_fn was registered twice, so a lot of device reset
functions were also called twice when QEMU started.
It is sufficient to call sysbus_get_default() which will
register qbus_reset_all_fn.
Signed-off-by: Stefan Weil w...@mail.berlios.de
---
vl.c |2 +-
1 files changed, 1
Thank you for addressing this. Similar patches were proposed and
weren't merged unfortunately.
The reason why the qdev_register_reset() in vl.c is to keep the reset order.
The reset for main_system_bus shouldn't registered by qbus_create_inplace().
But the check, bus != main_system_bus, doesn't
