* Need help in debugging partially blocked hypervisor
@ 2009-10-21 13:07 Dietmar Hahn
2009-10-21 13:28 ` Keir Fraser
2009-10-30 12:20 ` Dietmar Hahn
0 siblings, 2 replies; 21+ messages in thread
From: Dietmar Hahn @ 2009-10-21 13:07 UTC (permalink / raw)
To: xen-devel
Hi,
I need some help in debugging a strange hypervisor behavior together
with using fully virtualized performance counters.
For info I use SLES11, means xen-3.3.1 and linux-2.6.27.19-5... on a
Intel nehalem machine.
I tried the hypervisor from xen-unstable but the machine didn't boot.
dom0 1 cpu
domU 2 cpu's
3 cpu's paused.
I start performance counter in domU and after some time the domU cpus
are running forever (seeing with xm vcpu-list) and the domU is not accessible.
dom0 is still working like expected.
Serial console doesn't react on 3xCTRL-A, but xm debug-keys prints it's output
on the serial console.
When I try to pause the domU (xm pause ...), using xenctx or some debug keys where
the domU must get paused, the dom0 freezes and only a hard reset helps, what
seems to come from the call of vcpu_sleep_sync().
I tried xentrace while in the strange state and saw only loggings from the CPU0
(dom0 cpu), what means for me that the domU CPU's are somewhere in the
hypervisor.
Attached is the output of "xm debug-keys d". I hope someone has an idea about the
direction where I have to look deeper.
Many thanks in advance!
Dietmar.
(XEN) 'd' pressed -> dumping registers
(XEN) *** Dumping CPU0 guest state (d0:v0): ***
(XEN) ----[ Xen-3.3.1 x86_64 debug=n Tainted: C ]----
(XEN) CPU: 0
(XEN) RIP: e033:[<ffffffff8020746a>]
(XEN) RFLAGS: 0000000000000216 EM: 0 CONTEXT: pv guest
(XEN) rax: 0000000000000023 rbx: ffffffff803c7505 rcx: ffffffff8020746a
(XEN) rdx: 00007fd955ef2f8a rsi: 00007fd95635dc00 rdi: 00007fd946ff9170
(XEN) rbp: ffffffffffffffda rsp: ffff8800da541dc0 r8: 00007fd956324390
(XEN) r9: 0000000000000002 r10: 0000000000000000 r11: 0000000000000216
(XEN) r12: ffff8800dbd42080 r13: ffff8800db4d5500 r14: 0000000000000000
(XEN) r15: 00007fd946ff9200 cr0: 0000000080050033 cr4: 00000000000026b0
(XEN) cr3: 000000025c880000 cr2: 00007fef4f880ad0
(XEN) ds: 0000 es: 0000 fs: 0000 gs: 0000 ss: e02b cs: e033
(XEN) Guest stack trace from rsp=ffff8800da541dc0:
(XEN) ffffffff80307263 ffffffff80207460 ffffffff803c7593 ffff8800ce4d7720
(XEN) 00000000da4fc067 ffff8800050a7180 ffffffff8028484c ffff8800ce1399c0
(XEN) 0000000000000003 0000000000000000 ffff8800ce1399c0 00007fd946ff9000
(XEN) 0000000000000000 0000000000000023 00007fd946ff9170 00007fd95635dc00
(XEN) 00007fd955ef2f8a 0000000000000000 00007fd956324390 ffff8800d9bc4780
(XEN) 0000000000000001 00007fd946ff9000 ffffffff803c7505 ffff8800dbd42100
(XEN) ffff8800dbd42080 ffff8800db4d5500 0000000000000000 00007fd946ff9200
(XEN) ffffffff802e0ae3 0030500046ff9000 ffff8800db4d5500 00007fd946ff9200
(XEN) 0000000000305000 0000000000000006 0000000000000006 00007fd956208608
(XEN) ffffffff802aa8b5 ffff8800db4d5500 ffff8800db4d5500 00007fd946ff9200
(XEN) ffffffff802aab22 0000000000001000 ffff8800dbde7520 00007fd946ff9000
(XEN) 0000000000000000 ffff8800db4d5500 00007fd946ff9200 0000000000305000
(XEN) ffffffff802aab82 0000000000000006 0000000100000001 0000000000000000
(XEN) 0000000001ce0b34 0000000001c8eed0 0000000000000006 0000000000000001
(XEN) ffffffff8020b3b8 0000000000000246 0000000000000000 0000000000000200
(XEN) fffffffffffffffd 0000000000000010 ffffffff8020b350 00007fd946ff9200
(XEN) 0000000000305000 0000000000000006 0000000000000010 00007fd95536fb77
(XEN) 000000000000e033 0000000000000246 00007fd946ff9168 000000000000e02b
(XEN) 0000000000000000 0000000000000000 0000000000000000 0000000000000000
(XEN) 0000000000000000 0000000000000000 0000000000000000 0000000000000000
(XEN)
(XEN) *** Dumping CPU1 host state: ***
(XEN) ----[ Xen-3.3.1 x86_64 debug=n Tainted: C ]----
(XEN) CPU: 1
(XEN) RIP: e008:[<ffff828c8013a24b>] default_idle+0x2b/0x40
(XEN) RFLAGS: 0000000000000246 CONTEXT: hypervisor
(XEN) rax: 0000000000000080 rbx: ffff8300bf5f7f28 rcx: 0000000000000001
(XEN) rdx: ffff828c80276980 rsi: ffff828c8021ad40 rdi: 0000000000002000
(XEN) rbp: ffff8300bf5f7f28 rsp: ffff8300bf5f7f08 r8: 0000000000000002
(XEN) r9: ffff8300be601e00 r10: 0000000000000000 r11: ffff8300be601e10
(XEN) r12: ffff828c80276980 r13: 00000014ef213474 r14: ffff828c8021a160
(XEN) r15: ffff828c8021a100 cr0: 000000008005003b cr4: 00000000000026b0
(XEN) cr3: 00000000be864000 cr2: 00007fd946ff3ed0
(XEN) ds: 002b es: 002b fs: 0000 gs: 0000 ss: e010 cs: e008
(XEN) Xen stack trace from rsp=ffff8300bf5f7f08:
(XEN) ffff828c8013e126 0000000000002000 ffff8300be6fc080 ffff8300be61c080
(XEN) 0000000000000000 0000000000000000 0000000000000000 0000000000000000
(XEN) 0000000000000000 0000000000000000 0000000000000246 0000000000007ff0
(XEN) ffff880080ad1000 ffff8800dd488000 0000000000000000 ffffffff8020730a
(XEN) 0000000000000000 0000000000000001 0000000000000002 0000010000000000
(XEN) ffffffff8020730a 000000000000e033 0000000000000246 ffff8800dd489f28
(XEN) 000000000000e02b 0000000000000000 0000000000000000 0000000000000000
(XEN) 0000000000000000 0000000000000001 ffff8300be6fc080
(XEN) Xen call trace:
(XEN) [<ffff828c8013a24b>] default_idle+0x2b/0x40
(XEN) [<ffff828c8013e126>] idle_loop+0xa6/0xd0
(XEN)
(XEN) No guest context (CPU1 is idle).
(XEN)
(XEN) *** Dumping CPU2 host state: ***
(XEN) ----[ Xen-3.3.1 x86_64 debug=n Tainted: C ]----
(XEN) CPU: 2
(XEN) RIP: e008:[<ffff828c8019a45c>] vmx_vmexit_handler+0x2ec/0x1b20
(XEN) RFLAGS: 0000000000000246 CONTEXT: hypervisor
(XEN) rax: 0000000000000020 rbx: ffff8300be6e0080 rcx: 0000000000000000
(XEN) rdx: ffff828c8021c3a0 rsi: 00000000000003de rdi: ffff8300be6f7f28
(XEN) rbp: ffff9700ffb80990 rsp: ffff8300be6f7e38 r8: ffff97600036379c
(XEN) r9: ffff9700ff428b5b r10: ffff976000363794 r11: 0000000000000000
(XEN) r12: 0000000000000000 r13: ffff8300be6e0080 r14: ffff8300be6f7f28
(XEN) r15: ffff976000363958 cr0: 000000008005003b cr4: 00000000000026b0
(XEN) cr3: 000000033fc01000 cr2: 0000000000000000
(XEN) ds: 0000 es: 0000 fs: 0000 gs: 0000 ss: 0000 cs: e008
(XEN) Xen stack trace from rsp=ffff8300be6f7e38:
(XEN) 0000000000000000 ffff8300be6e0080 ffff8300be6e1858 ffff8300be6e0080
(XEN) ffff9700ffb80990 ffff828c80187141 000000000000e102 000000000000e102
(XEN) 00000000000000e1 ffff828c8019483d ffff8300be6ee102 ffff828c80137d6e
(XEN) ffff8300be6f7f28 ffff8300be6e0080 0000000000000000 ffff8300be601f08
(XEN) 00000078be6edeea 0000000000000002 ffff8300be6f7f28 ffff828c8011b87a
(XEN) ffff828c80276980 0000000000000002 ffff828c80277980 ffff8300be6e0080
(XEN) ffff9700ffb80990 0000000000000000 ffff976000363958 ffffffffffffffff
(XEN) ffff976000363958 ffff828c801944c3 ffff976000363958 ffffffffffffffff
(XEN) ffff976000363958 0000000000000000 ffff9700ffb80990 0000000000000050
(XEN) 0000000000000000 ffff976000363794 ffff9700ff428b5b ffff97600036379c
(XEN) 0000000000000730 ffffb000000b8000 00000000000003de 00000000000003de
(XEN) ffff9700ffb80990 000000000000000b ffff9700ff025250 0000000000000000
(XEN) 0000000000010097 ffff976000363938 0000000000000000 5555555555555555
(XEN) 5555555555555555 5555555555555555 5555555555555555 5555555500000002
(XEN) ffff8300be6e0080
(XEN) Xen call trace:
(XEN) [<ffff828c8019a45c>] vmx_vmexit_handler+0x2ec/0x1b20
(XEN) [<ffff828c80187141>] hvm_vcpu_has_pending_irq+0x41/0x60
(XEN) [<ffff828c8019483d>] vmx_intr_assist+0x2bd/0x490
(XEN) [<ffff828c80137d6e>] reprogram_timer+0x1e/0x90
(XEN) [<ffff828c8011b87a>] _spin_unlock_irq+0x1a/0x40
(XEN) [<ffff828c801944c3>] vmx_asm_do_vmentry+0x0/0xbd
(XEN)
(XEN) *** Dumping CPU2 guest state (d1:v1): ***
(XEN) ----[ Xen-3.3.1 x86_64 debug=n Tainted: C ]----
(XEN) CPU: 2
(XEN) RIP: 0020:[<ffff9700ff025250>]
(XEN) RFLAGS: 0000000000010097 CONTEXT: hvm guest
(XEN) rax: 0000000000000730 rbx: 0000000000000050 rcx: ffffb000000b8000
(XEN) rdx: 00000000000003de rsi: 00000000000003de rdi: ffff9700ffb80990
(XEN) rbp: ffff9700ffb80990 rsp: ffff976000363938 r8: ffff97600036379c
(XEN) r9: ffff9700ff428b5b r10: ffff976000363794 r11: 0000000000000000
(XEN) r12: 0000000000000000 r13: ffff976000363958 r14: ffffffffffffffff
(XEN) r15: ffff976000363958 cr0: 0000000080050033 cr4: 00000000000006b0
(XEN) cr3: 0000000001822000 cr2: 0000000000000000
(XEN) ds: 0028 es: 0028 fs: 0028 gs: 0028 ss: 0028 cs: 0020
(XEN)
(XEN) *** Dumping CPU3 host state: ***
(XEN) ----[ Xen-3.3.1 x86_64 debug=n Tainted: C ]----
(XEN) CPU: 3
(XEN) RIP: e008:[<ffff828c8019a45c>] vmx_vmexit_handler+0x2ec/0x1b20
(XEN) RFLAGS: 0000000000000202 CONTEXT: hypervisor
(XEN) rax: 0000000000000027 rbx: ffff8300be6e4080 rcx: 0000000000000007
(XEN) rdx: ffff828c8021e3a0 rsi: ffff9700fe1a9b70 rdi: ffff8300be91ff28
(XEN) rbp: ffff9700ffb80998 rsp: ffff8300be91fe38 r8: 0000000000000000
(XEN) r9: ffff9700ff41e074 r10: 0000000000000000 r11: 0000000000000000
(XEN) r12: 0000000000000007 r13: ffff8300be6e4080 r14: ffff8300be91ff28
(XEN) r15: ffff9700ff01f9c0 cr0: 000000008005003b cr4: 00000000000026b0
(XEN) cr3: 000000033fc26000 cr2: 0000000000000000
(XEN) ds: 0000 es: 0000 fs: 0000 gs: 0000 ss: 0000 cs: e008
(XEN) Xen stack trace from rsp=ffff8300be91fe38:
(XEN) ffff828c8021e100 ffff8300be6e4080 ffff8300be6e5858 ffff8300be6e4080
(XEN) ffff9700ffb80998 ffff828c80187141 000000000000e102 000000000000e102
(XEN) 00000000000000e1 ffff828c8019483d ffff8300be6ee102 ffff828c80137d6e
(XEN) ffff8300be91ff28 ffff8300be6e4080 0000000000000000 ffff8300be852088
(XEN) 000001f9889c1558 0000000000000003 ffff8300be91ff28 ffff828c8011b87a
(XEN) ffff828c80276980 0000000000000003 ffff828c80277980 ffff8300be6e4080
(XEN) ffff9700ffb80998 ffff9700ff0476fc ffff9700ff047700 ffff9700fe000000
(XEN) ffff9700ff01f9c0 ffff828c801944c3 ffff9700ff01f9c0 ffff9700fe000000
(XEN) ffff9700ff047700 ffff9700ff0476fc ffff9700ffb80998 00000000c0010001
(XEN) 0000000000000000 0000000000000000 ffff9700ff41e074 0000000000000000
(XEN) ffff9700ff02e59a 0000000000000043 0000000000000043 ffff9700fe1a9b70
(XEN) ffff9700ffb80998 000000f100000001 ffff9700ff02e5c9 0000000000000000
(XEN) 0000000000000282 ffff9700fe1a9b60 0000000000000000 0000000000000000
(XEN) 0000000000000000 0000000000000000 0000000000000000 0000000000000003
(XEN) ffff8300be6e4080
(XEN) Xen call trace:
(XEN) [<ffff828c8019a45c>] vmx_vmexit_handler+0x2ec/0x1b20
(XEN) [<ffff828c80187141>] hvm_vcpu_has_pending_irq+0x41/0x60
(XEN) [<ffff828c8019483d>] vmx_intr_assist+0x2bd/0x490
(XEN) [<ffff828c80137d6e>] reprogram_timer+0x1e/0x90
(XEN) [<ffff828c8011b87a>] _spin_unlock_irq+0x1a/0x40
(XEN) [<ffff828c801944c3>] vmx_asm_do_vmentry+0x0/0xbd
(XEN)
(XEN) *** Dumping CPU3 guest state (d1:v0): ***
(XEN) ----[ Xen-3.3.1 x86_64 debug=n Tainted: C ]----
(XEN) CPU: 3
(XEN) RIP: 0020:[<ffff9700ff02e5c9>]
(XEN) RFLAGS: 0000000000000282 CONTEXT: hvm guest
(XEN) rax: ffff9700ff02e59a rbx: 00000000c0010001 rcx: 0000000000000043
(XEN) rdx: 0000000000000043 rsi: ffff9700fe1a9b70 rdi: ffff9700ffb80998
(XEN) rbp: ffff9700ffb80998 rsp: ffff9700fe1a9b60 r8: 0000000000000000
(XEN) r9: ffff9700ff41e074 r10: 0000000000000000 r11: 0000000000000000
(XEN) r12: ffff9700ff0476fc r13: ffff9700ff047700 r14: ffff9700fe000000
(XEN) r15: ffff9700ff01f9c0 cr0: 0000000080050033 cr4: 00000000000006b0
(XEN) cr3: 0000000001423000 cr2: 0000000000000000
(XEN) ds: 0028 es: 0028 fs: 0028 gs: 0028 ss: 0028 cs: 0020
(XEN)
--
Company details: http://ts.fujitsu.com/imprint.html
^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: Need help in debugging partially blocked hypervisor
2009-10-21 13:07 Need help in debugging partially blocked hypervisor Dietmar Hahn
@ 2009-10-21 13:28 ` Keir Fraser
2009-10-21 13:35 ` Dietmar Hahn
2009-10-30 12:20 ` Dietmar Hahn
1 sibling, 1 reply; 21+ messages in thread
From: Keir Fraser @ 2009-10-21 13:28 UTC (permalink / raw)
To: Dietmar Hahn, xen-devel
On 21/10/2009 14:07, "Dietmar Hahn" <dietmar.hahn@ts.fujitsu.com> wrote:
> I need some help in debugging a strange hypervisor behavior together
> with using fully virtualized performance counters.
>
> For info I use SLES11, means xen-3.3.1 and linux-2.6.27.19-5... on a
> Intel nehalem machine.
> I tried the hypervisor from xen-unstable but the machine didn't boot.
That in itself is frankly more of a concern to me. Probably recent
irq-handling changes, or some other platform change, has broken boot on some
machines. If we don't get reports and testing help with that, it'll end up
broken in the next major stable release too, which we really don't want.
Meanwhile, can you at least boot with 3.4? At least we still maintain that.
And do a debug build (debug=y make ...) so that the backtraces from the 'd'
debug key are more meaningful.
-- Keir
^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: Need help in debugging partially blocked hypervisor
2009-10-21 13:28 ` Keir Fraser
@ 2009-10-21 13:35 ` Dietmar Hahn
2009-10-21 13:53 ` Keir Fraser
0 siblings, 1 reply; 21+ messages in thread
From: Dietmar Hahn @ 2009-10-21 13:35 UTC (permalink / raw)
To: Keir Fraser; +Cc: xen-devel
> On 21/10/2009 14:07, "Dietmar Hahn" <dietmar.hahn@ts.fujitsu.com> wrote:
>
> > I need some help in debugging a strange hypervisor behavior together
> > with using fully virtualized performance counters.
> >
> > For info I use SLES11, means xen-3.3.1 and linux-2.6.27.19-5... on a
> > Intel nehalem machine.
> > I tried the hypervisor from xen-unstable but the machine didn't boot.
>
> That in itself is frankly more of a concern to me. Probably recent
> irq-handling changes, or some other platform change, has broken boot on some
> machines. If we don't get reports and testing help with that, it'll end up
> broken in the next major stable release too, which we really don't want.
>
> Meanwhile, can you at least boot with 3.4? At least we still maintain that.
> And do a debug build (debug=y make ...) so that the backtraces from the 'd'
> debug key are more meaningful.
>
> -- Keir
Yes, you are right, I'll try 3.4.
Thanks.
Dietmar.
>
>
>
>
--
Dietmar Hahn
TSP ES&S SWE OS Telephone: +49 (0) 89 636 40274
Fujitsu Technology Solutions Email: dietmar.hahn@ts.fujitsu.com
Otto-Hahn-Ring 6 Internet: http://ts.fujitsu.com
D-81739 München Company details:ts.fujitsu.com/imprint.html
^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: Need help in debugging partially blocked hypervisor
2009-10-21 13:35 ` Dietmar Hahn
@ 2009-10-21 13:53 ` Keir Fraser
0 siblings, 0 replies; 21+ messages in thread
From: Keir Fraser @ 2009-10-21 13:53 UTC (permalink / raw)
To: Dietmar Hahn; +Cc: xen-devel
On 21/10/2009 14:35, "Dietmar Hahn" <dietmar.hahn@ts.fujitsu.com> wrote:
>> That in itself is frankly more of a concern to me. Probably recent
>> irq-handling changes, or some other platform change, has broken boot on some
>> machines. If we don't get reports and testing help with that, it'll end up
>> broken in the next major stable release too, which we really don't want.
>>
>> Meanwhile, can you at least boot with 3.4? At least we still maintain that.
>> And do a debug build (debug=y make ...) so that the backtraces from the 'd'
>> debug key are more meaningful.
>>
>> -- Keir
>
> Yes, you are right, I'll try 3.4.
Thanks. DomU guests taking out the host is an embarrassing class of bug. It
would be good to get this sorted for 3.4.2 if the bug still exists. Or worst
case we could make this perfctr stuff a default-off config option. ;-)
-- Keir
^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: Need help in debugging partially blocked hypervisor
2009-10-21 13:07 Need help in debugging partially blocked hypervisor Dietmar Hahn
2009-10-21 13:28 ` Keir Fraser
@ 2009-10-30 12:20 ` Dietmar Hahn
2009-10-30 13:06 ` Keir Fraser
1 sibling, 1 reply; 21+ messages in thread
From: Dietmar Hahn @ 2009-10-30 12:20 UTC (permalink / raw)
To: xen-devel
Hi,
> I need some help in debugging a strange hypervisor behavior together
> with using fully virtualized performance counters.
>
I added some own tracer to xentrace to find, what the CPU is doing.
No I can see, that in the strange case the CPU is doing endless (and nothing
else!) performance counter NMI's within the hypervisor.
pmu_apic_interrupt
smp_pmu_apic_interrupt
vmx_do_pmu_interrupt
vpmu_do_interrupt
In the normal case in core2_vpmu_do_interrupt:
1. Read the cause of the nmi
rdmsrl(MSR_CORE_PERF_GLOBAL_STATUS, msr_content);
...
2. Save the value for the domU
...
3. Reset the cause
wrmsrl(MSR_CORE_PERF_GLOBAL_OVF_CTRL, msr_content);
4. Inject NMI in domU
This works very well for a short time.
Then the hypervisor falls in the endless nmi loop. The cause for this seems
to be that "3. Reset the cause" doesn't work anymore. Means writing to the
MSR_CORE_PERF_GLOBAL_OVF_CTRL doesn't reset the MSR_CORE_PERF_GLOBAL_STATUS
which leads to the next nmi immediately.
I found this by adding another tracer which reads the MSR_CORE_PERF_GLOBAL_STATUS
once again after writing the MSR_CORE_PERF_GLOBAL_OVF_CTRL.
In the normal case this contains now 0, in the strange case the value is unchanged!
I searched the intel processor spec but couldn't find any help.
So my questions is, what is wrong here?
Can anybody with more knowledge point me in the right direction, what can I still
do to find the real cause of this?
Many thanks in advance!
Dietmar.
--
Company details: http://ts.fujitsu.com/imprint.html
^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: Need help in debugging partially blocked hypervisor
2009-10-30 12:20 ` Dietmar Hahn
@ 2009-10-30 13:06 ` Keir Fraser
2009-11-02 1:12 ` Haitao Shan
0 siblings, 1 reply; 21+ messages in thread
From: Keir Fraser @ 2009-10-30 13:06 UTC (permalink / raw)
To: Dietmar Hahn, xen-devel; +Cc: haitao.shan
On 30/10/2009 12:20, "Dietmar Hahn" <dietmar.hahn@ts.fujitsu.com> wrote:
> I searched the intel processor spec but couldn't find any help.
> So my questions is, what is wrong here?
> Can anybody with more knowledge point me in the right direction, what can I
> still
> do to find the real cause of this?
You should probably Cc one of the Intel guys who implemented this stuff --
I've added Haitao Shan.
Meanwhile I'd be interested to know whether things work okay for you, minus
performance counters and the hypervisor hang, if you return immediately from
vpmu_initialise(). Really at minimum we need such a fix, perhaps with a boot
paremeter to re-enable the feature, for 3.4.2 release; allowing guests to
hose the hypervisor like this is of course not on.
-- Keir
^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: Need help in debugging partially blocked hypervisor
2009-10-30 13:06 ` Keir Fraser
@ 2009-11-02 1:12 ` Haitao Shan
2009-11-02 9:11 ` Dietmar Hahn
0 siblings, 1 reply; 21+ messages in thread
From: Haitao Shan @ 2009-11-02 1:12 UTC (permalink / raw)
To: Keir Fraser; +Cc: xen-devel, haitao.shan, Dietmar Hahn
Can I know how you enabled vPMU on Nehalem? This is not supported in
current Xen.
Concerning vpmu support, I totally agree that we can disable this
feature by default. If anyone really wants to use it, he can use boot
options to turn it on. I am preparing a patch for that. And I will
send a patch to enable NHM vpmu together.
For the problem that Dietmar met, I think I once met this before. Can
you add some code in vpmu_do_interrupt that sets the counter you are
using to a value other than zero? Please let me know if that can help.
Best Regards
Shan Haitao
2009/10/30 Keir Fraser <keir.fraser@eu.citrix.com>:
> On 30/10/2009 12:20, "Dietmar Hahn" <dietmar.hahn@ts.fujitsu.com> wrote:
>
>> I searched the intel processor spec but couldn't find any help.
>> So my questions is, what is wrong here?
>> Can anybody with more knowledge point me in the right direction, what can I
>> still
>> do to find the real cause of this?
>
> You should probably Cc one of the Intel guys who implemented this stuff --
> I've added Haitao Shan.
>
> Meanwhile I'd be interested to know whether things work okay for you, minus
> performance counters and the hypervisor hang, if you return immediately from
> vpmu_initialise(). Really at minimum we need such a fix, perhaps with a boot
> paremeter to re-enable the feature, for 3.4.2 release; allowing guests to
> hose the hypervisor like this is of course not on.
>
> -- Keir
>
>
>
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/xen-devel
>
^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: Need help in debugging partially blocked hypervisor
2009-11-02 1:12 ` Haitao Shan
@ 2009-11-02 9:11 ` Dietmar Hahn
2009-11-02 9:49 ` Shan, Haitao
0 siblings, 1 reply; 21+ messages in thread
From: Dietmar Hahn @ 2009-11-02 9:11 UTC (permalink / raw)
To: xen-devel, haitao.shan; +Cc: Keir Fraser
Hi Haitao,
> Can I know how you enabled vPMU on Nehalem? This is not supported in
> current Xen.
http://lists.xensource.com/archives/html/xen-devel/2009-09/msg00829.html
>
> Concerning vpmu support, I totally agree that we can disable this
> feature by default. If anyone really wants to use it, he can use boot
> options to turn it on.
Yes, that's OK for me.
> I am preparing a patch for that. And I will
> send a patch to enable NHM vpmu together.
>
> For the problem that Dietmar met, I think I once met this before. Can
> you add some code in vpmu_do_interrupt that sets the counter you are
> using to a value other than zero? Please let me know if that can help.
I don't set the counter to zero. I use 0-val to set the counter.
Actually I testet on Nehalem with
- General Perf-counter #2 (0xc3) with CPU_CLK_UNHALTED and val=1100000
- Fixed counter #1 (0x30a) and val=1100000
The thing is that in normal case the overflows of both counters appear
nearly at the same time.
As described I added some extra tracer for xentrace in
core2_vpmu_do_interrupt() so the code looks like:
rdmsrl(MSR_CORE_PERF_GLOBAL_STATUS, msr_content); -> 1. Step
{
uint32_t HAHN_l, HAHN_h;
HAHN_l = (uint32_t) msr_content;
HAHN_h = (uint32_t) (msr_content >> 32);
HVMTRACE_3D(HAHN_TR2, v, 1, HAHN_h, HAHN_l); -> 2. Step
}
if ( !msr_content )
return 0;
core2_vpmu_cxt->global_ovf_status |= msr_content;
msr_content = 0xC000000700000000 | ((1 << core2_get_pmc_count()) - 1);
wrmsrl(MSR_CORE_PERF_GLOBAL_OVF_CTRL, msr_content); -> 3. Step
rdmsrl(MSR_CORE_PERF_GLOBAL_STATUS, msr_content); -> 4. Step
{
uint32_t HAHN_l, HAHN_h;
HAHN_l = (uint32_t) msr_content;
HAHN_h = (uint32_t) (msr_content >> 32);
HVMTRACE_3D(HAHN_TR2, v, 0xa, HAHN_h, HAHN_l); -> 5. Step
rdmsrl(0xc3, msr_content); -> 6. Step General counter #2
HAHN_l = (uint32_t) msr_content;
HAHN_h = (uint32_t) (msr_content >> 32);
HVMTRACE_3D(HAHN_TR2, v, 0xc3, HAHN_h, HAHN_l);
rdmsrl(0x30a, msr_content); -> 7. Step Fixed counter #1
HAHN_l = (uint32_t) msr_content;
HAHN_h = (uint32_t) (msr_content >> 32);
HVMTRACE_3D(HAHN_TR2, v, 0x30a, HAHN_h, HAHN_l);
}
With these tracers I got the following output:
Last good NMI:
Both counter cause the NMI. Resetting works OK.
The counter itself were running further.
2. Step: par1 = 0x01, high = 0x0002, low = 0x0004 ] rdmsrl(MSR_CORE_PERF_GLOBAL_STATUS)
5. Step: par1 = 0x0a, high = 0x0000, low = 0x0000 ] rdmsrl(MSR_CORE_PERF_GLOBAL_STATUS)
6. Step: par1 = 0xc3, high = 0x0000, low = 0x03c4 ] rdmsrl(0xc3) -> #2 general counter
7. Step: par1 = 0x30a, high = 0x0000, low = 0x02da ] rdmsrl(0x30a) -> #1 fixed counter
NMI from where things goes wrong:
Both counter cause the NMI. Resetting works NOT correct, only for the
general counter!
The general counter (caused the NMI) seems to be stopped!
2. Step: par1 = 0x01, high = 0x0002, low = 0x0004 ] rdmsrl(MSR_CORE_PERF_GLOBAL_STATUS)
5. Step: par1 = 0x0a, high = 0x0002, low = 0x0000 ] rdmsrl(MSR_CORE_PERF_GLOBAL_STATUS)
6. Step: par1 = 0xc3, high = 0x0000, low = 0x00ec ] rdmsrl(0xc3) -> #2 general counter
7. Step: par1 = 0x30a, high = 0x0000, low = 0x0000 ] rdmsrl(0x30a) -> #1 fixed counter
Wrong NMI:
Only the fixed counter causes the NMI (which was not resetted during NMI handling above!)
Both counter seems to be stopped!
2. Step: par1 = 0x01, high = 0x0002, low = 0x0000 ] rdmsrl(MSR_CORE_PERF_GLOBAL_STATUS)
5. Step: par1 = 0x0a, high = 0x0002, low = 0x0000 ] rdmsrl(MSR_CORE_PERF_GLOBAL_STATUS)
6. Step: par1 = 0xc3, high = 0x0000, low = 0x00ec ] rdmsrl(0xc3) -> #2 general counter
7. Step: par1 = 0x30a, high = 0x0000, low = 0x0000 ] rdmsrl(0x30a) -> #1 fixed counter
And this state remains forever!
I hope my explanations are understandable ;-)
Until now I can see this behavior only on a Nehalem processor.
Thanks.
Dietmar
>
> Best Regards
> Shan Haitao
>
> 2009/10/30 Keir Fraser <keir.fraser@eu.citrix.com>:
> > On 30/10/2009 12:20, "Dietmar Hahn" <dietmar.hahn@ts.fujitsu.com> wrote:
> >
> >> I searched the intel processor spec but couldn't find any help.
> >> So my questions is, what is wrong here?
> >> Can anybody with more knowledge point me in the right direction, what can I
> >> still
> >> do to find the real cause of this?
> >
> > You should probably Cc one of the Intel guys who implemented this stuff --
> > I've added Haitao Shan.
> >
> > Meanwhile I'd be interested to know whether things work okay for you, minus
> > performance counters and the hypervisor hang, if you return immediately from
> > vpmu_initialise(). Really at minimum we need such a fix, perhaps with a boot
> > paremeter to re-enable the feature, for 3.4.2 release; allowing guests to
> > hose the hypervisor like this is of course not on.
> >
> > -- Keir
> >
--
Company details: http://ts.fujitsu.com/imprint.html
^ permalink raw reply [flat|nested] 21+ messages in thread
* RE: Need help in debugging partially blocked hypervisor
2009-11-02 9:11 ` Dietmar Hahn
@ 2009-11-02 9:49 ` Shan, Haitao
2009-11-02 10:30 ` Dietmar Hahn
0 siblings, 1 reply; 21+ messages in thread
From: Shan, Haitao @ 2009-11-02 9:49 UTC (permalink / raw)
To: Dietmar Hahn, xen-devel; +Cc: Keir Fraser
Very detailed explanation indeed. What you described is the same as I saw months ago.
But unluckily, I do not know the root cause yet. It seems to me that unmasking of PMI in local APIC will immediately generate a new NMI in the system if one of the enabled counter is zero at that time.
That is why I was asking you whether you could try to set that counter to some value other than zero (for example, 0x1) before unmasking(in your case, it is Fixed Counter 1 0x30a) PMI in vpmu_do_interrupt and see whether it helped.
When I met this problem, I remember that I tried two approaches:
1> Setting the counter to non-zero before unmasking PMI in vpmu_do_interrupt;
2> Remove unmasking PMI from vpmu_do_interrupt and unmask *physical PMI* when guest vcpu unmasks virtual PMI.
I remember that approach 2 can fix this issue. But I do not remember the result of approach 1, since I met this about one year ago.
It is my understanding that approach 2 is quite same as approach 1, since normally guest will set the counter to some negative value (for example, -100000) before unmasking virtual PMI.
However, approach 2 looks cleaner and more reasonable.
Can you have a try and let me know the result? If both can not work, there might be some problems that I have not met before.
BTW: Sorry, I did not see your patch to enable NHM vpmu before. So, there is no need for me to work on that now. :)
Haitao
Dietmar Hahn wrote:
> Hi Haitao,
>
>> Can I know how you enabled vPMU on Nehalem? This is not supported in
>> current Xen.
>
> http://lists.xensource.com/archives/html/xen-devel/2009-09/msg00829.html
>
>>
>> Concerning vpmu support, I totally agree that we can disable this
>> feature by default. If anyone really wants to use it, he can use boot
>> options to turn it on.
>
> Yes, that's OK for me.
>
>> I am preparing a patch for that. And I will
>> send a patch to enable NHM vpmu together.
>>
>> For the problem that Dietmar met, I think I once met this before. Can
>> you add some code in vpmu_do_interrupt that sets the counter you are
>> using to a value other than zero? Please let me know if that can
>> help.
>
> I don't set the counter to zero. I use 0-val to set the counter.
> Actually I testet on Nehalem with
> - General Perf-counter #2 (0xc3) with CPU_CLK_UNHALTED and val=1100000
> - Fixed counter #1 (0x30a) and val=1100000
> The thing is that in normal case the overflows of both counters appear
> nearly at the same time.
> As described I added some extra tracer for xentrace in
> core2_vpmu_do_interrupt() so the code looks like:
>
> rdmsrl(MSR_CORE_PERF_GLOBAL_STATUS, msr_content); -> 1. Step
> {
> uint32_t HAHN_l, HAHN_h;
> HAHN_l = (uint32_t) msr_content;
> HAHN_h = (uint32_t) (msr_content >> 32);
> HVMTRACE_3D(HAHN_TR2, v, 1, HAHN_h, HAHN_l); -> 2. Step
> }
> if ( !msr_content )
> return 0;
> core2_vpmu_cxt->global_ovf_status |= msr_content;
> msr_content = 0xC000000700000000 | ((1 << core2_get_pmc_count())
> - 1); wrmsrl(MSR_CORE_PERF_GLOBAL_OVF_CTRL, msr_content); -> 3.
> Step
>
> rdmsrl(MSR_CORE_PERF_GLOBAL_STATUS, msr_content); -> 4. Step
> {
> uint32_t HAHN_l, HAHN_h;
> HAHN_l = (uint32_t) msr_content;
> HAHN_h = (uint32_t) (msr_content >> 32);
> HVMTRACE_3D(HAHN_TR2, v, 0xa, HAHN_h, HAHN_l); -> 5. Step
>
> rdmsrl(0xc3, msr_content); -> 6. Step
> General counter #2 HAHN_l = (uint32_t) msr_content;
> HAHN_h = (uint32_t) (msr_content >> 32);
> HVMTRACE_3D(HAHN_TR2, v, 0xc3, HAHN_h, HAHN_l);
> rdmsrl(0x30a, msr_content); -> 7. Step
> Fixed counter #1 HAHN_l = (uint32_t) msr_content;
> HAHN_h = (uint32_t) (msr_content >> 32);
> HVMTRACE_3D(HAHN_TR2, v, 0x30a, HAHN_h, HAHN_l);
> }
>
> With these tracers I got the following output:
>
> Last good NMI:
> Both counter cause the NMI. Resetting works OK.
> The counter itself were running further.
> 2. Step: par1 = 0x01, high = 0x0002, low = 0x0004 ]
> rdmsrl(MSR_CORE_PERF_GLOBAL_STATUS)
> 5. Step: par1 = 0x0a, high = 0x0000, low = 0x0000 ]
> rdmsrl(MSR_CORE_PERF_GLOBAL_STATUS)
> 6. Step: par1 = 0xc3, high = 0x0000, low = 0x03c4 ] rdmsrl(0xc3)
> -> #2 general counter
> 7. Step: par1 = 0x30a, high = 0x0000, low = 0x02da ] rdmsrl(0x30a)
> -> #1 fixed counter
>
> NMI from where things goes wrong:
> Both counter cause the NMI. Resetting works NOT correct, only for the
> general counter!
> The general counter (caused the NMI) seems to be stopped!
> 2. Step: par1 = 0x01, high = 0x0002, low = 0x0004 ]
> rdmsrl(MSR_CORE_PERF_GLOBAL_STATUS)
> 5. Step: par1 = 0x0a, high = 0x0002, low = 0x0000 ]
> rdmsrl(MSR_CORE_PERF_GLOBAL_STATUS)
> 6. Step: par1 = 0xc3, high = 0x0000, low = 0x00ec ] rdmsrl(0xc3)
> -> #2 general counter
> 7. Step: par1 = 0x30a, high = 0x0000, low = 0x0000 ] rdmsrl(0x30a)
> -> #1 fixed counter
>
> Wrong NMI:
> Only the fixed counter causes the NMI (which was not resetted during
> NMI handling above!) Both counter seems to be stopped!
> 2. Step: par1 = 0x01, high = 0x0002, low = 0x0000 ]
> rdmsrl(MSR_CORE_PERF_GLOBAL_STATUS)
> 5. Step: par1 = 0x0a, high = 0x0002, low = 0x0000 ]
> rdmsrl(MSR_CORE_PERF_GLOBAL_STATUS)
> 6. Step: par1 = 0xc3, high = 0x0000, low = 0x00ec ] rdmsrl(0xc3)
> -> #2 general counter
> 7. Step: par1 = 0x30a, high = 0x0000, low = 0x0000 ] rdmsrl(0x30a)
> -> #1 fixed counter
>
> And this state remains forever!
> I hope my explanations are understandable ;-)
>
> Until now I can see this behavior only on a Nehalem processor.
>
> Thanks.
> Dietmar
>
>>
>> Best Regards
>> Shan Haitao
>>
>> 2009/10/30 Keir Fraser <keir.fraser@eu.citrix.com>:
>>> On 30/10/2009 12:20, "Dietmar Hahn" <dietmar.hahn@ts.fujitsu.com>
>>> wrote:
>>>
>>>> I searched the intel processor spec but couldn't find any help.
>>>> So my questions is, what is wrong here?
>>>> Can anybody with more knowledge point me in the right direction,
>>>> what can I still do to find the real cause of this?
>>>
>>> You should probably Cc one of the Intel guys who implemented this
>>> stuff -- I've added Haitao Shan.
>>>
>>> Meanwhile I'd be interested to know whether things work okay for
>>> you, minus performance counters and the hypervisor hang, if you
>>> return immediately from vpmu_initialise(). Really at minimum we
>>> need such a fix, perhaps with a boot paremeter to re-enable the
>>> feature, for 3.4.2 release; allowing guests to hose the hypervisor
>>> like this is of course not on.
>>>
>>> -- Keir
^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: Need help in debugging partially blocked hypervisor
2009-11-02 9:49 ` Shan, Haitao
@ 2009-11-02 10:30 ` Dietmar Hahn
2009-11-03 6:53 ` Dietmar Hahn
0 siblings, 1 reply; 21+ messages in thread
From: Dietmar Hahn @ 2009-11-02 10:30 UTC (permalink / raw)
To: Shan, Haitao; +Cc: xen-devel, Keir Fraser
> Very detailed explanation indeed. What you described is the same as I saw months ago.
> But unluckily, I do not know the root cause yet. It seems to me that unmasking of PMI in local APIC will immediately generate a new NMI in the system if one of the enabled counter is zero at that time.
> That is why I was asking you whether you could try to set that counter to some value other than zero (for example, 0x1) before unmasking(in your case, it is Fixed Counter 1 0x30a) PMI in vpmu_do_interrupt and see whether it helped.
OK I will try to set the counter after reading the 0 value to 1.
But some things remain fully unclear ...
Dietmar.
>
> When I met this problem, I remember that I tried two approaches:
> 1> Setting the counter to non-zero before unmasking PMI in vpmu_do_interrupt;
> 2> Remove unmasking PMI from vpmu_do_interrupt and unmask *physical PMI* when guest vcpu unmasks virtual PMI.
> I remember that approach 2 can fix this issue. But I do not remember the result of approach 1, since I met this about one year ago.
> It is my understanding that approach 2 is quite same as approach 1, since normally guest will set the counter to some negative value (for example, -100000) before unmasking virtual PMI.
> However, approach 2 looks cleaner and more reasonable.
>
> Can you have a try and let me know the result? If both can not work, there might be some problems that I have not met before.
>
> BTW: Sorry, I did not see your patch to enable NHM vpmu before. So, there is no need for me to work on that now. :)
>
> Haitao
>
>
> Dietmar Hahn wrote:
> > Hi Haitao,
> >
> >> Can I know how you enabled vPMU on Nehalem? This is not supported in
> >> current Xen.
> >
> > http://lists.xensource.com/archives/html/xen-devel/2009-09/msg00829.html
> >
> >>
> >> Concerning vpmu support, I totally agree that we can disable this
> >> feature by default. If anyone really wants to use it, he can use boot
> >> options to turn it on.
> >
> > Yes, that's OK for me.
> >
> >> I am preparing a patch for that. And I will
> >> send a patch to enable NHM vpmu together.
> >>
> >> For the problem that Dietmar met, I think I once met this before. Can
> >> you add some code in vpmu_do_interrupt that sets the counter you are
> >> using to a value other than zero? Please let me know if that can
> >> help.
> >
> > I don't set the counter to zero. I use 0-val to set the counter.
> > Actually I testet on Nehalem with
> > - General Perf-counter #2 (0xc3) with CPU_CLK_UNHALTED and val=1100000
> > - Fixed counter #1 (0x30a) and val=1100000
> > The thing is that in normal case the overflows of both counters appear
> > nearly at the same time.
> > As described I added some extra tracer for xentrace in
> > core2_vpmu_do_interrupt() so the code looks like:
> >
> > rdmsrl(MSR_CORE_PERF_GLOBAL_STATUS, msr_content); -> 1. Step
> > {
> > uint32_t HAHN_l, HAHN_h;
> > HAHN_l = (uint32_t) msr_content;
> > HAHN_h = (uint32_t) (msr_content >> 32);
> > HVMTRACE_3D(HAHN_TR2, v, 1, HAHN_h, HAHN_l); -> 2. Step
> > }
> > if ( !msr_content )
> > return 0;
> > core2_vpmu_cxt->global_ovf_status |= msr_content;
> > msr_content = 0xC000000700000000 | ((1 << core2_get_pmc_count())
> > - 1); wrmsrl(MSR_CORE_PERF_GLOBAL_OVF_CTRL, msr_content); -> 3.
> > Step
> >
> > rdmsrl(MSR_CORE_PERF_GLOBAL_STATUS, msr_content); -> 4. Step
> > {
> > uint32_t HAHN_l, HAHN_h;
> > HAHN_l = (uint32_t) msr_content;
> > HAHN_h = (uint32_t) (msr_content >> 32);
> > HVMTRACE_3D(HAHN_TR2, v, 0xa, HAHN_h, HAHN_l); -> 5. Step
> >
> > rdmsrl(0xc3, msr_content); -> 6. Step
> > General counter #2 HAHN_l = (uint32_t) msr_content;
> > HAHN_h = (uint32_t) (msr_content >> 32);
> > HVMTRACE_3D(HAHN_TR2, v, 0xc3, HAHN_h, HAHN_l);
> > rdmsrl(0x30a, msr_content); -> 7. Step
> > Fixed counter #1 HAHN_l = (uint32_t) msr_content;
> > HAHN_h = (uint32_t) (msr_content >> 32);
> > HVMTRACE_3D(HAHN_TR2, v, 0x30a, HAHN_h, HAHN_l);
> > }
> >
> > With these tracers I got the following output:
> >
> > Last good NMI:
> > Both counter cause the NMI. Resetting works OK.
> > The counter itself were running further.
> > 2. Step: par1 = 0x01, high = 0x0002, low = 0x0004 ]
> > rdmsrl(MSR_CORE_PERF_GLOBAL_STATUS)
> > 5. Step: par1 = 0x0a, high = 0x0000, low = 0x0000 ]
> > rdmsrl(MSR_CORE_PERF_GLOBAL_STATUS)
> > 6. Step: par1 = 0xc3, high = 0x0000, low = 0x03c4 ] rdmsrl(0xc3)
> > -> #2 general counter
> > 7. Step: par1 = 0x30a, high = 0x0000, low = 0x02da ] rdmsrl(0x30a)
> > -> #1 fixed counter
> >
> > NMI from where things goes wrong:
> > Both counter cause the NMI. Resetting works NOT correct, only for the
> > general counter!
> > The general counter (caused the NMI) seems to be stopped!
> > 2. Step: par1 = 0x01, high = 0x0002, low = 0x0004 ]
> > rdmsrl(MSR_CORE_PERF_GLOBAL_STATUS)
> > 5. Step: par1 = 0x0a, high = 0x0002, low = 0x0000 ]
> > rdmsrl(MSR_CORE_PERF_GLOBAL_STATUS)
> > 6. Step: par1 = 0xc3, high = 0x0000, low = 0x00ec ] rdmsrl(0xc3)
> > -> #2 general counter
> > 7. Step: par1 = 0x30a, high = 0x0000, low = 0x0000 ] rdmsrl(0x30a)
> > -> #1 fixed counter
> >
> > Wrong NMI:
> > Only the fixed counter causes the NMI (which was not resetted during
> > NMI handling above!) Both counter seems to be stopped!
> > 2. Step: par1 = 0x01, high = 0x0002, low = 0x0000 ]
> > rdmsrl(MSR_CORE_PERF_GLOBAL_STATUS)
> > 5. Step: par1 = 0x0a, high = 0x0002, low = 0x0000 ]
> > rdmsrl(MSR_CORE_PERF_GLOBAL_STATUS)
> > 6. Step: par1 = 0xc3, high = 0x0000, low = 0x00ec ] rdmsrl(0xc3)
> > -> #2 general counter
> > 7. Step: par1 = 0x30a, high = 0x0000, low = 0x0000 ] rdmsrl(0x30a)
> > -> #1 fixed counter
> >
> > And this state remains forever!
> > I hope my explanations are understandable ;-)
> >
> > Until now I can see this behavior only on a Nehalem processor.
> >
> > Thanks.
> > Dietmar
> >
> >>
> >> Best Regards
> >> Shan Haitao
> >>
> >> 2009/10/30 Keir Fraser <keir.fraser@eu.citrix.com>:
> >>> On 30/10/2009 12:20, "Dietmar Hahn" <dietmar.hahn@ts.fujitsu.com>
> >>> wrote:
> >>>
> >>>> I searched the intel processor spec but couldn't find any help.
> >>>> So my questions is, what is wrong here?
> >>>> Can anybody with more knowledge point me in the right direction,
> >>>> what can I still do to find the real cause of this?
> >>>
> >>> You should probably Cc one of the Intel guys who implemented this
> >>> stuff -- I've added Haitao Shan.
> >>>
> >>> Meanwhile I'd be interested to know whether things work okay for
> >>> you, minus performance counters and the hypervisor hang, if you
> >>> return immediately from vpmu_initialise(). Really at minimum we
> >>> need such a fix, perhaps with a boot paremeter to re-enable the
> >>> feature, for 3.4.2 release; allowing guests to hose the hypervisor
> >>> like this is of course not on.
> >>>
> >>> -- Keir
>
--
Dietmar Hahn
TSP ES&S SWE OS Telephone: +49 (0) 89 636 40274
Fujitsu Technology Solutions Email: dietmar.hahn@ts.fujitsu.com
Otto-Hahn-Ring 6 Internet: http://ts.fujitsu.com
D-81739 München Company details:ts.fujitsu.com/imprint.html
^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: Need help in debugging partially blocked hypervisor
2009-11-02 10:30 ` Dietmar Hahn
@ 2009-11-03 6:53 ` Dietmar Hahn
2009-11-03 7:32 ` Shan, Haitao
0 siblings, 1 reply; 21+ messages in thread
From: Dietmar Hahn @ 2009-11-03 6:53 UTC (permalink / raw)
To: xen-devel; +Cc: Shan, Haitao, Keir Fraser
>
> > Very detailed explanation indeed. What you described is the same as I saw months ago.
> > But unluckily, I do not know the root cause yet. It seems to me that unmasking of PMI in local APIC will immediately generate a new NMI in the system if one of the enabled counter is zero at that time.
> > That is why I was asking you whether you could try to set that counter to some value other than zero (for example, 0x1) before unmasking(in your case, it is Fixed Counter 1 0x30a) PMI in vpmu_do_interrupt and see whether it helped.
>
> OK I will try to set the counter after reading the 0 value to 1.
> But some things remain fully unclear ...
Hi Haitao,
> 1> Setting the counter to non-zero before unmasking PMI in vpmu_do_interrupt;
I tried your first approach.
1. I added
rdmsrl(CounterX, msr_content)
if (msr_content == 0)
{
HVMTRACE_3D(HAHN_TR2, ...); // A tracer to see this.
wrmsrl(ConterX, 0x1)
}
directly behind the line of reading the MSR_CORE_PERF_GLOBAL_STATUS.
In the xentrace output I found some tracers where counters were zero
but I couldn't reproduce the hanging behavior!
The interesting thing here was, that MSR_CORE_PERF_GLOBAL_STATUS
contained always zero (4. Step) after resetting it with writing
MSR_CORE_PERF_GLOBAL_OVF_CTRL (3. Step).
This was differently seen in my first mail!
2. I added the code above behind the second read (for test) of
MSR_CORE_PERF_GLOBAL_STATUS (around 6. and 7. Step).
Now I could see some of these tracers but no hanging behavior!
In this case I could see the same behavior of the
MSR_CORE_PERF_GLOBAL_STATUS like in my first mail.
The conclusion is, that this seems to be a workaround for the endless
NMI loop. PMI's are a very rarely event and this should not raise a performance
problem.
I didn't try your second approach
> 2> Remove unmasking PMI from vpmu_do_interrupt and unmask *physical PMI* when guest vcpu unmasks virtual PMI.
but I have some question.
- What if the 'physical PMI' is not unmasked in vpmu_do_interrupt and a watchdog NMI would
occur before the domU unmasks it?
- Is it possible that after handling the NMI (and not unmasking) another
domU got running on this CPU and therefore PMI's got lost?
But the real cause of the problem is unknown. As said I saw this only on
Nehalem. Maybe there is a problem together with the hardware? Perhaps your
hardware colleagues know something more ;-)
Thanks
Dietmar
>
> >
> > When I met this problem, I remember that I tried two approaches:
> > 1> Setting the counter to non-zero before unmasking PMI in vpmu_do_interrupt;
> > 2> Remove unmasking PMI from vpmu_do_interrupt and unmask *physical PMI* when guest vcpu unmasks virtual PMI.
> > I remember that approach 2 can fix this issue. But I do not remember the result of approach 1, since I met this about one year ago.
> > It is my understanding that approach 2 is quite same as approach 1, since normally guest will set the counter to some negative value (for example, -100000) before unmasking virtual PMI.
> > However, approach 2 looks cleaner and more reasonable.
> >
> > Can you have a try and let me know the result? If both can not work, there might be some problems that I have not met before.
> >
> > BTW: Sorry, I did not see your patch to enable NHM vpmu before. So, there is no need for me to work on that now. :)
> >
> > Haitao
> >
> >
> > Dietmar Hahn wrote:
> > > Hi Haitao,
> > >
> > >> Can I know how you enabled vPMU on Nehalem? This is not supported in
> > >> current Xen.
> > >
> > > http://lists.xensource.com/archives/html/xen-devel/2009-09/msg00829.html
> > >
> > >>
> > >> Concerning vpmu support, I totally agree that we can disable this
> > >> feature by default. If anyone really wants to use it, he can use boot
> > >> options to turn it on.
> > >
> > > Yes, that's OK for me.
> > >
> > >> I am preparing a patch for that. And I will
> > >> send a patch to enable NHM vpmu together.
> > >>
> > >> For the problem that Dietmar met, I think I once met this before. Can
> > >> you add some code in vpmu_do_interrupt that sets the counter you are
> > >> using to a value other than zero? Please let me know if that can
> > >> help.
> > >
> > > I don't set the counter to zero. I use 0-val to set the counter.
> > > Actually I testet on Nehalem with
> > > - General Perf-counter #2 (0xc3) with CPU_CLK_UNHALTED and val=1100000
> > > - Fixed counter #1 (0x30a) and val=1100000
> > > The thing is that in normal case the overflows of both counters appear
> > > nearly at the same time.
> > > As described I added some extra tracer for xentrace in
> > > core2_vpmu_do_interrupt() so the code looks like:
> > >
> > > rdmsrl(MSR_CORE_PERF_GLOBAL_STATUS, msr_content); -> 1. Step
> > > {
> > > uint32_t HAHN_l, HAHN_h;
> > > HAHN_l = (uint32_t) msr_content;
> > > HAHN_h = (uint32_t) (msr_content >> 32);
> > > HVMTRACE_3D(HAHN_TR2, v, 1, HAHN_h, HAHN_l); -> 2. Step
> > > }
> > > if ( !msr_content )
> > > return 0;
> > > core2_vpmu_cxt->global_ovf_status |= msr_content;
> > > msr_content = 0xC000000700000000 | ((1 << core2_get_pmc_count())
> > > - 1); wrmsrl(MSR_CORE_PERF_GLOBAL_OVF_CTRL, msr_content); -> 3.
> > > Step
> > >
> > > rdmsrl(MSR_CORE_PERF_GLOBAL_STATUS, msr_content); -> 4. Step
> > > {
> > > uint32_t HAHN_l, HAHN_h;
> > > HAHN_l = (uint32_t) msr_content;
> > > HAHN_h = (uint32_t) (msr_content >> 32);
> > > HVMTRACE_3D(HAHN_TR2, v, 0xa, HAHN_h, HAHN_l); -> 5. Step
> > >
> > > rdmsrl(0xc3, msr_content); -> 6. Step
> > > General counter #2 HAHN_l = (uint32_t) msr_content;
> > > HAHN_h = (uint32_t) (msr_content >> 32);
> > > HVMTRACE_3D(HAHN_TR2, v, 0xc3, HAHN_h, HAHN_l);
> > > rdmsrl(0x30a, msr_content); -> 7. Step
> > > Fixed counter #1 HAHN_l = (uint32_t) msr_content;
> > > HAHN_h = (uint32_t) (msr_content >> 32);
> > > HVMTRACE_3D(HAHN_TR2, v, 0x30a, HAHN_h, HAHN_l);
> > > }
> > >
> > > With these tracers I got the following output:
> > >
> > > Last good NMI:
> > > Both counter cause the NMI. Resetting works OK.
> > > The counter itself were running further.
> > > 2. Step: par1 = 0x01, high = 0x0002, low = 0x0004 ]
> > > rdmsrl(MSR_CORE_PERF_GLOBAL_STATUS)
> > > 5. Step: par1 = 0x0a, high = 0x0000, low = 0x0000 ]
> > > rdmsrl(MSR_CORE_PERF_GLOBAL_STATUS)
> > > 6. Step: par1 = 0xc3, high = 0x0000, low = 0x03c4 ] rdmsrl(0xc3)
> > > -> #2 general counter
> > > 7. Step: par1 = 0x30a, high = 0x0000, low = 0x02da ] rdmsrl(0x30a)
> > > -> #1 fixed counter
> > >
> > > NMI from where things goes wrong:
> > > Both counter cause the NMI. Resetting works NOT correct, only for the
> > > general counter!
> > > The general counter (caused the NMI) seems to be stopped!
> > > 2. Step: par1 = 0x01, high = 0x0002, low = 0x0004 ]
> > > rdmsrl(MSR_CORE_PERF_GLOBAL_STATUS)
> > > 5. Step: par1 = 0x0a, high = 0x0002, low = 0x0000 ]
> > > rdmsrl(MSR_CORE_PERF_GLOBAL_STATUS)
> > > 6. Step: par1 = 0xc3, high = 0x0000, low = 0x00ec ] rdmsrl(0xc3)
> > > -> #2 general counter
> > > 7. Step: par1 = 0x30a, high = 0x0000, low = 0x0000 ] rdmsrl(0x30a)
> > > -> #1 fixed counter
> > >
> > > Wrong NMI:
> > > Only the fixed counter causes the NMI (which was not resetted during
> > > NMI handling above!) Both counter seems to be stopped!
> > > 2. Step: par1 = 0x01, high = 0x0002, low = 0x0000 ]
> > > rdmsrl(MSR_CORE_PERF_GLOBAL_STATUS)
> > > 5. Step: par1 = 0x0a, high = 0x0002, low = 0x0000 ]
> > > rdmsrl(MSR_CORE_PERF_GLOBAL_STATUS)
> > > 6. Step: par1 = 0xc3, high = 0x0000, low = 0x00ec ] rdmsrl(0xc3)
> > > -> #2 general counter
> > > 7. Step: par1 = 0x30a, high = 0x0000, low = 0x0000 ] rdmsrl(0x30a)
> > > -> #1 fixed counter
> > >
> > > And this state remains forever!
> > > I hope my explanations are understandable ;-)
> > >
> > > Until now I can see this behavior only on a Nehalem processor.
> > >
> > > Thanks.
> > > Dietmar
> > >
> > >>
> > >> Best Regards
> > >> Shan Haitao
> > >>
> > >> 2009/10/30 Keir Fraser <keir.fraser@eu.citrix.com>:
> > >>> On 30/10/2009 12:20, "Dietmar Hahn" <dietmar.hahn@ts.fujitsu.com>
> > >>> wrote:
> > >>>
> > >>>> I searched the intel processor spec but couldn't find any help.
> > >>>> So my questions is, what is wrong here?
> > >>>> Can anybody with more knowledge point me in the right direction,
> > >>>> what can I still do to find the real cause of this?
> > >>>
> > >>> You should probably Cc one of the Intel guys who implemented this
> > >>> stuff -- I've added Haitao Shan.
> > >>>
> > >>> Meanwhile I'd be interested to know whether things work okay for
> > >>> you, minus performance counters and the hypervisor hang, if you
> > >>> return immediately from vpmu_initialise(). Really at minimum we
> > >>> need such a fix, perhaps with a boot paremeter to re-enable the
> > >>> feature, for 3.4.2 release; allowing guests to hose the hypervisor
> > >>> like this is of course not on.
> > >>>
> > >>> -- Keir
> >
>
--
Dietmar Hahn
TSP ES&S SWE OS Telephone: +49 (0) 89 636 40274
Fujitsu Technology Solutions Email: dietmar.hahn@ts.fujitsu.com
Otto-Hahn-Ring 6 Internet: http://ts.fujitsu.com
D-81739 München Company details:ts.fujitsu.com/imprint.html
^ permalink raw reply [flat|nested] 21+ messages in thread
* RE: Need help in debugging partially blocked hypervisor
2009-11-03 6:53 ` Dietmar Hahn
@ 2009-11-03 7:32 ` Shan, Haitao
2009-11-03 7:52 ` Dietmar Hahn
0 siblings, 1 reply; 21+ messages in thread
From: Shan, Haitao @ 2009-11-03 7:32 UTC (permalink / raw)
To: Dietmar Hahn, xen-devel; +Cc: Keir Fraser
See my comments embedded. :)
Haitao
Dietmar Hahn wrote:
> The conclusion is, that this seems to be a workaround for the endless
> NMI loop. PMI's are a very rarely event and this should not raise a
> performance
> problem.
I totally agree that this is only a workaround for approach 1.
>
> I didn't try your second approach
>> 2> Remove unmasking PMI from vpmu_do_interrupt and unmask *physical
>> PMI* when guest vcpu unmasks virtual PMI. but I have some question.
>
> - What if the 'physical PMI' is not unmasked in vpmu_do_interrupt and
> a watchdog NMI would occur before the domU unmasks it?
I think the second NMI will be lost.
> - Is it possible that after handling the NMI (and not unmasking)
> another domU got running on this CPU and therefore PMI's got lost?
LVTPC entry in physical local APIC is save/restored by Xen on VCPU switches. So unmasking (or not) of PMI of one vcpu should have no impact on another vcpu. When developing vPMU, I treated as vPMU context both PMU MSRs and LVTPC entry in local APIC. vPMU context is save/restored on physical HW when vcpus is scheduled, either in an active save/restore manner or a lazy one (depending on the PMU usage at the time of switch).
>
> But the real cause of the problem is unknown. As said I saw this only
> on
> Nehalem. Maybe there is a problem together with the hardware? Perhaps
> your
> hardware colleagues know something more ;-)
When I found this problem, I just thought it might be a corner case that only happens on my box (of course, I only see this in NHM, too).
I will try to pin HW guy to see if any explanation, since it is proven to be a general problem on NHM.
But before everything is clear, I think approach 2 is a better solution now.
>
> Thanks
> Dietmar
>
>>
>>>
>>> When I met this problem, I remember that I tried two approaches:
>>> 1> Setting the counter to non-zero before unmasking PMI in
>>> vpmu_do_interrupt; 2> Remove unmasking PMI from vpmu_do_interrupt
>>> and unmask *physical PMI* when guest vcpu unmasks virtual PMI.
>>> I remember that approach 2 can fix this issue. But I do not
>>> remember the result of approach 1, since I met this about one year
>>> ago.
>>> It is my understanding that approach 2 is quite same as approach 1,
>>> since normally guest will set the counter to some negative value
>>> (for example, -100000) before unmasking virtual PMI.
>>> However, approach 2 looks cleaner and more reasonable.
>>>
>>> Can you have a try and let me know the result? If both can not
>>> work, there might be some problems that I have not met before.
>>>
>>> BTW: Sorry, I did not see your patch to enable NHM vpmu before. So,
>>> there is no need for me to work on that now. :)
>>>
>>> Haitao
>>>
>>>
>>> Dietmar Hahn wrote:
>>>> Hi Haitao,
>>>>
>>>>> Can I know how you enabled vPMU on Nehalem? This is not supported
>>>>> in current Xen.
>>>>
>>>> http://lists.xensource.com/archives/html/xen-devel/2009-09/msg00829.html
>>>>
>>>>>
>>>>> Concerning vpmu support, I totally agree that we can disable this
>>>>> feature by default. If anyone really wants to use it, he can use
>>>>> boot options to turn it on.
>>>>
>>>> Yes, that's OK for me.
>>>>
>>>>> I am preparing a patch for that. And I will
>>>>> send a patch to enable NHM vpmu together.
>>>>>
>>>>> For the problem that Dietmar met, I think I once met this before.
>>>>> Can you add some code in vpmu_do_interrupt that sets the counter
>>>>> you are using to a value other than zero? Please let me know if
>>>>> that can help.
>>>>
>>>> I don't set the counter to zero. I use 0-val to set the counter.
>>>> Actually I testet on Nehalem with
>>>> - General Perf-counter #2 (0xc3) with CPU_CLK_UNHALTED and
>>>> val=1100000
>>>> - Fixed counter #1 (0x30a) and val=1100000
>>>> The thing is that in normal case the overflows of both counters
>>>> appear nearly at the same time. As described I added some extra
>>>> tracer for xentrace in core2_vpmu_do_interrupt() so the code looks
>>>> like:
>>>>
>>>> rdmsrl(MSR_CORE_PERF_GLOBAL_STATUS, msr_content); -> 1.
>>>> Step { uint32_t HAHN_l, HAHN_h;
>>>> HAHN_l = (uint32_t) msr_content;
>>>> HAHN_h = (uint32_t) (msr_content >> 32);
>>>> HVMTRACE_3D(HAHN_TR2, v, 1, HAHN_h, HAHN_l); -> 2. Step }
>>>> if ( !msr_content )
>>>> return 0;
>>>> core2_vpmu_cxt->global_ovf_status |= msr_content;
>>>> msr_content = 0xC000000700000000 | ((1 <<
>>>> core2_get_pmc_count()) - 1);
>>>> wrmsrl(MSR_CORE_PERF_GLOBAL_OVF_CTRL, msr_content); -> 3. Step
>>>>
>>>> rdmsrl(MSR_CORE_PERF_GLOBAL_STATUS, msr_content); -> 4.
>>>> Step { uint32_t HAHN_l, HAHN_h;
>>>> HAHN_l = (uint32_t) msr_content;
>>>> HAHN_h = (uint32_t) (msr_content >> 32);
>>>> HVMTRACE_3D(HAHN_TR2, v, 0xa, HAHN_h, HAHN_l); -> 5.
>>>> Step
>>>>
>>>> rdmsrl(0xc3, msr_content); -> 6.
>>>> Step General counter #2 HAHN_l = (uint32_t) msr_content;
>>>> HAHN_h = (uint32_t) (msr_content >> 32);
>>>> HVMTRACE_3D(HAHN_TR2, v, 0xc3, HAHN_h, HAHN_l);
>>>> rdmsrl(0x30a, msr_content); -> 7.
>>>> Step Fixed counter #1 HAHN_l = (uint32_t) msr_content;
>>>> HAHN_h = (uint32_t) (msr_content >> 32);
>>>> HVMTRACE_3D(HAHN_TR2, v, 0x30a, HAHN_h, HAHN_l); }
>>>>
>>>> With these tracers I got the following output:
>>>>
>>>> Last good NMI:
>>>> Both counter cause the NMI. Resetting works OK.
>>>> The counter itself were running further.
>>>> 2. Step: par1 = 0x01, high = 0x0002, low = 0x0004 ]
>>>> rdmsrl(MSR_CORE_PERF_GLOBAL_STATUS)
>>>> 5. Step: par1 = 0x0a, high = 0x0000, low = 0x0000 ]
>>>> rdmsrl(MSR_CORE_PERF_GLOBAL_STATUS)
>>>> 6. Step: par1 = 0xc3, high = 0x0000, low = 0x03c4 ]
>>>> rdmsrl(0xc3) -> #2 general counter
>>>> 7. Step: par1 = 0x30a, high = 0x0000, low = 0x02da ]
>>>> rdmsrl(0x30a) -> #1 fixed counter
>>>>
>>>> NMI from where things goes wrong:
>>>> Both counter cause the NMI. Resetting works NOT correct, only for
>>>> the general counter! The general counter (caused the NMI) seems to
>>>> be stopped!
>>>> 2. Step: par1 = 0x01, high = 0x0002, low = 0x0004 ]
>>>> rdmsrl(MSR_CORE_PERF_GLOBAL_STATUS)
>>>> 5. Step: par1 = 0x0a, high = 0x0002, low = 0x0000 ]
>>>> rdmsrl(MSR_CORE_PERF_GLOBAL_STATUS)
>>>> 6. Step: par1 = 0xc3, high = 0x0000, low = 0x00ec ]
>>>> rdmsrl(0xc3) -> #2 general counter
>>>> 7. Step: par1 = 0x30a, high = 0x0000, low = 0x0000 ]
>>>> rdmsrl(0x30a) -> #1 fixed counter
>>>>
>>>> Wrong NMI:
>>>> Only the fixed counter causes the NMI (which was not resetted
>>>> during NMI handling above!) Both counter seems to be stopped!
>>>> 2. Step: par1 = 0x01, high = 0x0002, low = 0x0000 ]
>>>> rdmsrl(MSR_CORE_PERF_GLOBAL_STATUS)
>>>> 5. Step: par1 = 0x0a, high = 0x0002, low = 0x0000 ]
>>>> rdmsrl(MSR_CORE_PERF_GLOBAL_STATUS)
>>>> 6. Step: par1 = 0xc3, high = 0x0000, low = 0x00ec ]
>>>> rdmsrl(0xc3) -> #2 general counter
>>>> 7. Step: par1 = 0x30a, high = 0x0000, low = 0x0000 ]
>>>> rdmsrl(0x30a) -> #1 fixed counter
>>>>
>>>> And this state remains forever!
>>>> I hope my explanations are understandable ;-)
>>>>
>>>> Until now I can see this behavior only on a Nehalem processor.
>>>>
>>>> Thanks.
>>>> Dietmar
>>>>
>>>>>
>>>>> Best Regards
>>>>> Shan Haitao
>>>>>
>>>>> 2009/10/30 Keir Fraser <keir.fraser@eu.citrix.com>:
>>>>>> On 30/10/2009 12:20, "Dietmar Hahn"
>>>>>> <dietmar.hahn@ts.fujitsu.com> wrote:
>>>>>>
>>>>>>> I searched the intel processor spec but couldn't find any help.
>>>>>>> So my questions is, what is wrong here?
>>>>>>> Can anybody with more knowledge point me in the right direction,
>>>>>>> what can I still do to find the real cause of this?
>>>>>>
>>>>>> You should probably Cc one of the Intel guys who implemented this
>>>>>> stuff -- I've added Haitao Shan.
>>>>>>
>>>>>> Meanwhile I'd be interested to know whether things work okay for
>>>>>> you, minus performance counters and the hypervisor hang, if you
>>>>>> return immediately from vpmu_initialise(). Really at minimum we
>>>>>> need such a fix, perhaps with a boot paremeter to re-enable the
>>>>>> feature, for 3.4.2 release; allowing guests to hose the
>>>>>> hypervisor like this is of course not on.
>>>>>>
>>>>>> -- Keir
^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: Need help in debugging partially blocked hypervisor
2009-11-03 7:32 ` Shan, Haitao
@ 2009-11-03 7:52 ` Dietmar Hahn
2009-11-03 8:02 ` Shan, Haitao
0 siblings, 1 reply; 21+ messages in thread
From: Dietmar Hahn @ 2009-11-03 7:52 UTC (permalink / raw)
To: xen-devel; +Cc: Shan, Haitao, Keir Fraser
Please see below.
> See my comments embedded. :)
>
> Haitao
>
>
> Dietmar Hahn wrote:
> > The conclusion is, that this seems to be a workaround for the endless
> > NMI loop. PMI's are a very rarely event and this should not raise a
> > performance
> > problem.
> I totally agree that this is only a workaround for approach 1.
>
> >
> > I didn't try your second approach
> >> 2> Remove unmasking PMI from vpmu_do_interrupt and unmask *physical
> >> PMI* when guest vcpu unmasks virtual PMI. but I have some question.
> >
> > - What if the 'physical PMI' is not unmasked in vpmu_do_interrupt and
> > a watchdog NMI would occur before the domU unmasks it?
> I think the second NMI will be lost.
>
> > - Is it possible that after handling the NMI (and not unmasking)
> > another domU got running on this CPU and therefore PMI's got lost?
> LVTPC entry in physical local APIC is save/restored by Xen on VCPU switches. So unmasking (or not) of PMI of one vcpu should have no impact on another vcpu. When developing vPMU, I treated as vPMU context both PMU MSRs and LVTPC entry in local APIC. vPMU context is save/restored on physical HW when vcpus is scheduled, either in an active save/restore manner or a lazy one (depending on the PMU usage at the time of switch).
>
> >
> > But the real cause of the problem is unknown. As said I saw this only
> > on
> > Nehalem. Maybe there is a problem together with the hardware? Perhaps
> > your
> > hardware colleagues know something more ;-)
> When I found this problem, I just thought it might be a corner case that only happens on my box (of course, I only see this in NHM, too).
> I will try to pin HW guy to see if any explanation, since it is proven to be a general problem on NHM.
>
> But before everything is clear, I think approach 2 is a better solution now.
What would be the effect if the guest unmasks the PMI (which leads to unmasking the 'physical PMI')
but doesn't reset the counter to a value != 0? Is the guest able to produce the nmi endless loop?
Dietmar.
>
> >
> > Thanks
> > Dietmar
> >
> >>
> >>>
> >>> When I met this problem, I remember that I tried two approaches:
> >>> 1> Setting the counter to non-zero before unmasking PMI in
> >>> vpmu_do_interrupt; 2> Remove unmasking PMI from vpmu_do_interrupt
> >>> and unmask *physical PMI* when guest vcpu unmasks virtual PMI.
> >>> I remember that approach 2 can fix this issue. But I do not
> >>> remember the result of approach 1, since I met this about one year
> >>> ago.
> >>> It is my understanding that approach 2 is quite same as approach 1,
> >>> since normally guest will set the counter to some negative value
> >>> (for example, -100000) before unmasking virtual PMI.
> >>> However, approach 2 looks cleaner and more reasonable.
> >>>
> >>> Can you have a try and let me know the result? If both can not
> >>> work, there might be some problems that I have not met before.
> >>>
> >>> BTW: Sorry, I did not see your patch to enable NHM vpmu before. So,
> >>> there is no need for me to work on that now. :)
> >>>
> >>> Haitao
> >>>
> >>>
> >>> Dietmar Hahn wrote:
> >>>> Hi Haitao,
> >>>>
> >>>>> Can I know how you enabled vPMU on Nehalem? This is not supported
> >>>>> in current Xen.
> >>>>
> >>>> http://lists.xensource.com/archives/html/xen-devel/2009-09/msg00829.html
> >>>>
> >>>>>
> >>>>> Concerning vpmu support, I totally agree that we can disable this
> >>>>> feature by default. If anyone really wants to use it, he can use
> >>>>> boot options to turn it on.
> >>>>
> >>>> Yes, that's OK for me.
> >>>>
> >>>>> I am preparing a patch for that. And I will
> >>>>> send a patch to enable NHM vpmu together.
> >>>>>
> >>>>> For the problem that Dietmar met, I think I once met this before.
> >>>>> Can you add some code in vpmu_do_interrupt that sets the counter
> >>>>> you are using to a value other than zero? Please let me know if
> >>>>> that can help.
> >>>>
> >>>> I don't set the counter to zero. I use 0-val to set the counter.
> >>>> Actually I testet on Nehalem with
> >>>> - General Perf-counter #2 (0xc3) with CPU_CLK_UNHALTED and
> >>>> val=1100000
> >>>> - Fixed counter #1 (0x30a) and val=1100000
> >>>> The thing is that in normal case the overflows of both counters
> >>>> appear nearly at the same time. As described I added some extra
> >>>> tracer for xentrace in core2_vpmu_do_interrupt() so the code looks
> >>>> like:
> >>>>
> >>>> rdmsrl(MSR_CORE_PERF_GLOBAL_STATUS, msr_content); -> 1.
> >>>> Step { uint32_t HAHN_l, HAHN_h;
> >>>> HAHN_l = (uint32_t) msr_content;
> >>>> HAHN_h = (uint32_t) (msr_content >> 32);
> >>>> HVMTRACE_3D(HAHN_TR2, v, 1, HAHN_h, HAHN_l); -> 2. Step }
> >>>> if ( !msr_content )
> >>>> return 0;
> >>>> core2_vpmu_cxt->global_ovf_status |= msr_content;
> >>>> msr_content = 0xC000000700000000 | ((1 <<
> >>>> core2_get_pmc_count()) - 1);
> >>>> wrmsrl(MSR_CORE_PERF_GLOBAL_OVF_CTRL, msr_content); -> 3. Step
> >>>>
> >>>> rdmsrl(MSR_CORE_PERF_GLOBAL_STATUS, msr_content); -> 4.
> >>>> Step { uint32_t HAHN_l, HAHN_h;
> >>>> HAHN_l = (uint32_t) msr_content;
> >>>> HAHN_h = (uint32_t) (msr_content >> 32);
> >>>> HVMTRACE_3D(HAHN_TR2, v, 0xa, HAHN_h, HAHN_l); -> 5.
> >>>> Step
> >>>>
> >>>> rdmsrl(0xc3, msr_content); -> 6.
> >>>> Step General counter #2 HAHN_l = (uint32_t) msr_content;
> >>>> HAHN_h = (uint32_t) (msr_content >> 32);
> >>>> HVMTRACE_3D(HAHN_TR2, v, 0xc3, HAHN_h, HAHN_l);
> >>>> rdmsrl(0x30a, msr_content); -> 7.
> >>>> Step Fixed counter #1 HAHN_l = (uint32_t) msr_content;
> >>>> HAHN_h = (uint32_t) (msr_content >> 32);
> >>>> HVMTRACE_3D(HAHN_TR2, v, 0x30a, HAHN_h, HAHN_l); }
> >>>>
> >>>> With these tracers I got the following output:
> >>>>
> >>>> Last good NMI:
> >>>> Both counter cause the NMI. Resetting works OK.
> >>>> The counter itself were running further.
> >>>> 2. Step: par1 = 0x01, high = 0x0002, low = 0x0004 ]
> >>>> rdmsrl(MSR_CORE_PERF_GLOBAL_STATUS)
> >>>> 5. Step: par1 = 0x0a, high = 0x0000, low = 0x0000 ]
> >>>> rdmsrl(MSR_CORE_PERF_GLOBAL_STATUS)
> >>>> 6. Step: par1 = 0xc3, high = 0x0000, low = 0x03c4 ]
> >>>> rdmsrl(0xc3) -> #2 general counter
> >>>> 7. Step: par1 = 0x30a, high = 0x0000, low = 0x02da ]
> >>>> rdmsrl(0x30a) -> #1 fixed counter
> >>>>
> >>>> NMI from where things goes wrong:
> >>>> Both counter cause the NMI. Resetting works NOT correct, only for
> >>>> the general counter! The general counter (caused the NMI) seems to
> >>>> be stopped!
> >>>> 2. Step: par1 = 0x01, high = 0x0002, low = 0x0004 ]
> >>>> rdmsrl(MSR_CORE_PERF_GLOBAL_STATUS)
> >>>> 5. Step: par1 = 0x0a, high = 0x0002, low = 0x0000 ]
> >>>> rdmsrl(MSR_CORE_PERF_GLOBAL_STATUS)
> >>>> 6. Step: par1 = 0xc3, high = 0x0000, low = 0x00ec ]
> >>>> rdmsrl(0xc3) -> #2 general counter
> >>>> 7. Step: par1 = 0x30a, high = 0x0000, low = 0x0000 ]
> >>>> rdmsrl(0x30a) -> #1 fixed counter
> >>>>
> >>>> Wrong NMI:
> >>>> Only the fixed counter causes the NMI (which was not resetted
> >>>> during NMI handling above!) Both counter seems to be stopped!
> >>>> 2. Step: par1 = 0x01, high = 0x0002, low = 0x0000 ]
> >>>> rdmsrl(MSR_CORE_PERF_GLOBAL_STATUS)
> >>>> 5. Step: par1 = 0x0a, high = 0x0002, low = 0x0000 ]
> >>>> rdmsrl(MSR_CORE_PERF_GLOBAL_STATUS)
> >>>> 6. Step: par1 = 0xc3, high = 0x0000, low = 0x00ec ]
> >>>> rdmsrl(0xc3) -> #2 general counter
> >>>> 7. Step: par1 = 0x30a, high = 0x0000, low = 0x0000 ]
> >>>> rdmsrl(0x30a) -> #1 fixed counter
> >>>>
> >>>> And this state remains forever!
> >>>> I hope my explanations are understandable ;-)
> >>>>
> >>>> Until now I can see this behavior only on a Nehalem processor.
> >>>>
> >>>> Thanks.
> >>>> Dietmar
> >>>>
> >>>>>
> >>>>> Best Regards
> >>>>> Shan Haitao
> >>>>>
> >>>>> 2009/10/30 Keir Fraser <keir.fraser@eu.citrix.com>:
> >>>>>> On 30/10/2009 12:20, "Dietmar Hahn"
> >>>>>> <dietmar.hahn@ts.fujitsu.com> wrote:
> >>>>>>
> >>>>>>> I searched the intel processor spec but couldn't find any help.
> >>>>>>> So my questions is, what is wrong here?
> >>>>>>> Can anybody with more knowledge point me in the right direction,
> >>>>>>> what can I still do to find the real cause of this?
> >>>>>>
> >>>>>> You should probably Cc one of the Intel guys who implemented this
> >>>>>> stuff -- I've added Haitao Shan.
> >>>>>>
> >>>>>> Meanwhile I'd be interested to know whether things work okay for
> >>>>>> you, minus performance counters and the hypervisor hang, if you
> >>>>>> return immediately from vpmu_initialise(). Really at minimum we
> >>>>>> need such a fix, perhaps with a boot paremeter to re-enable the
> >>>>>> feature, for 3.4.2 release; allowing guests to hose the
> >>>>>> hypervisor like this is of course not on.
> >>>>>>
> >>>>>> -- Keir
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/xen-devel
>
>
--
Company details: http://ts.fujitsu.com/imprint.html
^ permalink raw reply [flat|nested] 21+ messages in thread
* RE: Need help in debugging partially blocked hypervisor
2009-11-03 7:52 ` Dietmar Hahn
@ 2009-11-03 8:02 ` Shan, Haitao
2009-11-03 8:24 ` Dietmar Hahn
0 siblings, 1 reply; 21+ messages in thread
From: Shan, Haitao @ 2009-11-03 8:02 UTC (permalink / raw)
To: Dietmar Hahn, xen-devel; +Cc: Keir Fraser
I suspect the guest will reproduce this PMI loop if guest behaves as you said in this email. But as far as I know, VTune and oprofile do not behave like that.
Of course, this approach is still like workaround (unless I get comfirm that HW requires to do so). This approach is preferrable because it does not change the contents of MSRs. Thus, we have no impact on guest software that does rely on reading the correct value from HW. Approach 1 existed just because we knew that in event-based sampling, counter value on receiving PMI was not used by OProfile/VTune at all and it was safe to set the counter to some non-zero value.
Haitao
Dietmar Hahn wrote:
> Please see below.
>
>> See my comments embedded. :)
>>
>> Haitao
>>
>>
>> Dietmar Hahn wrote:
>>> The conclusion is, that this seems to be a workaround for the
>>> endless NMI loop. PMI's are a very rarely event and this should not
>>> raise a performance problem.
>> I totally agree that this is only a workaround for approach 1.
>>
>>>
>>> I didn't try your second approach
>>>> 2> Remove unmasking PMI from vpmu_do_interrupt and unmask *physical
>>>> PMI* when guest vcpu unmasks virtual PMI. but I have some question.
>>>
>>> - What if the 'physical PMI' is not unmasked in vpmu_do_interrupt
>>> and a watchdog NMI would occur before the domU unmasks it?
>> I think the second NMI will be lost.
>>
>>> - Is it possible that after handling the NMI (and not unmasking)
>>> another domU got running on this CPU and therefore PMI's got lost?
>> LVTPC entry in physical local APIC is save/restored by Xen on VCPU
>> switches. So unmasking (or not) of PMI of one vcpu should have no
>> impact on another vcpu. When developing vPMU, I treated as vPMU
>> context both PMU MSRs and LVTPC entry in local APIC. vPMU context is
>> save/restored on physical HW when vcpus is scheduled, either in an
>> active save/restore manner or a lazy one (depending on the PMU usage
>> at the time of switch).
>>
>>>
>>> But the real cause of the problem is unknown. As said I saw this
>>> only on Nehalem. Maybe there is a problem together with the
>>> hardware? Perhaps your hardware colleagues know something more ;-)
>> When I found this problem, I just thought it might be a corner case
>> that only happens on my box (of course, I only see this in NHM,
>> too).
>> I will try to pin HW guy to see if any explanation, since it is
>> proven to be a general problem on NHM.
>>
>> But before everything is clear, I think approach 2 is a better
>> solution now.
>
> What would be the effect if the guest unmasks the PMI (which leads to
> unmasking the 'physical PMI') but doesn't reset the counter to a
> value != 0? Is the guest able to produce the nmi endless loop?
>
> Dietmar.
>
>>
>>>
>>> Thanks
>>> Dietmar
>>>
>>>>
>>>>>
>>>>> When I met this problem, I remember that I tried two approaches:
>>>>> 1> Setting the counter to non-zero before unmasking PMI in
>>>>> vpmu_do_interrupt; 2> Remove unmasking PMI from vpmu_do_interrupt
>>>>> and unmask *physical PMI* when guest vcpu unmasks virtual PMI.
>>>>> I remember that approach 2 can fix this issue. But I do not
>>>>> remember the result of approach 1, since I met this about one
>>>>> year ago. It is my understanding that approach 2 is quite same as
>>>>> approach 1, since normally guest will set the counter to some
>>>>> negative value (for example, -100000) before unmasking virtual
>>>>> PMI.
>>>>> However, approach 2 looks cleaner and more reasonable.
>>>>>
>>>>> Can you have a try and let me know the result? If both can not
>>>>> work, there might be some problems that I have not met before.
>>>>>
>>>>> BTW: Sorry, I did not see your patch to enable NHM vpmu before.
>>>>> So, there is no need for me to work on that now. :)
>>>>>
>>>>> Haitao
>>>>>
>>>>>
>>>>> Dietmar Hahn wrote:
>>>>>> Hi Haitao,
>>>>>>
>>>>>>> Can I know how you enabled vPMU on Nehalem? This is not
>>>>>>> supported in current Xen.
>>>>>>
>>>>>> http://lists.xensource.com/archives/html/xen-devel/2009-09/msg00829.html
>>>>>>
>>>>>>>
>>>>>>> Concerning vpmu support, I totally agree that we can disable
>>>>>>> this feature by default. If anyone really wants to use it, he
>>>>>>> can use boot options to turn it on.
>>>>>>
>>>>>> Yes, that's OK for me.
>>>>>>
>>>>>>> I am preparing a patch for that. And I will
>>>>>>> send a patch to enable NHM vpmu together.
>>>>>>>
>>>>>>> For the problem that Dietmar met, I think I once met this
>>>>>>> before. Can you add some code in vpmu_do_interrupt that sets
>>>>>>> the counter you are using to a value other than zero? Please
>>>>>>> let me know if that can help.
>>>>>>
>>>>>> I don't set the counter to zero. I use 0-val to set the counter.
>>>>>> Actually I testet on Nehalem with
>>>>>> - General Perf-counter #2 (0xc3) with CPU_CLK_UNHALTED and
>>>>>> val=1100000
>>>>>> - Fixed counter #1 (0x30a) and val=1100000
>>>>>> The thing is that in normal case the overflows of both counters
>>>>>> appear nearly at the same time. As described I added some extra
>>>>>> tracer for xentrace in core2_vpmu_do_interrupt() so the code
>>>>>> looks like:
>>>>>>
>>>>>> rdmsrl(MSR_CORE_PERF_GLOBAL_STATUS, msr_content); -> 1.
>>>>>> Step { uint32_t HAHN_l, HAHN_h;
>>>>>> HAHN_l = (uint32_t) msr_content;
>>>>>> HAHN_h = (uint32_t) (msr_content >> 32);
>>>>>> HVMTRACE_3D(HAHN_TR2, v, 1, HAHN_h, HAHN_l); -> 2. Step
>>>>>> } if ( !msr_content ) return 0;
>>>>>> core2_vpmu_cxt->global_ovf_status |= msr_content;
>>>>>> msr_content = 0xC000000700000000 | ((1 <<
>>>>>> core2_get_pmc_count()) - 1);
>>>>>> wrmsrl(MSR_CORE_PERF_GLOBAL_OVF_CTRL, msr_content); -> 3. Step
>>>>>>
>>>>>> rdmsrl(MSR_CORE_PERF_GLOBAL_STATUS, msr_content); -> 4.
>>>>>> Step { uint32_t HAHN_l, HAHN_h;
>>>>>> HAHN_l = (uint32_t) msr_content;
>>>>>> HAHN_h = (uint32_t) (msr_content >> 32);
>>>>>> HVMTRACE_3D(HAHN_TR2, v, 0xa, HAHN_h, HAHN_l); -> 5.
>>>>>> Step
>>>>>>
>>>>>> rdmsrl(0xc3, msr_content); -> 6.
>>>>>> Step General counter #2 HAHN_l = (uint32_t) msr_content;
>>>>>> HAHN_h = (uint32_t) (msr_content >> 32);
>>>>>> HVMTRACE_3D(HAHN_TR2, v, 0xc3, HAHN_h, HAHN_l);
>>>>>> rdmsrl(0x30a, msr_content); -> 7.
>>>>>> Step Fixed counter #1 HAHN_l = (uint32_t) msr_content;
>>>>>> HAHN_h = (uint32_t) (msr_content >> 32);
>>>>>> HVMTRACE_3D(HAHN_TR2, v, 0x30a, HAHN_h, HAHN_l); }
>>>>>>
>>>>>> With these tracers I got the following output:
>>>>>>
>>>>>> Last good NMI:
>>>>>> Both counter cause the NMI. Resetting works OK.
>>>>>> The counter itself were running further.
>>>>>> 2. Step: par1 = 0x01, high = 0x0002, low = 0x0004 ]
>>>>>> rdmsrl(MSR_CORE_PERF_GLOBAL_STATUS)
>>>>>> 5. Step: par1 = 0x0a, high = 0x0000, low = 0x0000 ]
>>>>>> rdmsrl(MSR_CORE_PERF_GLOBAL_STATUS)
>>>>>> 6. Step: par1 = 0xc3, high = 0x0000, low = 0x03c4 ]
>>>>>> rdmsrl(0xc3) -> #2 general counter
>>>>>> 7. Step: par1 = 0x30a, high = 0x0000, low = 0x02da ]
>>>>>> rdmsrl(0x30a) -> #1 fixed counter
>>>>>>
>>>>>> NMI from where things goes wrong:
>>>>>> Both counter cause the NMI. Resetting works NOT correct, only for
>>>>>> the general counter! The general counter (caused the NMI) seems
>>>>>> to be stopped!
>>>>>> 2. Step: par1 = 0x01, high = 0x0002, low = 0x0004 ]
>>>>>> rdmsrl(MSR_CORE_PERF_GLOBAL_STATUS)
>>>>>> 5. Step: par1 = 0x0a, high = 0x0002, low = 0x0000 ]
>>>>>> rdmsrl(MSR_CORE_PERF_GLOBAL_STATUS)
>>>>>> 6. Step: par1 = 0xc3, high = 0x0000, low = 0x00ec ]
>>>>>> rdmsrl(0xc3) -> #2 general counter
>>>>>> 7. Step: par1 = 0x30a, high = 0x0000, low = 0x0000 ]
>>>>>> rdmsrl(0x30a) -> #1 fixed counter
>>>>>>
>>>>>> Wrong NMI:
>>>>>> Only the fixed counter causes the NMI (which was not resetted
>>>>>> during NMI handling above!) Both counter seems to be stopped!
>>>>>> 2. Step: par1 = 0x01, high = 0x0002, low = 0x0000 ]
>>>>>> rdmsrl(MSR_CORE_PERF_GLOBAL_STATUS)
>>>>>> 5. Step: par1 = 0x0a, high = 0x0002, low = 0x0000 ]
>>>>>> rdmsrl(MSR_CORE_PERF_GLOBAL_STATUS)
>>>>>> 6. Step: par1 = 0xc3, high = 0x0000, low = 0x00ec ]
>>>>>> rdmsrl(0xc3) -> #2 general counter
>>>>>> 7. Step: par1 = 0x30a, high = 0x0000, low = 0x0000 ]
>>>>>> rdmsrl(0x30a) -> #1 fixed counter
>>>>>>
>>>>>> And this state remains forever!
>>>>>> I hope my explanations are understandable ;-)
>>>>>>
>>>>>> Until now I can see this behavior only on a Nehalem processor.
>>>>>>
>>>>>> Thanks.
>>>>>> Dietmar
>>>>>>
>>>>>>>
>>>>>>> Best Regards
>>>>>>> Shan Haitao
>>>>>>>
>>>>>>> 2009/10/30 Keir Fraser <keir.fraser@eu.citrix.com>:
>>>>>>>> On 30/10/2009 12:20, "Dietmar Hahn"
>>>>>>>> <dietmar.hahn@ts.fujitsu.com> wrote:
>>>>>>>>
>>>>>>>>> I searched the intel processor spec but couldn't find any
>>>>>>>>> help. So my questions is, what is wrong here?
>>>>>>>>> Can anybody with more knowledge point me in the right
>>>>>>>>> direction, what can I still do to find the real cause of this?
>>>>>>>>
>>>>>>>> You should probably Cc one of the Intel guys who implemented
>>>>>>>> this stuff -- I've added Haitao Shan.
>>>>>>>>
>>>>>>>> Meanwhile I'd be interested to know whether things work okay
>>>>>>>> for you, minus performance counters and the hypervisor hang,
>>>>>>>> if you return immediately from vpmu_initialise(). Really at
>>>>>>>> minimum we need such a fix, perhaps with a boot paremeter to
>>>>>>>> re-enable the feature, for 3.4.2 release; allowing guests to
>>>>>>>> hose the hypervisor like this is of course not on.
>>>>>>>>
>>>>>>>> -- Keir
>> _______________________________________________
>> Xen-devel mailing list
>> Xen-devel@lists.xensource.com
>> http://lists.xensource.com/xen-devel
^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: Need help in debugging partially blocked hypervisor
2009-11-03 8:02 ` Shan, Haitao
@ 2009-11-03 8:24 ` Dietmar Hahn
2009-11-03 8:43 ` Shan, Haitao
2009-11-03 9:00 ` Shan, Haitao
0 siblings, 2 replies; 21+ messages in thread
From: Dietmar Hahn @ 2009-11-03 8:24 UTC (permalink / raw)
To: xen-devel; +Cc: Shan, Haitao, Keir Fraser
> I suspect the guest will reproduce this PMI loop if guest behaves as you said in this email. But as far as I know, VTune and oprofile do not behave like that.
> Of course, this approach is still like workaround (unless I get comfirm that HW requires to do so). This approach is preferrable because it does not change the contents of MSRs. Thus, we have no impact on guest software that does rely on reading the correct value from HW. Approach 1 existed just because we knew that in event-based sampling, counter value on receiving PMI was not used by OProfile/VTune at all and it was safe to set the counter to some non-zero value.
>
> Haitao
>
OK, then will you send a patch?
Dietmar.
>
> Dietmar Hahn wrote:
> > Please see below.
> >
> >> See my comments embedded. :)
> >>
> >> Haitao
> >>
> >>
> >> Dietmar Hahn wrote:
> >>> The conclusion is, that this seems to be a workaround for the
> >>> endless NMI loop. PMI's are a very rarely event and this should not
> >>> raise a performance problem.
> >> I totally agree that this is only a workaround for approach 1.
> >>
> >>>
> >>> I didn't try your second approach
> >>>> 2> Remove unmasking PMI from vpmu_do_interrupt and unmask *physical
> >>>> PMI* when guest vcpu unmasks virtual PMI. but I have some question.
> >>>
> >>> - What if the 'physical PMI' is not unmasked in vpmu_do_interrupt
> >>> and a watchdog NMI would occur before the domU unmasks it?
> >> I think the second NMI will be lost.
> >>
> >>> - Is it possible that after handling the NMI (and not unmasking)
> >>> another domU got running on this CPU and therefore PMI's got lost?
> >> LVTPC entry in physical local APIC is save/restored by Xen on VCPU
> >> switches. So unmasking (or not) of PMI of one vcpu should have no
> >> impact on another vcpu. When developing vPMU, I treated as vPMU
> >> context both PMU MSRs and LVTPC entry in local APIC. vPMU context is
> >> save/restored on physical HW when vcpus is scheduled, either in an
> >> active save/restore manner or a lazy one (depending on the PMU usage
> >> at the time of switch).
> >>
> >>>
> >>> But the real cause of the problem is unknown. As said I saw this
> >>> only on Nehalem. Maybe there is a problem together with the
> >>> hardware? Perhaps your hardware colleagues know something more ;-)
> >> When I found this problem, I just thought it might be a corner case
> >> that only happens on my box (of course, I only see this in NHM,
> >> too).
> >> I will try to pin HW guy to see if any explanation, since it is
> >> proven to be a general problem on NHM.
> >>
> >> But before everything is clear, I think approach 2 is a better
> >> solution now.
> >
> > What would be the effect if the guest unmasks the PMI (which leads to
> > unmasking the 'physical PMI') but doesn't reset the counter to a
> > value != 0? Is the guest able to produce the nmi endless loop?
> >
> > Dietmar.
> >
> >>
> >>>
> >>> Thanks
> >>> Dietmar
> >>>
> >>>>
> >>>>>
> >>>>> When I met this problem, I remember that I tried two approaches:
> >>>>> 1> Setting the counter to non-zero before unmasking PMI in
> >>>>> vpmu_do_interrupt; 2> Remove unmasking PMI from vpmu_do_interrupt
> >>>>> and unmask *physical PMI* when guest vcpu unmasks virtual PMI.
> >>>>> I remember that approach 2 can fix this issue. But I do not
> >>>>> remember the result of approach 1, since I met this about one
> >>>>> year ago. It is my understanding that approach 2 is quite same as
> >>>>> approach 1, since normally guest will set the counter to some
> >>>>> negative value (for example, -100000) before unmasking virtual
> >>>>> PMI.
> >>>>> However, approach 2 looks cleaner and more reasonable.
> >>>>>
> >>>>> Can you have a try and let me know the result? If both can not
> >>>>> work, there might be some problems that I have not met before.
> >>>>>
> >>>>> BTW: Sorry, I did not see your patch to enable NHM vpmu before.
> >>>>> So, there is no need for me to work on that now. :)
> >>>>>
> >>>>> Haitao
> >>>>>
> >>>>>
> >>>>> Dietmar Hahn wrote:
> >>>>>> Hi Haitao,
> >>>>>>
> >>>>>>> Can I know how you enabled vPMU on Nehalem? This is not
> >>>>>>> supported in current Xen.
> >>>>>>
> >>>>>> http://lists.xensource.com/archives/html/xen-devel/2009-09/msg00829.html
> >>>>>>
> >>>>>>>
> >>>>>>> Concerning vpmu support, I totally agree that we can disable
> >>>>>>> this feature by default. If anyone really wants to use it, he
> >>>>>>> can use boot options to turn it on.
> >>>>>>
> >>>>>> Yes, that's OK for me.
> >>>>>>
> >>>>>>> I am preparing a patch for that. And I will
> >>>>>>> send a patch to enable NHM vpmu together.
> >>>>>>>
> >>>>>>> For the problem that Dietmar met, I think I once met this
> >>>>>>> before. Can you add some code in vpmu_do_interrupt that sets
> >>>>>>> the counter you are using to a value other than zero? Please
> >>>>>>> let me know if that can help.
> >>>>>>
> >>>>>> I don't set the counter to zero. I use 0-val to set the counter.
> >>>>>> Actually I testet on Nehalem with
> >>>>>> - General Perf-counter #2 (0xc3) with CPU_CLK_UNHALTED and
> >>>>>> val=1100000
> >>>>>> - Fixed counter #1 (0x30a) and val=1100000
> >>>>>> The thing is that in normal case the overflows of both counters
> >>>>>> appear nearly at the same time. As described I added some extra
> >>>>>> tracer for xentrace in core2_vpmu_do_interrupt() so the code
> >>>>>> looks like:
> >>>>>>
> >>>>>> rdmsrl(MSR_CORE_PERF_GLOBAL_STATUS, msr_content); -> 1.
> >>>>>> Step { uint32_t HAHN_l, HAHN_h;
> >>>>>> HAHN_l = (uint32_t) msr_content;
> >>>>>> HAHN_h = (uint32_t) (msr_content >> 32);
> >>>>>> HVMTRACE_3D(HAHN_TR2, v, 1, HAHN_h, HAHN_l); -> 2. Step
> >>>>>> } if ( !msr_content ) return 0;
> >>>>>> core2_vpmu_cxt->global_ovf_status |= msr_content;
> >>>>>> msr_content = 0xC000000700000000 | ((1 <<
> >>>>>> core2_get_pmc_count()) - 1);
> >>>>>> wrmsrl(MSR_CORE_PERF_GLOBAL_OVF_CTRL, msr_content); -> 3. Step
> >>>>>>
> >>>>>> rdmsrl(MSR_CORE_PERF_GLOBAL_STATUS, msr_content); -> 4.
> >>>>>> Step { uint32_t HAHN_l, HAHN_h;
> >>>>>> HAHN_l = (uint32_t) msr_content;
> >>>>>> HAHN_h = (uint32_t) (msr_content >> 32);
> >>>>>> HVMTRACE_3D(HAHN_TR2, v, 0xa, HAHN_h, HAHN_l); -> 5.
> >>>>>> Step
> >>>>>>
> >>>>>> rdmsrl(0xc3, msr_content); -> 6.
> >>>>>> Step General counter #2 HAHN_l = (uint32_t) msr_content;
> >>>>>> HAHN_h = (uint32_t) (msr_content >> 32);
> >>>>>> HVMTRACE_3D(HAHN_TR2, v, 0xc3, HAHN_h, HAHN_l);
> >>>>>> rdmsrl(0x30a, msr_content); -> 7.
> >>>>>> Step Fixed counter #1 HAHN_l = (uint32_t) msr_content;
> >>>>>> HAHN_h = (uint32_t) (msr_content >> 32);
> >>>>>> HVMTRACE_3D(HAHN_TR2, v, 0x30a, HAHN_h, HAHN_l); }
> >>>>>>
> >>>>>> With these tracers I got the following output:
> >>>>>>
> >>>>>> Last good NMI:
> >>>>>> Both counter cause the NMI. Resetting works OK.
> >>>>>> The counter itself were running further.
> >>>>>> 2. Step: par1 = 0x01, high = 0x0002, low = 0x0004 ]
> >>>>>> rdmsrl(MSR_CORE_PERF_GLOBAL_STATUS)
> >>>>>> 5. Step: par1 = 0x0a, high = 0x0000, low = 0x0000 ]
> >>>>>> rdmsrl(MSR_CORE_PERF_GLOBAL_STATUS)
> >>>>>> 6. Step: par1 = 0xc3, high = 0x0000, low = 0x03c4 ]
> >>>>>> rdmsrl(0xc3) -> #2 general counter
> >>>>>> 7. Step: par1 = 0x30a, high = 0x0000, low = 0x02da ]
> >>>>>> rdmsrl(0x30a) -> #1 fixed counter
> >>>>>>
> >>>>>> NMI from where things goes wrong:
> >>>>>> Both counter cause the NMI. Resetting works NOT correct, only for
> >>>>>> the general counter! The general counter (caused the NMI) seems
> >>>>>> to be stopped!
> >>>>>> 2. Step: par1 = 0x01, high = 0x0002, low = 0x0004 ]
> >>>>>> rdmsrl(MSR_CORE_PERF_GLOBAL_STATUS)
> >>>>>> 5. Step: par1 = 0x0a, high = 0x0002, low = 0x0000 ]
> >>>>>> rdmsrl(MSR_CORE_PERF_GLOBAL_STATUS)
> >>>>>> 6. Step: par1 = 0xc3, high = 0x0000, low = 0x00ec ]
> >>>>>> rdmsrl(0xc3) -> #2 general counter
> >>>>>> 7. Step: par1 = 0x30a, high = 0x0000, low = 0x0000 ]
> >>>>>> rdmsrl(0x30a) -> #1 fixed counter
> >>>>>>
> >>>>>> Wrong NMI:
> >>>>>> Only the fixed counter causes the NMI (which was not resetted
> >>>>>> during NMI handling above!) Both counter seems to be stopped!
> >>>>>> 2. Step: par1 = 0x01, high = 0x0002, low = 0x0000 ]
> >>>>>> rdmsrl(MSR_CORE_PERF_GLOBAL_STATUS)
> >>>>>> 5. Step: par1 = 0x0a, high = 0x0002, low = 0x0000 ]
> >>>>>> rdmsrl(MSR_CORE_PERF_GLOBAL_STATUS)
> >>>>>> 6. Step: par1 = 0xc3, high = 0x0000, low = 0x00ec ]
> >>>>>> rdmsrl(0xc3) -> #2 general counter
> >>>>>> 7. Step: par1 = 0x30a, high = 0x0000, low = 0x0000 ]
> >>>>>> rdmsrl(0x30a) -> #1 fixed counter
> >>>>>>
> >>>>>> And this state remains forever!
> >>>>>> I hope my explanations are understandable ;-)
> >>>>>>
> >>>>>> Until now I can see this behavior only on a Nehalem processor.
> >>>>>>
> >>>>>> Thanks.
> >>>>>> Dietmar
> >>>>>>
> >>>>>>>
> >>>>>>> Best Regards
> >>>>>>> Shan Haitao
> >>>>>>>
> >>>>>>> 2009/10/30 Keir Fraser <keir.fraser@eu.citrix.com>:
> >>>>>>>> On 30/10/2009 12:20, "Dietmar Hahn"
> >>>>>>>> <dietmar.hahn@ts.fujitsu.com> wrote:
> >>>>>>>>
> >>>>>>>>> I searched the intel processor spec but couldn't find any
> >>>>>>>>> help. So my questions is, what is wrong here?
> >>>>>>>>> Can anybody with more knowledge point me in the right
> >>>>>>>>> direction, what can I still do to find the real cause of this?
> >>>>>>>>
> >>>>>>>> You should probably Cc one of the Intel guys who implemented
> >>>>>>>> this stuff -- I've added Haitao Shan.
> >>>>>>>>
> >>>>>>>> Meanwhile I'd be interested to know whether things work okay
> >>>>>>>> for you, minus performance counters and the hypervisor hang,
> >>>>>>>> if you return immediately from vpmu_initialise(). Really at
> >>>>>>>> minimum we need such a fix, perhaps with a boot paremeter to
> >>>>>>>> re-enable the feature, for 3.4.2 release; allowing guests to
> >>>>>>>> hose the hypervisor like this is of course not on.
> >>>>>>>>
> >>>>>>>> -- Keir
> >> _______________________________________________
> >> Xen-devel mailing list
> >> Xen-devel@lists.xensource.com
> >> http://lists.xensource.com/xen-devel
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/xen-devel
>
>
--
Dietmar Hahn
TSP ES&S SWE OS Telephone: +49 (0) 89 636 40274
Fujitsu Technology Solutions Email: dietmar.hahn@ts.fujitsu.com
Otto-Hahn-Ring 6 Internet: http://ts.fujitsu.com
D-81739 München Company details:ts.fujitsu.com/imprint.html
^ permalink raw reply [flat|nested] 21+ messages in thread
* RE: Need help in debugging partially blocked hypervisor
2009-11-03 8:24 ` Dietmar Hahn
@ 2009-11-03 8:43 ` Shan, Haitao
2009-11-03 9:03 ` Dietmar Hahn
2009-11-03 9:00 ` Shan, Haitao
1 sibling, 1 reply; 21+ messages in thread
From: Shan, Haitao @ 2009-11-03 8:43 UTC (permalink / raw)
To: Dietmar Hahn, xen-devel; +Cc: Keir Fraser
No problem.
Can you help to test? I have no test box at hand now, which might cause delay.
Haitao
Dietmar Hahn wrote:
>> I suspect the guest will reproduce this PMI loop if guest behaves as
>> you said in this email. But as far as I know, VTune and oprofile do
>> not behave like that.
>> Of course, this approach is still like workaround (unless I get
>> comfirm that HW requires to do so). This approach is preferrable
>> because it does not change the contents of MSRs. Thus, we have no
>> impact on guest software that does rely on reading the correct value
>> from HW. Approach 1 existed just because we knew that in event-based
>> sampling, counter value on receiving PMI was not used by
>> OProfile/VTune at all and it was safe to set the counter to some
>> non-zero value.
>>
>> Haitao
>>
>
> OK, then will you send a patch?
> Dietmar.
>
>>
>> Dietmar Hahn wrote:
>>> Please see below.
>>>
>>>> See my comments embedded. :)
>>>>
>>>> Haitao
>>>>
>>>>
>>>> Dietmar Hahn wrote:
>>>>> The conclusion is, that this seems to be a workaround for the
>>>>> endless NMI loop. PMI's are a very rarely event and this should
>>>>> not raise a performance problem.
>>>> I totally agree that this is only a workaround for approach 1.
>>>>
>>>>>
>>>>> I didn't try your second approach
>>>>>> 2> Remove unmasking PMI from vpmu_do_interrupt and unmask
>>>>>> *physical PMI* when guest vcpu unmasks virtual PMI. but I have
>>>>>> some question.
>>>>>
>>>>> - What if the 'physical PMI' is not unmasked in vpmu_do_interrupt
>>>>> and a watchdog NMI would occur before the domU unmasks it?
>>>> I think the second NMI will be lost.
>>>>
>>>>> - Is it possible that after handling the NMI (and not unmasking)
>>>>> another domU got running on this CPU and therefore PMI's got
>>>>> lost?
>>>> LVTPC entry in physical local APIC is save/restored by Xen on VCPU
>>>> switches. So unmasking (or not) of PMI of one vcpu should have no
>>>> impact on another vcpu. When developing vPMU, I treated as vPMU
>>>> context both PMU MSRs and LVTPC entry in local APIC. vPMU context
>>>> is save/restored on physical HW when vcpus is scheduled, either in
>>>> an active save/restore manner or a lazy one (depending on the PMU
>>>> usage at the time of switch).
>>>>
>>>>>
>>>>> But the real cause of the problem is unknown. As said I saw this
>>>>> only on Nehalem. Maybe there is a problem together with the
>>>>> hardware? Perhaps your hardware colleagues know something more ;-)
>>>> When I found this problem, I just thought it might be a corner case
>>>> that only happens on my box (of course, I only see this in NHM,
>>>> too). I will try to pin HW guy to see if any explanation, since it
>>>> is proven to be a general problem on NHM.
>>>>
>>>> But before everything is clear, I think approach 2 is a better
>>>> solution now.
>>>
>>> What would be the effect if the guest unmasks the PMI (which leads
>>> to unmasking the 'physical PMI') but doesn't reset the counter to a
>>> value != 0? Is the guest able to produce the nmi endless loop?
>>>
>>> Dietmar.
>>>
>>>>
>>>>>
>>>>> Thanks
>>>>> Dietmar
>>>>>
>>>>>>
>>>>>>>
>>>>>>> When I met this problem, I remember that I tried two approaches:
>>>>>>> 1> Setting the counter to non-zero before unmasking PMI in
>>>>>>> vpmu_do_interrupt; 2> Remove unmasking PMI from
>>>>>>> vpmu_do_interrupt and unmask *physical PMI* when guest vcpu
>>>>>>> unmasks virtual PMI.
>>>>>>> I remember that approach 2 can fix this issue. But I do not
>>>>>>> remember the result of approach 1, since I met this about one
>>>>>>> year ago. It is my understanding that approach 2 is quite same
>>>>>>> as approach 1, since normally guest will set the counter to some
>>>>>>> negative value (for example, -100000) before unmasking virtual
>>>>>>> PMI. However, approach 2 looks cleaner and more reasonable.
>>>>>>>
>>>>>>> Can you have a try and let me know the result? If both can not
>>>>>>> work, there might be some problems that I have not met before.
>>>>>>>
>>>>>>> BTW: Sorry, I did not see your patch to enable NHM vpmu before.
>>>>>>> So, there is no need for me to work on that now. :)
>>>>>>>
>>>>>>> Haitao
>>>>>>>
>>>>>>>
>>>>>>> Dietmar Hahn wrote:
>>>>>>>> Hi Haitao,
>>>>>>>>
>>>>>>>>> Can I know how you enabled vPMU on Nehalem? This is not
>>>>>>>>> supported in current Xen.
>>>>>>>>
>>>>>>>> http://lists.xensource.com/archives/html/xen-devel/2009-09/msg00829.html
>>>>>>>>
>>>>>>>>>
>>>>>>>>> Concerning vpmu support, I totally agree that we can disable
>>>>>>>>> this feature by default. If anyone really wants to use it, he
>>>>>>>>> can use boot options to turn it on.
>>>>>>>>
>>>>>>>> Yes, that's OK for me.
>>>>>>>>
>>>>>>>>> I am preparing a patch for that. And I will
>>>>>>>>> send a patch to enable NHM vpmu together.
>>>>>>>>>
>>>>>>>>> For the problem that Dietmar met, I think I once met this
>>>>>>>>> before. Can you add some code in vpmu_do_interrupt that sets
>>>>>>>>> the counter you are using to a value other than zero? Please
>>>>>>>>> let me know if that can help.
>>>>>>>>
>>>>>>>> I don't set the counter to zero. I use 0-val to set the
>>>>>>>> counter. Actually I testet on Nehalem with
>>>>>>>> - General Perf-counter #2 (0xc3) with CPU_CLK_UNHALTED and
>>>>>>>> val=1100000
>>>>>>>> - Fixed counter #1 (0x30a) and val=1100000
>>>>>>>> The thing is that in normal case the overflows of both counters
>>>>>>>> appear nearly at the same time. As described I added some extra
>>>>>>>> tracer for xentrace in core2_vpmu_do_interrupt() so the code
>>>>>>>> looks like:
>>>>>>>>
>>>>>>>> rdmsrl(MSR_CORE_PERF_GLOBAL_STATUS, msr_content); -> 1.
>>>>>>>> Step { uint32_t HAHN_l, HAHN_h;
>>>>>>>> HAHN_l = (uint32_t) msr_content;
>>>>>>>> HAHN_h = (uint32_t) (msr_content >> 32);
>>>>>>>> HVMTRACE_3D(HAHN_TR2, v, 1, HAHN_h, HAHN_l); -> 2. Step
>>>>>>>> } if ( !msr_content ) return 0;
>>>>>>>> core2_vpmu_cxt->global_ovf_status |= msr_content;
>>>>>>>> msr_content = 0xC000000700000000 | ((1 <<
>>>>>>>> core2_get_pmc_count()) - 1);
>>>>>>>> wrmsrl(MSR_CORE_PERF_GLOBAL_OVF_CTRL, msr_content); -> 3.
>>>>>>>> Step
>>>>>>>>
>>>>>>>> rdmsrl(MSR_CORE_PERF_GLOBAL_STATUS, msr_content); -> 4.
>>>>>>>> Step { uint32_t HAHN_l, HAHN_h;
>>>>>>>> HAHN_l = (uint32_t) msr_content;
>>>>>>>> HAHN_h = (uint32_t) (msr_content >> 32);
>>>>>>>> HVMTRACE_3D(HAHN_TR2, v, 0xa, HAHN_h, HAHN_l); ->
>>>>>>>> 5. Step
>>>>>>>>
>>>>>>>> rdmsrl(0xc3, msr_content); -> 6.
>>>>>>>> Step General counter #2 HAHN_l = (uint32_t)
>>>>>>>> msr_content; HAHN_h = (uint32_t) (msr_content >> 32);
>>>>>>>> HVMTRACE_3D(HAHN_TR2, v, 0xc3, HAHN_h, HAHN_l);
>>>>>>>> rdmsrl(0x30a, msr_content); -> 7.
>>>>>>>> Step Fixed counter #1 HAHN_l = (uint32_t) msr_content;
>>>>>>>> HAHN_h = (uint32_t) (msr_content >> 32);
>>>>>>>> HVMTRACE_3D(HAHN_TR2, v, 0x30a, HAHN_h, HAHN_l); }
>>>>>>>>
>>>>>>>> With these tracers I got the following output:
>>>>>>>>
>>>>>>>> Last good NMI:
>>>>>>>> Both counter cause the NMI. Resetting works OK.
>>>>>>>> The counter itself were running further.
>>>>>>>> 2. Step: par1 = 0x01, high = 0x0002, low = 0x0004 ]
>>>>>>>> rdmsrl(MSR_CORE_PERF_GLOBAL_STATUS)
>>>>>>>> 5. Step: par1 = 0x0a, high = 0x0000, low = 0x0000 ]
>>>>>>>> rdmsrl(MSR_CORE_PERF_GLOBAL_STATUS)
>>>>>>>> 6. Step: par1 = 0xc3, high = 0x0000, low = 0x03c4 ]
>>>>>>>> rdmsrl(0xc3) -> #2 general counter
>>>>>>>> 7. Step: par1 = 0x30a, high = 0x0000, low = 0x02da ]
>>>>>>>> rdmsrl(0x30a) -> #1 fixed counter
>>>>>>>>
>>>>>>>> NMI from where things goes wrong:
>>>>>>>> Both counter cause the NMI. Resetting works NOT correct, only
>>>>>>>> for the general counter! The general counter (caused the NMI)
>>>>>>>> seems to be stopped!
>>>>>>>> 2. Step: par1 = 0x01, high = 0x0002, low = 0x0004 ]
>>>>>>>> rdmsrl(MSR_CORE_PERF_GLOBAL_STATUS)
>>>>>>>> 5. Step: par1 = 0x0a, high = 0x0002, low = 0x0000 ]
>>>>>>>> rdmsrl(MSR_CORE_PERF_GLOBAL_STATUS)
>>>>>>>> 6. Step: par1 = 0xc3, high = 0x0000, low = 0x00ec ]
>>>>>>>> rdmsrl(0xc3) -> #2 general counter
>>>>>>>> 7. Step: par1 = 0x30a, high = 0x0000, low = 0x0000 ]
>>>>>>>> rdmsrl(0x30a) -> #1 fixed counter
>>>>>>>>
>>>>>>>> Wrong NMI:
>>>>>>>> Only the fixed counter causes the NMI (which was not resetted
>>>>>>>> during NMI handling above!) Both counter seems to be stopped!
>>>>>>>> 2. Step: par1 = 0x01, high = 0x0002, low = 0x0000 ]
>>>>>>>> rdmsrl(MSR_CORE_PERF_GLOBAL_STATUS)
>>>>>>>> 5. Step: par1 = 0x0a, high = 0x0002, low = 0x0000 ]
>>>>>>>> rdmsrl(MSR_CORE_PERF_GLOBAL_STATUS)
>>>>>>>> 6. Step: par1 = 0xc3, high = 0x0000, low = 0x00ec ]
>>>>>>>> rdmsrl(0xc3) -> #2 general counter
>>>>>>>> 7. Step: par1 = 0x30a, high = 0x0000, low = 0x0000 ]
>>>>>>>> rdmsrl(0x30a) -> #1 fixed counter
>>>>>>>>
>>>>>>>> And this state remains forever!
>>>>>>>> I hope my explanations are understandable ;-)
>>>>>>>>
>>>>>>>> Until now I can see this behavior only on a Nehalem processor.
>>>>>>>>
>>>>>>>> Thanks.
>>>>>>>> Dietmar
>>>>>>>>
>>>>>>>>>
>>>>>>>>> Best Regards
>>>>>>>>> Shan Haitao
>>>>>>>>>
>>>>>>>>> 2009/10/30 Keir Fraser <keir.fraser@eu.citrix.com>:
>>>>>>>>>> On 30/10/2009 12:20, "Dietmar Hahn"
>>>>>>>>>> <dietmar.hahn@ts.fujitsu.com> wrote:
>>>>>>>>>>
>>>>>>>>>>> I searched the intel processor spec but couldn't find any
>>>>>>>>>>> help. So my questions is, what is wrong here?
>>>>>>>>>>> Can anybody with more knowledge point me in the right
>>>>>>>>>>> direction, what can I still do to find the real cause of
>>>>>>>>>>> this?
>>>>>>>>>>
>>>>>>>>>> You should probably Cc one of the Intel guys who implemented
>>>>>>>>>> this stuff -- I've added Haitao Shan.
>>>>>>>>>>
>>>>>>>>>> Meanwhile I'd be interested to know whether things work okay
>>>>>>>>>> for you, minus performance counters and the hypervisor hang,
>>>>>>>>>> if you return immediately from vpmu_initialise(). Really at
>>>>>>>>>> minimum we need such a fix, perhaps with a boot paremeter to
>>>>>>>>>> re-enable the feature, for 3.4.2 release; allowing guests to
>>>>>>>>>> hose the hypervisor like this is of course not on.
>>>>>>>>>>
>>>>>>>>>> -- Keir
>>>> _______________________________________________
>>>> Xen-devel mailing list
>>>> Xen-devel@lists.xensource.com
>>>> http://lists.xensource.com/xen-devel
>> _______________________________________________
>> Xen-devel mailing list
>> Xen-devel@lists.xensource.com
>> http://lists.xensource.com/xen-devel
^ permalink raw reply [flat|nested] 21+ messages in thread
* RE: Need help in debugging partially blocked hypervisor
2009-11-03 8:24 ` Dietmar Hahn
2009-11-03 8:43 ` Shan, Haitao
@ 2009-11-03 9:00 ` Shan, Haitao
1 sibling, 0 replies; 21+ messages in thread
From: Shan, Haitao @ 2009-11-03 9:00 UTC (permalink / raw)
To: Dietmar Hahn, xen-devel; +Cc: Keir Fraser
[-- Attachment #1: Type: text/plain, Size: 10835 bytes --]
Hi, Dietmar,
Please review the attached patch. Any comments?
Haitao
Dietmar Hahn wrote:
>> I suspect the guest will reproduce this PMI loop if guest behaves as
>> you said in this email. But as far as I know, VTune and oprofile do
>> not behave like that.
>> Of course, this approach is still like workaround (unless I get
>> comfirm that HW requires to do so). This approach is preferrable
>> because it does not change the contents of MSRs. Thus, we have no
>> impact on guest software that does rely on reading the correct value
>> from HW. Approach 1 existed just because we knew that in event-based
>> sampling, counter value on receiving PMI was not used by
>> OProfile/VTune at all and it was safe to set the counter to some
>> non-zero value.
>>
>> Haitao
>>
>
> OK, then will you send a patch?
> Dietmar.
>
>>
>> Dietmar Hahn wrote:
>>> Please see below.
>>>
>>>> See my comments embedded. :)
>>>>
>>>> Haitao
>>>>
>>>>
>>>> Dietmar Hahn wrote:
>>>>> The conclusion is, that this seems to be a workaround for the
>>>>> endless NMI loop. PMI's are a very rarely event and this should
>>>>> not raise a performance problem.
>>>> I totally agree that this is only a workaround for approach 1.
>>>>
>>>>>
>>>>> I didn't try your second approach
>>>>>> 2> Remove unmasking PMI from vpmu_do_interrupt and unmask
>>>>>> *physical PMI* when guest vcpu unmasks virtual PMI. but I have
>>>>>> some question.
>>>>>
>>>>> - What if the 'physical PMI' is not unmasked in vpmu_do_interrupt
>>>>> and a watchdog NMI would occur before the domU unmasks it?
>>>> I think the second NMI will be lost.
>>>>
>>>>> - Is it possible that after handling the NMI (and not unmasking)
>>>>> another domU got running on this CPU and therefore PMI's got
>>>>> lost?
>>>> LVTPC entry in physical local APIC is save/restored by Xen on VCPU
>>>> switches. So unmasking (or not) of PMI of one vcpu should have no
>>>> impact on another vcpu. When developing vPMU, I treated as vPMU
>>>> context both PMU MSRs and LVTPC entry in local APIC. vPMU context
>>>> is save/restored on physical HW when vcpus is scheduled, either in
>>>> an active save/restore manner or a lazy one (depending on the PMU
>>>> usage at the time of switch).
>>>>
>>>>>
>>>>> But the real cause of the problem is unknown. As said I saw this
>>>>> only on Nehalem. Maybe there is a problem together with the
>>>>> hardware? Perhaps your hardware colleagues know something more ;-)
>>>> When I found this problem, I just thought it might be a corner case
>>>> that only happens on my box (of course, I only see this in NHM,
>>>> too). I will try to pin HW guy to see if any explanation, since it
>>>> is proven to be a general problem on NHM.
>>>>
>>>> But before everything is clear, I think approach 2 is a better
>>>> solution now.
>>>
>>> What would be the effect if the guest unmasks the PMI (which leads
>>> to unmasking the 'physical PMI') but doesn't reset the counter to a
>>> value != 0? Is the guest able to produce the nmi endless loop?
>>>
>>> Dietmar.
>>>
>>>>
>>>>>
>>>>> Thanks
>>>>> Dietmar
>>>>>
>>>>>>
>>>>>>>
>>>>>>> When I met this problem, I remember that I tried two approaches:
>>>>>>> 1> Setting the counter to non-zero before unmasking PMI in
>>>>>>> vpmu_do_interrupt; 2> Remove unmasking PMI from
>>>>>>> vpmu_do_interrupt and unmask *physical PMI* when guest vcpu
>>>>>>> unmasks virtual PMI.
>>>>>>> I remember that approach 2 can fix this issue. But I do not
>>>>>>> remember the result of approach 1, since I met this about one
>>>>>>> year ago. It is my understanding that approach 2 is quite same
>>>>>>> as approach 1, since normally guest will set the counter to some
>>>>>>> negative value (for example, -100000) before unmasking virtual
>>>>>>> PMI. However, approach 2 looks cleaner and more reasonable.
>>>>>>>
>>>>>>> Can you have a try and let me know the result? If both can not
>>>>>>> work, there might be some problems that I have not met before.
>>>>>>>
>>>>>>> BTW: Sorry, I did not see your patch to enable NHM vpmu before.
>>>>>>> So, there is no need for me to work on that now. :)
>>>>>>>
>>>>>>> Haitao
>>>>>>>
>>>>>>>
>>>>>>> Dietmar Hahn wrote:
>>>>>>>> Hi Haitao,
>>>>>>>>
>>>>>>>>> Can I know how you enabled vPMU on Nehalem? This is not
>>>>>>>>> supported in current Xen.
>>>>>>>>
>>>>>>>> http://lists.xensource.com/archives/html/xen-devel/2009-09/msg00829.html
>>>>>>>>
>>>>>>>>>
>>>>>>>>> Concerning vpmu support, I totally agree that we can disable
>>>>>>>>> this feature by default. If anyone really wants to use it, he
>>>>>>>>> can use boot options to turn it on.
>>>>>>>>
>>>>>>>> Yes, that's OK for me.
>>>>>>>>
>>>>>>>>> I am preparing a patch for that. And I will
>>>>>>>>> send a patch to enable NHM vpmu together.
>>>>>>>>>
>>>>>>>>> For the problem that Dietmar met, I think I once met this
>>>>>>>>> before. Can you add some code in vpmu_do_interrupt that sets
>>>>>>>>> the counter you are using to a value other than zero? Please
>>>>>>>>> let me know if that can help.
>>>>>>>>
>>>>>>>> I don't set the counter to zero. I use 0-val to set the
>>>>>>>> counter. Actually I testet on Nehalem with
>>>>>>>> - General Perf-counter #2 (0xc3) with CPU_CLK_UNHALTED and
>>>>>>>> val=1100000
>>>>>>>> - Fixed counter #1 (0x30a) and val=1100000
>>>>>>>> The thing is that in normal case the overflows of both counters
>>>>>>>> appear nearly at the same time. As described I added some extra
>>>>>>>> tracer for xentrace in core2_vpmu_do_interrupt() so the code
>>>>>>>> looks like:
>>>>>>>>
>>>>>>>> rdmsrl(MSR_CORE_PERF_GLOBAL_STATUS, msr_content); -> 1.
>>>>>>>> Step { uint32_t HAHN_l, HAHN_h;
>>>>>>>> HAHN_l = (uint32_t) msr_content;
>>>>>>>> HAHN_h = (uint32_t) (msr_content >> 32);
>>>>>>>> HVMTRACE_3D(HAHN_TR2, v, 1, HAHN_h, HAHN_l); -> 2. Step
>>>>>>>> } if ( !msr_content ) return 0;
>>>>>>>> core2_vpmu_cxt->global_ovf_status |= msr_content;
>>>>>>>> msr_content = 0xC000000700000000 | ((1 <<
>>>>>>>> core2_get_pmc_count()) - 1);
>>>>>>>> wrmsrl(MSR_CORE_PERF_GLOBAL_OVF_CTRL, msr_content); -> 3.
>>>>>>>> Step
>>>>>>>>
>>>>>>>> rdmsrl(MSR_CORE_PERF_GLOBAL_STATUS, msr_content); -> 4.
>>>>>>>> Step { uint32_t HAHN_l, HAHN_h;
>>>>>>>> HAHN_l = (uint32_t) msr_content;
>>>>>>>> HAHN_h = (uint32_t) (msr_content >> 32);
>>>>>>>> HVMTRACE_3D(HAHN_TR2, v, 0xa, HAHN_h, HAHN_l); ->
>>>>>>>> 5. Step
>>>>>>>>
>>>>>>>> rdmsrl(0xc3, msr_content); -> 6.
>>>>>>>> Step General counter #2 HAHN_l = (uint32_t)
>>>>>>>> msr_content; HAHN_h = (uint32_t) (msr_content >> 32);
>>>>>>>> HVMTRACE_3D(HAHN_TR2, v, 0xc3, HAHN_h, HAHN_l);
>>>>>>>> rdmsrl(0x30a, msr_content); -> 7.
>>>>>>>> Step Fixed counter #1 HAHN_l = (uint32_t) msr_content;
>>>>>>>> HAHN_h = (uint32_t) (msr_content >> 32);
>>>>>>>> HVMTRACE_3D(HAHN_TR2, v, 0x30a, HAHN_h, HAHN_l); }
>>>>>>>>
>>>>>>>> With these tracers I got the following output:
>>>>>>>>
>>>>>>>> Last good NMI:
>>>>>>>> Both counter cause the NMI. Resetting works OK.
>>>>>>>> The counter itself were running further.
>>>>>>>> 2. Step: par1 = 0x01, high = 0x0002, low = 0x0004 ]
>>>>>>>> rdmsrl(MSR_CORE_PERF_GLOBAL_STATUS)
>>>>>>>> 5. Step: par1 = 0x0a, high = 0x0000, low = 0x0000 ]
>>>>>>>> rdmsrl(MSR_CORE_PERF_GLOBAL_STATUS)
>>>>>>>> 6. Step: par1 = 0xc3, high = 0x0000, low = 0x03c4 ]
>>>>>>>> rdmsrl(0xc3) -> #2 general counter
>>>>>>>> 7. Step: par1 = 0x30a, high = 0x0000, low = 0x02da ]
>>>>>>>> rdmsrl(0x30a) -> #1 fixed counter
>>>>>>>>
>>>>>>>> NMI from where things goes wrong:
>>>>>>>> Both counter cause the NMI. Resetting works NOT correct, only
>>>>>>>> for the general counter! The general counter (caused the NMI)
>>>>>>>> seems to be stopped!
>>>>>>>> 2. Step: par1 = 0x01, high = 0x0002, low = 0x0004 ]
>>>>>>>> rdmsrl(MSR_CORE_PERF_GLOBAL_STATUS)
>>>>>>>> 5. Step: par1 = 0x0a, high = 0x0002, low = 0x0000 ]
>>>>>>>> rdmsrl(MSR_CORE_PERF_GLOBAL_STATUS)
>>>>>>>> 6. Step: par1 = 0xc3, high = 0x0000, low = 0x00ec ]
>>>>>>>> rdmsrl(0xc3) -> #2 general counter
>>>>>>>> 7. Step: par1 = 0x30a, high = 0x0000, low = 0x0000 ]
>>>>>>>> rdmsrl(0x30a) -> #1 fixed counter
>>>>>>>>
>>>>>>>> Wrong NMI:
>>>>>>>> Only the fixed counter causes the NMI (which was not resetted
>>>>>>>> during NMI handling above!) Both counter seems to be stopped!
>>>>>>>> 2. Step: par1 = 0x01, high = 0x0002, low = 0x0000 ]
>>>>>>>> rdmsrl(MSR_CORE_PERF_GLOBAL_STATUS)
>>>>>>>> 5. Step: par1 = 0x0a, high = 0x0002, low = 0x0000 ]
>>>>>>>> rdmsrl(MSR_CORE_PERF_GLOBAL_STATUS)
>>>>>>>> 6. Step: par1 = 0xc3, high = 0x0000, low = 0x00ec ]
>>>>>>>> rdmsrl(0xc3) -> #2 general counter
>>>>>>>> 7. Step: par1 = 0x30a, high = 0x0000, low = 0x0000 ]
>>>>>>>> rdmsrl(0x30a) -> #1 fixed counter
>>>>>>>>
>>>>>>>> And this state remains forever!
>>>>>>>> I hope my explanations are understandable ;-)
>>>>>>>>
>>>>>>>> Until now I can see this behavior only on a Nehalem processor.
>>>>>>>>
>>>>>>>> Thanks.
>>>>>>>> Dietmar
>>>>>>>>
>>>>>>>>>
>>>>>>>>> Best Regards
>>>>>>>>> Shan Haitao
>>>>>>>>>
>>>>>>>>> 2009/10/30 Keir Fraser <keir.fraser@eu.citrix.com>:
>>>>>>>>>> On 30/10/2009 12:20, "Dietmar Hahn"
>>>>>>>>>> <dietmar.hahn@ts.fujitsu.com> wrote:
>>>>>>>>>>
>>>>>>>>>>> I searched the intel processor spec but couldn't find any
>>>>>>>>>>> help. So my questions is, what is wrong here?
>>>>>>>>>>> Can anybody with more knowledge point me in the right
>>>>>>>>>>> direction, what can I still do to find the real cause of
>>>>>>>>>>> this?
>>>>>>>>>>
>>>>>>>>>> You should probably Cc one of the Intel guys who implemented
>>>>>>>>>> this stuff -- I've added Haitao Shan.
>>>>>>>>>>
>>>>>>>>>> Meanwhile I'd be interested to know whether things work okay
>>>>>>>>>> for you, minus performance counters and the hypervisor hang,
>>>>>>>>>> if you return immediately from vpmu_initialise(). Really at
>>>>>>>>>> minimum we need such a fix, perhaps with a boot paremeter to
>>>>>>>>>> re-enable the feature, for 3.4.2 release; allowing guests to
>>>>>>>>>> hose the hypervisor like this is of course not on.
>>>>>>>>>>
>>>>>>>>>> -- Keir
>>>> _______________________________________________
>>>> Xen-devel mailing list
>>>> Xen-devel@lists.xensource.com
>>>> http://lists.xensource.com/xen-devel
>> _______________________________________________
>> Xen-devel mailing list
>> Xen-devel@lists.xensource.com
>> http://lists.xensource.com/xen-devel
[-- Attachment #2: unmask_vPMI.patch --]
[-- Type: application/octet-stream, Size: 1201 bytes --]
diff -r 19f0e0867a18 xen/arch/x86/hvm/vlapic.c
--- a/xen/arch/x86/hvm/vlapic.c Mon Nov 02 09:38:34 2009 +0000
+++ b/xen/arch/x86/hvm/vlapic.c Tue Nov 03 02:22:14 2009 +0800
@@ -656,6 +656,10 @@ static int vlapic_write(struct vcpu *v,
val |= APIC_LVT_MASKED;
val &= vlapic_lvt_mask[(offset - APIC_LVTT) >> 4];
vlapic_set_reg(vlapic, offset, val);
+ if ( offset == APIC_LVTPC )
+ apic_write_around(APIC_LVTPC,
+ (apic_read(APIC_LVTPC) & ~APIC_LVT_MASKED)
+ | (val & APIC_LVT_MASKED));
if ( offset == APIC_LVT0 )
{
vlapic_adjust_i8259_target(v->domain);
diff -r 19f0e0867a18 xen/arch/x86/hvm/vmx/vpmu_core2.c
--- a/xen/arch/x86/hvm/vmx/vpmu_core2.c Mon Nov 02 09:38:34 2009 +0000
+++ b/xen/arch/x86/hvm/vmx/vpmu_core2.c Tue Nov 03 02:15:50 2009 +0800
@@ -501,8 +501,6 @@ static int core2_vpmu_do_interrupt(struc
msr_content = 0xC000000700000000 | ((1 << core2_get_pmc_count()) - 1);
wrmsrl(MSR_CORE_PERF_GLOBAL_OVF_CTRL, msr_content);
- apic_write_around(APIC_LVTPC, apic_read(APIC_LVTPC) & ~APIC_LVT_MASKED);
-
if ( !is_vlapic_lvtpc_enabled(vlapic) )
return 1;
[-- Attachment #3: Type: text/plain, Size: 138 bytes --]
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel
^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: Need help in debugging partially blocked hypervisor
2009-11-03 8:43 ` Shan, Haitao
@ 2009-11-03 9:03 ` Dietmar Hahn
0 siblings, 0 replies; 21+ messages in thread
From: Dietmar Hahn @ 2009-11-03 9:03 UTC (permalink / raw)
To: xen-devel; +Cc: Shan, Haitao, Keir Fraser
> No problem.
> Can you help to test? I have no test box at hand now, which might cause delay.
>
Sure :-)
Dietmar.
> Haitao
>
>
> Dietmar Hahn wrote:
> >> I suspect the guest will reproduce this PMI loop if guest behaves as
> >> you said in this email. But as far as I know, VTune and oprofile do
> >> not behave like that.
> >> Of course, this approach is still like workaround (unless I get
> >> comfirm that HW requires to do so). This approach is preferrable
> >> because it does not change the contents of MSRs. Thus, we have no
> >> impact on guest software that does rely on reading the correct value
> >> from HW. Approach 1 existed just because we knew that in event-based
> >> sampling, counter value on receiving PMI was not used by
> >> OProfile/VTune at all and it was safe to set the counter to some
> >> non-zero value.
> >>
> >> Haitao
> >>
> >
> > OK, then will you send a patch?
> > Dietmar.
> >
> >>
> >> Dietmar Hahn wrote:
> >>> Please see below.
> >>>
> >>>> See my comments embedded. :)
> >>>>
> >>>> Haitao
> >>>>
> >>>>
> >>>> Dietmar Hahn wrote:
> >>>>> The conclusion is, that this seems to be a workaround for the
> >>>>> endless NMI loop. PMI's are a very rarely event and this should
> >>>>> not raise a performance problem.
> >>>> I totally agree that this is only a workaround for approach 1.
> >>>>
> >>>>>
> >>>>> I didn't try your second approach
> >>>>>> 2> Remove unmasking PMI from vpmu_do_interrupt and unmask
> >>>>>> *physical PMI* when guest vcpu unmasks virtual PMI. but I have
> >>>>>> some question.
> >>>>>
> >>>>> - What if the 'physical PMI' is not unmasked in vpmu_do_interrupt
> >>>>> and a watchdog NMI would occur before the domU unmasks it?
> >>>> I think the second NMI will be lost.
> >>>>
> >>>>> - Is it possible that after handling the NMI (and not unmasking)
> >>>>> another domU got running on this CPU and therefore PMI's got
> >>>>> lost?
> >>>> LVTPC entry in physical local APIC is save/restored by Xen on VCPU
> >>>> switches. So unmasking (or not) of PMI of one vcpu should have no
> >>>> impact on another vcpu. When developing vPMU, I treated as vPMU
> >>>> context both PMU MSRs and LVTPC entry in local APIC. vPMU context
> >>>> is save/restored on physical HW when vcpus is scheduled, either in
> >>>> an active save/restore manner or a lazy one (depending on the PMU
> >>>> usage at the time of switch).
> >>>>
> >>>>>
> >>>>> But the real cause of the problem is unknown. As said I saw this
> >>>>> only on Nehalem. Maybe there is a problem together with the
> >>>>> hardware? Perhaps your hardware colleagues know something more ;-)
> >>>> When I found this problem, I just thought it might be a corner case
> >>>> that only happens on my box (of course, I only see this in NHM,
> >>>> too). I will try to pin HW guy to see if any explanation, since it
> >>>> is proven to be a general problem on NHM.
> >>>>
> >>>> But before everything is clear, I think approach 2 is a better
> >>>> solution now.
> >>>
> >>> What would be the effect if the guest unmasks the PMI (which leads
> >>> to unmasking the 'physical PMI') but doesn't reset the counter to a
> >>> value != 0? Is the guest able to produce the nmi endless loop?
> >>>
> >>> Dietmar.
> >>>
> >>>>
> >>>>>
> >>>>> Thanks
> >>>>> Dietmar
> >>>>>
> >>>>>>
> >>>>>>>
> >>>>>>> When I met this problem, I remember that I tried two approaches:
> >>>>>>> 1> Setting the counter to non-zero before unmasking PMI in
> >>>>>>> vpmu_do_interrupt; 2> Remove unmasking PMI from
> >>>>>>> vpmu_do_interrupt and unmask *physical PMI* when guest vcpu
> >>>>>>> unmasks virtual PMI.
> >>>>>>> I remember that approach 2 can fix this issue. But I do not
> >>>>>>> remember the result of approach 1, since I met this about one
> >>>>>>> year ago. It is my understanding that approach 2 is quite same
> >>>>>>> as approach 1, since normally guest will set the counter to some
> >>>>>>> negative value (for example, -100000) before unmasking virtual
> >>>>>>> PMI. However, approach 2 looks cleaner and more reasonable.
> >>>>>>>
> >>>>>>> Can you have a try and let me know the result? If both can not
> >>>>>>> work, there might be some problems that I have not met before.
> >>>>>>>
> >>>>>>> BTW: Sorry, I did not see your patch to enable NHM vpmu before.
> >>>>>>> So, there is no need for me to work on that now. :)
> >>>>>>>
> >>>>>>> Haitao
> >>>>>>>
> >>>>>>>
> >>>>>>> Dietmar Hahn wrote:
> >>>>>>>> Hi Haitao,
> >>>>>>>>
> >>>>>>>>> Can I know how you enabled vPMU on Nehalem? This is not
> >>>>>>>>> supported in current Xen.
> >>>>>>>>
> >>>>>>>> http://lists.xensource.com/archives/html/xen-devel/2009-09/msg00829.html
> >>>>>>>>
> >>>>>>>>>
> >>>>>>>>> Concerning vpmu support, I totally agree that we can disable
> >>>>>>>>> this feature by default. If anyone really wants to use it, he
> >>>>>>>>> can use boot options to turn it on.
> >>>>>>>>
> >>>>>>>> Yes, that's OK for me.
> >>>>>>>>
> >>>>>>>>> I am preparing a patch for that. And I will
> >>>>>>>>> send a patch to enable NHM vpmu together.
> >>>>>>>>>
> >>>>>>>>> For the problem that Dietmar met, I think I once met this
> >>>>>>>>> before. Can you add some code in vpmu_do_interrupt that sets
> >>>>>>>>> the counter you are using to a value other than zero? Please
> >>>>>>>>> let me know if that can help.
> >>>>>>>>
> >>>>>>>> I don't set the counter to zero. I use 0-val to set the
> >>>>>>>> counter. Actually I testet on Nehalem with
> >>>>>>>> - General Perf-counter #2 (0xc3) with CPU_CLK_UNHALTED and
> >>>>>>>> val=1100000
> >>>>>>>> - Fixed counter #1 (0x30a) and val=1100000
> >>>>>>>> The thing is that in normal case the overflows of both counters
> >>>>>>>> appear nearly at the same time. As described I added some extra
> >>>>>>>> tracer for xentrace in core2_vpmu_do_interrupt() so the code
> >>>>>>>> looks like:
> >>>>>>>>
> >>>>>>>> rdmsrl(MSR_CORE_PERF_GLOBAL_STATUS, msr_content); -> 1.
> >>>>>>>> Step { uint32_t HAHN_l, HAHN_h;
> >>>>>>>> HAHN_l = (uint32_t) msr_content;
> >>>>>>>> HAHN_h = (uint32_t) (msr_content >> 32);
> >>>>>>>> HVMTRACE_3D(HAHN_TR2, v, 1, HAHN_h, HAHN_l); -> 2. Step
> >>>>>>>> } if ( !msr_content ) return 0;
> >>>>>>>> core2_vpmu_cxt->global_ovf_status |= msr_content;
> >>>>>>>> msr_content = 0xC000000700000000 | ((1 <<
> >>>>>>>> core2_get_pmc_count()) - 1);
> >>>>>>>> wrmsrl(MSR_CORE_PERF_GLOBAL_OVF_CTRL, msr_content); -> 3.
> >>>>>>>> Step
> >>>>>>>>
> >>>>>>>> rdmsrl(MSR_CORE_PERF_GLOBAL_STATUS, msr_content); -> 4.
> >>>>>>>> Step { uint32_t HAHN_l, HAHN_h;
> >>>>>>>> HAHN_l = (uint32_t) msr_content;
> >>>>>>>> HAHN_h = (uint32_t) (msr_content >> 32);
> >>>>>>>> HVMTRACE_3D(HAHN_TR2, v, 0xa, HAHN_h, HAHN_l); ->
> >>>>>>>> 5. Step
> >>>>>>>>
> >>>>>>>> rdmsrl(0xc3, msr_content); -> 6.
> >>>>>>>> Step General counter #2 HAHN_l = (uint32_t)
> >>>>>>>> msr_content; HAHN_h = (uint32_t) (msr_content >> 32);
> >>>>>>>> HVMTRACE_3D(HAHN_TR2, v, 0xc3, HAHN_h, HAHN_l);
> >>>>>>>> rdmsrl(0x30a, msr_content); -> 7.
> >>>>>>>> Step Fixed counter #1 HAHN_l = (uint32_t) msr_content;
> >>>>>>>> HAHN_h = (uint32_t) (msr_content >> 32);
> >>>>>>>> HVMTRACE_3D(HAHN_TR2, v, 0x30a, HAHN_h, HAHN_l); }
> >>>>>>>>
> >>>>>>>> With these tracers I got the following output:
> >>>>>>>>
> >>>>>>>> Last good NMI:
> >>>>>>>> Both counter cause the NMI. Resetting works OK.
> >>>>>>>> The counter itself were running further.
> >>>>>>>> 2. Step: par1 = 0x01, high = 0x0002, low = 0x0004 ]
> >>>>>>>> rdmsrl(MSR_CORE_PERF_GLOBAL_STATUS)
> >>>>>>>> 5. Step: par1 = 0x0a, high = 0x0000, low = 0x0000 ]
> >>>>>>>> rdmsrl(MSR_CORE_PERF_GLOBAL_STATUS)
> >>>>>>>> 6. Step: par1 = 0xc3, high = 0x0000, low = 0x03c4 ]
> >>>>>>>> rdmsrl(0xc3) -> #2 general counter
> >>>>>>>> 7. Step: par1 = 0x30a, high = 0x0000, low = 0x02da ]
> >>>>>>>> rdmsrl(0x30a) -> #1 fixed counter
> >>>>>>>>
> >>>>>>>> NMI from where things goes wrong:
> >>>>>>>> Both counter cause the NMI. Resetting works NOT correct, only
> >>>>>>>> for the general counter! The general counter (caused the NMI)
> >>>>>>>> seems to be stopped!
> >>>>>>>> 2. Step: par1 = 0x01, high = 0x0002, low = 0x0004 ]
> >>>>>>>> rdmsrl(MSR_CORE_PERF_GLOBAL_STATUS)
> >>>>>>>> 5. Step: par1 = 0x0a, high = 0x0002, low = 0x0000 ]
> >>>>>>>> rdmsrl(MSR_CORE_PERF_GLOBAL_STATUS)
> >>>>>>>> 6. Step: par1 = 0xc3, high = 0x0000, low = 0x00ec ]
> >>>>>>>> rdmsrl(0xc3) -> #2 general counter
> >>>>>>>> 7. Step: par1 = 0x30a, high = 0x0000, low = 0x0000 ]
> >>>>>>>> rdmsrl(0x30a) -> #1 fixed counter
> >>>>>>>>
> >>>>>>>> Wrong NMI:
> >>>>>>>> Only the fixed counter causes the NMI (which was not resetted
> >>>>>>>> during NMI handling above!) Both counter seems to be stopped!
> >>>>>>>> 2. Step: par1 = 0x01, high = 0x0002, low = 0x0000 ]
> >>>>>>>> rdmsrl(MSR_CORE_PERF_GLOBAL_STATUS)
> >>>>>>>> 5. Step: par1 = 0x0a, high = 0x0002, low = 0x0000 ]
> >>>>>>>> rdmsrl(MSR_CORE_PERF_GLOBAL_STATUS)
> >>>>>>>> 6. Step: par1 = 0xc3, high = 0x0000, low = 0x00ec ]
> >>>>>>>> rdmsrl(0xc3) -> #2 general counter
> >>>>>>>> 7. Step: par1 = 0x30a, high = 0x0000, low = 0x0000 ]
> >>>>>>>> rdmsrl(0x30a) -> #1 fixed counter
> >>>>>>>>
> >>>>>>>> And this state remains forever!
> >>>>>>>> I hope my explanations are understandable ;-)
> >>>>>>>>
> >>>>>>>> Until now I can see this behavior only on a Nehalem processor.
> >>>>>>>>
> >>>>>>>> Thanks.
> >>>>>>>> Dietmar
> >>>>>>>>
> >>>>>>>>>
> >>>>>>>>> Best Regards
> >>>>>>>>> Shan Haitao
> >>>>>>>>>
> >>>>>>>>> 2009/10/30 Keir Fraser <keir.fraser@eu.citrix.com>:
> >>>>>>>>>> On 30/10/2009 12:20, "Dietmar Hahn"
> >>>>>>>>>> <dietmar.hahn@ts.fujitsu.com> wrote:
> >>>>>>>>>>
> >>>>>>>>>>> I searched the intel processor spec but couldn't find any
> >>>>>>>>>>> help. So my questions is, what is wrong here?
> >>>>>>>>>>> Can anybody with more knowledge point me in the right
> >>>>>>>>>>> direction, what can I still do to find the real cause of
> >>>>>>>>>>> this?
> >>>>>>>>>>
> >>>>>>>>>> You should probably Cc one of the Intel guys who implemented
> >>>>>>>>>> this stuff -- I've added Haitao Shan.
> >>>>>>>>>>
> >>>>>>>>>> Meanwhile I'd be interested to know whether things work okay
> >>>>>>>>>> for you, minus performance counters and the hypervisor hang,
> >>>>>>>>>> if you return immediately from vpmu_initialise(). Really at
> >>>>>>>>>> minimum we need such a fix, perhaps with a boot paremeter to
> >>>>>>>>>> re-enable the feature, for 3.4.2 release; allowing guests to
> >>>>>>>>>> hose the hypervisor like this is of course not on.
> >>>>>>>>>>
> >>>>>>>>>> -- Keir
> >>>> _______________________________________________
> >>>> Xen-devel mailing list
> >>>> Xen-devel@lists.xensource.com
> >>>> http://lists.xensource.com/xen-devel
> >> _______________________________________________
> >> Xen-devel mailing list
> >> Xen-devel@lists.xensource.com
> >> http://lists.xensource.com/xen-devel
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/xen-devel
>
>
--
Company details: http://ts.fujitsu.com/imprint.html
^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: Need help in debugging partially blocked hypervisor
2009-10-22 6:39 ` Keir Fraser
@ 2009-10-22 7:21 ` Dietmar Hahn
0 siblings, 0 replies; 21+ messages in thread
From: Dietmar Hahn @ 2009-10-22 7:21 UTC (permalink / raw)
To: Keir Fraser; +Cc: xen-devel
> On 22/10/2009 07:23, "Dietmar Hahn" <dietmar.hahn@ts.fujitsu.com> wrote:
>
> > OK, I tried xen-3.4-testing.hg and the system booted fine ;-)
> > Then I did a fresh hg pull from xen-unstable and the boot stopped in
> > the linux kernel.
> > Attached are the loggings from the serial console for both hypervisors.
>
> Okay, so output just dies early during dom0 boot. I guess if you try the 'd'
> debug key that you get no output from that either (CTRL-a three times
> followed by d)?
Sorry, CTRL-a doesn't work.
>
> Does xen-unstable work on other machines with that dom0 kernel, do you know?
> It's not at this point clear whether the issue is related to the hardware or
> the particular dom0 kernel.
Yes it works on older machines, I can send you the log.
>
> If you haven't seen that dom0 kernel work with xen-unstable on any system,
> can I get that dom0 kernel from somewhere to give it a go? Perhaps your
> exact dom0 kernel binary to start with, to make things as close as possibel
> to your setup?
If needed I can put the kernel on an outgoing ftp server.
Dietmar.
--
Company details: http://ts.fujitsu.com/imprint.html
^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: Need help in debugging partially blocked hypervisor
2009-10-22 6:23 Dietmar Hahn
@ 2009-10-22 6:39 ` Keir Fraser
2009-10-22 7:21 ` Dietmar Hahn
0 siblings, 1 reply; 21+ messages in thread
From: Keir Fraser @ 2009-10-22 6:39 UTC (permalink / raw)
To: Dietmar Hahn, xen-devel
On 22/10/2009 07:23, "Dietmar Hahn" <dietmar.hahn@ts.fujitsu.com> wrote:
> OK, I tried xen-3.4-testing.hg and the system booted fine ;-)
> Then I did a fresh hg pull from xen-unstable and the boot stopped in
> the linux kernel.
> Attached are the loggings from the serial console for both hypervisors.
Okay, so output just dies early during dom0 boot. I guess if you try the 'd'
debug key that you get no output from that either (CTRL-a three times
followed by d)?
Does xen-unstable work on other machines with that dom0 kernel, do you know?
It's not at this point clear whether the issue is related to the hardware or
the particular dom0 kernel.
If you haven't seen that dom0 kernel work with xen-unstable on any system,
can I get that dom0 kernel from somewhere to give it a go? Perhaps your
exact dom0 kernel binary to start with, to make things as close as possibel
to your setup?
Thanks,
Keir
^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: Need help in debugging partially blocked hypervisor
@ 2009-10-22 6:23 Dietmar Hahn
2009-10-22 6:39 ` Keir Fraser
0 siblings, 1 reply; 21+ messages in thread
From: Dietmar Hahn @ 2009-10-22 6:23 UTC (permalink / raw)
To: xen-devel
[-- Attachment #1: Type: text/plain, Size: 1309 bytes --]
Am 21.10.2009 schrieb Keir Keir Fraser:
> On 21/10/2009 14:07, "Dietmar Hahn" <dietmar.hahn@ts.fujitsu.com> wrote:
>
> > I need some help in debugging a strange hypervisor behavior together
> > with using fully virtualized performance counters.
> >
> > For info I use SLES11, means xen-3.3.1 and linux-2.6.27.19-5... on a
> > Intel nehalem machine.
> > I tried the hypervisor from xen-unstable but the machine didn't boot.
>
> That in itself is frankly more of a concern to me. Probably recent
> irq-handling changes, or some other platform change, has broken boot on some
> machines. If we don't get reports and testing help with that, it'll end up
> broken in the next major stable release too, which we really don't want.
>
> Meanwhile, can you at least boot with 3.4? At least we still maintain that.
> And do a debug build (debug=y make ...) so that the backtraces from the 'd'
> debug key are more meaningful.
>
> -- Keir
OK, I tried xen-3.4-testing.hg and the system booted fine ;-)
Then I did a fresh hg pull from xen-unstable and the boot stopped in
the linux kernel.
Attached are the loggings from the serial console for both hypervisors.
The tests with the performance counters needs more time for some preparations.
Thanks.
Dietmar.
--
Company details: http://ts.fujitsu.com/imprint.html
[-- Attachment #2: xen-3.4.2-rc2-log.txt --]
[-- Type: text/plain, Size: 51668 bytes --]
\ \/ /___ _ __ |___ /| || | |___ \ _ __ ___|___ \ _ __ _ __ ___
\ // _ \ '_ \ |_ \| || |_ __) |__| '__/ __| __) |__| '_ \| '__/ _ \
/ \ __/ | | | ___) |__ _| / __/|__| | | (__ / __/|__| |_) | | | __/
/_/\_\___|_| |_| |____(_) |_|(_)_____| |_| \___|_____| | .__/|_| \___|
|_|
(XEN) Xen version 3.4.2-rc2-pre (hahn@mch.fsc.net) (gcc version 4.3.2 [gcc-4_3-branch revision 141291] (SUSE Linux) ) Wed Oct 21 15:40:45 CEST 2009
(XEN) Latest ChangeSet: Tue Oct 20 21:44:08 2009 +0100 19791:df79861db125
(XEN) Console output is synchronous.
(XEN) Command line: console=com1 com1=38400 msi=0 sync_console debug=yes guest_loglvl=all loglvl=all dom0_mem=3546M
(XEN) Video information:
(XEN) VGA is text mode 80x25, font 8x16
(XEN) VBE/DDC methods: V2; EDID transfer time: 1 seconds
(XEN) Disc information:
(XEN) Found 6 MBR signatures
(XEN) Found 6 EDD information structures
(XEN) Xen-e820 RAM map:
(XEN) 0000000000000000 - 000000000009cc00 (usable)
(XEN) 000000000009cc00 - 00000000000a0000 (reserved)
(XEN) 00000000000e4000 - 0000000000100000 (reserved)
(XEN) 0000000000100000 - 00000000bf7c0000 (usable)
(XEN) 00000000bf7c0000 - 00000000bf7cb000 (ACPI data)
(XEN) 00000000bf7cb000 - 00000000bf7cc000 (ACPI NVS)
(XEN) 00000000bf7cc000 - 00000000c0000000 (reserved)
(XEN) 00000000e0000000 - 00000000f0000000 (reserved)
(XEN) 00000000fec00000 - 00000000fed00000 (reserved)
(XEN) 00000000fee00000 - 00000000fee01000 (reserved)
(XEN) 00000000ffa80000 - 0000000100000000 (reserved)
(XEN) 0000000100000000 - 0000000340000000 (usable)
(XEN) System RAM: 12279MB (12574064kB)
(XEN) ACPI: RSDP 000F80F0, 0024 (r2 PTLTD )
(XEN) ACPI: XSDT BF7C53B0, 00D4 (r1 PTLTD XSDT 60000 LTP 0)
(XEN) ACPI: FACP BF7C9BE1, 00F4 (r3 FSC TYLERBRG 60000 PTL F4240)
(XEN) ACPI: DSDT BF7C5484, 46D9 (r1 FSC D2619 60000 MSFT 3000001)
(XEN) ACPI: FACS BF7CBFC0, 0040
(XEN) ACPI: TCPA BF7C9CD5, 0032 (r1 Phoeni x 60000 TL 0)
(XEN) ACPI: SLIT BF7C9D07, 0030 (r1 FSC 60000 5A)
(XEN) ACPI: EINJ BF7C9D37, 01B0 (r1 PTL WHEAPTL 60000 PTL 1)
(XEN) ACPI: HEST BF7C9EE7, 0268 (r1 PTL WHEAPTL 60000 PTL 1)
(XEN) ACPI: BERT BF7CA14F, 0030 (r1 PTL WHEAPTL 60000 PTL 1)
(XEN) ACPI: SSDT BF7CA17F, 00E1 (r1 wheaos wheaosc 60000 INTL 20050624)
(XEN) ACPI: ERST BF7CA260, 0270 (r1 PTL WHEAPTL 60000 PTL 1)
(XEN) ACPI: SSDT BF7CA4D0, 00D8 (r1 FSC CST_PR00 60000 CSF 1)
(XEN) ACPI: SSDT BF7CA5A8, 00D8 (r1 FSC CST_PR02 60000 CSF 1)
(XEN) ACPI: SSDT BF7CA680, 00D8 (r1 FSC CST_PR04 60000 CSF 1)
(XEN) ACPI: SSDT BF7CA758, 00D8 (r1 FSC CST_PR06 60000 CSF 1)
(XEN) ACPI: SSDT BF7CA830, 015B (r1 FSC PST_PR00 60000 CSF 1)
(XEN) ACPI: SSDT BF7CA98B, 015B (r1 FSC PST_PR02 60000 CSF 1)
(XEN) ACPI: SSDT BF7CAAE6, 015B (r1 FSC PST_PR04 60000 CSF 1)
(XEN) ACPI: SSDT BF7CAC41, 015B (r1 FSC PST_PR06 60000 CSF 1)
(XEN) ACPI: SPCR BF7CAD9C, 0050 (r1 PTLTD $UCRTBL$ 60000 PTL 1)
(XEN) ACPI: DMAR BF7CADEC, 00E8 (r1 Intel OEMDMAR 60000 LOHR 1)
(XEN) ACPI: MCFG BF7CAED4, 003C (r1 PTLTD MCFG 60000 LTP 0)
(XEN) ACPI: HPET BF7CAF10, 0038 (r1 PTLTD HPETTBL 60000 LTP 1)
(XEN) ACPI: APIC BF7CAF48, 0090 (r1 PTLTD APIC 60000 LTP 0)
(XEN) ACPI: BOOT BF7CAFD8, 0028 (r1 PTLTD $SBFTBL$ 60000 LTP 1)
(XEN) NUMA turned off
(XEN) Faking a node at 0000000000000000-0000000340000000
(XEN) Domain heap initialised
(XEN) found SMP MP-table at 000f8120
(XEN) DMI present.
(XEN) Using APIC driver default
(XEN) ACPI: PM-Timer IO Port: 0x1008
(XEN) ACPI: ACPI SLEEP INFO: pm1x_cnt[1004,0], pm1x_evt[1000,0]
(XEN) ACPI: wakeup_vec[bf7cbfcc], vec_size[20]
(XEN) ACPI: Local APIC address 0xfee00000
(XEN) ACPI: LAPIC (acpi_id[0x00] lapic_id[0x00] enabled)
(XEN) Processor #0 7:10 APIC version 21
(XEN) ACPI: LAPIC (acpi_id[0x01] lapic_id[0x02] enabled)
(XEN) Processor #2 7:10 APIC version 21
(XEN) ACPI: LAPIC (acpi_id[0x02] lapic_id[0x04] enabled)
(XEN) Processor #4 7:10 APIC version 21
(XEN) ACPI: LAPIC (acpi_id[0x03] lapic_id[0x06] enabled)
(XEN) Processor #6 7:10 APIC version 21
(XEN) ACPI: LAPIC_NMI (acpi_id[0x00] high edge lint[0x1])
(XEN) ACPI: LAPIC_NMI (acpi_id[0x01] high edge lint[0x1])
(XEN) ACPI: LAPIC_NMI (acpi_id[0x02] high edge lint[0x1])
(XEN) ACPI: LAPIC_NMI (acpi_id[0x03] high edge lint[0x1])
(XEN) ACPI: IOAPIC (id[0x01] address[0xfec00000] gsi_base[0])
(XEN) IOAPIC[0]: apic_id 1, version 32, address 0xfec00000, GSI 0-23
(XEN) ACPI: IOAPIC (id[0x03] address[0xfec80000] gsi_base[24])
(XEN) IOAPIC[1]: apic_id 3, version 32, address 0xfec80000, GSI 24-47
(XEN) ACPI: INT_SRC_OVR (bus 0 bus_irq 0 global_irq 2 high edge)
(XEN) ACPI: INT_SRC_OVR (bus 0 bus_irq 9 global_irq 9 high level)
(XEN) ACPI: IRQ0 used by override.
(XEN) ACPI: IRQ2 used by override.
(XEN) ACPI: IRQ9 used by override.
(XEN) Enabling APIC mode: Flat. Using 2 I/O APICs
(XEN) ACPI: HPET id: 0x8086a301 base: 0xfed00000
(XEN) Using ACPI (MADT) for SMP configuration information
(XEN) Using scheduler: SMP Credit Scheduler (credit)
(XEN) Initializing CPU#0
(XEN) Detected 2266.816 MHz processor.
(XEN) CPU: L1 I cache: 32K, L1 D cache: 32K
(XEN) CPU: L2 cache: 256K
(XEN) CPU: L3 cache: 8192K
(XEN) CPU: Physical Processor ID: 0
(XEN) CPU: Processor Core ID: 0
(XEN) VMX: Supported advanced features:
(XEN) - APIC MMIO access virtualisation
(XEN) - APIC TPR shadow
(XEN) - Extended Page Tables (EPT)
(XEN) - Virtual-Processor Identifiers (VPID)
(XEN) - Virtual NMI
(XEN) - MSR direct-access bitmap
(XEN) VMX: EPT is available.
(XEN) VMX: VPID is available.
(XEN) HVM: VMX enabled
(XEN) HVM: Hardware Assisted Paging detected.
(XEN) Intel machine check reporting enabled on CPU#0.
(XEN) mce_init: init bank0
(XEN) CPU0: Thermal monitoring enabled (TM1)
(XEN) CMCI: find owner on CPU0
(XEN) CMCI: CPU0 owner_map[6c], no_cmci_map[93]
(XEN) CPU0: Intel(R) Xeon(R) CPU E5520 @ 2.27GHz stepping 05
(XEN) Booting processor 1/2 eip 8c000
(XEN) Initializing CPU#1
(XEN) CPU: L1 I cache: 32K, L1 D cache: 32K
(XEN) CPU: L2 cache: 256K
(XEN) CPU: L3 cache: 8192K
(XEN) CPU: Physical Processor ID: 0
(XEN) CPU: Processor Core ID: 1
(XEN) Intel machine check reporting enabled on CPU#1.
(XEN) CPU1: Thermal monitoring enabled (TM1)
(XEN) CMCI: find owner on CPU1
(XEN) CMCI: CPU1 owner_map[2c], no_cmci_map[93]
(XEN) CPU1: Intel(R) Xeon(R) CPU E5520 @ 2.27GHz stepping 05
(XEN) Booting processor 2/4 eip 8c000
(XEN) Initializing CPU#2
(XEN) CPU: L1 I cache: 32K, L1 D cache: 32K
(XEN) CPU: L2 cache: 256K
(XEN) CPU: L3 cache: 8192K
(XEN) CPU: Physical Processor ID: 0
(XEN) CPU: Processor Core ID: 2
(XEN) Intel machine check reporting enabled on CPU#2.
(XEN) CPU2: Thermal monitoring enabled (TM1)
(XEN) CMCI: find owner on CPU2
(XEN) CMCI: CPU2 owner_map[2c], no_cmci_map[93]
(XEN) CPU2: Intel(R) Xeon(R) CPU E5520 @ 2.27GHz stepping 05
(XEN) Booting processor 3/6 eip 8c000
(XEN) Initializing CPU#3
(XEN) CPU: L1 I cache: 32K, L1 D cache: 32K
(XEN) CPU: L2 cache: 256K
(XEN) CPU: L3 cache: 8192K
(XEN) CPU: Physical Processor ID: 0
(XEN) CPU: Processor Core ID: 3
(XEN) Intel machine check reporting enabled on CPU#3.
(XEN) CPU3: Thermal monitoring enabled (TM1)
(XEN) CMCI: find owner on CPU3
(XEN) CMCI: CPU3 owner_map[2c], no_cmci_map[93]
(XEN) CPU3: Intel(R) Xeon(R) CPU E5520 @ 2.27GHz stepping 05
(XEN) Total of 4 processors activated.
(XEN) ENABLING IO-APIC IRQs
(XEN) -> Using new ACK method
(XEN) ..TIMER: vector=0xF0 apic1=0 pin1=2 apic2=-1 pin2=-1
(XEN) checking TSC synchronization across 4 CPUs: passed.
(XEN) Platform timer is 14.318MHz HPET
(XEN) microcode.c:73:d32767 microcode: CPU1 resumed
(XEN) Brought up 4 CPUs
(XEN) microcode.c:73:d32767 microcode: CPU3 resumed
(XEN) microcode.c:73:d32767 microcode: CPU2 resumed
(XEN) I/O virtualisation disabled
(XEN) HPET: 4 timers in total, 0 timers will be used for broadcast
(XEN) ACPI sleep modes: S3
(XEN) mcheck_poll: Machine check polling timer started.
(XEN) *** LOADING DOMAIN 0 ***
(XEN) elf_parse_binary: phdr: paddr=0x200000 memsz=0x459000
(XEN) elf_parse_binary: phdr: paddr=0x659000 memsz=0xad1c8
(XEN) elf_parse_binary: phdr: paddr=0x707000 memsz=0x888
(XEN) elf_parse_binary: phdr: paddr=0x708000 memsz=0x1250b8
(XEN) elf_parse_binary: memory: 0x200000 -> 0x82d0b8
(XEN) elf_xen_parse_note: GUEST_OS = "linux"
(XEN) elf_xen_parse_note: GUEST_VERSION = "2.6"
(XEN) elf_xen_parse_note: XEN_VERSION = "xen-3.0"
(XEN) elf_xen_parse_note: VIRT_BASE = 0xffffffff80000000
(XEN) elf_xen_parse_note: PADDR_OFFSET = 0x0
(XEN) elf_xen_parse_note: ENTRY = 0xffffffff80200000
(XEN) elf_xen_parse_note: HYPERCALL_PAGE = 0xffffffff80207000
(XEN) elf_xen_parse_note: unknown xen elf note (0xd)
(XEN) elf_xen_parse_note: FEATURES = "writable_page_tables|writable_descriptor_tables|auto_translated_physmap|pae_pgdir_above_4gb|supervisor_mode_kernel"
(XEN) elf_xen_parse_note: LOADER = "generic"
(XEN) elf_xen_parse_note: SUSPEND_CANCEL = 0x1
(XEN) elf_xen_addr_calc_check: addresses:
(XEN) virt_base = 0xffffffff80000000
(XEN) elf_paddr_offset = 0x0
(XEN) virt_offset = 0xffffffff80000000
(XEN) virt_kstart = 0xffffffff80200000
(XEN) virt_kend = 0xffffffff8082d0b8
(XEN) virt_entry = 0xffffffff80200000
(XEN) p2m_base = 0xffffffffffffffff
(XEN) Xen kernel: 64-bit, lsb, compat32
(XEN) Dom0 kernel: 64-bit, lsb, paddr 0x200000 -> 0x82d0b8
(XEN) PHYSICAL MEMORY ARRANGEMENT:
(XEN) Dom0 alloc.: 0000000334000000->0000000336000000 (899584 pages to be allocated)
(XEN) VIRTUAL MEMORY ARRANGEMENT:
(XEN) Loaded kernel: ffffffff80200000->ffffffff8082d0b8
(XEN) Init. ramdisk: ffffffff8082e000->ffffffff81209400
(XEN) Phys-Mach map: ffffffff8120a000->ffffffff818f7000
(XEN) Start info: ffffffff818f7000->ffffffff818f74b4
(XEN) Page tables: ffffffff818f8000->ffffffff81909000
(XEN) Boot stack: ffffffff81909000->ffffffff8190a000
(XEN) TOTAL: ffffffff80000000->ffffffff81c00000
(XEN) ENTRY ADDRESS: ffffffff80200000
(XEN) Dom0 has maximum 4 VCPUs
(XEN) elf_load_binary: phdr 0 at 0xffffffff80200000 -> 0xffffffff80659000
(XEN) elf_load_binary: phdr 1 at 0xffffffff80659000 -> 0xffffffff807061c8
(XEN) elf_load_binary: phdr 2 at 0xffffffff80707000 -> 0xffffffff80707888
(XEN) elf_load_binary: phdr 3 at 0xffffffff80708000 -> 0xffffffff807566a0
(XEN) Scrubbing Free RAM: ......................................................................................done.
(XEN) Xen trace buffers: disabled
(XEN) Std. Loglevel: All
(XEN) Guest Loglevel: All
(XEN) **********************************************
(XEN) ******* WARNING: CONSOLE OUTPUT IS SYNCHRONOUS
(XEN) ******* This option is intended to aid debugging of Xen by ensuring
(XEN) ******* that all output is synchronously delivered on the serial line.
(XEN) ******* However it can introduce SIGNIFICANT latencies and affect
(XEN) ******* timekeeping. It is NOT recommended for production use!
(XEN) **********************************************
(XEN) 3... 2... 1...
(XEN) *** Serial input -> DOM0 (type 'CTRL-a' three times to switch input to Xen)
(XEN) Freed 132kB init memory.
Kernel alive
Kernel really alive
Initializing cgroup subsys cpuset
Initializing cgroup subsys cpu
Linux version 2.6.27.19-5-xen (geeko@buildhost) (gcc version 4.3.2 [gcc-4_3-branch revision 141291] (SUSE Linux) ) #1 SMP 2009-02-28 04:40:21 +0100
Command line: root=/dev/md11 splash=silent showopts vga=0x314 console=ttyS0,38400,8n1 console=tty0 xencons=ttyS0
KERNEL supported cpus:
Intel GenuineIntel
AMD AuthenticAMD
Centaur CentaurHauls
Xen-provided physical RAM map:
Xen: 0000000000000000 - 00000000de200000 (usable)
DMI present.
last_pfn = 0xde200 max_arch_pfn = 0x6ffffff
init_memory_mapping
last_map_addr: de200000 end: de200000
RAMDISK: 0082e000 - 01209400
ACPI: RSDP 000F80F0, 0024 (r2 PTLTD )
ACPI: XSDT BF7C53B0, 00D4 (r1 PTLTD XSDT 60000 LTP 0)
ACPI: FACP BF7C9BE1, 00F4 (r3 FSC TYLERBRG 60000 PTL F4240)
ACPI: DSDT BF7C5484, 46D9 (r1 FSC D2619 60000 MSFT 3000001)
ACPI: FACS BF7CBFC0, 0040
ACPI: TCPA BF7C9CD5, 0032 (r1 Phoeni x 60000 TL 0)
ACPI: SLIT BF7C9D07, 0030 (r1 FSC 60000 5A)
ACPI: EINJ BF7C9D37, 01B0 (r1 PTL WHEAPTL 60000 PTL 1)
ACPI: HEST BF7C9EE7, 0268 (r1 PTL WHEAPTL 60000 PTL 1)
ACPI: BERT BF7CA14F, 0030 (r1 PTL WHEAPTL 60000 PTL 1)
ACPI: SSDT BF7CA17F, 00E1 (r1 wheaos wheaosc 60000 INTL 20050624)
ACPI: ERST BF7CA260, 0270 (r1 PTL WHEAPTL 60000 PTL 1)
ACPI: SSDT BF7CA4D0, 00D8 (r1 FSC CST_PR00 60000 CSF 1)
ACPI: SSDT BF7CA5A8, 00D8 (r1 FSC CST_PR02 60000 CSF 1)
ACPI: SSDT BF7CA680, 00D8 (r1 FSC CST_PR04 60000 CSF 1)
ACPI: SSDT BF7CA758, 00D8 (r1 FSC CST_PR06 60000 CSF 1)
ACPI: SSDT BF7CA830, 015B (r1 FSC PST_PR00 60000 CSF 1)
ACPI: SSDT BF7CA98B, 015B (r1 FSC PST_PR02 60000 CSF 1)
ACPI: SSDT BF7CAAE6, 015B (r1 FSC PST_PR04 60000 CSF 1)
ACPI: SSDT BF7CAC41, 015B (r1 FSC PST_PR06 60000 CSF 1)
ACPI: SPCR BF7CAD9C, 0050 (r1 PTLTD $UCRTBL$ 60000 PTL 1)
ACPI: BF7CADEC, 00E8 (r1 Intel OEMDMAR 60000 LOHR 1)
ACPI: MCFG BF7CAED4, 003C (r1 PTLTD MCFG 60000 LTP 0)
ACPI: HPET BF7CAF10, 0038 (r1 PTLTD HPETTBL 60000 LTP 1)
ACPI: APIC BF7CAF48, 0090 (r1 PTLTD APIC 60000 LTP 0)
ACPI: BOOT BF7CAFD8, 0028 (r1 PTLTD $SBFTBL$ 60000 LTP 1)
(4 early reservations) ==> bootmem [0000000000 - 00dda00000]
#0 [0000200000 - 000082d0b8] TEXT DATA BSS ==> [0000200000 - 000082d0b8]
#1 [000082e000 - 0001909000] Xen provided ==> [000082e000 - 0001909000]
#2 [0001909000 - 000190c000] INITMAP ==> [0001909000 - 000190c000]
#3 [000190c000 - 0002002000] PGTABLE ==> [000190c000 - 0002002000]
found SMP MP-table at [ffffffffff5f0120] 000f8120
Zone PFN ranges:
DMA 0x00000000 -> 0x00001000
DMA32 0x00001000 -> 0x00100000
Normal 0x00100000 -> 0x00100000
Movable zone start PFN for each node
early_node_map[1] active PFN ranges
0: 0x00000000 -> 0x000de200
ACPI: LAPIC (acpi_id[0x00] lapic_id[0x00] enabled)
ACPI: LAPIC (acpi_id[0x01] lapic_id[0x02] enabled)
ACPI: LAPIC (acpi_id[0x02] lapic_id[0x04] enabled)
ACPI: LAPIC (acpi_id[0x03] lapic_id[0x06] enabled)
ACPI: LAPIC_NMI (acpi_id[0x00] high edge lint[0x1])
ACPI: LAPIC_NMI (acpi_id[0x01] high edge lint[0x1])
ACPI: LAPIC_NMI (acpi_id[0x02] high edge lint[0x1])
ACPI: LAPIC_NMI (acpi_id[0x03] high edge lint[0x1])
ACPI: IOAPIC (id[0x01] address[0xfec00000] gsi_base[0])
IOAPIC[0]: apic_id 1, version 0, address 0xfec00000, GSI 0-23
ACPI: IOAPIC (id[0x03] address[0xfec80000] gsi_base[24])
IOAPIC[1]: apic_id 3, version 0, address 0xfec80000, GSI 24-47
ACPI: INT_SRC_OVR (bus 0 bus_irq 0 global_irq 2 high edge)
ACPI: INT_SRC_OVR (bus 0 bus_irq 9 global_irq 9 high level)
Using ACPI (MADT) for SMP configuration information
Allocating PCI resources starting at c2000000 (gap: c0000000:20000000)
PERCPU: Allocating 50848 bytes of per cpu data
Built 1 zonelists in Zone order, mobility grouping on. Total pages: 895608
Kernel command line: root=/dev/md11 splash=silent showopts vga=0x314 console=ttyS0,38400,8n1 console=tty0 xencons=ttyS0
bootsplash: silent mode.
Initializing CPU#0
PID hash table entries: 4096 (order: 12, 32768 bytes)
Extended CMOS year: 2000
Xen reported: 2266.748 MHz processor.
Console: colour VGA+ 80x25
console [tty0] enabled
console [ttyS0] enabled
Dentry cache hash table entries: 524288 (order: 10, 4194304 bytes)
Inode-cache hash table entries: 262144 (order: 9, 2097152 bytes)
Software IO TLB enabled:
Aperture: 64 megabytes
Kernel range: ffff880005e9f000 - ffff880009e9f000
Address size: 27 bits
PCI-DMA: Using software bounce buffering for IO (SWIOTLB)
Memory: 3469944k/3639296k available (2483k kernel code, 160452k reserved, 2190k data, 284k init)
Calibrating delay using timer specific routine.. 4535.34 BogoMIPS (lpj=9070687)
Security Framework initialized
AppArmor: AppArmor initialized
Mount-cache hash table entries: 256
Initializing cgroup subsys ns
Initializing cgroup subsys cpuacct
Initializing cgroup subsys memory
Initializing cgroup subsys devices
Initializing cgroup subsys freezer
CPU: L1 I cache: 32K, L1 D cache: 32K
CPU: L2 cache: 256K
CPU: L3 cache: 8192K
CPU: Physical Processor ID: 0
CPU: Processor Core ID: 0
SMP alternatives: switching to UP code
ACPI: Core revision 20080609
Parsing all Control Methods:
Table [DSDT](id 0001) - 563 Objects with 64 Devices 124 Methods 34 Regions
Parsing all Control Methods:
Table [SSDT](id 0002) - 8 Objects with 0 Devices 1 Methods 2 Regions
Parsing all Control Methods:
Table [SSDT](id 0003) - 2 Objects with 0 Devices 0 Methods 0 Regions
Parsing all Control Methods:
Table [SSDT](id 0004) - 2 Objects with 0 Devices 0 Methods 0 Regions
Parsing all Control Methods:
Table [SSDT](id 0005) - 2 Objects with 0 Devices 0 Methods 0 Regions
Parsing all Control Methods:
Table [SSDT](id 0006) - 2 Objects with 0 Devices 0 Methods 0 Regions
Parsing all Control Methods:
Table [SSDT](id 0007) - 3 Objects with 0 Devices 0 Methods 0 Regions
Parsing all Control Methods:
Table [SSDT](id 0008) - 3 Objects with 0 Devices 0 Methods 0 Regions
Parsing all Control Methods:
Table [SSDT](id 0009) - 3 Objects with 0 Devices 0 Methods 0 Regions
Parsing all Control Methods:
Table [SSDT](id 000A) - 3 Objects with 0 Devices 0 Methods 0 Regions
tbxface-0596 [00] tb_load_namespace : ACPI Tables successfully acquired
evxfevnt-0091 [00] enable : Transition to ACPI mode successful
SMP alternatives: switching to SMP code
Initializing CPU#1
Initializing CPU#2
CPU: L1 I cache: 32K, L1 D cache: 32K
CPU: L2 cache: 256K
CPU: L3 cache: 8192K
CPU: Physical Processor ID: 0
CPU: Processor Core ID: 2
Brought up 4 CPUs
Initializing CPU#3
CPU: L1 I cache: 32K, L1 D cache: 32K
CPU: L2 cache: 256K
CPU: L3 cache: 8192K
CPU: Physical Processor ID: 0
CPU: Processor Core ID: 3
net_namespace: 1936 bytes
CPU: L1 I cache: 32K, L1 D cache: 32K
CPU: L2 cache: 256K
CPU: L3 cache: 8192K
CPU: Physical Processor ID: 0
CPU: Processor Core ID: 1
NET: Registered protocol family 16
ACPI FADT declares the system doesn't support PCIe ASPM, so disable it
ACPI: bus type pci registered
PCI: MCFG configuration 0: base e0000000 segment 0 buses 0 - 10
PCI: MCFG area at e0000000 reserved in E820
PCI: Using MMCONFIG at e0000000 - e0afffff
PCI: Using configuration type 1 for base access
evgpeblk-0957 [00] ev_create_gpe_block : GPE 00 to 3F [_GPE] 8 regs on int 0x9
Completing Region/Field/Buffer/Package initialization:..................................................................................................
Initialized 31/36 Regions 0/0 Fields 24/24 Buffers 43/43 Packages (600 nodes)
Initializing Device/Processor/Thermal objects by executing _INI methods:.............
Executed 13 _INI methods requiring 13 _STA executions (examined 82 objects)
evgpeblk-1054 [00] ev_initialize_gpe_bloc: Found 9 Wake, Enabled 1 Runtime GPEs in this block
ACPI: Interpreter enabled
ACPI: (supports S0 S1 S5)
ACPI: Using IOAPIC for interrupt routing
ACPI: PCI Root Bridge [CPU0] (0000:ff)
ACPI: PCI Root Bridge [CPU1] (0000:fe)
ACPI: PCI Root Bridge [PCI0] (0000:00)
pci 0000:00:00.0: PME# supported from D0 D3hot D3cold
pci 0000:00:00.0: PME# disabled
pci 0000:00:01.0: PME# supported from D0 D3hot D3cold
pci 0000:00:01.0: PME# disabled
pci 0000:00:03.0: PME# supported from D0 D3hot D3cold
pci 0000:00:03.0: PME# disabled
pci 0000:00:05.0: PME# supported from D0 D3hot D3cold
pci 0000:00:05.0: PME# disabled
pci 0000:00:07.0: PME# supported from D0 D3hot D3cold
pci 0000:00:07.0: PME# disabled
pci 0000:00:08.0: PME# supported from D0 D3hot D3cold
pci 0000:00:08.0: PME# disabled
pci 0000:00:09.0: PME# supported from D0 D3hot D3cold
pci 0000:00:09.0: PME# disabled
pci 0000:00:0a.0: PME# supported from D0 D3hot D3cold
pci 0000:00:0a.0: PME# disabled
pci 0000:00:1a.7: PME# supported from D0 D3hot D3cold
pci 0000:00:1a.7: PME# disabled
pci 0000:00:1c.0: PME# supported from D0 D3hot D3cold
pci 0000:00:1c.0: PME# disabled
pci 0000:00:1c.4: PME# supported from D0 D3hot D3cold
pci 0000:00:1c.4: PME# disabled
pci 0000:00:1d.7: PME# supported from D0 D3hot D3cold
pci 0000:00:1d.7: PME# disabled
pci 0000:08:00.0: PME# supported from D0 D3hot D3cold
pci 0000:08:00.0: PME# disabled
pci 0000:08:00.1: PME# supported from D0 D3hot D3cold
pci 0000:08:00.1: PME# disabled
pci 0000:00:1e.0: transparent bridge
ACPI: PCI Interrupt Link [LNKA] (IRQs 3 4 5 6 7 9 10 *11 12 14 15)
ACPI: PCI Interrupt Link [LNKB] (IRQs 3 4 5 6 7 9 10 *11 12 14 15)
ACPI: PCI Interrupt Link [LNKC] (IRQs 3 4 5 6 7 *9 10 11 12 14 15)
ACPI: PCI Interrupt Link [LNKD] (IRQs 3 4 5 6 7 9 *10 11 12 14 15)
ACPI: PCI Interrupt Link [LNKE] (IRQs 3 4 5 6 7 9 10 11 12 14 15) *0, disabled.
ACPI: PCI Interrupt Link [LNKF] (IRQs 3 4 5 6 7 9 10 *11 12 14 15)
ACPI: PCI Interrupt Link [LNKG] (IRQs 3 4 5 6 7 9 10 *11 12 14 15)
ACPI: PCI Interrupt Link [LNKH] (IRQs 3 4 *5 6 7 9 10 11 12 14 15)
ACPI Warning (tbutils-0217): Incorrect checksum in table [ ] - 41, should be 85 [20080609]
Linux Plug and Play Support v0.97 (c) Adam Belay
pnp: PnP ACPI init
ACPI: bus type pnp registered
pnp: PnP ACPI: found 13 devices
ACPI: ACPI bus type pnp unregistered
xen_mem: Initialising balloon driver.
PCI: Using ACPI for IRQ routing
AppArmor: AppArmor Filesystem Enabled
ACPI: RTC can wake from S4
system 00:00: iomem range 0xe0000000-0xefffffff could not be reserved
system 00:04: ioport range 0x200-0x20f has been reserved
system 00:04: ioport range 0x4d0-0x4d1 has been reserved
system 00:04: ioport range 0x500-0x57f has been reserved
system 00:04: ioport range 0x800-0x80f has been reserved
system 00:04: ioport range 0x810-0x81f has been reserved
system 00:04: ioport range 0xca0-0xca1 has been reserved
system 00:04: ioport range 0xca4-0xca7 has been reserved
system 00:04: ioport range 0xca8-0xcab has been reserved
system 00:04: ioport range 0xcae-0xcaf has been reserved
system 00:04: ioport range 0xe00-0xe7f has been reserved
system 00:04: ioport range 0x1000-0x107f has been reserved
system 00:04: ioport range 0x1100-0x110f has been reserved
system 00:04: ioport range 0x1180-0x11ff has been reserved
system 00:04: ioport range 0xfe00-0xfe00 has been reserved
system 00:04: ioport range 0xff00-0xff00 has been reserved
system 00:04: iomem range 0xfec00000-0xfecfffff could not be reserved
system 00:04: iomem range 0xfee00000-0xfeefffff could not be reserved
system 00:04: iomem range 0xfed1c000-0xfed1ffff has been reserved
pci 0000:00:01.0: PCI bridge, secondary bus 0000:01
pci 0000:00:01.0: IO window: 0x2000-0x2fff
pci 0000:00:01.0: MEM window: 0xce100000-0xce1fffff
pci 0000:00:01.0: PREFETCH window: 0x000000c2000000-0x000000c20fffff
pci 0000:00:03.0: PCI bridge, secondary bus 0000:02
pci 0000:00:03.0: IO window: 0x3000-0x3fff
pci 0000:00:03.0: MEM window: 0xce200000-0xce2fffff
pci 0000:00:03.0: PREFETCH window: 0x000000c2100000-0x000000c21fffff
pci 0000:00:05.0: PCI bridge, secondary bus 0000:03
pci 0000:00:05.0: IO window: disabled
pci 0000:00:05.0: MEM window: disabled
pci 0000:00:05.0: PREFETCH window: disabled
pci 0000:00:07.0: PCI bridge, secondary bus 0000:04
pci 0000:00:07.0: IO window: disabled
pci 0000:00:07.0: MEM window: disabled
pci 0000:00:07.0: PREFETCH window: disabled
pci 0000:00:08.0: PCI bridge, secondary bus 0000:05
pci 0000:00:08.0: IO window: disabled
pci 0000:00:08.0: MEM window: disabled
pci 0000:00:08.0: PREFETCH window: disabled
pci 0000:00:09.0: PCI bridge, secondary bus 0000:06
pci 0000:00:09.0: IO window: disabled
pci 0000:00:09.0: MEM window: disabled
pci 0000:00:09.0: PREFETCH window: disabled
pci 0000:00:0a.0: PCI bridge, secondary bus 0000:07
pci 0000:00:0a.0: IO window: disabled
pci 0000:00:0a.0: MEM window: disabled
pci 0000:00:0a.0: PREFETCH window: disabled
pci 0000:00:1c.0: PCI bridge, secondary bus 0000:08
pci 0000:00:1c.0: IO window: 0x4000-0x4fff
pci 0000:00:1c.0: MEM window: 0xce300000-0xce3fffff
pci 0000:00:1c.0: PREFETCH window: 0x000000c2200000-0x000000c22fffff
pci 0000:00:1c.4: PCI bridge, secondary bus 0000:09
pci 0000:00:1c.4: IO window: disabled
pci 0000:00:1c.4: MEM window: 0xce400000-0xceffffff
pci 0000:00:1c.4: PREFETCH window: 0x000000cf000000-0x000000cfffffff
pci 0000:00:1e.0: PCI bridge, secondary bus 0000:0a
pci 0000:00:1e.0: IO window: disabled
pci 0000:00:1e.0: MEM window: disabled
pci 0000:00:1e.0: PREFETCH window: disabled
pci 0000:00:01.0: PCI INT A -> GSI 28 (level, low) -> IRQ 28
pci 0000:00:03.0: PCI INT A -> GSI 24 (level, low) -> IRQ 24
pci 0000:00:05.0: PCI INT A -> GSI 26 (level, low) -> IRQ 26
pci 0000:00:07.0: PCI INT A -> GSI 30 (level, low) -> IRQ 30
pci 0000:00:08.0: PCI INT A -> GSI 31 (level, low) -> IRQ 31
pci 0000:00:09.0: PCI INT A -> GSI 32 (level, low) -> IRQ 32
pci 0000:00:0a.0: PCI INT A -> GSI 33 (level, low) -> IRQ 33
pci 0000:00:1c.0: PCI INT A -> GSI 16 (level, low) -> IRQ 16
pci 0000:00:1c.4: PCI INT A -> GSI 16 (level, low) -> IRQ 16
bus: ff index 0 io port: [0, ffff]
bus: ff index 1 mmio: [0, ffffffffffffffff]
bus: fe index 0 io port: [0, ffff]
bus: fe index 1 mmio: [0, ffffffffffffffff]
bus: 00 index 0 io port: [0, ffff]
bus: 00 index 1 mmio: [0, ffffffffffffffff]
bus: 01 index 0 io port: [2000, 2fff]
bus: 01 index 1 mmio: [ce100000, ce1fffff]
bus: 01 index 2 mmio: [c2000000, c20fffff]
bus: 01 index 3 mmio: [0, 0]
bus: 02 index 0 io port: [3000, 3fff]
bus: 02 index 1 mmio: [ce200000, ce2fffff]
bus: 02 index 2 mmio: [c2100000, c21fffff]
bus: 02 index 3 mmio: [0, 0]
bus: 03 index 0 mmio: [0, 0]
bus: 03 index 1 mmio: [0, 0]
bus: 03 index 2 mmio: [0, 0]
bus: 03 index 3 mmio: [0, 0]
bus: 04 index 0 mmio: [0, 0]
bus: 04 index 1 mmio: [0, 0]
bus: 04 index 2 mmio: [0, 0]
bus: 04 index 3 mmio: [0, 0]
bus: 05 index 0 mmio: [0, 0]
bus: 05 index 1 mmio: [0, 0]
bus: 05 index 2 mmio: [0, 0]
bus: 05 index 3 mmio: [0, 0]
bus: 06 index 0 mmio: [0, 0]
bus: 06 index 1 mmio: [0, 0]
bus: 06 index 2 mmio: [0, 0]
bus: 06 index 3 mmio: [0, 0]
bus: 07 index 0 mmio: [0, 0]
bus: 07 index 1 mmio: [0, 0]
bus: 07 index 2 mmio: [0, 0]
bus: 07 index 3 mmio: [0, 0]
bus: 08 index 0 io port: [4000, 4fff]
bus: 08 index 1 mmio: [ce300000, ce3fffff]
bus: 08 index 2 mmio: [c2200000, c22fffff]
bus: 08 index 3 mmio: [0, 0]
bus: 09 index 0 mmio: [0, 0]
bus: 09 index 1 mmio: [ce400000, ceffffff]
bus: 09 index 2 mmio: [cf000000, cfffffff]
bus: 09 index 3 mmio: [0, 0]
bus: 0a index 0 mmio: [0, 0]
bus: 0a index 1 mmio: [0, 0]
bus: 0a index 2 mmio: [0, 0]
bus: 0a index 3 io port: [0, ffff]
bus: 0a index 4 mmio: [0, ffffffffffffffff]
NET: Registered protocol family 2
IP route cache hash table entries: 131072 (order: 8, 1048576 bytes)
TCP established hash table entries: 262144 (order: 10, 4194304 bytes)
TCP bind hash table entries: 65536 (order: 8, 1048576 bytes)
TCP: Hash tables configured (established 262144 bind 65536)
TCP reno registered
NET: Registered protocol family 1
Unpacking initramfs... done
Freeing initrd memory: 10093k freed
Simple Boot Flag at 0x7c set to 0x1
audit: initializing netlink socket (disabled)
type=2000 audit(1256132858.083:1): initialized
VFS: Disk quotas dquot_6.5.1
Dquot-cache hash table entries: 512 (order 0, 4096 bytes)
msgmni has been set to 1777
Block layer SCSI generic (bsg) driver version 0.4 loaded (major 254)
io scheduler noop registered
io scheduler anticipatory registered
io scheduler deadline registered
io scheduler cfq registered (default)
(XEN) PCI add device 00:01.0
pcieport-driver 0000:00:01.0: found MSI capability
(XEN) PCI add device 00:03.0
pcieport-driver 0000:00:03.0: found MSI capability
(XEN) PCI add device 00:05.0
pcieport-driver 0000:00:05.0: found MSI capability
(XEN) PCI add device 00:07.0
pcieport-driver 0000:00:07.0: found MSI capability
(XEN) PCI add device 00:08.0
pcieport-driver 0000:00:08.0: found MSI capability
(XEN) PCI add device 00:09.0
pcieport-driver 0000:00:09.0: found MSI capability
(XEN) PCI add device 00:0a.0
pcieport-driver 0000:00:0a.0: found MSI capability
(XEN) PCI add device 00:1c.0
pcieport-driver 0000:00:1c.0: found MSI capability
(XEN) PCI add device 00:1c.4
pcieport-driver 0000:00:1c.4: found MSI capability
Non-volatile memory driver v1.2
Xen virtual console successfully installed as ttyS0
Event-channel device installed.
PNP: No PS/2 controller found. Probing ports directly.
i8042.c: No controller found.
mice: PS/2 mouse device common for all mice
TCP cubic registered
registered taskstats version 1
Freeing unused kernel memory: 284k freed
Write protecting the kernel read-only data: 4420k
SCSI subsystem initialized
megasas: 00.00.04.01 Thu July 24 11:41:51 PST 2008
(XEN) PCI add device 01:00.0
megasas: 0x1000:0x0060:0x1734:0x10f9: bus 1:slot 0:func 0
vendor=8086 device=3408
megaraid_sas 0000:01:00.0: PCI INT A -> GSI 28 (level, low) -> IRQ 28
megasas: FW now in Ready state
scsi0 : LSI SAS based MegaRAID driver
scsi 0:0:4:0: Enclosure FSC SAS Expander 1.04 PQ: 0 ANSI: 3
scsi 0:0:5:0: Direct-Access SEAGATE ST9146802SS 2101 PQ: 0 ANSI: 5
scsi 0:0:6:0: Direct-Access SEAGATE ST9146802SS 2101 PQ: 0 ANSI: 5
scsi 0:0:7:0: Enclosure FSC SAS Expander 1.04 PQ: 0 ANSI: 3
scsi 0:2:0:0: Direct-Access LSI MegaRAID SAS RMB 1.40 PQ: 0 ANSI: 5
scsi 0:2:1:0: Direct-Access LSI MegaRAID SAS RMB 1.40 PQ: 0 ANSI: 5
scsi 0:2:2:0: Direct-Access LSI MegaRAID SAS RMB 1.40 PQ: 0 ANSI: 5
scsi 0:2:3:0: Direct-Access LSI MegaRAID SAS RMB 1.40 PQ: 0 ANSI: 5
scsi 0:2:4:0: Direct-Access LSI MegaRAID SAS RMB 1.40 PQ: 0 ANSI: 5
scsi 0:2:5:0: Direct-Access LSI MegaRAID SAS RMB 1.40 PQ: 0 ANSI: 5
Emulex LightPulse Fibre Channel SCSI driver 8.2.8.14
Copyright(c) 2004-2009 Emulex. All rights reserved.
(XEN) PCI add device 02:00.0
vendor=8086 device=340a
lpfc 0000:02:00.0: PCI INT A -> GSI 24 (level, low) -> IRQ 24
scsi1 : on PCI bus 02 device 00 irq 24
(XEN) PCI add device 02:00.1
vendor=8086 device=340a
lpfc 0000:02:00.1: PCI INT B -> GSI 34 (level, low) -> IRQ 34
scsi2 : on PCI bus 02 device 01 irq 34
ACPI: CPU0 (power states: C1[C1] C3[C3])
(XEN) Set CPU acpi_id(0) cpuid(0) Px State info:
(XEN) _PCT: descriptor=130, length=12, space_id=127, bit_width=0, bit_offset=0, reserved=0, address=0
(XEN) _PCT: descriptor=130, length=12, space_id=127, bit_width=0, bit_offset=0, reserved=0, address=0
(XEN) _PSS: state_count=7
(XEN) State0: 2262MHz 101000mW 50us 150us 0x12 0x12
(XEN) State1: 2261MHz 100000mW 50us 150us 0x11 0x11
(XEN) State2: 2128MHz 94000mW 50us 150us 0x10 0x10
(XEN) State3: 1995MHz 88000mW 50us 150us 0xf 0xf
(XEN) State4: 1862MHz 82000mW 50us 150us 0xe 0xe
(XEN) State5: 1729MHz 76000mW 50us 150us 0xd 0xd
(XEN) State6: 1596MHz 70000mW 50us 150us 0xc 0xc
(XEN) _PSD: num_entries=5 rev=0 domain=0 coord_type=252 num_processors=1
(XEN) _PPC: 0
(XEN) xen_pminfo: @acpi_cpufreq_cpu_init,HARDWARE addr space
(XEN) CPU 0 initialization completed
processor ACPI_CPU:00: registered as cooling_device0
No available Cx info for cpu 255
processor ACPI_CPU:01: registered as cooling_device1
ACPI: CPU2 (power states: C1[C1] C3[C3])
(XEN) Set CPU acpi_id(1) cpuid(1) Px State info:
(XEN) _PCT: descriptor=130, length=12, space_id=127, bit_width=0, bit_offset=0, reserved=0, address=0
(XEN) _PCT: descriptor=130, length=12, space_id=127, bit_width=0, bit_offset=0, reserved=0, address=0
(XEN) _PSS: state_count=7
(XEN) State0: 2262MHz 101000mW 50us 150us 0x12 0x12
(XEN) State1: 2261MHz 100000mW 50us 150us 0x11 0x11
(XEN) State2: 2128MHz 94000mW 50us 150us 0x10 0x10
(XEN) State3: 1995MHz 88000mW 50us 150us 0xf 0xf
(XEN) State4: 1862MHz 82000mW 50us 150us 0xe 0xe
(XEN) State5: 1729MHz 76000mW 50us 150us 0xd 0xd
(XEN) State6: 1596MHz 70000mW 50us 150us 0xc 0xc
(XEN) _PSD: num_entries=5 rev=0 domain=1 coord_type=252 num_processors=1
(XEN) _PPC: 0
(XEN) xen_pminfo: @acpi_cpufreq_cpu_init,HARDWARE addr space
(XEN) CPU 1 initialization completed
processor ACPI_CPU:02: registered as cooling_device2
BIOS reported wrong ACPI id for the processor
ACPI Exception (evxface-0544): AE_NOT_EXIST, Removing notify handler [20080609]
ACPI: CPU-1 (power states: C1[C1] C3[C3])
(XEN) Set CPU acpi_id(2) cpuid(2) Px State info:
(XEN) _PCT: descriptor=130, length=12, space_id=127, bit_width=0, bit_offset=0, reserved=0, address=0
(XEN) _PCT: descriptor=130, length=12, space_id=127, bit_width=0, bit_offset=0, reserved=0, address=0
(XEN) _PSS: state_count=7
(XEN) State0: 2262MHz 101000mW 50us 150us 0x12 0x12
(XEN) State1: 2261MHz 100000mW 50us 150us 0x11 0x11
(XEN) State2: 2128MHz 94000mW 50us 150us 0x10 0x10
(XEN) State3: 1995MHz 88000mW 50us 150us 0xf 0xf
(XEN) State4: 1862MHz 82000mW 50us 150us 0xe 0xe
(XEN) State5: 1729MHz 76000mW 50us 150us 0xd 0xd
(XEN) State6: 1596MHz 70000mW 50us 150us 0xc 0xc
(XEN) _PSD: num_entries=5 rev=0 domain=2 coord_type=252 num_processors=1
(XEN) _PPC: 0
(XEN) xen_pminfo: @acpi_cpufreq_cpu_init,HARDWARE addr space
(XEN) CPU 2 initialization completed
processor ACPI_CPU:04: registered as cooling_device3
No available Cx info for cpu 255
processor ACPI_CPU:05: registered as cooling_device4
ACPI: CPU-1 (power states: C1[C1] C3[C3])
(XEN) Set CPU acpi_id(3) cpuid(3) Px State info:
(XEN) _PCT: descriptor=130, length=12, space_id=127, bit_width=0, bit_offset=0, reserved=0, address=0
(XEN) _PCT: descriptor=130, length=12, space_id=127, bit_width=0, bit_offset=0, reserved=0, address=0
(XEN) _PSS: state_count=7
(XEN) State0: 2262MHz 101000mW 50us 150us 0x12 0x12
(XEN) State1: 2261MHz 100000mW 50us 150us 0x11 0x11
(XEN) State2: 2128MHz 94000mW 50us 150us 0x10 0x10
(XEN) State3: 1995MHz 88000mW 50us 150us 0xf 0xf
(XEN) State4: 1862MHz 82000mW 50us 150us 0xe 0xe
(XEN) State5: 1729MHz 76000mW 50us 150us 0xd 0xd
(XEN) State6: 1596MHz 70000mW 50us 150us 0xc 0xc
(XEN) _PSD: num_entries=5 rev=0 domain=3 coord_type=252 num_processors=1
(XEN) _PPC: 0
(XEN) xen_pminfo: @acpi_cpufreq_cpu_init,HARDWARE addr space
(XEN) CPU 3 initialization completed
processor ACPI_CPU:06: registered as cooling_device5
BIOS reported wrong ACPI id for the processor
ACPI Exception (evxface-0544): AE_NOT_EXIST, Removing notify handler [20080609]
No available Cx info for cpu 255
processor ACPI_CPU:08: registered as cooling_device6
BIOS reported wrong ACPI id for the processor
ACPI Exception (evxface-0544): AE_NOT_EXIST, Removing notify handler [20080609]
No available Cx info for cpu 255
processor ACPI_CPU:0a: registered as cooling_device7
BIOS reported wrong ACPI id for the processor
ACPI Exception (evxface-0544): AE_NOT_EXIST, Removing notify handler [20080609]
No available Cx info for cpu 255
processor ACPI_CPU:0c: registered as cooling_device8
BIOS reported wrong ACPI id for the processor
ACPI Exception (evxface-0544): AE_NOT_EXIST, Removing notify handler [20080609]
No available Cx info for cpu 255
processor ACPI_CPU:0e: registered as cooling_device9
BIOS reported wrong ACPI id for the processor
ACPI Exception (evxface-0544): AE_NOT_EXIST, Removing notify handler [20080609]
ACPI: No dock devices found.
(XEN) PCI add device 00:1f.2
ata_piix 0000:00:1f.2: PCI INT A -> GSI 16 (level, low) -> IRQ 16
ata_piix 0000:00:1f.2: MAP [ P0 P2 P1 P3 ]
scsi3 : ata_piix
scsi4 : ata_piix
ata1: SATA max UDMA/133 cmd 0x1c50 ctl 0x1c44 bmdma 0x1c10 irq 16
ata2: SATA max UDMA/133 cmd 0x1c48 ctl 0x1c40 bmdma 0x1c18 irq 16
ata1.00: SATA link up 1.5 Gbps (SStatus 113 SControl 300)
ata1.01: SATA link down (SStatus 0 SControl 300)
ata1.00: ATAPI: HL-DT-ST DVDRAM GH40N, NV01, max UDMA/100
ata1.00: configured for UDMA/100
ata2.00: SATA link down (SStatus 0 SControl 300)
ata2.01: SATA link down (SStatus 0 SControl 300)
scsi 3:0:0:0: CD-ROM HL-DT-ST DVDRAM GH40N NV01 PQ: 0 ANSI: 5
(XEN) PCI add device 00:1f.5
ata_piix 0000:00:1f.5: PCI INT B -> GSI 17 (level, low) -> IRQ 17
ata_piix 0000:00:1f.5: MAP [ P0 -- P1 -- ]
scsi5 : ata_piix
scsi6 : ata_piix
ata3: SATA max UDMA/133 cmd 0x1c68 ctl 0x1c5c bmdma 0x1c30 irq 17
ata4: SATA max UDMA/133 cmd 0x1c60 ctl 0x1c58 bmdma 0x1c38 irq 17
ata3: SATA link down (SStatus 0 SControl 300)
ata4: SATA link down (SStatus 0 SControl 300)
Uniform Multi-Platform E-IDE driver
md: raid1 personality registered for level 1
BIOS EDD facility v0.16 2004-Jun-25, 6 devices found
usbcore: registered new interface driver usbfs
usbcore: registered new interface driver hub
usbcore: registered new device driver usb
usbcore: registered new interface driver hiddev
usbcore: registered new interface driver usbhid
usbhid: v2.6:USB HID core driver
(XEN) PCI add device 00:1a.7
ehci_hcd 0000:00:1a.7: PCI INT C -> GSI 18 (level, low) -> IRQ 18
ehci_hcd 0000:00:1a.7: EHCI Host Controller
ehci_hcd 0000:00:1a.7: new USB bus registered, assigned bus number 1
ehci_hcd 0000:00:1a.7: debug port 1
ehci_hcd 0000:00:1a.7: irq 18, io mem 0xce020000
ehci_hcd 0000:00:1a.7: USB 2.0 started, EHCI 1.00, driver 10 Dec 2004
usb usb1: configuration #1 chosen from 1 choice
hub 1-0:1.0: USB hub found
hub 1-0:1.0: 6 ports detected
usb usb1: New USB device found, idVendor=1d6b, idProduct=0002
usb usb1: New USB device strings: Mfr=3, Product=2, SerialNumber=1
usb usb1: Product: EHCI Host Controller
usb usb1: Manufacturer: Linux 2.6.27.19-5-xen ehci_hcd
usb usb1: SerialNumber: 0000:00:1a.7
(XEN) PCI add device 00:1d.7
ehci_hcd 0000:00:1d.7: PCI INT A -> GSI 23 (level, low) -> IRQ 23
ehci_hcd 0000:00:1d.7: EHCI Host Controller
ehci_hcd 0000:00:1d.7: new USB bus registered, assigned bus number 2
ehci_hcd 0000:00:1d.7: debug port 1
ehci_hcd 0000:00:1d.7: irq 23, io mem 0xce021000
ehci_hcd 0000:00:1d.7: USB 2.0 started, EHCI 1.00, driver 10 Dec 2004
usb usb2: configuration #1 chosen from 1 choice
hub 2-0:1.0: USB hub found
hub 2-0:1.0: 6 ports detected
usb usb2: New USB device found, idVendor=1d6b, idProduct=0002
usb usb2: New USB device strings: Mfr=3, Product=2, SerialNumber=1
usb usb2: Product: EHCI Host Controller
usb usb2: Manufacturer: Linux 2.6.27.19-5-xen ehci_hcd
usb usb2: SerialNumber: 0000:00:1d.7
USB Universal Host Controller Interface driver v3.0
(XEN) PCI add device 00:1a.0
uhci_hcd 0000:00:1a.0: PCI INT A -> GSI 19 (level, low) -> IRQ 19
uhci_hcd 0000:00:1a.0: UHCI Host Controller
uhci_hcd 0000:00:1a.0: new USB bus registered, assigned bus number 3
uhci_hcd 0000:00:1a.0: irq 19, io base 0x00001820
usb usb3: configuration #1 chosen from 1 choice
hub 3-0:1.0: USB hub found
hub 3-0:1.0: 2 ports detected
usb usb3: New USB device found, idVendor=1d6b, idProduct=0001
usb usb3: New USB device strings: Mfr=3, Product=2, SerialNumber=1
usb usb3: Product: UHCI Host Controller
usb usb3: Manufacturer: Linux 2.6.27.19-5-xen uhci_hcd
usb usb3: SerialNumber: 0000:00:1a.0
(XEN) PCI add device 00:1a.1
uhci_hcd 0000:00:1a.1: PCI INT B -> GSI 18 (level, low) -> IRQ 18
uhci_hcd 0000:00:1a.1: UHCI Host Controller
uhci_hcd 0000:00:1a.1: new USB bus registered, assigned bus number 4
uhci_hcd 0000:00:1a.1: irq 18, io base 0x00001840
usb usb4: configuration #1 chosen from 1 choice
hub 4-0:1.0: USB hub found
hub 4-0:1.0: 2 ports detected
usb usb4: New USB device found, idVendor=1d6b, idProduct=0001
usb usb4: New USB device strings: Mfr=3, Product=2, SerialNumber=1
usb usb4: Product: UHCI Host Controller
usb usb4: Manufacturer: Linux 2.6.27.19-5-xen uhci_hcd
usb usb4: SerialNumber: 0000:00:1a.1
(XEN) PCI add device 00:1a.2
uhci_hcd 0000:00:1a.2: PCI INT C -> GSI 18 (level, low) -> IRQ 18
uhci_hcd 0000:00:1a.2: UHCI Host Controller
uhci_hcd 0000:00:1a.2: new USB bus registered, assigned bus number 5
uhci_hcd 0000:00:1a.2: irq 18, io base 0x00001860
usb usb5: configuration #1 chosen from 1 choice
hub 5-0:1.0: USB hub found
hub 5-0:1.0: 2 ports detected
usb usb5: New USB device found, idVendor=1d6b, idProduct=0001
usb usb5: New USB device strings: Mfr=3, Product=2, SerialNumber=1
usb usb5: Product: UHCI Host Controller
usb usb5: Manufacturer: Linux 2.6.27.19-5-xen uhci_hcd
usb usb5: SerialNumber: 0000:00:1a.2
(XEN) PCI add device 00:1d.0
uhci_hcd 0000:00:1d.0: PCI INT A -> GSI 23 (level, low) -> IRQ 23
uhci_hcd 0000:00:1d.0: UHCI Host Controller
uhci_hcd 0000:00:1d.0: new USB bus registered, assigned bus number 6
uhci_hcd 0000:00:1d.0: irq 23, io base 0x00001880
usb usb6: configuration #1 chosen from 1 choice
hub 6-0:1.0: USB hub found
hub 6-0:1.0: 2 ports detected
usb usb6: New USB device found, idVendor=1d6b, idProduct=0001
usb usb6: New USB device strings: Mfr=3, Product=2, SerialNumber=1
usb usb6: Product: UHCI Host Controller
usb usb6: Manufacturer: Linux 2.6.27.19-5-xen uhci_hcd
usb usb6: SerialNumber: 0000:00:1d.0
(XEN) PCI add device 00:1d.1
uhci_hcd 0000:00:1d.1: PCI INT B -> GSI 22 (level, low) -> IRQ 22
uhci_hcd 0000:00:1d.1: UHCI Host Controller
uhci_hcd 0000:00:1d.1: new USB bus registered, assigned bus number 7
uhci_hcd 0000:00:1d.1: irq 22, io base 0x000018a0
usb usb7: configuration #1 chosen from 1 choice
hub 7-0:1.0: USB hub found
hub 7-0:1.0: 2 ports detected
usb usb7: New USB device found, idVendor=1d6b, idProduct=0001
usb usb7: New USB device strings: Mfr=3, Product=2, SerialNumber=1
usb usb7: Product: UHCI Host Controller
usb usb7: Manufacturer: Linux 2.6.27.19-5-xen uhci_hcd
usb usb7: SerialNumber: 0000:00:1d.1
(XEN) PCI add device 00:1d.2
uhci_hcd 0000:00:1d.2: PCI INT C -> GSI 21 (level, low) -> IRQ 21
uhci_hcd 0000:00:1d.2: UHCI Host Controller
usb 7-2: new full speed USB device using uhci_hcd and address 2
uhci_hcd 0000:00:1d.2: new USB bus registered, assigned bus number 8
uhci_hcd 0000:00:1d.2: irq 21, io base 0x000018c0
usb usb8: configuration #1 chosen from 1 choice
hub 8-0:1.0: USB hub found
hub 8-0:1.0: 2 ports detected
usb 7-2: configuration #1 chosen from 1 choice
usb usb8: New USB device found, idVendor=1d6b, idProduct=0001
usb usb8: New USB device strings: Mfr=3, Product=2, SerialNumber=1
usb usb8: Product: UHCI Host Controller
usb usb8: Manufacturer: Linux 2.6.27.19-5-xen uhci_hcd
usb usb8: SerialNumber: 0000:00:1d.2
netfront: Initialising virtual ethernet driver.
input: FSC USB2 as /devices/pci0000:00/0000:00:1d.1/usb7/7-2/7-2:1.0/input/input0
udevd version 128 started
input,hidraw0: USB HID v1.10 Keyboard [FSC USB2] on usb-0000:00:1d.1-2
input: FSC USB2 as /devices/pci0000:00/0000:00:1d.1/usb7/7-2/7-2:1.1/input/input1
sd 0:2:0:0: [sda] 40960000 512-byte hardware sectors: (20.9GB/19.5GiB)
sd 0:2:0:0: [sda] Write Protect is off
sd 0:2:0:0: [sda] Write cache: disabled, read cache: enabled, supports DPO and FUA
sd 0:2:0:0: [sda] 40960000 512-byte hardware sectors: (20.9GB/19.5GiB)
sd 0:2:0:0: [sda] Write Protect is off
sd 0:2:0:0: [sda] Write cache: disabled, read cache: enabled, supports DPO and FUA
sda: sda1
sd 0:2:0:0: [sda] Attached SCSI disk
sd 0:2:1:0: [sdb] 61440000 512-byte hardware sectors: (31.4GB/29.2GiB)
sd 0:2:1:0: [sdb] Write Protect is off
sd 0:2:1:0: [sdb] Write cache: disabled, read cache: enabled, supports DPO and FUA
sd 0:2:1:0: [sdb] 61440000 512-byte hardware sectors: (31.4GB/29.2GiB)
sd 0:2:1:0: [sdb] Write Protect is off
sd 0:2:1:0: [sdb] Write cache: disabled, read cache: enabled, supports DPO and FUA
sdb:<6>input,hidraw1: USB HID v1.10 Mouse [FSC USB2] on usb-0000:00:1d.1-2
usb 7-2: New USB device found, idVendor=0415, idProduct=0624
usb 7-2: New USB device strings: Mfr=2, Product=3, SerialNumber=1
usb 7-2: Product: FSC USB2
usb 7-2: SerialNumber: 234415001B4
sdb1 sdb2
sd 0:2:1:0: [sdb] Attached SCSI disk
sd 0:2:2:0: [sdc] 40960000 512-byte hardware sectors: (20.9GB/19.5GiB)
sd 0:2:2:0: [sdc] Write Protect is off
sd 0:2:2:0: [sdc] Write cache: disabled, read cache: enabled, supports DPO and FUA
sd 0:2:2:0: [sdc] 40960000 512-byte hardware sectors: (20.9GB/19.5GiB)
sd 0:2:2:0: [sdc] Write Protect is off
sd 0:2:2:0: [sdc] Write cache: disabled, read cache: enabled, supports DPO and FUA
sdc: sdc1 sdc2
sd 0:2:2:0: [sdc] Attached SCSI disk
sd 0:2:3:0: [sdd] 40960000 512-byte hardware sectors: (20.9GB/19.5GiB)
sd 0:2:3:0: [sdd] Write Protect is off
sd 0:2:3:0: [sdd] Write cache: disabled, read cache: enabled, supports DPO and FUA
sd 0:2:3:0: [sdd] 40960000 512-byte hardware sectors: (20.9GB/19.5GiB)
sd 0:2:3:0: [sdd] Write Protect is off
sd 0:2:3:0: [sdd] Write cache: disabled, read cache: enabled, supports DPO and FUA
sdd: unknown partition table
sd 0:2:3:0: [sdd] Attached SCSI disk
sd 0:2:4:0: [sde] 40960000 512-byte hardware sectors: (20.9GB/19.5GiB)
sd 0:2:4:0: [sde] Write Protect is off
sd 0:2:4:0: [sde] Write cache: disabled, read cache: enabled, supports DPO and FUA
sd 0:2:4:0: [sde] 40960000 512-byte hardware sectors: (20.9GB/19.5GiB)
sd 0:2:4:0: [sde] Write Protect is off
sd 0:2:4:0: [sde] Write cache: disabled, read cache: enabled, supports DPO and FUA
sde: sde1 < sde5 >
sd 0:2:4:0: [sde] Attached SCSI disk
sd 0:2:5:0: [sdf] 60391424 512-byte hardware sectors: (30.9GB/28.7GiB)
sd 0:2:5:0: [sdf] Write Protect is off
sd 0:2:5:0: [sdf] Write cache: disabled, read cache: enabled, supports DPO and FUA
sd 0:2:5:0: [sdf] 60391424 512-byte hardware sectors: (30.9GB/28.7GiB)
sd 0:2:5:0: [sdf] Write Protect is off
sd 0:2:5:0: [sdf] Write cache: disabled, read cache: enabled, supports DPO and FUA
sdf: sdf1 sdf2
sd 0:2:5:0: [sdf] Attached SCSI disk
Boot logging started on /dev/tty1(/dev/console) at Wed Oct 21 13:48:20 2009
md: raid0 personality registered for level 0
xor: automatically using best checksumming function: generic_sse
generic_sse: 5979.000 MB/sec
xor: using function: generic_sse (5979.000 MB/sec)
async_tx: api initialized (async)
raid6: int64x1 2474 MB/s
raid6: int64x2 3208 MB/s
raid6: int64x4 2509 MB/s
raid6: int64x8 2056 MB/s
raid6: sse2x1 5617 MB/s
raid6: sse2x2 6582 MB/s
raid6: sse2x4 7619 MB/s
raid6: using algorithm sse2x4 (7619 MB/s)
md: raid6 personality registered for level 6
md: raid5 personality registered for level 5
md: raid4 personality registered for level 4
md: md11 stopped.
md: bind<sda1>
raid1: raid set md11 active with 1 out of 2 mirrors
mdadm: /dev/md/11 has been started with 1 drive (out of 2).
Waiting for device /dev/md11 to appear: ok
fsck 1.41.1 (01-Sep-2008)
[/sbin/fsck.ext3 (1) -- /] fsck.ext3 -a -C0 /dev/md11
SQX2KR1: recovering journal
SQX2KR1: clean, 116477/1281120 files, 2913465/5116672 blocks
fsck succeeded. Mounting root device read-write.
Mounting root /dev/md11
mount -o rw,acl,user_xattr -t ext3 /dev/md11 /root
kjournald starting. Commit interval 5 seconds
EXT3 FS on md11, internal journal
EXT3-fs: mounted filesystem with ordered data mode.
Boot logging started on /dev/tty1(/dev/console (deleted)) at Wed Oct 21 15:48:26 2009
Starting udevd: udevd version 128 started
done
Loading drivers, configuring devices: scsi 0:0:4:0: Attached scsi generic sg0 type 13
scsi 0:0:7:0: Attached scsi generic sg1 type 13
sd 0:2:0:0: Attached scsi generic sg2 type 0
sd 0:2:1:0: Attached scsi generic sg3 type 0
sd 0:2:2:0: Attached scsi generic sg4 type 0
sd 0:2:3:0: Attached scsi generic sg5 type 0
sd 0:2:4:0: Attached scsi generic sg6 type 0
sd 0:2:5:0: Attached scsi generic sg7 type 0
scsi 3:0:0:0: Attached scsi generic sg8 type 5
Initializing USB Mass Storage driver...
scsi7 : SCSI emulation for USB Mass Storage devices
scsi8 : SCSI emulation for USB Mass Storage devices
sr0: scsi3-mmc drive: 48x/48x writer dvd-ram cd/rw xa/form2 cdda tray
usbcore: registered new interface driver usb-storage
USB Mass Storage support registered.
Uniform CD-ROM driver Revision: 3.20
Intel(R) Gigabit Ethernet Network Driver - version 1.2.45-k2
Copyright (c) 2008 Intel Corporation.
(XEN) PCI add device 08:00.0
vendor=8086 device=3a40
igb 0000:08:00.0: PCI INT A -> GSI 16 (level, low) -> IRQ 16
input: Power Button (FF) as /devices/LNXSYSTM:00/LNXPWRBN:00/input/input2
igb 0000:08:00.0: Intel(R) Gigabit Ethernet Network Connection
igb 0000:08:00.0: eth0: (PCIe:2.5Gb/s:Width x4) 00:19:99:48:e3:58
igb 0000:08:00.0: eth0: PBA No: 313130-031
igb 0000:08:00.0: Using MSI-X interrupts. 4 rx queue(s), 4 tx queue(s)
(XEN) PCI add device 00:1f.3
(XEN) PCI add device 08:00.1
i801_smbus 0000:00:1f.3: PCI INT B -> GSI 17 (level, low) -> IRQ 17
vendor=8086 device=3a40
igb 0000:08:00.1: PCI INT B -> GSI 17 (level, low) -> IRQ 17
ACPI: Power Button (FF) [PWRF]
input: Power Button (CM) as /devices/LNXSYSTM:00/device:00/PNP0C0C:00/input/input3
ses 0:0:4:0: Attached Enclosure device
ses 0:0:7:0: Attached Enclosure device
input: PC Speaker as /devices/platform/pcspkr/input/input4
igb 0000:08:00.1: Intel(R) Gigabit Ethernet Network Connection
igb 0000:08:00.1: eth1: (PCIe:2.5Gb/s:Width x4) 00:19:99:48:e3:59
igb 0000:08:00.1: eth1: PBA No: 313130-031
igb 0000:08:00.1: Using MSI-X interrupts. 4 rx queue(s), 4 tx queue(s)
ACPI: Power Button (CM) [PWRB]
Serial: 8250/16550 driver8 ports, IRQ sharing disabled
rtc_cmos 00:06: rtc core: registered rtc_cmos as rtc0
rtc0: alarms up to one month, y3k
Serial: 8250/16550 driver8 ports, IRQ sharing disabled
8250_pnp: Unknown symbol serial8250_unregister_port
8250_pnp: Unknown symbol serial8250_resume_port
8250_pnp: Unknown symbol serial8250_register_port
8250_pnp: Unknown symbol serial8250_suspend_port
Serial: 8250/16550 driver8 ports, IRQ sharing disabled
scsi 7:0:0:0: CD-ROM KVM vmDisk-CD 0.01 PQ: 0 ANSI: 0
scsi 8:0:0:0: Direct-Access KVM vmDisk 0.01 PQ: 0 ANSI: 0
sd 8:0:0:0: [sdg] Attached SCSI removable disk
sd 8:0:0:0: Attached scsi generic sg9 type 0
sr1: scsi3-mmc drive: 0x/0x caddy
sr 7:0:0:0: Attached scsi generic sg10 type 5
8250_pnp: gave up waiting for init of module 8250.
8250_pnp: Unknown symbol serial8250_unregister_port
8250_pnp: Unknown symbol serial8250_resume_port
8250_pnp: Unknown symbol serial8250_register_port
8250_pnp: Unknown symbol serial8250_suspend_port
Serial: 8250/16550 driver8 ports, IRQ sharing disabled
8250_pnp: Unknown symbol serial8250_unregister_port
8250_pnp: Unknown symbol serial8250_resume_port
8250_pnp: Unknown symbol serial8250_register_port
8250_pnp: Unknown symbol serial8250_suspend_port
8250_pnp: Unknown symbol serial8250_unregister_port
8250_pnp: Unknown symbol serial8250_resume_port
8250_pnp: Unknown symbol serial8250_register_port
8250_pnp: Unknown symbol serial8250_suspend_port
done
Loading required kernel modules
init_xsd: xsd driver entry point
Activating swap-devices in /etc/fstab... done
Adding 19531208k swap on /dev/sdb1. Priority:-1 extents:1 across:19531208k
Setting up the system clockSetting up timezone data done
done
device-mapper: uevent: version 1.0.3
device-mapper: ioctl: 4.14.0-ioctl (2008-04-23) initialised: dm-devel@redhat.com
Activating device mapper...
done
Starting MD Raid md: md12 stopped.
md: bind<sdc1>
raid1: raid set md12 active with 1 out of 2 mirrors
mdadm: /dev/md/12 has been started with 1 drive (out of 2).
md: md13 stopped.
md: bind<sdc2>
raid1: raid set md13 active with 1 out of 2 mirrors
mdadm: /dev/md/13 has been started with 1 drive (out of 2).
[-- Attachment #3: xen-unstable-log.txt --]
[-- Type: text/plain, Size: 36525 bytes --]
\ \/ /___ _ __ |___ / | ___| _ _ _ __ ___| |_ __ _| |__ | | ___ |
\ // _ \ '_ \ |_ \ |___ \ __| | | | '_ \/ __| __/ _` | '_ \| |/ _ \
/ \ __/ | | | ___) | ___) |__| |_| | | | \__ \ || (_| | |_) | | __/
/_/\_\___|_| |_| |____(_)____/ \__,_|_| |_|___/\__\__,_|_.__/|_|\___|
(XEN) Xen version 3.5-unstable (hahn@mch.fsc.net) (gcc version 4.3.2 [gcc-4_3-branch revision 141291] (SUSE Linux) ) Thu Oct 22 07:50:08 CEST 2009
(XEN) Latest ChangeSet: Wed Oct 21 16:08:28 2009 +0100 20354:37829fd7c1e3
(XEN) Console output is synchronous.
(XEN) Command line: console=com1 com1=38400 msi=0 sync_console debug=yes guest_loglvl=all loglvl=all dom0_mem=3546M
(XEN) Video information:
(XEN) VGA is text mode 80x25, font 8x16
(XEN) VBE/DDC methods: V2; EDID transfer time: 1 seconds
(XEN) Disc information:
(XEN) Found 6 MBR signatures
(XEN) Found 6 EDD information structures
(XEN) Xen-e820 RAM map:
(XEN) 0000000000000000 - 000000000009cc00 (usable)
(XEN) 000000000009cc00 - 00000000000a0000 (reserved)
(XEN) 00000000000e4000 - 0000000000100000 (reserved)
(XEN) 0000000000100000 - 00000000bf7c0000 (usable)
(XEN) 00000000bf7c0000 - 00000000bf7cb000 (ACPI data)
(XEN) 00000000bf7cb000 - 00000000bf7cc000 (ACPI NVS)
(XEN) 00000000bf7cc000 - 00000000c0000000 (reserved)
(XEN) 00000000e0000000 - 00000000f0000000 (reserved)
(XEN) 00000000fec00000 - 00000000fed00000 (reserved)
(XEN) 00000000fee00000 - 00000000fee01000 (reserved)
(XEN) 00000000ffa80000 - 0000000100000000 (reserved)
(XEN) 0000000100000000 - 0000000340000000 (usable)
(XEN) ACPI: RSDP 000F80F0, 0024 (r2 PTLTD )
(XEN) ACPI: XSDT BF7C53B0, 00D4 (r1 PTLTD XSDT 60000 LTP 0)
(XEN) ACPI: FACP BF7C9BE1, 00F4 (r3 FSC TYLERBRG 60000 PTL F4240)
(XEN) ACPI: DSDT BF7C5484, 46D9 (r1 FSC D2619 60000 MSFT 3000001)
(XEN) ACPI: FACS BF7CBFC0, 0040
(XEN) ACPI: TCPA BF7C9CD5, 0032 (r1 Phoeni x 60000 TL 0)
(XEN) ACPI: SLIT BF7C9D07, 0030 (r1 FSC 60000 5A)
(XEN) ACPI: EINJ BF7C9D37, 01B0 (r1 PTL WHEAPTL 60000 PTL 1)
(XEN) ACPI: HEST BF7C9EE7, 0268 (r1 PTL WHEAPTL 60000 PTL 1)
(XEN) ACPI: BERT BF7CA14F, 0030 (r1 PTL WHEAPTL 60000 PTL 1)
(XEN) ACPI: SSDT BF7CA17F, 00E1 (r1 wheaos wheaosc 60000 INTL 20050624)
(XEN) ACPI: ERST BF7CA260, 0270 (r1 PTL WHEAPTL 60000 PTL 1)
(XEN) ACPI: SSDT BF7CA4D0, 00D8 (r1 FSC CST_PR00 60000 CSF 1)
(XEN) ACPI: SSDT BF7CA5A8, 00D8 (r1 FSC CST_PR02 60000 CSF 1)
(XEN) ACPI: SSDT BF7CA680, 00D8 (r1 FSC CST_PR04 60000 CSF 1)
(XEN) ACPI: SSDT BF7CA758, 00D8 (r1 FSC CST_PR06 60000 CSF 1)
(XEN) ACPI: SSDT BF7CA830, 015B (r1 FSC PST_PR00 60000 CSF 1)
(XEN) ACPI: SSDT BF7CA98B, 015B (r1 FSC PST_PR02 60000 CSF 1)
(XEN) ACPI: SSDT BF7CAAE6, 015B (r1 FSC PST_PR04 60000 CSF 1)
(XEN) ACPI: SSDT BF7CAC41, 015B (r1 FSC PST_PR06 60000 CSF 1)
(XEN) ACPI: SPCR BF7CAD9C, 0050 (r1 PTLTD $UCRTBL$ 60000 PTL 1)
(XEN) ACPI: DMAR BF7CADEC, 00E8 (r1 Intel OEMDMAR 60000 LOHR 1)
(XEN) ACPI: MCFG BF7CAED4, 003C (r1 PTLTD MCFG 60000 LTP 0)
(XEN) ACPI: HPET BF7CAF10, 0038 (r1 PTLTD HPETTBL 60000 LTP 1)
(XEN) ACPI: APIC BF7CAF48, 0090 (r1 PTLTD APIC 60000 LTP 0)
(XEN) ACPI: BOOT BF7CAFD8, 0028 (r1 PTLTD $SBFTBL$ 60000 LTP 1)
(XEN) System RAM: 12257MB (12551560kB)
(XEN) NUMA turned off
(XEN) Faking a node at 0000000000000000-0000000340000000
(XEN) Domain heap initialised
(XEN) found SMP MP-table at 000f8120
(XEN) DMI present.
(XEN) Using APIC driver default
(XEN) ACPI: PM-Timer IO Port: 0x1008
(XEN) ACPI: ACPI SLEEP INFO: pm1x_cnt[1004,0], pm1x_evt[1000,0]
(XEN) ACPI: wakeup_vec[bf7cbfcc], vec_size[20]
(XEN) ACPI: Local APIC address 0xfee00000
(XEN) ACPI: LAPIC (acpi_id[0x00] lapic_id[0x00] enabled)
(XEN) Processor #0 7:10 APIC version 21
(XEN) ACPI: LAPIC (acpi_id[0x01] lapic_id[0x02] enabled)
(XEN) Processor #2 7:10 APIC version 21
(XEN) ACPI: LAPIC (acpi_id[0x02] lapic_id[0x04] enabled)
(XEN) Processor #4 7:10 APIC version 21
(XEN) ACPI: LAPIC (acpi_id[0x03] lapic_id[0x06] enabled)
(XEN) Processor #6 7:10 APIC version 21
(XEN) ACPI: LAPIC_NMI (acpi_id[0x00] high edge lint[0x1])
(XEN) ACPI: LAPIC_NMI (acpi_id[0x01] high edge lint[0x1])
(XEN) ACPI: LAPIC_NMI (acpi_id[0x02] high edge lint[0x1])
(XEN) ACPI: LAPIC_NMI (acpi_id[0x03] high edge lint[0x1])
(XEN) ACPI: IOAPIC (id[0x01] address[0xfec00000] gsi_base[0])
(XEN) IOAPIC[0]: apic_id 1, version 32, address 0xfec00000, GSI 0-23
(XEN) ACPI: IOAPIC (id[0x03] address[0xfec80000] gsi_base[24])
(XEN) IOAPIC[1]: apic_id 3, version 32, address 0xfec80000, GSI 24-47
(XEN) ACPI: INT_SRC_OVR (bus 0 bus_irq 0 global_irq 2 high edge)
(XEN) ACPI: INT_SRC_OVR (bus 0 bus_irq 9 global_irq 9 high level)
(XEN) ACPI: IRQ0 used by override.
(XEN) ACPI: IRQ2 used by override.
(XEN) ACPI: IRQ9 used by override.
(XEN) Enabling APIC mode: Flat. Using 2 I/O APICs
(XEN) ACPI: HPET id: 0x8086a301 base: 0xfed00000
(XEN) PCI: MCFG configuration 0: base e0000000 segment 0 buses 0 - 10
(XEN) PCI: MCFG area at e0000000 reserved in E820
(XEN) Using ACPI (MADT) for SMP configuration information
(XEN) Using scheduler: SMP Credit Scheduler (credit)
(XEN) Initializing CPU#0
(XEN) Detected 2266.792 MHz processor.
(XEN) CPU: L1 I cache: 32K, L1 D cache: 32K
(XEN) CPU: L2 cache: 256K
(XEN) CPU: L3 cache: 8192K
(XEN) CPU: Physical Processor ID: 0
(XEN) CPU: Processor Core ID: 0
(XEN) VMX: Supported advanced features:
(XEN) - APIC MMIO access virtualisation
(XEN) - APIC TPR shadow
(XEN) - Extended Page Tables (EPT)
(XEN) - Virtual-Processor Identifiers (VPID)
(XEN) - Virtual NMI
(XEN) - MSR direct-access bitmap
(XEN) HVM: VMX enabled
(XEN) HVM: Hardware Assisted Paging detected.
(XEN) Intel machine check reporting enabled on CPU#0.
(XEN) CPU0: Thermal monitoring enabled (TM1)
(XEN) I/O virtualisation disabled
(XEN) CPU0: Intel(R) Xeon(R) CPU E5520 @ 2.27GHz stepping 05
(XEN) Booting processor 1/2 eip 8c000
(XEN) Initializing CPU#1
(XEN) CPU: L1 I cache: 32K, L1 D cache: 32K
(XEN) CPU: L2 cache: 256K
(XEN) CPU: L3 cache: 8192K
(XEN) CPU: Physical Processor ID: 0
(XEN) CPU: Processor Core ID: 1
(XEN) Intel machine check reporting enabled on CPU#1.
(XEN) CPU1: Thermal monitoring enabled (TM1)
(XEN) CPU1: Intel(R) Xeon(R) CPU E5520 @ 2.27GHz stepping 05
(XEN) Booting processor 2/4 eip 8c000
(XEN) Initializing CPU#2
(XEN) CPU: L1 I cache: 32K, L1 D cache: 32K
(XEN) CPU: L2 cache: 256K
(XEN) CPU: L3 cache: 8192K
(XEN) CPU: Physical Processor ID: 0
(XEN) CPU: Processor Core ID: 2
(XEN) Intel machine check reporting enabled on CPU#2.
(XEN) CPU2: Thermal monitoring enabled (TM1)
(XEN) CPU2: Intel(R) Xeon(R) CPU E5520 @ 2.27GHz stepping 05
(XEN) Booting processor 3/6 eip 8c000
(XEN) Initializing CPU#3
(XEN) CPU: L1 I cache: 32K, L1 D cache: 32K
(XEN) CPU: L2 cache: 256K
(XEN) CPU: L3 cache: 8192K
(XEN) CPU: Physical Processor ID: 0
(XEN) CPU: Processor Core ID: 3
(XEN) Intel machine check reporting enabled on CPU#3.
(XEN) CPU3: Thermal monitoring enabled (TM1)
(XEN) CPU3: Intel(R) Xeon(R) CPU E5520 @ 2.27GHz stepping 05
(XEN) Total of 4 processors activated.
(XEN) ENABLING IO-APIC IRQs
(XEN) -> Using new ACK method
(XEN) ..TIMER: vector=0xF0 apic1=0 pin1=2 apic2=-1 pin2=-1
(XEN) TSC is reliable, synchronization unnecessary
(XEN) Platform timer is 14.318MHz HPET
(XEN) microcode.c:73:d32767 microcode: CPU1 resumed
(XEN) microcode.c:73:d32767 microcode: CPU2 resumed
(XEN) microcode.c:73:d32767 microcode: CPU3 resumed
(XEN) Brought up 4 CPUs
(XEN) HPET: 4 timers in total, 0 timers will be used for broadcast
(XEN) ACPI sleep modes: S3
(XEN) mcheck_poll: Machine check polling timer started.
(XEN) *** LOADING DOMAIN 0 ***
(XEN) elf_parse_binary: phdr: paddr=0x200000 memsz=0x459000
(XEN) elf_parse_binary: phdr: paddr=0x659000 memsz=0xad1c8
(XEN) elf_parse_binary: phdr: paddr=0x707000 memsz=0x888
(XEN) elf_parse_binary: phdr: paddr=0x708000 memsz=0x1250b8
(XEN) elf_parse_binary: memory: 0x200000 -> 0x82d0b8
(XEN) elf_xen_parse_note: GUEST_OS = "linux"
(XEN) elf_xen_parse_note: GUEST_VERSION = "2.6"
(XEN) elf_xen_parse_note: XEN_VERSION = "xen-3.0"
(XEN) elf_xen_parse_note: VIRT_BASE = 0xffffffff80000000
(XEN) elf_xen_parse_note: PADDR_OFFSET = 0x0
(XEN) elf_xen_parse_note: ENTRY = 0xffffffff80200000
(XEN) elf_xen_parse_note: HYPERCALL_PAGE = 0xffffffff80207000
(XEN) elf_xen_parse_note: unknown xen elf note (0xd)
(XEN) elf_xen_parse_note: FEATURES = "writable_page_tables|writable_descriptor_tables|auto_translated_physmap|pae_pgdir_above_4gb|supervisor_mode_kernel"
(XEN) elf_xen_parse_note: LOADER = "generic"
(XEN) elf_xen_parse_note: SUSPEND_CANCEL = 0x1
(XEN) elf_xen_addr_calc_check: addresses:
(XEN) virt_base = 0xffffffff80000000
(XEN) elf_paddr_offset = 0x0
(XEN) virt_offset = 0xffffffff80000000
(XEN) virt_kstart = 0xffffffff80200000
(XEN) virt_kend = 0xffffffff8082d0b8
(XEN) virt_entry = 0xffffffff80200000
(XEN) p2m_base = 0xffffffffffffffff
(XEN) Xen kernel: 64-bit, lsb, compat32
(XEN) Dom0 kernel: 64-bit, lsb, paddr 0x200000 -> 0x82d0b8
(XEN) PHYSICAL MEMORY ARRANGEMENT:
(XEN) Dom0 alloc.: 0000000334000000->0000000336000000 (899584 pages to be allocated)
(XEN) VIRTUAL MEMORY ARRANGEMENT:
(XEN) Loaded kernel: ffffffff80200000->ffffffff8082d0b8
(XEN) Init. ramdisk: ffffffff8082e000->ffffffff81209400
(XEN) Phys-Mach map: ffffffff8120a000->ffffffff818f7000
(XEN) Start info: ffffffff818f7000->ffffffff818f74b4
(XEN) Page tables: ffffffff818f8000->ffffffff81909000
(XEN) Boot stack: ffffffff81909000->ffffffff8190a000
(XEN) TOTAL: ffffffff80000000->ffffffff81c00000
(XEN) ENTRY ADDRESS: ffffffff80200000
(XEN) Dom0 has maximum 4 VCPUs
(XEN) elf_load_binary: phdr 0 at 0xffffffff80200000 -> 0xffffffff80659000
(XEN) elf_load_binary: phdr 1 at 0xffffffff80659000 -> 0xffffffff807061c8
(XEN) elf_load_binary: phdr 2 at 0xffffffff80707000 -> 0xffffffff80707888
(XEN) elf_load_binary: phdr 3 at 0xffffffff80708000 -> 0xffffffff807566a0
(XEN) Scrubbing Free RAM: ......................................................................................done.
(XEN) Xen trace buffers: disabled
(XEN) Std. Loglevel: All
(XEN) Guest Loglevel: All
(XEN) **********************************************
(XEN) ******* WARNING: CONSOLE OUTPUT IS SYNCHRONOUS
(XEN) ******* This option is intended to aid debugging of Xen by ensuring
(XEN) ******* that all output is synchronously delivered on the serial line.
(XEN) ******* However it can introduce SIGNIFICANT latencies and affect
(XEN) ******* timekeeping. It is NOT recommended for production use!
(XEN) **********************************************
(XEN) 3... 2... 1...
(XEN) *** Serial input -> DOM0 (type 'CTRL-a' three times to switch input to Xen)
(XEN) Freed 148kB init memory.
Kernel alive
Kernel really alive
Initializing cgroup subsys cpuset
Initializing cgroup subsys cpu
Linux version 2.6.27.19-5-xen (geeko@buildhost) (gcc version 4.3.2 [gcc-4_3-branch revision 141291] (SUSE Linux) ) #1 SMP 2009-02-28 04:40:21 +0100
Command line: root=/dev/md11 splash=silent showopts vga=0x314 console=ttyS0,38400,8n1 console=tty0 xencons=ttyS0
KERNEL supported cpus:
Intel GenuineIntel
AMD AuthenticAMD
Centaur CentaurHauls
Xen-provided physical RAM map:
Xen: 0000000000000000 - 00000000de200000 (usable)
DMI present.
last_pfn = 0xde200 max_arch_pfn = 0x6ffffff
init_memory_mapping
last_map_addr: de200000 end: de200000
RAMDISK: 0082e000 - 01209400
ACPI: RSDP 000F80F0, 0024 (r2 PTLTD )
ACPI: XSDT BF7C53B0, 00D4 (r1 PTLTD XSDT 60000 LTP 0)
ACPI: FACP BF7C9BE1, 00F4 (r3 FSC TYLERBRG 60000 PTL F4240)
ACPI: DSDT BF7C5484, 46D9 (r1 FSC D2619 60000 MSFT 3000001)
ACPI: FACS BF7CBFC0, 0040
ACPI: TCPA BF7C9CD5, 0032 (r1 Phoeni x 60000 TL 0)
ACPI: SLIT BF7C9D07, 0030 (r1 FSC 60000 5A)
ACPI: EINJ BF7C9D37, 01B0 (r1 PTL WHEAPTL 60000 PTL 1)
ACPI: HEST BF7C9EE7, 0268 (r1 PTL WHEAPTL 60000 PTL 1)
ACPI: BERT BF7CA14F, 0030 (r1 PTL WHEAPTL 60000 PTL 1)
ACPI: SSDT BF7CA17F, 00E1 (r1 wheaos wheaosc 60000 INTL 20050624)
ACPI: ERST BF7CA260, 0270 (r1 PTL WHEAPTL 60000 PTL 1)
ACPI: SSDT BF7CA4D0, 00D8 (r1 FSC CST_PR00 60000 CSF 1)
ACPI: SSDT BF7CA5A8, 00D8 (r1 FSC CST_PR02 60000 CSF 1)
ACPI: SSDT BF7CA680, 00D8 (r1 FSC CST_PR04 60000 CSF 1)
ACPI: SSDT BF7CA758, 00D8 (r1 FSC CST_PR06 60000 CSF 1)
ACPI: SSDT BF7CA830, 015B (r1 FSC PST_PR00 60000 CSF 1)
ACPI: SSDT BF7CA98B, 015B (r1 FSC PST_PR02 60000 CSF 1)
ACPI: SSDT BF7CAAE6, 015B (r1 FSC PST_PR04 60000 CSF 1)
ACPI: SSDT BF7CAC41, 015B (r1 FSC PST_PR06 60000 CSF 1)
ACPI: SPCR BF7CAD9C, 0050 (r1 PTLTD $UCRTBL$ 60000 PTL 1)
ACPI: BF7CADEC, 00E8 (r1 Intel OEMDMAR 60000 LOHR 1)
ACPI: MCFG BF7CAED4, 003C (r1 PTLTD MCFG 60000 LTP 0)
ACPI: HPET BF7CAF10, 0038 (r1 PTLTD HPETTBL 60000 LTP 1)
ACPI: APIC BF7CAF48, 0090 (r1 PTLTD APIC 60000 LTP 0)
ACPI: BOOT BF7CAFD8, 0028 (r1 PTLTD $SBFTBL$ 60000 LTP 1)
(4 early reservations) ==> bootmem [0000000000 - 00dda00000]
#0 [0000200000 - 000082d0b8] TEXT DATA BSS ==> [0000200000 - 000082d0b8]
#1 [000082e000 - 0001909000] Xen provided ==> [000082e000 - 0001909000]
#2 [0001909000 - 000190c000] INITMAP ==> [0001909000 - 000190c000]
#3 [000190c000 - 0002002000] PGTABLE ==> [000190c000 - 0002002000]
found SMP MP-table at [ffffffffff5f0120] 000f8120
Zone PFN ranges:
DMA 0x00000000 -> 0x00001000
DMA32 0x00001000 -> 0x00100000
Normal 0x00100000 -> 0x00100000
Movable zone start PFN for each node
early_node_map[1] active PFN ranges
0: 0x00000000 -> 0x000de200
ACPI: LAPIC (acpi_id[0x00] lapic_id[0x00] enabled)
ACPI: LAPIC (acpi_id[0x01] lapic_id[0x02] enabled)
ACPI: LAPIC (acpi_id[0x02] lapic_id[0x04] enabled)
ACPI: LAPIC (acpi_id[0x03] lapic_id[0x06] enabled)
ACPI: LAPIC_NMI (acpi_id[0x00] high edge lint[0x1])
ACPI: LAPIC_NMI (acpi_id[0x01] high edge lint[0x1])
ACPI: LAPIC_NMI (acpi_id[0x02] high edge lint[0x1])
ACPI: LAPIC_NMI (acpi_id[0x03] high edge lint[0x1])
ACPI: IOAPIC (id[0x01] address[0xfec00000] gsi_base[0])
IOAPIC[0]: apic_id 1, version 0, address 0xfec00000, GSI 0-23
ACPI: IOAPIC (id[0x03] address[0xfec80000] gsi_base[24])
IOAPIC[1]: apic_id 3, version 0, address 0xfec80000, GSI 24-47
ACPI: INT_SRC_OVR (bus 0 bus_irq 0 global_irq 2 high edge)
ACPI: INT_SRC_OVR (bus 0 bus_irq 9 global_irq 9 high level)
Using ACPI (MADT) for SMP configuration information
Allocating PCI resources starting at c2000000 (gap: c0000000:20000000)
PERCPU: Allocating 50848 bytes of per cpu data
Built 1 zonelists in Zone order, mobility grouping on. Total pages: 895608
Kernel command line: root=/dev/md11 splash=silent showopts vga=0x314 console=ttyS0,38400,8n1 console=tty0 xencons=ttyS0
bootsplash: silent mode.
Initializing CPU#0
PID hash table entries: 4096 (order: 12, 32768 bytes)
Extended CMOS year: 2000
Xen reported: 2266.792 MHz processor.
Console: colour VGA+ 80x25
console [tty0] enabled
console [ttyS0] enabled
Dentry cache hash table entries: 524288 (order: 10, 4194304 bytes)
Inode-cache hash table entries: 262144 (order: 9, 2097152 bytes)
Software IO TLB enabled:
Aperture: 64 megabytes
Kernel range: ffff880005e9f000 - ffff880009e9f000
Address size: 27 bits
PCI-DMA: Using software bounce buffering for IO (SWIOTLB)
Memory: 3469944k/3639296k available (2483k kernel code, 160452k reserved, 2190k data, 284k init)
Calibrating delay using timer specific routine.. 4535.50 BogoMIPS (lpj=9071010)
Security Framework initialized
AppArmor: AppArmor initialized
Mount-cache hash table entries: 256
Initializing cgroup subsys ns
Initializing cgroup subsys cpuacct
Initializing cgroup subsys memory
Initializing cgroup subsys devices
Initializing cgroup subsys freezer
CPU: L1 I cache: 32K, L1 D cache: 32K
CPU: L2 cache: 256K
CPU: L3 cache: 8192K
CPU: Physical Processor ID: 0
CPU: Processor Core ID: 0
SMP alternatives: switching to UP code
ACPI: Core revision 20080609
Parsing all Control Methods:
Table [DSDT](id 0001) - 563 Objects with 64 Devices 124 Methods 34 Regions
Parsing all Control Methods:
Table [SSDT](id 0002) - 8 Objects with 0 Devices 1 Methods 2 Regions
Parsing all Control Methods:
Table [SSDT](id 0003) - 2 Objects with 0 Devices 0 Methods 0 Regions
Parsing all Control Methods:
Table [SSDT](id 0004) - 2 Objects with 0 Devices 0 Methods 0 Regions
Parsing all Control Methods:
Table [SSDT](id 0005) - 2 Objects with 0 Devices 0 Methods 0 Regions
Parsing all Control Methods:
Table [SSDT](id 0006) - 2 Objects with 0 Devices 0 Methods 0 Regions
Parsing all Control Methods:
Table [SSDT](id 0007) - 3 Objects with 0 Devices 0 Methods 0 Regions
Parsing all Control Methods:
Table [SSDT](id 0008) - 3 Objects with 0 Devices 0 Methods 0 Regions
Parsing all Control Methods:
Table [SSDT](id 0009) - 3 Objects with 0 Devices 0 Methods 0 Regions
Parsing all Control Methods:
Table [SSDT](id 000A) - 3 Objects with 0 Devices 0 Methods 0 Regions
tbxface-0596 [00] tb_load_namespace : ACPI Tables successfully acquired
evxfevnt-0091 [00] enable : Transition to ACPI mode successful
(XEN) io_apic.c:2208:
(XEN) ioapic_guest_write: apic=0, pin=2, irq=0
(XEN) ioapic_guest_write: new_entry=00000900
(XEN) ioapic_guest_write: Attempt to modify IO-APIC pin for in-use IRQ!
(XEN) io_apic.c:2208:
(XEN) ioapic_guest_write: apic=0, pin=4, irq=4
(XEN) ioapic_guest_write: new_entry=00000904
(XEN) ioapic_guest_write: Attempt to modify IO-APIC pin for in-use IRQ!
SMP alternatives: switching to SMP code
Initializing CPU#1
Initializing CPU#2
CPU: L1 I cache: 32K, L1 D cache: 32K
CPU: L2 cache: 256K
CPU: L3 cache: 8192K
CPU: Physical Processor ID: 0
CPU: Processor Core ID: 2
Brought up 4 CPUs
Initializing CPU#3
CPU: L1 I cache: 32K, L1 D cache: 32K
CPU: L2 cache: 256K
CPU: L3 cache: 8192K
CPU: Physical Processor ID: 0
CPU: Processor Core ID: 3
net_namespace: 1936 bytes
CPU: L1 I cache: 32K, L1 D cache: 32K
CPU: L2 cache: 256K
CPU: L3 cache: 8192K
CPU: Physical Processor ID: 0
CPU: Processor Core ID: 1
NET: Registered protocol family 16
ACPI FADT declares the system doesn't support PCIe ASPM, so disable it
ACPI: bus type pci registered
PCI: MCFG configuration 0: base e0000000 segment 0 buses 0 - 10
PCI: MCFG area at e0000000 reserved in E820
PCI: Using MMCONFIG at e0000000 - e0afffff
PCI: Using configuration type 1 for base access
evgpeblk-0957 [00] ev_create_gpe_block : GPE 00 to 3F [_GPE] 8 regs on int 0x9
Completing Region/Field/Buffer/Package initialization:..................................................................................................
Initialized 31/36 Regions 0/0 Fields 24/24 Buffers 43/43 Packages (600 nodes)
Initializing Device/Processor/Thermal objects by executing _INI methods:.............
Executed 13 _INI methods requiring 13 _STA executions (examined 82 objects)
evgpeblk-1054 [00] ev_initialize_gpe_bloc: Found 9 Wake, Enabled 1 Runtime GPEs in this block
ACPI: Interpreter enabled
ACPI: (supports S0 S1 S5)
ACPI: Using IOAPIC for interrupt routing
ACPI: PCI Root Bridge [CPU0] (0000:ff)
ACPI: PCI Root Bridge [CPU1] (0000:fe)
ACPI: PCI Root Bridge [PCI0] (0000:00)
pci 0000:00:00.0: PME# supported from D0 D3hot D3cold
pci 0000:00:00.0: PME# disabled
pci 0000:00:01.0: PME# supported from D0 D3hot D3cold
pci 0000:00:01.0: PME# disabled
pci 0000:00:03.0: PME# supported from D0 D3hot D3cold
pci 0000:00:03.0: PME# disabled
pci 0000:00:05.0: PME# supported from D0 D3hot D3cold
pci 0000:00:05.0: PME# disabled
pci 0000:00:07.0: PME# supported from D0 D3hot D3cold
pci 0000:00:07.0: PME# disabled
pci 0000:00:08.0: PME# supported from D0 D3hot D3cold
pci 0000:00:08.0: PME# disabled
pci 0000:00:09.0: PME# supported from D0 D3hot D3cold
pci 0000:00:09.0: PME# disabled
pci 0000:00:0a.0: PME# supported from D0 D3hot D3cold
pci 0000:00:0a.0: PME# disabled
pci 0000:00:1a.7: PME# supported from D0 D3hot D3cold
pci 0000:00:1a.7: PME# disabled
pci 0000:00:1c.0: PME# supported from D0 D3hot D3cold
pci 0000:00:1c.0: PME# disabled
pci 0000:00:1c.4: PME# supported from D0 D3hot D3cold
pci 0000:00:1c.4: PME# disabled
pci 0000:00:1d.7: PME# supported from D0 D3hot D3cold
pci 0000:00:1d.7: PME# disabled
pci 0000:08:00.0: PME# supported from D0 D3hot D3cold
pci 0000:08:00.0: PME# disabled
pci 0000:08:00.1: PME# supported from D0 D3hot D3cold
pci 0000:08:00.1: PME# disabled
pci 0000:00:1e.0: transparent bridge
ACPI: PCI Interrupt Link [LNKA] (IRQs 3 4 5 6 7 9 10 *11 12 14 15)
ACPI: PCI Interrupt Link [LNKB] (IRQs 3 4 5 6 7 9 10 *11 12 14 15)
ACPI: PCI Interrupt Link [LNKC] (IRQs 3 4 5 6 7 *9 10 11 12 14 15)
ACPI: PCI Interrupt Link [LNKD] (IRQs 3 4 5 6 7 9 *10 11 12 14 15)
ACPI: PCI Interrupt Link [LNKE] (IRQs 3 4 5 6 7 9 10 11 12 14 15) *0, disabled.
ACPI: PCI Interrupt Link [LNKF] (IRQs 3 4 5 6 7 9 10 *11 12 14 15)
ACPI: PCI Interrupt Link [LNKG] (IRQs 3 4 5 6 7 9 10 *11 12 14 15)
ACPI: PCI Interrupt Link [LNKH] (IRQs 3 4 *5 6 7 9 10 11 12 14 15)
ACPI Warning (tbutils-0217): Incorrect checksum in table [ ] - 41, should be 85 [20080609]
Linux Plug and Play Support v0.97 (c) Adam Belay
pnp: PnP ACPI init
ACPI: bus type pnp registered
(XEN) io_apic.c:2208:
(XEN) ioapic_guest_write: apic=0, pin=4, irq=4
(XEN) ioapic_guest_write: new_entry=00000904
(XEN) ioapic_guest_write: Attempt to modify IO-APIC pin for in-use IRQ!
pnp: PnP ACPI: found 13 devices
ACPI: ACPI bus type pnp unregistered
xen_mem: Initialising balloon driver.
PCI: Using ACPI for IRQ routing
AppArmor: AppArmor Filesystem Enabled
ACPI: RTC can wake from S4
system 00:00: iomem range 0xe0000000-0xefffffff could not be reserved
system 00:04: ioport range 0x200-0x20f has been reserved
system 00:04: ioport range 0x4d0-0x4d1 has been reserved
system 00:04: ioport range 0x500-0x57f has been reserved
system 00:04: ioport range 0x800-0x80f has been reserved
system 00:04: ioport range 0x810-0x81f has been reserved
system 00:04: ioport range 0xca0-0xca1 has been reserved
system 00:04: ioport range 0xca4-0xca7 has been reserved
system 00:04: ioport range 0xca8-0xcab has been reserved
system 00:04: ioport range 0xcae-0xcaf has been reserved
system 00:04: ioport range 0xe00-0xe7f has been reserved
system 00:04: ioport range 0x1000-0x107f has been reserved
system 00:04: ioport range 0x1100-0x110f has been reserved
system 00:04: ioport range 0x1180-0x11ff has been reserved
system 00:04: ioport range 0xfe00-0xfe00 has been reserved
system 00:04: ioport range 0xff00-0xff00 has been reserved
system 00:04: iomem range 0xfec00000-0xfecfffff could not be reserved
system 00:04: iomem range 0xfee00000-0xfeefffff could not be reserved
system 00:04: iomem range 0xfed1c000-0xfed1ffff has been reserved
pci 0000:00:01.0: PCI bridge, secondary bus 0000:01
pci 0000:00:01.0: IO window: 0x2000-0x2fff
pci 0000:00:01.0: MEM window: 0xce100000-0xce1fffff
pci 0000:00:01.0: PREFETCH window: 0x000000c2000000-0x000000c20fffff
pci 0000:00:03.0: PCI bridge, secondary bus 0000:02
pci 0000:00:03.0: IO window: 0x3000-0x3fff
pci 0000:00:03.0: MEM window: 0xce200000-0xce2fffff
pci 0000:00:03.0: PREFETCH window: 0x000000c2100000-0x000000c21fffff
pci 0000:00:05.0: PCI bridge, secondary bus 0000:03
pci 0000:00:05.0: IO window: disabled
pci 0000:00:05.0: MEM window: disabled
pci 0000:00:05.0: PREFETCH window: disabled
pci 0000:00:07.0: PCI bridge, secondary bus 0000:04
pci 0000:00:07.0: IO window: disabled
pci 0000:00:07.0: MEM window: disabled
pci 0000:00:07.0: PREFETCH window: disabled
pci 0000:00:08.0: PCI bridge, secondary bus 0000:05
pci 0000:00:08.0: IO window: disabled
pci 0000:00:08.0: MEM window: disabled
pci 0000:00:08.0: PREFETCH window: disabled
pci 0000:00:09.0: PCI bridge, secondary bus 0000:06
pci 0000:00:09.0: IO window: disabled
pci 0000:00:09.0: MEM window: disabled
pci 0000:00:09.0: PREFETCH window: disabled
pci 0000:00:0a.0: PCI bridge, secondary bus 0000:07
pci 0000:00:0a.0: IO window: disabled
pci 0000:00:0a.0: MEM window: disabled
pci 0000:00:0a.0: PREFETCH window: disabled
pci 0000:00:1c.0: PCI bridge, secondary bus 0000:08
pci 0000:00:1c.0: IO window: 0x4000-0x4fff
pci 0000:00:1c.0: MEM window: 0xce300000-0xce3fffff
pci 0000:00:1c.0: PREFETCH window: 0x000000c2200000-0x000000c22fffff
pci 0000:00:1c.4: PCI bridge, secondary bus 0000:09
pci 0000:00:1c.4: IO window: disabled
pci 0000:00:1c.4: MEM window: 0xce400000-0xceffffff
pci 0000:00:1c.4: PREFETCH window: 0x000000cf000000-0x000000cfffffff
pci 0000:00:1e.0: PCI bridge, secondary bus 0000:0a
pci 0000:00:1e.0: IO window: disabled
pci 0000:00:1e.0: MEM window: disabled
pci 0000:00:1e.0: PREFETCH window: disabled
(XEN) allocated vector for irq:28
pci 0000:00:01.0: PCI INT A -> GSI 28 (level, low) -> IRQ 28
(XEN) allocated vector for irq:24
pci 0000:00:03.0: PCI INT A -> GSI 24 (level, low) -> IRQ 24
(XEN) allocated vector for irq:26
pci 0000:00:05.0: PCI INT A -> GSI 26 (level, low) -> IRQ 26
(XEN) allocated vector for irq:30
pci 0000:00:07.0: PCI INT A -> GSI 30 (level, low) -> IRQ 30
(XEN) allocated vector for irq:31
pci 0000:00:08.0: PCI INT A -> GSI 31 (level, low) -> IRQ 31
(XEN) allocated vector for irq:32
pci 0000:00:09.0: PCI INT A -> GSI 32 (level, low) -> IRQ 32
(XEN) allocated vector for irq:33
pci 0000:00:0a.0: PCI INT A -> GSI 33 (level, low) -> IRQ 33
(XEN) allocated vector for irq:16
pci 0000:00:1c.0: PCI INT A -> GSI 16 (level, low) -> IRQ 16
pci 0000:00:1c.4: PCI INT A -> GSI 16 (level, low) -> IRQ 16
bus: ff index 0 io port: [0, ffff]
bus: ff index 1 mmio: [0, ffffffffffffffff]
bus: fe index 0 io port: [0, ffff]
bus: fe index 1 mmio: [0, ffffffffffffffff]
bus: 00 index 0 io port: [0, ffff]
bus: 00 index 1 mmio: [0, ffffffffffffffff]
bus: 01 index 0 io port: [2000, 2fff]
bus: 01 index 1 mmio: [ce100000, ce1fffff]
bus: 01 index 2 mmio: [c2000000, c20fffff]
bus: 01 index 3 mmio: [0, 0]
bus: 02 index 0 io port: [3000, 3fff]
bus: 02 index 1 mmio: [ce200000, ce2fffff]
bus: 02 index 2 mmio: [c2100000, c21fffff]
bus: 02 index 3 mmio: [0, 0]
bus: 03 index 0 mmio: [0, 0]
bus: 03 index 1 mmio: [0, 0]
bus: 03 index 2 mmio: [0, 0]
bus: 03 index 3 mmio: [0, 0]
bus: 04 index 0 mmio: [0, 0]
bus: 04 index 1 mmio: [0, 0]
bus: 04 index 2 mmio: [0, 0]
bus: 04 index 3 mmio: [0, 0]
bus: 05 index 0 mmio: [0, 0]
bus: 05 index 1 mmio: [0, 0]
bus: 05 index 2 mmio: [0, 0]
bus: 05 index 3 mmio: [0, 0]
bus: 06 index 0 mmio: [0, 0]
bus: 06 index 1 mmio: [0, 0]
bus: 06 index 2 mmio: [0, 0]
bus: 06 index 3 mmio: [0, 0]
bus: 07 index 0 mmio: [0, 0]
bus: 07 index 1 mmio: [0, 0]
bus: 07 index 2 mmio: [0, 0]
bus: 07 index 3 mmio: [0, 0]
bus: 08 index 0 io port: [4000, 4fff]
bus: 08 index 1 mmio: [ce300000, ce3fffff]
bus: 08 index 2 mmio: [c2200000, c22fffff]
bus: 08 index 3 mmio: [0, 0]
bus: 09 index 0 mmio: [0, 0]
bus: 09 index 1 mmio: [ce400000, ceffffff]
bus: 09 index 2 mmio: [cf000000, cfffffff]
bus: 09 index 3 mmio: [0, 0]
bus: 0a index 0 mmio: [0, 0]
bus: 0a index 1 mmio: [0, 0]
bus: 0a index 2 mmio: [0, 0]
bus: 0a index 3 io port: [0, ffff]
bus: 0a index 4 mmio: [0, ffffffffffffffff]
NET: Registered protocol family 2
IP route cache hash table entries: 131072 (order: 8, 1048576 bytes)
TCP established hash table entries: 262144 (order: 10, 4194304 bytes)
TCP bind hash table entries: 65536 (order: 8, 1048576 bytes)
TCP: Hash tables configured (established 262144 bind 65536)
TCP reno registered
NET: Registered protocol family 1
Unpacking initramfs... done
Freeing initrd memory: 10093k freed
Simple Boot Flag at 0x7c set to 0x1
audit: initializing netlink socket (disabled)
type=2000 audit(1256191330.523:1): initialized
VFS: Disk quotas dquot_6.5.1
Dquot-cache hash table entries: 512 (order 0, 4096 bytes)
msgmni has been set to 1777
Block layer SCSI generic (bsg) driver version 0.4 loaded (major 254)
io scheduler noop registered
io scheduler anticipatory registered
io scheduler deadline registered
io scheduler cfq registered (default)
(XEN) PCI add device 00:01.0
pcieport-driver 0000:00:01.0: found MSI capability
(XEN) PCI add device 00:03.0
pcieport-driver 0000:00:03.0: found MSI capability
(XEN) PCI add device 00:05.0
pcieport-driver 0000:00:05.0: found MSI capability
(XEN) PCI add device 00:07.0
pcieport-driver 0000:00:07.0: found MSI capability
(XEN) PCI add device 00:08.0
pcieport-driver 0000:00:08.0: found MSI capability
(XEN) PCI add device 00:09.0
pcieport-driver 0000:00:09.0: found MSI capability
(XEN) PCI add device 00:0a.0
pcieport-driver 0000:00:0a.0: found MSI capability
(XEN) PCI add device 00:1c.0
pcieport-driver 0000:00:1c.0: found MSI capability
(XEN) PCI add device 00:1c.4
pcieport-driver 0000:00:1c.4: found MSI capability
Non-volatile memory driver v1.2
Xen virtual console successfully installed as ttyS0
Event-channel device installed.
PNP: No PS/2 controller found. Probing ports directly.
i8042.c: No controller found.
mice: PS/2 mouse device common for all mice
TCP cubic registered
registered taskstats version 1
Freeing unused kernel memory: 284k freed
Write protecting the kernel read-only data: 4420k
SCSI subsystem initialized
megasas: 00.00.04.01 Thu July 24 11:41:51 PST 2008
(XEN) PCI add device 01:00.0
megasas: 0x1000:0x0060:0x1734:0x10f9: bus 1:slot 0:func 0
vendor=8086 device=3408
megaraid_sas 0000:01:00.0: PCI INT A -> GSI 28 (level, low) -> IRQ 28
megasas: FW now in Ready state
scsi0 : LSI SAS based MegaRAID driver
scsi 0:0:4:0: Enclosure FSC SAS Expander 1.04 PQ: 0 ANSI: 3
scsi 0:0:5:0: Direct-Access SEAGATE ST9146802SS 2101 PQ: 0 ANSI: 5
scsi 0:0:6:0: Direct-Access SEAGATE ST9146802SS 2101 PQ: 0 ANSI: 5
scsi 0:0:7:0: Enclosure FSC SAS Expander 1.04 PQ: 0 ANSI: 3
scsi 0:2:0:0: Direct-Access LSI MegaRAID SAS RMB 1.40 PQ: 0 ANSI: 5
scsi 0:2:1:0: Direct-Access LSI MegaRAID SAS RMB 1.40 PQ: 0 ANSI: 5
scsi 0:2:2:0: Direct-Access LSI MegaRAID SAS RMB 1.40 PQ: 0 ANSI: 5
scsi 0:2:3:0: Direct-Access LSI MegaRAID SAS RMB 1.40 PQ: 0 ANSI: 5
scsi 0:2:4:0: Direct-Access LSI MegaRAID SAS RMB 1.40 PQ: 0 ANSI: 5
scsi 0:2:5:0: Direct-Access LSI MegaRAID SAS RMB 1.40 PQ: 0 ANSI: 5
Emulex LightPulse Fibre Channel SCSI driver 8.2.8.14
Copyright(c) 2004-2009 Emulex. All rights reserved.
(XEN) PCI add device 02:00.0
vendor=8086 device=340a
lpfc 0000:02:00.0: PCI INT A -> GSI 24 (level, low) -> IRQ 24
scsi1 : on PCI bus 02 device 00 irq 24
(XEN) PCI add device 02:00.1
vendor=8086 device=340a
(XEN) allocated vector for irq:34
lpfc 0000:02:00.1: PCI INT B -> GSI 34 (level, low) -> IRQ 34
scsi2 : on PCI bus 02 device 01 irq 34
ACPI: CPU0 (power states: C1[C1] C3[C3])
(XEN) Set CPU acpi_id(0) cpuid(0) Px State info:
(XEN) _PCT: descriptor=130, length=12, space_id=127, bit_width=0, bit_offset=0, reserved=0, address=0
(XEN) _PCT: descriptor=130, length=12, space_id=127, bit_width=0, bit_offset=0, reserved=0, address=0
(XEN) _PSS: state_count=7
(XEN) State0: 2262MHz 101000mW 50us 150us 0x12 0x12
(XEN) State1: 2261MHz 100000mW 50us 150us 0x11 0x11
(XEN) State2: 2128MHz 94000mW 50us 150us 0x10 0x10
(XEN) State3: 1995MHz 88000mW 50us 150us 0xf 0xf
(XEN) State4: 1862MHz 82000mW 50us 150us 0xe 0xe
(XEN) State5: 1729MHz 76000mW 50us 150us 0xd 0xd
(XEN) State6: 1596MHz 70000mW 50us 150us 0xc 0xc
(XEN) _PSD: num_entries=5 rev=0 domain=0 coord_type=252 num_processors=1
(XEN) _PPC: 0
(XEN) xen_pminfo: @acpi_cpufreq_cpu_init,HARDWARE addr space
(XEN) CPU 0 initialization completed
processor ACPI_CPU:00: registered as cooling_device0
No available Cx info for cpu 255
processor ACPI_CPU:01: registered as cooling_device1
ACPI: CPU2 (power states: C1[C1] C3[C3])
(XEN) Set CPU acpi_id(1) cpuid(1) Px State info:
(XEN) _PCT: descriptor=130, length=12, space_id=127, bit_width=0, bit_offset=0, reserved=0, address=0
(XEN) _PCT: descriptor=130, length=12, space_id=127, bit_width=0, bit_offset=0, reserved=0, address=0
(XEN) _PSS: state_count=7
(XEN) State0: 2262MHz 101000mW 50us 150us 0x12 0x12
(XEN) State1: 2261MHz 100000mW 50us 150us 0x11 0x11
(XEN) State2: 2128MHz 94000mW 50us 150us 0x10 0x10
(XEN) State3: 1995MHz 88000mW 50us 150us 0xf 0xf
(XEN) State4: 1862MHz 82000mW 50us 150us 0xe 0xe
(XEN) State5: 1729MHz 76000mW 50us 150us 0xd 0xd
(XEN) State6: 1596MHz 70000mW 50us 150us 0xc 0xc
(XEN) _PSD: num_entries=5 rev=0 domain=1 coord_type=252 num_processors=1
(XEN) _PPC: 0
(XEN) xen_pminfo: @acpi_cpufreq_cpu_init,HARDWARE addr space
(XEN) CPU 1 initialization completed
processor ACPI_CPU:02: registered as cooling_device2
BIOS reported wrong ACPI id for the processor
ACPI Exception (evxface-0544): AE_NOT_EXIST, Removing notify handler [20080609]
ACPI: CPU-1 (power states: C1[C1] C3[C3])
(XEN) Set CPU acpi_id(2) cpuid(2) Px State info:
(XEN) _PCT: descriptor=130, length=12, space_id=127, bit_width=0, bit_offset=0, reserved=0, address=0
(XEN) _PCT: descriptor=130, length=12, space_id=127, bit_width=0, bit_offset=0, reserved=0, address=0
(XEN) _PSS: state_count=7
(XEN) State0: 2262MHz 101000mW 50us 150us 0x12 0x12
(XEN) State1: 2261MHz 100000mW 50us 150us 0x11 0x11
(XEN) State2: 2128MHz 94000mW 50us 150us 0x10 0x10
(XEN) State3: 1995MHz 88000mW 50us 150us 0xf 0xf
(XEN) State4: 1862MHz 82000mW 50us 150us 0xe 0xe
(XEN) State5: 1729MHz 76000mW 50us 150us 0xd 0xd
(XEN) State6: 1596MHz 70000mW 50us 150us 0xc 0xc
(XEN) _PSD: num_entries=5 rev=0 domain=2 coord_type=252 num_processors=1
(XEN) _PPC: 0
(XEN) xen_pminfo: @acpi_cpufreq_cpu_init,HARDWARE addr space
(XEN) CPU 2 initialization completed
processor ACPI_CPU:04: registered as cooling_device3
No available Cx info for cpu 255
processor ACPI_CPU:05: registered as cooling_device4
ACPI: CPU-1 (power states: C1[C1] C3[C3])
(XEN) Set CPU acpi_id(3) cpuid(3) Px State info:
(XEN) _PCT: descriptor=130, length=12, space_id=127, bit_width=0, bit_offset=0, reserved=0, address=0
(XEN) _PCT: descriptor=130, length=12, space_id=127, bit_width=0, bit_offset=0, reserved=0, address=0
(XEN) _PSS: state_count=7
(XEN) State0: 2262MHz 101000mW 50us 150us 0x12 0x12
(XEN) State1: 2261MHz 100000mW 50us 150us 0x11 0x11
(XEN) State2: 2128MHz 94000mW 50us 150us 0x10 0x10
(XEN) State3: 1995MHz 88000mW 50us 150us 0xf 0xf
(XEN) State4: 1862MHz 82000mW 50us 150us 0xe 0xe
(XEN) State5: 1729MHz 76000mW 50us 150us 0xd 0xd
(XEN) State6: 1596MHz 70000mW 50us 150us 0xc 0xc
(XEN) _PSD: num_entries=5 rev=0 domain=3 coord_type=252 num_processors=1
(XEN) _PPC: 0
(XEN) xen_pminfo: @acpi_cpufreq_cpu_init,HARDWARE addr space
(XEN) CPU 3 initialization completed
processor ACPI_CPU:06: registered as cooling_device5
BIOS reported wrong ACPI id for the processor
ACPI Exception (evxface-0544): AE_NOT_EXIST, Removing notify handler [20080609]
No available Cx info for cpu 255
processor ACPI_CPU:08: registered as cooling_device6
BIOS reported wrong ACPI id for the processor
ACPI Exception (evxface-0544): AE_NOT_EXIST, Removing notify handler [20080609]
No available Cx info for cpu 255
processor ACPI_CPU:0a: registered as cooling_device7
BIOS reported wrong ACPI id for the processor
ACPI Exception (evxface-0544): AE_NOT_EXIST, Removing notify handler [20080609]
No available Cx info for cpu 255
processor ACPI_CPU:0c: registered as cooling_device8
BIOS reported wrong ACPI id for the processor
ACPI Exception (evxface-0544): AE_NOT_EXIST, Removing notify handler [20080609]
No available Cx info for cpu 255
processor ACPI_CPU:0e: registered as cooling_device9
BIOS reported wrong ACPI id for the processor
ACPI Exception (evxface-0544): AE_NOT_EXIST, Removing notify handler [20080609]
ACPI: No dock devices found.
(XEN) PCI add device 00:1f.2
ata_piix 0000:00:1f.2: PCI INT A -> GSI 16 (level, low) -> IRQ 16
ata_piix 0000:00:1f.2: MAP [ P0 P2 P1 P3 ]
scsi3 : ata_piix
scsi4 : ata_piix
ata1: SATA max UDMA/133 cmd 0x1c50 ctl 0x1c44 bmdma 0x1c10 irq 16
ata2: SATA max UDMA/133 cmd 0x1c48 ctl 0x1c40 bmdma 0x1c18 irq 16
[-- Attachment #4: Type: text/plain, Size: 138 bytes --]
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel
^ permalink raw reply [flat|nested] 21+ messages in thread
end of thread, other threads:[~2009-11-03 9:03 UTC | newest]
Thread overview: 21+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2009-10-21 13:07 Need help in debugging partially blocked hypervisor Dietmar Hahn
2009-10-21 13:28 ` Keir Fraser
2009-10-21 13:35 ` Dietmar Hahn
2009-10-21 13:53 ` Keir Fraser
2009-10-30 12:20 ` Dietmar Hahn
2009-10-30 13:06 ` Keir Fraser
2009-11-02 1:12 ` Haitao Shan
2009-11-02 9:11 ` Dietmar Hahn
2009-11-02 9:49 ` Shan, Haitao
2009-11-02 10:30 ` Dietmar Hahn
2009-11-03 6:53 ` Dietmar Hahn
2009-11-03 7:32 ` Shan, Haitao
2009-11-03 7:52 ` Dietmar Hahn
2009-11-03 8:02 ` Shan, Haitao
2009-11-03 8:24 ` Dietmar Hahn
2009-11-03 8:43 ` Shan, Haitao
2009-11-03 9:03 ` Dietmar Hahn
2009-11-03 9:00 ` Shan, Haitao
2009-10-22 6:23 Dietmar Hahn
2009-10-22 6:39 ` Keir Fraser
2009-10-22 7:21 ` Dietmar Hahn
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.