From mboxrd@z Thu Jan 1 00:00:00 1970 From: "James Harper" Subject: RE: hang on restore in 3.3.1 Date: Thu, 12 Feb 2009 00:08:07 +1100 Message-ID: References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Return-path: Content-class: urn:content-classes:message List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com To: James Harper , Keir Fraser , xen-devel@lists.xensource.com List-Id: xen-devel@lists.xenproject.org > > On 11/02/2009 09:51, "James Harper" > wrote: > > > > > What do you think the chances are of it being a qemu problem? the > > > xentrace code would indicate that it was the hypervisor asserting the > > > interrupt, but that wouldn't preclude qemu from being the originator > of > > > the interrupt would it? > > > > Most interrupts come from qemu, since it emulates most devices. > Switching > > your qemu is a pretty easy test (build internal old version rather than > > out-of-tree new version). > > >=20 > I just rebooted with my GPLPV drivers inactive (eg not hiding qemu > devices, leaving the PV network device with 'disconnected' and not > enumerating block devices), and I found that an NDIS device is using > vector 0x93, which will be the qemu realtek device. I hide it on boot, but > I forgot to hide it again after the restore which will probably be the > cause of my problems... hopefully hiding it on restore again will stop it > generating interrupts! Well it's not the qemu realtek device like I thought it was - I tried it on a domain with no network interfaces at all. The other thing that uses that vector is the USB interface. I have noticed that after a restore, the restored computer has reverted back to the 'mouse' rather than the 'tablet' driver... maybe there is something in that? I'll keep looking. James