* XEN Panic with VT-d support enabled on Xeon E55xx platform
@ 2009-04-06 15:52 Isabelle, Francois
2009-04-07 2:31 ` Zhao, Yu
0 siblings, 1 reply; 12+ messages in thread
From: Isabelle, Francois @ 2009-04-06 15:52 UTC (permalink / raw)
To: xen-devel
Hi all,
I'm working with a board on which XEN panics with the following message (see below). From what I can see on the lists, most of the problems on these platforms seem to be related to broken DMAR tables and RMRR, but this platform passes the VT-d firmware toolkit (http://edc.intel.com/Platforms/Xeon-5500/) successfully so I'm tented to blame XEN for it... should I file a bug entry?
>From what I can see in the 'queue invalidation' code, a timeout is reached. As anyone seen this on a similar platform?
(XEN) Xen version 3.4-unstable (root@localdomain) (gcc version 4.1.2 20080704 (Red Hat 4.1.2-44)) Fri Apr 3 14:20:00 EDT 2009
(XEN) Latest ChangeSet: Mon Mar 30 16:48:26 2009 +0100 19433:d5ddc782bc49
(XEN) Command line: console=com1 com1=115200,8n1 iommu=1 loglvl=all loglvl_guest=all ro
..
(XEN) Enabling APIC mode: Flat. Using 1 I/O APICs
(XEN) ACPI: HPET id: 0xffffffff base: 0xfed00000
(XEN) [VT-D]dmar.c:485: Host address width 39
(XEN) [VT-D]dmar.c:494: found ACPI_DMAR_DRHD
(XEN) [VT-D]dmar.c:349: dmaru->address = fbffe000
(XEN) [VT-D]dmar.c:306: found IOAPIC: bdf = f0:1f.7
(XEN) [VT-D]dmar.c:358: found INCLUDE_ALL
(XEN) [VT-D]dmar.c:498: found ACPI_DMAR_RMRR
(XEN) [VT-D]dmar.c:300: found endpoint: bdf = 0:1d.0
(XEN) [VT-D]dmar.c:300: found endpoint: bdf = 0:1d.1
(XEN) [VT-D]dmar.c:300: found endpoint: bdf = 0:1d.2
(XEN) [VT-D]dmar.c:300: found endpoint: bdf = 0:1d.7
(XEN) [VT-D]dmar.c:498: found ACPI_DMAR_RMRR
(XEN) [VT-D]dmar.c:300: found endpoint: bdf = 0:1d.0
(XEN) [VT-D]dmar.c:300: found endpoint: bdf = 0:1d.1
(XEN) [VT-D]dmar.c:300: found endpoint: bdf = 0:1d.2
(XEN) [VT-D]dmar.c:300: found endpoint: bdf = 0:1d.7
(XEN) [VT-D]dmar.c:502: found ACPI_DMAR_ATSR
(XEN) [VT-D]dmar.c:287: found bridge: bdf = 0:3.0 sec = 5 sub = 5
(XEN) [VT-D]dmar.c:287: found bridge: bdf = 0:4.0 sec = 6 sub = e
(XEN) [VT-D]dmar.c:287: found bridge: bdf = 0:5.0 sec = 3 sub = 3
(XEN) [VT-D]dmar.c:287: found bridge: bdf = 0:7.0 sec = 18 sub = 18
(XEN) [VT-D]dmar.c:287: found bridge: bdf = 0:8.0 sec = f sub = 17
(XEN) [VT-D]dmar.c:287: found bridge: bdf = 0:9.0 sec = 4 sub = 4
(XEN) [VT-D]dmar.c:287: found bridge: bdf = 0:a.0 sec = 2 sub = 2
..
(XEN) Intel VT-d Snoop Control supported.
(XEN) Intel VT-d DMA Passthrough not supported.
(XEN) Intel VT-d Queued Invalidation supported.
(XEN) Intel VT-d Interrupt Remapping supported.
(XEN) DMAR_IQA_REG = 7f79d000
(XEN) DMAR_IQH_REG = 0
(XEN) DMAR_IQT_REG = 20
(XEN)
(XEN) ****************************************
(XEN) Panic on CPU 0:
(XEN) queue invalidate wait descriptor was not executed
(XEN) ****************************************
(XEN)
(XEN) Reboot in five seconds...
François Isabelle
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: XEN Panic with VT-d support enabled on Xeon E55xx platform
2009-04-06 15:52 XEN Panic with VT-d support enabled on Xeon E55xx platform Isabelle, Francois
@ 2009-04-07 2:31 ` Zhao, Yu
2009-04-07 4:40 ` Cui, Dexuan
0 siblings, 1 reply; 12+ messages in thread
From: Zhao, Yu @ 2009-04-07 2:31 UTC (permalink / raw)
To: Isabelle, Francois; +Cc: xen-devel
Hi Francois,
Do you have this problem all the times? Can you please grab some logs
and send them to me? The dmesg from a native kernel if you can't boot up
any version of Xen, and the whole Xen hypervisor log would help us to
figure out the problem.
Thanks,
Yu
Isabelle, Francois wrote:
> Hi all,
>
> I'm working with a board on which XEN panics with the following message (see below). From what I can see on the lists, most of the problems on these platforms seem to be related to broken DMAR tables and RMRR, but this platform passes the VT-d firmware toolkit (http://edc.intel.com/Platforms/Xeon-5500/) successfully so I'm tented to blame XEN for it... should I file a bug entry?
>
>>From what I can see in the 'queue invalidation' code, a timeout is reached. As anyone seen this on a similar platform?
>
>
> (XEN) Xen version 3.4-unstable (root@localdomain) (gcc version 4.1.2 20080704 (Red Hat 4.1.2-44)) Fri Apr 3 14:20:00 EDT 2009
> (XEN) Latest ChangeSet: Mon Mar 30 16:48:26 2009 +0100 19433:d5ddc782bc49
> (XEN) Command line: console=com1 com1=115200,8n1 iommu=1 loglvl=all loglvl_guest=all ro
>
> ..
> (XEN) Enabling APIC mode: Flat. Using 1 I/O APICs
> (XEN) ACPI: HPET id: 0xffffffff base: 0xfed00000
> (XEN) [VT-D]dmar.c:485: Host address width 39
> (XEN) [VT-D]dmar.c:494: found ACPI_DMAR_DRHD
> (XEN) [VT-D]dmar.c:349: dmaru->address = fbffe000
> (XEN) [VT-D]dmar.c:306: found IOAPIC: bdf = f0:1f.7
> (XEN) [VT-D]dmar.c:358: found INCLUDE_ALL
> (XEN) [VT-D]dmar.c:498: found ACPI_DMAR_RMRR
> (XEN) [VT-D]dmar.c:300: found endpoint: bdf = 0:1d.0
> (XEN) [VT-D]dmar.c:300: found endpoint: bdf = 0:1d.1
> (XEN) [VT-D]dmar.c:300: found endpoint: bdf = 0:1d.2
> (XEN) [VT-D]dmar.c:300: found endpoint: bdf = 0:1d.7
> (XEN) [VT-D]dmar.c:498: found ACPI_DMAR_RMRR
> (XEN) [VT-D]dmar.c:300: found endpoint: bdf = 0:1d.0
> (XEN) [VT-D]dmar.c:300: found endpoint: bdf = 0:1d.1
> (XEN) [VT-D]dmar.c:300: found endpoint: bdf = 0:1d.2
> (XEN) [VT-D]dmar.c:300: found endpoint: bdf = 0:1d.7
> (XEN) [VT-D]dmar.c:502: found ACPI_DMAR_ATSR
> (XEN) [VT-D]dmar.c:287: found bridge: bdf = 0:3.0 sec = 5 sub = 5
> (XEN) [VT-D]dmar.c:287: found bridge: bdf = 0:4.0 sec = 6 sub = e
> (XEN) [VT-D]dmar.c:287: found bridge: bdf = 0:5.0 sec = 3 sub = 3
> (XEN) [VT-D]dmar.c:287: found bridge: bdf = 0:7.0 sec = 18 sub = 18
> (XEN) [VT-D]dmar.c:287: found bridge: bdf = 0:8.0 sec = f sub = 17
> (XEN) [VT-D]dmar.c:287: found bridge: bdf = 0:9.0 sec = 4 sub = 4
> (XEN) [VT-D]dmar.c:287: found bridge: bdf = 0:a.0 sec = 2 sub = 2
> ..
> (XEN) Intel VT-d Snoop Control supported.
> (XEN) Intel VT-d DMA Passthrough not supported.
> (XEN) Intel VT-d Queued Invalidation supported.
> (XEN) Intel VT-d Interrupt Remapping supported.
> (XEN) DMAR_IQA_REG = 7f79d000
> (XEN) DMAR_IQH_REG = 0
> (XEN) DMAR_IQT_REG = 20
> (XEN)
> (XEN) ****************************************
> (XEN) Panic on CPU 0:
> (XEN) queue invalidate wait descriptor was not executed
> (XEN) ****************************************
> (XEN)
> (XEN) Reboot in five seconds...
>
> François Isabelle
>
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/xen-devel
^ permalink raw reply [flat|nested] 12+ messages in thread
* RE: XEN Panic with VT-d support enabled on Xeon E55xx platform
2009-04-07 2:31 ` Zhao, Yu
@ 2009-04-07 4:40 ` Cui, Dexuan
2009-04-07 7:05 ` Cui, Dexuan
0 siblings, 1 reply; 12+ messages in thread
From: Cui, Dexuan @ 2009-04-07 4:40 UTC (permalink / raw)
To: Zhao, Yu, Isabelle, Francois; +Cc: xen-devel
> (XEN) DMAR_IQA_REG = 7f79d000
> (XEN) DMAR_IQH_REG = 0
> (XEN) DMAR_IQT_REG = 20
Here the IQT is such a big number 0x20... this seems pretty strange.
Hi François,
And, could you please try the xen parameter "iommu=no-intremap" ? -- If you still see the panic, please also add the parameter "nosmp" to see if there would any change.
We don't have the same host at hand. :-( So we need try these on your host.
BTW, can you boot the same host using the latest native linux-2.6.29-rc8 when you iommu_intel=on and interrupt remapping is enabled?
PS, what's your BIOS version and date -- could you try to find the latest BIOS for the host? I personally tend to think this is a BIOS issue.
Thanks,
-- Dexuan
-----Original Message-----
From: xen-devel-bounces@lists.xensource.com [mailto:xen-devel-bounces@lists.xensource.com] On Behalf Of Zhao, Yu
Sent: Tuesday, April 07, 2009 10:31 AM
To: Isabelle, Francois
Cc: xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] XEN Panic with VT-d support enabled on Xeon E55xx platform
Hi Francois,
Do you have this problem all the times? Can you please grab some logs
and send them to me? The dmesg from a native kernel if you can't boot up
any version of Xen, and the whole Xen hypervisor log would help us to
figure out the problem.
Thanks,
Yu
Isabelle, Francois wrote:
> Hi all,
>
> I'm working with a board on which XEN panics with the following message (see below). From what I can see on the lists, most of the problems on these platforms seem to be related to broken DMAR tables and RMRR, but this platform passes the VT-d firmware toolkit (http://edc.intel.com/Platforms/Xeon-5500/) successfully so I'm tented to blame XEN for it... should I file a bug entry?
>
>>From what I can see in the 'queue invalidation' code, a timeout is reached. As anyone seen this on a similar platform?
>
>
> (XEN) Xen version 3.4-unstable (root@localdomain) (gcc version 4.1.2 20080704 (Red Hat 4.1.2-44)) Fri Apr 3 14:20:00 EDT 2009
> (XEN) Latest ChangeSet: Mon Mar 30 16:48:26 2009 +0100 19433:d5ddc782bc49
> (XEN) Command line: console=com1 com1=115200,8n1 iommu=1 loglvl=all loglvl_guest=all ro
>
> ..
> (XEN) Enabling APIC mode: Flat. Using 1 I/O APICs
> (XEN) ACPI: HPET id: 0xffffffff base: 0xfed00000
> (XEN) [VT-D]dmar.c:485: Host address width 39
> (XEN) [VT-D]dmar.c:494: found ACPI_DMAR_DRHD
> (XEN) [VT-D]dmar.c:349: dmaru->address = fbffe000
> (XEN) [VT-D]dmar.c:306: found IOAPIC: bdf = f0:1f.7
> (XEN) [VT-D]dmar.c:358: found INCLUDE_ALL
> (XEN) [VT-D]dmar.c:498: found ACPI_DMAR_RMRR
> (XEN) [VT-D]dmar.c:300: found endpoint: bdf = 0:1d.0
> (XEN) [VT-D]dmar.c:300: found endpoint: bdf = 0:1d.1
> (XEN) [VT-D]dmar.c:300: found endpoint: bdf = 0:1d.2
> (XEN) [VT-D]dmar.c:300: found endpoint: bdf = 0:1d.7
> (XEN) [VT-D]dmar.c:498: found ACPI_DMAR_RMRR
> (XEN) [VT-D]dmar.c:300: found endpoint: bdf = 0:1d.0
> (XEN) [VT-D]dmar.c:300: found endpoint: bdf = 0:1d.1
> (XEN) [VT-D]dmar.c:300: found endpoint: bdf = 0:1d.2
> (XEN) [VT-D]dmar.c:300: found endpoint: bdf = 0:1d.7
> (XEN) [VT-D]dmar.c:502: found ACPI_DMAR_ATSR
> (XEN) [VT-D]dmar.c:287: found bridge: bdf = 0:3.0 sec = 5 sub = 5
> (XEN) [VT-D]dmar.c:287: found bridge: bdf = 0:4.0 sec = 6 sub = e
> (XEN) [VT-D]dmar.c:287: found bridge: bdf = 0:5.0 sec = 3 sub = 3
> (XEN) [VT-D]dmar.c:287: found bridge: bdf = 0:7.0 sec = 18 sub = 18
> (XEN) [VT-D]dmar.c:287: found bridge: bdf = 0:8.0 sec = f sub = 17
> (XEN) [VT-D]dmar.c:287: found bridge: bdf = 0:9.0 sec = 4 sub = 4
> (XEN) [VT-D]dmar.c:287: found bridge: bdf = 0:a.0 sec = 2 sub = 2
> ..
> (XEN) Intel VT-d Snoop Control supported.
> (XEN) Intel VT-d DMA Passthrough not supported.
> (XEN) Intel VT-d Queued Invalidation supported.
> (XEN) Intel VT-d Interrupt Remapping supported.
> (XEN) DMAR_IQA_REG = 7f79d000
> (XEN) DMAR_IQH_REG = 0
> (XEN) DMAR_IQT_REG = 20
> (XEN)
> (XEN) ****************************************
> (XEN) Panic on CPU 0:
> (XEN) queue invalidate wait descriptor was not executed
> (XEN) ****************************************
> (XEN)
> (XEN) Reboot in five seconds...
>
> François Isabelle
>
> _______________________________________________
> 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] 12+ messages in thread
* RE: XEN Panic with VT-d support enabled on Xeon E55xx platform
2009-04-07 4:40 ` Cui, Dexuan
@ 2009-04-07 7:05 ` Cui, Dexuan
2009-04-07 13:12 ` XEN Panic with VT-d support enabled on Xeon E55xxplatform Isabelle, Francois
0 siblings, 1 reply; 12+ messages in thread
From: Cui, Dexuan @ 2009-04-07 7:05 UTC (permalink / raw)
To: Zhao, Yu, Isabelle, Francois; +Cc: xen-devel
>> (XEN) DMAR_IQA_REG = 7f79d000
>> (XEN) DMAR_IQH_REG = 0
>> (XEN) DMAR_IQT_REG = 20
>Here the IQT is such a big number 0x20... this seems pretty strange.
Oh, actually this 0x20 is normal -- actually QT = IQT_REG >> 4 accoriding the format of IQT_REG in VT-d spec. So QT = 0x2 -- this is ok.
So looks the panic somehow happens on the first invalidation: enable_intremap() -> iommu_flush_iec_global(). I expect your host can boot fine with iommu=no-intremap -- if this still doesn't work, could you please try iommu=no-qinval,no-intremap ?
Thanks,
-- Dexuan
-----Original Message-----
From: xen-devel-bounces@lists.xensource.com [mailto:xen-devel-bounces@lists.xensource.com] On Behalf Of Cui, Dexuan
Sent: Tuesday, April 07, 2009 12:40 PM
To: Zhao, Yu; Isabelle, Francois
Cc: xen-devel@lists.xensource.com
Subject: RE: [Xen-devel] XEN Panic with VT-d support enabled on Xeon E55xx platform
> (XEN) DMAR_IQA_REG = 7f79d000
> (XEN) DMAR_IQH_REG = 0
> (XEN) DMAR_IQT_REG = 20
Here the IQT is such a big number 0x20... this seems pretty strange.
Hi François,
And, could you please try the xen parameter "iommu=no-intremap" ? -- If you still see the panic, please also add the parameter "nosmp" to see if there would any change.
We don't have the same host at hand. :-( So we need try these on your host.
BTW, can you boot the same host using the latest native linux-2.6.29-rc8 when you iommu_intel=on and interrupt remapping is enabled?
PS, what's your BIOS version and date -- could you try to find the latest BIOS for the host? I personally tend to think this is a BIOS issue.
Thanks,
-- Dexuan
-----Original Message-----
From: xen-devel-bounces@lists.xensource.com [mailto:xen-devel-bounces@lists.xensource.com] On Behalf Of Zhao, Yu
Sent: Tuesday, April 07, 2009 10:31 AM
To: Isabelle, Francois
Cc: xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] XEN Panic with VT-d support enabled on Xeon E55xx platform
Hi Francois,
Do you have this problem all the times? Can you please grab some logs
and send them to me? The dmesg from a native kernel if you can't boot up
any version of Xen, and the whole Xen hypervisor log would help us to
figure out the problem.
Thanks,
Yu
Isabelle, Francois wrote:
> Hi all,
>
> I'm working with a board on which XEN panics with the following message (see below). From what I can see on the lists, most of the problems on these platforms seem to be related to broken DMAR tables and RMRR, but this platform passes the VT-d firmware toolkit (http://edc.intel.com/Platforms/Xeon-5500/) successfully so I'm tented to blame XEN for it... should I file a bug entry?
>
>>From what I can see in the 'queue invalidation' code, a timeout is reached. As anyone seen this on a similar platform?
>
>
> (XEN) Xen version 3.4-unstable (root@localdomain) (gcc version 4.1.2 20080704 (Red Hat 4.1.2-44)) Fri Apr 3 14:20:00 EDT 2009
> (XEN) Latest ChangeSet: Mon Mar 30 16:48:26 2009 +0100 19433:d5ddc782bc49
> (XEN) Command line: console=com1 com1=115200,8n1 iommu=1 loglvl=all loglvl_guest=all ro
>
> ..
> (XEN) Enabling APIC mode: Flat. Using 1 I/O APICs
> (XEN) ACPI: HPET id: 0xffffffff base: 0xfed00000
> (XEN) [VT-D]dmar.c:485: Host address width 39
> (XEN) [VT-D]dmar.c:494: found ACPI_DMAR_DRHD
> (XEN) [VT-D]dmar.c:349: dmaru->address = fbffe000
> (XEN) [VT-D]dmar.c:306: found IOAPIC: bdf = f0:1f.7
> (XEN) [VT-D]dmar.c:358: found INCLUDE_ALL
> (XEN) [VT-D]dmar.c:498: found ACPI_DMAR_RMRR
> (XEN) [VT-D]dmar.c:300: found endpoint: bdf = 0:1d.0
> (XEN) [VT-D]dmar.c:300: found endpoint: bdf = 0:1d.1
> (XEN) [VT-D]dmar.c:300: found endpoint: bdf = 0:1d.2
> (XEN) [VT-D]dmar.c:300: found endpoint: bdf = 0:1d.7
> (XEN) [VT-D]dmar.c:498: found ACPI_DMAR_RMRR
> (XEN) [VT-D]dmar.c:300: found endpoint: bdf = 0:1d.0
> (XEN) [VT-D]dmar.c:300: found endpoint: bdf = 0:1d.1
> (XEN) [VT-D]dmar.c:300: found endpoint: bdf = 0:1d.2
> (XEN) [VT-D]dmar.c:300: found endpoint: bdf = 0:1d.7
> (XEN) [VT-D]dmar.c:502: found ACPI_DMAR_ATSR
> (XEN) [VT-D]dmar.c:287: found bridge: bdf = 0:3.0 sec = 5 sub = 5
> (XEN) [VT-D]dmar.c:287: found bridge: bdf = 0:4.0 sec = 6 sub = e
> (XEN) [VT-D]dmar.c:287: found bridge: bdf = 0:5.0 sec = 3 sub = 3
> (XEN) [VT-D]dmar.c:287: found bridge: bdf = 0:7.0 sec = 18 sub = 18
> (XEN) [VT-D]dmar.c:287: found bridge: bdf = 0:8.0 sec = f sub = 17
> (XEN) [VT-D]dmar.c:287: found bridge: bdf = 0:9.0 sec = 4 sub = 4
> (XEN) [VT-D]dmar.c:287: found bridge: bdf = 0:a.0 sec = 2 sub = 2
> ..
> (XEN) Intel VT-d Snoop Control supported.
> (XEN) Intel VT-d DMA Passthrough not supported.
> (XEN) Intel VT-d Queued Invalidation supported.
> (XEN) Intel VT-d Interrupt Remapping supported.
> (XEN) DMAR_IQA_REG = 7f79d000
> (XEN) DMAR_IQH_REG = 0
> (XEN) DMAR_IQT_REG = 20
> (XEN)
> (XEN) ****************************************
> (XEN) Panic on CPU 0:
> (XEN) queue invalidate wait descriptor was not executed
> (XEN) ****************************************
> (XEN)
> (XEN) Reboot in five seconds...
>
> François Isabelle
>
> _______________________________________________
> 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
^ permalink raw reply [flat|nested] 12+ messages in thread
* RE: XEN Panic with VT-d support enabled on Xeon E55xxplatform
2009-04-07 7:05 ` Cui, Dexuan
@ 2009-04-07 13:12 ` Isabelle, Francois
2009-04-07 14:21 ` Cui, Dexuan
0 siblings, 1 reply; 12+ messages in thread
From: Isabelle, Francois @ 2009-04-07 13:12 UTC (permalink / raw)
To: Cui, Dexuan, Zhao, Yu; +Cc: xen-devel
[-- Attachment #1: Type: text/plain, Size: 6875 bytes --]
Hi.
Here is what you both asked for:
>> Do you have this problem all the times? Can you please grab some logs
>> and send them to me?
Yes Yu, all the times. I will package the logs as attachment to this post.
>> iommu=xxx
Dexuan, 'iommu=no-intremap' is not enough to make it run, ' iommu=no-qinval,no-intremap' allows booting.
Here are some parts of the log I don't understand...
>(XEN) [VT-D]dmar.c:485: Host address width 39
Shouldn't this be 38 ?
>(XEN) Intel VT-d Snoop Control supported.
>(XEN) Intel VT-d DMA Passthrough not supported.
Shouldn't that be enabled to support DMA from domU?
>(XEN) Intel VT-d Queued Invalidation supported.
>(XEN) Intel VT-d Interrupt Remapping supported.
>(XEN) HPET broadcast init failed, turn to PIT broadcast.
Does that mean the HPET is not functional?
Can we expect a good level of performance with interrupt remapping disabled? Will a domU be able to load a 82576 driver and use the NIC at all?
Thank you both for your replies.
François Isabelle
-----Message d'origine-----
De : Cui, Dexuan [mailto:dexuan.cui@intel.com]
Envoyé : 7 avril 2009 03:05
À : Zhao, Yu; Isabelle, Francois
Cc : xen-devel@lists.xensource.com
Objet : RE: [Xen-devel] XEN Panic with VT-d support enabled on Xeon E55xxplatform
>> (XEN) DMAR_IQA_REG = 7f79d000
>> (XEN) DMAR_IQH_REG = 0
>> (XEN) DMAR_IQT_REG = 20
>Here the IQT is such a big number 0x20... this seems pretty strange.
Oh, actually this 0x20 is normal -- actually QT = IQT_REG >> 4 accoriding the format of IQT_REG in VT-d spec. So QT = 0x2 -- this is ok.
So looks the panic somehow happens on the first invalidation: enable_intremap() -> iommu_flush_iec_global(). I expect your host can boot fine with iommu=no-intremap -- if this still doesn't work, could you please try iommu=no-qinval,no-intremap ?
Thanks,
-- Dexuan
-----Original Message-----
From: xen-devel-bounces@lists.xensource.com [mailto:xen-devel-bounces@lists.xensource.com] On Behalf Of Cui, Dexuan
Sent: Tuesday, April 07, 2009 12:40 PM
To: Zhao, Yu; Isabelle, Francois
Cc: xen-devel@lists.xensource.com
Subject: RE: [Xen-devel] XEN Panic with VT-d support enabled on Xeon E55xx platform
> (XEN) DMAR_IQA_REG = 7f79d000
> (XEN) DMAR_IQH_REG = 0
> (XEN) DMAR_IQT_REG = 20
Here the IQT is such a big number 0x20... this seems pretty strange.
Hi François,
And, could you please try the xen parameter "iommu=no-intremap" ? -- If you still see the panic, please also add the parameter "nosmp" to see if there would any change.
We don't have the same host at hand. :-( So we need try these on your host.
BTW, can you boot the same host using the latest native linux-2.6.29-rc8 when you iommu_intel=on and interrupt remapping is enabled?
PS, what's your BIOS version and date -- could you try to find the latest BIOS for the host? I personally tend to think this is a BIOS issue.
Thanks,
-- Dexuan
-----Original Message-----
From: xen-devel-bounces@lists.xensource.com [mailto:xen-devel-bounces@lists.xensource.com] On Behalf Of Zhao, Yu
Sent: Tuesday, April 07, 2009 10:31 AM
To: Isabelle, Francois
Cc: xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] XEN Panic with VT-d support enabled on Xeon E55xx platform
Hi Francois,
Do you have this problem all the times? Can you please grab some logs
and send them to me? The dmesg from a native kernel if you can't boot up
any version of Xen, and the whole Xen hypervisor log would help us to
figure out the problem.
Thanks,
Yu
Isabelle, Francois wrote:
> Hi all,
>
> I'm working with a board on which XEN panics with the following message (see below). From what I can see on the lists, most of the problems on these platforms seem to be related to broken DMAR tables and RMRR, but this platform passes the VT-d firmware toolkit (http://edc.intel.com/Platforms/Xeon-5500/) successfully so I'm tented to blame XEN for it... should I file a bug entry?
>
>>From what I can see in the 'queue invalidation' code, a timeout is reached. As anyone seen this on a similar platform?
>
>
> (XEN) Xen version 3.4-unstable (root@localdomain) (gcc version 4.1.2 20080704 (Red Hat 4.1.2-44)) Fri Apr 3 14:20:00 EDT 2009
> (XEN) Latest ChangeSet: Mon Mar 30 16:48:26 2009 +0100 19433:d5ddc782bc49
> (XEN) Command line: console=com1 com1=115200,8n1 iommu=1 loglvl=all loglvl_guest=all ro
>
> ..
> (XEN) Enabling APIC mode: Flat. Using 1 I/O APICs
> (XEN) ACPI: HPET id: 0xffffffff base: 0xfed00000
> (XEN) [VT-D]dmar.c:485: Host address width 39
> (XEN) [VT-D]dmar.c:494: found ACPI_DMAR_DRHD
> (XEN) [VT-D]dmar.c:349: dmaru->address = fbffe000
> (XEN) [VT-D]dmar.c:306: found IOAPIC: bdf = f0:1f.7
> (XEN) [VT-D]dmar.c:358: found INCLUDE_ALL
> (XEN) [VT-D]dmar.c:498: found ACPI_DMAR_RMRR
> (XEN) [VT-D]dmar.c:300: found endpoint: bdf = 0:1d.0
> (XEN) [VT-D]dmar.c:300: found endpoint: bdf = 0:1d.1
> (XEN) [VT-D]dmar.c:300: found endpoint: bdf = 0:1d.2
> (XEN) [VT-D]dmar.c:300: found endpoint: bdf = 0:1d.7
> (XEN) [VT-D]dmar.c:498: found ACPI_DMAR_RMRR
> (XEN) [VT-D]dmar.c:300: found endpoint: bdf = 0:1d.0
> (XEN) [VT-D]dmar.c:300: found endpoint: bdf = 0:1d.1
> (XEN) [VT-D]dmar.c:300: found endpoint: bdf = 0:1d.2
> (XEN) [VT-D]dmar.c:300: found endpoint: bdf = 0:1d.7
> (XEN) [VT-D]dmar.c:502: found ACPI_DMAR_ATSR
> (XEN) [VT-D]dmar.c:287: found bridge: bdf = 0:3.0 sec = 5 sub = 5
> (XEN) [VT-D]dmar.c:287: found bridge: bdf = 0:4.0 sec = 6 sub = e
> (XEN) [VT-D]dmar.c:287: found bridge: bdf = 0:5.0 sec = 3 sub = 3
> (XEN) [VT-D]dmar.c:287: found bridge: bdf = 0:7.0 sec = 18 sub = 18
> (XEN) [VT-D]dmar.c:287: found bridge: bdf = 0:8.0 sec = f sub = 17
> (XEN) [VT-D]dmar.c:287: found bridge: bdf = 0:9.0 sec = 4 sub = 4
> (XEN) [VT-D]dmar.c:287: found bridge: bdf = 0:a.0 sec = 2 sub = 2
> ..
> (XEN) Intel VT-d Snoop Control supported.
> (XEN) Intel VT-d DMA Passthrough not supported.
> (XEN) Intel VT-d Queued Invalidation supported.
> (XEN) Intel VT-d Interrupt Remapping supported.
> (XEN) DMAR_IQA_REG = 7f79d000
> (XEN) DMAR_IQH_REG = 0
> (XEN) DMAR_IQT_REG = 20
> (XEN)
> (XEN) ****************************************
> (XEN) Panic on CPU 0:
> (XEN) queue invalidate wait descriptor was not executed
> (XEN) ****************************************
> (XEN)
> (XEN) Reboot in five seconds...
>
> François Isabelle
>
> _______________________________________________
> 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
[-- Attachment #2: xen-unstable-iommu-no-qinval.txt --]
[-- Type: text/plain, Size: 52324 bytes --]
root (hd0,0)
Filesystem type is ext2fs, partition type 0x83
kernel /boot/xen.gz console=com1 com1=115200,8n1 iommu=no-qinval loglvl=all lo
glvl_guest=all ro
[Multiboot-elf, <0x100000:0x13b768:0x8e898>, shtab=0x2ca078, entry=0x100000]
module /boot/vmlinuz-2.6.18.8-xenkci ro root=LABEL=/ console=ttyS0,115200,8n1
pciback.hide=(04:00.0)(04:00.1) pciback.verbose_request=1
[Multiboot-module @ 0x2cb000, 0x76f7d8 bytes]
module /boot/initrd-2.6.18-xenkci.img
[Multiboot-module @ 0xa3b000, 0x443600 bytes]
__ __ _____ _ _ _ _ _
\ \/ /___ _ __ |___ /| || | _ _ _ __ ___| |_ __ _| |__ | | ___
\ // _ \ '_ \ |_ \| || |_ __| | | | '_ \/ __| __/ _` | '_ \| |/ _ \
/ \ __/ | | | ___) |__ _|__| |_| | | | \__ \ || (_| | |_) | | __/
/_/\_\___|_| |_| |____(_) |_| \__,_|_| |_|___/\__\__,_|_.__/|_|\___|
(XEN) Xen version 3.4-unstable (root@localdomain) (gcc version 4.1.2 20080704 (Red Hat 4.1.2-44)) Fri Apr 3 14:20:00 EDT 2009
(XEN) Latest ChangeSet: Mon Mar 30 16:48:26 2009 +0100 19433:d5ddc782bc49
(XEN) Command line: console=com1 com1=115200,8n1 iommu=no-qinval loglvl=all loglvl_guest=all ro
(XEN) Video information:
(XEN) No VGA detected
(XEN) Disc information:
(XEN) Found 1 MBR signatures
(XEN) Found 1 EDD information structures
(XEN) Xen-e820 RAM map:
(XEN) 0000000000000000 - 000000000009a800 (usable)
(XEN) 000000000009a800 - 00000000000a0000 (reserved)
(XEN) 00000000000e4000 - 0000000000100000 (reserved)
(XEN) 0000000000100000 - 000000007f7b0000 (usable)
(XEN) 000000007f7b0000 - 000000007f7be000 (ACPI data)
(XEN) 000000007f7be000 - 000000007f7d0000 (ACPI NVS)
(XEN) 000000007f7d0000 - 000000007f7e0000 (reserved)
(XEN) 000000007f7ed000 - 0000000080000000 (reserved)
(XEN) 00000000e0000000 - 00000000f0000000 (reserved)
(XEN) 00000000fee00000 - 00000000fee01000 (reserved)
(XEN) 00000000ffb00000 - 0000000100000000 (reserved)
(XEN) System RAM: 2039MB (2088232kB)
(XEN) ACPI: RSDP 000FA6B0, 0024 (r2 ACPIAM)
(XEN) ACPI: XSDT 7F7B0100, 005C (r1 031209 XSDT0910 20090312 MSFT 97)
(XEN) ACPI: FACP 7F7B0290, 00F4 (r4 031209 FACP0910 20090312 MSFT 97)
(XEN) ACPI: DSDT 7F7B04B0, 4FFD (r2 5007_ 5007_115 115 INTL 20051117)
(XEN) ACPI: FACS 7F7BE000, 0040
(XEN) ACPI: APIC 7F7B0390, 008C (r2 031209 APIC0910 20090312 MSFT 97)
(XEN) ACPI: MCFG 7F7B0470, 003C (r1 031209 OEMMCFG 20090312 MSFT 97)
(XEN) ACPI: OEMB 7F7BE040, 0072 (r1 031209 OEMB0910 20090312 MSFT 97)
(XEN) ACPI: HPET 7F7BA4B0, 0038 (r1 031209 OEMHPET 20090312 MSFT 97)
(XEN) ACPI: DMAR 7F7BE0C0, 00F8 (r1 AMI OEMDMAR 1 MSFT 97)
(XEN) ACPI: SSDT 7F7BFC10, 0363 (r1 DpgPmm CpuPm 12 INTL 20051117)
(XEN) NUMA turned off
(XEN) Faking a node at 0000000000000000-000000007f7b0000
(XEN) Domain heap initialised
(XEN) found SMP MP-table at 000ff780
(XEN) DMI present.
(XEN) Using APIC driver default
(XEN) ACPI: PM-Timer IO Port: 0x808
(XEN) ACPI: ACPI SLEEP INFO: pm1x_cnt[804,0], pm1x_evt[800,0]
(XEN) ACPI: wakeup_vec[7f7be00c], vec_size[20]
(XEN) ACPI: Local APIC address 0xfee00000
(XEN) ACPI: LAPIC (acpi_id[0x01] lapic_id[0x00] enabled)
(XEN) Processor #0 7:10 APIC version 21
(XEN) ACPI: LAPIC (acpi_id[0x02] lapic_id[0x02] enabled)
(XEN) Processor #2 7:10 APIC version 21
(XEN) ACPI: LAPIC (acpi_id[0x03] lapic_id[0x04] enabled)
(XEN) Processor #4 7:10 APIC version 21
(XEN) ACPI: LAPIC (acpi_id[0x04] lapic_id[0x06] enabled)
(XEN) Processor #6 7:10 APIC version 21
(XEN) ACPI: LAPIC (acpi_id[0x05] lapic_id[0x01] enabled)
(XEN) Processor #1 7:10 APIC version 21
(XEN) ACPI: LAPIC (acpi_id[0x06] lapic_id[0x03] enabled)
(XEN) Processor #3 7:10 APIC version 21
(XEN) ACPI: LAPIC (acpi_id[0x07] lapic_id[0x05] enabled)
(XEN) Processor #5 7:10 APIC version 21
(XEN) ACPI: LAPIC (acpi_id[0x08] lapic_id[0x07] enabled)
(XEN) Processor #7 7:10 APIC version 21
(XEN) ACPI: IOAPIC (id[0x08] address[0xfec00000] gsi_base[0])
(XEN) IOAPIC[0]: apic_id 8, version 32, address 0xfec00000, GSI 0-23
(XEN) ACPI: INT_SRC_OVR (bus 0 bus_irq 0 global_irq 2 dfl dfl)
(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 1 I/O APICs
(XEN) ACPI: HPET id: 0xffffffff base: 0xfed00000
(XEN) [VT-D]dmar.c:485: Host address width 39
(XEN) [VT-D]dmar.c:494: found ACPI_DMAR_DRHD
(XEN) [VT-D]dmar.c:349: dmaru->address = fbffe000
(XEN) [VT-D]dmar.c:306: found IOAPIC: bdf = f0:1f.7
(XEN) [VT-D]dmar.c:358: found INCLUDE_ALL
(XEN) [VT-D]dmar.c:498: found ACPI_DMAR_RMRR
(XEN) [VT-D]dmar.c:300: found endpoint: bdf = 0:1d.0
(XEN) [VT-D]dmar.c:300: found endpoint: bdf = 0:1d.1
(XEN) [VT-D]dmar.c:300: found endpoint: bdf = 0:1d.2
(XEN) [VT-D]dmar.c:300: found endpoint: bdf = 0:1d.7
(XEN) [VT-D]dmar.c:498: found ACPI_DMAR_RMRR
(XEN) [VT-D]dmar.c:300: found endpoint: bdf = 0:1d.0
(XEN) [VT-D]dmar.c:300: found endpoint: bdf = 0:1d.1
(XEN) [VT-D]dmar.c:300: found endpoint: bdf = 0:1d.2
(XEN) [VT-D]dmar.c:300: found endpoint: bdf = 0:1d.7
(XEN) [VT-D]dmar.c:502: found ACPI_DMAR_ATSR
(XEN) [VT-D]dmar.c:287: found bridge: bdf = 0:3.0 sec = 5 sub = 5
(XEN) [VT-D]dmar.c:287: found bridge: bdf = 0:4.0 sec = 6 sub = 6
(XEN) [VT-D]dmar.c:287: found bridge: bdf = 0:5.0 sec = 3 sub = 3
(XEN) [VT-D]dmar.c:287: found bridge: bdf = 0:7.0 sec = 8 sub = 8
(XEN) [VT-D]dmar.c:287: found bridge: bdf = 0:8.0 sec = 7 sub = 7
(XEN) [VT-D]dmar.c:287: found bridge: bdf = 0:9.0 sec = 4 sub = 4
(XEN) [VT-D]dmar.c:287: found bridge: bdf = 0:a.0 sec = 2 sub = 2
(XEN) Intel VT-d DMAR tables have been parsed.
(XEN) Using ACPI (MADT) for SMP configuration information
(XEN) Using scheduler: SMP Credit Scheduler (credit)
(XEN) Initializing CPU#0
(XEN) Detected 2128.038 MHz processor.
(XEN) , L1 D cache: 32K
(XEN) CPU: Physical Processor 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) 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 L5518 @ 2.13GHz stepping 05
(XEN) Booting processor 1/2 eip 8c000
(XEN) Initializing CPU#1
(XEN) , L1 D cache: 32K
(XEN) CPU: Physical Processor ID: 0
(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 L5518 @ 2.13GHz stepping 05
(XEN) Booting processor 2/4 eip 8c000
(XEN) Initializing CPU#2
(XEN) , L1 D cache: 32K
(XEN) CPU: Physical Processor ID: 0
(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 L5518 @ 2.13GHz stepping 05
(XEN) Booting processor 3/6 eip 8c000
(XEN) Initializing CPU#3
(XEN) , L1 D cache: 32K
(XEN) CPU: Physical Processor ID: 0
(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 L5518 @ 2.13GHz stepping 05
(XEN) Booting processor 4/1 eip 8c000
(XEN) Initializing CPU#4
(XEN) , L1 D cache: 32K
(XEN) CPU: Physical Processor ID: 0
(XEN) Intel machine check reporting enabled on CPU#4.
(XEN) CPU4: Thermal monitoring enabled (TM1)
(XEN) CMCI: find owner on CPU4
(XEN) CMCI: CPU4 owner_map[0], no_cmci_map[93]
(XEN) CPU4: Intel(R) Xeon(R) CPU L5518 @ 2.13GHz stepping 05
(XEN) Booting processor 5/3 eip 8c000
(XEN) Initializing CPU#5
(XEN) , L1 D cache: 32K
(XEN) CPU: Physical Processor ID: 0
(XEN) Intel machine check reporting enabled on CPU#5.
(XEN) CPU5: Thermal monitoring enabled (TM1)
(XEN) CMCI: find owner on CPU5
(XEN) CMCI: CPU5 owner_map[0], no_cmci_map[93]
(XEN) CPU5: Intel(R) Xeon(R) CPU L5518 @ 2.13GHz stepping 05
(XEN) Booting processor 6/5 eip 8c000
(XEN) Initializing CPU#6
(XEN) , L1 D cache: 32K
(XEN) CPU: Physical Processor ID: 0
(XEN) Intel machine check reporting enabled on CPU#6.
(XEN) CPU6: Thermal monitoring enabled (TM1)
(XEN) CMCI: find owner on CPU6
(XEN) CMCI: CPU6 owner_map[0], no_cmci_map[93]
(XEN) CPU6: Intel(R) Xeon(R) CPU L5518 @ 2.13GHz stepping 05
(XEN) Booting processor 7/7 eip 8c000
(XEN) Initializing CPU#7
(XEN) , L1 D cache: 32K
(XEN) CPU: Physical Processor ID: 0
(XEN) Intel machine check reporting enabled on CPU#7.
(XEN) CPU7: Thermal monitoring enabled (TM1)
(XEN) CMCI: find owner on CPU7
(XEN) CMCI: CPU7 owner_map[0], no_cmci_map[93]
(XEN) CPU7: Intel(R) Xeon(R) CPU L5518 @ 2.13GHz stepping 05
(XEN) Total of 8 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 8 CPUs: passed.
(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: CPU5 resumed
(XEN) Brought up 8 CPUs
(XEN) microcode.c:73:d32767 microcode: CPU6 resumed
(XEN) microcode.c:73:d32767 microcode: CPU4 resumed
(XEN) microcode.c:73:d32767 microcode: CPU3 resumed
(XEN) microcode.c:73:d32767 microcode: CPU7 resumed
(XEN) [VT-D]iommu.c:1789:d32767 Interrupt Remapping disabled since Queued Invalidation isn't supported or enabled.
(XEN) Intel VT-d Snoop Control supported.
(XEN) Intel VT-d DMA Passthrough not supported.
(XEN) Intel VT-d Queued Invalidation not supported.
(XEN) Intel VT-d Interrupt Remapping not supported.
(XEN) I/O virtualisation enabled
(XEN) I/O virtualisation for PV guests disabled
(XEN) HPET: 4 timers in total, 0 timers will be used for broadcast
(XEN) HPET broadcast init failed, turn to PIT broadcast.
(XEN) ACPI sleep modes: S3
(XEN) mcheck_poll: Machine check polling timer started.
(XEN) [VT-D]iommu.c:1230:d32767 domain_context_mapping:PCIe: bdf = 0:0.0
(XEN) [VT-D]iommu.c:1230:d32767 domain_context_mapping:PCIe: bdf = 0:14.0
(XEN) [VT-D]iommu.c:1230:d32767 domain_context_mapping:PCIe: bdf = 0:14.1
(XEN) [VT-D]iommu.c:1230:d32767 domain_context_mapping:PCIe: bdf = 0:14.2
(XEN) [VT-D]iommu.c:1237:d32767 domain_context_mapping:PCI: bdf = 0:14.3
(XEN) [VT-D]iommu.c:1230:d32767 domain_context_mapping:PCIe: bdf = 0:16.0
(XEN) [VT-D]iommu.c:1230:d32767 domain_context_mapping:PCIe: bdf = 0:16.1
(XEN) [VT-D]iommu.c:1230:d32767 domain_context_mapping:PCIe: bdf = 0:16.2
(XEN) [VT-D]iommu.c:1230:d32767 domain_context_mapping:PCIe: bdf = 0:16.3
(XEN) [VT-D]iommu.c:1230:d32767 domain_context_mapping:PCIe: bdf = 0:16.4
(XEN) [VT-D]iommu.c:1230:d32767 domain_context_mapping:PCIe: bdf = 0:16.5
(XEN) [VT-D]iommu.c:1230:d32767 domain_context_mapping:PCIe: bdf = 0:16.6
(XEN) [VT-D]iommu.c:1230:d32767 domain_context_mapping:PCIe: bdf = 0:16.7
(XEN) [VT-D]iommu.c:1237:d32767 domain_context_mapping:PCI: bdf = 0:1d.0
(XEN) [VT-D]iommu.c:1237:d32767 domain_context_mapping:PCI: bdf = 0:1d.1
(XEN) [VT-D]iommu.c:1237:d32767 domain_context_mapping:PCI: bdf = 0:1d.2
(XEN) [VT-D]iommu.c:1237:d32767 domain_context_mapping:PCI: bdf = 0:1d.7
(XEN) [VT-D]iommu.c:1237:d32767 domain_context_mapping:PCI: bdf = 0:1f.0
(XEN) [VT-D]iommu.c:1237:d32767 domain_context_mapping:PCI: bdf = 0:1f.2
(XEN) [VT-D]iommu.c:1237:d32767 domain_context_mapping:PCI: bdf = 0:1f.3
(XEN) [VT-D]iommu.c:1230:d32767 domain_context_mapping:PCIe: bdf = 2:0.0
(XEN) [VT-D]iommu.c:1230:d32767 domain_context_mapping:PCIe: bdf = 2:0.1
(XEN) [VT-D]iommu.c:1230:d32767 domain_context_mapping:PCIe: bdf = 3:0.0
(XEN) [VT-D]iommu.c:1230:d32767 domain_context_mapping:PCIe: bdf = 3:0.1
(XEN) [VT-D]iommu.c:1230:d32767 domain_context_mapping:PCIe: bdf = 4:0.0
(XEN) [VT-D]iommu.c:1230:d32767 domain_context_mapping:PCIe: bdf = 4:0.1
(XEN) [VT-D]iommu.c:1230:d32767 domain_context_mapping:PCIe: bdf = 6:0.0
(XEN) [VT-D]iommu.c:1237:d32767 domain_context_mapping:PCI: bdf = fe:0.0
(XEN) [VT-D]iommu.c:1237:d32767 domain_context_mapping:PCI: bdf = fe:0.1
(XEN) [VT-D]iommu.c:1237:d32767 domain_context_mapping:PCI: bdf = fe:2.0
(XEN) [VT-D]iommu.c:1237:d32767 domain_context_mapping:PCI: bdf = fe:2.1
(XEN) [VT-D]iommu.c:1237:d32767 domain_context_mapping:PCI: bdf = fe:2.4
(XEN) [VT-D]iommu.c:1237:d32767 domain_context_mapping:PCI: bdf = fe:2.5
(XEN) [VT-D]iommu.c:1237:d32767 domain_context_mapping:PCI: bdf = fe:3.0
(XEN) [VT-D]iommu.c:1237:d32767 domain_context_mapping:PCI: bdf = fe:3.1
(XEN) [VT-D]iommu.c:1237:d32767 domain_context_mapping:PCI: bdf = fe:3.2
(XEN) [VT-D]iommu.c:1237:d32767 domain_context_mapping:PCI: bdf = fe:3.4
(XEN) [VT-D]iommu.c:1237:d32767 domain_context_mapping:PCI: bdf = fe:4.0
(XEN) [VT-D]iommu.c:1237:d32767 domain_context_mapping:PCI: bdf = fe:4.1
(XEN) [VT-D]iommu.c:1237:d32767 domain_context_mapping:PCI: bdf = fe:4.2
(XEN) [VT-D]iommu.c:1237:d32767 domain_context_mapping:PCI: bdf = fe:4.3
(XEN) [VT-D]iommu.c:1237:d32767 domain_context_mapping:PCI: bdf = fe:5.0
(XEN) [VT-D]iommu.c:1237:d32767 domain_context_mapping:PCI: bdf = fe:5.1
(XEN) [VT-D]iommu.c:1237:d32767 domain_context_mapping:PCI: bdf = fe:5.2
(XEN) [VT-D]iommu.c:1237:d32767 domain_context_mapping:PCI: bdf = fe:5.3
(XEN) [VT-D]iommu.c:1237:d32767 domain_context_mapping:PCI: bdf = fe:6.0
(XEN) [VT-D]iommu.c:1237:d32767 domain_context_mapping:PCI: bdf = fe:6.1
(XEN) [VT-D]iommu.c:1237:d32767 domain_context_mapping:PCI: bdf = fe:6.2
(XEN) [VT-D]iommu.c:1237:d32767 domain_context_mapping:PCI: bdf = fe:6.3
(XEN) [VT-D]iommu.c:1237:d32767 domain_context_mapping:PCI: bdf = 0:1d.0
(XEN) [VT-D]iommu.c:1237:d32767 domain_context_mapping:PCI: bdf = 0:1d.1
(XEN) [VT-D]iommu.c:1237:d32767 domain_context_mapping:PCI: bdf = 0:1d.2
(XEN) [VT-D]iommu.c:1237:d32767 domain_context_mapping:PCI: bdf = 0:1d.7
(XEN) [VT-D]iommu.c:1237:d32767 domain_context_mapping:PCI: bdf = 0:1d.0
(XEN) [VT-D]iommu.c:1237:d32767 domain_context_mapping:PCI: bdf = 0:1d.1
(XEN) [VT-D]iommu.c:1237:d32767 domain_context_mapping:PCI: bdf = 0:1d.2
(XEN) [VT-D]iommu.c:1237:d32767 domain_context_mapping:PCI: bdf = 0:1d.7
(XEN) [VT-D]iommu.c:620: iommu_enable_translation: iommu->reg = ffff828bfff57000
(XEN) *** LOADING DOMAIN 0 ***
(XEN) elf_parse_binary: phdr: paddr=0xffffffff80200000 memsz=0x295be0
(XEN) elf_parse_binary: phdr: paddr=0xffffffff80496000 memsz=0x92928
(XEN) elf_parse_binary: phdr: paddr=0xffffffff80529000 memsz=0xc08
(XEN) elf_parse_binary: phdr: paddr=0xffffffff8052a000 memsz=0xcf90c
(XEN) elf_parse_binary: memory: 0xffffffff80200000 -> 0xffffffff805f990c
(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 = 0xffffffff80000000
(XEN) elf_xen_parse_note: ENTRY = 0xffffffff80200000
(XEN) elf_xen_parse_note: HYPERCALL_PAGE = 0xffffffff80206000
(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 = 0xffffffff80000000
(XEN) virt_offset = 0x0
(XEN) virt_kstart = 0xffffffff80200000
(XEN) virt_kend = 0xffffffff805f990c
(XEN) virt_entry = 0xffffffff80200000
(XEN) p2m_base = 0xffffffffffffffff
(XEN) Xen kernel: 64-bit, lsb, compat32
(XEN) Dom0 kernel: 64-bit, lsb, paddr 0xffffffff80200000 -> 0xffffffff805f990c
(XEN) PHYSICAL MEMORY ARRANGEMENT:
(XEN) Dom0 alloc.: 000000007b000000->000000007c000000 (478343 pages to be allocated)
(XEN) VIRTUAL MEMORY ARRANGEMENT:
(XEN) Loaded kernel: ffffffff80200000->ffffffff805f990c
(XEN) Init. ramdisk: ffffffff805fa000->ffffffff80a3d600
(XEN) Phys-Mach map: ffffffff80a3e000->ffffffff80dec438
(XEN) Start info: ffffffff80ded000->ffffffff80ded4b4
(XEN) Page tables: ffffffff80dee000->ffffffff80df9000
(XEN) Boot stack: ffffffff80df9000->ffffffff80dfa000
(XEN) TOTAL: ffffffff80000000->ffffffff81000000
(XEN) ENTRY ADDRESS: ffffffff80200000
(XEN) Dom0 has maximum 8 VCPUs
(XEN) elf_load_binary: phdr 0 at 0xffffffff80200000 -> 0xffffffff80495be0
(XEN) elf_load_binary: phdr 1 at 0xffffffff80496000 -> 0xffffffff80528928
(XEN) elf_load_binary: phdr 2 at 0xffffffff80529000 -> 0xffffffff80529c08
(XEN) elf_load_binary: phdr 3 at 0xffffffff8052a000 -> 0xffffffff80565108
(XEN) Scrubbing Free RAM: .done.
(XEN) Xen trace buffers: disabled
(XEN) Std. Loglevel: All
(XEN) Guest Loglevel: All
(XEN) *** Serial input -> DOM0 (type 'CTRL-a' three times to switch input to Xen)
(XEN) Freed 132kB init memory.
kernel direct mapping tables up to 76487000 @ dfa000-11b0000
Bootdata ok (command line is ro root=LABEL=/ console=ttyS0,115200,8n1 pciback.hide=(04:00.0)(04:00.1) pciback.verbose_request=1)
Linux version 2.6.18.8-xenkci (root@localhost.localdomain) (gcc version 4.1.2 20080704 (Red Hat 4.1.2-44)) #3 SMP Fri Apr 3 14:18:07 EDT 2009
BIOS-provided physical RAM map:
Xen: 0000000000000000 - 0000000076487000 (usable)
DMI present.
>>> ERROR: Invalid checksum
ACPI: LAPIC (acpi_id[0x01] lapic_id[0x00] enabled)
ACPI: LAPIC (acpi_id[0x02] lapic_id[0x02] enabled)
ACPI: LAPIC (acpi_id[0x03] lapic_id[0x04] enabled)
ACPI: LAPIC (acpi_id[0x04] lapic_id[0x06] enabled)
ACPI: LAPIC (acpi_id[0x05] lapic_id[0x01] enabled)
ACPI: LAPIC (acpi_id[0x06] lapic_id[0x03] enabled)
ACPI: LAPIC (acpi_id[0x07] lapic_id[0x05] enabled)
ACPI: LAPIC (acpi_id[0x08] lapic_id[0x07] enabled)
ACPI: IOAPIC (id[0x08] address[0xfec00000] gsi_base[0])
IOAPIC[0]: apic_id 8, version 32, address 0xfec00000, GSI 0-23
ACPI: INT_SRC_OVR (bus 0 bus_irq 0 global_irq 2 dfl dfl)
ACPI: INT_SRC_OVR (bus 0 bus_irq 9 global_irq 9 high level)
Setting APIC routing to xen
Using ACPI (MADT) for SMP configuration information
Allocating PCI resources starting at 88000000 (gap: 80000000:60000000)
Built 1 zonelists. Total pages: 477864
Kernel command line: ro root=LABEL=/ console=ttyS0,115200,8n1 pciback.hide=(04:00.0)(04:00.1) pciback.verbose_request=1
Initializing CPU#0
PID hash table entries: 4096 (order: 12, 32768 bytes)
Xen reported: 2128.038 MHz processor.
Console: colour dummy device 80x25
Dentry cache hash table entries: 262144 (order: 9, 2097152 bytes)
Inode-cache hash table entries: 131072 (order: 8, 1048576 bytes)
Software IO TLB enabled:
Aperture: 2 megabytes
Kernel range: ffff8800032bc000 - ffff8800034bc000
Address size: 22 bits
PCI-DMA: Using software bounce buffering for IO (SWIOTLB)
Memory: 1881268k/1937948k available (2206k kernel code, 48180k reserved, 945k data, 180k init)
Calibrating delay using timer specific routine.. 4257.40 BogoMIPS (lpj=21287001)
Security Framework v1.0.0 initialized
Capability LSM initialized
Mount-cache hash table entries: 256
, L1 D cache: 32K
CPU: Physical Processor ID: 0
CPU: Processor Core ID: 0
SMP alternatives: switching to UP code
ACPI: Core revision 20060707
SMP alternatives: switching to SMP code
Initializing CPU#1
, L1 D cache: 32K
CPU: Physical Processor ID: 0
CPU: Processor Core ID: 0
Initializing CPU#2
, L1 D cache: 32K
CPU: Physical Processor ID: 0
CPU: Processor Core ID: 0
Initializing CPU#3
, L1 D cache: 32K
CPU: Physical Processor ID: 0
CPU: Processor Core ID: 0
Initializing CPU#4
, L1 D cache: 32K
CPU: Physical Processor ID: 0
CPU: Processor Core ID: 0
Initializing CPU#5
, L1 D cache: 32K
CPU: Physical Processor ID: 0
CPU: Processor Core ID: 0
Initializing CPU#6
, L1 D cache: 32K
CPU: Physical Processor ID: 0
CPU: Processor Core ID: 0
Brought up 8 CPUs
Initializing CPU#7
, L1 D cache: 32K
CPU: Physical Processor ID: 0
CPU: Processor Core ID: 0
migration_cost=20
checking if image is initramfs... it is
Freeing initrd memory: 4365k freed
NET: Registered protocol family 16
ACPI: bus type pci registered
PCI: Using configuration type 1
ACPI: Interpreter enabled
ACPI: Using IOAPIC for interrupt routing
Error attaching device data
Error attaching device data
Error attaching device data
Error attaching device data
Error attaching device data
Error attaching device data
Error attaching device data
Error attaching device data
ACPI: PCI Root Bridge [PCI0] (0000:00)
PCI: Transparent bridge - 0000:00:1e.0
ACPI: PCI Interrupt Link [LNKA] (IRQs 3 4 6 7 12 *14 15)
ACPI: PCI Interrupt Link [LNKB] (IRQs *5)
ACPI: PCI Interrupt Link [LNKC] (IRQs 3 4 *6 7 12 14 15)
ACPI: PCI Interrupt Link [LNKD] (IRQs 3 4 6 7 12 14 *15)
ACPI: PCI Interrupt Link [LNKE] (IRQs 3 4 6 7 12 14 15) *0, disabled.
ACPI: PCI Interrupt Link [LNKF] (IRQs 3 4 6 7 12 14 15) *0, disabled.
ACPI: PCI Interrupt Link [LNKG] (IRQs 3 4 6 7 12 14 15) *0, disabled.
ACPI: PCI Interrupt Link [LNKH] (IRQs 3 4 6 7 12 14 15) *0, disabled.
Linux Plug and Play Support v0.97 (c) Adam Belay
pnp: PnP ACPI init
(XEN) io_apic.c:2139:
(XEN) ioapic_guest_write: apic=0, pin=4, old_irq=4, new_irq=4
(XEN) ioapic_guest_write: old_entry=000009f1, new_entry=000109f1
(XEN) ioapic_guest_write: Attempt to modify IO-APIC pin for in-use IRQ!
pnp: PnP ACPI: found 15 devices
xen_mem: Initialising balloon driver.
PCI: Using ACPI for IRQ routing
PCI: If a device doesn't work, try "pci=routeirq". If it helps, post a report
pnp: 00:0c: ioport range 0xa00-0xa1f has been reserved
(XEN) PCI add device 00:00.0
(XEN) PCI add device 00:03.0
(XEN) PCI add device 00:04.0
(XEN) PCI add device 00:05.0
(XEN) PCI add device 00:07.0
(XEN) PCI add device 00:08.0
(XEN) PCI add device 00:09.0
(XEN) PCI add device 00:0a.0
(XEN) PCI add device 00:14.0
(XEN) PCI add device 00:14.1
(XEN) PCI add device 00:14.2
(XEN) PCI add device 00:14.3
(XEN) PCI add device 00:16.0
(XEN) PCI add device 00:16.1
(XEN) PCI add device 00:16.2
(XEN) PCI add device 00:16.3
(XEN) PCI add device 00:16.4
(XEN) PCI add device 00:16.5
(XEN) PCI add device 00:16.6
(XEN) PCI add device 00:16.7
(XEN) PCI add device 00:1d.0
(XEN) PCI add device 00:1d.1
(XEN) PCI add device 00:1d.2
(XEN) PCI add device 00:1d.7
(XEN) PCI add device 00:1e.0
(XEN) PCI add device 00:1f.0
(XEN) PCI add device 00:1f.2
(XEN) PCI add device 00:1f.3
(XEN) PCI add device 06:00.0
(XEN) PCI add device 03:00.0
(XEN) PCI add device 03:00.1
(XEN) PCI add device 04:00.0
pciback 0000:04:00.0: seizing device
(XEN) PCI add device 04:00.1
pciback 0000:04:00.1: seizing device
(XEN) PCI add device 02:00.0
(XEN) PCI add device 02:00.1
PCI: Bridge: 0000:00:03.0
IO window: disabled.
MEM window: disabled.
PREFETCH window: disabled.
PCI: Bridge: 0000:00:04.0
IO window: e000-efff
MEM window: fbc00000-fbefffff
PREFETCH window: disabled.
PCI: Bridge: 0000:00:05.0
IO window: c000-cfff
MEM window: disabled.
PREFETCH window: faf00000-faffffff
PCI: Bridge: 0000:00:07.0
IO window: disabled.
MEM window: disabled.
PREFETCH window: disabled.
PCI: Bridge: 0000:00:08.0
IO window: disabled.
MEM window: disabled.
PREFETCH window: disabled.
PCI: Bridge: 0000:00:09.0
IO window: d000-dfff
MEM window: fba00000-fbbfffff
PREFETCH window: disabled.
PCI: Bridge: 0000:00:0a.0
IO window: b000-bfff
MEM window: fb700000-fb8fffff
PREFETCH window: disabled.
PCI: Bridge: 0000:00:1e.0
IO window: disabled.
MEM window: disabled.
PREFETCH window: disabled.
NET: Registered protocol family 2
IP route cache hash table entries: 65536 (order: 7, 524288 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
IA-32 Microcode Update Driver: v1.14a-xen <tigran@veritas.com>
audit: initializing netlink socket (disabled)
audit(1239094683.001:1): initialized
VFS: Disk quotas dquot_6.5.1
Dquot-cache hash table entries: 512 (order 0, 4096 bytes)
Initializing Cryptographic API
io scheduler noop registered
io scheduler anticipatory registered
io scheduler deadline registered
io scheduler cfq registered (default)
Real Time Clock Driver v1.12ac
Non-volatile memory driver v1.2
RAMDISK driver initialized: 16 RAM disks of 16384K size 1024 blocksize
loop: loaded (max 8 devices)
e1000e: Intel(R) PRO/1000 Network Driver - 0.3.3.3-k4
e1000e: Copyright (c) 1999-2008 Intel Corporation.
Intel(R) Gigabit Ethernet Network Driver - version 1.2.45-k2
Copyright (c) 2008 Intel Corporation.
(XEN) PCI add device 02:00.0
GSI 16 sharing vector 0x98 and IRQ 16
ACPI: PCI Interrupt 0000:02:00.0[A] -> GSI 16 (level, low) -> IRQ 16
igb 0000:02:00.0: Intel(R) Gigabit Ethernet Network Connection
igb 0000:02:00.0: eth0: (PCIe:2.5Gb/s:Width x4) 00:a0:a5:62:85:88
igb 0000:02:00.0: eth0: PBA No: 000001-004
igb 0000:02:00.0: Using MSI-X interrupts. 4 rx queue(s), 1 tx queue(s)
(XEN) PCI add device 02:00.1
GSI 17 sharing vector 0xD0 and IRQ 17
ACPI: PCI Interrupt 0000:02:00.1[B] -> GSI 17 (level, low) -> IRQ 17
igb 0000:02:00.1: Intel(R) Gigabit Ethernet Network Connection
igb 0000:02:00.1: eth1: (PCIe:2.5Gb/s:Width x4) 00:a0:a5:62:85:89
igb 0000:02:00.1: eth1: PBA No: 000001-004
igb 0000:02:00.1: Using MSI-X interrupts. 4 rx queue(s), 1 tx queue(s)
ixgbe: Intel(R) 10 Gigabit PCI Express Network Driver - version 1.3.56.5-NAPI
Copyright (c) 1999-2008 Intel Corporation.
Xen virtual console successfully installed as xvc0
Event-channel device installed.
netfront: Initialising virtual ethernet driver.
ACPI: PCI Interrupt 0000:04:00.1[B] -> GSI 17 (level, low) -> IRQ 17
ACPI: PCI interrupt for device 0000:04:00.1 disabled
ACPI: PCI Interrupt 0000:04:00.0[A] -> GSI 16 (level, low) -> IRQ 16
ACPI: PCI interrupt for device 0000:04:00.0 disabled
Uniform Multi-Platform E-IDE driver Revision: 7.00alpha2
ide: Assuming 33MHz system bus speed for PIO modes; override with idebus=xx
PNP: No PS/2 controller found. Probing ports directly.
serio: i8042 AUX port at 0x60,0x64 irq 12
serio: i8042 KBD port at 0x60,0x64 irq 1
mice: PS/2 mouse device common for all mice
md: md driver 0.90.3 MAX_MD_DEVS=256, MD_SB_DISKS=27
md: bitmap version 4.39
NET: Registered protocol family 1
NET: Registered protocol family 17
ACPI: (supports S0 S1 S4 S5)
BIOS EDD facility v0.16 2004-Jun-25, 1 devices found
Freeing unused kernel memory: 180k freed
Red Hat nash version 5.1.19.6 starting
Mounting proc filesystem
Mounting sysfs filesystem
Creating /dev
Creating initial device nodes
Setting up hotplug.
input: AT Translated Set 2 keyboard as /class/input/input0
Creating block device nodes.
Loading usbcore.ko module
usbcore: registered new driver usbfs
usbcore: registered new driver hub
Loading ehci-hcd.ko module
(XEN) PCI add device 00:1d.7
ACPI: PCI Interrupt 0000:00:1d.7[A] -> GSI 16 (level, low) -> IRQ 16
ehci_hcd 0000:00:1d.7: EHCI Host Controller
ehci_hcd 0000:00:1d.7: new USB bus registered, assigned bus number 1
ehci_hcd 0000:00:1d.7: debug port 1
ehci_hcd 0000:00:1d.7: irq 16, io mem 0xfb9d6000
ehci_hcd 0000:00:1d.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
Loading ohci-hcd.ko module
Loading uhci-hcd.ko module
USB Universal Host Controller Interface driver v3.0
(XEN) PCI add device 00:1d.0
ACPI: PCI Interrupt 0000:00:1d.0[A] -> GSI 16 (level, low) -> IRQ 16
uhci_hcd 0000:00:1d.0: UHCI Host Controller
uhci_hcd 0000:00:1d.0: new USB bus registered, assigned bus number 2
uhci_hcd 0000:00:1d.0: irq 16, io base 0x0000ac00
usb usb2: configuration #1 chosen from 1 choice
hub 2-0:1.0: USB hub found
hub 2-0:1.0: 2 ports detected
(XEN) PCI add device 00:1d.1
ACPI: PCI Interrupt 0000:00:1d.1[B] -> GSI 17 (level, low) -> IRQ 17
uhci_hcd 0000:00:1d.1: UHCI Host Controller
uhci_hcd 0000:00:1d.1: new USB bus registered, assigned bus number 3
uhci_hcd 0000:00:1d.1: irq 17, io base 0x0000a880
usb usb3: configuration #1 chosen from 1 choice
hub 3-0:1.0: USB hub found
hub 3-0:1.0: 2 ports detected
(XEN) PCI add device 00:1d.2
GSI 18 sharing vector 0x49 and IRQ 18
ACPI: PCI Interrupt 0000:00:1d.2[C] -> GSI 18 (level, low) -> IRQ 18
uhci_hcd 0000:00:1d.2: UHCI Host Controller
uhci_hcd 0000:00:1d.2: new USB bus registered, assigned bus number 4
uhci_hcd 0000:00:1d.2: irq 18, io base 0x0000a800
usb usb4: configuration #1 chosen from 1 choice
hub 4-0:1.0: USB hub found
hub 4-0:1.0: 2 ports detected
Loading jbd.ko module
Loading ext3.ko module
Loading scsi_mod.ko module
SCSI subsystem initialized
Loading sd_mod.ko module
Loading scsi_transport_sas.ko module
Loading mptbase.ko module
Fusion MPT base driver 3.04.01
Copyright (c) 1999-2005 LSI Logic Corporation
Loading mptscsih.ko module
Loading mptsas.ko module
Fusion MPT SAS Host driver 3.04.01
(XEN) PCI add device 06:00.0
ACPI: PCI Interrupt 0000:06:00.0[A] -> GSI 16 (level, low) -> IRQ 16
mptbase: Initiating ioc0 bringup
ioc0: SAS1064E: Capabilities={Initiator}
scsi0 : ioc0: LSISAS1064E, FwRev=011b0000h, Ports=1, MaxQ=277, IRQ=16
Vendor: SEAGATE Model: ST9146802SS Rev: 0003
Type: Direct-Access ANSI SCSI revision: 05
SCSI device sda: 286749488 512-byte hdwr sectors (146816 MB)
sda: Write Protect is off
SCSI device sda: drive cache: write back w/ FUA
SCSI device sda: 286749488 512-byte hdwr sectors (146816 MB)
sda: Write Protect is off
SCSI device sda: drive cache: write back w/ FUA
sda: sda1 sda2 sda3 < sda5 >
sd 0:0:0:0: Attached scsi disk sda
Loading libata.ko module
Loading ahci.ko module
(XEN) PCI add device 00:1f.2
GSI 19 sharing vector 0x51 and IRQ 19
ACPI: PCI Interrupt 0000:00:1f.2[B] -> GSI 19 (level, low) -> IRQ 19
ahci 0000:00:1f.2: AHCI 0001.0200 32 slots 6 ports 3 Gbps 0x3f impl SATA mode
ahci 0000:00:1f.2: flags: 64bit ncq stag pm led clo pio slum part
ata1: SATA max UDMA/133 cmd 0xFFFFC20000022100 ctl 0x0 bmdma 0x0 irq 243
ata2: SATA max UDMA/133 cmd 0xFFFFC20000022180 ctl 0x0 bmdma 0x0 irq 243
ata3: SATA max UDMA/133 cmd 0xFFFFC20000022200 ctl 0x0 bmdma 0x0 irq 243
ata4: SATA max UDMA/133 cmd 0xFFFFC20000022280 ctl 0x0 bmdma 0x0 irq 243
ata5: SATA max UDMA/133 cmd 0xFFFFC20000022300 ctl 0x0 bmdma 0x0 irq 243
ata6: SATA max UDMA/133 cmd 0xFFFFC20000022380 ctl 0x0 bmdma 0x0 irq 243
scsi1 : ahci
ata1: SATA link down (SStatus 0 SControl 300)
scsi2 : ahci
ata2: SATA link down (SStatus 0 SControl 300)
scsi3 : ahci
ata3: SATA link down (SStatus 0 SControl 300)
scsi4 : ahci
ata4: SATA link down (SStatus 0 SControl 300)
scsi5 : ahci
ata5: SATA link down (SStatus 0 SControl 300)
scsi6 : ahci
ata6: SATA link down (SStatus 0 SControl 300)
Loading usb-storage.ko module
Initializing USB Mass Storage driver...
usbcore: registered new driver usb-storage
USB Mass Storage support registered.
Waiting for driver initialization.
Loading ide-disk.ko module
Loading aacraid.ko module
Adaptec aacraid driver (1.1-5[2409]-mh2)
Waiting for driver initialization.
Creating root device.
Mounting root filesystem.
kjournald starting. Commit interval 5 seconds
EXT3-fs: mounted filesystem with ordered data mode.
Setting up other filesystems.
Setting up new root fs
no fstab.sys, mounting internal defaults
Switching to new root and running init.
unmounting old /dev
unmounting old /proc
unmounting old /sys
INIT: version 2.86 booting
Welcome to CentOS release 5.3 (Final)
Press 'I' to enter interactive startup.
Setting clock (localtime): Tue Apr 7 08:58:50 EDT 2009 [ OK ]
Starting udev: (XEN) PCI add device 00:1f.3
[ OK ]
Loading default keymap (us): [ OK ]
Setting hostname localhost.localdomain: [ OK ]
(XEN) Set CPU acpi_id(1) cpuid(0) Px State info:
(XEN) _PPC: 0
(XEN) cpu1 cx acpi info:
(XEN) count = 3
(XEN) flags: bm_cntl[1], bm_chk[1], has_cst[1],
(XEN) pwr_setup_done[1], bm_rld_set[0]
(XEN) states[0]:
(XEN) reg.space_id = 0x7f
(XEN) reg.bit_width = 0x1
(XEN) reg.bit_offset = 0x2
(XEN) reg.access_size = 0x1
(XEN) reg.address = 0x0
(XEN) type = 1
(XEN) latency = 1
(XEN) power = 1000
(XEN) dp(@0x0000000000000000)
(XEN) states[1]:
(XEN) reg.space_id = 0x7f
(XEN) reg.bit_width = 0x1
(XEN) reg.bit_offset = 0x2
(XEN) reg.access_size = 0x1
(XEN) reg.address = 0x10
(XEN) type = 2
(XEN) latency = 17
(XEN) power = 500
(XEN) dp(@0x0000000000000000)
(XEN) states[2]:
(XEN) reg.space_id = 0x7f
(XEN) reg.bit_width = 0x1
(XEN) reg.bit_offset = 0x2
(XEN) reg.access_size = 0x1
(XEN) reg.address = 0x20
(XEN) type = 3
(XEN) latency = 17
(XEN) power = 350
(XEN) dp(@0x0000000000000000)
(XEN) MWAIT leaf not supported by cpuid
(XEN) MWAIT leaf not supported by cpuid
(XEN) MWAIT leaf not supported by cpuid
(XEN) ==cpu0==
(XEN) active state: C-1
(XEN) max_cstate: C7
(XEN) states:
(XEN) C1: type[C1] latency[000] usage[00000000] duration[0]
(XEN) C0: usage[00000000] duration[54585186609]
(XEN) Set CPU acpi_id(1) 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=6
(XEN) State0: 2134MHz 70000mW 10us 10us 0x11 0x11
(XEN) State1: 2133MHz 60000mW 10us 10us 0x10 0x10
(XEN) State2: 2000MHz 49000mW 10us 10us 0xf 0xf
(XEN) State3: 1867MHz 41000mW 10us 10us 0xe 0xe
(XEN) State4: 1733MHz 34000mW 10us 10us 0xd 0xd
(XEN) State5: 1600MHz 28000mW 10us 10us 0xc 0xc
(XEN) _PSD: num_entries=5 rev=0 domain=0 coord_type=254 num_processors=8
(XEN) _PPC: 0
(XEN) xen_pminfo: @acpi_cpufreq_cpu_init,HARDWARE addr space
(XEN) CPU 0 initialization completed
(XEN) Set CPU acpi_id(2) cpuid(1) Px State info:
(XEN) _PPC: 0
(XEN) cpu2 cx acpi info:
(XEN) count = 3
(XEN) flags: bm_cntl[1], bm_chk[1], has_cst[1],
(XEN) pwr_setup_done[1], bm_rld_set[0]
(XEN) states[0]:
(XEN) reg.space_id = 0x7f
(XEN) reg.bit_width = 0x1
(XEN) reg.bit_offset = 0x2
(XEN) reg.access_size = 0x1
(XEN) reg.address = 0x0
(XEN) type = 1
(XEN) latency = 1
(XEN) power = 1000
(XEN) dp(@0x0000000000000000)
(XEN) states[1]:
(XEN) reg.space_id = 0x7f
(XEN) reg.bit_width = 0x1
(XEN) reg.bit_offset = 0x2
(XEN) reg.access_size = 0x1
(XEN) reg.address = 0x10
(XEN) type = 2
(XEN) latency = 17
(XEN) power = 500
(XEN) dp(@0x0000000000000000)
(XEN) states[2]:
(XEN) reg.space_id = 0x7f
(XEN) reg.bit_width = 0x1
(XEN) reg.bit_offset = 0x2
(XEN) reg.access_size = 0x1
(XEN) reg.address = 0x20
(XEN) type = 3
(XEN) latency = 17
(XEN) power = 350
(XEN) dp(@0x0000000000000000)
(XEN) MWAIT leaf not supported by cpuid
(XEN) MWAIT leaf not supported by cpuid
(XEN) MWAIT leaf not supported by cpuid
(XEN) ==cpu1==
(XEN) active state: C-1
(XEN) max_cstate: C7
(XEN) states:
(XEN) C1: type[C1] latency[000] usage[00000000] duration[0]
(XEN) C0: usage[00000000] duration[54587928266]
(XEN) Set CPU acpi_id(2) 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=6
(XEN) State0: 2134MHz 70000mW 10us 10us 0x11 0x11
(XEN) State1: 2133MHz 60000mW 10us 10us 0x10 0x10
(XEN) State2: 2000MHz 49000mW 10us 10us 0xf 0xf
(XEN) State3: 1867MHz 41000mW 10us 10us 0xe 0xe
(XEN) State4: 1733MHz 34000mW 10us 10us 0xd 0xd
(XEN) State5: 1600MHz 28000mW 10us 10us 0xc 0xc
(XEN) _PSD: num_entries=5 rev=0 domain=0 coord_type=254 num_processors=8
(XEN) _PPC: 0
(XEN) adding CPU 1
(XEN) Set CPU acpi_id(3) cpuid(2) Px State info:
(XEN) _PPC: 0
(XEN) cpu3 cx acpi info:
(XEN) count = 3
(XEN) flags: bm_cntl[1], bm_chk[1], has_cst[1],
(XEN) pwr_setup_done[1], bm_rld_set[0]
(XEN) states[0]:
(XEN) reg.space_id = 0x7f
(XEN) reg.bit_width = 0x1
(XEN) reg.bit_offset = 0x2
(XEN) reg.access_size = 0x1
(XEN) reg.address = 0x0
(XEN) type = 1
(XEN) latency = 1
(XEN) power = 1000
(XEN) dp(@0x0000000000000000)
(XEN) states[1]:
(XEN) reg.space_id = 0x7f
(XEN) reg.bit_width = 0x1
(XEN) reg.bit_offset = 0x2
(XEN) reg.access_size = 0x1
(XEN) reg.address = 0x10
(XEN) type = 2
(XEN) latency = 17
(XEN) power = 500
(XEN) dp(@0x0000000000000000)
(XEN) states[2]:
(XEN) reg.space_id = 0x7f
(XEN) reg.bit_width = 0x1
(XEN) reg.bit_offset = 0x2
(XEN) reg.access_size = 0x1
(XEN) reg.address = 0x20
(XEN) type = 3
(XEN) latency = 17
(XEN) power = 350
(XEN) dp(@0x0000000000000000)
(XEN) MWAIT leaf not supported by cpuid
(XEN) MWAIT leaf not supported by cpuid
(XEN) MWAIT leaf not supported by cpuid
(XEN) ==cpu2==
(XEN) active state: C-1
(XEN) max_cstate: C7
(XEN) states:
(XEN) C1: type[C1] latency[000] usage[00000000] duration[0]
(XEN) C0: usage[00000000] duration[54589552649]
(XEN) Set CPU acpi_id(3) 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=6
(XEN) State0: 2134MHz 70000mW 10us 10us 0x11 0x11
(XEN) State1: 2133MHz 60000mW 10us 10us 0x10 0x10
(XEN) State2: 2000MHz 49000mW 10us 10us 0xf 0xf
(XEN) State3: 1867MHz 41000mW 10us 10us 0xe 0xe
(XEN) State4: 1733MHz 34000mW 10us 10us 0xd 0xd
(XEN) State5: 1600MHz 28000mW 10us 10us 0xc 0xc
(XEN) _PSD: num_entries=5 rev=0 domain=0 coord_type=254 num_processors=8
(XEN) _PPC: 0
(XEN) adding CPU 2
(XEN) Set CPU acpi_id(4) cpuid(3) Px State info:
(XEN) _PPC: 0
(XEN) cpu4 cx acpi info:
(XEN) count = 3
(XEN) flags: bm_cntl[1], bm_chk[1], has_cst[1],
(XEN) pwr_setup_done[1], bm_rld_set[0]
(XEN) states[0]:
(XEN) reg.space_id = 0x7f
(XEN) reg.bit_width = 0x1
(XEN) reg.bit_offset = 0x2
(XEN) reg.access_size = 0x1
(XEN) reg.address = 0x0
(XEN) type = 1
(XEN) latency = 1
(XEN) power = 1000
(XEN) dp(@0x0000000000000000)
(XEN) states[1]:
(XEN) reg.space_id = 0x7f
(XEN) reg.bit_width = 0x1
(XEN) reg.bit_offset = 0x2
(XEN) reg.access_size = 0x1
(XEN) reg.address = 0x10
(XEN) type = 2
(XEN) latency = 17
(XEN) power = 500
(XEN) dp(@0x0000000000000000)
(XEN) states[2]:
(XEN) reg.space_id = 0x7f
(XEN) reg.bit_width = 0x1
(XEN) reg.bit_offset = 0x2
(XEN) reg.access_size = 0x1
(XEN) reg.address = 0x20
(XEN) type = 3
(XEN) latency = 17
(XEN) power = 350
(XEN) dp(@0x0000000000000000)
(XEN) MWAIT leaf not supported by cpuid
(XEN) MWAIT leaf not supported by cpuid
(XEN) MWAIT leaf not supported by cpuid
(XEN) ==cpu3==
(XEN) active state: C-1
(XEN) max_cstate: C7
(XEN) states:
(XEN) C1: type[C1] latency[000] usage[00000000] duration[0]
(XEN) C0: usage[00000000] duration[54591172523]
(XEN) Set CPU acpi_id(4) 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=6
(XEN) State0: 2134MHz 70000mW 10us 10us 0x11 0x11
(XEN) State1: 2133MHz 60000mW 10us 10us 0x10 0x10
(XEN) State2: 2000MHz 49000mW 10us 10us 0xf 0xf
(XEN) State3: 1867MHz 41000mW 10us 10us 0xe 0xe
(XEN) State4: 1733MHz 34000mW 10us 10us 0xd 0xd
(XEN) State5: 1600MHz 28000mW 10us 10us 0xc 0xc
(XEN) _PSD: num_entries=5 rev=0 domain=0 coord_type=254 num_processors=8
(XEN) _PPC: 0
(XEN) adding CPU 3
(XEN) Set CPU acpi_id(5) cpuid(4) Px State info:
(XEN) _PPC: 0
(XEN) cpu5 cx acpi info:
(XEN) count = 3
(XEN) flags: bm_cntl[1], bm_chk[1], has_cst[1],
(XEN) pwr_setup_done[1], bm_rld_set[0]
(XEN) states[0]:
(XEN) reg.space_id = 0x7f
(XEN) reg.bit_width = 0x1
(XEN) reg.bit_offset = 0x2
(XEN) reg.access_size = 0x1
(XEN) reg.address = 0x0
(XEN) type = 1
(XEN) latency = 1
(XEN) power = 1000
(XEN) dp(@0x0000000000000000)
(XEN) states[1]:
(XEN) reg.space_id = 0x7f
(XEN) reg.bit_width = 0x1
(XEN) reg.bit_offset = 0x2
(XEN) reg.access_size = 0x1
(XEN) reg.address = 0x10
(XEN) type = 2
(XEN) latency = 17
(XEN) power = 500
(XEN) dp(@0x0000000000000000)
(XEN) states[2]:
(XEN) reg.space_id = 0x7f
(XEN) reg.bit_width = 0x1
(XEN) reg.bit_offset = 0x2
(XEN) reg.access_size = 0x1
(XEN) reg.address = 0x20
(XEN) type = 3
(XEN) latency = 17
(XEN) power = 350
(XEN) dp(@0x0000000000000000)
(XEN) MWAIT leaf not supported by cpuid
(XEN) MWAIT leaf not supported by cpuid
(XEN) MWAIT leaf not supported by cpuid
(XEN) ==cpu4==
(XEN) active state: C-1
(XEN) max_cstate: C7
(XEN) states:
(XEN) C1: type[C1] latency[000] usage[00000000] duration[0]
(XEN) C0: usage[00000000] duration[54592795045]
(XEN) Set CPU acpi_id(5) cpuid(4) 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=6
(XEN) State0: 2134MHz 70000mW 10us 10us 0x11 0x11
(XEN) State1: 2133MHz 60000mW 10us 10us 0x10 0x10
(XEN) State2: 2000MHz 49000mW 10us 10us 0xf 0xf
(XEN) State3: 1867MHz 41000mW 10us 10us 0xe 0xe
(XEN) State4: 1733MHz 34000mW 10us 10us 0xd 0xd
(XEN) State5: 1600MHz 28000mW 10us 10us 0xc 0xc
(XEN) _PSD: num_entries=5 rev=0 domain=0 coord_type=254 num_processors=8
(XEN) _PPC: 0
(XEN) adding CPU 4
(XEN) Set CPU acpi_id(6) cpuid(5) Px State info:
(XEN) _PPC: 0
(XEN) cpu6 cx acpi info:
(XEN) count = 3
(XEN) flags: bm_cntl[1], bm_chk[1], has_cst[1],
(XEN) pwr_setup_done[1], bm_rld_set[0]
(XEN) states[0]:
(XEN) reg.space_id = 0x7f
(XEN) reg.bit_width = 0x1
(XEN) reg.bit_offset = 0x2
(XEN) reg.access_size = 0x1
(XEN) reg.address = 0x0
(XEN) type = 1
(XEN) latency = 1
(XEN) power = 1000
(XEN) dp(@0x0000000000000000)
(XEN) states[1]:
(XEN) reg.space_id = 0x7f
(XEN) reg.bit_width = 0x1
(XEN) reg.bit_offset = 0x2
(XEN) reg.access_size = 0x1
(XEN) reg.address = 0x10
(XEN) type = 2
(XEN) latency = 17
(XEN) power = 500
(XEN) dp(@0x0000000000000000)
(XEN) states[2]:
(XEN) reg.space_id = 0x7f
(XEN) reg.bit_width = 0x1
(XEN) reg.bit_offset = 0x2
(XEN) reg.access_size = 0x1
(XEN) reg.address = 0x20
(XEN) type = 3
(XEN) latency = 17
(XEN) power = 350
(XEN) dp(@0x0000000000000000)
(XEN) MWAIT leaf not supported by cpuid
(XEN) MWAIT leaf not supported by cpuid
(XEN) MWAIT leaf not supported by cpuid
(XEN) ==cpu5==
(XEN) active state: C-1
(XEN) max_cstate: C7
(XEN) states:
(XEN) C1: type[C1] latency[000] usage[00000000] duration[0]
(XEN) C0: usage[00000000] duration[54594413224]
(XEN) Set CPU acpi_id(6) cpuid(5) 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=6
(XEN) State0: 2134MHz 70000mW 10us 10us 0x11 0x11
(XEN) State1: 2133MHz 60000mW 10us 10us 0x10 0x10
(XEN) State2: 2000MHz 49000mW 10us 10us 0xf 0xf
(XEN) State3: 1867MHz 41000mW 10us 10us 0xe 0xe
(XEN) State4: 1733MHz 34000mW 10us 10us 0xd 0xd
(XEN) State5: 1600MHz 28000mW 10us 10us 0xc 0xc
(XEN) _PSD: num_entries=5 rev=0 domain=0 coord_type=254 num_processors=8
(XEN) _PPC: 0
(XEN) adding CPU 5
(XEN) Set CPU acpi_id(7) cpuid(6) Px State info:
(XEN) _PPC: 0
(XEN) cpu7 cx acpi info:
(XEN) count = 3
(XEN) flags: bm_cntl[1], bm_chk[1], has_cst[1],
(XEN) pwr_setup_done[1], bm_rld_set[0]
(XEN) states[0]:
(XEN) reg.space_id = 0x7f
(XEN) reg.bit_width = 0x1
(XEN) reg.bit_offset = 0x2
(XEN) reg.access_size = 0x1
(XEN) reg.address = 0x0
(XEN) type = 1
(XEN) latency = 1
(XEN) power = 1000
(XEN) dp(@0x0000000000000000)
(XEN) states[1]:
(XEN) reg.space_id = 0x7f
(XEN) reg.bit_width = 0x1
(XEN) reg.bit_offset = 0x2
(XEN) reg.access_size = 0x1
(XEN) reg.address = 0x10
(XEN) type = 2
(XEN) latency = 17
(XEN) power = 500
(XEN) dp(@0x0000000000000000)
(XEN) states[2]:
(XEN) reg.space_id = 0x7f
(XEN) reg.bit_width = 0x1
(XEN) reg.bit_offset = 0x2
(XEN) reg.access_size = 0x1
(XEN) reg.address = 0x20
(XEN) type = 3
(XEN) latency = 17
(XEN) power = 350
(XEN) dp(@0x0000000000000000)
(XEN) MWAIT leaf not supported by cpuid
(XEN) MWAIT leaf not supported by cpuid
(XEN) MWAIT leaf not supported by cpuid
(XEN) ==cpu6==
(XEN) active state: C-1
(XEN) max_cstate: C7
(XEN) states:
(XEN) C1: type[C1] latency[000] usage[00000000] duration[0]
(XEN) C0: usage[00000000] duration[54596029552]
(XEN) Set CPU acpi_id(7) cpuid(6) 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=6
(XEN) State0: 2134MHz 70000mW 10us 10us 0x11 0x11
(XEN) State1: 2133MHz 60000mW 10us 10us 0x10 0x10
(XEN) State2: 2000MHz 49000mW 10us 10us 0xf 0xf
(XEN) State3: 1867MHz 41000mW 10us 10us 0xe 0xe
(XEN) State4: 1733MHz 34000mW 10us 10us 0xd 0xd
(XEN) State5: 1600MHz 28000mW 10us 10us 0xc 0xc
(XEN) _PSD: num_entries=5 rev=0 domain=0 coord_type=254 num_processors=8
(XEN) _PPC: 0
(XEN) adding CPU 6
(XEN) Set CPU acpi_id(8) cpuid(7) Px State info:
(XEN) _PPC: 0
(XEN) cpu8 cx acpi info:
(XEN) count = 3
(XEN) flags: bm_cntl[1], bm_chk[1], has_cst[1],
(XEN) pwr_setup_done[1], bm_rld_set[0]
(XEN) states[0]:
(XEN) reg.space_id = 0x7f
(XEN) reg.bit_width = 0x1
(XEN) reg.bit_offset = 0x2
(XEN) reg.access_size = 0x1
(XEN) reg.address = 0x0
(XEN) type = 1
(XEN) latency = 1
(XEN) power = 1000
(XEN) dp(@0x0000000000000000)
(XEN) states[1]:
(XEN) reg.space_id = 0x7f
(XEN) reg.bit_width = 0x1
(XEN) reg.bit_offset = 0x2
(XEN) reg.access_size = 0x1
(XEN) reg.address = 0x10
(XEN) type = 2
(XEN) latency = 17
(XEN) power = 500
(XEN) dp(@0x0000000000000000)
(XEN) states[2]:
(XEN) reg.space_id = 0x7f
(XEN) reg.bit_width = 0x1
(XEN) reg.bit_offset = 0x2
(XEN) reg.access_size = 0x1
(XEN) reg.address = 0x20
(XEN) type = 3
(XEN) latency = 17
(XEN) power = 350
(XEN) dp(@0x0000000000000000)
(XEN) MWAIT leaf not supported by cpuid
(XEN) MWAIT leaf not supported by cpuid
(XEN) MWAIT leaf not supported by cpuid
(XEN) ==cpu7==
(XEN) active state: C-1
(XEN) max_cstate: C7
(XEN) states:
(XEN) C1: type[C1] latency[000] usage[00000000] duration[0]
(XEN) C0: usage[00000000] duration[54597670530]
(XEN) Set CPU acpi_id(8) cpuid(7) 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=6
(XEN) State0: 2134MHz 70000mW 10us 10us 0x11 0x11
(XEN) State1: 2133MHz 60000mW 10us 10us 0x10 0x10
(XEN) State2: 2000MHz 49000mW 10us 10us 0xf 0xf
(XEN) State3: 1867MHz 41000mW 10us 10us 0xe 0xe
(XEN) State4: 1733MHz 34000mW 10us 10us 0xd 0xd
(XEN) State5: 1600MHz 28000mW 10us 10us 0xc 0xc
(XEN) _PSD: num_entries=5 rev=0 domain=0 coord_type=254 num_processors=8
(XEN) _PPC: 0
(XEN) adding CPU 7
No devices found
Setting up Logical Volume Management: [ OK ]
Checking filesystems
Checking all file systems.
[/sbin/fsck.ext3 (1) -- /] fsck.ext3 -a /dev/sda1
/: clean, 250960/2560864 files, 1945012/2560351 blocks
[ OK ]
Remounting root filesystem in read-write mode: [ OK ]
Mounting local filesystems: [ OK ]
Enabling local filesystem quotas: [ OK ]
Enabling /etc/fstab swaps: [ OK ]
INIT: Entering runlevel: 3
Entering non-interactive startup
Applying Intel CPU microcode update: FATAL: Module microcode not found.
ERROR: Module microcode does not exist in /proc/modules
Starting background readahead: [ OK ]
Checking for hardware changes [ OK ]
Bringing up loopback interface: [ OK ]
Bringing up interface eth2:
Determining IP information for eth2... done.
[ OK ]
Starting auditd: [ OK ]
Starting system logger: [ OK ]
Starting kernel logger: [ OK ]
Starting irqbalance: [ OK ]
Starting portmap: [ OK ]
Starting NFS statd: [ OK ]
Starting RPC idmapd: [ OK ]
Starting system message bus: [ OK ]
[ OK ] Bluetooth services:[ OK ]
Mounting other filesystems: [ OK ]
Starting PC/SC smart card daemon (pcscd): [ OK ]
Starting hidd: [ OK ]
Starting autofs: Loading autofs4: [ OK ]
Starting automount: [ OK ]
[ OK ]
Starting acpi daemon: [ OK ]
Starting sshd: [ OK ]
Starting cups: [ OK ]
Starting xinetd: [ OK ]
Starting sendmail: [ OK ]
Starting sm-client: [ OK ]
Starting console mouse services: [ OK ]
Starting crond: [ OK ]
Starting xfs: [ OK ]
Starting anacron: [ OK ]
Starting atd: [ OK ]
Starting libvirtd daemon: [ OK ]
Starting yum-updatesd: [ OK ]
Starting Avahi daemon... [ OK ]
Starting HAL daemon: Bridge firewalling registered
ip_tables: (C) 2000-2006 Netfilter Core Team
Netfilter messages via NETLINK v0.30.
ip_conntrack version 2.4 (8192 buckets, 65536 max) - 304 bytes per conntrack
[ OK ]
Starting xend: FATAL: Module blkbk not found.
FATAL: Module blktap not found.
FATAL: Module netbk not found.
FATAL: Module netloop not found.
[ OK ]
Starting Cluster Module - cluster monitor: Setting verbosity level to LogBasic
[ OK ]
Starting oddjobd: [ OK ]
Starting ricci: [ OK ]
Starting smartd: [ OK ]
CentOS release 5.3 (Final)
Kernel 2.6.18.8-xenkci on an x86_64
localhost.localdomain login:
[-- Attachment #3: xen-unstable-iommu-1.txt --]
[-- Type: text/plain, Size: 10343 bytes --]
root (hd0,0)
Filesystem type is ext2fs, partition type 0x83
kernel /boot/xen.gz console=com1 com1=115200,8n1 iommu=1 loglvl=all loglvl_gue
st=all ro
[Multiboot-elf, <0x100000:0x13b768:0x8e898>, shtab=0x2ca078, entry=0x100000]
module /boot/vmlinuz-2.6.18.8-xenkci ro root=LABEL=/ console=ttyS0,115200,8n1
pciback.hide=(04:00.0)(04:00.1) pciback.verbose_request=1
[Multiboot-module @ 0x2cb000, 0x76f7d8 bytes]
module /boot/initrd-2.6.18-xenkci.img
[Multiboot-module @ 0xa3b000, 0x443600 bytes]
__ __ _____ _ _ _ _ _
\ \/ /___ _ __ |___ /| || | _ _ _ __ ___| |_ __ _| |__ | | ___
\ // _ \ '_ \ |_ \| || |_ __| | | | '_ \/ __| __/ _` | '_ \| |/ _ \
/ \ __/ | | | ___) |__ _|__| |_| | | | \__ \ || (_| | |_) | | __/
/_/\_\___|_| |_| |____(_) |_| \__,_|_| |_|___/\__\__,_|_.__/|_|\___|
(XEN) Xen version 3.4-unstable (root@localdomain) (gcc version 4.1.2 20080704 (Red Hat 4.1.2-44)) Fri Apr 3 14:20:00 EDT 2009
(XEN) Latest ChangeSet: Mon Mar 30 16:48:26 2009 +0100 19433:d5ddc782bc49
(XEN) Command line: console=com1 com1=115200,8n1 iommu=1 loglvl=all loglvl_guest=all ro
(XEN) Video information:
(XEN) No VGA detected
(XEN) Disc information:
(XEN) Found 1 MBR signatures
(XEN) Found 1 EDD information structures
(XEN) Xen-e820 RAM map:
(XEN) 0000000000000000 - 000000000009a800 (usable)
(XEN) 000000000009a800 - 00000000000a0000 (reserved)
(XEN) 00000000000e4000 - 0000000000100000 (reserved)
(XEN) 0000000000100000 - 000000007f7b0000 (usable)
(XEN) 000000007f7b0000 - 000000007f7be000 (ACPI data)
(XEN) 000000007f7be000 - 000000007f7d0000 (ACPI NVS)
(XEN) 000000007f7d0000 - 000000007f7e0000 (reserved)
(XEN) 000000007f7ed000 - 0000000080000000 (reserved)
(XEN) 00000000e0000000 - 00000000f0000000 (reserved)
(XEN) 00000000fee00000 - 00000000fee01000 (reserved)
(XEN) 00000000ffb00000 - 0000000100000000 (reserved)
(XEN) System RAM: 2039MB (2088232kB)
(XEN) ACPI: RSDP 000FA6B0, 0024 (r2 ACPIAM)
(XEN) ACPI: XSDT 7F7B0100, 005C (r1 031209 XSDT0910 20090312 MSFT 97)
(XEN) ACPI: FACP 7F7B0290, 00F4 (r4 031209 FACP0910 20090312 MSFT 97)
(XEN) ACPI: DSDT 7F7B04B0, 4FFD (r2 5007_ 5007_115 115 INTL 20051117)
(XEN) ACPI: FACS 7F7BE000, 0040
(XEN) ACPI: APIC 7F7B0390, 008C (r2 031209 APIC0910 20090312 MSFT 97)
(XEN) ACPI: MCFG 7F7B0470, 003C (r1 031209 OEMMCFG 20090312 MSFT 97)
(XEN) ACPI: OEMB 7F7BE040, 0072 (r1 031209 OEMB0910 20090312 MSFT 97)
(XEN) ACPI: HPET 7F7BA4B0, 0038 (r1 031209 OEMHPET 20090312 MSFT 97)
(XEN) ACPI: DMAR 7F7BE0C0, 00F8 (r1 AMI OEMDMAR 1 MSFT 97)
(XEN) ACPI: SSDT 7F7BFC10, 0363 (r1 DpgPmm CpuPm 12 INTL 20051117)
(XEN) NUMA turned off
(XEN) Faking a node at 0000000000000000-000000007f7b0000
(XEN) Domain heap initialised
(XEN) found SMP MP-table at 000ff780
(XEN) DMI present.
(XEN) Using APIC driver default
(XEN) ACPI: PM-Timer IO Port: 0x808
(XEN) ACPI: ACPI SLEEP INFO: pm1x_cnt[804,0], pm1x_evt[800,0]
(XEN) ACPI: wakeup_vec[7f7be00c], vec_size[20]
(XEN) ACPI: Local APIC address 0xfee00000
(XEN) ACPI: LAPIC (acpi_id[0x01] lapic_id[0x00] enabled)
(XEN) Processor #0 7:10 APIC version 21
(XEN) ACPI: LAPIC (acpi_id[0x02] lapic_id[0x02] enabled)
(XEN) Processor #2 7:10 APIC version 21
(XEN) ACPI: LAPIC (acpi_id[0x03] lapic_id[0x04] enabled)
(XEN) Processor #4 7:10 APIC version 21
(XEN) ACPI: LAPIC (acpi_id[0x04] lapic_id[0x06] enabled)
(XEN) Processor #6 7:10 APIC version 21
(XEN) ACPI: LAPIC (acpi_id[0x05] lapic_id[0x01] enabled)
(XEN) Processor #1 7:10 APIC version 21
(XEN) ACPI: LAPIC (acpi_id[0x06] lapic_id[0x03] enabled)
(XEN) Processor #3 7:10 APIC version 21
(XEN) ACPI: LAPIC (acpi_id[0x07] lapic_id[0x05] enabled)
(XEN) Processor #5 7:10 APIC version 21
(XEN) ACPI: LAPIC (acpi_id[0x08] lapic_id[0x07] enabled)
(XEN) Processor #7 7:10 APIC version 21
(XEN) ACPI: IOAPIC (id[0x08] address[0xfec00000] gsi_base[0])
(XEN) IOAPIC[0]: apic_id 8, version 32, address 0xfec00000, GSI 0-23
(XEN) ACPI: INT_SRC_OVR (bus 0 bus_irq 0 global_irq 2 dfl dfl)
(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 1 I/O APICs
(XEN) ACPI: HPET id: 0xffffffff base: 0xfed00000
(XEN) [VT-D]dmar.c:485: Host address width 39
(XEN) [VT-D]dmar.c:494: found ACPI_DMAR_DRHD
(XEN) [VT-D]dmar.c:349: dmaru->address = fbffe000
(XEN) [VT-D]dmar.c:306: found IOAPIC: bdf = f0:1f.7
(XEN) [VT-D]dmar.c:358: found INCLUDE_ALL
(XEN) [VT-D]dmar.c:498: found ACPI_DMAR_RMRR
(XEN) [VT-D]dmar.c:300: found endpoint: bdf = 0:1d.0
(XEN) [VT-D]dmar.c:300: found endpoint: bdf = 0:1d.1
(XEN) [VT-D]dmar.c:300: found endpoint: bdf = 0:1d.2
(XEN) [VT-D]dmar.c:300: found endpoint: bdf = 0:1d.7
(XEN) [VT-D]dmar.c:498: found ACPI_DMAR_RMRR
(XEN) [VT-D]dmar.c:300: found endpoint: bdf = 0:1d.0
(XEN) [VT-D]dmar.c:300: found endpoint: bdf = 0:1d.1
(XEN) [VT-D]dmar.c:300: found endpoint: bdf = 0:1d.2
(XEN) [VT-D]dmar.c:300: found endpoint: bdf = 0:1d.7
(XEN) [VT-D]dmar.c:502: found ACPI_DMAR_ATSR
(XEN) [VT-D]dmar.c:287: found bridge: bdf = 0:3.0 sec = 5 sub = 5
(XEN) [VT-D]dmar.c:287: found bridge: bdf = 0:4.0 sec = 6 sub = 6
(XEN) [VT-D]dmar.c:287: found bridge: bdf = 0:5.0 sec = 3 sub = 3
(XEN) [VT-D]dmar.c:287: found bridge: bdf = 0:7.0 sec = 8 sub = 8
(XEN) [VT-D]dmar.c:287: found bridge: bdf = 0:8.0 sec = 7 sub = 7
(XEN) [VT-D]dmar.c:287: found bridge: bdf = 0:9.0 sec = 4 sub = 4
(XEN) [VT-D]dmar.c:287: found bridge: bdf = 0:a.0 sec = 2 sub = 2
(XEN) Intel VT-d DMAR tables have been parsed.
(XEN) Using ACPI (MADT) for SMP configuration information
(XEN) Using scheduler: SMP Credit Scheduler (credit)
(XEN) Initializing CPU#0
(XEN) Detected 2128.044 MHz processor.
(XEN) , L1 D cache: 32K
(XEN) CPU: Physical Processor 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) 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 L5518 @ 2.13GHz stepping 05
(XEN) Booting processor 1/2 eip 8c000
(XEN) Initializing CPU#1
(XEN) , L1 D cache: 32K
(XEN) CPU: Physical Processor ID: 0
(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 L5518 @ 2.13GHz stepping 05
(XEN) Booting processor 2/4 eip 8c000
(XEN) Initializing CPU#2
(XEN) , L1 D cache: 32K
(XEN) CPU: Physical Processor ID: 0
(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 L5518 @ 2.13GHz stepping 05
(XEN) Booting processor 3/6 eip 8c000
(XEN) Initializing CPU#3
(XEN) , L1 D cache: 32K
(XEN) CPU: Physical Processor ID: 0
(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 L5518 @ 2.13GHz stepping 05
(XEN) Booting processor 4/1 eip 8c000
(XEN) Initializing CPU#4
(XEN) , L1 D cache: 32K
(XEN) CPU: Physical Processor ID: 0
(XEN) Intel machine check reporting enabled on CPU#4.
(XEN) CPU4: Thermal monitoring enabled (TM1)
(XEN) CMCI: find owner on CPU4
(XEN) CMCI: CPU4 owner_map[0], no_cmci_map[93]
(XEN) CPU4: Intel(R) Xeon(R) CPU L5518 @ 2.13GHz stepping 05
(XEN) Booting processor 5/3 eip 8c000
(XEN) Initializing CPU#5
(XEN) , L1 D cache: 32K
(XEN) CPU: Physical Processor ID: 0
(XEN) Intel machine check reporting enabled on CPU#5.
(XEN) CPU5: Thermal monitoring enabled (TM1)
(XEN) CMCI: find owner on CPU5
(XEN) CMCI: CPU5 owner_map[0], no_cmci_map[93]
(XEN) CPU5: Intel(R) Xeon(R) CPU L5518 @ 2.13GHz stepping 05
(XEN) Booting processor 6/5 eip 8c000
(XEN) Initializing CPU#6
(XEN) , L1 D cache: 32K
(XEN) CPU: Physical Processor ID: 0
(XEN) Intel machine check reporting enabled on CPU#6.
(XEN) CPU6: Thermal monitoring enabled (TM1)
(XEN) CMCI: find owner on CPU6
(XEN) CMCI: CPU6 owner_map[0], no_cmci_map[93]
(XEN) CPU6: Intel(R) Xeon(R) CPU L5518 @ 2.13GHz stepping 05
(XEN) Booting processor 7/7 eip 8c000
(XEN) Initializing CPU#7
(XEN) , L1 D cache: 32K
(XEN) CPU: Physical Processor ID: 0
(XEN) Intel machine check reporting enabled on CPU#7.
(XEN) CPU7: Thermal monitoring enabled (TM1)
(XEN) CMCI: find owner on CPU7
(XEN) CMCI: CPU7 owner_map[0], no_cmci_map[93]
(XEN) CPU7: Intel(R) Xeon(R) CPU L5518 @ 2.13GHz stepping 05
(XEN) Total of 8 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 8 CPUs: passed.
(XEN) Platform timer is 14.318MHz HPET
(XEN) microcode.c:73:d32767 microcode: CPU1 resumed
(XEN) microcode.c:73:d32767 microcode: CPU4 resumed
(XEN) microcode.c:73:d32767 microcode: CPU2 resumed
(XEN) microcode.c:73:d32767 microcode: CPU7 resumed
(XEN) microcode.c:73:d32767 microcode: CPU5 resumed
(XEN) microcode.c:73:d32767 microcode: CPU3 resumed
(XEN) Brought up 8 CPUs
(XEN) microcode.c:73:d32767 microcode: CPU6 resumed
(XEN) Intel VT-d Snoop Control supported.
(XEN) Intel VT-d DMA Passthrough not supported.
(XEN) Intel VT-d Queued Invalidation supported.
(XEN) Intel VT-d Interrupt Remapping supported.
(XEN) DMAR_IQA_REG = 7f79d000
(XEN) DMAR_IQH_REG = 0
(XEN) DMAR_IQT_REG = 20
(XEN)
(XEN) ****************************************
(XEN) Panic on CPU 0:
(XEN) queue invalidate wait descriptor was not executed
(XEN) ****************************************
(XEN)
(XEN) Reboot in five seconds...
[-- 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] 12+ messages in thread
* RE: XEN Panic with VT-d support enabled on Xeon E55xxplatform
2009-04-07 13:12 ` XEN Panic with VT-d support enabled on Xeon E55xxplatform Isabelle, Francois
@ 2009-04-07 14:21 ` Cui, Dexuan
2009-04-07 15:06 ` Isabelle, Francois
0 siblings, 1 reply; 12+ messages in thread
From: Cui, Dexuan @ 2009-04-07 14:21 UTC (permalink / raw)
To: Isabelle, Francois, Zhao, Yu; +Cc: xen-devel
>>> iommu=xxx
> Dexuan, 'iommu=no-intremap' is not enough to make it run, ' iommu=no-qinval,no-intremap' allows booting.
When you only use iommu=no-intremap and see the panic, can you attached the xen log?
And can you also try iommu=passthrough,no-intremap and attach the log?
>>(XEN) [VT-D]dmar.c:485: Host address width 39
>Shouldn't this be 38 ?
The Host Address Width (HAW) of the platform is computed as (N+1), where N is the value reported in the Host Address Width field of DMA Remapping Reporting Structure.
Please see acpi_parse_dmar() or VT-d spec for details.
>>(XEN) Intel VT-d Snoop Control supported.
>>(XEN) Intel VT-d DMA Passthrough not supported.
> Shouldn't that be enabled to support DMA from domU?
If the "DMA Passthrough" (please don't mistake it for DMA remapping:-) of VT-d Context Entry is used, the DMA requests related to the Context Entry can bypass DMA remapping. This can be faster than DMA remapping. If you host supports DMA passthrough (you could check your BIOS setup menu), in Xen we can enable DMA passthrough by iommu=passthrough (Note, even with this parameter, we only enable passthrough for Dom0 considering secrity)
>>(XEN) HPET broadcast init failed, turn to PIT broadcast.
> Does that mean the HPET is not functional?
>From hpet_fsb_cap_lookup(), looks your HPET timers may work, but they don't support FSB routing, so won't be used in power management code.
>Can we expect a good level of performance with interrupt remapping disabled? Will a domU be able to load a 82576 driver and use the NIC at all?
I think we should have almost the same performance with Interrupt Remapping enabled or disabled.
82576 should work in DomU.
Thanks,
-- Dexuan
-----Original Message-----
From: Isabelle, Francois [mailto:Francois.Isabelle@ca.kontron.com]
Sent: Tuesday, April 07, 2009 9:12 PM
To: Cui, Dexuan; Zhao, Yu
Cc: xen-devel@lists.xensource.com
Subject: RE: [Xen-devel] XEN Panic with VT-d support enabled on Xeon E55xxplatform
Hi.
Here is what you both asked for:
>> Do you have this problem all the times? Can you please grab some logs
>> and send them to me?
Yes Yu, all the times. I will package the logs as attachment to this post.
>> iommu=xxx
Dexuan, 'iommu=no-intremap' is not enough to make it run, ' iommu=no-qinval,no-intremap' allows booting.
Here are some parts of the log I don't understand...
>(XEN) [VT-D]dmar.c:485: Host address width 39
Shouldn't this be 38 ?
>(XEN) Intel VT-d Snoop Control supported.
>(XEN) Intel VT-d DMA Passthrough not supported.
Shouldn't that be enabled to support DMA from domU?
>(XEN) Intel VT-d Queued Invalidation supported.
>(XEN) Intel VT-d Interrupt Remapping supported.
>(XEN) HPET broadcast init failed, turn to PIT broadcast.
Does that mean the HPET is not functional?
Can we expect a good level of performance with interrupt remapping disabled? Will a domU be able to load a 82576 driver and use the NIC at all?
Thank you both for your replies.
François Isabelle
-----Message d'origine-----
De : Cui, Dexuan [mailto:dexuan.cui@intel.com]
Envoyé : 7 avril 2009 03:05
À : Zhao, Yu; Isabelle, Francois
Cc : xen-devel@lists.xensource.com
Objet : RE: [Xen-devel] XEN Panic with VT-d support enabled on Xeon E55xxplatform
>> (XEN) DMAR_IQA_REG = 7f79d000
>> (XEN) DMAR_IQH_REG = 0
>> (XEN) DMAR_IQT_REG = 20
>Here the IQT is such a big number 0x20... this seems pretty strange.
Oh, actually this 0x20 is normal -- actually QT = IQT_REG >> 4 accoriding the format of IQT_REG in VT-d spec. So QT = 0x2 -- this is ok.
So looks the panic somehow happens on the first invalidation: enable_intremap() -> iommu_flush_iec_global(). I expect your host can boot fine with iommu=no-intremap -- if this still doesn't work, could you please try iommu=no-qinval,no-intremap ?
Thanks,
-- Dexuan
-----Original Message-----
From: xen-devel-bounces@lists.xensource.com [mailto:xen-devel-bounces@lists.xensource.com] On Behalf Of Cui, Dexuan
Sent: Tuesday, April 07, 2009 12:40 PM
To: Zhao, Yu; Isabelle, Francois
Cc: xen-devel@lists.xensource.com
Subject: RE: [Xen-devel] XEN Panic with VT-d support enabled on Xeon E55xx platform
> (XEN) DMAR_IQA_REG = 7f79d000
> (XEN) DMAR_IQH_REG = 0
> (XEN) DMAR_IQT_REG = 20
Here the IQT is such a big number 0x20... this seems pretty strange.
Hi François,
And, could you please try the xen parameter "iommu=no-intremap" ? -- If you still see the panic, please also add the parameter "nosmp" to see if there would any change.
We don't have the same host at hand. :-( So we need try these on your host.
BTW, can you boot the same host using the latest native linux-2.6.29-rc8 when you iommu_intel=on and interrupt remapping is enabled?
PS, what's your BIOS version and date -- could you try to find the latest BIOS for the host? I personally tend to think this is a BIOS issue.
Thanks,
-- Dexuan
-----Original Message-----
From: xen-devel-bounces@lists.xensource.com [mailto:xen-devel-bounces@lists.xensource.com] On Behalf Of Zhao, Yu
Sent: Tuesday, April 07, 2009 10:31 AM
To: Isabelle, Francois
Cc: xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] XEN Panic with VT-d support enabled on Xeon E55xx platform
Hi Francois,
Do you have this problem all the times? Can you please grab some logs
and send them to me? The dmesg from a native kernel if you can't boot up
any version of Xen, and the whole Xen hypervisor log would help us to
figure out the problem.
Thanks,
Yu
Isabelle, Francois wrote:
> Hi all,
>
> I'm working with a board on which XEN panics with the following message (see below). From what I can see on the lists, most of the problems on these platforms seem to be related to broken DMAR tables and RMRR, but this platform passes the VT-d firmware toolkit (http://edc.intel.com/Platforms/Xeon-5500/) successfully so I'm tented to blame XEN for it... should I file a bug entry?
>
>>From what I can see in the 'queue invalidation' code, a timeout is reached. As anyone seen this on a similar platform?
>
>
> (XEN) Xen version 3.4-unstable (root@localdomain) (gcc version 4.1.2 20080704 (Red Hat 4.1.2-44)) Fri Apr 3 14:20:00 EDT 2009
> (XEN) Latest ChangeSet: Mon Mar 30 16:48:26 2009 +0100 19433:d5ddc782bc49
> (XEN) Command line: console=com1 com1=115200,8n1 iommu=1 loglvl=all loglvl_guest=all ro
>
> ..
> (XEN) Enabling APIC mode: Flat. Using 1 I/O APICs
> (XEN) ACPI: HPET id: 0xffffffff base: 0xfed00000
> (XEN) [VT-D]dmar.c:485: Host address width 39
> (XEN) [VT-D]dmar.c:494: found ACPI_DMAR_DRHD
> (XEN) [VT-D]dmar.c:349: dmaru->address = fbffe000
> (XEN) [VT-D]dmar.c:306: found IOAPIC: bdf = f0:1f.7
> (XEN) [VT-D]dmar.c:358: found INCLUDE_ALL
> (XEN) [VT-D]dmar.c:498: found ACPI_DMAR_RMRR
> (XEN) [VT-D]dmar.c:300: found endpoint: bdf = 0:1d.0
> (XEN) [VT-D]dmar.c:300: found endpoint: bdf = 0:1d.1
> (XEN) [VT-D]dmar.c:300: found endpoint: bdf = 0:1d.2
> (XEN) [VT-D]dmar.c:300: found endpoint: bdf = 0:1d.7
> (XEN) [VT-D]dmar.c:498: found ACPI_DMAR_RMRR
> (XEN) [VT-D]dmar.c:300: found endpoint: bdf = 0:1d.0
> (XEN) [VT-D]dmar.c:300: found endpoint: bdf = 0:1d.1
> (XEN) [VT-D]dmar.c:300: found endpoint: bdf = 0:1d.2
> (XEN) [VT-D]dmar.c:300: found endpoint: bdf = 0:1d.7
> (XEN) [VT-D]dmar.c:502: found ACPI_DMAR_ATSR
> (XEN) [VT-D]dmar.c:287: found bridge: bdf = 0:3.0 sec = 5 sub = 5
> (XEN) [VT-D]dmar.c:287: found bridge: bdf = 0:4.0 sec = 6 sub = e
> (XEN) [VT-D]dmar.c:287: found bridge: bdf = 0:5.0 sec = 3 sub = 3
> (XEN) [VT-D]dmar.c:287: found bridge: bdf = 0:7.0 sec = 18 sub = 18
> (XEN) [VT-D]dmar.c:287: found bridge: bdf = 0:8.0 sec = f sub = 17
> (XEN) [VT-D]dmar.c:287: found bridge: bdf = 0:9.0 sec = 4 sub = 4
> (XEN) [VT-D]dmar.c:287: found bridge: bdf = 0:a.0 sec = 2 sub = 2
> ..
> (XEN) Intel VT-d Snoop Control supported.
> (XEN) Intel VT-d DMA Passthrough not supported.
> (XEN) Intel VT-d Queued Invalidation supported.
> (XEN) Intel VT-d Interrupt Remapping supported.
> (XEN) DMAR_IQA_REG = 7f79d000
> (XEN) DMAR_IQH_REG = 0
> (XEN) DMAR_IQT_REG = 20
> (XEN)
> (XEN) ****************************************
> (XEN) Panic on CPU 0:
> (XEN) queue invalidate wait descriptor was not executed
> (XEN) ****************************************
> (XEN)
> (XEN) Reboot in five seconds...
>
> François Isabelle
>
> _______________________________________________
> 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
^ permalink raw reply [flat|nested] 12+ messages in thread
* RE: XEN Panic with VT-d support enabled on Xeon E55xxplatform
2009-04-07 14:21 ` Cui, Dexuan
@ 2009-04-07 15:06 ` Isabelle, Francois
2009-04-08 5:54 ` Zhao, Yu
0 siblings, 1 reply; 12+ messages in thread
From: Isabelle, Francois @ 2009-04-07 15:06 UTC (permalink / raw)
To: Cui, Dexuan, Zhao, Yu; +Cc: xen-devel
[-- Attachment #1: Type: text/plain, Size: 9659 bytes --]
>> When you only use iommu=no-intremap and see the panic, can you attached >>the xen log?
>>And can you also try iommu=passthrough,no-intremap and attach the log?
See attached files.
>> VT-d Context Entry is used, the DMA requests related to the Context Entry can bypass DMA remapping. This can be faster than DMA remapping.
The BIOS does not have an option for this on my board. But I did mistook it for DMA remapping.
And thank you for answering my questions.
François Isabelle
-----Message d'origine-----
De : Cui, Dexuan [mailto:dexuan.cui@intel.com]
Envoyé : 7 avril 2009 10:22
À : Isabelle, Francois; Zhao, Yu
Cc : xen-devel@lists.xensource.com
Objet : RE: [Xen-devel] XEN Panic with VT-d support enabled on Xeon E55xxplatform
>>> iommu=xxx
> Dexuan, 'iommu=no-intremap' is not enough to make it run, ' iommu=no-qinval,no-intremap' allows booting.
When you only use iommu=no-intremap and see the panic, can you attached the xen log?
And can you also try iommu=passthrough,no-intremap and attach the log?
>>(XEN) [VT-D]dmar.c:485: Host address width 39
>Shouldn't this be 38 ?
The Host Address Width (HAW) of the platform is computed as (N+1), where N is the value reported in the Host Address Width field of DMA Remapping Reporting Structure.
Please see acpi_parse_dmar() or VT-d spec for details.
>>(XEN) Intel VT-d Snoop Control supported.
>>(XEN) Intel VT-d DMA Passthrough not supported.
> Shouldn't that be enabled to support DMA from domU?
If the "DMA Passthrough" (please don't mistake it for DMA remapping:-) of VT-d Context Entry is used, the DMA requests related to the Context Entry can bypass DMA remapping. This can be faster than DMA remapping. If you host supports DMA passthrough (you could check your BIOS setup menu), in Xen we can enable DMA passthrough by iommu=passthrough (Note, even with this parameter, we only enable passthrough for Dom0 considering secrity)
>>(XEN) HPET broadcast init failed, turn to PIT broadcast.
> Does that mean the HPET is not functional?
>From hpet_fsb_cap_lookup(), looks your HPET timers may work, but they don't support FSB routing, so won't be used in power management code.
>Can we expect a good level of performance with interrupt remapping disabled? Will a domU be able to load a 82576 driver and use the NIC at all?
I think we should have almost the same performance with Interrupt Remapping enabled or disabled.
82576 should work in DomU.
Thanks,
-- Dexuan
-----Original Message-----
From: Isabelle, Francois [mailto:Francois.Isabelle@ca.kontron.com]
Sent: Tuesday, April 07, 2009 9:12 PM
To: Cui, Dexuan; Zhao, Yu
Cc: xen-devel@lists.xensource.com
Subject: RE: [Xen-devel] XEN Panic with VT-d support enabled on Xeon E55xxplatform
Hi.
Here is what you both asked for:
>> Do you have this problem all the times? Can you please grab some logs
>> and send them to me?
Yes Yu, all the times. I will package the logs as attachment to this post.
>> iommu=xxx
Dexuan, 'iommu=no-intremap' is not enough to make it run, ' iommu=no-qinval,no-intremap' allows booting.
Here are some parts of the log I don't understand...
>(XEN) [VT-D]dmar.c:485: Host address width 39
Shouldn't this be 38 ?
>(XEN) Intel VT-d Snoop Control supported.
>(XEN) Intel VT-d DMA Passthrough not supported.
Shouldn't that be enabled to support DMA from domU?
>(XEN) Intel VT-d Queued Invalidation supported.
>(XEN) Intel VT-d Interrupt Remapping supported.
>(XEN) HPET broadcast init failed, turn to PIT broadcast.
Does that mean the HPET is not functional?
Can we expect a good level of performance with interrupt remapping disabled? Will a domU be able to load a 82576 driver and use the NIC at all?
Thank you both for your replies.
François Isabelle
-----Message d'origine-----
De : Cui, Dexuan [mailto:dexuan.cui@intel.com]
Envoyé : 7 avril 2009 03:05
À : Zhao, Yu; Isabelle, Francois
Cc : xen-devel@lists.xensource.com
Objet : RE: [Xen-devel] XEN Panic with VT-d support enabled on Xeon E55xxplatform
>> (XEN) DMAR_IQA_REG = 7f79d000
>> (XEN) DMAR_IQH_REG = 0
>> (XEN) DMAR_IQT_REG = 20
>Here the IQT is such a big number 0x20... this seems pretty strange.
Oh, actually this 0x20 is normal -- actually QT = IQT_REG >> 4 accoriding the format of IQT_REG in VT-d spec. So QT = 0x2 -- this is ok.
So looks the panic somehow happens on the first invalidation: enable_intremap() -> iommu_flush_iec_global(). I expect your host can boot fine with iommu=no-intremap -- if this still doesn't work, could you please try iommu=no-qinval,no-intremap ?
Thanks,
-- Dexuan
-----Original Message-----
From: xen-devel-bounces@lists.xensource.com [mailto:xen-devel-bounces@lists.xensource.com] On Behalf Of Cui, Dexuan
Sent: Tuesday, April 07, 2009 12:40 PM
To: Zhao, Yu; Isabelle, Francois
Cc: xen-devel@lists.xensource.com
Subject: RE: [Xen-devel] XEN Panic with VT-d support enabled on Xeon E55xx platform
> (XEN) DMAR_IQA_REG = 7f79d000
> (XEN) DMAR_IQH_REG = 0
> (XEN) DMAR_IQT_REG = 20
Here the IQT is such a big number 0x20... this seems pretty strange.
Hi François,
And, could you please try the xen parameter "iommu=no-intremap" ? -- If you still see the panic, please also add the parameter "nosmp" to see if there would any change.
We don't have the same host at hand. :-( So we need try these on your host.
BTW, can you boot the same host using the latest native linux-2.6.29-rc8 when you iommu_intel=on and interrupt remapping is enabled?
PS, what's your BIOS version and date -- could you try to find the latest BIOS for the host? I personally tend to think this is a BIOS issue.
Thanks,
-- Dexuan
-----Original Message-----
From: xen-devel-bounces@lists.xensource.com [mailto:xen-devel-bounces@lists.xensource.com] On Behalf Of Zhao, Yu
Sent: Tuesday, April 07, 2009 10:31 AM
To: Isabelle, Francois
Cc: xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] XEN Panic with VT-d support enabled on Xeon E55xx platform
Hi Francois,
Do you have this problem all the times? Can you please grab some logs
and send them to me? The dmesg from a native kernel if you can't boot up
any version of Xen, and the whole Xen hypervisor log would help us to
figure out the problem.
Thanks,
Yu
Isabelle, Francois wrote:
> Hi all,
>
> I'm working with a board on which XEN panics with the following message (see below). From what I can see on the lists, most of the problems on these platforms seem to be related to broken DMAR tables and RMRR, but this platform passes the VT-d firmware toolkit (http://edc.intel.com/Platforms/Xeon-5500/) successfully so I'm tented to blame XEN for it... should I file a bug entry?
>
>>From what I can see in the 'queue invalidation' code, a timeout is reached. As anyone seen this on a similar platform?
>
>
> (XEN) Xen version 3.4-unstable (root@localdomain) (gcc version 4.1.2 20080704 (Red Hat 4.1.2-44)) Fri Apr 3 14:20:00 EDT 2009
> (XEN) Latest ChangeSet: Mon Mar 30 16:48:26 2009 +0100 19433:d5ddc782bc49
> (XEN) Command line: console=com1 com1=115200,8n1 iommu=1 loglvl=all loglvl_guest=all ro
>
> ..
> (XEN) Enabling APIC mode: Flat. Using 1 I/O APICs
> (XEN) ACPI: HPET id: 0xffffffff base: 0xfed00000
> (XEN) [VT-D]dmar.c:485: Host address width 39
> (XEN) [VT-D]dmar.c:494: found ACPI_DMAR_DRHD
> (XEN) [VT-D]dmar.c:349: dmaru->address = fbffe000
> (XEN) [VT-D]dmar.c:306: found IOAPIC: bdf = f0:1f.7
> (XEN) [VT-D]dmar.c:358: found INCLUDE_ALL
> (XEN) [VT-D]dmar.c:498: found ACPI_DMAR_RMRR
> (XEN) [VT-D]dmar.c:300: found endpoint: bdf = 0:1d.0
> (XEN) [VT-D]dmar.c:300: found endpoint: bdf = 0:1d.1
> (XEN) [VT-D]dmar.c:300: found endpoint: bdf = 0:1d.2
> (XEN) [VT-D]dmar.c:300: found endpoint: bdf = 0:1d.7
> (XEN) [VT-D]dmar.c:498: found ACPI_DMAR_RMRR
> (XEN) [VT-D]dmar.c:300: found endpoint: bdf = 0:1d.0
> (XEN) [VT-D]dmar.c:300: found endpoint: bdf = 0:1d.1
> (XEN) [VT-D]dmar.c:300: found endpoint: bdf = 0:1d.2
> (XEN) [VT-D]dmar.c:300: found endpoint: bdf = 0:1d.7
> (XEN) [VT-D]dmar.c:502: found ACPI_DMAR_ATSR
> (XEN) [VT-D]dmar.c:287: found bridge: bdf = 0:3.0 sec = 5 sub = 5
> (XEN) [VT-D]dmar.c:287: found bridge: bdf = 0:4.0 sec = 6 sub = e
> (XEN) [VT-D]dmar.c:287: found bridge: bdf = 0:5.0 sec = 3 sub = 3
> (XEN) [VT-D]dmar.c:287: found bridge: bdf = 0:7.0 sec = 18 sub = 18
> (XEN) [VT-D]dmar.c:287: found bridge: bdf = 0:8.0 sec = f sub = 17
> (XEN) [VT-D]dmar.c:287: found bridge: bdf = 0:9.0 sec = 4 sub = 4
> (XEN) [VT-D]dmar.c:287: found bridge: bdf = 0:a.0 sec = 2 sub = 2
> ..
> (XEN) Intel VT-d Snoop Control supported.
> (XEN) Intel VT-d DMA Passthrough not supported.
> (XEN) Intel VT-d Queued Invalidation supported.
> (XEN) Intel VT-d Interrupt Remapping supported.
> (XEN) DMAR_IQA_REG = 7f79d000
> (XEN) DMAR_IQH_REG = 0
> (XEN) DMAR_IQT_REG = 20
> (XEN)
> (XEN) ****************************************
> (XEN) Panic on CPU 0:
> (XEN) queue invalidate wait descriptor was not executed
> (XEN) ****************************************
> (XEN)
> (XEN) Reboot in five seconds...
>
> François Isabelle
>
> _______________________________________________
> 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
[-- Attachment #2: xen-unstable-iommu-no-intremap.txt --]
[-- Type: text/plain, Size: 14867 bytes --]
root (hd0,0)
Filesystem type is ext2fs, partition type 0x83
kernel /boot/xen.gz console=com1 com1=115200,8n1 iommu=no-intremap loglvl=all
loglvl_guest=all ro
[Multiboot-elf, <0x100000:0x13b768:0x8e898>, shtab=0x2ca078, entry=0x100000]
module /boot/vmlinuz-2.6.18.8-xenkci ro root=LABEL=/ console=ttyS0,115200,8n1
pciback.hide=(04:00.0)(04:00.1) pciback.verbose_request=1
[Multiboot-module @ 0x2cb000, 0x76f7d8 bytes]
module /boot/initrd-2.6.18-xenkci.img
[Multiboot-module @ 0xa3b000, 0x443600 bytes] __ __ _____ _ _ _ _ _
\ \/ /___ _ __ |___ /| || | _ _ _ __ ___| |_ __ _| |__ | | ___
\ // _ \ '_ \ |_ \| || |_ __| | | | '_ \/ __| __/ _` | '_ \| |/ _ \
/ \ __/ | | | ___) |__ _|__| |_| | | | \__ \ || (_| | |_) | | __/
/_/\_\___|_| |_| |____(_) |_| \__,_|_| |_|___/\__\__,_|_.__/|_|\___|
(XEN) Xen version 3.4-unstable (root@localdomain) (gcc version 4.1.2 20080704 (Red Hat 4.1.2-44)) Fri Apr 3 14:20:00 EDT 2009
(XEN) Latest ChangeSet: Mon Mar 30 16:48:26 2009 +0100 19433:d5ddc782bc49
(XEN) Command line: console=com1 com1=115200,8n1 iommu=no-intremap loglvl=all loglvl_guest=all ro
(XEN) Video information:
(XEN) No VGA detected
(XEN) Disc information:
(XEN) Found 1 MBR signatures
(XEN) Found 1 EDD information structures
(XEN) Xen-e820 RAM map:
(XEN) 0000000000000000 - 000000000009a800 (usable)
(XEN) 000000000009a800 - 00000000000a0000 (reserved)
(XEN) 00000000000e4000 - 0000000000100000 (reserved)
(XEN) 0000000000100000 - 000000007f7b0000 (usable)
(XEN) 000000007f7b0000 - 000000007f7be000 (ACPI data)
(XEN) 000000007f7be000 - 000000007f7d0000 (ACPI NVS)
(XEN) 000000007f7d0000 - 000000007f7e0000 (reserved)
(XEN) 000000007f7ed000 - 0000000080000000 (reserved)
(XEN) 00000000e0000000 - 00000000f0000000 (reserved)
(XEN) 00000000fee00000 - 00000000fee01000 (reserved)
(XEN) 00000000ffb00000 - 0000000100000000 (reserved)
(XEN) System RAM: 2039MB (2088232kB)
(XEN) ACPI: RSDP 000FA6B0, 0024 (r2 ACPIAM)
(XEN) ACPI: XSDT 7F7B0100, 005C (r1 031209 XSDT0910 20090312 MSFT 97)
(XEN) ACPI: FACP 7F7B0290, 00F4 (r4 031209 FACP0910 20090312 MSFT 97)
(XEN) ACPI: DSDT 7F7B04B0, 4FFD (r2 5007_ 5007_115 115 INTL 20051117)
(XEN) ACPI: FACS 7F7BE000, 0040
(XEN) ACPI: APIC 7F7B0390, 008C (r2 031209 APIC0910 20090312 MSFT 97)
(XEN) ACPI: MCFG 7F7B0470, 003C (r1 031209 OEMMCFG 20090312 MSFT 97)
(XEN) ACPI: OEMB 7F7BE040, 0072 (r1 031209 OEMB0910 20090312 MSFT 97)
(XEN) ACPI: HPET 7F7BA4B0, 0038 (r1 031209 OEMHPET 20090312 MSFT 97)
(XEN) ACPI: DMAR 7F7BE0C0, 00F8 (r1 AMI OEMDMAR 1 MSFT 97)
(XEN) ACPI: SSDT 7F7BFC10, 0363 (r1 DpgPmm CpuPm 12 INTL 20051117)
(XEN) NUMA turned off
(XEN) Faking a node at 0000000000000000-000000007f7b0000
(XEN) Domain heap initialised
(XEN) found SMP MP-table at 000ff780
(XEN) DMI present.
(XEN) Using APIC driver default
(XEN) ACPI: PM-Timer IO Port: 0x808
(XEN) ACPI: ACPI SLEEP INFO: pm1x_cnt[804,0], pm1x_evt[800,0]
(XEN) ACPI: wakeup_vec[7f7be00c], vec_size[20]
(XEN) ACPI: Local APIC address 0xfee00000
(XEN) ACPI: LAPIC (acpi_id[0x01] lapic_id[0x00] enabled)
(XEN) Processor #0 7:10 APIC version 21
(XEN) ACPI: LAPIC (acpi_id[0x02] lapic_id[0x02] enabled)
(XEN) Processor #2 7:10 APIC version 21
(XEN) ACPI: LAPIC (acpi_id[0x03] lapic_id[0x04] enabled)
(XEN) Processor #4 7:10 APIC version 21
(XEN) ACPI: LAPIC (acpi_id[0x04] lapic_id[0x06] enabled)
(XEN) Processor #6 7:10 APIC version 21
(XEN) ACPI: LAPIC (acpi_id[0x05] lapic_id[0x01] enabled)
(XEN) Processor #1 7:10 APIC version 21
(XEN) ACPI: LAPIC (acpi_id[0x06] lapic_id[0x03] enabled)
(XEN) Processor #3 7:10 APIC version 21
(XEN) ACPI: LAPIC (acpi_id[0x07] lapic_id[0x05] enabled)
(XEN) Processor #5 7:10 APIC version 21
(XEN) ACPI: LAPIC (acpi_id[0x08] lapic_id[0x07] enabled)
(XEN) Processor #7 7:10 APIC version 21
(XEN) ACPI: IOAPIC (id[0x08] address[0xfec00000] gsi_base[0])
(XEN) IOAPIC[0]: apic_id 8, version 32, address 0xfec00000, GSI 0-23
(XEN) ACPI: INT_SRC_OVR (bus 0 bus_irq 0 global_irq 2 dfl dfl)
(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 1 I/O APICs
(XEN) ACPI: HPET id: 0xffffffff base: 0xfed00000
(XEN) [VT-D]dmar.c:485: Host address width 39
(XEN) [VT-D]dmar.c:494: found ACPI_DMAR_DRHD
(XEN) [VT-D]dmar.c:349: dmaru->address = fbffe000
(XEN) [VT-D]dmar.c:306: found IOAPIC: bdf = f0:1f.7
(XEN) [VT-D]dmar.c:358: found INCLUDE_ALL
(XEN) [VT-D]dmar.c:498: found ACPI_DMAR_RMRR
(XEN) [VT-D]dmar.c:300: found endpoint: bdf = 0:1d.0
(XEN) [VT-D]dmar.c:300: found endpoint: bdf = 0:1d.1
(XEN) [VT-D]dmar.c:300: found endpoint: bdf = 0:1d.2
(XEN) [VT-D]dmar.c:300: found endpoint: bdf = 0:1d.7
(XEN) [VT-D]dmar.c:498: found ACPI_DMAR_RMRR
(XEN) [VT-D]dmar.c:300: found endpoint: bdf = 0:1d.0
(XEN) [VT-D]dmar.c:300: found endpoint: bdf = 0:1d.1
(XEN) [VT-D]dmar.c:300: found endpoint: bdf = 0:1d.2
(XEN) [VT-D]dmar.c:300: found endpoint: bdf = 0:1d.7
(XEN) [VT-D]dmar.c:502: found ACPI_DMAR_ATSR
(XEN) [VT-D]dmar.c:287: found bridge: bdf = 0:3.0 sec = 5 sub = 5
(XEN) [VT-D]dmar.c:287: found bridge: bdf = 0:4.0 sec = 6 sub = 6
(XEN) [VT-D]dmar.c:287: found bridge: bdf = 0:5.0 sec = 3 sub = 3
(XEN) [VT-D]dmar.c:287: found bridge: bdf = 0:7.0 sec = 8 sub = 8
(XEN) [VT-D]dmar.c:287: found bridge: bdf = 0:8.0 sec = 7 sub = 7
(XEN) [VT-D]dmar.c:287: found bridge: bdf = 0:9.0 sec = 4 sub = 4
(XEN) [VT-D]dmar.c:287: found bridge: bdf = 0:a.0 sec = 2 sub = 2
(XEN) Intel VT-d DMAR tables have been parsed.
(XEN) Using ACPI (MADT) for SMP configuration information
(XEN) Using scheduler: SMP Credit Scheduler (credit)
(XEN) Initializing CPU#0
(XEN) Detected 2128.066 MHz processor.
(XEN) , L1 D cache: 32K
(XEN) CPU: Physical Processor 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) CPU0: Thermal monitoring enabled (TM1)
(XEN) CMCI: find owner on CPU0
(XEN) CMCI: CPU0 owner_map[16c], no_cmci_map[93]
(XEN) CPU0: Intel(R) Xeon(R) CPU L5518 @ 2.13GHz stepping 05
(XEN) Booting processor 1/2 eip 8c000
(XEN) Initializing CPU#1
(XEN) , L1 D cache: 32K
(XEN) CPU: Physical Processor ID: 0
(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 L5518 @ 2.13GHz stepping 05
(XEN) Booting processor 2/4 eip 8c000
(XEN) Initializing CPU#2
(XEN) , L1 D cache: 32K
(XEN) CPU: Physical Processor ID: 0
(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 L5518 @ 2.13GHz stepping 05
(XEN) Booting processor 3/6 eip 8c000
(XEN) Initializing CPU#3
(XEN) , L1 D cache: 32K
(XEN) CPU: Physical Processor ID: 0
(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 L5518 @ 2.13GHz stepping 05
(XEN) Booting processor 4/1 eip 8c000
(XEN) Initializing CPU#4
(XEN) , L1 D cache: 32K
(XEN) CPU: Physical Processor ID: 0
(XEN) Intel machine check reporting enabled on CPU#4.
(XEN) CPU4: Thermal monitoring enabled (TM1)
(XEN) CMCI: find owner on CPU4
(XEN) CMCI: CPU4 owner_map[0], no_cmci_map[93]
(XEN) CPU4: Intel(R) Xeon(R) CPU L5518 @ 2.13GHz stepping 05
(XEN) Booting processor 5/3 eip 8c000
(XEN) Initializing CPU#5
(XEN) , L1 D cache: 32K
(XEN) CPU: Physical Processor ID: 0
(XEN) Intel machine check reporting enabled on CPU#5.
(XEN) CPU5: Thermal monitoring enabled (TM1)
(XEN) CMCI: find owner on CPU5
(XEN) CMCI: CPU5 owner_map[0], no_cmci_map[93]
(XEN) CPU5: Intel(R) Xeon(R) CPU L5518 @ 2.13GHz stepping 05
(XEN) Booting processor 6/5 eip 8c000
(XEN) Initializing CPU#6
(XEN) , L1 D cache: 32K
(XEN) CPU: Physical Processor ID: 0
(XEN) Intel machine check reporting enabled on CPU#6.
(XEN) CPU6: Thermal monitoring enabled (TM1)
(XEN) CMCI: find owner on CPU6
(XEN) CMCI: CPU6 owner_map[0], no_cmci_map[93]
(XEN) CPU6: Intel(R) Xeon(R) CPU L5518 @ 2.13GHz stepping 05
(XEN) Booting processor 7/7 eip 8c000
(XEN) Initializing CPU#7
(XEN) , L1 D cache: 32K
(XEN) CPU: Physical Processor ID: 0
(XEN) Intel machine check reporting enabled on CPU#7.
(XEN) CPU7: Thermal monitoring enabled (TM1)
(XEN) CMCI: find owner on CPU7
(XEN) CMCI: CPU7 owner_map[0], no_cmci_map[93]
(XEN) CPU7: Intel(R) Xeon(R) CPU L5518 @ 2.13GHz stepping 05
(XEN) Total of 8 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 8 CPUs: passed.
(XEN) Platform timer is 14.318MHz HPET
(XEN) microcode.c:73:d32767 microcode: CPU1 resumed
(XEN) microcode.c:73:d32767 microcode: CPU3 resumed
(XEN) microcode.c:73:d32767 microcode: CPU5 resumed
(XEN) microcode.c:73:d32767 microcode: CPU7 resumed
(XEN) Brought up 8 CPUs
(XEN) microcode.c:73:d32767 microcode: CPU6 resumed
(XEN) microcode.c:73:d32767 microcode: CPU4 resumed
(XEN) microcode.c:73:d32767 microcode: CPU2 resumed
(XEN) Intel VT-d Snoop Control supported.
(XEN) Intel VT-d DMA Passthrough not supported.
(XEN) Intel VT-d Queued Invalidation supported.
(XEN) Intel VT-d Interrupt Remapping not supported.
(XEN) I/O virtualisation enabled
(XEN) I/O virtualisation for PV guests disabled
(XEN) HPET: 4 timers in total, 0 timers will be used for broadcast
(XEN) HPET broadcast init failed, turn to PIT broadcast.
(XEN) ACPI sleep modes: S3
(XEN) mcheck_poll: Machine check polling timer started.
(XEN) [VT-D]iommu.c:1230:d32767 domain_context_mapping:PCIe: bdf = 0:0.0
(XEN) [VT-D]iommu.c:1230:d32767 domain_context_mapping:PCIe: bdf = 0:14.0
(XEN) [VT-D]iommu.c:1230:d32767 domain_context_mapping:PCIe: bdf = 0:14.1
(XEN) [VT-D]iommu.c:1230:d32767 domain_context_mapping:PCIe: bdf = 0:14.2
(XEN) [VT-D]iommu.c:1237:d32767 domain_context_mapping:PCI: bdf = 0:14.3
(XEN) [VT-D]iommu.c:1230:d32767 domain_context_mapping:PCIe: bdf = 0:16.0
(XEN) [VT-D]iommu.c:1230:d32767 domain_context_mapping:PCIe: bdf = 0:16.1
(XEN) [VT-D]iommu.c:1230:d32767 domain_context_mapping:PCIe: bdf = 0:16.2
(XEN) [VT-D]iommu.c:1230:d32767 domain_context_mapping:PCIe: bdf = 0:16.3
(XEN) [VT-D]iommu.c:1230:d32767 domain_context_mapping:PCIe: bdf = 0:16.4
(XEN) [VT-D]iommu.c:1230:d32767 domain_context_mapping:PCIe: bdf = 0:16.5
(XEN) [VT-D]iommu.c:1230:d32767 domain_context_mapping:PCIe: bdf = 0:16.6
(XEN) [VT-D]iommu.c:1230:d32767 domain_context_mapping:PCIe: bdf = 0:16.7
(XEN) [VT-D]iommu.c:1237:d32767 domain_context_mapping:PCI: bdf = 0:1d.0
(XEN) [VT-D]iommu.c:1237:d32767 domain_context_mapping:PCI: bdf = 0:1d.1
(XEN) [VT-D]iommu.c:1237:d32767 domain_context_mapping:PCI: bdf = 0:1d.2
(XEN) [VT-D]iommu.c:1237:d32767 domain_context_mapping:PCI: bdf = 0:1d.7
(XEN) [VT-D]iommu.c:1237:d32767 domain_context_mapping:PCI: bdf = 0:1f.0
(XEN) [VT-D]iommu.c:1237:d32767 domain_context_mapping:PCI: bdf = 0:1f.2
(XEN) [VT-D]iommu.c:1237:d32767 domain_context_mapping:PCI: bdf = 0:1f.3
(XEN) [VT-D]iommu.c:1230:d32767 domain_context_mapping:PCIe: bdf = 2:0.0
(XEN) [VT-D]iommu.c:1230:d32767 domain_context_mapping:PCIe: bdf = 2:0.1
(XEN) [VT-D]iommu.c:1230:d32767 domain_context_mapping:PCIe: bdf = 3:0.0
(XEN) [VT-D]iommu.c:1230:d32767 domain_context_mapping:PCIe: bdf = 3:0.1
(XEN) [VT-D]iommu.c:1230:d32767 domain_context_mapping:PCIe: bdf = 4:0.0
(XEN) [VT-D]iommu.c:1230:d32767 domain_context_mapping:PCIe: bdf = 4:0.1
(XEN) [VT-D]iommu.c:1230:d32767 domain_context_mapping:PCIe: bdf = 6:0.0
(XEN) [VT-D]iommu.c:1237:d32767 domain_context_mapping:PCI: bdf = fe:0.0
(XEN) [VT-D]iommu.c:1237:d32767 domain_context_mapping:PCI: bdf = fe:0.1
(XEN) [VT-D]iommu.c:1237:d32767 domain_context_mapping:PCI: bdf = fe:2.0
(XEN) [VT-D]iommu.c:1237:d32767 domain_context_mapping:PCI: bdf = fe:2.1
(XEN) [VT-D]iommu.c:1237:d32767 domain_context_mapping:PCI: bdf = fe:2.4
(XEN) [VT-D]iommu.c:1237:d32767 domain_context_mapping:PCI: bdf = fe:2.5
(XEN) [VT-D]iommu.c:1237:d32767 domain_context_mapping:PCI: bdf = fe:3.0
(XEN) [VT-D]iommu.c:1237:d32767 domain_context_mapping:PCI: bdf = fe:3.1
(XEN) [VT-D]iommu.c:1237:d32767 domain_context_mapping:PCI: bdf = fe:3.2
(XEN) [VT-D]iommu.c:1237:d32767 domain_context_mapping:PCI: bdf = fe:3.4
(XEN) [VT-D]iommu.c:1237:d32767 domain_context_mapping:PCI: bdf = fe:4.0
(XEN) [VT-D]iommu.c:1237:d32767 domain_context_mapping:PCI: bdf = fe:4.1
(XEN) [VT-D]iommu.c:1237:d32767 domain_context_mapping:PCI: bdf = fe:4.2
(XEN) [VT-D]iommu.c:1237:d32767 domain_context_mapping:PCI: bdf = fe:4.3
(XEN) [VT-D]iommu.c:1237:d32767 domain_context_mapping:PCI: bdf = fe:5.0
(XEN) [VT-D]iommu.c:1237:d32767 domain_context_mapping:PCI: bdf = fe:5.1
(XEN) [VT-D]iommu.c:1237:d32767 domain_context_mapping:PCI: bdf = fe:5.2
(XEN) [VT-D]iommu.c:1237:d32767 domain_context_mapping:PCI: bdf = fe:5.3
(XEN) [VT-D]iommu.c:1237:d32767 domain_context_mapping:PCI: bdf = fe:6.0
(XEN) [VT-D]iommu.c:1237:d32767 domain_context_mapping:PCI: bdf = fe:6.1
(XEN) [VT-D]iommu.c:1237:d32767 domain_context_mapping:PCI: bdf = fe:6.2
(XEN) [VT-D]iommu.c:1237:d32767 domain_context_mapping:PCI: bdf = fe:6.3
(XEN) [VT-D]iommu.c:1237:d32767 domain_context_mapping:PCI: bdf = 0:1d.0
(XEN) DMAR_IQA_REG = 7f79d000
(XEN) DMAR_IQH_REG = 0
(XEN) DMAR_IQT_REG = 20
(XEN)
(XEN) ****************************************
(XEN) Panic on CPU 0:
(XEN) queue invalidate wait descriptor was not executed
(XEN) ****************************************
(XEN)
(XEN) Reboot in five seconds...
[-- Attachment #3: xen-unstable-iommu-passthrough-no-intremap.txt --]
[-- Type: text/plain, Size: 14848 bytes --]
root (hd0,0)
Filesystem type is ext2fs, partition type 0x83
kernel /boot/xen.gz console=com1 com1=115200,8n1 iommu=passthrough,no-intremap
loglvl=all loglvl_guest=all ro
[Multiboot-elf, <0x100000:0x13b768:0x8e898>, shtab=0x2ca078, entry=0x100000]
module /boot/vmlinuz-2.6.18.8-xenkci ro root=LABEL=/ console=ttyS0,115200,8n1
pciback.hide=(04:00.0)(04:00.1) pciback.verbose_request=1
[Multiboot-module @ 0x2cb000, 0x76f7d8 bytes]
module /boot/initrd-2.6.18-xenkci.img
[Multiboot-module @ 0xa3b000, 0x443600 bytes]
__ __ _____ _ _ _ _ _
\ \/ /___ _ __ |___ /| || | _ _ _ __ ___| |_ __ _| |__ | | ___
\ // _ \ '_ \ |_ \| || |_ __| | | | '_ \/ __| __/ _` | '_ \| |/ _ \
/ \ __/ | | | ___) |__ _|__| |_| | | | \__ \ || (_| | |_) | | __/
/_/\_\___|_| |_| |____(_) |_| \__,_|_| |_|___/\__\__,_|_.__/|_|\___|
(XEN) Xen version 3.4-unstable (root@localdomain) (gcc version 4.1.2 20080704 (Red Hat 4.1.2-44)) Fri Apr 3 14:20:00 EDT 2009
(XEN) Latest ChangeSet: Mon Mar 30 16:48:26 2009 +0100 19433:d5ddc782bc49
(XEN) Command line: console=com1 com1=115200,8n1 iommu=passthrough,no-intremap loglvl=all loglvl_guest=all ro
(XEN) Video information:
(XEN) No VGA detected
(XEN) Disc information:
(XEN) Found 1 MBR signatures
(XEN) Found 1 EDD information structures
(XEN) Xen-e820 RAM map:
(XEN) 0000000000000000 - 000000000009a800 (usable)
(XEN) 000000000009a800 - 00000000000a0000 (reserved)
(XEN) 00000000000e4000 - 0000000000100000 (reserved)
(XEN) 0000000000100000 - 000000007f7b0000 (usable)
(XEN) 000000007f7b0000 - 000000007f7be000 (ACPI data)
(XEN) 000000007f7be000 - 000000007f7d0000 (ACPI NVS)
(XEN) 000000007f7d0000 - 000000007f7e0000 (reserved)
(XEN) 000000007f7ed000 - 0000000080000000 (reserved)
(XEN) 00000000e0000000 - 00000000f0000000 (reserved)
(XEN) 00000000fee00000 - 00000000fee01000 (reserved)
(XEN) 00000000ffb00000 - 0000000100000000 (reserved)
(XEN) System RAM: 2039MB (2088232kB)
(XEN) ACPI: RSDP 000FA6B0, 0024 (r2 ACPIAM)
(XEN) ACPI: XSDT 7F7B0100, 005C (r1 031209 XSDT0910 20090312 MSFT 97)
(XEN) ACPI: FACP 7F7B0290, 00F4 (r4 031209 FACP0910 20090312 MSFT 97)
(XEN) ACPI: DSDT 7F7B04B0, 4FFD (r2 5007_ 5007_115 115 INTL 20051117)
(XEN) ACPI: FACS 7F7BE000, 0040
(XEN) ACPI: APIC 7F7B0390, 008C (r2 031209 APIC0910 20090312 MSFT 97)
(XEN) ACPI: MCFG 7F7B0470, 003C (r1 031209 OEMMCFG 20090312 MSFT 97)
(XEN) ACPI: OEMB 7F7BE040, 0072 (r1 031209 OEMB0910 20090312 MSFT 97)
(XEN) ACPI: HPET 7F7BA4B0, 0038 (r1 031209 OEMHPET 20090312 MSFT 97)
(XEN) ACPI: DMAR 7F7BE0C0, 00F8 (r1 AMI OEMDMAR 1 MSFT 97)
(XEN) ACPI: SSDT 7F7BFC10, 0363 (r1 DpgPmm CpuPm 12 INTL 20051117)
(XEN) NUMA turned off
(XEN) Faking a node at 0000000000000000-000000007f7b0000
(XEN) Domain heap initialised
(XEN) found SMP MP-table at 000ff780
(XEN) DMI present.
(XEN) Using APIC driver default
(XEN) ACPI: PM-Timer IO Port: 0x808
(XEN) ACPI: ACPI SLEEP INFO: pm1x_cnt[804,0], pm1x_evt[800,0]
(XEN) ACPI: wakeup_vec[7f7be00c], vec_size[20]
(XEN) ACPI: Local APIC address 0xfee00000
(XEN) ACPI: LAPIC (acpi_id[0x01] lapic_id[0x00] enabled)
(XEN) Processor #0 7:10 APIC version 21
(XEN) ACPI: LAPIC (acpi_id[0x02] lapic_id[0x02] enabled)
(XEN) Processor #2 7:10 APIC version 21
(XEN) ACPI: LAPIC (acpi_id[0x03] lapic_id[0x04] enabled)
(XEN) Processor #4 7:10 APIC version 21
(XEN) ACPI: LAPIC (acpi_id[0x04] lapic_id[0x06] enabled)
(XEN) Processor #6 7:10 APIC version 21
(XEN) ACPI: LAPIC (acpi_id[0x05] lapic_id[0x01] enabled)
(XEN) Processor #1 7:10 APIC version 21
(XEN) ACPI: LAPIC (acpi_id[0x06] lapic_id[0x03] enabled)
(XEN) Processor #3 7:10 APIC version 21
(XEN) ACPI: LAPIC (acpi_id[0x07] lapic_id[0x05] enabled)
(XEN) Processor #5 7:10 APIC version 21
(XEN) ACPI: LAPIC (acpi_id[0x08] lapic_id[0x07] enabled)
(XEN) Processor #7 7:10 APIC version 21
(XEN) ACPI: IOAPIC (id[0x08] address[0xfec00000] gsi_base[0])
(XEN) IOAPIC[0]: apic_id 8, version 32, address 0xfec00000, GSI 0-23
(XEN) ACPI: INT_SRC_OVR (bus 0 bus_irq 0 global_irq 2 dfl dfl)
(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 1 I/O APICs
(XEN) ACPI: HPET id: 0xffffffff base: 0xfed00000
(XEN) [VT-D]dmar.c:485: Host address width 39
(XEN) [VT-D]dmar.c:494: found ACPI_DMAR_DRHD
(XEN) [VT-D]dmar.c:349: dmaru->address = fbffe000
(XEN) [VT-D]dmar.c:306: found IOAPIC: bdf = f0:1f.7
(XEN) [VT-D]dmar.c:358: found INCLUDE_ALL
(XEN) [VT-D]dmar.c:498: found ACPI_DMAR_RMRR
(XEN) [VT-D]dmar.c:300: found endpoint: bdf = 0:1d.0
(XEN) [VT-D]dmar.c:300: found endpoint: bdf = 0:1d.1
(XEN) [VT-D]dmar.c:300: found endpoint: bdf = 0:1d.2
(XEN) [VT-D]dmar.c:300: found endpoint: bdf = 0:1d.7
(XEN) [VT-D]dmar.c:498: found ACPI_DMAR_RMRR
(XEN) [VT-D]dmar.c:300: found endpoint: bdf = 0:1d.0
(XEN) [VT-D]dmar.c:300: found endpoint: bdf = 0:1d.1
(XEN) [VT-D]dmar.c:300: found endpoint: bdf = 0:1d.2
(XEN) [VT-D]dmar.c:300: found endpoint: bdf = 0:1d.7
(XEN) [VT-D]dmar.c:502: found ACPI_DMAR_ATSR
(XEN) [VT-D]dmar.c:287: found bridge: bdf = 0:3.0 sec = 5 sub = 5
(XEN) [VT-D]dmar.c:287: found bridge: bdf = 0:4.0 sec = 6 sub = 6
(XEN) [VT-D]dmar.c:287: found bridge: bdf = 0:5.0 sec = 3 sub = 3
(XEN) [VT-D]dmar.c:287: found bridge: bdf = 0:7.0 sec = 8 sub = 8
(XEN) [VT-D]dmar.c:287: found bridge: bdf = 0:8.0 sec = 7 sub = 7
(XEN) [VT-D]dmar.c:287: found bridge: bdf = 0:9.0 sec = 4 sub = 4
(XEN) [VT-D]dmar.c:287: found bridge: bdf = 0:a.0 sec = 2 sub = 2
(XEN) Intel VT-d DMAR tables have been parsed.
(XEN) Using ACPI (MADT) for SMP configuration information
(XEN) Using scheduler: SMP Credit Scheduler (credit)
(XEN) Initializing CPU#0
(XEN) Detected 2128.070 MHz processor.
(XEN) , L1 D cache: 32K
(XEN) CPU: Physical Processor 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) 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 L5518 @ 2.13GHz stepping 05
(XEN) Booting processor 1/2 eip 8c000
(XEN) Initializing CPU#1
(XEN) , L1 D cache: 32K
(XEN) CPU: Physical Processor ID: 0
(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 L5518 @ 2.13GHz stepping 05
(XEN) Booting processor 2/4 eip 8c000
(XEN) Initializing CPU#2
(XEN) , L1 D cache: 32K
(XEN) CPU: Physical Processor ID: 0
(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 L5518 @ 2.13GHz stepping 05
(XEN) Booting processor 3/6 eip 8c000
(XEN) Initializing CPU#3
(XEN) , L1 D cache: 32K
(XEN) CPU: Physical Processor ID: 0
(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 L5518 @ 2.13GHz stepping 05
(XEN) Booting processor 4/1 eip 8c000
(XEN) Initializing CPU#4
(XEN) , L1 D cache: 32K
(XEN) CPU: Physical Processor ID: 0
(XEN) Intel machine check reporting enabled on CPU#4.
(XEN) CPU4: Thermal monitoring enabled (TM1)
(XEN) CMCI: find owner on CPU4
(XEN) CMCI: CPU4 owner_map[0], no_cmci_map[93]
(XEN) CPU4: Intel(R) Xeon(R) CPU L5518 @ 2.13GHz stepping 05
(XEN) Booting processor 5/3 eip 8c000
(XEN) Initializing CPU#5
(XEN) , L1 D cache: 32K
(XEN) CPU: Physical Processor ID: 0
(XEN) Intel machine check reporting enabled on CPU#5.
(XEN) CPU5: Thermal monitoring enabled (TM1)
(XEN) CMCI: find owner on CPU5
(XEN) CMCI: CPU5 owner_map[0], no_cmci_map[93]
(XEN) CPU5: Intel(R) Xeon(R) CPU L5518 @ 2.13GHz stepping 05
(XEN) Booting processor 6/5 eip 8c000
(XEN) Initializing CPU#6
(XEN) , L1 D cache: 32K
(XEN) CPU: Physical Processor ID: 0
(XEN) Intel machine check reporting enabled on CPU#6.
(XEN) CPU6: Thermal monitoring enabled (TM1)
(XEN) CMCI: find owner on CPU6
(XEN) CMCI: CPU6 owner_map[0], no_cmci_map[93]
(XEN) CPU6: Intel(R) Xeon(R) CPU L5518 @ 2.13GHz stepping 05
(XEN) Booting processor 7/7 eip 8c000
(XEN) Initializing CPU#7
(XEN) , L1 D cache: 32K
(XEN) CPU: Physical Processor ID: 0
(XEN) Intel machine check reporting enabled on CPU#7.
(XEN) CPU7: Thermal monitoring enabled (TM1)
(XEN) CMCI: find owner on CPU7
(XEN) CMCI: CPU7 owner_map[0], no_cmci_map[93]
(XEN) CPU7: Intel(R) Xeon(R) CPU L5518 @ 2.13GHz stepping 05
(XEN) Total of 8 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 8 CPUs: passed.
(XEN) Platform timer is 14.318MHz HPET
(XEN) microcode.c:73:d32767 microcode: CPU1 resumed
(XEN) microcode.c:73:d32767 microcode: CPU4 resumed
(XEN) microcode.c:73:d32767 microcode: CPU6 resumed
(XEN) microcode.c:73:d32767 microcode: CPU3 resumed
(XEN) Brought up 8 CPUs
(XEN) microcode.c:73:d32767 microcode: CPU5 resumed
(XEN) microcode.c:73:d32767 microcode: CPU7 resumed
(XEN) microcode.c:73:d32767 microcode: CPU2 resumed
(XEN) Intel VT-d Snoop Control supported.
(XEN) Intel VT-d DMA Passthrough supported.
(XEN) Intel VT-d Queued Invalidation supported.
(XEN) Intel VT-d Interrupt Remapping not supported.
(XEN) I/O virtualisation enabled
(XEN) I/O virtualisation for PV guests disabled
(XEN) HPET: 4 timers in total, 0 timers will be used for broadcast
(XEN) HPET broadcast init failed, turn to PIT broadcast.
(XEN) ACPI sleep modes: S3
(XEN) mcheck_poll: Machine check polling timer started.
(XEN) [VT-D]iommu.c:1230:d32767 domain_context_mapping:PCIe: bdf = 0:0.0
(XEN) [VT-D]iommu.c:1230:d32767 domain_context_mapping:PCIe: bdf = 0:14.0
(XEN) [VT-D]iommu.c:1230:d32767 domain_context_mapping:PCIe: bdf = 0:14.1
(XEN) [VT-D]iommu.c:1230:d32767 domain_context_mapping:PCIe: bdf = 0:14.2
(XEN) [VT-D]iommu.c:1237:d32767 domain_context_mapping:PCI: bdf = 0:14.3
(XEN) [VT-D]iommu.c:1230:d32767 domain_context_mapping:PCIe: bdf = 0:16.0
(XEN) [VT-D]iommu.c:1230:d32767 domain_context_mapping:PCIe: bdf = 0:16.1
(XEN) [VT-D]iommu.c:1230:d32767 domain_context_mapping:PCIe: bdf = 0:16.2
(XEN) [VT-D]iommu.c:1230:d32767 domain_context_mapping:PCIe: bdf = 0:16.3
(XEN) [VT-D]iommu.c:1230:d32767 domain_context_mapping:PCIe: bdf = 0:16.4
(XEN) [VT-D]iommu.c:1230:d32767 domain_context_mapping:PCIe: bdf = 0:16.5
(XEN) [VT-D]iommu.c:1230:d32767 domain_context_mapping:PCIe: bdf = 0:16.6
(XEN) [VT-D]iommu.c:1230:d32767 domain_context_mapping:PCIe: bdf = 0:16.7
(XEN) [VT-D]iommu.c:1237:d32767 domain_context_mapping:PCI: bdf = 0:1d.0
(XEN) [VT-D]iommu.c:1237:d32767 domain_context_mapping:PCI: bdf = 0:1d.1
(XEN) [VT-D]iommu.c:1237:d32767 domain_context_mapping:PCI: bdf = 0:1d.2
(XEN) [VT-D]iommu.c:1237:d32767 domain_context_mapping:PCI: bdf = 0:1d.7
(XEN) [VT-D]iommu.c:1237:d32767 domain_context_mapping:PCI: bdf = 0:1f.0
(XEN) [VT-D]iommu.c:1237:d32767 domain_context_mapping:PCI: bdf = 0:1f.2
(XEN) [VT-D]iommu.c:1237:d32767 domain_context_mapping:PCI: bdf = 0:1f.3
(XEN) [VT-D]iommu.c:1230:d32767 domain_context_mapping:PCIe: bdf = 2:0.0
(XEN) [VT-D]iommu.c:1230:d32767 domain_context_mapping:PCIe: bdf = 2:0.1
(XEN) [VT-D]iommu.c:1230:d32767 domain_context_mapping:PCIe: bdf = 3:0.0
(XEN) [VT-D]iommu.c:1230:d32767 domain_context_mapping:PCIe: bdf = 3:0.1
(XEN) [VT-D]iommu.c:1230:d32767 domain_context_mapping:PCIe: bdf = 4:0.0
(XEN) [VT-D]iommu.c:1230:d32767 domain_context_mapping:PCIe: bdf = 4:0.1
(XEN) [VT-D]iommu.c:1230:d32767 domain_context_mapping:PCIe: bdf = 6:0.0
(XEN) [VT-D]iommu.c:1237:d32767 domain_context_mapping:PCI: bdf = fe:0.0
(XEN) [VT-D]iommu.c:1237:d32767 domain_context_mapping:PCI: bdf = fe:0.1
(XEN) [VT-D]iommu.c:1237:d32767 domain_context_mapping:PCI: bdf = fe:2.0
(XEN) [VT-D]iommu.c:1237:d32767 domain_context_mapping:PCI: bdf = fe:2.1
(XEN) [VT-D]iommu.c:1237:d32767 domain_context_mapping:PCI: bdf = fe:2.4
(XEN) [VT-D]iommu.c:1237:d32767 domain_context_mapping:PCI: bdf = fe:2.5
(XEN) [VT-D]iommu.c:1237:d32767 domain_context_mapping:PCI: bdf = fe:3.0
(XEN) [VT-D]iommu.c:1237:d32767 domain_context_mapping:PCI: bdf = fe:3.1
(XEN) [VT-D]iommu.c:1237:d32767 domain_context_mapping:PCI: bdf = fe:3.2
(XEN) [VT-D]iommu.c:1237:d32767 domain_context_mapping:PCI: bdf = fe:3.4
(XEN) [VT-D]iommu.c:1237:d32767 domain_context_mapping:PCI: bdf = fe:4.0
(XEN) [VT-D]iommu.c:1237:d32767 domain_context_mapping:PCI: bdf = fe:4.1
(XEN) [VT-D]iommu.c:1237:d32767 domain_context_mapping:PCI: bdf = fe:4.2
(XEN) [VT-D]iommu.c:1237:d32767 domain_context_mapping:PCI: bdf = fe:4.3
(XEN) [VT-D]iommu.c:1237:d32767 domain_context_mapping:PCI: bdf = fe:5.0
(XEN) [VT-D]iommu.c:1237:d32767 domain_context_mapping:PCI: bdf = fe:5.1
(XEN) [VT-D]iommu.c:1237:d32767 domain_context_mapping:PCI: bdf = fe:5.2
(XEN) [VT-D]iommu.c:1237:d32767 domain_context_mapping:PCI: bdf = fe:5.3
(XEN) [VT-D]iommu.c:1237:d32767 domain_context_mapping:PCI: bdf = fe:6.0
(XEN) [VT-D]iommu.c:1237:d32767 domain_context_mapping:PCI: bdf = fe:6.1
(XEN) [VT-D]iommu.c:1237:d32767 domain_context_mapping:PCI: bdf = fe:6.2
(XEN) [VT-D]iommu.c:1237:d32767 domain_context_mapping:PCI: bdf = fe:6.3
(XEN) [VT-D]iommu.c:1237:d32767 domain_context_mapping:PCI: bdf = 0:1d.0
(XEN) [VT-D]iommu.c:1237:d32767 domain_context_mapping:PCI: bdf = 0:1d.1
(XEN) [VT-D]iommu.c:1237:d32767 domain_context_mapping:PCI: bdf = 0:1d.2
(XEN) [VT-D]iommu.c:1237:d32767 domain_context_mapping:PCI: bdf = 0:1d.7
(XEN) [VT-D]iommu.c:1237:d32767 domain_context_mapping:PCI: bdf = 0:1d.0
(XEN) [VT-D]iommu.c:1237:d32767 domain_context_mapping:PCI: bdf = 0:1d.1
(XEN) [VT-D]iommu.c:1237:d32767 domain_context_mapping:PCI: bdf = 0:1d.2
(XEN) [VT-D]iommu.c:1237:d32767 domain_context_mapping:PCI: bdf = 0:1d.7
(XEN) DMAR_IQA_REG = 7f79d000
(XEN) DMAR_IQH_REG = 0
(XEN) DMAR_IQT_REG = 20
(XEN)
(XEN) ****************************************
(XEN) Panic on CPU 0:
(XEN) queue invalidate wait descriptor was not executed
(XEN) ****************************************
(XEN)
(XEN) Reboot in five seconds...
[-- 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] 12+ messages in thread
* Re: XEN Panic with VT-d support enabled on Xeon E55xxplatform
2009-04-07 15:06 ` Isabelle, Francois
@ 2009-04-08 5:54 ` Zhao, Yu
2009-04-09 12:40 ` Isabelle, Francois
2009-04-16 13:50 ` Isabelle, Francois
0 siblings, 2 replies; 12+ messages in thread
From: Zhao, Yu @ 2009-04-08 5:54 UTC (permalink / raw)
To: Isabelle, Francois; +Cc: xen-devel, Cui, Dexuan
Francois,
Thank you for the log.
(XEN) [VT-D]iommu.c:1237:d32767 domain_context_mapping:PCI: bdf = 0:1d.0
Did you see 1 second delay after above line was printed? Or the system
got panic immediately following it?
(XEN) DMAR_IQA_REG = 7f79d000
(XEN) DMAR_IQH_REG = 0
(XEN) DMAR_IQT_REG = 20
(XEN)
(XEN) ****************************************
(XEN) Panic on CPU 0:
(XEN) queue invalidate wait descriptor was not executed
(XEN) ****************************************
(XEN)
(XEN) Reboot in five seconds...
Isabelle, Francois wrote:
>>> When you only use iommu=no-intremap and see the panic, can you attached >>the xen log?
>>> And can you also try iommu=passthrough,no-intremap and attach the log?
>
> See attached files.
>
>>> VT-d Context Entry is used, the DMA requests related to the Context Entry can bypass DMA remapping. This can be faster than DMA remapping.
> The BIOS does not have an option for this on my board. But I did mistook it for DMA remapping.
>
>
> And thank you for answering my questions.
>
> François Isabelle
>
>
>
>
> -----Message d'origine-----
> De : Cui, Dexuan [mailto:dexuan.cui@intel.com]
> Envoyé : 7 avril 2009 10:22
> À : Isabelle, Francois; Zhao, Yu
> Cc : xen-devel@lists.xensource.com
> Objet : RE: [Xen-devel] XEN Panic with VT-d support enabled on Xeon E55xxplatform
>
>>>> iommu=xxx
>> Dexuan, 'iommu=no-intremap' is not enough to make it run, ' iommu=no-qinval,no-intremap' allows booting.
> When you only use iommu=no-intremap and see the panic, can you attached the xen log?
> And can you also try iommu=passthrough,no-intremap and attach the log?
>
>>> (XEN) [VT-D]dmar.c:485: Host address width 39
>> Shouldn't this be 38 ?
> The Host Address Width (HAW) of the platform is computed as (N+1), where N is the value reported in the Host Address Width field of DMA Remapping Reporting Structure.
> Please see acpi_parse_dmar() or VT-d spec for details.
>
>>> (XEN) Intel VT-d Snoop Control supported.
>>> (XEN) Intel VT-d DMA Passthrough not supported.
>> Shouldn't that be enabled to support DMA from domU?
> If the "DMA Passthrough" (please don't mistake it for DMA remapping:-) of VT-d Context Entry is used, the DMA requests related to the Context Entry can bypass DMA remapping. This can be faster than DMA remapping. If you host supports DMA passthrough (you could check your BIOS setup menu), in Xen we can enable DMA passthrough by iommu=passthrough (Note, even with this parameter, we only enable passthrough for Dom0 considering secrity)
>
>
>>> (XEN) HPET broadcast init failed, turn to PIT broadcast.
>> Does that mean the HPET is not functional?
>>From hpet_fsb_cap_lookup(), looks your HPET timers may work, but they don't support FSB routing, so won't be used in power management code.
>
>> Can we expect a good level of performance with interrupt remapping disabled? Will a domU be able to load a 82576 driver and use the NIC at all?
> I think we should have almost the same performance with Interrupt Remapping enabled or disabled.
> 82576 should work in DomU.
>
> Thanks,
> -- Dexuan
>
>
>
> -----Original Message-----
> From: Isabelle, Francois [mailto:Francois.Isabelle@ca.kontron.com]
> Sent: Tuesday, April 07, 2009 9:12 PM
> To: Cui, Dexuan; Zhao, Yu
> Cc: xen-devel@lists.xensource.com
> Subject: RE: [Xen-devel] XEN Panic with VT-d support enabled on Xeon E55xxplatform
>
> Hi.
>
> Here is what you both asked for:
>
>>> Do you have this problem all the times? Can you please grab some logs
>>> and send them to me?
>
> Yes Yu, all the times. I will package the logs as attachment to this post.
>
>>> iommu=xxx
> Dexuan, 'iommu=no-intremap' is not enough to make it run, ' iommu=no-qinval,no-intremap' allows booting.
>
> Here are some parts of the log I don't understand...
>
>> (XEN) [VT-D]dmar.c:485: Host address width 39
> Shouldn't this be 38 ?
>
>> (XEN) Intel VT-d Snoop Control supported.
>> (XEN) Intel VT-d DMA Passthrough not supported.
> Shouldn't that be enabled to support DMA from domU?
>
>> (XEN) Intel VT-d Queued Invalidation supported.
>> (XEN) Intel VT-d Interrupt Remapping supported.
>
>> (XEN) HPET broadcast init failed, turn to PIT broadcast.
> Does that mean the HPET is not functional?
>
> Can we expect a good level of performance with interrupt remapping disabled? Will a domU be able to load a 82576 driver and use the NIC at all?
>
> Thank you both for your replies.
>
> François Isabelle
>
> -----Message d'origine-----
> De : Cui, Dexuan [mailto:dexuan.cui@intel.com]
> Envoyé : 7 avril 2009 03:05
> À : Zhao, Yu; Isabelle, Francois
> Cc : xen-devel@lists.xensource.com
> Objet : RE: [Xen-devel] XEN Panic with VT-d support enabled on Xeon E55xxplatform
>
>>> (XEN) DMAR_IQA_REG = 7f79d000
>>> (XEN) DMAR_IQH_REG = 0
>>> (XEN) DMAR_IQT_REG = 20
>> Here the IQT is such a big number 0x20... this seems pretty strange.
> Oh, actually this 0x20 is normal -- actually QT = IQT_REG >> 4 accoriding the format of IQT_REG in VT-d spec. So QT = 0x2 -- this is ok.
> So looks the panic somehow happens on the first invalidation: enable_intremap() -> iommu_flush_iec_global(). I expect your host can boot fine with iommu=no-intremap -- if this still doesn't work, could you please try iommu=no-qinval,no-intremap ?
>
> Thanks,
> -- Dexuan
>
>
>
> -----Original Message-----
> From: xen-devel-bounces@lists.xensource.com [mailto:xen-devel-bounces@lists.xensource.com] On Behalf Of Cui, Dexuan
> Sent: Tuesday, April 07, 2009 12:40 PM
> To: Zhao, Yu; Isabelle, Francois
> Cc: xen-devel@lists.xensource.com
> Subject: RE: [Xen-devel] XEN Panic with VT-d support enabled on Xeon E55xx platform
>
>> (XEN) DMAR_IQA_REG = 7f79d000
>> (XEN) DMAR_IQH_REG = 0
>> (XEN) DMAR_IQT_REG = 20
> Here the IQT is such a big number 0x20... this seems pretty strange.
>
> Hi François,
> And, could you please try the xen parameter "iommu=no-intremap" ? -- If you still see the panic, please also add the parameter "nosmp" to see if there would any change.
> We don't have the same host at hand. :-( So we need try these on your host.
> BTW, can you boot the same host using the latest native linux-2.6.29-rc8 when you iommu_intel=on and interrupt remapping is enabled?
>
> PS, what's your BIOS version and date -- could you try to find the latest BIOS for the host? I personally tend to think this is a BIOS issue.
>
> Thanks,
> -- Dexuan
>
>
>
> -----Original Message-----
> From: xen-devel-bounces@lists.xensource.com [mailto:xen-devel-bounces@lists.xensource.com] On Behalf Of Zhao, Yu
> Sent: Tuesday, April 07, 2009 10:31 AM
> To: Isabelle, Francois
> Cc: xen-devel@lists.xensource.com
> Subject: Re: [Xen-devel] XEN Panic with VT-d support enabled on Xeon E55xx platform
>
> Hi Francois,
>
> Do you have this problem all the times? Can you please grab some logs
> and send them to me? The dmesg from a native kernel if you can't boot up
> any version of Xen, and the whole Xen hypervisor log would help us to
> figure out the problem.
>
> Thanks,
> Yu
>
>
> Isabelle, Francois wrote:
>> Hi all,
>>
>> I'm working with a board on which XEN panics with the following message (see below). From what I can see on the lists, most of the problems on these platforms seem to be related to broken DMAR tables and RMRR, but this platform passes the VT-d firmware toolkit (http://edc.intel.com/Platforms/Xeon-5500/) successfully so I'm tented to blame XEN for it... should I file a bug entry?
>>
>> >From what I can see in the 'queue invalidation' code, a timeout is reached. As anyone seen this on a similar platform?
>>
>>
>> (XEN) Xen version 3.4-unstable (root@localdomain) (gcc version 4.1.2 20080704 (Red Hat 4.1.2-44)) Fri Apr 3 14:20:00 EDT 2009
>> (XEN) Latest ChangeSet: Mon Mar 30 16:48:26 2009 +0100 19433:d5ddc782bc49
>> (XEN) Command line: console=com1 com1=115200,8n1 iommu=1 loglvl=all loglvl_guest=all ro
>>
>> ..
>> (XEN) Enabling APIC mode: Flat. Using 1 I/O APICs
>> (XEN) ACPI: HPET id: 0xffffffff base: 0xfed00000
>> (XEN) [VT-D]dmar.c:485: Host address width 39
>> (XEN) [VT-D]dmar.c:494: found ACPI_DMAR_DRHD
>> (XEN) [VT-D]dmar.c:349: dmaru->address = fbffe000
>> (XEN) [VT-D]dmar.c:306: found IOAPIC: bdf = f0:1f.7
>> (XEN) [VT-D]dmar.c:358: found INCLUDE_ALL
>> (XEN) [VT-D]dmar.c:498: found ACPI_DMAR_RMRR
>> (XEN) [VT-D]dmar.c:300: found endpoint: bdf = 0:1d.0
>> (XEN) [VT-D]dmar.c:300: found endpoint: bdf = 0:1d.1
>> (XEN) [VT-D]dmar.c:300: found endpoint: bdf = 0:1d.2
>> (XEN) [VT-D]dmar.c:300: found endpoint: bdf = 0:1d.7
>> (XEN) [VT-D]dmar.c:498: found ACPI_DMAR_RMRR
>> (XEN) [VT-D]dmar.c:300: found endpoint: bdf = 0:1d.0
>> (XEN) [VT-D]dmar.c:300: found endpoint: bdf = 0:1d.1
>> (XEN) [VT-D]dmar.c:300: found endpoint: bdf = 0:1d.2
>> (XEN) [VT-D]dmar.c:300: found endpoint: bdf = 0:1d.7
>> (XEN) [VT-D]dmar.c:502: found ACPI_DMAR_ATSR
>> (XEN) [VT-D]dmar.c:287: found bridge: bdf = 0:3.0 sec = 5 sub = 5
>> (XEN) [VT-D]dmar.c:287: found bridge: bdf = 0:4.0 sec = 6 sub = e
>> (XEN) [VT-D]dmar.c:287: found bridge: bdf = 0:5.0 sec = 3 sub = 3
>> (XEN) [VT-D]dmar.c:287: found bridge: bdf = 0:7.0 sec = 18 sub = 18
>> (XEN) [VT-D]dmar.c:287: found bridge: bdf = 0:8.0 sec = f sub = 17
>> (XEN) [VT-D]dmar.c:287: found bridge: bdf = 0:9.0 sec = 4 sub = 4
>> (XEN) [VT-D]dmar.c:287: found bridge: bdf = 0:a.0 sec = 2 sub = 2
>> ..
>> (XEN) Intel VT-d Snoop Control supported.
>> (XEN) Intel VT-d DMA Passthrough not supported.
>> (XEN) Intel VT-d Queued Invalidation supported.
>> (XEN) Intel VT-d Interrupt Remapping supported.
>> (XEN) DMAR_IQA_REG = 7f79d000
>> (XEN) DMAR_IQH_REG = 0
>> (XEN) DMAR_IQT_REG = 20
>> (XEN)
>> (XEN) ****************************************
>> (XEN) Panic on CPU 0:
>> (XEN) queue invalidate wait descriptor was not executed
>> (XEN) ****************************************
>> (XEN)
>> (XEN) Reboot in five seconds...
>>
>> François Isabelle
>>
>> _______________________________________________
>> 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
>
^ permalink raw reply [flat|nested] 12+ messages in thread
* RE: XEN Panic with VT-d support enabled on Xeon E55xxplatform
2009-04-08 5:54 ` Zhao, Yu
@ 2009-04-09 12:40 ` Isabelle, Francois
2009-04-16 13:50 ` Isabelle, Francois
1 sibling, 0 replies; 12+ messages in thread
From: Isabelle, Francois @ 2009-04-09 12:40 UTC (permalink / raw)
To: Zhao, Yu; +Cc: xen-devel, Cui, Dexuan
>> Did you see 1 second delay after above line was printed? Or the system
got panic immediately following it?
Yes, maybe a little less but it's not immediate for sure.
François Isabelle
-----Message d'origine-----
De : Zhao, Yu [mailto:yu.zhao@intel.com]
Envoyé : 8 avril 2009 01:55
À : Isabelle, Francois
Cc : Cui, Dexuan; xen-devel@lists.xensource.com
Objet : Re: [Xen-devel] XEN Panic with VT-d support enabled on Xeon E55xxplatform
Francois,
Thank you for the log.
(XEN) [VT-D]iommu.c:1237:d32767 domain_context_mapping:PCI: bdf = 0:1d.0
Did you see 1 second delay after above line was printed? Or the system
got panic immediately following it?
(XEN) DMAR_IQA_REG = 7f79d000
(XEN) DMAR_IQH_REG = 0
(XEN) DMAR_IQT_REG = 20
(XEN)
(XEN) ****************************************
(XEN) Panic on CPU 0:
(XEN) queue invalidate wait descriptor was not executed
(XEN) ****************************************
(XEN)
(XEN) Reboot in five seconds...
Isabelle, Francois wrote:
>>> When you only use iommu=no-intremap and see the panic, can you attached >>the xen log?
>>> And can you also try iommu=passthrough,no-intremap and attach the log?
>
> See attached files.
>
>>> VT-d Context Entry is used, the DMA requests related to the Context Entry can bypass DMA remapping. This can be faster than DMA remapping.
> The BIOS does not have an option for this on my board. But I did mistook it for DMA remapping.
>
>
> And thank you for answering my questions.
>
> François Isabelle
>
>
>
>
> -----Message d'origine-----
> De : Cui, Dexuan [mailto:dexuan.cui@intel.com]
> Envoyé : 7 avril 2009 10:22
> À : Isabelle, Francois; Zhao, Yu
> Cc : xen-devel@lists.xensource.com
> Objet : RE: [Xen-devel] XEN Panic with VT-d support enabled on Xeon E55xxplatform
>
>>>> iommu=xxx
>> Dexuan, 'iommu=no-intremap' is not enough to make it run, ' iommu=no-qinval,no-intremap' allows booting.
> When you only use iommu=no-intremap and see the panic, can you attached the xen log?
> And can you also try iommu=passthrough,no-intremap and attach the log?
>
>>> (XEN) [VT-D]dmar.c:485: Host address width 39
>> Shouldn't this be 38 ?
> The Host Address Width (HAW) of the platform is computed as (N+1), where N is the value reported in the Host Address Width field of DMA Remapping Reporting Structure.
> Please see acpi_parse_dmar() or VT-d spec for details.
>
>>> (XEN) Intel VT-d Snoop Control supported.
>>> (XEN) Intel VT-d DMA Passthrough not supported.
>> Shouldn't that be enabled to support DMA from domU?
> If the "DMA Passthrough" (please don't mistake it for DMA remapping:-) of VT-d Context Entry is used, the DMA requests related to the Context Entry can bypass DMA remapping. This can be faster than DMA remapping. If you host supports DMA passthrough (you could check your BIOS setup menu), in Xen we can enable DMA passthrough by iommu=passthrough (Note, even with this parameter, we only enable passthrough for Dom0 considering secrity)
>
>
>>> (XEN) HPET broadcast init failed, turn to PIT broadcast.
>> Does that mean the HPET is not functional?
>>From hpet_fsb_cap_lookup(), looks your HPET timers may work, but they don't support FSB routing, so won't be used in power management code.
>
>> Can we expect a good level of performance with interrupt remapping disabled? Will a domU be able to load a 82576 driver and use the NIC at all?
> I think we should have almost the same performance with Interrupt Remapping enabled or disabled.
> 82576 should work in DomU.
>
> Thanks,
> -- Dexuan
>
>
>
> -----Original Message-----
> From: Isabelle, Francois [mailto:Francois.Isabelle@ca.kontron.com]
> Sent: Tuesday, April 07, 2009 9:12 PM
> To: Cui, Dexuan; Zhao, Yu
> Cc: xen-devel@lists.xensource.com
> Subject: RE: [Xen-devel] XEN Panic with VT-d support enabled on Xeon E55xxplatform
>
> Hi.
>
> Here is what you both asked for:
>
>>> Do you have this problem all the times? Can you please grab some logs
>>> and send them to me?
>
> Yes Yu, all the times. I will package the logs as attachment to this post.
>
>>> iommu=xxx
> Dexuan, 'iommu=no-intremap' is not enough to make it run, ' iommu=no-qinval,no-intremap' allows booting.
>
> Here are some parts of the log I don't understand...
>
>> (XEN) [VT-D]dmar.c:485: Host address width 39
> Shouldn't this be 38 ?
>
>> (XEN) Intel VT-d Snoop Control supported.
>> (XEN) Intel VT-d DMA Passthrough not supported.
> Shouldn't that be enabled to support DMA from domU?
>
>> (XEN) Intel VT-d Queued Invalidation supported.
>> (XEN) Intel VT-d Interrupt Remapping supported.
>
>> (XEN) HPET broadcast init failed, turn to PIT broadcast.
> Does that mean the HPET is not functional?
>
> Can we expect a good level of performance with interrupt remapping disabled? Will a domU be able to load a 82576 driver and use the NIC at all?
>
> Thank you both for your replies.
>
> François Isabelle
>
> -----Message d'origine-----
> De : Cui, Dexuan [mailto:dexuan.cui@intel.com]
> Envoyé : 7 avril 2009 03:05
> À : Zhao, Yu; Isabelle, Francois
> Cc : xen-devel@lists.xensource.com
> Objet : RE: [Xen-devel] XEN Panic with VT-d support enabled on Xeon E55xxplatform
>
>>> (XEN) DMAR_IQA_REG = 7f79d000
>>> (XEN) DMAR_IQH_REG = 0
>>> (XEN) DMAR_IQT_REG = 20
>> Here the IQT is such a big number 0x20... this seems pretty strange.
> Oh, actually this 0x20 is normal -- actually QT = IQT_REG >> 4 accoriding the format of IQT_REG in VT-d spec. So QT = 0x2 -- this is ok.
> So looks the panic somehow happens on the first invalidation: enable_intremap() -> iommu_flush_iec_global(). I expect your host can boot fine with iommu=no-intremap -- if this still doesn't work, could you please try iommu=no-qinval,no-intremap ?
>
> Thanks,
> -- Dexuan
>
>
>
> -----Original Message-----
> From: xen-devel-bounces@lists.xensource.com [mailto:xen-devel-bounces@lists.xensource.com] On Behalf Of Cui, Dexuan
> Sent: Tuesday, April 07, 2009 12:40 PM
> To: Zhao, Yu; Isabelle, Francois
> Cc: xen-devel@lists.xensource.com
> Subject: RE: [Xen-devel] XEN Panic with VT-d support enabled on Xeon E55xx platform
>
>> (XEN) DMAR_IQA_REG = 7f79d000
>> (XEN) DMAR_IQH_REG = 0
>> (XEN) DMAR_IQT_REG = 20
> Here the IQT is such a big number 0x20... this seems pretty strange.
>
> Hi François,
> And, could you please try the xen parameter "iommu=no-intremap" ? -- If you still see the panic, please also add the parameter "nosmp" to see if there would any change.
> We don't have the same host at hand. :-( So we need try these on your host.
> BTW, can you boot the same host using the latest native linux-2.6.29-rc8 when you iommu_intel=on and interrupt remapping is enabled?
>
> PS, what's your BIOS version and date -- could you try to find the latest BIOS for the host? I personally tend to think this is a BIOS issue.
>
> Thanks,
> -- Dexuan
>
>
>
> -----Original Message-----
> From: xen-devel-bounces@lists.xensource.com [mailto:xen-devel-bounces@lists.xensource.com] On Behalf Of Zhao, Yu
> Sent: Tuesday, April 07, 2009 10:31 AM
> To: Isabelle, Francois
> Cc: xen-devel@lists.xensource.com
> Subject: Re: [Xen-devel] XEN Panic with VT-d support enabled on Xeon E55xx platform
>
> Hi Francois,
>
> Do you have this problem all the times? Can you please grab some logs
> and send them to me? The dmesg from a native kernel if you can't boot up
> any version of Xen, and the whole Xen hypervisor log would help us to
> figure out the problem.
>
> Thanks,
> Yu
>
>
> Isabelle, Francois wrote:
>> Hi all,
>>
>> I'm working with a board on which XEN panics with the following message (see below). From what I can see on the lists, most of the problems on these platforms seem to be related to broken DMAR tables and RMRR, but this platform passes the VT-d firmware toolkit (http://edc.intel.com/Platforms/Xeon-5500/) successfully so I'm tented to blame XEN for it... should I file a bug entry?
>>
>> >From what I can see in the 'queue invalidation' code, a timeout is reached. As anyone seen this on a similar platform?
>>
>>
>> (XEN) Xen version 3.4-unstable (root@localdomain) (gcc version 4.1.2 20080704 (Red Hat 4.1.2-44)) Fri Apr 3 14:20:00 EDT 2009
>> (XEN) Latest ChangeSet: Mon Mar 30 16:48:26 2009 +0100 19433:d5ddc782bc49
>> (XEN) Command line: console=com1 com1=115200,8n1 iommu=1 loglvl=all loglvl_guest=all ro
>>
>> ..
>> (XEN) Enabling APIC mode: Flat. Using 1 I/O APICs
>> (XEN) ACPI: HPET id: 0xffffffff base: 0xfed00000
>> (XEN) [VT-D]dmar.c:485: Host address width 39
>> (XEN) [VT-D]dmar.c:494: found ACPI_DMAR_DRHD
>> (XEN) [VT-D]dmar.c:349: dmaru->address = fbffe000
>> (XEN) [VT-D]dmar.c:306: found IOAPIC: bdf = f0:1f.7
>> (XEN) [VT-D]dmar.c:358: found INCLUDE_ALL
>> (XEN) [VT-D]dmar.c:498: found ACPI_DMAR_RMRR
>> (XEN) [VT-D]dmar.c:300: found endpoint: bdf = 0:1d.0
>> (XEN) [VT-D]dmar.c:300: found endpoint: bdf = 0:1d.1
>> (XEN) [VT-D]dmar.c:300: found endpoint: bdf = 0:1d.2
>> (XEN) [VT-D]dmar.c:300: found endpoint: bdf = 0:1d.7
>> (XEN) [VT-D]dmar.c:498: found ACPI_DMAR_RMRR
>> (XEN) [VT-D]dmar.c:300: found endpoint: bdf = 0:1d.0
>> (XEN) [VT-D]dmar.c:300: found endpoint: bdf = 0:1d.1
>> (XEN) [VT-D]dmar.c:300: found endpoint: bdf = 0:1d.2
>> (XEN) [VT-D]dmar.c:300: found endpoint: bdf = 0:1d.7
>> (XEN) [VT-D]dmar.c:502: found ACPI_DMAR_ATSR
>> (XEN) [VT-D]dmar.c:287: found bridge: bdf = 0:3.0 sec = 5 sub = 5
>> (XEN) [VT-D]dmar.c:287: found bridge: bdf = 0:4.0 sec = 6 sub = e
>> (XEN) [VT-D]dmar.c:287: found bridge: bdf = 0:5.0 sec = 3 sub = 3
>> (XEN) [VT-D]dmar.c:287: found bridge: bdf = 0:7.0 sec = 18 sub = 18
>> (XEN) [VT-D]dmar.c:287: found bridge: bdf = 0:8.0 sec = f sub = 17
>> (XEN) [VT-D]dmar.c:287: found bridge: bdf = 0:9.0 sec = 4 sub = 4
>> (XEN) [VT-D]dmar.c:287: found bridge: bdf = 0:a.0 sec = 2 sub = 2
>> ..
>> (XEN) Intel VT-d Snoop Control supported.
>> (XEN) Intel VT-d DMA Passthrough not supported.
>> (XEN) Intel VT-d Queued Invalidation supported.
>> (XEN) Intel VT-d Interrupt Remapping supported.
>> (XEN) DMAR_IQA_REG = 7f79d000
>> (XEN) DMAR_IQH_REG = 0
>> (XEN) DMAR_IQT_REG = 20
>> (XEN)
>> (XEN) ****************************************
>> (XEN) Panic on CPU 0:
>> (XEN) queue invalidate wait descriptor was not executed
>> (XEN) ****************************************
>> (XEN)
>> (XEN) Reboot in five seconds...
>>
>> François Isabelle
>>
>> _______________________________________________
>> 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
>
^ permalink raw reply [flat|nested] 12+ messages in thread
* RE: XEN Panic with VT-d support enabled on Xeon E55xxplatform
2009-04-08 5:54 ` Zhao, Yu
2009-04-09 12:40 ` Isabelle, Francois
@ 2009-04-16 13:50 ` Isabelle, Francois
2009-06-03 12:02 ` Testing Intel 82599 under XEN Isabelle, Francois
1 sibling, 1 reply; 12+ messages in thread
From: Isabelle, Francois @ 2009-04-16 13:50 UTC (permalink / raw)
To: Zhao, Yu; +Cc: xen-devel, Cui, Dexuan
Just to let you know..
It turned out that our DMAR table was wrongly providing IOMMU DRHD table for inactive channel (isochronous HD audio is disabled); our AMI BIOS was clearing the "non isoch" bit in the VTISOCHCTRL register.
Thank you.
François Isabelle
-----Message d'origine-----
De : Zhao, Yu [mailto:yu.zhao@intel.com]
Envoyé : 8 avril 2009 01:55
À : Isabelle, Francois
Cc : Cui, Dexuan; xen-devel@lists.xensource.com
Objet : Re: [Xen-devel] XEN Panic with VT-d support enabled on Xeon E55xxplatform
Francois,
Thank you for the log.
(XEN) [VT-D]iommu.c:1237:d32767 domain_context_mapping:PCI: bdf = 0:1d.0
Did you see 1 second delay after above line was printed? Or the system
got panic immediately following it?
(XEN) DMAR_IQA_REG = 7f79d000
(XEN) DMAR_IQH_REG = 0
(XEN) DMAR_IQT_REG = 20
(XEN)
(XEN) ****************************************
(XEN) Panic on CPU 0:
(XEN) queue invalidate wait descriptor was not executed
(XEN) ****************************************
(XEN)
(XEN) Reboot in five seconds...
Isabelle, Francois wrote:
>>> When you only use iommu=no-intremap and see the panic, can you attached >>the xen log?
>>> And can you also try iommu=passthrough,no-intremap and attach the log?
>
> See attached files.
>
>>> VT-d Context Entry is used, the DMA requests related to the Context Entry can bypass DMA remapping. This can be faster than DMA remapping.
> The BIOS does not have an option for this on my board. But I did mistook it for DMA remapping.
>
>
> And thank you for answering my questions.
>
> François Isabelle
>
>
>
>
> -----Message d'origine-----
> De : Cui, Dexuan [mailto:dexuan.cui@intel.com]
> Envoyé : 7 avril 2009 10:22
> À : Isabelle, Francois; Zhao, Yu
> Cc : xen-devel@lists.xensource.com
> Objet : RE: [Xen-devel] XEN Panic with VT-d support enabled on Xeon E55xxplatform
>
>>>> iommu=xxx
>> Dexuan, 'iommu=no-intremap' is not enough to make it run, ' iommu=no-qinval,no-intremap' allows booting.
> When you only use iommu=no-intremap and see the panic, can you attached the xen log?
> And can you also try iommu=passthrough,no-intremap and attach the log?
>
>>> (XEN) [VT-D]dmar.c:485: Host address width 39
>> Shouldn't this be 38 ?
> The Host Address Width (HAW) of the platform is computed as (N+1), where N is the value reported in the Host Address Width field of DMA Remapping Reporting Structure.
> Please see acpi_parse_dmar() or VT-d spec for details.
>
>>> (XEN) Intel VT-d Snoop Control supported.
>>> (XEN) Intel VT-d DMA Passthrough not supported.
>> Shouldn't that be enabled to support DMA from domU?
> If the "DMA Passthrough" (please don't mistake it for DMA remapping:-) of VT-d Context Entry is used, the DMA requests related to the Context Entry can bypass DMA remapping. This can be faster than DMA remapping. If you host supports DMA passthrough (you could check your BIOS setup menu), in Xen we can enable DMA passthrough by iommu=passthrough (Note, even with this parameter, we only enable passthrough for Dom0 considering secrity)
>
>
>>> (XEN) HPET broadcast init failed, turn to PIT broadcast.
>> Does that mean the HPET is not functional?
>>From hpet_fsb_cap_lookup(), looks your HPET timers may work, but they don't support FSB routing, so won't be used in power management code.
>
>> Can we expect a good level of performance with interrupt remapping disabled? Will a domU be able to load a 82576 driver and use the NIC at all?
> I think we should have almost the same performance with Interrupt Remapping enabled or disabled.
> 82576 should work in DomU.
>
> Thanks,
> -- Dexuan
>
>
>
> -----Original Message-----
> From: Isabelle, Francois [mailto:Francois.Isabelle@ca.kontron.com]
> Sent: Tuesday, April 07, 2009 9:12 PM
> To: Cui, Dexuan; Zhao, Yu
> Cc: xen-devel@lists.xensource.com
> Subject: RE: [Xen-devel] XEN Panic with VT-d support enabled on Xeon E55xxplatform
>
> Hi.
>
> Here is what you both asked for:
>
>>> Do you have this problem all the times? Can you please grab some logs
>>> and send them to me?
>
> Yes Yu, all the times. I will package the logs as attachment to this post.
>
>>> iommu=xxx
> Dexuan, 'iommu=no-intremap' is not enough to make it run, ' iommu=no-qinval,no-intremap' allows booting.
>
> Here are some parts of the log I don't understand...
>
>> (XEN) [VT-D]dmar.c:485: Host address width 39
> Shouldn't this be 38 ?
>
>> (XEN) Intel VT-d Snoop Control supported.
>> (XEN) Intel VT-d DMA Passthrough not supported.
> Shouldn't that be enabled to support DMA from domU?
>
>> (XEN) Intel VT-d Queued Invalidation supported.
>> (XEN) Intel VT-d Interrupt Remapping supported.
>
>> (XEN) HPET broadcast init failed, turn to PIT broadcast.
> Does that mean the HPET is not functional?
>
> Can we expect a good level of performance with interrupt remapping disabled? Will a domU be able to load a 82576 driver and use the NIC at all?
>
> Thank you both for your replies.
>
> François Isabelle
>
> -----Message d'origine-----
> De : Cui, Dexuan [mailto:dexuan.cui@intel.com]
> Envoyé : 7 avril 2009 03:05
> À : Zhao, Yu; Isabelle, Francois
> Cc : xen-devel@lists.xensource.com
> Objet : RE: [Xen-devel] XEN Panic with VT-d support enabled on Xeon E55xxplatform
>
>>> (XEN) DMAR_IQA_REG = 7f79d000
>>> (XEN) DMAR_IQH_REG = 0
>>> (XEN) DMAR_IQT_REG = 20
>> Here the IQT is such a big number 0x20... this seems pretty strange.
> Oh, actually this 0x20 is normal -- actually QT = IQT_REG >> 4 accoriding the format of IQT_REG in VT-d spec. So QT = 0x2 -- this is ok.
> So looks the panic somehow happens on the first invalidation: enable_intremap() -> iommu_flush_iec_global(). I expect your host can boot fine with iommu=no-intremap -- if this still doesn't work, could you please try iommu=no-qinval,no-intremap ?
>
> Thanks,
> -- Dexuan
>
>
>
> -----Original Message-----
> From: xen-devel-bounces@lists.xensource.com [mailto:xen-devel-bounces@lists.xensource.com] On Behalf Of Cui, Dexuan
> Sent: Tuesday, April 07, 2009 12:40 PM
> To: Zhao, Yu; Isabelle, Francois
> Cc: xen-devel@lists.xensource.com
> Subject: RE: [Xen-devel] XEN Panic with VT-d support enabled on Xeon E55xx platform
>
>> (XEN) DMAR_IQA_REG = 7f79d000
>> (XEN) DMAR_IQH_REG = 0
>> (XEN) DMAR_IQT_REG = 20
> Here the IQT is such a big number 0x20... this seems pretty strange.
>
> Hi François,
> And, could you please try the xen parameter "iommu=no-intremap" ? -- If you still see the panic, please also add the parameter "nosmp" to see if there would any change.
> We don't have the same host at hand. :-( So we need try these on your host.
> BTW, can you boot the same host using the latest native linux-2.6.29-rc8 when you iommu_intel=on and interrupt remapping is enabled?
>
> PS, what's your BIOS version and date -- could you try to find the latest BIOS for the host? I personally tend to think this is a BIOS issue.
>
> Thanks,
> -- Dexuan
>
>
>
> -----Original Message-----
> From: xen-devel-bounces@lists.xensource.com [mailto:xen-devel-bounces@lists.xensource.com] On Behalf Of Zhao, Yu
> Sent: Tuesday, April 07, 2009 10:31 AM
> To: Isabelle, Francois
> Cc: xen-devel@lists.xensource.com
> Subject: Re: [Xen-devel] XEN Panic with VT-d support enabled on Xeon E55xx platform
>
> Hi Francois,
>
> Do you have this problem all the times? Can you please grab some logs
> and send them to me? The dmesg from a native kernel if you can't boot up
> any version of Xen, and the whole Xen hypervisor log would help us to
> figure out the problem.
>
> Thanks,
> Yu
>
>
> Isabelle, Francois wrote:
>> Hi all,
>>
>> I'm working with a board on which XEN panics with the following message (see below). From what I can see on the lists, most of the problems on these platforms seem to be related to broken DMAR tables and RMRR, but this platform passes the VT-d firmware toolkit (http://edc.intel.com/Platforms/Xeon-5500/) successfully so I'm tented to blame XEN for it... should I file a bug entry?
>>
>> >From what I can see in the 'queue invalidation' code, a timeout is reached. As anyone seen this on a similar platform?
>>
>>
>> (XEN) Xen version 3.4-unstable (root@localdomain) (gcc version 4.1.2 20080704 (Red Hat 4.1.2-44)) Fri Apr 3 14:20:00 EDT 2009
>> (XEN) Latest ChangeSet: Mon Mar 30 16:48:26 2009 +0100 19433:d5ddc782bc49
>> (XEN) Command line: console=com1 com1=115200,8n1 iommu=1 loglvl=all loglvl_guest=all ro
>>
>> ..
>> (XEN) Enabling APIC mode: Flat. Using 1 I/O APICs
>> (XEN) ACPI: HPET id: 0xffffffff base: 0xfed00000
>> (XEN) [VT-D]dmar.c:485: Host address width 39
>> (XEN) [VT-D]dmar.c:494: found ACPI_DMAR_DRHD
>> (XEN) [VT-D]dmar.c:349: dmaru->address = fbffe000
>> (XEN) [VT-D]dmar.c:306: found IOAPIC: bdf = f0:1f.7
>> (XEN) [VT-D]dmar.c:358: found INCLUDE_ALL
>> (XEN) [VT-D]dmar.c:498: found ACPI_DMAR_RMRR
>> (XEN) [VT-D]dmar.c:300: found endpoint: bdf = 0:1d.0
>> (XEN) [VT-D]dmar.c:300: found endpoint: bdf = 0:1d.1
>> (XEN) [VT-D]dmar.c:300: found endpoint: bdf = 0:1d.2
>> (XEN) [VT-D]dmar.c:300: found endpoint: bdf = 0:1d.7
>> (XEN) [VT-D]dmar.c:498: found ACPI_DMAR_RMRR
>> (XEN) [VT-D]dmar.c:300: found endpoint: bdf = 0:1d.0
>> (XEN) [VT-D]dmar.c:300: found endpoint: bdf = 0:1d.1
>> (XEN) [VT-D]dmar.c:300: found endpoint: bdf = 0:1d.2
>> (XEN) [VT-D]dmar.c:300: found endpoint: bdf = 0:1d.7
>> (XEN) [VT-D]dmar.c:502: found ACPI_DMAR_ATSR
>> (XEN) [VT-D]dmar.c:287: found bridge: bdf = 0:3.0 sec = 5 sub = 5
>> (XEN) [VT-D]dmar.c:287: found bridge: bdf = 0:4.0 sec = 6 sub = e
>> (XEN) [VT-D]dmar.c:287: found bridge: bdf = 0:5.0 sec = 3 sub = 3
>> (XEN) [VT-D]dmar.c:287: found bridge: bdf = 0:7.0 sec = 18 sub = 18
>> (XEN) [VT-D]dmar.c:287: found bridge: bdf = 0:8.0 sec = f sub = 17
>> (XEN) [VT-D]dmar.c:287: found bridge: bdf = 0:9.0 sec = 4 sub = 4
>> (XEN) [VT-D]dmar.c:287: found bridge: bdf = 0:a.0 sec = 2 sub = 2
>> ..
>> (XEN) Intel VT-d Snoop Control supported.
>> (XEN) Intel VT-d DMA Passthrough not supported.
>> (XEN) Intel VT-d Queued Invalidation supported.
>> (XEN) Intel VT-d Interrupt Remapping supported.
>> (XEN) DMAR_IQA_REG = 7f79d000
>> (XEN) DMAR_IQH_REG = 0
>> (XEN) DMAR_IQT_REG = 20
>> (XEN)
>> (XEN) ****************************************
>> (XEN) Panic on CPU 0:
>> (XEN) queue invalidate wait descriptor was not executed
>> (XEN) ****************************************
>> (XEN)
>> (XEN) Reboot in five seconds...
>>
>> François Isabelle
>>
>> _______________________________________________
>> 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
>
^ permalink raw reply [flat|nested] 12+ messages in thread
* Testing Intel 82599 under XEN
2009-04-16 13:50 ` Isabelle, Francois
@ 2009-06-03 12:02 ` Isabelle, Francois
2009-06-03 20:12 ` Rose, Gregory V
0 siblings, 1 reply; 12+ messages in thread
From: Isabelle, Francois @ 2009-06-03 12:02 UTC (permalink / raw)
To: Zhao, Yu; +Cc: xen-devel
Hi.
I noticed you submitted 82576 quirks for XEN, I was wondering if we could expect similar patches for the 10GE 82599 chip? Right now the Beta driver I have access to crashes under XEN.
Have you got a chance to test this network controller yet ?
Thank you
François Isabelle
^ permalink raw reply [flat|nested] 12+ messages in thread
* RE: Testing Intel 82599 under XEN
2009-06-03 12:02 ` Testing Intel 82599 under XEN Isabelle, Francois
@ 2009-06-03 20:12 ` Rose, Gregory V
0 siblings, 0 replies; 12+ messages in thread
From: Rose, Gregory V @ 2009-06-03 20:12 UTC (permalink / raw)
To: Isabelle, Francois, Zhao, Yu; +Cc: xen-devel
The quirk submitted for the 82576 was for SR-IOV enablement on systems for which there is no native SR-IOV support. Unless Yu Zhao has submitted other quirks for the device that I missed...
Intel has not yet delivered or published any SR-IOV driver enablement for the 82599. It's in the works is about all I can say. The Beta driver you have is for Linux and has little or no testing on Xen. Normally a driver that works in Linux will work in Xen but as noted it is Beta level only and I'd not be surprised to hear of issues with it.
Regards,
Greg Rose
Intel Lan Access Division
-----Original Message-----
From: xen-devel-bounces@lists.xensource.com [mailto:xen-devel-bounces@lists.xensource.com] On Behalf Of Isabelle, Francois
Sent: Wednesday, June 03, 2009 5:02 AM
To: Zhao, Yu
Cc: xen-devel@lists.xensource.com
Subject: [Xen-devel] Testing Intel 82599 under XEN
Hi.
I noticed you submitted 82576 quirks for XEN, I was wondering if we could expect similar patches for the 10GE 82599 chip? Right now the Beta driver I have access to crashes under XEN.
Have you got a chance to test this network controller yet ?
Thank you
François Isabelle
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel
^ permalink raw reply [flat|nested] 12+ messages in thread
end of thread, other threads:[~2009-06-03 20:12 UTC | newest]
Thread overview: 12+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2009-04-06 15:52 XEN Panic with VT-d support enabled on Xeon E55xx platform Isabelle, Francois
2009-04-07 2:31 ` Zhao, Yu
2009-04-07 4:40 ` Cui, Dexuan
2009-04-07 7:05 ` Cui, Dexuan
2009-04-07 13:12 ` XEN Panic with VT-d support enabled on Xeon E55xxplatform Isabelle, Francois
2009-04-07 14:21 ` Cui, Dexuan
2009-04-07 15:06 ` Isabelle, Francois
2009-04-08 5:54 ` Zhao, Yu
2009-04-09 12:40 ` Isabelle, Francois
2009-04-16 13:50 ` Isabelle, Francois
2009-06-03 12:02 ` Testing Intel 82599 under XEN Isabelle, Francois
2009-06-03 20:12 ` Rose, Gregory V
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.