WARNING - OLD ARCHIVES

This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
   
 
 
Xen 
 
Home Products Support Community News
 
   
 

xen-devel

[Xen-devel] RE: Workaround for the corrupted Intel X48 DMAR table

To: "Han, Weidong" <weidong.han@xxxxxxxxx>, "Neo Jia" <neojia@xxxxxxxxx>
Subject: [Xen-devel] RE: Workaround for the corrupted Intel X48 DMAR table
From: "Han, Weidong" <weidong.han@xxxxxxxxx>
Date: Thu, 17 Jul 2008 17:35:04 +0800
Cc: "Zhao, Yu" <yu.zhao@xxxxxxxxx>, xen-devel@xxxxxxxxxxxxxxxxxxx, "Yang, Xiaowei" <xiaowei.yang@xxxxxxxxx>, Jean Guyader <jean.guyader@xxxxxxxxxxxxx>
Delivery-date: Thu, 17 Jul 2008 02:35:35 -0700
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
In-reply-to: <0122C7C995D32147B66BF4F440D301630159F2DF@xxxxxxxxxxxxxxxxxxxxxxxxxxxx>
List-help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-id: Xen developer discussion <xen-devel.lists.xensource.com>
List-post: <mailto:xen-devel@lists.xensource.com>
List-subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
References: <5d649bdb0807151831j38ca8810gf045ccc588ee04b@xxxxxxxxxxxxxx> <0122C7C995D32147B66BF4F440D301630159F2DF@xxxxxxxxxxxxxxxxxxxxxxxxxxxx>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
Thread-index: Acjm46trbdPTQFZcS1Swxf4Z1icDSQABZjxwAEEBctA=
Thread-topic: Workaround for the corrupted Intel X48 DMAR table
Neo,
 
Pls try attached patch, which return error when rmrr range is incorrect during DMAR parsing. This results in disable VT-d. It should let your machine boot successfully. BTW, we are cleaning up VT-d code to handle errors gracefully.
 
Randy (Weidong)


From: Han, Weidong
Sent: 2008年7月16日 10:14
To: 'Neo Jia'
Cc: 'xen-devel@xxxxxxxxxxxxxxxxxxx'; Zhao, Yu; 'Jean Guyader'
Subject: RE: Workaround for the corrupted Intel X48 DMAR table

From your log, one RMRR range is incorrect: (XEN) RMRR: base address = 80000000, end address = 7fffffff.
 
We are setting up environment to debug this issue.  
 
Randy (Weidong)


From: Neo Jia [mailto:neojia@xxxxxxxxx]
Sent: 2008年7月16日 9:31
To: Han, Weidong
Cc: xen-devel@xxxxxxxxxxxxxxxxxxx; Zhao, Yu; Jean Guyader
Subject: Re: Workaround for the corrupted Intel X48 DMAR table

Randy,

I finally can get the serial port PCI card working, though it will hangs the Dom0 but it is enough for me at this moment. The following is the log after applying your patch.

Thanks,
Neo

