On 2010-10-09 03:10, Arjan Koers wrote:
On 2010-10-09 00:06, Marcelo Tosatti wrote:
...
Backports attached. Michael, Arjan, please give them a try.
Thanks for the patches.
Successfully tested with 2.6.34.7, 2.6.35.7 and 2.6.36-rc7 host
(with a 2.6.35.7 guest).
Here's a smaller
On Mon, Oct 11, 2010 at 10:47:16AM -1000, Zachary Amsden wrote:
On 10/08/2010 10:59 PM, Arjan Koers wrote:
On 2010-10-09 08:29, Michael Tokarev wrote:
...
The result is that no released linux kernel boots
in smp in kvm, which is a linux virtual machine.
That's irony, isn't it?
I wonder
On 10/08/2010 09:27 PM, Zachary Amsden wrote:
On 10/08/2010 03:10 PM, Arjan Koers wrote:
On 2010-10-09 00:06, Marcelo Tosatti wrote:
On Thu, Oct 07, 2010 at 04:47:11PM -1000, Zachary Amsden wrote:
On 10/07/2010 02:12 PM, Arjan Koers wrote:
On 2010-10-03 01:42, Zachary Amsden wrote:
...
On Mon, Oct 11, 2010 at 12:53:26PM -0500, Anthony Liguori wrote:
On 10/08/2010 09:27 PM, Zachary Amsden wrote:
On 10/08/2010 03:10 PM, Arjan Koers wrote:
On 2010-10-09 00:06, Marcelo Tosatti wrote:
On Thu, Oct 07, 2010 at 04:47:11PM -1000, Zachary Amsden wrote:
On 10/07/2010 02:12 PM, Arjan
On 10/08/2010 10:59 PM, Arjan Koers wrote:
On 2010-10-09 08:29, Michael Tokarev wrote:
...
The result is that no released linux kernel boots
in smp in kvm, which is a linux virtual machine.
That's irony, isn't it?
I wonder how distributions (which are almost all based
on 2.6.32 nowadays)
09.10.2010 06:27, Zachary Amsden wrote:
[]
There's a lot of work I've done and also a lot of work done by Glauber
Costa on kvmclock that recently went upstream.
I've seen your series that went into 2.6.36-to-be.
And tried to apply to a stable kernel series (2.6.32)
near the beginning of this
09.10.2010 02:06, Marcelo Tosatti wrote:
[]
commit bd59fc8ff95126f27b7a0df1b6cc602aa428812d
Author: Zachary Amsdenzams...@redhat.com
Date: Thu Aug 19 22:07:26 2010 -1000
[]
commit aad07c4f92bae2edaa42bcef84c2afdd0d082458
Author: Zachary Amsdenzams...@redhat.com
Date: Thu Aug 19 22:07:19
09.10.2010 11:59, Michael Tokarev wrote:
[]
As far as I can see, most of these can be dealt with
by re-loading kvm modules. Let me try these and some
of the earlier patches...
So the two one-line backports, while applied to the
_host_ kvm modules, eliminated all the issues I had
so far with
On 2010-10-09 08:29, Michael Tokarev wrote:
...
The result is that no released linux kernel boots
in smp in kvm, which is a linux virtual machine.
That's irony, isn't it?
I wonder how distributions (which are almost all based
on 2.6.32 nowadays) will deal with the issue.. ;)
It looks like
On 2010-10-09 04:27, Zachary Amsden wrote:
...
There's a lot of work I've done and also a lot of work done by Glauber
Costa on kvmclock that recently went upstream.
It's unlikely that you'll be bug free without all of those patches
applied; most of the patches were not just enhancements, but
On 2010-10-09 03:10, Arjan Koers wrote:
On 2010-10-09 00:06, Marcelo Tosatti wrote:
On Thu, Oct 07, 2010 at 04:47:11PM -1000, Zachary Amsden wrote:
On 10/07/2010 02:12 PM, Arjan Koers wrote:
On 2010-10-03 01:42, Zachary Amsden wrote:
...
Umm... do you guys have this commit? This is
On Thu, Oct 07, 2010 at 04:47:11PM -1000, Zachary Amsden wrote:
On 10/07/2010 02:12 PM, Arjan Koers wrote:
On 2010-10-03 01:42, Zachary Amsden wrote:
...
Umm... do you guys have this commit? This is supposed to address the
issue where the guest keeps resetting the TSC. A guest which does
On 2010-10-09 00:06, Marcelo Tosatti wrote:
On Thu, Oct 07, 2010 at 04:47:11PM -1000, Zachary Amsden wrote:
On 10/07/2010 02:12 PM, Arjan Koers wrote:
On 2010-10-03 01:42, Zachary Amsden wrote:
...
Umm... do you guys have this commit? This is supposed to address the
issue where the guest
On 10/08/2010 03:10 PM, Arjan Koers wrote:
On 2010-10-09 00:06, Marcelo Tosatti wrote:
On Thu, Oct 07, 2010 at 04:47:11PM -1000, Zachary Amsden wrote:
On 10/07/2010 02:12 PM, Arjan Koers wrote:
On 2010-10-03 01:42, Zachary Amsden wrote:
...
Umm... do you guys
On 10/08/2010 03:10 PM, Arjan Koers wrote:
On 2010-10-09 00:06, Marcelo Tosatti wrote:
On Thu, Oct 07, 2010 at 04:47:11PM -1000, Zachary Amsden wrote:
On 10/07/2010 02:12 PM, Arjan Koers wrote:
On 2010-10-03 01:42, Zachary Amsden wrote:
...
Umm... do you guys
On 2010-10-03 01:42, Zachary Amsden wrote:
...
Umm... do you guys have this commit? This is supposed to address the
issue where the guest keeps resetting the TSC. A guest which does that
will break kvmclock. It only happens on SMP, and it's much worse on AMD
CPUs...
sound like your
On 10/07/2010 02:12 PM, Arjan Koers wrote:
On 2010-10-03 01:42, Zachary Amsden wrote:
...
Umm... do you guys have this commit? This is supposed to address the
issue where the guest keeps resetting the TSC. A guest which does that
will break kvmclock. It only happens on SMP, and it's
03.10.2010 01:55, Zachary Amsden wrote:
On 10/01/2010 09:35 PM, Michael Tokarev wrote:
[]
[0.04] APIC delta adjusted to PM-Timer: 6248670 (6435422)
[0.050298] Booting Node 0, Processors #1 Ok.
[0.023332] Initializing CPU#1
Before this, time is very granular...
[
On 10/03/2010 10:16 AM, Michael Tokarev wrote:
I just booted this same guest using kvm-0.12.5 - using that one
guest does not report unstable tsc, yet does not list it in the
available_clocksources. It also shows time jumps:
...
[0;0/0:0.00] Detected 3217.424 MHz processor.
[0;0/0:
03.10.2010 03:42, Zachary Amsden wrote:
[]
Umm... do you guys have this commit? This is supposed to address the
issue where the guest keeps resetting the TSC. A guest which does that
will break kvmclock. It only happens on SMP, and it's much worse on AMD
CPUs...
sound like your
03.10.2010 12:16, Michael Tokarev wrote:
Host is using tsc, and this is the only available clocksource now.
It was long time ago when I looked at this last - usually all
standard 3, also hpet and acpi_pm, are available too. This is
AthlonII CPU, which has synced tsc. I upgraded the CPU this
02.10.2010 09:35, Zachary Amsden wrote:
[]
Can you try this patch to see if it helps? I believe it is also safe
for Xen, but cc'ing to double check.
It makes no visible difference.
For some reason one of my test guests - 2.6.35.6 32bit kernel -
stopped booting completely, always handing at
02.10.2010 11:35, Michael Tokarev wrote:
[]
[0.25] ata1: PATA max MWDMA2 cmd 0x1f0 ctl 0x3f6 bmdma 0xc000 irq 14
[0.25] ata2: PATA max MWDMA2 cmd 0x170 ctl 0x376 bmdma 0xc008 irq 15
Note the time - it is constant after switching to kvmclock.
Another interesting observation.
Ugh. Replying to myself again and again, but I found all these
variants quite interesting for the problem at hand.
02.10.2010 11:40, Michael Tokarev wrote:
02.10.2010 11:35, Michael Tokarev wrote:
[]
[0.25] ata1: PATA max MWDMA2 cmd 0x1f0 ctl 0x3f6 bmdma 0xc000 irq 14
[0.25]
On 2010-10-02 09:35, Michael Tokarev wrote:
02.10.2010 09:35, Zachary Amsden wrote:
[]
Can you try this patch to see if it helps? I believe it is also safe
for Xen, but cc'ing to double check.
It makes no visible difference.
For some reason one of my test guests - 2.6.35.6 32bit kernel
02.10.2010 20:10, Arjan Koers wrote:
[]
I'm pretty sure that your kernel will boot with this debug patch (for
2.6.35.7). It doesn't fix the problem, but corrects things afterwards.
The patch sets the clock backwards if it detects that the previous
value was far into the future. It also
On 10/01/2010 09:35 PM, Michael Tokarev wrote:
02.10.2010 09:35, Zachary Amsden wrote:
[]
Can you try this patch to see if it helps? I believe it is also safe
for Xen, but cc'ing to double check.
It makes no visible difference.
For some reason one of my test guests - 2.6.35.6 32bit
On 10/02/2010 06:10 AM, Arjan Koers wrote:
On 2010-10-02 09:35, Michael Tokarev wrote:
02.10.2010 09:35, Zachary Amsden wrote:
[]
Can you try this patch to see if it helps? I believe it is also safe
for Xen, but cc'ing to double check.
It makes no visible difference.
For
On 09/30/2010 01:07 PM, Michael Tokarev wrote:
01.10.2010 03:02, Michael Tokarev wrote:
30.09.2010 23:05, Marcelo Tosatti wrote:
[]
Arjan, Michael, can you try the following:
From 3823c018162dc708b543cbdc680a4c7d63533fee Mon Sep 17 00:00:00 2001
From: Zachary
29.09.2010 23:26, Arjan Koers wrote:
On 2010-09-29 11:19, Michael Tokarev wrote:
29.09.2010 13:17, Michael Tokarev wrote:
[]
Avi, this is definitely a -stable material, for 2.6.32 (longterm
stable) and 2.6.35.
Er. Please excuse me for the misinformation. It is _not_ for 2.6.32
ofcourse.
30.09.2010 11:55, Michael Tokarev wrote:
29.09.2010 23:26, Arjan Koers wrote:
On 2010-09-29 11:19, Michael Tokarev wrote:
29.09.2010 13:17, Michael Tokarev wrote:
[]
Avi, this is definitely a -stable material, for 2.6.32 (longterm
stable) and 2.6.35.
Er. Please excuse me for the
On 09/29/2010 11:59 PM, Michael Tokarev wrote:
30.09.2010 11:55, Michael Tokarev wrote:
29.09.2010 23:26, Arjan Koers wrote:
On 2010-09-29 11:19, Michael Tokarev wrote:
29.09.2010 13:17, Michael Tokarev wrote:
[]
Avi, this is definitely a -stable material,
30.09.2010 17:54, Zachary Amsden wrote:
[]
The printk movement is just a bandaid patch, correct? Anything which
does printk before kvmclock is registered could trigger the same bug.
Well, I'd not say it's just a bandaid patch, it's real bug -- either
we can read kvmclock (so it's initialized),
On 2010-09-30 17:32, Zachary Amsden wrote:
On 09/30/2010 05:12 AM, Michael Tokarev wrote:
30.09.2010 17:54, Zachary Amsden wrote:
[]
The printk movement is just a bandaid patch, correct? Anything which
does printk before kvmclock is registered could trigger the same bug.
Well,
On 2010-09-30 21:05, Marcelo Tosatti wrote:
Arjan, Michael, can you try the following:
From 3823c018162dc708b543cbdc680a4c7d63533fee Mon Sep 17 00:00:00 2001
From: Zachary Amsden zams...@redhat.com
Date: Sat, 29 May 2010 17:52:46 -1000
Subject: [KVM V2 04/25] Fix SVM VMCB reset
Cc: Avi
30.09.2010 23:05, Marcelo Tosatti wrote:
[]
Arjan, Michael, can you try the following:
From 3823c018162dc708b543cbdc680a4c7d63533fee Mon Sep 17 00:00:00 2001
From: Zachary Amsden zams...@redhat.com
Date: Sat, 29 May 2010 17:52:46 -1000
Subject: [KVM V2 04/25] Fix SVM VMCB reset
Cc: Avi
01.10.2010 03:02, Michael Tokarev wrote:
30.09.2010 23:05, Marcelo Tosatti wrote:
[]
Arjan, Michael, can you try the following:
From 3823c018162dc708b543cbdc680a4c7d63533fee Mon Sep 17 00:00:00 2001
From: Zachary Amsden zams...@redhat.com
Date: Sat, 29 May 2010 17:52:46 -1000
Subject: [KVM
On 09/30/2010 01:07 PM, Michael Tokarev wrote:
01.10.2010 03:02, Michael Tokarev wrote:
30.09.2010 23:05, Marcelo Tosatti wrote:
[]
Arjan, Michael, can you try the following:
From 3823c018162dc708b543cbdc680a4c7d63533fee Mon Sep 17 00:00:00 2001
From: Zachary
Ping? ;)
28.09.2010 15:16, Michael Tokarev wrote:
Arjan Koers 0h61vkll2ly8 at xutrox.com writes:
Move a printk that's using the clock before it's ready
Fix a hang during SMP kernel boot on KVM that showed up
after commit 489fb490dbf8dab0249ad82b56688ae3842a79e8
(2.6.35) and
On 08/03/2010 12:35 AM, Arjan Koers wrote:
I don't think that pvclock_clocksource_read is receiving
completely random uninitialized data. The values in shadow
are wrong, but could be interpreted as valid data
(shadow.tsc_to_nsec_mul = b6dc43b6, shadow.tsc_shift = ,
shadow.flags = 0 and
29.09.2010 12:28, Avi Kivity wrote:
On 08/03/2010 12:35 AM, Arjan Koers wrote:
I don't think that pvclock_clocksource_read is receiving
completely random uninitialized data. The values in shadow
are wrong, but could be interpreted as valid data
(shadow.tsc_to_nsec_mul = b6dc43b6,
29.09.2010 13:17, Michael Tokarev пишет:
29.09.2010 12:28, Avi Kivity wrote:
On 08/03/2010 12:35 AM, Arjan Koers wrote:
I don't think that pvclock_clocksource_read is receiving
completely random uninitialized data. The values in shadow
are wrong, but could be interpreted as valid data
On 2010-09-29 11:19, Michael Tokarev wrote:
29.09.2010 13:17, Michael Tokarev пишет:
29.09.2010 12:28, Avi Kivity wrote:
On 08/03/2010 12:35 AM, Arjan Koers wrote:
I don't think that pvclock_clocksource_read is receiving
completely random uninitialized data. The values in shadow
are wrong,
Arjan Koers 0h61vkll2ly8 at xutrox.com writes:
[]
I've attached the printk patches for 2.6.34.1 and 2.6.35, in case
anyone needs them...
Move a printk that's using the clock before it's ready
Fix a hang during SMP kernel boot on KVM that showed up
after commit
Zachary Amsden wrote:
On 07/28/2010 02:25 AM, Andre Przywara wrote:
Andre Przywara wrote:
Andre Przywara wrote:
Avi Kivity wrote:
On 07/27/2010 04:48 PM, Andre Przywara wrote:
Wierd. Maybe the clock goes crazy.
Let's see if it jumps forward alot:
} while (unlikely(last !=
On Sat, Jul 31, 2010 at 01:55:10PM -1000, Zachary Amsden wrote:
On 07/31/2010 06:36 AM, Arjan Koers wrote:
On 2010-07-31 13:53, Arjan Koers wrote:
The kernel boots successfully when CONFIG_PRINTK_TIME is not set.
The problem occurs when this message is printed:
[0.016000] kvm-clock:
On 2010-08-02 16:43, Glauber Costa wrote:
On Sat, Jul 31, 2010 at 01:55:10PM -1000, Zachary Amsden wrote:
On 07/31/2010 06:36 AM, Arjan Koers wrote:
On 2010-07-31 13:53, Arjan Koers wrote:
The kernel boots successfully when CONFIG_PRINTK_TIME is not set.
The problem occurs when this message
On Mon, Aug 02, 2010 at 06:16:16PM +0200, Arjan Koers wrote:
On 2010-08-02 16:43, Glauber Costa wrote:
On Sat, Jul 31, 2010 at 01:55:10PM -1000, Zachary Amsden wrote:
On 07/31/2010 06:36 AM, Arjan Koers wrote:
On 2010-07-31 13:53, Arjan Koers wrote:
The kernel boots successfully when
On 08/02/2010 04:43 AM, Glauber Costa wrote:
On Sat, Jul 31, 2010 at 01:55:10PM -1000, Zachary Amsden wrote:
On 07/31/2010 06:36 AM, Arjan Koers wrote:
On 2010-07-31 13:53, Arjan Koers wrote:
The kernel boots successfully when CONFIG_PRINTK_TIME is not set.
The
On Mon, Aug 02, 2010 at 10:26:30AM -1000, Zachary Amsden wrote:
On 08/02/2010 04:43 AM, Glauber Costa wrote:
On Sat, Jul 31, 2010 at 01:55:10PM -1000, Zachary Amsden wrote:
On 07/31/2010 06:36 AM, Arjan Koers wrote:
On 2010-07-31 13:53, Arjan Koers wrote:
The kernel boots successfully when
On 2010-08-02 22:26, Zachary Amsden wrote:
On 08/02/2010 04:43 AM, Glauber Costa wrote:
On Sat, Jul 31, 2010 at 01:55:10PM -1000, Zachary Amsden wrote:
On 07/31/2010 06:36 AM, Arjan Koers wrote:
On 2010-07-31 13:53, Arjan Koers wrote:
The kernel boots successfully when
On 08/02/2010 11:35 AM, Arjan Koers wrote:
On 2010-08-02 22:26, Zachary Amsden wrote:
On 08/02/2010 04:43 AM, Glauber Costa wrote:
On Sat, Jul 31, 2010 at 01:55:10PM -1000, Zachary Amsden wrote:
On 07/31/2010 06:36 AM, Arjan Koers wrote:
On 2010-07-31 13:53,
On 2010-07-31 03:38, Zachary Amsden wrote:
How are you printing shadow.version? From a local variable captured
during the barrier window or directly in a printk afterwards? If should
never go backwards like this, and the vcpus come from a zalloc. This is
not easily explainable by anything
On 2010-07-31 04:39, Zachary Amsden wrote:
On 07/30/2010 02:34 PM, Arjan Koers wrote:
On 2010-07-28 12:37, Avi Kivity wrote:
On 07/28/2010 12:00 AM, Arjan Koers wrote:
On 2010-07-26 20:59, Arjan Koers wrote:
I ran into the same problem. 2.6.34.1 and 2.6.35-rc6 SMP guest
On 2010-07-31 13:53, Arjan Koers wrote:
The kernel boots successfully when CONFIG_PRINTK_TIME is not set.
The problem occurs when this message is printed:
[0.016000] kvm-clock: cpu 1, msr 0:1511c01, secondary cpu clock
When I disable that printk, the kernel boots with
On 2010-07-31 18:36, Arjan Koers wrote:
On 2010-07-31 13:53, Arjan Koers wrote:
The kernel boots successfully when CONFIG_PRINTK_TIME is not set.
The problem occurs when this message is printed:
[0.016000] kvm-clock: cpu 1, msr 0:1511c01, secondary cpu clock
When I disable that
On 07/31/2010 06:36 AM, Arjan Koers wrote:
On 2010-07-31 13:53, Arjan Koers wrote:
The kernel boots successfully when CONFIG_PRINTK_TIME is not set.
The problem occurs when this message is printed:
[0.016000] kvm-clock: cpu 1, msr 0:1511c01, secondary cpu clock
When I disable
On 2010-07-28 12:37, Avi Kivity wrote:
On 07/28/2010 12:00 AM, Arjan Koers wrote:
On 2010-07-26 20:59, Arjan Koers wrote:
I ran into the same problem. 2.6.34.1 and 2.6.35-rc6 SMP guest
kernels hang during boot.
It appears that last is way ahead of ret twice.
The kernel boots with this
On 07/30/2010 02:34 PM, Arjan Koers wrote:
On 2010-07-28 12:37, Avi Kivity wrote:
On 07/28/2010 12:00 AM, Arjan Koers wrote:
On 2010-07-26 20:59, Arjan Koers wrote:
I ran into the same problem. 2.6.34.1 and 2.6.35-rc6 SMP guest
kernels hang during boot.
It
On 07/30/2010 02:34 PM, Arjan Koers wrote:
On 2010-07-28 12:37, Avi Kivity wrote:
On 07/28/2010 12:00 AM, Arjan Koers wrote:
On 2010-07-26 20:59, Arjan Koers wrote:
I ran into the same problem. 2.6.34.1 and 2.6.35-rc6 SMP guest
kernels hang during boot.
It
Zachary Amsden wrote:
On 07/27/2010 11:51 AM, Andre Przywara wrote:
Andre Przywara wrote:
Avi Kivity wrote:
On 07/27/2010 04:48 PM, Andre Przywara wrote:
Wierd. Maybe the clock goes crazy.
Let's see if it jumps forward alot:
} while (unlikely(last != ret));
+
+ {
+
On 07/28/2010 12:00 AM, Arjan Koers wrote:
On 2010-07-26 20:59, Arjan Koers wrote:
I ran into the same problem. 2.6.34.1 and 2.6.35-rc6 SMP guest
kernels hang during boot.
It appears that last is way ahead of ret twice.
The kernel boots with this debug patch that makes the clock go
Andre Przywara wrote:
Andre Przywara wrote:
Avi Kivity wrote:
On 07/27/2010 04:48 PM, Andre Przywara wrote:
Wierd. Maybe the clock goes crazy.
Let's see if it jumps forward alot:
} while (unlikely(last != ret));
+
+ {
+static u64 last_report;
+if
On 07/26/2010 11:47 AM, Andre Przywara wrote:
Does this go away with CONFIG_DEBUG_RODATA=n? If so, it's a known
bug in the atomic_*() clobber lists.
Unfortunately the bug persists even with CONFIG_DEBUG_RODATA disabled.
The debug options I had enabled now are:
CONFIG_DEBUG_DEVRES=y
Avi Kivity wrote:
On 07/26/2010 11:47 AM, Andre Przywara wrote:
Does this go away with CONFIG_DEBUG_RODATA=n? If so, it's a known
bug in the atomic_*() clobber lists.
Unfortunately the bug persists even with CONFIG_DEBUG_RODATA disabled.
The debug options I had enabled now are:
On 07/27/2010 02:49 PM, Andre Przywara wrote:
What is the guest executing when it hangs?
Both VCPUs are halted, the monitor and System.map tell me it's in
native_safe_halt().
The code sequence confirms this, it is an intentional sti;hlt condition.
Using -smp 16 also shows that all 16 VCPUs
Avi Kivity wrote:
On 07/27/2010 02:49 PM, Andre Przywara wrote:
What is the guest executing when it hangs?
Both VCPUs are halted, the monitor and System.map tell me it's in
native_safe_halt().
The code sequence confirms this, it is an intentional sti;hlt condition.
Using -smp 16 also shows
On 07/27/2010 03:21 PM, Andre Przywara wrote:
Avi Kivity wrote:
On 07/27/2010 02:49 PM, Andre Przywara wrote:
What is the guest executing when it hangs?
Both VCPUs are halted, the monitor and System.map tell me it's in
native_safe_halt().
The code sequence confirms this, it is an
Avi Kivity wrote:
On 07/27/2010 03:21 PM, Andre Przywara wrote:
Avi Kivity wrote:
On 07/27/2010 02:49 PM, Andre Przywara wrote:
What is the guest executing when it hangs?
Both VCPUs are halted, the monitor and System.map tell me it's in
native_safe_halt().
The code sequence confirms
On 07/27/2010 04:48 PM, Andre Przywara wrote:
Wierd. Maybe the clock goes crazy.
Let's see if it jumps forward alot:
} while (unlikely(last != ret));
+
+ {
+static u64 last_report;
+if (ret last_report + 1) {
+last_report = ret;
Avi Kivity wrote:
On 07/27/2010 04:48 PM, Andre Przywara wrote:
Wierd. Maybe the clock goes crazy.
Let's see if it jumps forward alot:
} while (unlikely(last != ret));
+
+ {
+static u64 last_report;
+if (ret last_report + 1) {
+
On 2010-07-26 20:59, Arjan Koers wrote:
I ran into the same problem. 2.6.34.1 and 2.6.35-rc6 SMP guest
kernels hang during boot.
It appears that last is way ahead of ret twice.
The kernel boots with this debug patch that makes the clock go
backwards if the difference is big:
last =
Andre Przywara wrote:
Avi Kivity wrote:
On 07/27/2010 04:48 PM, Andre Przywara wrote:
Wierd. Maybe the clock goes crazy.
Let's see if it jumps forward alot:
} while (unlikely(last != ret));
+
+ {
+static u64 last_report;
+if (ret last_report +
On 07/27/2010 11:51 AM, Andre Przywara wrote:
Andre Przywara wrote:
Avi Kivity wrote:
On 07/27/2010 04:48 PM, Andre Przywara wrote:
Wierd. Maybe the clock goes crazy.
Let's see if it jumps forward alot:
} while (unlikely(last != ret));
+
+ {
+static u64
Avi Kivity wrote:
On 07/22/2010 03:53 PM, Andre Przywara wrote:
Hi,
I found a regression with pvclock and SMP KVM _guests_.
PVCLOCK enabled guest kernels boot with qemu-kvm.git and with smp=1,
but with smp=2 halt at:
Serial: 8250/16550 driver, 4 ports, IRQ sharing enabled
(last line
Andre Przywara wrote:
Avi Kivity wrote:
On 07/22/2010 03:53 PM, Andre Przywara wrote:
Hi,
I found a regression with pvclock and SMP KVM _guests_.
PVCLOCK enabled guest kernels boot with qemu-kvm.git and with smp=1,
but with smp=2 halt at:
Serial: 8250/16550 driver, 4 ports, IRQ sharing
On 07/22/2010 03:53 PM, Andre Przywara wrote:
Hi,
I found a regression with pvclock and SMP KVM _guests_.
PVCLOCK enabled guest kernels boot with qemu-kvm.git and with smp=1,
but with smp=2 halt at:
Serial: 8250/16550 driver, 4 ports, IRQ sharing enabled
(last line shown)
I bisected this
Hi,
I found a regression with pvclock and SMP KVM _guests_.
PVCLOCK enabled guest kernels boot with qemu-kvm.git and with smp=1, but
with smp=2 halt at:
Serial: 8250/16550 driver, 4 ports, IRQ sharing enabled
(last line shown)
I bisected this down to:
commit
78 matches
Mail list logo
