From mboxrd@z Thu Jan 1 00:00:00 1970 From: Diana Crisan Subject: Re: HVM Migration of domU on Qemu-upstream DM loses ACPI data in xenstore Date: Tue, 21 May 2013 11:08:14 +0100 (BST) Message-ID: <485231334.10362771.1369130894695.JavaMail.root@zimbra002> References: <1369051279.10868.28.camel@zakaz.uk.xensource.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <1369051279.10868.28.camel@zakaz.uk.xensource.com> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org To: Ian Campbell Cc: Alex Bligh , xen-devel@lists.xen.org List-Id: xen-devel@lists.xenproject.org Hello Ian, >On Mon, 2013-05-20 at 12:50 +0100, Alex Bligh wrote: >> Ian, >> >> --On 20 May 2013 09:40:01 +0100 Ian Campbell >> wrote: >> >> > You could perhaps verify this somewhat by playing with the kernel's >> > clocksource= option. >> >> clocksource=[hpet|pit|tsc|acpi_pm|cyclone|scx200_hrt] >> >> I'm guessing clocksource=tsc is the least dependent on 'other stuff'. >It'd be a good one to start with. You should be able to confirm under >sysfs which one is used now, I'm guessing it is acpi_pm. >It'd be worth trying each of the first 4 though. cyclone and scx200 seem >a bit specific... I tested the first 4 options with both xen 4.2 and xen 4.3. Please see below my findings: Under 4.2: tsc: cannot use this as not HRT compatible; can't switch while in HRT/NOHZ mode hpet: activated according to dmesg; after migration got this error: "i8042 no controller found; pm: device i8042 failed to restore: error -19" and this error (??) got the clock stuck again pit: did not get an error, but it did not seem to have listened to my request as I could see in dmesg it reading my request to switch to clocksource=pit but choosing to set the xen clocksource. Under 4.3: tsc: as above, not HRT compatible so cannot use it. hpet: still get the clock stuck after several migrations (3-4 migrations) pit: as above it is ignored. acpi_pm: it seems to be easier to replicate the problem with this clocksource - got it on the first migrate. Notes: the wallclock (date) and RTC (clock -r) on the hosts were in sync within a second >> We'll have a play. >> >> >> Any ideas on how to debug this further? It is odd that the date command >> >> (used to set a date) will unstick the clock. >> > >> > I'd have thought that would only poke the RTC, but to be honest I'm not >> > sure. >> >> I'm pretty sure date itself only changes the wallclock (the clock command >> normally being needed to write to the RTC). >Yes, I think you are right. >> If the images are running >> ntp, that may notice the wallclock change and write to CMOS I guess. Please let me know if you need any more details. -- Diana Crisan