(XEN)  VGA is graphics mode 1280x1024, 32 bpp
(XEN)  VBE/DDC methods: none; EDID transfer time: 0 seconds
(XEN)  EDID info not retrieved because no DDC retrieval method detected
(XEN) Disc information:
(XEN)  Found 1 MBR signatures
(XEN)  Found 1 EDD information structures
(XEN) Xen-e820 RAM map:
(XEN)  0000000000000000 - 000000000009dc00 (usable)
(XEN)  000000000009dc00 - 00000000000a0000 (reserved)
(XEN)  00000000000e0000 - 0000000000100000 (reserved)
(XEN)  0000000000100000 - 000000007ebf1000 (usable)
(XEN)  000000007ebf1000 - 000000007ec76000 (ACPI NVS)
(XEN)  000000007ec76000 - 000000007fdf1000 (usable)
(XEN)  000000007fdf1000 - 000000007fdf3000 (reserved)
(XEN)  000000007fdf3000 - 000000007fe8b000 (usable)
(XEN)  000000007fe8b000 - 000000007fee1000 (ACPI NVS)
(XEN)  000000007fee1000 - 000000007fee6000 (usable)
(XEN)  000000007fee6000 - 000000007fef2000 (ACPI data)
(XEN)  000000007fef2000 - 000000007fef3000 (usable)
(XEN)  000000007fef3000 - 000000007feff000 (ACPI data)
(XEN)  000000007feff000 - 000000007ff00000 (usable)
(XEN)  000000007ff00000 - 0000000080000000 (reserved)
(XEN)  00000000f0000000 - 00000000f8000000 (reserved)
(XEN)  00000000ffe00000 - 0000000100000000 (reserved)
(XEN) System RAM: 2045MB (2094752kB)
(XEN) ACPI: RSDP 000FE020, 0014 (r0 INTEL )
(XEN) ACPI: RSDT 7FEFD038, 0068 (r1 INTEL  DX48BT2       612       1000013)
(XEN) ACPI: FACP 7FEFC000, 0074 (r1 INTEL  DX48BT2       612 MSFT  1000013)
(XEN) ACPI: DSDT 7FEF7000, 4076 (r1 INTEL  DX48BT2       612 MSFT  1000013)
(XEN) ACPI: FACS 7FE9A000, 0040
(XEN) ACPI: APIC 7FEF6000, 0078 (r1 INTEL  DX48BT2       612 MSFT  1000013)
(XEN) ACPI: WDDT 7FEF5000, 0040 (r1 INTEL  DX48BT2       612 MSFT  1000013)
(XEN) ACPI: MCFG 7FEF4000, 003C (r1 INTEL  DX48BT2       612 MSFT  1000013)
(XEN) ACPI: ASF! 7FEF3000, 00A6 (r32 INTEL  DX48BT2       612 MSFT  1000013)
(XEN) ACPI: DMAR 7FEF1000, 0120 (r1 INTEL  DX48BT2       612 MSFT  1000013)
(XEN) ACPI: SSDT 7FEEE000, 0204 (r1 INTEL     CpuPm      612 MSFT  1000013)
(XEN) ACPI: SSDT 7FEED000, 01F9 (r1 INTEL   Cpu0Ist      612 MSFT  1000013)
(XEN) ACPI: SSDT 7FEEC000, 01F9 (r1 INTEL   Cpu1Ist      612 MSFT  1000013)
(XEN) ACPI: SSDT 7FEEB000, 01F9 (r1 INTEL   Cpu2Ist      612 MSFT  1000013)
(XEN) ACPI: SSDT 7FEEA000, 01F9 (r1 INTEL   Cpu3Ist      612 MSFT  1000013)
(XEN) ACPI: SSDT 7FEE9000, 01CF (r1 INTEL   Cpu0Cst      612 MSFT  1000013)
(XEN) ACPI: SSDT 7FEE8000, 01CF (r1 INTEL   Cpu1Cst      612 MSFT  1000013)
(XEN) ACPI: SSDT 7FEE7000, 01CF (r1 INTEL   Cpu2Cst      612 MSFT  1000013)
(XEN) ACPI: SSDT 7FEE6000, 01CF (r1 INTEL   Cpu3Cst      612 MSFT  1000013)
(XEN) ACPI: WDTT 7FEEF000, 02CC (r1 INTEL  DX48BT2       612 MSFT  1000013)
(XEN) ACPI: ASPT 7FEF0000, 002C (r1 INTEL  PerfTune      612 MSFT  1000013)
(XEN) Xen heap: 14MB (14752kB)
(XEN) Domain heap initialised: DMA width 32 bits
(XEN) Processor #0 6:15 APIC version 20
(XEN) Processor #2 6:15 APIC version 20
(XEN) Processor #1 6:15 APIC version 20
(XEN) Processor #3 6:15 APIC version 20
(XEN) IOAPIC[0]: apic_id 2, version 32, address 0xfec00000, GSI 0-23
(XEN) Enabling APIC mode:  Flat.  Using 1 I/O APICs
(XEN) RMRR: base address = e0000, end address = effff
(XEN) RMRR: base address = 80000000, end address = 7fffffff
(XEN) Intel VT-d has been enabled
(XEN) Using scheduler: SMP Credit Scheduler (credit)
(XEN) Detected 2400.150 MHz processor.
(XEN) HVM: VMX enabled
(XEN) CPU0: Intel(R) Core(TM)2 Quad CPU    Q6600  @ 2.40GHz stepping 0b
(XEN) Booting processor 1/2 eip 8c000
(XEN) CPU1: Intel(R) Core(TM)2 Quad CPU    Q6600  @ 2.40GHz stepping 0b
(XEN) Booting processor 2/1 eip 8c000
(XEN) CPU2: Intel(R) Core(TM)2 Quad CPU    Q6600  @ 2.40GHz stepping 0b
(XEN) Booting processor 3/3 eip 8c000
(XEN) CPU3: Intel(R) Core(TM)2 Quad CPU    Q6600  @ 2.40GHz stepping 0b
(XEN) Total of 4 processors activated.
(XEN) ENABLING IO-APIC IRQs
(XEN)  -> Using new ACK method
(XEN) Platform timer is 3.579MHz ACPI PM Timer
(XEN) Brought up 4 CPUs
(XEN) I/O virtualisation enabled
(XEN) I/O virtualisation for PV guests disabled
(XEN)
(XEN) ****************************************
(XEN) Panic on CPU 0:
(XEN) iommu_enable_translation(676): DMAR hardware is malfunctional, please disable IOMMU
(XEN) ****************************************
(XEN)
(XEN) Reboot in five seconds...


