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: "Neo Jia" <neojia@xxxxxxxxx>, <xen-devel@xxxxxxxxxxxxxxxxxxx>
Subject: [Xen-devel] RE: Workaround for the corrupted Intel X48 DMAR table
From: "Han, Weidong" <weidong.han@xxxxxxxxx>
Date: Mon, 14 Jul 2008 15:59:53 +0800
Cc: "Zhao, Yu" <yu.zhao@xxxxxxxxx>, Jean Guyader <jean.guyader@xxxxxxxxxxxxx>
Delivery-date: Mon, 14 Jul 2008 01:00:31 -0700
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
In-reply-to: <5d649bdb0807132347y23d19142n4f07eacb16d0845e@xxxxxxxxxxxxxx>
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: <5d649bdb0807132347y23d19142n4f07eacb16d0845e@xxxxxxxxxxxxxx>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
Thread-index: AcjlfY0nnba5fOoVTQmYMVW++S0W4wACcTdA
Thread-topic: 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
To: xen-devel@xxxxxxxxxxxxxxxxxxx
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!

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