On Mon, Jul 14, 2008 at 2:01 AM, Han, Weidong <weidong.han@xxxxxxxxx> wrote:
Neo,
 
Can you try attached patch? I guess you are using add-on graphics card, right?
 
Randy (weidong)


From: Han, Weidong
Sent: 2008年7月14日 16:00
To: 'Neo Jia'; 'xen-devel@xxxxxxxxxxxxxxxxxxx'
Cc: Zhao, Yu; 'Jean Guyader'
Subject: RE: Workaround for the corrupted Intel X48 DMAR table

It should be a BIOS bug.
 
Can you post your changes in "acpi_parse_one_rmrr" function and panic information?
 
Randy (Weidong)


From: Neo Jia [mailto:neojia@xxxxxxxxx]
Sent: 2008年7月14日 14:48
Cc: Han, Weidong; Zhao, Yu; Jean Guyader
Subject: Workaround for the corrupted Intel X48 DMAR table

hi,

I am trying the Xen unstable on X48 chipset these days but it failed due to an corrupted RMRR table in the ACPI. The following is the acpi dump of DMAR.

DMAR @ 0x7fef1000
  0000: 44 4d 41 52 20 01 00 00 01 d1 49 4e 54 45 4c 20  DMAR .....INTEL
  0010: 44 58 34 38 42 54 32 20 12 06 00 00 4d 53 46 54  DX48BT2 ....MSFT
  0020: 13 00 00 01 23 00 00 00 00 00 00 00 00 00 00 00  ....#...........
  0030: 00 00 18 00 00 00 00 00 00 00 b0 fe 00 00 00 00  ................
  0040: 01 08 00 00 00 00 1b 00 00 00 20 00 00 00 00 00  .......... .....
  0050: 00 10 b0 fe 00 00 00 00 01 08 00 00 00 00 02 00  ................
  0060: 01 08 00 00 00 00 02 01 00 00 28 00 00 00 00 00  ..........(.....
  0070: 00 20 b0 fe 00 00 00 00 01 08 00 00 00 00 03 00  . ..............
  0080: 01 08 00 00 00 00 03 02 01 08 00 00 00 00 03 03  ................
  0090: 00 00 10 00 01 00 00 00 00 30 b0 fe 00 00 00 00  .........0......
  00a0: 01 00 58 00 00 00 00 00 00 00 0e 00 00 00 00 00  ..X.............
  00b0: ff ff 0e 00 00 00 00 00 01 08 00 00 00 00 1d 00  ................
  00c0: 01 08 00 00 00 00 1d 01 01 08 00 00 00 00 1d 02  ................
  00d0: 01 08 00 00 00 00 1d 07 01 08 00 00 00 00 1a 00  ................
  00e0: 01 08 00 00 00 00 1a 01 01 08 00 00 00 00 1a 02  ................
  00f0: 01 08 00 00 00 00 1a 07 01 00 28 00 00 00 00 00  ..........(.....
  0100: 00 00 00 80 00 00 00 00 ff ff ff 7f 00 00 00 00  ................
  0110: 01 08 00 00 00 00 02 00 01 08 00 00 00 00 02 01  ................

In line: 0100: 00 00 00 80 00 00 00 00 ff ff ff 7f 00 00 00 00, the RMRR reserved memory region starting address is even higher than its limit address.

Is there anyway to do a software workaround for this issue? I tried to simply ignore that entry in the "acpi_parse_one_rmrr" function, but I hit a panic in function "iommu_enable_translation".

Thanks,
Neo

--
I would remember that if researchers were not ambitious
probably today we haven't the technology we are using!




--
I would remember that if researchers were not ambitious
probably today we haven't the technology we are using!

Attachment: rmrr_check.patch
Description: rmrr_check.patch

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel